Ollama im Dauerbetrieb: sieben Fehler, die wie Modellfehler aussehen — und es nicht sind

Ollama im Dauerbetrieb heißt: kein Chatfenster, keine Demo, sondern ein Dienst, der Wochen am Stück tausende Dokumente durch dasselbe Modell schiebt. Die meisten Fehler, die dabei wie eine Schwäche des Modells aussehen — abgeschnittene Antworten, plötzliche Langsamkeit, fremde Felder im JSON, ein Lauf, der scheinbar nichts tut — sind Konfigurations-, Ressourcen- und Prozessfehler. Dieser Artikel zeigt sieben davon aus unserem eigenen Betrieb: je mit Symptom, der naheliegenden Fehldiagnose, der tatsächlichen Ursache und dem einen Prüfschritt, mit dem du sie in Minuten von einem echten Modellproblem unterscheidest. Stand: September 2026.

Wer zuerst wissen will, welches Modell überhaupt zu welchem Zweck passt, findet das in Ollama und offene KI-Modelle: Welches Modell für welchen Zweck?; wie sich Modelle in der Qualität unterscheiden, zeigt der Blindtest Welches lokale KI-Modell schreibt das beste Deutsch?. Hier geht es um das, was danach kommt: den Betrieb.

Woran erkennst du, ob das Modell schuld ist?

Ein Modellfehler ist reproduzierbar an der Aufgabe, nicht an der Umgebung: dasselbe Dokument, derselbe Prompt, dieselbe falsche Antwort — auf jeder Maschine, in jedem Fenster, zu jeder Tageszeit. Ändert sich das Ergebnis mit der Dokumentlänge, der Uhrzeit, der Anzahl paralleler Läufe oder nach einem Neustart, liegt die Ursache fast immer außerhalb des Modells. Diese Frage zuerst zu stellen spart Wochen.

Der Grund, warum die Fehldiagnose so beliebt ist: Ollama ist schnell installiert, und die ersten Tests mit kurzen Prompts laufen tadellos. Der Dauerbetrieb bringt dann Dinge ins Spiel, die kein Testprompt zeigt — lange Dokumente, Pausen zwischen Batch-Schüben, eine zweite Pipeline auf demselben Server, ein hart abgebrochener Lauf. Jeder dieser Faktoren erzeugt ein Fehlerbild, das täuschend nach „Modell" aussieht.

Alle Zahlen in diesem Artikel stammen aus einem realen System: einem Dokumentenbestand aus mehreren tausend Geschäftsberichten, verarbeitet über Monate auf einem CPU-Server ohne Grafikkarte sowie auf einer GPU-Workstation, gemessen zwischen Juni und September 2026. Sie sind Beispiele, keine Benchmarks — deine Zahlen werden andere sein, das Muster nicht.

Fehler 1: „Das Modell kann kein sauberes JSON"

Die Antwort bricht mitten im JSON ab, der Parser wirft einen Fehler, und die Diagnose lautet „dieses Modell hält das Format nicht durch". In unserem Fall war das Kontextfenster mit 16.384 Token konfiguriert, das Dokument hatte 32.316 Token — für die Antwort blieben 135 Token, und die rohe Antwort endete nach dem dritten Feld auf .",.

Das ist kein Modellfehler, sondern Arithmetik: Systemanweisung plus Dokument füllen das Fenster, die Antwort bekommt den Rest. Ein Modell, das bei 135 Token Restplatz „kein JSON kann", kann bei 4.000 Token Restplatz plötzlich sehr wohl. Und der Fall war kein Ausreißer — eine Bestandsaufnahme zeigte, dass 2.048 von 3.853 Dokumenten über dem konfigurierten Fenster lagen. Mehr als die Hälfte.

Prüfschritt: Sieh dir die rohe, ungeparste Antwort an, nicht die Fehlermeldung des Parsers. Endet sie unvermittelt ohne schließende Klammer, ist es das Fenster. Miss danach die Tokenverteilung deines echten Bestands — nicht den Durchschnitt, sondern den oberen Rand — bevor du ein Fenster festlegst. Eine Schätzung „das reicht sicher" ist keine Messung.

Fehler 2: „Das Modell ist heute langsam"

Nach einer Pause dauert die erste Antwort ein Vielfaches der zweiten. Auf unserem CPU-Server antwortete ein 7B-Modell warm in 66 Sekunden; nach dem Entladen aus dem Speicher brauchte derselbe Aufruf 171 Sekunden, ein 30B-Modell beim Kaltstart 818 Sekunden. Das Modell war nie langsam — es war weg.

Ollama entlädt ein Modell nach einer konfigurierbaren Standzeit aus dem Speicher. Läuft eine Batch-Pipeline in Schüben mit Pausen dazwischen, entscheidet dieser eine Wert darüber, ob jeder Schub mit einem Kaltstart beginnt. Bei einem 30B-Modell sind das fast 14 Minuten, in denen scheinbar „das Modell rechnet" — tatsächlich liest es 18 GB von der Platte.

Prüfschritt: Schick denselben Aufruf zweimal direkt hintereinander. Ist der zweite um ein Vielfaches schneller, hast du keinen Modell-, sondern einen Standzeit-Fall. Wie lange ein Modell im Speicher bleiben sollte, hängt von deinem Schub-Muster ab — nicht von einer Empfehlung aus dem Netz.

Fehler 3: „Der Server ist zu klein"

Der Durchsatz liegt weit unter dem, was die Hardware hergeben müsste, und die Diagnose lautet „CPU-Server reicht nicht für KI". Bei uns war ein CPU-Kontingent von drei Kernen gesetzt, während die KI-Software intern mit acht parallelen Strängen arbeitete — der vollen Kernzahl der Maschine, unabhängig vom Kontingent.

Das Betriebssystem misst Rechenzeit in Zeitscheiben: Acht Stränge laufen kurz an, verbrauchen das Budget von drei Kernen in einem Bruchteil der Scheibe und werden dann abrupt gestoppt. Das Ergebnis ist Stop-and-Go statt gleichmäßiger Auslastung. Sichtbar wurde das nur an den realen Tokens pro Sekunde eines langen Dokuments — ein kurzer Testprompt läuft zu schnell durch, um den Effekt zu zeigen.

Derselbe Server lehrte uns noch etwas: Die Ressourcengrenzen waren auf einem veralteten Kommentar in der Konfiguration aufgebaut, der 16 GB Arbeitsspeicher behauptete. Die Maschine hatte rund 125 GB. Die Limits wurden zweimal nachjustiert, weil die ersten Annahmen falsch waren — RAM war nie das Problem, CPU schon. Ein Kommentar ist keine Messung.

Prüfschritt: Vergleiche die interne Strangzahl der KI-Software aus dem Prozesslog mit dem gesetzten CPU-Kontingent. Zwei unabhängige Limits, die keines vom anderen weiß — sie müssen von Hand synchron gehalten werden. Und lies die tatsächlichen Werte der Maschine aus, statt sie aus einer Config-Datei zu übernehmen.

Fehler 4: „Die Antwort kommt nie"

Ein Aufruf läuft und läuft; irgendwann greift der Timeout, der Speicher war die ganze Zeit belegt. Bei uns geriet ein Modell bei einem bestimmten Dokument in eine Schleife und produzierte über 220.000 Ausgabe-Token — weil niemand eine Obergrenze gesetzt hatte.

Ein Sprachmodell hat kein eingebautes „das reicht jetzt". Es erzeugt Token, bis etwas es stoppt: das Ende-Zeichen, das Kontextfenster oder eine explizite Ausgabe-Obergrenze. Fehlt die Obergrenze, ist ein einziges pathologisches Dokument genug, um einen Batch-Slot für Stunden zu blockieren. Das ist keine Modellschwäche, sondern ein fehlender Riegel im Aufruf.

Prüfschritt: Sieh in den Aufruf-Optionen nach, ob überhaupt eine Ausgabe-Obergrenze gesetzt ist. Wenn nicht, hast du keinen Timeout-Fall, sondern einen Konfigurationsfall — und zwar in jeder Aufgabe, nicht nur in der, die gerade aufgefallen ist.

Fehler 5: „Zwei Pipelines parallel sind schneller"

Zwei dauerhaft laufende Aufgaben teilen sich einen Server, der nur einen Aufruf gleichzeitig verarbeitet. Beide gleichzeitig zu starten klingt fair und schnell — es war die langsamere Variante. Gemessen: 2.720 Token pro Sekunde bei der Prompt-Verarbeitung, wenn zwei aufeinanderfolgende Aufrufe zur selben Aufgabe gehörten, gegenüber 2.353 Token pro Sekunde nach einem Wechsel zur anderen Aufgabe — 13,5 Prozent weniger.

Der Grund ist ein versteckter Vorteil: Das Modell hält einen Zwischenspeicher für den zuletzt verarbeiteten Prompt-Anfang, typischerweise die Systemanweisung, die bei jedem Aufruf derselben Aufgabe identisch ist. Bleibt die Aufgabe gleich, wird dieser Teil aus dem Cache bedient. Wechselt sie, wird der Cache verworfen. Bei echtem Parallelstart meldet praktisch jeder Aufruf einen Wechsel — der Vorteil bleibt fast nie erhalten. Echte Gleichzeitigkeit gab es dabei nie; die Hardware war nie doppelt beschäftigt.

Prüfschritt: Vergleiche die Prompt-Verarbeitungsrate zweier aufeinanderfolgender Aufrufe derselben Aufgabe mit der nach einem Aufgabenwechsel. Liegt ein zweistelliger Unterschied dazwischen, verschenkt der Parallelstart Durchsatz — und die Lösung kostet keine Rechenzeit, nur eine andere Reihenfolge. Wie die Steuerung dafür aussieht und wann das Muster nicht passt (Stichwort: dringende Einzelanfragen), gehört ins Seminar Lokale KI für Datenanalyse und Datenextraktion.

Fehler 6: „Das Modell beantwortet eine andere Frage"

Die Antwort ist einwandfreies JSON, lässt sich fehlerfrei parsen — enthält aber völlig andere Felder als angefordert: statt der verlangten Klassifikation kommen Kennzahlen, statt Kategorien eine Zusammenfassung, und bei jedem Dokument ein anderes erfundenes Schema. Über alle 50 Aufrufe gerechnet lag die Quote bei 14 Prozent — unauffällig genug, um sie als allgemeine Modellschwäche abzutun.

Erst die Aufschlüsselung nach Prompt-Größe zeigte, dass es keine Schwäche, sondern eine scharfe Grenze war: Unter 10.000 Token trat der Fehler in 0 von 41 Aufrufen auf, ab 20.000 Token in 7 von 9. Modelle gewichten Anfang und Ende eines langen Kontexts stärker als die Mitte. Liegen zwischen Anweisung und Antwort zehntausende Zeichen Fließtext, dominiert der Inhalt die Aufgabe: Das Modell sieht einen Geschäftsbericht und tut das Naheliegende.

Prüfschritt: Schlüssle die Fehlerquote nach Prompt-Größe auf, nie als Gesamtwert. Springt sie an einer Schwelle, ist es kein Rauschen, sondern Positionierung — und die ist eine Frage des Prompt-Aufbaus, nicht des Modells.

Fehler 7: „Der Lauf tut nichts"

Drei frisch gestartete Batch-Prozesse laufen, die Grafikkarte schläft, die Logs bleiben leer. Kein Fehler, kein Abbruch, nur Stillstand. Bei uns hielten drei „Leichen" — hart per Tastenkombination beendete Vorgänger — ihre Slots weiter besetzt, und die neuen Läufe warteten 40 Minuten untätig, weil die Selbstheilung des Slot-Managers auf 55 Minuten eingestellt war.

Ein Batch-System, das gleichzeitige Modell-Nutzer begrenzt, braucht eine Buchführung darüber, wer gerade einen Slot hält. Wird ein Prozess hart beendet, gibt er den Slot nicht frei — die Buchführung glaubt, er arbeite noch. Das ist ein Prozessfehler, kein KI-Fehler, und er entsteht in dem Moment, in dem jemand „nur mal schnell" den Lauf abbricht und neu startet.

Prüfschritt: Prüfe, ob die Prozesse, die laut Buchführung einen Slot halten, überhaupt noch existieren. Läuft die Prozess-ID nicht mehr, hält ein Toter den Platz. Und: Wer stoppt und neu startet, muss zwischen den beiden Schritten aufräumen — sonst wiederholt sich das Bild sofort. Für die laufende Beobachtung von Slots, Modellen und Token-Raten haben wir uns ein eigenes Werkzeug gebaut: ollama-top, ein Terminal-Monitor für Ollama und GPUs.

Die sieben Fehler im Überblick

Keiner dieser sieben Fälle wäre durch einen Modellwechsel verschwunden. Bei zweien hätte er ihn sogar verschleiert — ein anderes Modell mit größerem Fenster oder anderer Kontextgewichtung hätte die Ursache verdeckt, bis das nächste Dokument sie wieder freilegt.

Häufige Fragen

Warum bricht Ollama JSON-Antworten mitten im Wert ab?

Fast immer, weil das Kontextfenster für Eingabe und Ausgabe zusammen zu klein ist: Systemanweisung und Dokument belegen den Platz, für die Antwort bleiben wenige Token, und das Modell hört mitten im Feld auf. Die rohe Antwort endet dann ohne schließende Klammer. Erst wenn das Fenster nachweislich groß genug ist, lohnt sich ein Blick auf das Modell.

Warum ist die erste Antwort nach einer Pause so langsam?

Weil Ollama das Modell nach einer Standzeit aus dem Speicher entlädt und beim nächsten Aufruf neu von der Platte lädt. Auf einem CPU-Server haben wir für ein 7B-Modell 66 Sekunden warm gegen 171 Sekunden kalt gemessen, für ein 30B-Modell 818 Sekunden. Der zweite Aufruf direkt danach ist wieder schnell — das ist das sicherste Erkennungszeichen.

Reicht ein Server ohne Grafikkarte für Ollama im Dauerbetrieb?

Für nicht zeitkritische Batch-Aufgaben ja, wenn Kontextfenster, CPU-Kontingent und interne Strangzahl zusammenpassen. Unser Dokumentenbestand lief monatelang auf einem CPU-Server mit acht Kernen. Für interaktive Anwendungen mit Antwortzeiten im Sekundenbereich ist eine Grafikkarte dagegen die Voraussetzung, nicht die Kür.

Ist es ein Modellfehler, wenn derselbe Aufruf zweimal verschieden antwortet?

Nein, das ist echter Nicht-Determinismus, der lokale wie Cloud-Modelle gleichermaßen betrifft — auch bei einer Temperatur von null. Wer ein Ergebnis für „das" Ergebnis hält, sollte den Aufruf mindestens dreimal wiederholt haben. Für Entscheidungen, die daran hängen, braucht es eine Regel, wie mit Uneinigkeit umgegangen wird.

Sollte ich zwei Batch-Pipelines auf einem Ollama-Server parallel starten?

Wenn der Server nur einen Aufruf gleichzeitig verarbeitet, nein: Jeder Aufgabenwechsel verwirft den Prompt-Cache, bei uns kostete das 13,5 Prozent Prompt-Durchsatz. Echte Gleichzeitigkeit entsteht dabei nicht, die Hardware war nie doppelt beschäftigt. Entscheidend ist die Reihenfolge der Aufrufe — wie man sie ordnet, ohne Durchsatz zu verlieren, ist eine Frage der Steuerung, nicht des Modells.

Woran erkenne ich, dass ein Batch-Lauf hängt statt zu arbeiten?

An der Diskrepanz zwischen Buchführung und Realität: Prozesse laufen, aber die Grafikkarte oder CPU ist untätig und die Logs bleiben leer. Prüfe, ob die Prozesse, die laut Slot-Verwaltung arbeiten, noch existieren — hart beendete Vorgänger halten ihre Slots, bis eine Selbstheilung greift, bei uns nach 55 Minuten.

Die achte Frage: Brauchst du dafür überhaupt ein Modell?

Sieben Fehler, und jeder war teuer, bevor er verstanden war. Die achte Frage steht vor allen anderen: Ob die Aufgabe ein Sprachmodell überhaupt braucht — oder ob es nur die bequemste Antwort war. Ein Modell ist die teuerste Sprosse einer Leiter, und die letzte: Es kostet je Aufruf Rechenzeit, seine Antworten sind nicht reproduzierbar, und jede Angabe, die es liefert, muss belegt werden, bevor sie irgendwo landet. Wer eine Zahl braucht, die im Dokument maschinenlesbar vorliegt, oder einen Abschnitt, der eine feste Überschrift hat, bezahlt mit dem Modell für etwas, das eine Regel in Mikrosekunden und mit Beleg liefert.

Warum das so ist, steht hier. Wie man die drei Sprossen davor für den eigenen Bestand baut — welche Quellen es gibt, wie man den Zielbereich schneidet, wo eine Regel reicht und wo nicht — ist die Arbeit, die wir im Seminar an echten Dokumenten machen, nicht in einem Artikel. Wer den Weg vom Modell zurück zur Regel einmal gegangen ist, stellt die achte Frage danach vor jedem Projekt zuerst.

Verwandte Seminare und Artikel

• Ollama und offene KI-Modelle: Welches Modell für welchen Zweck? — Grundlagen: welches Modell für welchen Zweck, was die „B"-Zahl bedeutet und welche Hardware es verlangt.
• Welches lokale KI-Modell schreibt das beste Deutsch? — der Blindtest: 14 Modelle an echten Geschäftsberichten, und warum die naheliegende Metrik in die Irre führt.
• Lokale KI im Unternehmen: Volle Power, Daten bleiben im Haus — für Entscheider: Datenschutz, Kosten und Einführungsweg lokaler KI.
• ollama-top — Terminal-Monitor für Ollama, GPUs, Multi-Instance LLMs & Enterprise-Datenbanken — unser Terminal-Monitor für Ollama, GPUs und Token-Raten, Open Source.
• pgvector: KI-Suche direkt in PostgreSQL — Embeddings und semantische Suche direkt in PostgreSQL, die Basis für lokales RAG.
• Lokale KI für Datenanalyse & Datenextraktion — Seminar — das Seminar zu diesem Artikel: Betrieb, Kontextfenster, Fehlerbilder und Modellvergleich an eigenen Dokumenten.
• KI in PHP integrieren — Architektur für mehrere Anbieter (Seminar) — für Entwickler: lokale und entfernte Modelle hinter einer gemeinsamen Schnittstelle, austauschbar.
• Programmieren mit lokaler KI: Dein Code bleibt im Haus — Code-Assistenten komplett lokal betreiben.
• Datenbankanalysen mit KI – SQL-Seminar mit AI — SQL und KI: Abfragen schreiben, optimieren, migrieren.

Im Seminar vertiefen

Die sieben Fehler sind die Diagnose; die Einstellung dahinter — Fenster bemessen, Standzeiten und Kontingente an gemessenen Schüben ausrichten, Pipelines ordnen, Slots sauber verwalten — erarbeiten wir im Seminar Lokale KI für Datenanalyse und Datenextraktion an deinem eigenen Dokumentenbestand. Wer die Modelle danach in eine Anwendung einbauen will, so dass der Anbieter austauschbar bleibt, findet den Architekturteil in KI in PHP integrieren. Beides findet als Inhouse-Seminar bei dir vor Ort — Köln/Leverkusen vorn, bundesweit — oder remote statt; für laufende Systeme gibt es die begleitete Variante direkt an deinen Servern.

Seminare, Coaching und Projektunterstützung richten sich an Unternehmen, Behörden und Selbstständige. Die Anfrage ist unverbindlich und kostenlos; Umfang und Konditionen klären wir danach individuell.