2026 Ollama-CPU-Inferenz zu langsam: erst optimieren oder den Server wechseln?

Entscheidungsrahmen: Optimieren Sie zuerst Modell, Kontext, Arbeitsspeicher und Containergrenzen; wechseln Sie den Server erst, wenn eine wiederholbare Messung einen Ressourcenengpass zeigt. Wenn geringe Latenz oder hohe parallele Last zwingend sind, ist ein leistungsfähigerer CPU-Server nicht automatisch die Lösung: Dann sollte eine GPU-gestützte Inferenz oder eine externe Modell-API geprüft werden.

Dieser Leitfaden ist für Entwickler gedacht, deren Ollama-CPU-only-Inferenz zu langsam antwortet und die Ursachen systematisch eingrenzen möchten.
Auch kleine Teams mit selbst gehosteten KI-Anwendungen oder Wissensdatenbanken können damit entscheiden, ob Anwendungen, Vektorsuche und Modellinferenz getrennt laufen sollten.
Technische Verantwortliche vor einem Wechsel von VPS auf einen dedizierten Server erhalten eine Messbasis, bevor sie Ressourcen einkaufen.

Zuletzt aktualisiert am 23.10.2026; geprüft anhand des Ollama-Blogs, der offiziellen Veröffentlichungen und der verlinkten Produktdokumentation.

Zuerst den Engpass eingrenzen

Eine CPU-Inferenz ist nicht automatisch fehlerhaft, nur weil sie sich anders anfühlt als eine GPU-gestützte Antwort. Ohne GPU berechnet die CPU die Modelloperationen; ein großes Modell, ein langer Eingabetext oder konkurrierende Prozesse können die Antwort zusätzlich verzögern. Deshalb reicht die Beobachtung „es dauert lange“ nicht als Grundlage für einen Serverwechsel.

Entscheidend ist, welche Phase langsam ist. Dauert es vor der ersten Ausgabe, kann das auf Modellladung, Speicherbedarf oder I/O hindeuten. Kommt die erste Ausgabe zügig, die weitere Generierung aber langsam, liegt der Schwerpunkt eher auf der Berechnung während der Inferenz. Stockt die Antwort nur bei zusätzlicher Nutzung, sind Warteschlangen oder andere Dienste als Ursache zu prüfen.

Für eine belastbare Ausgangsmessung werden Modell, Eingabe, Kontext und Auslastung festgehalten. Nutzen Sie denselben Prompt und denselben Modellzustand bei jedem Vergleich. Die Ollama-API für die Generierung stellt Antwortinformationen bereit, die sich für die Auswertung einer Anfrage verwenden lassen. Notieren Sie mindestens:

• Modellname und Quantisierung beziehungsweise Modellvariante.
• Prompt und tatsächlich verwendete Kontextvorgabe.
• Zeit bis zur ersten Ausgabe und Dauer der Generierung.
• Speicherbelegung, Swap-Nutzung und CPU-Auslastung während des Tests.
• Ob weitere Anfragen oder Dienste gleichzeitig liefen.

Die Messung ist nur vergleichbar, wenn sich bei einem Testlauf jeweils eine relevante Variable ändert. Ein anderer Prompt, eine andere Kontextlänge und ein parallel gestarteter Indexaufbau machen einen Vorher-nachher-Vergleich unbrauchbar. Eine universelle Grenze für akzeptable Antwortzeit oder CPU-Auslastung gibt es hier nicht: Sie hängt davon ab, ob das System interaktiv antworten, Dokumente im Hintergrund verarbeiten oder mehrere Nutzer bedienen soll.

Mit einer reproduzierbaren Baseline starten

Vor jeder Änderung sollten die Symptome getrennt protokolliert werden. Dafür genügt eine kurze Messreihe im normalen Betriebszustand und eine Wiederholung unter möglichst gleichen Bedingungen. Für die Bewertung der Wartezeit sollte zwischen Modellladezeit, Zeit bis zur ersten Ausgabe und anschließender Generierung unterschieden werden; diese Phasen können unterschiedliche Ursachen haben.

1. Legen Sie eine repräsentative Anfrage fest, die dem späteren Einsatz entspricht. Verwenden Sie keine wechselnden Prompts, wenn Sie einzelne Einstellungen vergleichen.
2. Halten Sie Modellvariante und Kontextvorgabe fest. Die Modellgröße allein beschreibt nicht den gesamten Speicherbedarf.
3. Führen Sie eine Anfrage ohne zusätzliche Tests oder Hintergrundjobs aus und erfassen Sie die Beobachtungen.
4. Wiederholen Sie denselben Test unter der üblichen Anwendungsbelastung. So wird sichtbar, ob Dienste oder parallele Anfragen die Inferenz beeinflussen.
5. Ändern Sie anschließend nur einen Faktor, etwa Modellvariante, Kontext oder Containerbegrenzung, und messen Sie erneut.

Für die laufende Kontrolle helfen Betriebssystem- und Containeranzeigen. free kann den verfügbaren Speicher sichtbar machen; vmstat und docker stats können während eines Testlaufs Hinweise zu Speicher- und Ressourcennutzung liefern. Die exakten Befehlsoptionen hängen vom System und der installierten Version ab. Relevant ist nicht ein einzelner Momentwert, sondern ob Speicherknappheit, Auslagerung oder Ressourcenauslastung zeitgleich mit der Verzögerung auftreten.

Modellgröße und Quantisierung vergleichen

Die Dateigröße eines Modells ist ein erster Anhaltspunkt, aber keine zuverlässige Aussage darüber, ob es im laufenden Betrieb vollständig und ohne Speicherknappheit genutzt werden kann. Zusätzlich zur Modellrepräsentation beanspruchen der Laufzeitprozess und der KV-Cache Arbeitsspeicher. Der Speicherbedarf für Modellgewichte lässt sich grob über die Parameterzahl und die Quantisierungsbitbreite abschätzen:

Speicher für Gewichte ≈ Parameterzahl × Quantisierungsbitbreite ÷ 8

Diese Rechnung ist ausdrücklich nur eine Schätzung für die Gewichte, keine vollständige RAM-Prognose. Sie berücksichtigt weder Laufzeit-Overhead noch KV-Cache, Betriebssystem, parallel betriebene Anwendungen oder sonstige Speicherbelegung. Die Dokumentation zu Modellformaten und Quantisierung in llama.cpp bietet den technischen Kontext, ersetzt aber keine Messung mit der konkreten Modellvariante und Anwendung.

Wenn die Antwortzeit nicht genügt, sollte zuerst ein kleineres, für die Aufgabe geeignetes Modell unter denselben Bedingungen getestet werden. Danach lässt sich eine passende Quantisierung prüfen. Eine Variante mit weniger Speicherbedarf kann den Einsatz erleichtern, garantiert aber nicht, dass jede Aufgabe dieselbe Ergebnisqualität oder Geschwindigkeit erreicht. Bei wissensbasierten Anwendungen sind daher neben der Antwortzeit auch Antwortqualität und Zuverlässigkeit anhand repräsentativer Fragen zu prüfen.

Die Ollama-Ankündigung zu Version 0.30 und GGUF beschreibt Änderungen rund um llama.cpp und die GGUF-Kompatibilität. Sie ist kein Leistungsversprechen für eine bestimmte CPU, ein bestimmtes Modell oder eine konkrete Konfiguration. Für versionsabhängige Funktionen und Änderungen sollten die Ollama-Veröffentlichungen geprüft werden, statt aus einer Ankündigung auf aktuelle Leistungswerte zu schließen.

Kontext und Speicherbedarf voneinander unterscheiden

Ein umfangreicher Kontext kann sowohl den Speicherbedarf als auch die Rechenarbeit erhöhen. Das bedeutet jedoch nicht, dass jede langsame Anfrage durch eine kürzere Kontextvorgabe schneller wird. Zunächst ist zu klären, ob die Anwendung tatsächlich lange Eingaben übergibt, ob die Verzögerung während der Generierung wächst und ob parallel andere speicherintensive Dienste laufen.

Eine praktische Gegenprobe besteht aus zwei Eingaben für dieselbe Aufgabe: einer typischen kurzen Anfrage und einer realistischen langen Anfrage. Modell und übrige Bedingungen bleiben gleich. Wenn nur die lange Eingabe deutlich schlechter abschneidet, sollte der Kontextbedarf der Anwendung reduziert oder gezielter begrenzt werden. Ist auch die kurze Anfrage langsam und der Speicher nicht knapp, liegt die Ursache möglicherweise nicht im Kontext.

Bei fehlendem Arbeitsspeicher kann das Betriebssystem Daten auslagern. Swap-Aktivität, eine anhaltend hohe Speicherauslastung und ungewöhnlich lange Modellladezeiten sind dann getrennt von einer reinen CPU-Rechenbegrenzung zu bewerten. Ollamas FAQ zu Speicherverhalten und Modellbetrieb beschreibt relevante Aspekte des Betriebs; der konkrete Befund muss dennoch auf dem betroffenen Host erfasst werden. Ein voller Speicher allein erklärt nicht immer, ob Modell, Kontext oder ein anderer Dienst den Engpass verursacht.

Für die Speicherplanung muss der gesamte Stack berücksichtigt werden: Ollama, die Modellgewichte, KV-Cache, Anwendung, Vektordatenbank, Betriebssystem und gegebenenfalls Embedding- oder Ranking-Prozesse. Bei einem gemeinsamen Host kann außerdem ein Indexaufbau kurzfristig Speicher und CPU beanspruchen. In einer Wissensdatenbank ist daher zu testen, ob die Verzögerung auch außerhalb von Importen, Re-Embedding und Indexaktualisierungen auftritt.

Docker-Zuteilung und Thread-Verhalten prüfen

Ein Container kann weniger CPU oder Arbeitsspeicher erhalten, als der Host insgesamt besitzt. Eine hohe Zahl sichtbarer Host-Kerne ist deshalb kein Beleg dafür, dass der Ollama-Prozess alle nutzen darf. Prüfen Sie CPU-Quota, eine feste CPU-Auswahl und Speicherlimits, bevor Sie Schlussfolgerungen aus der Hostanzeige ziehen. Die Docker-Dokumentation zu Container-Ressourcen erläutert, wie solche Begrenzungen wirken.

Bei Docker sollten Sie außerdem kontrollieren, welche Ressourcen der Container tatsächlich sieht und ob die Anwendung mit einer absichtlich eingeschränkten Zuteilung läuft. Die Ollama-Dokumentation zum Docker-Betrieb ist die maßgebliche Referenz für den beschriebenen Containerbetrieb. Optionen können sich mit Softwareversionen ändern; prüfen Sie daher vor einer Anpassung die aktuelle Dokumentation und die lokale Konfiguration.

Ein sinnvoller Prüfpfad:

• Vergleichen Sie Host-Kapazität, Containerlimits und die im Container verfügbare Ressource.
• Kontrollieren Sie, ob CPU-Quota oder CPU-Auswahl einzelne Kerne ausschließen.
• Prüfen Sie, ob Speicherlimits zu Auslagerung oder einem Neustart des Prozesses führen.
• Beobachten Sie während desselben Testprompts Container- und Host-Auslastung.
• Ändern Sie die Zuteilung einzeln und wiederholen Sie den Basistest.

Eine feste Zahl für optimale Threads oder einen allgemein passenden Containerwert lässt sich ohne Kenntnis von Modell, Laufzeitversion und Host nicht seriös angeben. Ebenso sollte ein Community-Tipp nicht als allgemeine Optimierung übernommen werden, solange er nicht mit der eigenen Kombination aus Modell, Ollama-Version und Containerkonfiguration reproduziert wurde.

Passende Maßnahme anhand der Symptome auswählen

Die folgende Gegenüberstellung ordnet typische Beobachtungen möglichen nächsten Schritten zu. Sie ist ein Diagnosewerkzeug und kein Leistungsversprechen: Ein Symptom kann mehrere Ursachen haben, weshalb die passende Zeile durch einen kontrollierten Test bestätigt werden muss.

Die wichtigsten Symptome sind nicht austauschbar. Eine einzelne langsame Anfrage unter hoher CPU-Auslastung ist etwas anderes als eine wachsende Warteschlange bei mehreren Nutzern. Auch ein langsamer Start nach längerer Inaktivität kann mit Modellladung zusammenhängen, während dauerhaft zähe Generierung eher eine andere Prüfung verlangt. Erfassen Sie daher mindestens einen unbelasteten und einen normalen Betriebsfall.

Bei mehreren selbst gehosteten Diensten sollte eine Lastenliste erstellt werden: Modellinferenz, Anwendungsschicht, Vektorsuche, Embedding, Ranking, Datenbank und Hintergrundimporte. Wenn ein einzelner Import die interaktive Antwort verschlechtert, kann eine zeitliche Trennung oder eine Aufteilung der Dienste sinnvoller sein als ein pauschaler Wechsel zu mehr CPU. Bei stabil hoher Grundlast kann eine getrennte Bereitstellung dagegen die Diagnose und Ressourcenplanung erleichtern.

Erweiterung erst nach Messung bewerten

Ein Wechsel auf einen dedizierten Server ist dann zu prüfen, wenn die Messungen einen dauerhaften Engpass zeigen und die gewünschte Aufgabe zur CPU-Inferenz passt. Dafür sollten über den normalen Betriebsablauf hinweg folgende Punkte festgehalten werden: verbleibender Arbeitsspeicher, Swap-Aktivität, CPU-Auslastung während repräsentativer Anfragen, Warteschlangen bei parallelen Nutzern sowie die für die Anwendung akzeptable Wartezeit. Ein einzelner Spitzenwert oder ein isolierter Testlauf genügt nicht als Dimensionierungsgrundlage.

Die Ressourcenentscheidung hängt auch davon ab, welche Dienste auf derselben Maschine bleiben. Wird dort nur Ollama betrieben, fällt die Konkurrenz anders aus als bei einer Kombination aus Anwendung, Datenbank, Vektorsuche und Embedding. Bleiben mehrere Aufgaben zusammen, ist der Spitzenbedarf dieser Dienste in die Planung einzubeziehen. Soll die Modellinferenz im Hintergrund laufen, kann eine längere Antwortzeit akzeptabel sein; für direkte Nutzerinteraktion ist derselbe Messwert möglicherweise ein Ausschlusskriterium.

Für die Kapazitätsprüfung bietet SFP Cloud einen Überblick zu Serverangeboten und eine Preisseite. Maßgeblich sind die dort aktuell ausgewiesenen Ressourcen, Preise und Laufzeitbedingungen; aus diesem Artikel werden keine nicht überprüften Serverkonfigurationen oder Leistungswerte abgeleitet. Vor einer Bestellung sollte geprüft werden, ob die ausgewiesene Speicher- und CPU-Ausstattung den gemessenen Engpass tatsächlich adressiert. Zusätzliche Informationen zum Ablauf finden sich im Hilfebereich.

Ein dedizierter AMD-Server kann gegenüber einer gemeinsam genutzten VPS-Umgebung die geteilte Host-Ressourcennutzung vermeiden und mehr Kontrolle über die eigene Dienstverteilung geben. Er löst jedoch weder eine unpassende Modellwahl noch eine durch langen Kontext verursachte Mehrarbeit automatisch. SFP Cloud bietet keine GPU; wer Training, hohe parallele Last oder niedrige Antwortlatenz als feste Vorgabe hat, sollte CPU-only-Inferenz nicht als gleichwertigen Ersatz dafür einplanen.

Häufige Fragen

Warum ist Ollama bei reiner CPU-Nutzung oft langsam?

Bei CPU-only-Inferenz muss der Prozessor die Modellberechnungen ohne GPU-Beschleunigung ausführen. Ein großes Modell, ein umfangreicher Kontext oder konkurrierende Dienste erhöhen die Arbeit pro Anfrage zusätzlich. Prüfen Sie deshalb zuerst Modell, tatsächlichen Kontext, verfügbaren Arbeitsspeicher und CPU-Zuteilung. Eine langsame Antwort allein belegt weder einen Defekt noch, dass mehr CPU-Kerne die passende Lösung wären.

Sollte ich zuerst ein kleineres Modell wählen oder mehr RAM einsetzen?

Vergleichen Sie zunächst ein kleineres, für dieselbe Aufgabe geeignetes Modell unter identischen Testbedingungen. Beobachten Sie zugleich, ob das vorhandene Modell vollständig in den Arbeitsspeicher passt und ob das System auslagert. Ist der Speicher der Engpass, kann mehr RAM relevant sein; ist die CPU dauerhaft ausgelastet, löst zusätzlicher RAM die Rechenbegrenzung nicht. Eine pauschale Aufrüstregel gibt es nicht.

Kann ein langer Kontext die CPU-Inferenz verlangsamen?

Ja. Ein größerer Kontext kann zusätzlichen Speicher für den KV-Cache beanspruchen und die Arbeit pro Anfrage erhöhen. Der Effekt hängt vom Modell, der tatsächlichen Eingabe und den Einstellungen ab. Messen Sie deshalb mit einer repräsentativen kurzen und langen Eingabe, während Modell und übrige Bedingungen gleich bleiben. Begrenzen Sie den Kontext auf den Bedarf der Anwendung, statt ihn vorsorglich maximal anzusetzen.

Wie lassen sich Threads und Ressourcenlimits in Docker prüfen?

Prüfen Sie die Containerkonfiguration auf CPU-Quota, erlaubte Kerne und Speicherlimits und vergleichen Sie diese Angaben mit den tatsächlich verfügbaren Ressourcen im Container. Beobachten Sie außerdem während derselben Anfrage die Host- und Container-Auslastung. Docker dokumentiert die Ressourcengrenzen seiner Container; Ollama dokumentiert den Betrieb mit Docker. Ändern Sie jeweils nur eine Begrenzung und wiederholen Sie anschließend denselben Test.

Halten Sie vor einer Entscheidung Modell, Kontext, Speicher, Swap und Wartezeit im selben Basistest fest. Erst wenn daraus ein anhaltender Engpass hervorgeht, lohnt sich der Vergleich mit einer dedizierten Serverressource; die konkreten Optionen sind auf der Preisseite von SFP Cloud zu prüfen. Bei GPU-Bedarf oder hohen Anforderungen an parallele, latenzarme Inferenz ist dagegen eine GPU-Lösung oder eine externe Modell-API der passendere nächste Schritt.

Häufige Fragen

1. Q
   Warum ist Ollama bei reiner CPU-Nutzung oft langsam?

   Bei CPU-only-Inferenz muss der Prozessor die Modellberechnungen ohne GPU-Beschleunigung ausführen. Ein großes Modell, ein umfangreicher Kontext oder konkurrierende Dienste erhöhen die Arbeit pro Anfrage zusätzlich. Prüfen Sie deshalb zuerst Modell, tatsächlichen Kontext, verfügbaren Arbeitsspeicher und CPU-Zuteilung. Eine langsame Antwort allein belegt weder einen Defekt noch, dass mehr CPU-Kerne die passende Lösung wären.

2. Q
   Sollte ich bei langsamer Ollama-Inferenz zuerst ein kleineres Modell wählen oder mehr RAM einbauen?

   Vergleichen Sie zunächst ein kleineres, für dieselbe Aufgabe geeignetes Modell unter identischen Testbedingungen. Beobachten Sie zugleich, ob das vorhandene Modell vollständig in den Arbeitsspeicher passt und ob das System auslagert. Ist der Speicher der Engpass, kann mehr RAM relevant sein; ist die CPU dauerhaft ausgelastet, löst zusätzlicher RAM die Rechenbegrenzung nicht. Eine pauschale Aufrüstregel gibt es nicht.

3. Q
   Kann ein langer Kontext Ollama auf der CPU ausbremsen?

   Ja. Ein größerer Kontext kann zusätzlichen Speicher für den KV-Cache beanspruchen und die Arbeit pro Anfrage erhöhen. Der Effekt hängt vom Modell, der tatsächlichen Eingabe und den Einstellungen ab. Messen Sie deshalb mit einer realistischen kurzen und langen Eingabe, während Modell und übrige Bedingungen gleich bleiben. Begrenzen Sie den Kontext auf den Bedarf der Anwendung, statt ihn vorsorglich maximal anzusetzen.

4. Q
   Wie prüfe ich bei Ollama in Docker Threads und Ressourcengrenzen?

   Prüfen Sie die Containerkonfiguration auf CPU-Quota, erlaubte Kerne und Speicherlimits und vergleichen Sie diese Angaben mit der tatsächlich sichtbaren Ressource im Container. Beobachten Sie außerdem während derselben Anfrage die Host- und Container-Auslastung. Docker dokumentiert die Ressourcengrenzen seiner Container; Ollama dokumentiert den Betrieb mit Docker. Ändern Sie jeweils nur eine Begrenzung und wiederholen Sie anschließend denselben Test.