Docker Model Runner: Guide för konfiguration av kontextstorlek

Konfigurera kontextstorlekar i Docker Model Runner med tillfälliga lösningar

Sidinnehåll

Konfigurera kontextstorlekar i Docker Model Runner är mer komplicerat än det borde vara.

Trots att parametern context_size finns i docker-compose-konfigurationen ignoreras den ofta av bilden docker/model-runner:latest-cuda, som har en hårdkodad kontextstorlek på 4096 token. Den här guiden utforskar begränsningarna och ger praktiska lösningar.

konfigurera bil Det här bilden skapades av Flux 1 dev.

Förstå problemet

När du använder Docker Model Runner med docker-compose kan du konfigurera kontextstorlek på följande sätt:

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

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

Emellertid visar loggarna den faktiska kontextstorlek som används:

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

Du kommer att se utdata som:

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

Bilden docker/model-runner:latest-cuda hårdkodar --ctx-size 4096 när den kallar llama.cpp, helt ignorerar din konfiguration context_size: 10240.

Varför detta händer

Kontextstorleken (n_ctx) sätts vid modellinitieringstid i llama.cpp, den underliggande inferensmotorn som Docker Model Runner använder. Detta sker under modellens kontextkonstruktionsfas, innan några API-förfrågningar bearbetas. Docker Model Runners compose-integrering verkar ha en bugg där den inte korrekt överför parametern context_size från modelleravsnittet till den underliggande llama.cpp-processen. Istället standardiseras det till 4096 token oavsett din konfiguration.

Den här begränsningen innebär att även om Docker Compose känner igen parametern context_size i din YAML-konfiguration, respekterar inte bilden docker/model-runner:latest-cuda den när den konstruerar llama.cpp-kommandoradsargumenten. Flaggan --ctx-size 4096 som är hårdkodad tar företräde över någon konfiguration du anger.

Arbetssätt och lösningar

Vad ska man göra? Metoderna 1-2-3 kommer att fungera, men de har begränsningar.

Metod 1. ad-hoc, kommer att fungera. Metod 2. hårdkodad i modellen. Metod 3. kräver containerisering och att du lägger till din egen app i kompositionen. Det är närmare produktionsmiljö.

Metod 1: Använd docker model configure (Begränsad)

Du kan konfigurera kontextstorlek med Docker Model CLI, som sparar konfigurationen i Docker-modellens metadata:

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

Det här kommandot uppdaterar modellens konfiguration, men implementeringen har betydande begränsningar. Konfigurationen sparas men tillämpas inte alltid korrekt.

Begränsningar:

  • Det här fungerar inte när du använder docker model run direkt, endast via curl till API-ändpunkten
  • Du kan inte använda docker model run efter konfiguration - det kommer att ignorera konfigurationen
  • Konfigurationen ignoreras när du använder docker-compose med bilden docker/model-runner:latest-cuda
  • Konfigurationen kan gå förlorad när modellen uppdateras eller dras ner igen

Den här metoden fungerar bäst för testning med direkta API-anrop, men är inte lämplig för produktionsdistributioner med docker-compose.

Metod 2: Paketera din egen modell

Det mest tillförlitliga sättet att ställa in en anpassad kontextstorlek är att paketera din egen modell med den önskade kontextstorleken med docker model package. Detta bakar in kontextstorleken i modellens metadata vid paketeringstid:

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

Det här skapar en ny OCI-artefakt (liknande en Docker-bild) med kontextstorleken permanent konfigurerad. Den paketerade modellen kan sedan skickas till Docker Hub eller något OCI-kompatibelt register och dras ner som någon annan Docker Model Runner-modell.

Emellertid kräver den här metoden:

  • Åtkomst till den ursprungliga GGUF-modellfilen (den kvantiserade format som används av llama.cpp)
  • Repaketering varje gång du vill ändra kontextstorlek, vilket kan vara tidskrävande
  • Hantering av ditt eget modellregister eller Docker Hub-konto
  • Förståelse för Docker Model Runner paketeringsarbetsflöde

Den här metoden är bäst lämpad för produktionsmiljöer där du behöver konsekventa, reproducerbara kontextstorlekar över distributioner.

Metod 3: Docker Compose

Det här är för närvarande bruten för docker/model-runner:latest-cuda

Men för din egen app i bilden kan det fungera :)

Trots att syntaxen finns i docker-compose.yml:

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

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

Det här fungerar inte - parametern context_size känns igen av docker-compose men tillämpas inte. Modellen använder fortfarande 4096 token.

Metod 4: Miljövariabler (Även bruten)

Försök att använda miljövariabeln MODEL_CONTEXT:

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

Det här fungerar inte heller - miljövariabeln respekteras inte när du använder docker-compose.

Verifiera kontextstorlek

För att kontrollera vilken kontextstorlek som faktiskt används, undersök loggarna:

# Kontrollera llama.cpp-argument
docker compose logs 2>&1 | grep "llamaCppArgs"

# Kontrollera faktisk kontextstorlek
docker compose logs 2>&1 | grep -i "n_ctx" | tail -10

Du kommer att se utdata som:

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

Om du ser n_ctx = 4096 trots att du har konfigurerat ett annat värde, ignoreras din konfiguration.

Testning av kontextstorlek

För att verifiera om din kontextstorlekskonfiguration faktiskt tillämpas, måste du testa med prompts som överskrider den standardmässiga gränsen på 4096 token. Här är ett praktiskt skript som använder Python för att testa om din kontextstorlekskonfiguration fungerar:

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

# Test med stor 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

# Kontrollera tokenanvändning
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("✅ Kontextfönstret är större än 4096!")
        else:
            print("⚠️ Kontextfönstret verkar vara begränsat till 4096")
PYTHON

Alternativa lösningar

Om du behöver mer flexibel konfiguration av kontextstorlek, överväg dessa alternativ:

  • Ollama - Ett alternativt LLM-värdningssystem som ger bättre kontroll över kontextstorlekar och enklare konfiguration. Ollama låter dig ange kontextstorlek per modell och har inte samma docker-compose-begränsningar.

  • Jämförelse mellan Docker Model Runner och Ollama - En detaljerad jämförelse av båda lösningarna, inklusive kontextstorlekskonfigurationsförmåga, prestanda och när man ska välja varje plattform.

Relaterade resurser

Docker Model Runner

Docker och infrastruktur

Alternativa LLM-lösningar

Officiell dokumentation

Slutsats

Konfiguration av kontextstorlekar i Docker Model Runner är för närvarande problematisk när man använder docker-compose. Trots att konfigurationssyntaxen finns i Docker Compose-specifikationen är den inte korrekt implementerad i bilden docker/model-runner:latest-cuda, som hårdkodar en kontextstorlek på 4096 token oavsett din konfiguration.

Det mest tillförlitliga arbetssättet är att paketera dina egna modeller med den önskade kontextstorleken med docker model package, även om detta lägger till komplexitet i ditt arbetsflöde och kräver åtkomst till de ursprungliga GGUF-modellfilerna. Alternativt kan du använda docker model configure för direkt API-åtkomst, men detta fungerar inte med docker-compose-distributioner.

För de flesta användningsområden är den standardmässiga kontextstorleken på 4096 token tillräcklig för typiska konversations-AI-applikationer. Om du behöver större kontextfönster eller mer flexibel konfiguration, överväg att använda Ollama som alternativ, som ger bättre kontroll över kontextstorlekar utan docker-compose-begränsningar.

Du kan fortfarande optimera VRAM-användningen på andra sätt, till exempel genom modellkvantisering (Q4, Q6, Q8) och GPU-lagerskonfiguration (MODEL_GPU_LAYERS), som är mer effektiva för att minska minnesanvändningen än justeringar av kontextstorlek.

För mer detaljer om GPU-optimering och VRAM-hantering, se vår guide om konfigurering av NVIDIA GPU-stöd.