Engine-Regler, die zählen

Die meisten Engine-Defaults sind für eine Demo vernünftig und für echten Gebrauch falsch. Drei oder vier Regler ändern Ergebnisse: Kontextlänge, GPU-Offload, KV-Cache-Typ und Flash Attention. Alles andere ist Tuning am Rand. Diese Seite nutzt llama.cpp-Flag-Namen, mit Ollama-Entsprechungen am Ende — die Konzepte übertragen sich auf jede Engine.

Kontextlänge: die stille Default-Falle

Engines liefern konservative Defaults aus: llama.cpp historisch 512, dann 4096, Ollama 2048–4096 je nach Version (zum Zeitpunkt dieses Textes landet OLLAMA_CONTEXT_LENGTH bei etwa 4k). Ihr Model unterstützt derweil nativ womöglich 32k–128k. Fügen Sie ein 20k-Token-Dokument in einen 4k-Kontext ein, passiert eines von zwei Dingen, beide schlecht: ein harter Fehler („Anfrage übersteigt verfügbaren Kontext“) oder stilles Kappen der ältesten Nachrichten. Keine der Fehlermeldungen erklärt sich einem Anfänger von selbst.

Durchgerechnet: Sie laden einen Vertrag aus ~12k Tokens plus eine Frage in ein Standard-4096-Fenster. Die Engine behält das aktuellste Material, verwirft den Anfang des Dokuments, und das Model beantwortet selbstsicher Fragen über die falsche Hälfte der Datei. Das sieht aus wie ein dummes Model; es ist ein gekappter Prompt.

Der Fix ist mechanisch: Übergeben Sie die Kontextgröße bei jedem Start explizit, bemessen auf Ihre echten Prompts plus erwartete Ausgabe, und verifizieren Sie dann, dass das Startlog n_ctx = 16384 zeigt (oder was immer Sie wählten). Koreanisch-Notiz: Koreanischer Text tokenisiert im selben Tokenizer oft weniger dicht als englischer — eine Seite Koreanisch kann mehr Tokens kosten als eine Seite Englisch (siehe Tokens) —, also kommt Kontextdruck früher an, als Sie erwarten.

# die Falle: Defaults unterscheiden sich je Engine und Version
llama-server -m model.gguf                  # startet mit n_ctx = 4096 oder so

# der Fix: explizit, und im Startlog verifiziert
llama-server -m model.gguf -c 16384         # Log druckt: n_ctx = 16384

GPU-Offload: n_gpu_layers

-ngl / --n-gpu-layers legt fest, wie viele Transformer-Layer auf der GPU leben; benutzen Sie eine große Zahl wie 99 (oder -1, wo unterstützt) für „alle“. Das Symptom partiallen Offloads ist markant: 3–10 tok/s auf einer Maschine mit ordentlicher GPU. Verifizieren Sie mit der Lade-Logzeile, z. B. offloaded 33/33 layers to GPU. Kann der VRAM Model plus KV-Cache nicht halten, sind die ehrlichen Optionen ein kleineres Quant, ein quantisierter KV-Cache oder weniger offgeladene Layer — aber wissen Sie, dass jeder auf der CPU gelassene Layer die ganze Schleife in CPU-Rhythmus zieht (siehe Geschwindigkeit). Ein Model, das fast passt, halb zu offloaden ist meist schlechter als ein Quant-Schritt runter.

Machen Sie die Plausibilitätsprüfung auch in der anderen Richtung: -ngl 0 erzwingt reine CPU, und läuft das mit derselben Geschwindigkeit wie Ihre „GPU“-Konfiguration, hat die GPU nichts getan.

Threads (nur CPU-Modus)

Setzen Sie im CPU-Modus -t auf die Zahl der physischen Kerne, nicht der SMT-Threads: Auf einem Chip mit 8 Kernen/16 Threads benutzen Sie 8. Mehr Threads als physische Kerne verursachen Konkurrenz und verlangsamen den Decode. Die Prompt-Verarbeitung hat einen eigenen Regler (--threads-batch); dieselbe Regel gilt.

Speicher: mmap und --mlock

llama.cpp memory-mappt die Modelldatei standardmäßig: Der Start ist schnell, und unberührte Layer kosten keinen RAM. Der Kompromiss ist, dass das OS unter Speicherdruck Seiten verdrängen kann, was Stunden in eine Sitzung hinein rätselhafte Pausen verursacht. --mlock pinnpt das Model, damit es nicht verdrängt werden kann — nützlich auf beschäftigten Maschinen, um den Preis, Gigabytes vor allem anderen wegzuschließen. Ollama handhabt das intern; nackte llama.cpp-Nutzer auf geteilten Maschinen sollten wissen, dass es das Flag gibt.

Flash Attention

-fa / --flash-attn reduziert den Speicherverkehr im Attention-Schritt und ist in aktuellen llama.cpp-Builds standardmäßig an (oder auto). Es zählt am meisten bei langem Kontext, und die V-Cache-Quantisierung verlangt es in aktuellen Builds. Benimmt sich ein frischer Build auf Ihrem GPU-Backend falsch, ist dies das erste Flag zum Umschalten — und bei jedem aktuellen Build ist das Erste zu prüfen, dass es sich nicht still abgeschaltet hat.

KV-Cache-Quantisierung

--cache-type-k q8_0 --cache-type-v q5_0 speichert den KV-Cache in 8-Bit/5-Bit statt 16-Bit-Floats und halbiert den KV-Speicher grob oder besser bei geringen Qualitätskosten — was längeren Kontext im selben VRAM bedeutet. Was der KV-Cache ist und die exakte Größenrechnung: KV-Cache.

Typischer Gewinn: q8_0-K plus q5_0-V halbiert die KV-Größe grob mit kaum sichtbarer Änderung bei Chat-Aufgaben — verifizieren Sie es auf Ihren eigenen Workloads, bevor Sie ihm vertrauen.

Prompt-Batchgröße

-b / --batch-size ist die Stückgröße für den Prefill (Prompt-Verarbeitung). Größere Batches bedeuten schnelleres Time-to-First-Token bei langen Prompts, um den Preis etwas höheren Peak-VRAMs. Wenn sich lange eingefügte Texte träge anfahren, erhöhen Sie es, bevor Sie das Model beschuldigen.

Kontext stretchen: Rope-Scaling und YaRN

--rope-scaling yarn --rope-factor 2.0 streckt ein nativ-32k-Modell Richtung 64k, indem Positionsfrequenzen neu skaliert werden. Es funktioniert, mit einem Qualitätsgefälle: Der Abtrag ist nahe dem nativen Fenster klein und wächst, je weiter Sie es überdehnen. Für alles Wichtige: Bevorzugen Sie ein Model, dessen nativer Kontext Ihren Bedarf bereits deckt, vor dem Strecken eines kleineren Fensters (siehe Modellauswahl).

Zum Zeitpunkt dieses Textes legt Ollama Rope-Scaling in seinem Modelfile nicht frei; Streckkontext-Experimente heißen, llama.cpp direkt zu starten.

Eine kommentierte Startzeile

llama-server -m qwen3-8b-q4_k_m.gguf --host 127.0.0.1 --port 8080 -c 16384 -ngl 99 -fa on -b 2048 --cache-type-k q8_0 --cache-type-v q5_0

Ollama-Entsprechungen

# pro Model, in einem Modelfile:
PARAMETER num_ctx 16384
PARAMETER num_gpu 99

# oder global, bevor der Dienst startet:
export OLLAMA_CONTEXT_LENGTH=16384
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0

Ollama loggt eine Warnung, wenn eine Anfrage num_ctx übersteigt — lesen Sie das Log einmal, nachdem Sie irgendetwas davon geändert haben. Änderungen über Env-Variablen verlangen einen Neustart des Dienstes.

Um zu sehen, was Ollama wirklich anwandte: ollama show model --modelfile druckt die aufgelösten Parameter, und OLLAMA_DEBUG=1 bringt den Dienst dazu, echte Kontext- und Offload-Zähler zu loggen.

Sampler sind keine Engine-Regler

Temperatur, top-p, Repeat-Penalty — diese formen, welches Token gewählt wird, nicht wie schnell oder wie viel in den Speicher passt. Sie leben in Sampling. Ist die Ausgabe seltsam, aber Geschwindigkeit und Speicher fein, wollen Sie jene Seite, nicht diese.

Die Regel

Setzen Sie den Kontext explizit. Verifizieren Sie mit einer Logzeile — n_ctx = ... und offloaded N/N layers — jedes Mal, wenn Sie eine Startkonfiguration ändern. Defaults sind so getunt, dass die erste Demo startet, nicht dass Ihre Arbeitslast bedient wird.

llm_load_tensors: offloaded 33/33 layers to GPU
n_ctx = 16384

Beide Zeilen drucken binnen Sekunden nach dem Start. Grepen Sie einmal nach ihnen, und Konfiguration hört auf, Folklore zu sein.

Verwandt: Geschwindigkeit · KV-Cache · Sampling · Einen Endpunkt serven