Türkei (Türkisch)
Germany (German)
Worldwide (English)
Docker Model Runner kann Modelle aus Docker Hub, OCI-kompatiblen Registries oder Hugging Face laden und lokal bereitstellen.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Docker Model Runner: GPU-Anforderungen, llama.cpp/vLLM/Diffusers, OpenAI-/Ollama-API, Kontext/VRAM, OCI-Modelle und Ollama-Unterschiede.
Docker Model Runner kann Modelle aus Docker Hub, OCI-kompatiblen Registries oder Hugging Face laden und lokal bereitstellen.
Die aktuelle Docker-Dokumentation nennt OpenAI- und Ollama-kompatible APIs; die API-Referenz dokumentiert zusätzlich Anthropic-kompatible Endpoints.
Unterstützte Inference-Engines sind llama.cpp, vLLM und Diffusers; vLLM und Diffusers sind für Linux mit NVIDIA-GPUs vorgesehen.
Für Windows amd64 nennt Docker aktuell NVIDIA-GPU und Treiber 576.57+ als Voraussetzung.
Ollama vereinfacht lokale Inference; Docker Model Runner bindet Modelle stärker in Docker, Registries und Compose ein. Ein wichtiger Unterschied ist die Behandlung von Modellen als versionierbare OCI-Artefakte für Pull/Push und Deployment.
DMR cached Modelle nach dem ersten Pull lokal, lädt sie bei Requests in den Speicher und kann sie bei Inaktivität entladen. Bei der Kapazitätsplanung Cold-Load-Zeit und residenten VRAM getrennt betrachten.
Für Docker Desktop Windows amd64 nennt Docker NVIDIA-GPU und Treiber 576.57+. Docker Engine unter Linux unterstützt breiter CPU, NVIDIA CUDA, AMD ROCm und Vulkan; Aussagen zu AMD brauchen daher den Plattformkontext.
vLLM und Diffusers sind laut aktueller DMR-Dokumentation für Linux mit NVIDIA-GPU vorgesehen. Unter Windows ist llama.cpp mit GGUF der natürlichere Einstieg.
nvidia-smidocker versionDMR verwendet `docker model` für den Modell-Lifecycle. Modell aus Registry ziehen, ausführen, Metadaten/Kontext prüfen und Anwendungen an die lokale API anbinden.
Wird `docker model` nicht erkannt, Docker-Version und aktivierten Model Runner prüfen. Zuerst offiziellen Upgrade-/Enable-Weg nutzen statt beliebige CLI-Plugins zu kopieren.
docker model --helpdocker model pull ai/qwen2.5-coderdocker model inspect ai/qwen2.5-coderBei aktiviertem Host-TCP-Zugriff ist DMR laut Dokumentation über localhost:12434 erreichbar. OpenAI-Clients nutzen `/engines/v1`, Ollama-kompatible Clients den Host-Endpoint; bestehende Tools lassen sich dadurch leichter anbinden.
API-Kompatibilität bedeutet nicht, dass jede Ollama-/OpenAI-Funktion identisch ist. Tool Calling, Embeddings, Optionen und Streaming mit dem konkreten Client testen.
curl http://localhost:12434/engines/v1/modelscurl http://localhost:12434/api/tagsDie Modellgewichte bleiben gleich, aber längerer Kontext erhöht KV-Cache- und Runtime-Speicher. Docker unterstützt `docker model configure --context-size`; bei OOM ist eine kleinere Kontextgröße eine der ersten Maßnahmen.
Docker unterscheidet maximale Modell-Kontextlänge und tatsächlich konfigurierte Runtime-Kontextgröße. 128K Support bedeutet nicht, dass 128K auf 8/12/16 GB VRAM praktisch nutzbar ist.
docker model configure --context-size 8192 ai/qwen2.5-coderdocker model inspect ai/qwen2.5-coderllama.cpp eignet sich für ressourceneffiziente lokale GGUF-Inference. vLLM zielt auf hohen Durchsatz mit Safetensors. Diffusers dient Text-to-Image-Modellen wie Stable Diffusion.
DMR ist nicht nur ein weiterer LLM-Runner. Der strategische Unterschied liegt in mehreren Inference-Engines und Modell-Artefakt-Workflows unter Docker.
Ollama bleibt sehr praktisch für schnelle Installation, Community, Modelfile und einfache lokale API. DMR ist besonders für Docker-zentrierte Teams attraktiv, die Registry, Compose, Artefaktverteilung und konsistente Deployments wünschen.
Für einen einzelnen Windows-PC mit Chat/Coding-Modellen kann Ollama einfacher sein. Für versionierte Modell-Artefakte, Registry-Sharing, Linux-GPU-Server oder Diffusers/vLLM passt DMR oft besser.
Docker dokumentiert unter Linux Container-Isolation für die Engines, während macOS/Windows Plattform-Sandboxing statt gewöhnlicher Container nutzen. Das ist für die Sicherheitsarchitektur relevant.
Modell-Artefakte sind Supply-Chain-Eingaben wie Software-Abhängigkeiten. Registry-Provenance, Modellquelle, Lizenz und Runtime Flags vor Produktion prüfen.
| Bedarf | Passender |
|---|---|
| Schneller lokaler Chat/Coding für Einzelanwender | Ollama |
| Modell-Lifecycle mit Compose/Registries | Docker Model Runner |
| Linux High-Throughput Safetensors | DMR + vLLM |
| Bildgenerierung im Docker-Workflow | DMR + Diffusers (Linux/NVIDIA) |
Vor Änderungen in Produktion Kontext, Backup und Rückfallplan prüfen. Bei DNS, TLS, Recovery, Docker oder WordPress nicht mehrere Variablen gleichzeitig ändern, da sonst die Ursache schwerer zu isolieren ist.
Nein. Beide überschneiden sich bei lokaler Inference, setzen aber andere Ökosystem-/Deployment-Schwerpunkte.
Die aktuellen Windows-amd64-Anforderungen nennen NVIDIA; AMD/ROCm ist für Docker Engine unter Linux dokumentiert.
Nein. Größerer Kontext benötigt mehr Speicher und kann Durchsatz reduzieren. Den kleinsten ausreichenden Kontext wählen.
Wenn das Problem in Hosting-, VPS-, Docker-, Cloudflare-, Windows- oder WordPress-Infrastruktur weiter besteht, können Sie mit Fehlerausgabe und Architektur einen technischen Supportfall erstellen.