Wenn Sie verwenden Ollama wird für LLM-Modelle produziertSie haben wahrscheinlich schon festgestellt, dass es nicht einfach nur ums Installieren und Wegwerfen geht. Zwischen der Wahl des richtigen Modells, der Quantisierung, der richtigen Menge an VRAM, der Anzahl gleichzeitiger Anfragen und mehrstufiger Agenten kann es sehr leicht zu langsamen Antworten, 503-Fehlern oder sogar Abstürzen aufgrund von Speichermangel kommen.
Die gute Nachricht ist, dass man weiß, wie es funktioniert Ollama la Parallelverarbeitung, Warteschlangen und SpeicherDurch die Anwendung einiger bewährter Architektur- und Systempraktiken lässt sich die Leistung sowohl von GPUs als auch von CPUs deutlich verbessern. Dies gelingt zudem, ohne die Datensicherheit oder die Flexibilität lokaler Modelle zu beeinträchtigen.
Ollama und llama.cpp im Produktiveinsatz: Teile und Rollen
Bevor man irgendetwas feinabstimmt, ist es wichtig zu verstehen, wer was macht. llama.cpp ist die Inferenzmaschine., extrem optimiert in C++, um das Maximum aus der Hardware (CPU, Apple Silicon, NVIDIA, AMD) herauszuholen. Ollama ist die hochrangige „Verpackung“. Das System orchestriert diese Engine und andere Backends (wie beispielsweise vLLM in einigen Fällen) und stellt eine einfache CLI sowie eine sofort einsatzbereite REST-API bereit.
In der Praxis passiert beim Starten eines Modells mit Ollama Folgendes: Die Anwendung (geschrieben in Go) Es startet einen Kindprozess, der llama.cpp ausführt. (oder eine andere kompatible Laufzeitumgebung) verwaltet das Auslagern von Gewichten, die GPU-/CPU-Konfiguration, die Kontextgröße und die Lebensdauer des Modells im Speicher. Dies vereinfacht den Produktionsbetrieb erheblich im Vergleich zur direkten Verwendung von llama.cpp, wo Sie es kompilieren, Routen verwalten und Parameter wie … festlegen müssten. –n-GPU-SchichtenQuantisierung usw.
Wenn wir in Analogien denken, llama.cpp ist das Zentrum für Tensor-Chirurgie.Minimalistisch, feinabgestimmt, um das Maximum aus jedem CPU/GPU-Zyklus herauszuholen. Ollama ist das „IKEA“ der lokalen KI: Es bietet Ihnen ein vorkonfiguriertes System mit Modellverwaltung, Standard-API, Anfragewarteschlange und Hardware-Auto-TuningIdeal für Produktionsumgebungen, in denen man nicht mit jedem Kompilierungsflag kämpfen möchte.
Hardwareanforderungen und Modellauswahl für die Produktion
Ein wichtiger Aspekt für einen reibungslosen Ablauf ist, die Modellgröße im Verhältnis zur Hardware nicht zu überdimensionieren. Die Kombination Modellparameter + Quantisierungstyp + Kontextlänge Ermittelt RAM-, VRAM- und Inferenzzeiten.
Als Richtlinie gelten für die Produktion mit Ollama auf einer Einzelmaschine üblicherweise folgende Bereiche:
- 8 GB RAMKleine Modelle (1B, 3B, 7B quantisiert). Geeignet für Prototypen und kleinere Dienste, jedoch kann die Leistung unter hoher Last beeinträchtigt sein.
- 16 GB RAMEin sinnvoller Punkt für quantisierte 7B- und 13B-Modelle vom Typ Q4_K_M. Ein realer Dienst kann bereitgestellt werden, wenn die Parallelität gut kontrolliert wird.
- 32 GB oder mehrEmpfehlenswert, wenn Sie mit den Modellen 30B, 40B oder 70B experimentieren möchten oder wenn Sie planen, mehrere Modelle parallel zu betreiben.
Bei GPUs ist das Muster ähnlich: Je mehr VRAM Sie haben, desto mehr Ebenen können Sie auf die Grafikkarte auslagern. Und Sie erzielen einen höheren Durchsatz. Mit einer 16-GB-GPU können Sie problemlos gut quantisierte 7B- bis 13B-Modelle bedienen, während Sie für 70B bereits über sehr leistungsstarke Hardware oder mehrere GPUs sprechen.
In Bezug auf die Lagerung ist Folgendes zu beachten: „Kleine“ quantisierte Modelle können 2 GB Speicherplatz belegen.Mittelgroße SSDs reichen von 5 GB oder mehr bis hin zu sehr großen Modellen mit mehreren zehn oder sogar hundert Gigabyte. Eine NVMe-SSD macht sich beim Laden oder Wechseln von Datenträgern bemerkbar.
Letztendlich spielt die CPU immer noch eine Rolle, insbesondere wenn Sie Inferenz nur mit dem Prozessor oder in Kombination mit der GPU durchführen. 4 Kerne sind das minimal akzeptable Maß.Für einen stabilen Dienst mit mehreren gleichzeitigen Anfragen sind 8 Kerne oder mehr ideal.
Quantisierung und Modellformate: Wie man die Leistung steigert, ohne die Qualität zu beeinträchtigen
Damit ein LLM in der Praxis eingesetzt werden kann, benötigt man fast immer irgendeine Form von QuantisierungEs handelt sich um den Prozess der Umwandlung von Gleitkomma-Gewichten (FP16, FP32) in ganzzahlige Darstellungen mit weniger Bits (4, 8 usw.), wodurch die Größe des Modells und der von ihm verbrauchte Speicherplatz reduziert werden, allerdings auf Kosten eines geringen Genauigkeitsverlusts.
Eine in der Gemeinschaft oft wiederholte Faustregel lautet: Q4_K_M ist der angemessene Standard für lokaleDadurch wird die Größe auf etwa die Hälfte der von FP16 reduziert, der Qualitätsverlust liegt bei etwa 1–2 % (z. B. bei der Perplexität), und die Inferenzgeschwindigkeit steigt deutlich. Für eine noch stärkere Komprimierung kann man auf Q3 oder Q2 zurückgreifen, allerdings auf Kosten von mehr Halluzinationen und schlechteren Schlussfolgerungen.
Um Modelle mit Ollama zu verwenden, ist das Standardformat folgendes: GGUFwelches Gewichte, Metadaten und einen Tokenizer so verpackt, dass sie für Laufzeitumgebungen vom Typ llama.cpp optimiert sind. Viele Modelle in der Ollama-Bibliothek liegen bereits im GGUF-Format vor und sind quantisiert, daher ein Ollama ziehenWenn Sie externe Modelle einbinden (zum Beispiel von Hugging Face), können Sie Folgendes tun:
- Konvertieren Sie Formate wie Safetensors mithilfe der Tools von GGUF. lama.cpp (Skripte wie convert_hf_to_gguf.py).
- Quantisiere sie mit Binär quantisieren aus llama.cpp Auswahl des Schemas (Q4_K_M, Q5_K_S, etc.).
- Erstellen Sie eine Modelldatei in Ollama, das auf die .gguf-Datei verweist und Vorlage, Standardparameter und System definiert.
Dieser Fluss von Herunterladen → Konvertieren → Quantisieren → Registrieren in Ollama Es ermöglicht die Integration von Nischenmodellen in die Produktion, wie etwa juristische LLMs (z. B. Jurema-7B) oder domänenspezifische Modelle, wobei die gleiche Bereitstellungspipeline beibehalten wird.
Interne Modellparameter: num_ctx, Temperatur und Ausgangssteuerung
Sobald das Modell ausgewählt ist, gilt es, sein Verhalten zu steuern. Im Produktivbetrieb reicht es nicht aus, dass es „gut reagiert“; es muss … vorhersehbar, begrenzt und effizientDie wichtigsten von Ollama bereitgestellten Parameter (geerbt von llama.cpp) sind:
Einerseits ist num_ctxDas Kontextfenster definiert, wie viele Tokens das Modell gleichzeitig berücksichtigen kann: Systemmeldungen, Chatverlauf und die aktuelle Eingabeaufforderung. Größere Fenster ermöglichen die Verarbeitung von mehr Tokens. lange Gespräche und die Analyse umfangreicher DokumenteAllerdings erhöhen sie den RAM-/VRAM-Verbrauch und die Berechnungszeit erheblich. Wenn Sie einen höheren Wert festlegen, als für das Modell trainiert wurde, kann es außerdem zu ungewöhnlichem Verhalten oder Leistungseinbußen kommen.
Es ist außerdem entscheidend, die Stromerzeugung zu kontrollieren. num_predict (maximale Anzahl von Exit-Tokens), Listen von halt und Temperatur. Ein niedriger Temperaturwert (0,2–0,5) führt zu stabileren und weniger kreativen Reaktionen und ist ideal für Ampelkennzeichnung, Codierung oder VerifizierungenHohe Werte sind kreativen Verwendungszwecken vorbehalten, die selten ernsthafte Produktionsszenarien darstellen.
Darüber hinaus sind Optionen wie top_p y top_k Sie tragen dazu bei, Zufälligkeit zu begrenzen. Durch die Reduzierung von top_p auf moderate Werte (z. B. 0,8–0,9) wird der Raum möglicher Token eingeschränkt, was hilfreich ist, um Halluzinationen zu reduzieren und reproduzierbarere Ausgaben zu erzielen.
Alle diese Parameter können dauerhaft eingestellt werden in der Modelldatei durch Anweisungen PARAMETER, speziell mit dem CLI (Befehl überschreiben /set im interaktiven Modus) oder dynamisch über die REST-API im Feld übergeben options aus JSON.
Parallelverarbeitung, Warteschlangen und Batchverarbeitung bei Ollama: Die Maschine auslasten, ohne sie zu überlasten
Der eigentliche Sprung vom „lokalen Spielzeug“ zu Service in der Produktion Es tritt ein, wenn Sie mehrere Anfragen gleichzeitig erhalten. Ollama verwendet dafür ein eigenes System. Menschenmassen und Warteschlangen Dies zu verwalten, ohne einen zusätzlichen Server einrichten zu müssen.
Das zentrale Element ist die Umgebungsvariable. OLLAMA_NUM_PARALLELDies definiert, wie viele Anfragen ein geladenes Modell parallel verarbeiten kann. Der Standardwert ist üblicherweise 4 (oder 1 bei begrenztem Speicher). Höhere Werte erhöhen den Durchsatz, sofern ausreichend CPU-/GPU- und VRAM-Leistung vorhanden ist, erhöhen aber auch die Speicherauslastung und können die Latenz einzelner Anfragen verschlechtern.
Wenn mehrere Anfragen für dasselbe Modell eingehen, versucht Ollama Folgendes zu erreichen: DosierungEs gruppiert Anfragen und verarbeitet sie gemeinsam, wodurch die GPU-Array-Operationen besser genutzt werden. Für den Benutzer ist sichtbar, dass die Antworten gleichzeitig übertragen werden. Wenn mehr Anfragen eintreffen, als OLLAMA_NUM_PARALLEL zulässt, werden sie in einen bestimmten Bereich verschoben. FIFO-Warteschlange reguliert durch MAX_QUEUE OVEN, was standardmäßig 512 ist.
Wenn die Warteschlange voll ist, gibt Ollama den Fehlercode 503 („Serverüberlastung“) zurück. Und wenn der Speicher voll ist, tritt eine weitere Beschränkung in Kraft. OFEN_MAX_BELASTET_MODELLEDies gibt an, wie viele Modelle gleichzeitig geladen werden können. Wenn ein neues Modell geladen werden muss und nicht genügend Speicherplatz vorhanden ist, werden inaktive Modelle entladen und die Anfrage wartet, bis das neue Modell bereit ist.
In realen Anwendungen ist es üblich, mit Folgendem zu beginnen: OLLAMA_NUM_PARALLEL=1 oder 2 Um die Stabilität zu gewährleisten, sollten Sie die CPU-Auslastung, den VRAM und die p95-Latenz überwachen und die Einstellungen schrittweise erhöhen, solange keine Speichermangelfehler oder Warteschlangenspitzen auftreten.
Speichermanagementstrategien in Ollama
Der Arbeitsspeicher (RAM und VRAM) ist die entscheidende Ressource in jedem lokalen LLM-Dienst. Ollama kombiniert mehrere Strategien für Systemabstürze vermeiden wenn mehr Anfragen eingehen, als in den Arbeitsspeicher passen, oder wenn Sie Modelle verwenden möchten, die zu groß für Ihren Rechner sind.
Zum einen verwendet es ein FIFO-Warteschlange Die Variable OLLAMA_MAX_QUEUE steuert, dass nicht alle Anfragen gleichzeitig abgelehnt werden, wenn kein Arbeitsspeicher verfügbar ist. Ist die Warteschlange voll, wird explizit der Fehlercode 503 zurückgegeben, anstatt den Prozess einfach zu beenden.
Andererseits unterhält es eine begrenzte Anzahl von Modelle in den Speicher geladen Die Anzahl der geladenen Modelle wird durch OLLAMA_MAX_LOADED_MODELS (standardmäßig 3 pro GPU oder 3 pro CPU) festgelegt. Modelle, die über einen bestimmten Zeitraum inaktiv waren, können automatisch entladen werden, wodurch VRAM und RAM für nachfolgende Anfragen freigegeben werden.
Dieser Parameter spielt ebenfalls eine Rolle. OLLAMA_KEEP_ALIVEDieser Wert legt fest, wie lange ein Modell nach der letzten Anfrage im Speicher verbleibt. Werte wie 5 Minuten verhindern, dass das Modell bei jeder Anfrage neu geladen wird, halten es aber auch nicht unbegrenzt im RAM. Bei 0 wird das Modell nach Abschluss sofort heruntergeladen, was Speicherplatz spart, aber die Startzeit verlängert; bei -1 bleibt es unbegrenzt lange im Speicher, solange der Server aktiv ist.
Bei extrem hohem Speicherbedarf kann das Betriebssystem auf folgende Mechanismen zurückgreifen: AuslagerungsdateiDies beeinträchtigt die Leistung erheblich und kann sogar zu Speichermangel und Instanzabstürzen führen. Daher ist es unerlässlich, folgende Parameter anzupassen: Modellgröße, Quantisierung, Kontextlänge, Anzahl paralleler Anfragen und Anzahl gleichzeitig geladener Modelle.
CPU vs. GPU in Produktionsumgebungen mit Ollama
Nicht jeder hat im Produktiveinsatz Zugriff auf leistungsstarke GPUs, insbesondere nicht bei deren Einsatz in kostengünstigen Servern oder Laptops. Daher das wachsende Interesse an Inferenzoptimierung ausschließlich mit CPU, indem man leichtgewichtige und gut quantisierte Modelle auswählt, die angemessene Latenzzeiten ermöglichen.
Für die reine CPU-Nutzung empfiehlt es sich, Modelle von 2B, 3B oder 7B Verwenden Sie für quantisierte Kontexte (Q4_K_M, Q5 usw.) moderate Kontextgrößen und begrenzen Sie die Anzahl paralleler Anfragen. OLLAMA_NUM_THREADS Die Anzahl der physischen Kerne (oder etwas weniger) trägt dazu bei, Leistung und Ressourcennutzung in Einklang zu bringen und eine Systemüberlastung zu verhindern.
Wenn Sie eine GPU besitzen, ist es unerlässlich, dies zu überprüfen. ollama psdass das Modell tatsächlich die Grafikkarte nutzt (idealerweise „100 % GPU“ im Feld „Prozessor“). Konfigurationen, die zu viele CPU- und GPU-Ebenen mischen, neigen dazu, folgendes zu erzeugen: geringe ErträgeIn Umgebungen mit ausreichendem VRAM ist es wünschenswert, so viele Ebenen wie möglich auf die GPU auszulagern.
Um die Beschleunigung explizit zu aktivieren, müssen Sie in manchen Umgebungen Variablen wie beispielsweise exportieren. CUDA_OVEN=1 Oder konfigurieren Sie die NVIDIA/AMD-Treiber korrekt. Wenn in den Protokollen Fehler wie „CUDA-Fehler“ oder „ROCm-Fehler“ angezeigt werden, liegt wahrscheinlich ein Treiber- oder Hardware-Kompatibilitätsproblem vor.
Erweiterte Konfiguration: Umgebungsvariablen und stabile Bereitstellung
Über die Inferenzparameter hinaus kann Ollama mit einer guten Handvoll weiterer Parameter feinabgestimmt werden. Umgebungsvariablen Diese definieren das Netzwerk, die Routen, CORS, die Protokollierung und das Modellladeverhalten. Im Produktivbetrieb ist es üblich, mindestens Folgendes zu ändern:
Einerseits OLLAMA_HOST Legt fest, auf welcher Schnittstelle und welchem ​​Port die API lauscht. Standardmäßig ist dies 127.0.0.1:11434, d. h. sie ist nur lokal erreichbar. Um sie im internen Netzwerk zugänglich zu machen, können Sie dies auf 0.0.0.0:11434 oder eine spezifische IP-Adresse ändern. Diese muss jedoch immer durch eine Firewall oder einen Reverse-Proxy geschützt sein.
Eine weitere sehr nützliche Einstellung ist OFENMODELLEDadurch können Sie den Ordner, in dem die Modelle gespeichert sind, auf eine andere Festplatte oder ein anderes Laufwerk (z. B. eine große SSD) verschieben. Dies bietet Ihnen Flexibilität bei der Verwaltung von Speicherplatz und Backups, vorausgesetzt, der Benutzer, der den Dienst ausführt, verfügt über Lese- und Schreibberechtigungen für diesen Pfad.
Um Web-Frontends wie z. B. WebUI öffnen oder andere grafische Benutzeroberflächen müssen angepasst werden. OLLAMA_URSPRÜNGEDies steuert die zulässigen Ursprünge in CORS. Sie können bestimmte Domänen angeben (http://localhost:3000 usw.) oder "*" verwenden, um alle Domänen zuzulassen. Dies ist jedoch nur sinnvoll, wenn der Dienst nicht außerhalb eines streng kontrollierten Netzwerks zugänglich ist.
Während der Bereitstellung und Fehlerbehebung aktivieren OLLAMA_DEBUG=1 Um detaillierte Protokolle anzuzeigen: GPU-Erkennung, Laden von Modell-Blobs, Antwortzeiten, spezifische Fehler usw. Unter Linux können diese Protokolle einfach mit folgendem Befehl aufgerufen werden: journalctl -u ollama, die Möglichkeit, sie in Dateien umzuleiten oder nach Datum zu filtern.
Die genaue Vorgehensweise zum Festlegen dieser Variablen hängt von der Umgebung ab: Unter Linux erfolgt dies typischerweise durch eine systemd-Überschreibung für den Dienst. ollama.serviceauf macOS über launchctlUnter Windows geschieht dies über Systemumgebungsvariablen, in Docker über die Option -e en Andocklauf.
Modellverwaltung, Modelldateien und Workflows mit mehreren LLMs
Nach dem Systemteil ist es nun an der Zeit, darüber nachzudenken, wie Organisieren Sie die ModelleOllama bietet einen eigenen Katalog an, der mit Befehlen wie beispielsweise Ollama ziehen, Ollama-Liste, ollama rm y ollama pushMit dieser letzten Funktion können Sie benutzerdefinierte Vorlagen in Ihre Registry hochladen, was die Verteilung und Versionierung innerhalb von Teams oder Unternehmen erleichtert.
Um das Verhalten eines Modells anzupassen (Tonfall, Ansagevorlage, Standardparameter), wird das System verwendet, um ModelldateienDiese Dateien definieren beispielsweise die Anweisung FROM mit der Route nach .gguf, die Linien PARAMETER (Temperatur, num_ctx, num_predict, top_p usw.) und ein Vorlage wobei festgelegt wird, wie die Eingabeaufforderung strukturiert ist (Systemmeldungen, Benutzermeldungen, Assistentenmeldungen, Trennzeichen).
Mit ollama create Sie können eine Modelldatei kompilieren und ein neues logisches Modell im System registrieren, ohne den Speicherplatz physisch zu duplizieren. Dies ist sehr nützlich, um mehrere Varianten desselben Basismodells zu generieren (z. B. eine für den allgemeinen Gebrauch, eine weitere für Code optimiert, eine weitere für formalen Stil usw.).
In Architekturen mit Agenten oder mehrstufigen Abläufen (RAG + Leitplanke + Dokumentenauswertung + Abfrageerweiterung + Halluzinationsverifizierung) ist es üblich mehrere Modelle kombinierenEin universelles Modell, ein kleines und schnelles Modell für Klassifizierung/Leitplanken und eventuell ein spezialisiertes Modell für Gelände. Auch hier ist es entscheidend, OLLAMA_MAX_LOADED_MODELS und KEEP_ALIVE korrekt einzustellen, um ein ständiges Laden und Entladen von Modellen zu vermeiden.
Schließlich stellt die REST-API von Ollama Endpunkte für folgende Funktionen bereit: Chat, Generierung, Einbettungen und ModellmanagementDies ermöglicht die einfache Integration mit Agenten-Orchestrierungssystemen wie LangGraph sowie mit Backend-Anwendungen in Python, JavaScript, PHP usw., wobei Jitter-Wiederholungsversuche und Keep-Alive-Verbindungen auf Clientseite hinzugefügt werden, um gelegentliche Warteschlangenspitzen zu vermeiden.
Damit ist es möglich, von einem einfachen lokalen KI-"Spielzeug" zu einem robuste Plattform von LLMs in der ProduktionMit präziser Kontrolle über Leistung, Speicher und Verhalten, der Möglichkeit, Daten in der eigenen Infrastruktur zu speichern und nicht vollständig von externen Cloud-Anbietern abhängig zu sein, ist dies besonders wertvoll in Szenarien mit Datenschutzanforderungen, knappen Kosten oder dem Bedarf an tiefgreifender Anpassung.