Warum funktioniert context_size in docker-compose.yml nicht mit dem docker/model-runner-Image?

Das Bild docker/model-runner:latest-cuda kodiert den Wert –ctx-size 4096 hart, wenn llama.cpp aufgerufen wird, und ignoriert dabei den Parameter context_size im Abschnitt der Modelle. Dies ist eine bekannte Einschränkung der aktuellen Implementierung.

Darf ich die Kontextgröße pro API-Anfrage ändern?

Nein, die Kontextgröße wird zur Modellinitialisierung festgelegt, nicht pro Anfrage. Sie können die Ausgabelänge nur über den max_tokens-Parameter in API-Anfragen steuern.

Funktioniert der Befehl docker model configure –context-size?

Ja, aber nur wenn docker model run direkt verwendet wird. Die Konfiguration wird ignoriert, wenn docker-compose mit dem Bild docker/model-runner verwendet wird.

Wie kann ich die tatsächlich verwendete Kontextgröße überprüfen?

Überprüfen Sie die docker compose Protokolle mit docker compose logs 2>&1 | grep -i "n_ctx" , um die tatsächlich verwendete Kontextgröße (n_ctx) von llama.cpp zu sehen.

Wie kann ich am besten benutzerdefinierte Kontextgrößen verwenden?

Verpacken Sie Ihr eigenes Modell mit docker model package –context-size oder verwenden Sie docker model configure für direkte docker model run-Befehle. Bei docker-compose müssen Sie möglicherweise auf zukünftige Updates warten, die context_size ordnungsgemäß unterstützen.

Warum ist die Kontextgröße für den VRAM-Verbrauch wichtig?

Größere Kontextgrößen benötigen mehr VRAM. Allerdings legt docker/model-runner die Kontextgröße fest auf 4096, sodass der VRAM-Verbrauch hauptsächlich durch die Modellgröße, die Quantisierungsstufe und die Anzahl der GPU-Schichten (MODEL_GPU_LAYERS) bestimmt wird.

Wo passt die Docker Model Runner-Kontextkonfiguration in das Landschaftsbild der LLM-Hosting-Lösungen?

„Docker Model Runner ist eine lokale Option. Unser Hauptleitfaden zur LLM-Hosting-Vergleichsuntersuchung vergleicht ihn mit Ollama, vLLM, LocalAI und Cloud-Anbietern, einschließlich Konfigurations- und Infrastrukturkompromisse.“

Wenn die Kontextgröße entscheidend ist, sollte ich eine andere Lösung verwenden?

Ollama und andere lokale Tools bieten oft eine einfachere Steuerung der Kontextgröße. Der LLM-Hosting-Leitfaden vergleicht Docker Model Runner mit Ollama, vLLM, LocalAI und Cloud, damit Sie je nach Anwendungsfall eine Wahl treffen können.

Docker Model Runner: Kontextgrößen-Konfigurationsleitfaden

„Kontextgrößen im Docker Model Runner konfigurieren mit Umgehungsmöglichkeiten“

Inhaltsverzeichnis

Einrichten von Kontextgrößen im Docker Model Runner ist komplexer, als es sein sollte.

Obwohl der Parameter context_size in der docker-compose-Konfiguration vorhanden ist, wird er oft vom Image docker/model-runner:latest-cuda ignoriert, das eine Kontextgröße von 4096 Token festvorgibt. Dieser Leitfaden untersucht die Einschränkungen und bietet praktische Umgehungen. Für eine umfassendere Vergleichsanalyse von Docker Model Runner mit Ollama, vLLM, LocalAI und Cloud-Anbietern – einschließlich Konfigurations- und Infrastrukturauswirkungen – siehe LLM-Hosting: Lokal, Selbstgehostet und Cloud-Infrastruktur im Vergleich.

configuring car Dieses Bild wurde von Flux 1 dev generiert.

Problem verstehen

Wenn Sie Docker Model Runner mit docker-compose verwenden, können Sie die Kontextgröße wie folgt konfigurieren:

services:
  llm:
    image: docker/model-runner:latest-cuda
    models:
      - llm_model

models:
  llm_model:
    model: ai/gemma3-qat:4B
    context_size: 10240

Doch die Überprüfung der Protokolle zeigt die tatsächlich verwendete Kontextgröße:

docker compose logs 2>&1 | grep -i "n_ctx"

Sie werden eine Ausgabe wie folgt sehen:

llamaCppArgs: [... --ctx-size 4096 ...]
llama_context: n_ctx = 4096

Das Image docker/model-runner:latest-cuda vorgibt fest --ctx-size 4096, wenn llama.cpp aufgerufen wird, und ignoriert vollständig Ihre Konfiguration context_size: 10240.

Warum das passiert

Die Kontextgröße (n_ctx) wird in llama.cpp, dem zugrunde liegenden Inferenzmotor, der von Docker Model Runner verwendet wird, zur Initialisierungszeit des Modells festgelegt. Dies geschieht während der Kontextkonstruktion des Modells, bevor irgendeine API-Anfrage verarbeitet wird. Die Integration von Docker Model Runner in docker-compose scheint einen Fehler zu haben, bei dem der Parameter context_size nicht ordnungsgemäß vom Abschnitt models an den zugrunde liegenden Prozess von llama.cpp übergeben wird. Stattdessen wird standardmäßig auf 4096 Token zurückgegriffen, unabhängig von Ihrer Konfiguration.

Diese Einschränkung bedeutet, dass, obwohl Docker Compose den Parameter context_size in Ihrer YAML-Konfiguration erkennt, das Image docker/model-runner:latest-cuda ihn nicht beachtet, wenn die Befehlszeilenargumente für llama.cpp erstellt werden. Der fest vorgeschriebene Flag --ctx-size 4096 hat Vorrang vor jeder von Ihnen angegebenen Konfiguration.

Umgehungen und Lösungen

Was tun? Methoden 1–2–3 funktionieren, haben jedoch Einschränkungen.

Methode 1. Ad-hoc, funktioniert. Methode 2. Fest vorgeschrieben im Modell. Methode 3. Erfordert Containerisierung und Integration Ihres eigenen Apps in die Komposition. Das ist näher an der Produktion.

Methode 1: `docker model configure` verwenden (Eingeschränkt)

Sie können die Kontextgröße mithilfe der Docker Model CLI konfigurieren, die die Konfiguration in der Docker-Modellmetadaten speichert:

docker model configure --context-size=10000 ai/gemma3-qat:4B

Dieser Befehl aktualisiert die Modellkonfiguration, hat jedoch erhebliche Einschränkungen. Die Konfiguration wird gespeichert, wird aber nicht immer korrekt angewendet.

Einschränkungen:

Dies funktioniert nicht, wenn Sie docker model run direkt verwenden, sondern nur über die API-Endpunkt mit curl
Sie können docker model run nicht nach der Konfiguration verwenden – es wird die Konfiguration ignorieren
Die Konfiguration wird ignoriert, wenn Sie docker-compose mit dem Image docker/model-runner:latest-cuda verwenden
Die Konfiguration kann verloren gehen, wenn das Modell aktualisiert oder erneut heruntergeladen wird

Diese Methode eignet sich am besten für Tests mit direkten API-Aufrufen, ist aber nicht für Produktionsbereitstellungen mit docker-compose geeignet.

Methode 2: Ihr eigenes Modell verpacken

Die zuverlässigste Methode, um eine benutzerdefinierte Kontextgröße festzulegen, besteht darin, Ihr eigenes Modell mit der gewünschten Kontextgröße mithilfe von docker model package zu verpacken. Dies schreibt die Kontextgröße während des Verpackungsprozesses in die Modellmetadaten:

docker model package \
  --gguf /path/to/model.gguf \
  --context-size 10240 \
  --name my-model:custom-context

Dies erstellt ein neues OCI-Artifact (ähnlich einem Docker-Image) mit der Kontextgröße dauerhaft konfiguriert. Das verpackte Modell kann dann in das Docker Hub oder in einen beliebigen OCI-konformen Registry hochgeladen und wie jedes andere Docker Model Runner-Modell heruntergeladen werden.

Allerdings erfordert dieser Ansatz:

Zugriff auf die ursprüngliche GGUF-Modelldatei (das quantisierte Format, das von llama.cpp verwendet wird)
Neuerstellung jedes Mal, wenn Sie die Kontextgröße ändern möchten, was zeitaufwendig sein kann
Verwaltung Ihres eigenen Modellregisters oder Docker Hub-Kontos
Kenntnisse über den Verpackungsworkflow von Docker Model Runner

Diese Methode ist am besten für Produktionsumgebungen geeignet, in denen Sie konsistente, reproduzierbare Kontextgrößen über alle Bereitstellungen hinweg benötigen.

Methode 3: Docker Compose

Dies ist derzeit für docker/model-runner:latest-cuda defekt

Aber für Ihre eigene App im Image könnte es funktionieren :)

Obwohl die Syntax in docker-compose.yml vorhanden ist:

services:
  llm:
    image: docker/model-runner:latest-cuda
    models:
      - llm_model

models:
  llm_model:
    model: ai/gemma3-qat:4B
    context_size: 10240

Dies funktioniert nicht – der Parameter context_size wird von docker-compose erkannt, aber nicht angewendet. Das Modell verwendet weiterhin 4096 Token.

Methode 4: Umgebungsvariablen (Auch defekt)

Versuchen Sie, die Umgebungsvariable MODEL_CONTEXT zu verwenden:

services:
  llm:
    image: docker/model-runner:latest-cuda
    environment:
      - MODEL_CONTEXT=10240

Dies funktioniert auch nicht – die Umgebungsvariable wird nicht beachtet, wenn docker-compose verwendet wird.

Kontextgröße überprüfen

Um zu prüfen, welche Kontextgröße tatsächlich verwendet wird, untersuchen Sie die Protokolle:

# Prüfen Sie die llama.cpp-Argumente
docker compose logs 2>&1 | grep "llamaCppArgs"

# Prüfen Sie die tatsächliche Kontextgröße
docker compose logs 2>&1 | grep -i "n_ctx" | tail -10

Sie werden eine Ausgabe wie folgt sehen:

llamaCppArgs: [-ngl 999 --metrics --model /models/... --ctx-size 4096 ...]
llama_context: n_ctx = 4096
llama_context: n_ctx_per_seq = 4096

Wenn Sie n_ctx = 4096 sehen, obwohl Sie einen anderen Wert konfiguriert haben, wird Ihre Konfiguration ignoriert.

Kontextgröße testen

Um zu prüfen, ob Ihre Konfiguration der Kontextgröße tatsächlich angewendet wird, müssen Sie mit Prompts testen, die den Standardwert von 4096 Token überschreiten. Hier ist ein praktisches Skript, das mit Python verwendet wird, um zu prüfen, ob Ihre Konfiguration der Kontextgröße funktioniert:

#!/bin/bash
MODEL="ai/gemma3-qat:4B"
PORT=8085

# Test mit großem Prompt
python3 -c "print('test ' * 5000)" > large_prompt.txt

python3 << 'PYTHON' > request.json
import json
import os

with open('large_prompt.txt', 'r') as f:
    large_prompt = f.read().strip()

request = {
    "model": os.environ.get("MODEL", "ai/gemma3-qat:4B"),
    "messages": [{
        "role": "user",
        "content": large_prompt
    }]
}
print(json.dumps(request))
PYTHON

curl -s http://localhost:${PORT}/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d @request.json > response.json

# Prüfen Sie die Tokenverwendung
python3 << 'PYTHON'
import json
with open('response.json') as f:
    r = json.load(f)
    if 'usage' in r:
        print(f"Prompt tokens: {r['usage']['prompt_tokens']}")
        if r['usage']['prompt_tokens'] > 4096:
            print("✅ Der Kontextbereich ist größer als 4096!")
        else:
            print("⚠️ Der Kontextbereich scheint auf 4096 begrenzt zu sein")
PYTHON

Alternative Lösungen

Wenn Sie eine flexiblere Konfiguration der Kontextgröße benötigen, erwägen Sie diese Alternativen:

Ollama – Eine alternative Lösung zur LLM-Hosting, die eine bessere Kontrolle über Kontextgrößen und einfachere Konfiguration bietet. Ollama ermöglicht es Ihnen, die Kontextgröße pro Modell anzugeben und hat keine gleichen Einschränkungen bei docker-compose.
Vergleich zwischen Docker Model Runner und Ollama – Eine detaillierte Vergleichsanalyse beider Lösungen, einschließlich der Fähigkeiten zur Konfiguration der Kontextgröße, Leistung und der Entscheidung, welche Plattform in welchem Fall besser ist.

Um zu sehen, wie Docker Model Runner mit anderen lokalen und Cloud-Optionen zusammenpasst, prüfen Sie unseren Leitfaden zu LLM-Hosting: Lokal, Selbstgehostet und Cloud-Infrastruktur im Vergleich.

Schlussfolgerung

Die Konfiguration von Kontextgrößen in Docker Model Runner ist derzeit problematisch, wenn docker-compose verwendet wird. Obwohl der Konfigurationsparameter in der Docker Compose-Spezifikation vorhanden ist, wird er nicht ordnungsgemäß in dem Image docker/model-runner:latest-cuda implementiert, das eine Kontextgröße von 4096 Token festvorgibt, unabhängig von Ihrer Konfiguration.

Die zuverlässigste Umgehung besteht darin, Ihre eigenen Modelle mit der gewünschten Kontextgröße mithilfe von docker model package zu verpacken, obwohl dies Komplexität in Ihren Workflow hinzufügt und Zugriff auf die ursprünglichen GGUF-Modelldateien erfordert. Alternativ können Sie docker model configure für direkte API-Zugriffe verwenden, was aber nicht mit docker-compose-Bereitstellungen funktioniert.

Für die meisten Anwendungsfälle ist die Standardkontextgröße von 4096 Token für typische Anwendungen von Conversational AI ausreichend. Wenn Sie größere Kontextbereiche oder flexiblere Konfigurationen benötigen, erwägen Sie die Verwendung von Ollama als Alternative, die eine bessere Kontrolle über Kontextgrößen bietet, ohne Einschränkungen bei docker-compose.

Sie können den VRAM-Verbrauch weiterhin durch andere Methoden wie Modellquantisierung (Q4, Q6, Q8) und GPU-Schichtkonfiguration (MODEL_GPU_LAYERS) optimieren, die effektiver für die Reduzierung des Speicherverbrauchs sind als Anpassungen der Kontextgröße.

Für weitere Details zur GPU-Optimierung und VRAM-Verwaltung siehe unseren Leitfaden zu Konfigurieren der NVIDIA-GPU-Unterstützung.