Tools, MCPs und Skills · Lektion 5 von 6
KI-Fehler eingrenzen: Verbindung, Modell und Speicher
‚Geht nicht‘ beschreibt das Ergebnis, aber noch nicht die Ursache. Trenne Verbindung, Zugriff, Modell und Verarbeitung, bevor du etwas umstellst.
Nach dieser Lektion
Das kannst du prüfen.
Du bestimmst die Fehlerstelle, notierst relevante Bedingungen und prüfst eine Ursache nach der anderen.
- Du brauchst
- Eine Fehlermeldung oder die drei erfundenen Fälle der Übung. Für echte lokale Tests ein bereits eingerichtetes Ollama; für die Lernübung nicht nötig.
Kurz erklärt
Grenze einen KI-Fehler zuerst auf Verbindung, Zugang, Modell oder Verarbeitung ein. Notiere Meldung und Bedingungen, bilde eine Hypothese und ändere nur einen Punkt. Bei einem Timeout prüfst du vor einer Wiederholung auch mögliche bereits erfolgte Aktionen.
Zuerst bestimmen, welcher Teil scheitert
Notiere Anwendung, Version, Betriebsart und den letzten erfolgreichen Schritt. Ein lokales Modell, eine Cloud-API und ein MCP-Zugang sind verschiedene Datenwege. Eine Meldung des Clients kann deshalb eine andere Ursache haben als eine Fehlermeldung des Servers.
Halte den genauen Text, Statuscode und Zeitpunkt fest. Entferne Zugangsdaten sowie private Inhalte, bevor du ein Protokoll teilst. Ein Screenshot der gesamten Konfiguration ist dafür oft unnötig; eine bereinigte Meldung und die relevanten Bedingungen reichen für die erste Eingrenzung.
Passende Anleitung: Läuft dein Ollama in einem Container, kannst du „Ollama in Docker auf drei Ebenen prüfen“ als Diagnosefolge nutzen. Halte dabei Containerstatus, erreichbare API und vorhandene Modelle als getrennte Befunde fest.
Statuscode und Detailmeldung zusammen lesen
Bei der OpenAI-API steht 401 für ein Authentifizierungsproblem. Eine 429-Meldung kann unter anderem eine Anfragerate, ein Guthaben- oder Ausgabenlimit betreffen; prüfe den konkreten Fehlercode. Ein neuer Versuch löst einen ungültigen Zugang oder ein unverändertes Budgetlimit nicht automatisch.
Ein Timeout sagt zunächst, dass der Client nicht rechtzeitig ein Ergebnis erhalten hat. Eine bereits gestartete Aktion kann trotzdem Wirkung gehabt haben. Prüfe bei schreibenden oder sendenden Aufgaben den tatsächlichen Zustand, bevor du sie erneut auslöst.
Passende Anleitung: Kommt die Anfrage aus n8n, hilft dir „n8n-Zugangsdaten und Zugriffsfehler prüfen“ beim Abgleich von Dienst, Credential-Typ und Berechtigung. Der Guide ersetzt keine Prüfung des konkreten Fehlercodes beim angesprochenen Anbieter.
Vom Lesen zum eigenen Versuch
So beginnst du.
Eine Fehlermeldung oder die drei erfundenen Fälle der Übung. Für echte lokale Tests ein bereits eingerichtetes Ollama; für die Lernübung nicht nötig.
- 01
Einen kleinen reproduzierbaren Fall sichern
Nutze erfundene Eingaben und die kleinste Anfrage, die den Fehler zeigt. Notiere erwartetes Ergebnis und beobachtete Meldung.
Erkennbar an: Der Fehlerfall ist ohne private Daten beschreibbar.
- 02
Verbindung getrennt prüfen
Bei Ollama prüfst du Laufzeit und Modellliste. Bei einer Cloud-API prüfst du dokumentierten Endpunkt und Zugang. Bei MCP prüfst du Servereintrag und verfügbare Werkzeuge. Ändere keine Firewall oder Zertifikatsprüfung pauschal.
Erkennbar an: Du weißt, ob der Client den vorgesehenen Dienst überhaupt erreicht.
- 03
Modell und Anfrage eingrenzen
Vergleiche Modelltag, Berechtigung, Eingabeformat und Größe mit der konkreten Dokumentation. Bei lokalem Betrieb prüfst du Logs und Ressourcen. Verkleinere einen Test oder ändere eine Einstellung einzeln.
Erkennbar an: Jede Änderung hat eine vorher formulierte Erwartung.
- 04
Wiederholung begrenzen und Ergebnis festhalten
Bei einer vorübergehenden Störung warte gemäß Anbieterhinweis und begrenze Versuche. Bei Zugriff, Eingabe oder Budget korrigierst du zunächst die Ursache. Halte auch fehlgeschlagene Tests fest.
Erkennbar an: Du erkennst, wann du stoppen und den bereinigten Befund weitergeben solltest.
Windows · Lokalen Dienst anfragen
PowerShellTeste zuerst nur die Erreichbarkeit. Leere models-Daten und ein Verbindungsfehler bedeuten unterschiedliche Dinge.
Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/tags"macOS/Linux · Lokalen Dienst anfragen
TerminalDas ist die entsprechende lokale Anfrage im Terminal, kein neuer Modelllauf.
curl -s http://127.0.0.1:11434/api/tagsDie Installation und ein echter Modelllauf wurden für dieses Lernmaterial nicht auf deinem Gerät ausgeführt. Die Grafiken erklären den Ablauf; sie sind keine Screenshots oder Leistungsmessungen.
Die erste Frage hängt von der Meldung ab
| Beobachtung im Lernfall | Erster getrennter Prüfschritt |
|---|---|
| Connection refused | Ist der vorgesehene lokale Dienst erreichbar? |
| HTTP 401 | Stimmen Zugang und Projekt? Keine Schlüssel teilen. |
| HTTP 429 + credit_balance_exhausted | Konkreten Guthabenfehler einordnen; Wiederholen behebt ihn nicht. |
Jetzt bist du dran
Drei Fehler richtig einordnen
Fülle das Diagnoseblatt für jeden Fall aus. Erkläre außerdem, warum du bei C nicht einfach viele neue Anfragen senden solltest.
Dein Übungsmaterial
Eigenes Lernbeispiel · keine echten Kundendaten
Erfundene Diagnosefälle: A: Lokaler Client meldet ‚connection refused‘ für localhost:11434; ein Serverstatus wurde noch nicht geprüft. B: OpenAI-Anfrage liefert HTTP 401 und eine Meldung zu ungültiger Authentifizierung. C: OpenAI-Anfrage liefert HTTP 429, code: credit_balance_exhausted. Diagnoseblatt: Ebene / erste Hypothese / einzelner Prüfschritt / beobachtetes Ergebnis / nächste Entscheidung.
Optionaler Arbeitsauftrag
Für deinen eigenen Versuch. Diese Seite führt den Auftrag nicht aus.
Ordne die drei Fälle ein. Trenne Beobachtung und Vermutung. Nenne je Fall einen ersten Prüfschritt, ohne Zugangsdaten anzufordern, Limits zu erhöhen oder eine Außenwirkung zu wiederholen.
Lösungshinweis und mögliche Lösung
- A: zunächst Verbindung beziehungsweise erreichbarer lokaler Dienst prüfen. ‚Connection refused‘ beweist für sich weder einen kaputten Modelltag noch zu wenig Grafikspeicher.
- B: Zugang und das verwendete Projekt prüfen. Teile dabei keinen Schlüssel und entferne Geheimnisse aus dem Protokoll.
- C: der konkrete Code nennt erschöpftes Guthaben. Wiederholen verändert diesen Zustand nicht. Die Kontoeinstellungen werden gesondert geprüft; diese Übung autorisiert keinen Kauf.
- Für einen echten Fehler bleiben weitere Ursachen möglich. Notiere eine bestätigte Beobachtung erst nach dem entsprechenden Test.
Achte darauf: Mehrere Einstellungen gleichzeitig ändern und anschließend nicht mehr wissen, welche Änderung geholfen hat.
Du bist fertig, wenn Du kannst pro Fall die Ebene, eine begründete Hypothese und einen begrenzten nächsten Prüfschritt nennen.
Ein kurzer Selbsttest
Hast du den Unterschied erkannt?
Das Häkchen ist deine eigene Einschätzung. Speichern ist unten freiwillig.
Im Lernpfad Tools, MCPs und Skills findest du die vorherigen Setup-Schritte zu diesem Diagnoseblatt. Gehe zum letzten bestätigten Schritt zurück, wenn die Fehlerstelle noch offen ist.
Häufige Fragen
Soll ich meinen API-Schlüssel im Fehlerprotokoll zeigen?
Nein. Entferne Schlüssel, Tokens und private Eingaben. Beschreibe den Zugang mit neutralen Angaben und einer bereinigten Meldung.
Behebt ein neuer Versuch jede 429-Meldung?
Nein. Prüfe den konkreten Anbieterfehlercode. Anfragerate und Guthaben- oder Ausgabenlimit benötigen unterschiedliche nächste Schritte.
Wo finde ich lokale Ollama-Fehler?
Die Herstelleranleitung beschreibt Logs für Betriebssystem, Dienst und Container. Nutze den Pfad deines konkreten Betriebs und ändere nicht pauschal die gesamte Umgebung.
Was unterscheidet einen Verbindungsfehler von einer leeren Modellliste?
Bei einem Verbindungsfehler erhältst du keine passende Dienstantwort. Eine erfolgreich gelesene leere Liste ist dagegen eine Antwort ohne vorhandene Modelle. Prüfe Dienst und Modellbestand getrennt.
Warum notiere ich vor jeder Änderung eine Erwartung?
So kannst du feststellen, ob genau diese Änderung den Fehler beeinflusst. Ändere einen Punkt, beobachte das Ergebnis und halte auch erfolglose Versuche fest.
Verständlichkeit, Lernführung und FAQs redaktionell geprüft am . Die technischen Quellenstände stehen bei den jeweiligen Anleitungen. Beispiele bleiben als eigene Übungsfälle gekennzeichnet.
Quellen & Einordnung · 14. Oktober 2026
Weiterlesen und Angaben prüfen.
Fehlercodes und Wiederholungsverhalten sind produkt- und ebenenabhängig. Die drei Fälle sind eigene Lernbeispiele. Es wurde keine konkrete Fehlersituation auf deinem Rechner oder Konto diagnostiziert.
Optional · nur dieser Browser
An deiner Stelle weiterlernen.
Die Einheiten bleiben ohne Anmeldung nutzbar. Erst nach deinem Klick merkt sich dieser Browser deine Häkchen. Du kannst sie jederzeit löschen. Quizantworten werden nicht gespeichert oder versendet.
Fortschritt wird aktuell nicht gespeichert.