Dlaczego parametr context_size w pliku docker-compose.yml nie działa z obrazem docker/model-runner?

Obraz docker/model-runner:latest-cuda ustala w sposób stały parametr –ctx-size 4096 podczas wywoływania llama.cpp, ignorując parametr context_size w sekcji modeli. Jest to znana wada bieżącej implementacji.

Czy mogę zmienić rozmiar kontekstu na żądanie API?

Nie, wielkość kontekstu jest ustawiana podczas inicjalizacji modelu, a nie dla każdej żądania. Możesz kontrolować tylko długość wyjścia za pomocą parametru max_tokens w żądaniach API.

Działa polecenie docker model configure –context-size?

Tak, ale tylko wtedy, gdy używasz bezpośrednio docker model run. Konfiguracja jest ignorowana, gdy korzystasz z docker-compose i obrazu docker/model-runner.

Jak mogę zweryfikować rzeczywisty rozmiar kontekstu, który jest używany?

Sprawdź dzienniki docker compose za pomocą polecenia docker compose logs 2>&1 | grep -i "n_ctx" , aby zobaczyć rzeczywisty rozmiar kontekstu (n_ctx), który wykorzystuje llama.cpp.

Jak najlepiej korzystać z niestandardowych rozmiarów kontekstu?

Zapakuj własny model za pomocą docker model package –context-size, albo użyj docker model configure do bezpośredniego uruchamiania poleceń docker model run. Dla docker-compose może być konieczne poczekać na przyszłe aktualizacje, które poprawnie obsłużą context_size.

Dlaczego wielkość kontekstu jest ważna dla wykorzystania VRAM?

Większe rozmiary kontekstu wymagają większej ilości VRAM. Jednak w przypadku docker/model-runner rozmiar kontekstu jest ustalony na 4096, więc zużycie VRAM zależy głównie od rozmiaru modelu, poziomu kwantyzacji oraz liczby warstw GPU (MODEL_GPU_LAYERS).

Gdzie w krajobrazie hostingowania modeli LLM mieści się konfiguracja kontekstu Docker Model Runner?

Docker Model Runner to jedna z lokalnych opcji. Nasz główny przewodnik po hostowaniu LLM porównuje go z Ollama, vLLM, LocalAI i dostawcami chmurowymi, w tym aspekty konfiguracji i infrastruktury.

Jeśli rozmiar kontekstu jest kluczowy, czy powinienem zastosować inną metodę?

Ollama i inne lokalne narzędzia często oferują prostszy sposób na kontrolowanie rozmiaru kontekstu. Przewodnik po gospodarowaniu modelami LLM porównuje Docker Model Runner z Ollama, vLLM, LocalAI i chmurą, aby można było dokonać wyboru na podstawie konkretnego przypadku użycia.

Docker Model Runner: Przewodnik konfiguracji rozmiaru kontekstu

Skonfiguruj rozmiary kontekstów w Docker Model Runner z użyciem zaokrągleń

Page content

Konfigurowanie rozmiarów kontekstu w Docker Model Runner jest bardziej skomplikowane, niż powinno być.

Choć parametr context_size istnieje w konfiguracji docker-compose, często jest ignorowany przez obraz docker/model-runner:latest-cuda, który ustala rozmiar kontekstu na 4096 tokenów. Niniejszy przewodnik omawia ograniczenia i zaprezentuje praktyczne sposoby obejścia tego problemu. Dla szerokiego porównania Docker Model Runner z Ollama, vLLM, LocalAI i dostawcami chmurowych — w tym analizy konfiguracji i aspektów infrastrukturalnych — zobacz Hostowanie modeli językowych: porównanie lokalnego, samodzielnie hostowanego i chmurowego infrastruktury.

konfigurowanie samochodu To zdjęcie zostało wygenerowane przez Flux 1 dev.

Zrozumienie problemu

Podczas korzystania z Docker Model Runner z docker-compose możesz skonfigurować rozmiar kontekstu w następujący sposób:

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

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

Jednak sprawdzając logi, odkrywasz, jaki rzeczywisty rozmiar kontekstu jest używany:

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

Zobaczysz wynik takiego typu:

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

Obraz docker/model-runner:latest-cuda ustawia hardcode --ctx-size 4096 podczas wywoływania llama.cpp, całkowicie ignorując Twoją konfigurację context_size: 10240.

Dlaczego to się zdarza

Rozmiar kontekstu (n_ctx) jest ustawiany w momencie inicjalizacji modelu w llama.cpp, podstawowym silniku wnioskowania, który wykorzystuje Docker Model Runner. To dzieje się podczas fazy konstrukcji kontekstu modelu, przed przetworzeniem jakichkolwiek żądań API. Integracja Docker Model Runner z docker-compose wydaje się mieć błąd, w którym nieprawidłowo przekazuje parametr context_size z sekcji modeli do procesu llama.cpp. Zamiast tego, domyślnie ustawia 4096 tokenów, niezależnie od Twojej konfiguracji.

To ograniczenie oznacza, że mimo iż Docker Compose rozpoznaje parametr context_size w Twojej konfiguracji YAML, obraz docker/model-runner:latest-cuda go nie uwzględnia podczas tworzenia argumentów wiersza poleceń dla llama.cpp. Ustalone --ctx-size 4096 nadają się pierwszeństwo konfiguracji, którą określasz.

Przykłady rozwiązań i sposoby obejścia

Co zrobić? Metody 1-2-3 będą działać, ale mają ograniczenia.

Metoda 1. ad-hoc, będzie działać. Metoda 2. hardkodowana w modelu. Metoda 3. wymaga konteneryzacji i wstawienia własnej aplikacji do kompozycji. To jest bliższe produkcji.

Metoda 1: Użycie `docker model configure` (Ograniczenia)

Możesz skonfigurować rozmiar kontekstu za pomocą CLI Docker Model, który przechowuje konfigurację w metadanych modelu Docker:

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

To polecenie aktualizuje konfigurację modelu, ale implementacja ma istotne ograniczenia. Konfiguracja jest przechowywana, ale nie zawsze jest poprawnie stosowana.

Ograniczenia:

Nie działa, gdy korzystasz bezpośrednio z docker model run, tylko przez curl do punktu końcowego API
Nie możesz używać docker model run po skonfigurowaniu — zignoruje konfigurację
Konfiguracja jest ignorowana, gdy używasz docker-compose z obrazem docker/model-runner:latest-cuda
Konfiguracja może zostać utracona, gdy model zostanie zaktualizowany lub ponownie pobrany

Ta metoda działa najlepiej w przypadku testowania z bezpośrednimi wywołaniami API, ale nie jest odpowiednia do wdrożeń produkcyjnych z użyciem docker-compose.

Metoda 2: Umieszczenie własnego modelu

Najbardziej niezawodny sposób na ustawienie niestandardowego rozmiaru kontekstu to pakowanie własnego modelu z pożądanym rozmiarem kontekstu za pomocą docker model package. To zapisuje rozmiar kontekstu w metadanych modelu w momencie pakowania:

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

To tworzy nowy artefakt OCI (podobny do obrazu Docker) z trwale skonfigurowanym rozmiarem kontekstu. Pakowany model może zostać przesłany do Docker Hub lub dowolnego zgodnego z OCI rejestru i pobrany tak jak każdy inny model Docker Model Runner.

Jednak ten podejście wymaga:

Dostępu do oryginalnego pliku modelu GGUF (formatu kwantyzowanego używanego przez llama.cpp)
Ponownego pakowania za każdym razem, gdy chcesz zmienić rozmiar kontekstu, co może być czasochłonne
Zarządzania własnym rejestrem modeli lub kontem Docker Hub
Zrozumienia przepływu pracy pakowania Docker Model Runner

Ta metoda jest najlepsza do środowisk produkcyjnych, gdzie potrzebujesz spójnych, powtarzalnych rozmiarów kontekstu w różnych wdrożeniach.

Metoda 3: Docker Compose

To obecnie nie działa dla docker/model-runner:latest-cuda

Ale może działać dla własnej aplikacji w obrazie, jeśli tylko chcesz :)

Choć składnia istnieje w 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

To nie działa — parametr context_size jest rozpoznawany przez docker-compose, ale nie jest stosowany. Model nadal korzysta z 4096 tokenów.

Metoda 4: Zmienne środowiskowe (Także nie działają)

Próba użycia zmiennej środowiskowej MODEL_CONTEXT:

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

To również nie działa — zmienna środowiskowa nie jest stosowana podczas użycia docker-compose.

Sprawdzanie rozmiaru kontekstu

Aby sprawdzić, jaki rzeczywisty rozmiar kontekstu jest używany, przejrzyj logi:

# Sprawdzenie argumentów llama.cpp
docker compose logs 2>&1 | grep "llamaCppArgs"

# Sprawdzenie rzeczywistego rozmiaru kontekstu
docker compose logs 2>&1 | grep -i "n_ctx" | tail -10

Zobaczysz wynik takiego typu:

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

Jeśli zobaczysz n_ctx = 4096, mimo że skonfigurowałeś inny rozmiar, Twoja konfiguracja jest ignorowana.

Testowanie rozmiaru kontekstu

Aby zweryfikować, czy konfiguracja rozmiaru kontekstu faktycznie jest stosowana, musisz przetestować z wskazówkami przekraczającymi domyślny limit 4096 tokenów. Oto praktyczny skrypt korzystający z Pythona do testowania, czy konfiguracja rozmiaru kontekstu działa:

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

# Test z dużym wskazówką
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

# Sprawdzenie użycia tokenów
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("✅ Rozmiar okna kontekstu jest większy niż 4096!")
        else:
            print("⚠️ Rozmiar okna kontekstu wydaje się ograniczony do 4096")
PYTHON

Alternatywne rozwiązania

Jeśli potrzebujesz bardziej elastycznego konfigurowania rozmiarów kontekstu, rozważ poniższe alternatywy:

Ollama — alternatywna metoda hostowania modeli językowych, która oferuje lepszą kontrolę nad rozmiarami kontekstu i prostszą konfigurację. Ollama pozwala określić rozmiar kontekstu dla każdego modelu i nie ma tych samych ograniczeń związanych z docker-compose.
Porównanie Docker Model Runner z Ollama — szczegółowe porównanie obu rozwiązań, w tym możliwości konfiguracji rozmiarów kontekstu, wydajność oraz kiedy wybrać każdy z tych platform.

Aby zobaczyć, jak Docker Model Runner pasuje do innych lokalnych i chmurowych opcji, sprawdź nasz przewodnik Hostowanie modeli językowych: lokalne, samodzielnie hostowane i chmurowe infrastruktury porównane.

Powiązane zasoby

Docker Model Runner

Docker Model Runner Cheatsheet — kompletny referencyjny opis wszystkich operacji związanych z Docker Model Runner
Dodanie wsparcia dla GPU NVIDIA do Docker Model Runner — krok po kroku jak włączyć przyspieszenie GPU
Docker Model Runner vs Ollama: Który wybrać?

Docker i infrastruktura

Docker Cheatsheet — istotne polecenia Docker do zarządzania kontenerami
Docker Compose Cheatsheet — kompletny przewodnik po konfiguracji i poleceniach Docker Compose

Alternatywne rozwiązania dla modeli językowych

Ollama Cheatsheet — alternatywna metoda hostowania modeli językowych z wbudowanym wsparciem dla GPU i prostszym konfigurowaniem rozmiarów kontekstu
Integracja Ollama z Pythonem

Dokumentacja oficjalna

Dokumentacja Docker Model Runner — oficjalna dokumentacja Docker dotycząca Model Runner
Konfiguracja kontekstu w llama.cpp — dokumentacja silnika wnioskowania

Podsumowanie

Konfigurowanie rozmiarów kontekstu w Docker Model Runner jest obecnie problematyczne przy użyciu docker-compose. Choć składnia konfiguracji istnieje w specyfikacji Docker Compose, nie jest poprawnie zaimplementowana w obrazie docker/model-runner:latest-cuda, który ustala rozmiar kontekstu na 4096 tokenów niezależnie od Twojej konfiguracji.

Najbardziej niezawodny sposób obejścia problemu to pakowanie własnych modeli z pożądanym rozmiarem kontekstu za pomocą docker model package, choć to dodaje złożoność do Twojego procesu pracy i wymaga dostępu do oryginalnych plików modelu GGUF. Alternatywnie możesz użyć docker model configure do bezpośredniego dostępu do API, ale to nie działa z wdrożeniami docker-compose.

Dla większości przypadków użycia domyślny rozmiar kontekstu 4096 tokenów jest wystarczający dla typowych aplikacji AI dialogowych. Jeśli potrzebujesz większych okien kontekstu lub bardziej elastycznej konfiguracji, rozważ użycie Ollama jako alternatywy, która oferuje lepszą kontrolę nad rozmiarami kontekstu bez ograniczeń związanych z docker-compose.

Możesz nadal optymalizować użycie VRAM za pomocą innych metod, takich jak kwantyzacja modelu (Q4, Q6, Q8) i konfiguracja warstw GPU (MODEL_GPU_LAYERS), które są bardziej skuteczne w redukcji zużycia pamięci niż dostosowania rozmiaru kontekstu.

Aby uzyskać więcej informacji na temat optymalizacji GPU i zarządzania VRAM, zobacz nasz przewodnik dotyczący konfiguracji wsparcia dla GPU NVIDIA.