d3 lokal betreiben: Entscheidungsmodelle mit Ollama 0.40.11 in Docker

Mit Ollama 0.40.11 ist am 25. Oktober 2026 die Modellfamilie d3 erschienen. Sie stammt aus dem Projekt vLLM Semantic Router und trifft Entscheidungen statt Texte zu schreiben: Aus Text, JSON-Daten oder einem Bild wird eine Kategorie, eine Ja-Nein-Wahrscheinlichkeit oder eine Bewertung auf einer Skala. Damit lassen sich Tickets, Formulare oder Fotos lokal vorsortieren, ohne dass Daten das Haus verlassen. Diese Anleitung zeigt Docker Compose ohne Grafikkarte, alle Fragetypen über /v1/systemone, ein Triage-Skript sowie Backup, Restore und Update. Befehle und Messwerte stammen aus einem eigenen Test auf einem Linux-Host mit 16 CPU-Threads und 14 GiB RAM.

Voraussetzungen

Für den Einstieg mit dem kleinsten Modell planen Sie ein:

• Linux-Server oder VM mit x86-64 oder ARM64, mindestens 4 CPU-Kerne, besser 8 oder mehr
• 8 GB RAM für d3:2b (im Test belegte der Container geladen 3,9 GiB), 16 GB für das 4B-Modell d3 mit 5,6 GB Download
• 15 GB freier Speicher für Modell und Backup
• optional eine GPU mit 8 GB VRAM oder mehr für schnelle Bildfragen oder das 9B-Modell (10 GB)
• Docker Engine mit Compose-Plugin, eingerichtet wie in unserer Grundlage für Docker Compose unter Linux
• curl und jq auf dem Rechner, der die Abfragen schickt

Welche Modellgröße zu welcher Hardware passt, erklärt allgemein unser Vergleich zu Ollama-Modellen, VRAM und Quantisierung.

Schritt 1: Was d3 und /v1/systemone leisten

d3 formuliert keine Antwort, sondern bewertet nur die Optionen, die Sie vorgeben. Laut Ollama-Dokumentation gibt es drei Fragetypen:

Typ	Kriterien	Ergebnis
choice	2 bis 26 benannte Optionen mit Beschreibung	wahrscheinlichste Option, Wahrscheinlichkeit je Option, confidence
noul	optional Beschreibungen für "false" und "true"	Wahrscheinlichkeit für „ja“ von 0 bis 1
score	2 bis 10 Stufen, von niedrig nach hoch	gewichteter Mittelwert der Stufen-Indizes ab 0

Mehrere Fragen passen in eine Anfrage. Die Familie umfasst d3:2b, d3 (4B, entspricht latest), d3:9b und d3:27b; die Modelle stehen unter Apache 2.0. Kontext: 4.096 Token, kein Video. Laut Readme sind die Wahrscheinlichkeiten Modellausgaben, keine garantierten Trefferquoten.

Verifizieren: Eine vorhandene Installation meldet ihre Version per ollama --version; unter 0.40.9 folgt in Schritt 6 das Update.

Schritt 2: Ollama 0.40.11 mit Docker Compose starten

Legen Sie einen Projektordner an, etwa /opt/ollama-d3, und speichern Sie darin die compose.yaml:

services:
  ollama:
    image: ollama/ollama:0.40.11
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama:/root/.ollama
    environment:
      OLLAMA_KEEP_ALIVE: "10m"
      OLLAMA_CONTEXT_LENGTH: "4096"

volumes:
  ollama:

Eckdatum	Wert
Image	ollama/ollama:0.40.11 (Docker Hub, für AMD-GPUs 0.40.11-rocm)
Port	11434/TCP, hier nur an 127.0.0.1 gebunden
Volume	ollama:/root/.ollama mit Modellen und Manifests
Env	OLLAMA_KEEP_ALIVE (Modell nach letzter Anfrage geladen halten), OLLAMA_CONTEXT_LENGTH

Der Port hängt bewusst nur an 127.0.0.1: Die Ollama-API hat keine eigene Anmeldung. OLLAMA_KEEP_ALIVE hält das Modell zehn statt fünf Minuten geladen. Starten Sie den Dienst:

cd /opt/ollama-d3
docker compose up -d
docker compose exec ollama ollama --version

ollama version is 0.40.11

Die GPU-Konfiguration mit NVIDIA Container Toolkit zeigt unsere Anleitung zu Ollama mit Open WebUI.

Verifizieren: docker compose ps zeigt den Dienst ollama als Up, und curl -s http://127.0.0.1:11434/api/version liefert 0.40.11.

Schritt 3: d3 laden und im Terminal ausprobieren

Laden Sie das 2B-Modell, die passende Wahl für CPU-Server:

docker compose exec ollama ollama pull d3:2b
docker compose exec ollama ollama show d3:2b

    parameters          2.4B
    quantization        Q8_0
    requires            0.40.9
  Capabilities
    decision
    vision

Die Zeile requires 0.40.9 ist die Mindestversion. Auf der Kommandozeile stellt --ask eine Frage, --choice gibt Optionen vor, --level eine Skala.

docker compose exec ollama ollama run d3:2b \
  "Der VPN-Zugang im Homeoffice bricht alle zehn Minuten ab." \
  --ask "Which team should handle this?" \
  --choice 'network=VPN, Wi-Fi and internet' \
  --choice 'account=Login and passwords' \
  --choice 'hardware=Broken devices' \
  --ask "How urgent is this?" \
  --level "Routine" --level "Soon" --level "Immediate"

Which team should handle this?  network    95%
How urgent is this?             Immediate  73%  1.6 / 2

Die Skala reicht von 0 bis 2. Fragen und Kriterien formulieren wir wie die offiziellen Beispiele auf Englisch, die Tickets bleiben deutsch.

Verifizieren: docker compose exec ollama ollama list zeigt d3:2b mit 3,2 GB, und der Testaufruf gibt je Frage eine Zeile mit Option und Prozentwert aus.

Schritt 4: Klassifizieren, Ja/Nein und Bewerten über /v1/systemone

Eine API-Anfrage enthält model, den Eingabetext in state und benannte Fragen in questions:

curl -s http://127.0.0.1:11434/v1/systemone \
  -H 'Content-Type: application/json' -d '{
  "model": "d3:2b",
  "state": "Seit heute früh können sich drei Mitarbeiter in der Buchhaltung nicht mehr am Rechnungsportal anmelden. Die Fehlermeldung lautet: Konto gesperrt. Die Monatsabrechnung muss bis 12 Uhr raus.",
  "questions": {
    "login_problem": {
      "type": "noul",
      "instructions": "Does the ticket describe a login or account access problem?",
      "criteria": {
        "false": "No login or account access problem",
        "true": "A login or account access problem is described"
      }
    }
  }
}'

{"model":"d3:2b","answers":{"login_problem":{"type":"noul","noul":0.9927657363714215}},"usage":{"input_tokens":144,"output_tokens":0}}

noul ist eine Zahl, kein Wahrheitswert. Zum selben Text lieferte eine choice-Frage nach dem zuständigen Team account mit 0,83 (Alternative billing 0,17), und eine score-Frage mit den drei Stufen Routine, Soon und Immediate den Wert 1,86, also nahe „Immediate“.

Strukturierte Daten: state darf ein JSON-Objekt sein, etwa {"ticket_id": 4711, "subject": "Doppelte Abbuchung", "body": "…"}; auf Felder verweisen Sie in den Fragen mit Backticks wie `body`.

Mit drei Fragen in einer Anfrage (Kriterien wie im Skript in Schritt 5) ordnete d3:2b ein solches Ticket zur doppelten Abbuchung mit 0,996 dem Team billing zu und bewertete die Dringlichkeit mit 1,63. Die Ja-Nein-Frage nach einer Erstattung kam dagegen nur auf 0,22, obwohl der Kunde ausdrücklich um Erstattung bittet. Schritt 5 zeigt, wie stark die Formulierung wirkt.

Bilder: Bilder gehen base64-kodiert als Liste im Feld images mit ("images": ["$(base64 -w0 bild.png)"]), URLs akzeptiert der Endpunkt nicht; state bleibt Pflicht.

Zwei selbst erzeugte Testbilder erkannte d3:2b sicher: roter Kreis mit 0,99, blaues Quadrat mit 0,999 als square.

Messung auf CPU (16 Threads), d3:2b	Dauer
erste Anfrage inklusive Laden des Modells	20,6 s
Einzelfrage noul, choice oder score, Modell geladen	2,2 bis 2,6 s
JSON-State mit drei Fragen	8,7 bis 9,6 s
Bild mit zwei Fragen	18,9 bis 19,1 s
Arbeitsspeicher des Containers, Modell geladen	3,9 GiB

Verifizieren: Jede Antwort hat HTTP 200, enthält unter answers für jeden Fragenamen ein Objekt mit passendem type, und docker compose exec ollama ollama ps zeigt d3:2b mit 100% CPU oder GPU-Anteil.

Schritt 5: Praxisbeispiel Ticket-Triage per Skript

Ein eigener Modellname entkoppelt Skripte von der Modellgröße: Später stellen Sie d3-ticket im Modelfile auf d3 um, ohne Skripte anzufassen.

FROM d3:2b
PARAMETER num_ctx 4096

docker compose cp Modelfile ollama:/tmp/Modelfile
docker compose exec ollama ollama create d3-ticket -f /tmp/Modelfile
docker compose exec ollama ollama list

NAME                ID              SIZE      MODIFIED
d3-ticket:latest    271e536ea9e1    3.2 GB    Less than a second ago
d3:2b               e1b3991aa480    3.2 GB    About a minute ago

triage.sh stellt pro Textdatei drei Fragen in einer Anfrage und schreibt eine CSV-Zeile:

#!/bin/bash
# triage.sh: Tickets aus einem Ordner per d3 einordnen, Ausgabe als CSV
# Aufruf: ./triage.sh tickets/ > triage.csv
set -euo pipefail
OLLAMA_URL="${OLLAMA_URL:-http://127.0.0.1:11434}"
MODEL="${MODEL:-d3-ticket}"

echo "datei;team;team_p;dringlichkeit;rueckerstattung_p"
for f in "$1"/*.txt; do
  jq -n --arg model "$MODEL" --rawfile state "$f" '{
    model: $model,
    state: $state,
    questions: {
      team: {type: "choice",
        instructions: "Which team should handle this ticket?",
        criteria: {billing: "Invoices, payments and refunds",
                   account: "Login, passwords and account access",
                   hardware: "Broken devices, printers and cabling",
                   network: "VPN, Wi-Fi and internet connectivity"}},
      urgency: {type: "score",
        instructions: "How urgently does this ticket need a response?",
        criteria: ["Routine: no time pressure",
                   "Soon: users are inconvenienced",
                   "Immediate: a business-critical deadline or service is at risk"]},
      refund: {type: "noul",
        instructions: "Is the customer requesting money back?",
        criteria: {"false": "No money back is requested",
                   "true": "The customer asks for money back"}}
    }}' |
  curl -sf "$OLLAMA_URL/v1/systemone" -H 'Content-Type: application/json' -d @- |
  jq -r --arg f "$(basename "$f")" '.answers as $a |
    [$f, $a.team.choice, ($a.team.probabilities[$a.team.choice]*100|round),
     ($a.urgency.score*100|round/100), ($a.refund.noul*100|round)] | join(";")'
done

chmod +x triage.sh
./triage.sh tickets > triage.csv
cat triage.csv

datei;team;team_p;dringlichkeit;rueckerstattung_p
1001.txt;account;82;1.87;3
1002.txt;billing;100;1.03;99
1003.txt;hardware;100;0.76;0
1004.txt;network;100;1.15;1

Alle vier Testtickets landeten beim passenden Team. Bei Ticket 1002 ergab die konkrete Frage „Is the customer requesting money back?“ 99 Prozent für eine Erstattung, die abstraktere Formulierung aus Schritt 4 nur 22 Prozent: Die Wortwahl wirkt stark. Vier Tickets dauerten auf der CPU rund 25 Sekunden.

Tickets unter einer Schwelle, etwa 80 Prozent, sollten bei einem Menschen landen.

Verifizieren: Pro Ticketdatei erscheint eine CSV-Zeile. Ist Ollama gestoppt, endet das Skript nach der Kopfzeile mit Exit-Code 7, statt leere Ergebnisse zu schreiben.

Schritt 6: Update von einer älteren Ollama-Version

Unter 0.40.8 scheiterte im Test schon der Download:

Error: model requires ollama version v0.40.9 or newer (current version is v0.40.8)

Eine Anfrage an /v1/systemone endet dann mit HTTP 404 und {"error":"model 'd3:2b' not found"}. Für das Update setzen Sie den Tag in der compose.yaml neu und erstellen den Container neu; das Volume bleibt erhalten:

sed -i 's#ollama/ollama:0.40.8#ollama/ollama:0.40.11#' compose.yaml
docker compose pull
docker compose up -d
docker compose exec ollama ollama --version

Der Container meldete danach sofort 0.40.11, der Download von d3:2b lief ohne Fehler durch; ein frischer Download dauerte im Test 139 Sekunden. Über neue Tags informiert Sie etwa Diun, siehe unsere Anleitung zu Watchtower-Nachfolgern.

Verifizieren: ollama --version im Container meldet 0.40.11, ollama pull d3:2b endet mit success, und vorhandene Modelle stehen weiter in ollama list.

Schritt 7: Modelle sichern und wiederherstellen

Neu laden kostet Gigabytes, und eigene Ableitungen wie d3-ticket wären weg. Sichern Sie das Volume bei gestopptem Dienst:

docker compose stop
docker run --rm -v ollama-d3_ollama:/data:ro -v "$PWD":/backup alpine \
  tar cf /backup/ollama-backup.tar -C /data .
docker compose start

Den Volume-Namen zeigt docker volume ls. Im Test war das Archiv mit beiden Modellen 3,1 GB groß und in 70 Sekunden geschrieben. Unter models/manifests enthält es d3/2b und d3-ticket/latest.

Nach einem simulierten Totalverlust mit docker compose down -v ist ollama list leer, und eine Anfrage an d3-ticket endet mit HTTP 404 model 'd3-ticket' not found. Die Wiederherstellung:

docker compose down -v
docker compose up --no-start
docker run --rm -v ollama-d3_ollama:/data -v "$PWD":/backup:ro alpine \
  tar xf /backup/ollama-backup.tar -C /data
docker compose up -d
docker compose exec ollama ollama list

NAME                ID              SIZE      MODIFIED
d3-ticket:latest    271e536ea9e1    3.2 GB    54 seconds ago
d3:2b               e1b3991aa480    3.2 GB    54 seconds ago

up --no-start legt das Volume mit Compose-Labels an. Das Entpacken dauerte 71 Sekunden. Die erste Anfrage an d3-ticket lieferte danach dieselben Werte wie vor dem Verlust, und der Netzwerkzähler des Containers stieg dabei nur um rund 2 kB: Es wurde nichts nachgeladen.

Verifizieren: Nach dem Restore stehen d3:2b und d3-ticket mit unveränderter ID in ollama list, und eine Anfrage an d3-ticket liefert HTTP 200 ohne vorherigen pull.

Troubleshooting

Meldung	Ursache und Lösung
model requires ollama version v0.40.9 or newer	Ollama zu alt. Image-Tag auf 0.40.11 setzen, docker compose pull und up -d.
HTTP 404 model 'd3:2b' not found	Modell nicht geladen oder Name vertippt. ollama list prüfen, ollama pull d3:2b.
HTTP 400 questions.x: "type" must be one of: choice, score, noul	Unbekannter Fragetyp, etwa yesno. Für Ja/Nein heißt der Typ noul.
HTTP 400 score criteria must be an array of 2–10 levels	score braucht eine Liste mit 2 bis 10 Stufen, kein Objekt und keine Einzelstufe.
erste Anfrage dauert 20 Sekunden	Modell wird geladen; OLLAMA_KEEP_ALIVE erhöhen.

Häufige Fragen

Brauche ich für d3 eine Grafikkarte?

Nein. Im Test lief d3:2b auf reiner CPU. Für Bildfragen und Modelle ab 9B ist eine GPU deutlich angenehmer.

Welche Modellgröße soll ich nehmen?

Der Herausgeber nennt für die Originalmodelle einen Text-Index von 38,9 (2B), 52,6 (4B), 55,8 (9B) und 66,3 (27B). Liegen Ihre Testfälle mit 2B daneben, stellen Sie das Modelfile auf das 4B-Modell um.

Funktioniert die neue Sprachausgabe im Container?

Nein, phonon und /v1/audio/speech gibt es laut Release Notes nur unter macOS.

Fazit

d3 beantwortet klar umrissene Entscheidungsfragen mit Wahrscheinlichkeiten, läuft schon als 2B-Variante brauchbar auf einem CPU-Server und passt mit wenigen Zeilen Bash in bestehende Abläufe. Die Grenzen: Ergebnisse hängen spürbar von der Frageformulierung ab, Bildfragen dauern ohne GPU rund 19 Sekunden. Nutzen Sie d3 als Vorsortierung mit Schwellwerten, sichern Sie das Volume und pinnen Sie den Tag. Für den Dauerbetrieb lohnt ein Blick auf Healthchecks und weitere Härtung von Compose-Stacks.

Weiterführende Anleitungen und Quellen

• Ollama und Open WebUI mit Docker: lokales LLM
• Ollama-Modelle auswählen: VRAM und Quantisierung
• vLLM 0.32 mit eigenem /v1/systemone-Endpunkt
• Ollama v0.40.11, Release Notes (GitHub)
• d3 in der Ollama-Bibliothek
• Ollama-Dokumentation: Decision
• Ollama-API-Referenz: POST /v1/systemone
• vLLM Semantic Router: Decision-Modelle auf Hugging Face