> ## Documentation Index > Fetch the complete documentation index at: https://docs.tokios.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel. > Use 'connector' for the local tokios-connector process. > Use 'deployment' for the public model name in the API model field. > Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend. > API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-. # llama.cpp für Geschwindigkeit und Speicher optimieren > Optimieren Sie llama.cpp für maximale Leistung – Flash Attention, mmap vs. mlock, Thread-Tuning, Strategie für das Auslagern auf die GPU, Batchgröße, KV-Cache-Präzision und Platzierung der MoE-Experten. 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. > [!NOTE] > > Zuletzt überprüft: 2026-10-14 — llama.cpp Build b11609. > [!NOTE] > > 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -fa ``` 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. > [!TIP] > > **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. | Flag | Was es tut | Am besten für | | - | - | - | | `--mmap` (Standard) | Bildet die Datei ab; das OS seitet Daten nach Bedarf ein und aus | Einmal-Ausführungen, speicherbeschränkte Maschinen, schnelle Experimente | | `--mlock` | Fixiert jedes Byte im physischen RAM; nichts wird ausgelagert | Wiederholte Inferenz, dedizierte Inferenz-Server, Modelle, die Sie den ganzen Tag ausführen | ### 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -fa --mlock ``` > [!WARNING] > > `--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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -t 8 ``` | Szenario | Thread-Empfehlung | | - | - | | Vollständiges GPU-Offload (alle Schichten auf GPU) | `-t 2` bis `-t 4` — die CPU verarbeitet Orchestrierung und Tokenisierung, nicht Mathematik | | Partielles GPU-Offload (einige Schichten auf CPU) | Setzen Sie `-t` auf die Anzahl der physischen Kerne Ihrer CPU — nicht Hyperthreads | | Nur CPU (keine GPU) | Setzen Sie `-t` auf die Anzahl der physischen Kerne | > [!TIP] > > 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -ngl 20 -fa ``` 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -ngl 999 -fa ``` 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: ``` VRAM per layer ≈ (parameter_count_per_layer × bytes_per_weight) + KV_cache_per_layer ``` Für ein 7B-Modell bei Q4\_K\_M (\~4.5 Bits pro Gewicht, \~40 Schichten): | Komponente | Pro Schicht | 40 Schichten gesamt | | - | - | - | | Gewichte | \~0.15 GB | \~6 GB | | KV-Cache (f16, 4K ctx) | \~0.05 GB | \~2 GB | | **Gesamt** | | **\~8 GB** | 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: | Flag | Was es steuert | | - | - | | `-b` (Batch-Größe) | Gesamte Token, die in einem Batch während der Prompt-Aufnahme verarbeitet werden | | `-ub` (UBatch-Größe) | Maximale Token pro Micro-Batch innerhalb eines einzelnen Batch | ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -b 512 -ub 512 -fa ``` ### 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 | Einstellung | Effekt | | - | - | | Größeres `-b` (512-2048) | Schnellerer Prefill für lange Prompts — mehr Token pro Forward-Pass verarbeitet | | Größeres `-b` | Mehr VRAM/RAM während der Prompt-Aufnahme verbraucht | | Kleineres `-b` (128-256) | Niedrigere Speichernutzung, langsamerer Prefill | | `-ub` gleich `-b` | Einfachste Konfiguration; ein Micro-Batch deckt den vollständigen Batch ab | | `-ub` kleiner als `-b` | Begrenzt den Speicher pro Micro-Batch; nützlich wenn `-b` groß ist, aber VRAM knapp | > [!TIP] > > 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -fa \ --cache-type-k q8_0 --cache-type-v q8_0 ``` | Präzision | Speicher pro Element | Qualität | Wann verwenden | | - | - | - | - | | `f16` (Standard) | 2 Bytes | Basislinie | Maximale Qualität; Sie haben reichlich Speicher | | `q8_0` | 1 Byte | Fast identisch zu f16 | Beste Balance — halbiert KV-Cache-Speicher mit vernachlässigbarem Qualitätsverlust | | `q4_0` | 0.5 Bytes | Leichte Verschlechterung | Knapper Speicher; langer Kontext oder viele gleichzeitige Sequenzen | 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. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Aggressive: quarter the KV cache memory llama-server -m model.gguf -fa \ --cache-type-k q4_0 --cache-type-v q4_0 ``` > [!WARNING] > > `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: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf -ngl 999 --n-cpu-moe 4 -fa ``` `--n-cpu-moe ` 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. | Szenario | Konfiguration | | - | - | | MoE passt vollständig in VRAM | `-ngl 999` — keine CPU-Experten erforderlich | | MoE passt fast, einige Experten überlaufen | `--n-cpu-moe 2` bis `--n-cpu-moe 8` | | MoE ist zu groß für jedes vernünftige GPU-Setup | Kombinieren Sie `--n-cpu-moe` mit partieller `-ngl` | > [!TIP] > > 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 ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf \ -fa \ --mlock \ -b 512 \ -ub 512 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -ngl 999 \ --port 8080 ``` 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. > [!NOTE] > > llama.cpp läuft gut auf Apple Silicon, aber wenn Sie ausschließlich auf Mac bereitstellen, ist [MLX](https://github.com/ml-explore/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 ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf \ -fa \ -ngl 999 \ -b 512 \ -ub 512 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -t 4 \ --port 8080 ``` 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 ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} llama-server -m model.gguf \ -t 8 \ -b 256 \ -ub 256 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --port 8080 ``` 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](/de/guides/llama-cpp-remote-access.md)** > > Legen Sie Ihren llama.cpp-Server für Teammitglieder und Agenten über Tokios frei — ohne Ports zu öffnen. > **[Spekulative Dekodierung](/de/guides/speculative-decoding.md)** > > Decode mit Draft-Modellen, N-Grammen und EAGLE beschleunigen — funktioniert mit llama.cpp-Backends. > **[Ihr Deployment testen](/de/guides/benchmark-your-deployment.md)** > > Latenz und Durchsatz nach der Abstimmung messen, um die Verbesserung zu bestätigen. > **[KV-Cache und Kontext](/de/concepts/kv-cache-and-context.md)** > > Tiefere Erklärung, wie KV-Cache über Modellarchitekturen und Laufzeiten funktioniert. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.