Zum Hauptinhalt springen
llama.cpp ist die portabelste lokale Inferenz-Laufzeit. Sie läuft auf CPU, NVIDIA GPU, AMD GPU und Apple Silicon — oft aus derselben Binärdatei. Diese Flexibilität kommt mit einer langen Liste von Flags, und die Standardwerte sind nicht immer optimal für Ihre Hardware. Dieser Leitfaden behandelt die wichtigsten Flags und die Abwägungen hinter jedem.
Zuletzt überprüft: 2026-10-14 — llama.cpp Build b11609.
Alle Flags in diesem Leitfaden gelten für llama-server und llama-cli ab llama.cpp Build b11609 (14. Oktober 2026). Flag-Namen können zwischen Builds wechseln — führen Sie llama-server --help aus, um zu bestätigen, was Ihre Binärdatei unterstützt.

​
Flash Attention

Aktivieren Sie Flash Attention mit -fa oder --flash-attn on. In den meisten Benchmarks ist dies die nächstbeste Sache zu einer kostenlosen Leistungsverbesserung, die llama.cpp bietet — Sie bekommen schnellere Inferenz bei gleicher oder niedrigerer Speichernutzung, bei vernachlässigbaren Qualitätseinbußen.
Flash Attention überarbeitet, wie das Modell die Attention-Scores zwischen Token berechnet. Statt die volle Attention-Matrix im Speicher zu materialisieren, berechnet es Attention in gekachelten Blöcken, die in schnellen SRAM passen. Das Ergebnis:
  • Niedrigere Speichernutzung für den KV-Cache — der größte Gewinn bei langen Kontextlängen.
  • Schnellere Inferenz — besonders auf GPU, wo die gekachelte Berechnung gut auf Tensor-Cores abbildet.
  • Gleiche Ausgabequalität — Flash Attention ist mathematisch äquivalent zu Standard-Attention, keine Approximation.
Starten Sie immer mit -fa. Es gibt keinen Grund, es wegzulassen, außer Sie stoßen auf ein Kompatibilitätsproblem mit einem bestimmten Modell oder einer bestimmten Plattform. Es ist das Flag mit der höchsten Auswirkung in diesem Leitfaden.

​
mmap vs mlock

llama.cpp lädt Modellgewichte mit einer von 2 Strategien in den Speicher. Der Standard ist --mmap, der die Modelldatei direkt in den virtuellen Adressraum des Prozesses abbildet. Die Alternative ist --mlock, der das gesamte Modell im physischen RAM fixiert.

​
Wann mmap gewinnt

--mmap ist der Standard, weil es für die meisten interaktiven Anwendungen gut funktioniert. Das OS lädt Modell-Seiten auf Bedarf, daher ist der Start schnell und die Modelldatei zählt nicht doppelt gegen Ihren RAM, bis die Seiten tatsächlich berührt werden. Wenn Sie Modelle testen oder kurze Sitzungen ausführen, ist der Standard in Ordnung.

​
Wann mlock gewinnt

--mlock verhindert, dass das OS Modell-Seiten auslagert. Das ist wichtig, wenn:
  • Sie dasselbe Modell den ganzen Tag ausführen und konsistente Latenz wollen — kein Kaltstart-Penalty durch Page Faults.
  • Ihr System unter Speicherdruck von anderen Prozessen steht und Modellgewichte auslagern könnte.
  • Sie auf einer Maschine mit langsamem Swap (oder keinem Swap) sind und ein Page Fault die Inferenz für Sekunden blockieren würde.
--mlock erfordert, dass das vollständige Modell in den verfügbaren physischen RAM passt. Wenn es nicht passt, startet der Prozess nicht. Prüfen Sie Ihren verfügbaren Speicher mit free -h unter Linux oder dem Activity Monitor unter macOS, bevor Sie es aktivieren.

​
Thread-Abstimmung

Das -t-Flag setzt die Anzahl der CPU-Threads, die für Inferenz verwendet werden. Der richtige Wert hängt davon ab, wie viel Arbeit die CPU tatsächlich tut.
Mehr Threads sind nicht immer schneller. Jenseits der Anzahl physischer Kerne konkurrieren Threads um Cache und Speicherbandbreite und können Inferenz verlangsamen. Im Zweifel, starten Sie mit der physischen Kernanzahl und benchmarken von dort.
Auf Apple Silicon ist Thread-Abstimmung weniger wichtig, da GPU und CPU sich Unified Memory teilen und das Metal-Backend die Planung übernimmt. Der Standard funktioniert normalerweise gut.

​
GPU-Offload-Strategie

Das -ngl-Flag steuert, wie viele Modellschichten Sie auf die GPU auslagern. Mehr Schichten auf der GPU bedeuten schnellere Inferenz, aber jede Schicht verbraucht VRAM.

​
Partielles Offload

Setzen Sie -ngl auf die Anzahl der Schichten, die in den GPU-Speicher passen. Die restlichen Schichten laufen auf der CPU.
Verwenden Sie partielles Offload, wenn das vollständige Modell nicht in den VRAM passt. Starten Sie mit einem hohen Wert und reduzieren Sie, bis der Server startet, ohne dass der Speicher ausgeht.

​
Vollständiges Offload

Setzen Sie -ngl 999, um jede Schicht auszulagern. llama.cpp verwendet 999 als “alle verbleibenden Schichten” — es versucht nicht buchstäblich, 999 Schichten auszulagern.
Vollständiges Offload gibt die beste Inferenzgeschwindigkeit, weil jeder Forward-Pass auf der GPU läuft. Die Modellgewichte und der KV-Cache müssen beide in den VRAM passen.

​
Speicher-Budgetierung pro Schicht

Jede ausgelagerte Schicht verbraucht VRAM für sowohl Gewichte als auch KV-Cache. Eine grobe Schätzung:
Für ein 7B-Modell bei Q4_K_M (~4.5 Bits pro Gewicht, ~40 Schichten): Lassen Sie 1-2 GB VRAM-Spielraum für CUDA-Kontext und Overhead.

​
Batch-Größen-Abstimmung

Zwei Flags steuern, wie viele Token llama.cpp während der Prefill-Phase auf einmal verarbeitet:

​
Wie sie zusammenspielen

  • -b setzt die äußere Grenze. Wenn ein Prompt mehr Token als -b hat, teilt llama.cpp ihn in mehrere Batches auf.
  • -ub setzt die innere Chunk-Größe. llama.cpp verarbeitet den Batch in Micro-Batches von bis zu -ub Token.
  • -ub muss kleiner oder gleich -b sein.

​
Abwägungen

Für interaktiven Chat mit kurzen Prompts (unter 1K Token) ist der Standard -b 512 in Ordnung. Erhöhen Sie ihn nur, wenn Sie regelmäßig lange Dokumente aufnehmen und schnellere Time-to-First-Token wollen.

​
KV-Cache-Präzision

Der KV-Cache speichert Key- und Value-Tensoren für jedes Token in jeder aktiven Sequenz. Standardmäßig verwendet llama.cpp f16 (16-Bit-Gleitkomma) für sowohl Keys als auch Values. Sie können auf quantisierte Präzision wechseln, um die Speichernutzung bei kleinen Qualitätseinbußen zu reduzieren.
Sie können Keys und Values unabhängig setzen. Ein häufiges Muster ist q8_0 für beide, was den KV-Cache-Fußabdruck mit weniger als 1% Qualitätsunterschied bei den meisten Benchmarks halbiert.
q4_0 KV-Cache führt zu messbarem Qualitätsverlust bei Aufgaben, die auf präziser Attention über langen Kontext angewiesen sind — Needle-in-a-Haystack-Abruf, Multi-Dokument-Zusammenfassung und lange Konversationen. Testen Sie Ihren spezifischen Workload, bevor Sie sich für q4_0 festlegen.

​
MoE-Optimierung

Mixture-of-Experts-Modelle wie Qwen3.5-35B-A3B oder Mixtral speichern eine große Anzahl von Expert-Subnetzwerken in jeder Schicht, aktivieren aber nur wenige pro Token. Die Expert-Gewichte leben trotzdem im Speicher, auch wenn sie inaktiv sind, was MoE-Modelle unverhältnismäßig groß für ihre aktive Parameteranzahl macht. Auf Multi-GPU-Systemen können Sie Expert-Schichten auf die CPU legen, wenn der GPU-Speicher knapp ist:
--n-cpu-moe <num> hält die angegebene Anzahl von Expert-Sub-Schichten auf der CPU, während der Rest des Modells auf der GPU läuft. Dies tauscht eine kleine Latenzerhöhung gegen ein größeres Modell, das in den VRAM passt.
Starten Sie mit --n-cpu-moe 0 (alle Experten auf GPU) und erhöhen Sie nur, wenn Ihnen der VRAM ausgeht. Jeder Experte, der auf die CPU verschoben wird, fügt Latenz hinzu, weil die Daten während des Forward-Pass den PCIe-Bus überqueren müssen.

​
Beispielkonfigurationen

​
Apple Silicon — optimiert für M-Series Mac

Dies fixiert das Modell im Unified Memory, aktiviert Flash Attention und quantisiert den KV-Cache, um Ihr Speicherbudget zu dehnen. Apple Silicons Unified Memory bedeutet, dass die GPU auf den vollen RAM-Pool zugreifen kann, daher funktioniert vollständiges Offload (-ngl 999), solange Modell und KV-Cache passen.
llama.cpp läuft gut auf Apple Silicon, aber wenn Sie ausschließlich auf Mac bereitstellen, ist MLX für Apples Metal-Backend optimiert und könnte schnellere Inferenz für dasselbe Modell liefern. Verwenden Sie llama.cpp, wenn Sie plattformübergreifende Portabilität oder einen OpenAI-kompatiblen Server brauchen.

​
GPU-Offload — NVIDIA oder AMD dedizierte GPU

Vollständiges GPU-Offload mit Flash Attention und quantisiertem KV-Cache. Die 4 CPU-Threads verarbeiten Orchestrierung und Tokenisierung. Reduzieren Sie -ngl, wenn das Modell nicht passt — starten Sie bei der Gesamtschichtanzahl und reduzieren Sie in Schritten von 5, bis es lädt.

​
Nur CPU — keine GPU verfügbar

Kein GPU-Offload, also macht die CPU die ganze Arbeit. Die Thread-Anzahl entspricht den physischen Kernen. Kleinere Batch-Größe hält die Speichernutzung handhabbar. Verwenden Sie eine Q4_K_M- oder Q5_K_M-Quantisierung für die Modellgewichte, um den Fußabdruck klein zu halten.

​
Nächste Schritte

llama.cpp Fernzugriff

Legen Sie Ihren llama.cpp-Server für Teammitglieder und Agenten über Tokios frei — ohne Ports zu öffnen.

Spekulative Dekodierung

Decode mit Draft-Modellen, N-Grammen und EAGLE beschleunigen — funktioniert mit llama.cpp-Backends.

Ihr Deployment testen

Latenz und Durchsatz nach der Abstimmung messen, um die Verbesserung zu bestätigen.

KV-Cache und Kontext

Tiefere Erklärung, wie KV-Cache über Modellarchitekturen und Laufzeiten funktioniert.