> ## 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-. # Ollama für Geschwindigkeit und Speicher optimieren > Optimieren Sie Ollama für maximale Geschwindigkeit – Kontextfenster, Auslagern auf die GPU, Flash Attention, KV-Cache-Quantisierung und parallele Anfragen. Reduzieren Sie die Latenz mit diesen Einstellungen um 2-5x. Ollama ist der schnellste Weg, ein lokales Modell zum Laufen zu bringen — `ollama run llama3` und Sie servieren bereits. Unter der Haube umgibt es llama.cpp (und MLX auf Apple Silicon) und stellt eine Reihe von Umgebungsvariablen und Modellparametern bereit, die steuern, wie es Ihre Hardware nutzt. Die Standardwerte funktionieren für gelegentliche Nutzung, lassen aber erhebliche Leistung ungenutzt. Dieser Leitfaden behandelt jede wichtige Stellschraube und wie Sie sie für Ihre Workload setzen. > [!NOTE] > > Zuletzt überprüft: 2026-10-14 — Ollama v0.33.2. > [!NOTE] > > **Apple Silicon verwendet MLX.** Beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework statt llama.cpp. MLX liefert erheblich schnellere Inferenz auf M-Series-Chips (siehe [Apple Silicon and MLX optimization](#apple-silicon-and-mlx-optimization)). Die meisten Umgebungsvariablen in diesem Leitfaden gelten für beide Backends; wo das Verhalten abweicht, wird es explizit hervorgehoben. ## Kontextfenster-Abstimmung Das Kontextfenster (`num_ctx`) steuert, wie viele Token das Modell in einer einzigen Anfrage verarbeiten kann — Ihr Prompt plus die generierte Antwort zusammen. Es ist der größte Treiber des Speicherverbrauchs nach den Modellgewichten selbst. ### Wie Sie das Ollama-Kontextfenster erhöhen Ollama verwendet standardmäßig ein 2048-Token-Kontextfenster. Die meisten modernen Modelle unterstützen 8K, 32K oder sogar 128K Token, aber Ollama nutzt standardmäßig nicht das Maximum des Modells — es verwendet 2048, um den Speicherverbrauch vorhersehbar zu halten. Setzen Sie es auf 3 Arten, von am spezifischsten bis am globalsten: **Pro Anfrage (API):** ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "llama3", "messages": [{"role": "user", "content": "Summarize this document..."}], "options": { "num_ctx": 32768 } }' ``` **In einem Modelfile (persistent pro Modell):** ```dockerfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3 PARAMETER num_ctx 32768 ``` Dann bauen und starten Sie das benutzerdefinierte Modell: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} ollama create llama3-32k -f Modelfile ollama run llama3-32k ``` **Global (alle Modelle, alle Anfragen):** ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Linux (systemd) sudo systemctl edit ollama.service # Add: Environment="OLLAMA_CONTEXT_LENGTH=32768" sudo systemctl daemon-reload && systemctl restart ollama ``` ```powershell Windows theme={"theme":{"light":"github-light","dark":"css-variables"}} [System.Environment]::SetEnvironmentVariable("OLLAMA_CONTEXT_LENGTH", "32768", "User") # Restart Ollama ``` ```bash macOS theme={"theme":{"light":"github-light","dark":"css-variables"}} launchctl setenv OLLAMA_CONTEXT_LENGTH 32768 # Restart Ollama ``` ### Kontextfenster-Speicherkosten Der KV-Cache wächst linear mit der Kontextlänge. Die Formel: ``` KV cache memory = 2 × num_layers × hidden_dim × num_ctx × precision_bytes ``` Für ein 7B-Modell (32 Schichten, 4096 Hidden-Dimension) bei f16-Präzision: | Context length | KV cache memory | | - | - | | 2,048 (default) | \~1 GB | | 8,192 | \~4 GB | | 32,768 | \~16 GB | | 128,000 | \~64 GB | > [!TIP] > > Setzen Sie `num_ctx` nur so hoch, wie Ihre Workload es tatsächlich braucht. Ein Coding-Agent, der 2K-Prompts sendet, profitiert nicht von einem 128K-Kontextfenster — er verschwendet nur 64 GB KV-Cache-Speicher, der andere Anfragen bedienen oder ein größeres Modell fassen könnte. ## Flash Attention Flash Attention ist das Nächste an einer kostenlosen Leistungsverbesserung, die Ollama bietet. Es überarbeitet, wie das Modell die Attention 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: * **30-50% 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. ### Flash Attention in Ollama aktivieren Setzen Sie die Umgebungsvariable: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Linux (systemd) sudo systemctl edit ollama.service # Add: Environment="OLLAMA_FLASH_ATTENTION=1" sudo systemctl daemon-reload && systemctl restart ollama ``` ```powershell Windows theme={"theme":{"light":"github-light","dark":"css-variables"}} [System.Environment]::SetEnvironmentVariable("OLLAMA_FLASH_ATTENTION", "1", "User") # Restart Ollama ``` ```bash macOS theme={"theme":{"light":"github-light","dark":"css-variables"}} launchctl setenv OLLAMA_FLASH_ATTENTION 1 # Restart Ollama ``` > [!TIP] > > **Aktivieren Sie immer Flash Attention.** 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 die Einstellung mit der höchsten Auswirkung in diesem Leitfaden. > [!NOTE] > > Auf Apple Silicon mit dem MLX-Backend ist Flash Attention standardmäßig aktiviert und die Variable `OLLAMA_FLASH_ATTENTION` hat keinen Effekt — MLX verwendet immer optimierte Attention-Kernel. ## GPU-Offload-Strategie Ollama lädt automatisch Modellschichten auf Ihre GPU. Wenn das vollständige Modell in den VRAM passt, laufen alle Schichten auf der GPU für maximale Geschwindigkeit. Wenn der VRAM knapp ist, teilt Ollama Schichten zwischen GPU und CPU auf — die GPU führt aus, was sie kann, und der Rest fällt auf den System-RAM zurück. ### Wie Ollama GPU-Schichten entscheidet Ollamas GPU-Scheduling funktioniert in dieser Reihenfolge: 1. **Vollständiges Offload** — wenn die Modellgewichte + KV-Cache in den VRAM passen, gehen alle Schichten auf die GPU. Das ist die schnellste Konfiguration. 2. **Partielles Offload** — wenn das Modell nicht vollständig passt, legt Ollama so viele Schichten auf die GPU, wie der VRAM erlaubt, und führt den Rest auf der CPU aus. Die Leistung verschlechtert sich, weil jeder Forward-Pass für CPU-residente Schichten den PCIe-Bus überqueren muss. 3. **Nur CPU** — wenn keine GPU verfügbar ist oder der VRAM sogar für wenige Schichten zu klein ist, läuft das gesamte Modell auf der CPU. ### GPU-Schichten steuern mit `num_gpu` Der Parameter `num_gpu` setzt, wie viele Schichten auf die GPU ausgelagert werden. Setzen Sie ihn in einem Modelfile oder pro Anfrage: ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3 PARAMETER num_gpu 35 ``` ```bash API theme={"theme":{"light":"github-light","dark":"css-variables"}} curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "llama3", "messages": [{"role": "user", "content": "Hello"}], "options": { "num_gpu": 35 } }' ``` | `num_gpu` value | Behavior | | - | - | | `-1` | All layers on GPU (same as setting it to the total layer count) | | `0` | No GPU offload — CPU only | | `1` to `N` | Exactly that many layers on GPU, rest on CPU | | Not set (default) | Ollama auto-detects based on available VRAM | > [!TIP] > > Lassen Sie `num_gpu` ungesetzt und lassen Sie Ollama in den meisten Fällen automatisch erkennen. Setzen Sie ihn nur manuell, wenn Sie eine bestimmte Aufteilung erzwingen müssen — zum Beispiel, um VRAM für ein größeres Kontextfenster zu reservieren oder einige Schichten auf der CPU zu halten für ein Modell, das knapp passt. ### VRAM-Budgetierung Jede ausgelagerte Schicht verbraucht VRAM für sowohl Gewichte als auch KV-Cache. Eine grobe Schätzung: ``` VRAM per layer ≈ (parameters_per_layer × bytes_per_weight) + (KV_cache_per_layer × num_ctx) ``` Für ein 7B-Modell bei Q4\_K\_M (\~4.5 Bits pro Gewicht, \~32 Schichten): | Component | Per layer | 32 layers total | | - | - | - | | Weights | \~0.19 GB | \~6 GB | | KV cache (f16, 8K ctx) | \~0.13 GB | \~4 GB | | **Total** | | **\~10 GB** | Lassen Sie 1-2 GB VRAM-Spielraum für CUDA-Kontext und Overhead. > [!WARNING] > > Wenn Sie `num_ctx` erhöhen, wächst der KV-Cache und kann Schichten aus dem VRAM drängen. Wenn Sie `num_ctx 32768` setzen und Ollama plötzlich die Hälfte der Schichten auf die CPU auslagert, hat der KV-Cache Ihr VRAM-Budget aufgebraucht. Reduzieren Sie entweder `num_ctx`, verwenden Sie eine kleinere Quantisierung oder aktivieren Sie Flash Attention, um den KV-Cache zu verkleinern. ## KV-Cache-Präzision Der KV-Cache speichert Key- und Value-Tensoren für jedes Token in jeder aktiven Sequenz. Standardmäßig verwendet Ollama `f16` (16-Bit-Gleitkommazahl). Sie können auf quantisierte Präzision wechseln, um den Speicherverbrauch auf Kosten einer kleinen Qualität zu reduzieren. Setzen Sie den Cache-Typ mit der Umgebungsvariable `OLLAMA_KV_CACHE_TYPE`: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Linux (systemd) sudo systemctl edit ollama.service # Add: Environment="OLLAMA_KV_CACHE_TYPE=q8_0" sudo systemctl daemon-reload && systemctl restart ollama ``` | Cache type | Memory per element | Quality | When to use | | - | - | - | - | | `f16` (default) | 2 bytes | Baseline | Maximum quality; you have plenty of memory | | `q8_0` | 1 byte | Near-identical to f16 | Best balance — halves KV cache memory with negligible quality loss | | `q4_0` | 0.5 bytes | Slight degradation | Tight memory; long context or many concurrent sequences | ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Halve KV cache memory OLLAMA_KV_CACHE_TYPE=q8_0 # Quarter KV cache memory OLLAMA_KV_CACHE_TYPE=q4_0 ``` > [!TIP] > > Kombinieren Sie `OLLAMA_KV_CACHE_TYPE=q8_0` mit `OLLAMA_FLASH_ATTENTION=1` für den größten Speichergewinn. Flash Attention reduziert den KV-Cache-Footprint um 30-50%, und q8\_0 halbiert ihn erneut — zusammen können sie den KV-Cache-Speicher um 60-75% im Vergleich zum Standard reduzieren. > [!WARNING] > > `q4_0`-KV-Cache führt einen messbaren Qualitätsverlust bei Aufgaben ein, die auf präzise Attention über langen Kontext angewiesen sind — Needle-in-a-Haystack-Abfrage, Multi-Dokument-Zusammenfassung und lange Gespräche. Testen Sie Ihre spezifische Workload, bevor Sie sich für `q4_0` entscheiden. ## Thread-Konfiguration Der Parameter `num_thread` steuert, wie viele CPU-Threads Ollama für Inferenz verwendet. Der richtige Wert hängt davon ab, wie viel Arbeit die CPU tatsächlich tut. Setzen Sie ihn in einem Modelfile oder pro Anfrage: ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3 PARAMETER num_thread 8 ``` ```bash API theme={"theme":{"light":"github-light","dark":"css-variables"}} curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "llama3", "messages": [{"role": "user", "content": "Hello"}], "options": { "num_thread": 8 } }' ``` Sie können ihn auch global mit `OLLAMA_NUM_THREADS` setzen: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Linux (systemd) sudo systemctl edit ollama.service # Add: Environment="OLLAMA_NUM_THREADS=8" sudo systemctl daemon-reload && systemctl restart ollama ``` | Scenario | Thread guidance | | - | - | | Full GPU offload (all layers on GPU) | `num_thread 2` to `num_thread 4` — the CPU handles orchestration and tokenization, not math | | Partial GPU offload (some layers on CPU) | Set `num_thread` to the number of physical cores on your CPU — not hyperthreads | | CPU-only (no GPU) | Set `num_thread` to the number of physical cores | > [!WARNING] > > 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 einheitlichen Speicher teilen und das MLX-Backend das Scheduling übernimmt. Der Standard funktioniert normalerweise gut. ## Batch-Größen-Abstimmung Der Parameter `num_batch` steuert, wie viele Token Ollama auf einmal während der Prefill-Phase verarbeitet (Prompt-Aufnahme). Der Standard ist 512. ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3 PARAMETER num_batch 1024 ``` | Setting | Effect | | - | - | | `num_batch 512` (default) | Balanced for interactive chat with short prompts | | `num_batch 1024` | Faster prefill for long prompts — roughly 50-100% faster time-to-first-token | | `num_batch 2048` | Maximum throughput for document ingestion — up to 150% faster prefill | | `num_batch 2048+` | Diminishing returns; higher memory usage without proportional speed gains | > [!TIP] > > Für interaktiven Chat mit kurzen Prompts (unter 1K Token) ist der Standard `num_batch 512` in Ordnung. Erhöhen Sie ihn nur, wenn Sie regelmäßig lange Dokumente aufnehmen und schnellere Time-to-First-Token wollen. > [!WARNING] > > Größere Batch-Größen verbrauchen mehr VRAM während der Prompt-Aufnahme. Wenn Sie `num_batch` erhöhen und Out-of-Memory-Fehler erhalten, reduzieren Sie ihn oder senken Sie `num_ctx`. ## Parallele Anfragen `OLLAMA_NUM_PARALLEL` steuert, wie viele Anfragen ein einzelnes Modell gleichzeitig verarbeitet. Der Standard ist 1 — Ollama bearbeitet eine Anfrage nach der anderen pro geladenem Modell. ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Allow 4 parallel requests per model OLLAMA_NUM_PARALLEL=4 ``` | Value | Behavior | | - | - | | `1` (default) | One request at a time — lowest latency per request | | `2` to `4` | Multiple requests share the GPU — higher throughput, slightly higher per-request latency | | `8+` | Maximum throughput for batch workloads — requires significant VRAM for KV cache | > [!NOTE] > > RAM und VRAM skalieren mit `OLLAMA_NUM_PARALLEL`. Jede parallele Anfrage benötigt ihren eigenen KV-Cache. Wenn Sie 4 parallele Anfragen mit `num_ctx 8192` bedienen, benötigen Sie 4× den KV-Cache-Speicher im Vergleich zu einer einzelnen Anfrage. ### Wann Sie parallele Anfragen erhöhen Erhöhen Sie `OLLAMA_NUM_PARALLEL`, wenn: * Sie mehrere Benutzer oder Agenten vom selben Modell bedienen. * Sie Batch-Workloads ausführen, bei denen der Gesamtdurchsatz wichtiger ist als die Latenz einzelner Anfragen. * Sie VRAM-Spielraum haben und die GPU bei einzelnen Anfragen unterausgelastet ist. Behalten Sie ihn bei 1, wenn: * Sie einen einzelnen Benutzer oder Agenten bedienen. * Sie niedrige Latenz dem Durchsatz vorziehen. * Der VRAM knapp ist. ## Modell-Speicherverwaltung ### Modelle geladen halten mit `OLLAMA_KEEP_ALIVE` Standardmäßig entlädt Ollama ein Modell nach 5 Minuten Inaktivität aus dem Speicher. Die nächste Anfrage muss das Modell von der Festplatte neu laden, was je nach Modellgröße und Festplattengeschwindigkeit Sekunden bis Minuten dauert. Setzen Sie `OLLAMA_KEEP_ALIVE`, um zu steuern, wie lange Modelle geladen bleiben: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Keep models loaded indefinitely OLLAMA_KEEP_ALIVE=-1 # Keep models loaded for 1 hour OLLAMA_KEEP_ALIVE=1h # Unload models immediately after each request OLLAMA_KEEP_ALIVE=0 ``` | Value | Behavior | | - | - | | `5m` (default) | Unload after 5 minutes of inactivity | | `-1` | Keep loaded indefinitely — no reload penalty | | `0` | Unload immediately after each request | | Duration (`1h`, `30m`, `24h`) | Keep loaded for that duration after the last request | > [!TIP] > > Für einen dedizierten Inferenz-Server, der dasselbe Modell den ganzen Tag ausführt, setzen Sie `OLLAMA_KEEP_ALIVE=-1`. Das Modell bleibt im Speicher und jede Anfrage bekommt sofortige Antwort ohne Kaltstart-Penalty. ### Geladene Modelle begrenzen mit `OLLAMA_MAX_LOADED_MODELS` Ollama kann mehrere Modelle gleichzeitig geladen halten. Der Standard ist 3 × (Anzahl der GPUs) oder 3 bei nur CPU. Wenn Sie viele Modelle bedienen und den Speicherverbrauch begrenzen wollen, senken Sie dies: ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Only keep 1 model loaded at a time OLLAMA_MAX_LOADED_MODELS=1 ``` Wenn das Limit erreicht ist und ein neues Modell angefordert wird, entlädt Ollama das am wenigsten kürzlich verwendete Modell, um Platz zu machen. ## Apple Silicon und MLX-Optimierung Beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework. MLX ist für Apples einheitliche Speicherarchitektur optimiert und liefert erheblich schnellere Inferenz als llama.cpp auf M-Series-Chips. ### Leistungsgewinne Benchmarks aus Ollamas MLX-Optimierungs-Update vom Juni 2026: | Model | Quantization | Tokens/sec (MLX) | | - | - | - | | Gemma 4 12B | NVFP4 | \~55 tok/s | | Gemma 4 12B | Q4\_K\_M | \~46 tok/s | | Llama 3.1 8B | Q4\_K\_M | \~70-80 tok/s | MLX unterstützt auch NVFP4-Quantisierung auf Apple Silicon, die Near-BF16-Qualität mit 4-Bit-Speicher-Footprint liefert — halb so viel Qualitätsverlust wie Q4-Quantisierung. ### Apple Silicon Optimierungstipps 1. **Verwenden Sie MLX-optimierte Modelle.** Wenn Sie ein Modell auf Apple Silicon ziehen, verwendet Ollama automatisch das MLX-Backend. Keine Konfiguration erforderlich. 2. **Flash Attention ist immer eingeschaltet.** MLX verwendet standardmäßig optimierte Attention-Kernel. Die Variable `OLLAMA_FLASH_ATTENTION` hat keinen Effekt. 3. **Einheitlicher Speicher bedeutet vollständiges GPU-Offload.** Apples Silicon-GPU kann auf den vollständigen RAM-Pool zugreifen, daher funktioniert `-ngl 999` (alle Schichten auf GPU), solange Modell und KV-Cache in den einheitlichen Speicher passen. 4. **Verwenden Sie `OLLAMA_KV_CACHE_TYPE=q8_0`**, um Ihr Speicherbudget zu dehnen. Das Halbieren des KV-Cache ermöglicht das Ausführen größerer Modelle oder längerer Kontexte. 5. **Setzen Sie `OLLAMA_KEEP_ALIVE=-1`** für immer-verfügbare Inferenz. Modelle bleiben im einheitlichen Speicher ohne Neu ladestrafen. > [!NOTE] > > Wenn Sie plattformübergreifende Portabilität benötigen oder dieselbe Konfiguration auf NVIDIA GPU und Mac ausführen wollen, können Sie Ollama zwingen, das llama.cpp-Backend auf Apple Silicon zu verwenden. Kontaktieren Sie den Ollama-Support oder überprüfen Sie deren Dokumentation für die Umgebungsvariable, um die Backend-Auswahl zu überschreiben. ## Beispielkonfigurationen ### Mac Studio M2 Ultra — 128 GB einheitlicher Speicher ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=4 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:70b-q4_K_M PARAMETER num_ctx 32768 PARAMETER num_batch 1024 ``` Diese Konfiguration betreibt ein 70B-Q4-Modell mit einem 32K-Kontextfenster. Der 128-GB-Pool einheitlichen Speichers verarbeitet die \~40 GB Modellgewichte, \~16 GB KV-Cache bei q8\_0 und lässt Spielraum für 4 parallele Anfragen. MLX liefert maximalen Durchsatz auf Apple Silicon. ### NVIDIA RTX 4090 — 24 GB VRAM ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=2 OLLAMA_NUM_THREADS=4 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:8b-q4_K_M PARAMETER num_ctx 16384 PARAMETER num_batch 1024 ``` Diese Konfiguration betreibt ein 8B-Q4-Modell mit einem 16K-Kontextfenster. Der 24-GB-VRAM verarbeitet die \~5 GB Modellgewichte, \~4 GB KV-Cache bei q8\_0 mit Flash Attention und lässt Spielraum für 2 parallele Anfragen. Die 4 CPU-Threads verarbeiten Orchestrierung und Tokenisierung. ### Multi-GPU-Server — 4× RTX 4090 (96 GB Gesamt-VRAM) ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=8 OLLAMA_NUM_THREADS=8 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:70b-q4_K_M PARAMETER num_ctx 8192 PARAMETER num_batch 2048 ``` Diese Konfiguration betreibt ein 70B-Q4-Modell über 4 GPUs. Ollama verteilt Schichten automatisch über alle verfügbaren GPUs. Der 96-GB-Gesamt-VRAM verarbeitet die \~40 GB Modellgewichte, \~16 GB KV-Cache und lässt Spielraum für 8 parallele Anfragen. Die große Batch-Größe maximiert den Durchsatz für Batch-Workloads. ### Nur-CPU-Server — 64 GB RAM, keine GPU ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=1 OLLAMA_NUM_THREADS=16 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:8b-q4_K_M PARAMETER num_ctx 8192 PARAMETER num_batch 512 PARAMETER num_gpu 0 ``` Diese Konfiguration betreibt ein 8B-Q4-Modell vollständig auf CPU. Die 16 Threads entsprechen der physischen Kernanzahl. Die kleine Batch-Größe und einzelne parallele Anfrage halten den Speicherverbrauch handhabbar. Erwarten Sie 5-10 tok/s — nutzbar für interaktiven Chat, aber nicht für Batch-Workloads. ### Hochdurchsatz-Batchverarbeitung — RTX 4090 ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q4_0 OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=8 OLLAMA_NUM_THREADS=4 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:8b-q4_K_M PARAMETER num_ctx 4096 PARAMETER num_batch 2048 ``` Diese Konfiguration maximiert den Durchsatz für Offline-Batch-Workloads. Der q4\_0-KV-Cache viertelt den Speicherverbrauch, was 8 parallele Anfragen in 24 GB VRAM ermöglicht. Die große Batch-Größe beschleunigt die Prompt-Aufnahme. Der kurze 4K-Kontext hält den KV-Cache klein. Erwarten Sie 200-300 Gesamt-Token pro Sekunde über alle parallelen Anfragen. ### Latenzarmes interaktives Serving — RTX 4090 ```bash theme={"theme":{"light":"github-light","dark":"css-variables"}} # Environment variables OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_KEEP_ALIVE=-1 OLLAMA_NUM_PARALLEL=1 OLLAMA_NUM_THREADS=4 ``` ```dockerfile Modelfile theme={"theme":{"light":"github-light","dark":"css-variables"}} FROM llama3.1:8b-q4_K_M PARAMETER num_ctx 8192 PARAMETER num_batch 512 ``` Diese Konfiguration minimiert die Latenz für interaktiven Chat. Einzelne parallele Anfrage, q8\_0-KV-Cache für Qualität und moderate Batch-Größe. Erwarten Sie Time-to-First-Token unter 500ms und 50-70 tok/s Decode-Geschwindigkeit. ## Häufige Fehler und wie Sie sie vermeiden ### Fehler 1: num\_ctx zu hoch setzen **Problem:** Sie setzen `num_ctx 128000` „nur für den Fall", aber Ihre Prompts sind unter 2K Token. Sie haben gerade 64 GB KV-Cache-Speicher verschwendet. **Lösung:** Setzen Sie `num_ctx` passend zu Ihrer tatsächlichen Workload. Wenn Ihre Prompts unter 4K Token sind, verwenden Sie `num_ctx 4096` oder `num_ctx 8192`. Sie können es später für bestimmte Anfragen über die API immer erhöhen. ### Fehler 2: Flash Attention vergessen **Problem:** Sie verwenden 30-50% mehr VRAM als nötig, weil Flash Attention nicht aktiviert ist. **Lösung:** Setzen Sie immer `OLLAMA_FLASH_ATTENTION=1`. Es gibt keinen Nachteil auf unterstützter Hardware. ### Fehler 3: Modell-Entladen nicht steuern **Problem:** Sie starten Ihre Anfrage nach einer 10-minütigen Pause neu, und die erste Anfrage dauert 30 Sekunden, weil Ollama das Modell von der Festplatte neu geladen hat. **Lösung:** Setzen Sie `OLLAMA_KEEP_ALIVE=-1` für immer-verfügbare Inferenz. Das Modell bleibt im Speicher und jede Anfrage bekommt sofortige Antwort. ### Fehler 4: Zu viele Threads auf GPU verwenden **Problem:** Sie setzen `num_thread 32` auf einer 32-Thread-CPU, aber alle Schichten sind auf der GPU. Die zusätzlichen Threads konkurrieren um Cache und verlangsamen die Orchestrierung. **Lösung:** Wenn alle Schichten auf der GPU sind, verwenden Sie `num_thread 2` bis `num_thread 4`. Die CPU verarbeitet nur Orchestrierung und Tokenisierung, nicht Inferenz-Mathematik. ### Fehler 5: KV-Cache-Präzision ignorieren **Problem:** Ihr VRAM geht zur Neige und Ollama lagert Schichten auf die CPU aus, aber Sie haben nie bedacht, dass der KV-Cache 2× mehr Speicher als nötig verwendet. **Lösung:** Setzen Sie `OLLAMA_KV_CACHE_TYPE=q8_0`, um den KV-Cache-Speicher zu halbieren. Das ist die beste Balance aus Qualität und Speichereinsparung. ### Fehler 6: OLLAMA\_NUM\_PARALLEL zu hoch setzen **Problem:** Sie setzen `OLLAMA_NUM_PARALLEL=16` auf einer 24-GB-GPU, und jetzt hat jede Anfrage nur 1.5 GB KV-Cache. Anfragen schlagen fehl oder die Qualität verschlechtert sich. **Lösung:** Berechnen Sie Ihr KV-Cache-Budget: `(VRAM - model_weights) / num_parallel`. Wenn das weniger als 1 GB pro Anfrage übrig lässt, reduzieren Sie `num_parallel` oder senken Sie `num_ctx`. ## Fehlerbehebung ### Ollama ist nach dem Start langsam **Ursache:** Das Modell wurde entladen und musste von der Festplatte neu geladen werden. **Lösung:** Setzen Sie `OLLAMA_KEEP_ALIVE=-1`, um das Modell unbegrenzt geladen zu halten. ### Out-of-Memory-Fehler **Ursache:** Das Modell + KV-Cache überschreitet den verfügbaren VRAM oder RAM. **Lösung:** Reduzieren Sie `num_ctx`, aktivieren Sie `OLLAMA_FLASH_ATTENTION=1`, setzen Sie `OLLAMA_KV_CACHE_TYPE=q8_0` oder verwenden Sie eine kleinere Quantisierung. ### GPU wird nicht verwendet **Ursache:** Ollama hat die GPU nicht erkannt, oder der VRAM ist zu klein für sogar wenige Schichten. **Lösung:** Prüfen Sie `ollama ps`, um zu sehen, ob Schichten auf der GPU sind. Stellen Sie für NVIDIA-GPUs sicher, dass die NVIDIA-Treiber und das CUDA-Toolkit installiert sind. Stellen Sie für AMD-GPUs sicher, dass ROCm installiert ist. ### Langsame CPU-Inferenz **Ursache:** Zu viele Threads oder Schichten zwischen GPU und CPU aufgeteilt. **Lösung:** Setzen Sie `num_thread` auf die physische Kernanzahl. Lagern Sie wenn möglich mehr Schichten auf die GPU aus mit `num_gpu`. Verwenden Sie eine kleinere Quantisierung (Q4\_K\_M oder Q5\_K\_M), um mehr Schichten auf die GPU zu bekommen. ## Nächste Schritte > **[Ollama remote access](/de/guides/ollama-remote-access.md)** > > Machen Sie Ihr Ollama-Modell für Teamkollegen und Agenten über Tokios zugänglich — ohne Ports zu öffnen oder OLLAMA\_HOST=0.0.0.0 zu setzen. > **[Hardware reference](/de/guides/hardware-reference.md)** > > Vergleichen Sie Hardware-Plattformen für lokale LLM-Inferenz — Spezifikationen, Modellkapazität und Empfehlungen. > **[Model fit finder](/de/guides/model-fit.md)** > > Finden Sie, welche Modelle auf Ihrer Hardware laufen, oder welche Hardware Ihr Zielmodell ausführen kann. > **[Test your deployment](/de/guides/benchmark-your-deployment.md)** > > Messen Sie Latenz und Durchsatz nach der Optimierung, um die Verbesserung zu bestätigen. ## Häufig gestellte Fragen > **What is the best Ollama configuration for fast inference?** > > Aktivieren Sie Flash Attention (`OLLAMA_FLASH_ATTENTION=1`), setzen Sie das Kontextfenster auf das, was Ihre Aufgabe tatsächlich braucht (nicht das Modellmaximum), verwenden Sie quantisierten KV-Cache (`OLLAMA_KV_CACHE_TYPE=q8_0` oder `q4_0`) für lange Kontexte und stellen Sie sicher, dass Ihr Modell vollständig auf der GPU ausgelagert ist. Siehe die Abschnitte oben für die genauen Befehle. > **How do I reduce Ollama memory usage?** > > Die 3 größten Hebel: (1) `num_ctx` senken — Speicher skaliert linear mit der Kontextlänge, (2) den KV-Cache mit `OLLAMA_KV_CACHE_TYPE=q4_0` für bis zu 75% KV-Einsparung quantisieren, (3) eine kleinere Quantisierung der Modellgewichte verwenden (z.B. Q4\_0 statt Q8\_0). Flash Attention spart auch 30-50% an Attention-Speicher. > **Does Ollama use MLX on Mac?** > > Ja — beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework, nicht llama.cpp. MLX liefert erheblich schnellere Inferenz auf M-Series-Chips (55-80 tok/s auf M2 Ultra vs 25-40 tok/s mit llama.cpp). Die Variable `OLLAMA_FLASH_ATTENTION` hat keinen Effekt auf MLX, weil MLX immer optimierte Attention-Kernel verwendet. > **How many parallel requests can Ollama handle?** > > Setzen Sie `OLLAMA_NUM_PARALLEL` (Standard 1). Jeder parallele Slot fügt ungefähr 20-30% Speicher-Overhead für KV-Cache hinzu. Für ein 7B-Modell bei Q4 mit 8K Kontext passen 4 parallele Slots bequem in 8 GB VRAM. Für größere Modelle oder längere Kontexte, starten Sie mit 2 und messen Sie. > **Why is Ollama slow to load my model?** > > Die Modellladezeit wird dominiert vom Lesen der Gewichte von der Festplatte und ihrem Transfer auf die GPU. Verwenden Sie eine NVMe-SSD (nicht HDD), setzen Sie `OLLAMA_KEEP_ALIVE`, um das Modell zwischen Anfragen warm zu halten, und setzen Sie `OLLAMA_MAX_LOADED_MODELS`, um Entladen und Neuladen zu vermeiden. Auf Apple Silicon laden NVFP4-Modelle schneller, weil die Gewichte kleiner sind. > **What GPU offload settings should I use?** > > Standardmäßig wählt Ollama automatisch aus, wie viele Schichten auf die GPU ausgelagert werden. Für maximale Geschwindigkeit setzen Sie `num_gpu` auf die Gesamtschichtanzahl des Modells (vollständig auslagern). Wenn Ihnen der VRAM ausgeht, reduzieren Sie `num_ctx` vor `num_gpu` — das Modell vollständig auf der GPU zu halten ist fast immer schneller als partielles Offload. ## Quellen * [Ollama FAQ](https://docs.ollama.com/faq) — offizielle Dokumentation zu Umgebungsvariablen und Konfiguration * [Ollama Modelfile reference](https://docs.ollama.com/modelfile) — Parametersyntax und gültige Werte * [Ollama MLX performance update](https://ollama.com/blog/mlx-performance) — Benchmarks und Optimierungen für Apple Silicon vom Juni 2026 * [Ollama GPU scheduling deep dive](https://eastondev.com/blog/en/posts/ai/ollama-gpu-scheduling/) — VRAM-Verwaltung und Multi-GPU-Verhalten * [Ollama performance tuning: batching, KV cache, and OOM](https://eastondev.com/blog/en/posts/ai/20260410-ollama-performance-optimization/) — num\_batch-Benchmarks und Speicherberechnungen * [Ollama environment variables: complete reference](https://modelpiper.com/blog/ollama-environment-variables) — geprüft gegen die Quelle v0.32.5 > [!NOTE] > > Nach dem Ändern der Ollama-Konfiguration registrieren Sie Ihre Tokios-Deployment erneut, damit der Connector den neuen Upstream-Endpunkt übernimmt. Siehe [Register Model](/de/setup/register-model.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.