Ollama sucht bei ollama.com, vLLM 0.31 meldet sich beim Start: was in einem lokalen Stack wirklich lokal bleibt

/01Was Ollama und vLLM in den letzten Wochen geändert haben

Zwei Werkzeuge tragen den größten Teil der lokalen Inferenz im Mittelstand: Ollama auf Arbeitsplätzen und kleinen Servern, vLLM auf GPU-Servern. Beide haben seit Ende September Versionen veröffentlicht, die die Frage „Was läuft hier eigentlich lokal?" neu stellen.

Ollama. Die Websuche als Werkzeug für Modelle gibt es seit dem 24. September 2025 – so datiert der Blogeintrag, der die Funktion eingeführt hat. Seitdem ist sie ausgebaut worden: Version 0.35.1 vom 29. September 2026 hebt die Zahl der Suchen pro Antwort von drei auf zehn. Version 0.35.0 vom Vortag bringt „Decision Models" über einen neuen Endpunkt /v1/systemone. Parallel läuft die 0.40er-Reihe: 0.40.0 vom 25. September 2026 macht MLX zur Standard-Laufzeit auf Apple Silicon; 0.40.1 vom 7. Oktober fügt dem lokalen Server laut Änderungsliste einen Proxy für die „cloud usage and balance APIs" hinzu und entfernt den Kontoschritt aus dem CLI-Onboarding; 0.40.2 vom 8. Oktober führt eine Hintergrund-Aktualisierung bereits heruntergeladener Modelle beim ersten Start ein; 0.40.3 vom 11. Oktober setzt genau diese Hintergrund-Aktualisierung wieder aus. Vier Releases in zwei Wochen, drei davon mit Änderungen daran, was der lokale Prozess von sich aus tut.

vLLM. Version 0.31.0 vom 5. Oktober 2026 bündelt laut Release Notes 717 Commits von 307 Beitragenden. Für Betreiber relevant: vllm preload startet einen Daemon, der quantisierte Gewichte im GPU-Speicher hält, sodass ein Neustart der Engine ohne erneutes Laden auskommt; experimentell gibt es Snapshots einer initialisierten Engine per CRIU. spekulatives Dekodieren mit Draft-Modell läuft jetzt auf dem neuen Model Runner V2. Zwei Sicherheitsänderungen betreffen jeden, der multimodale Modelle serviert: Anfrageparameter mm_processor_kwargs und media_io_kwargs werden standardmäßig abgelehnt, es sei denn, der Server startet mit --trust-request-mm-kwargs – eine Konsequenz aus Lücken wie der im Artikel zu CVE-2026-22778 beschriebenen. Entfernt wurde tokenizer_mode="slow"; --enforce-eager schaltet jetzt auch das JIT-Kernel-Warmup ab.

Nichts davon ist ein Skandal. Es ist der normale Lauf zweier aktiver Projekte. Aber wer einen Stack als „lokal" beschafft hat, sollte nach diesen Wochen prüfen, ob er das noch ist.

/02Wer sucht, wenn Ollama sucht

Die Websuche in Ollama ist technisch kein lokales Werkzeug. Die Dokumentation ist eindeutig: Die Anfrage geht als POST https://ollama.com/api/web_search an Ollamas Server, ebenso web_fetch für das Laden einzelner Seiten. Voraussetzung ist ein kostenloses Ollama-Konto und ein API-Schlüssel von ollama.com/settings/keys, gesetzt als OLLAMA_API_KEY oder im Authorization-Header. Der Parameter max_results steht standardmäßig auf 5, höchstens 10. Ollama spricht von einem „großzügigen kostenlosen Kontingent"; höhere Limits gibt es über ein Cloud-Abonnement.

Das Modell läuft dabei weiter lokal. Was das Haus verlässt, ist die Suchanfrage – und die formuliert das Modell aus dem Gespräch heraus. Fragt ein Sachbearbeiter den Assistenten nach dem Lieferstatus für Kunde Müller und das Modell beschließt, dazu zu suchen, steht „Lieferstatus Müller GmbH" in einer Anfrage an ollama.com. Die Datenschutzerklärung von Ollama (Stand März 2026) beschreibt, dass Cloud-Inhalte „transient" verarbeitet und nicht über die Bearbeitung hinaus gespeichert werden; die FAQ sagt für lokale Nutzung: „We don't see your prompts or data when you run locally." Beides kann stimmen und ändert nichts an der Architektur: Ein Modell mit Werkzeugaufruf entscheidet selbst, wann es das Werkzeug zieht, und die Anfrage ist eine Ableitung aus dem Prompt.

Dazu kommen die Cloud-Modelle. Seit Ollama Modelle mit dem Suffix :cloud anbietet, die nicht heruntergeladen werden, sondern auf Ollamas Servern laufen, kann ein Nutzer mit einem Tippfehler im Modellnamen – gemma4:cloud statt gemma4 – die gesamte Konversation nach außen geben. Die Cloud-Dokumentation sagt zudem: Für zuletzt genutzte Cloud-Modelle zeigen die Nutzungseinstellungen „upcoming retirements"; heruntergeladene lokale Modelle seien davon nicht betroffen. Das ist der ganze Unterschied in einem Satz.

/03Inventar: was ein „lokaler" Stack nach außen meldet

Die Websuche ist der sichtbarste Fall, aber nicht der einzige. Die folgende Tabelle listet, was in einem typischen Stack aus Ollama, vLLM, Hugging-Face-Bibliotheken und einer Chat-Oberfläche Verbindungen nach außen aufbaut – mit der Quelle, aus der die Abschaltung hervorgeht.

Was in der Tabelle fehlt, ist genauso wichtig: die Werkzeuge, die Ihr Agent selbst aufruft. Ein MCP-Server, der „nur" einen Wechselkurs holt, telefoniert nach außen; ein RAG-Indexer, der URLs aus Dokumenten nachlädt, ebenfalls. Wie man diese Klasse über ein Gateway einfängt, steht im Artikel zur Egress-Kontrolle für MCP.

/04Egress-Inventur: ss, tcpdump, Proxy-Log

Die Tabelle sagt, was die Dokumentation verspricht. Was Ihr Server tut, sagt nur eine Messung. Drei Werkzeuge reichen, und sie sind auf jedem Linux-Server vorhanden oder in einer Minute installiert.

# 1) Momentaufnahme: welche Prozesse halten ausgehende HTTPS-Verbindungen?
ss -tnp state established '( dport = :443 )'

# 2) Mitschnitt über eine Stunde Betrieb: Ziele außerhalb des eigenen Netzes
sudo tcpdump -ni eth0 -l 'tcp port 443 and not net 10.0.0.0/8 and not net 192.168.0.0/16' \
  | awk '{print $5}' | sed 's/\.[0-9]*:$//' | sort | uniq -c | sort -rn | head -30

# 3) DNS verrät die Namen, auch wenn TLS den Inhalt verbirgt
sudo tcpdump -ni eth0 -l 'udp port 53' | grep -oE 'A\? [^ ]+' | sort | uniq -c | sort -rn | head -30

# 4) Wenn ein Proxy Pflicht ist: alles, was ihn umgeht, ist verdächtig
journalctl -u ollama --since "1 hour ago" | grep -iE 'ollama\.com|cloud|web_search'

Führen Sie die Messung in drei Zuständen durch: Leerlauf, normaler Betrieb mit echten Nutzern, und einmal gezielt nach ollama pull beziehungsweise einem Modellwechsel. Der Leerlauf zeigt Telemetrie und Update-Checks; der Betrieb zeigt Werkzeugaufrufe; der Modellwechsel zeigt Registry- und Hub-Zugriffe. Notieren Sie je Ziel den Prozess, der die Verbindung hält – ss -p liefert ihn – und ordnen Sie ihn einer Zeile der Tabelle zu. Was sich nicht zuordnen lässt, ist ein Fund.

Wer es dauerhaft will, schreibt die Regel in die Firewall statt in den Kalender. Mit nftables lässt sich der Benutzer ollama (der Standard-Dienstbenutzer des Linux-Installers) auf interne Ziele beschränken und jeder Versuch nach außen protokollieren:

sudo nft add table inet egress
sudo nft add chain inet egress out '{ type filter hook output priority 0; policy accept; }'
sudo nft add rule inet egress out meta skuid ollama ip daddr != 10.0.0.0/8 \
  tcp dport { 80, 443 } log prefix "ollama-egress " drop
sudo nft list chain inet egress out

Der Vorteil gegenüber dem Vertrauen in eine Umgebungsvariable: Die Regel gilt auch nach dem nächsten Update, das vielleicht eine neue Verbindung einführt – wie 0.40.1 den Nutzungs-Proxy. Die Protokollzeile sagt Ihnen dann, dass sich etwas geändert hat.

/05Ollama: Cloud und Websuche abschalten

Die Abschaltung ist dokumentiert und einfach. Die FAQ nennt zwei gleichwertige Wege; auf einem Server mit systemd gehört die Variable in die Dienstdefinition, nicht in die Shell eines Administrators.

# Weg 1: Umgebungsvariable im systemd-Dienst
sudo systemctl edit ollama.service
# im Editor:
[Service]
Environment="OLLAMA_NO_CLOUD=1"
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/srv/ollama/models"
Environment="HTTPS_PROXY=https://proxy.firma.local:3128"

sudo systemctl daemon-reload && sudo systemctl restart ollama
journalctl -u ollama -b | grep -i 'cloud disabled'      # erwartet: Ollama cloud disabled: true

# Weg 2: Konfigurationsdatei des Dienstbenutzers
sudo -u ollama tee /usr/share/ollama/.ollama/server.json <<'EOF'
{ "disable_ollama_cloud": true }
EOF

Drei Hinweise aus der Praxis. Erstens: OLLAMA_HOST bleibt auf 127.0.0.1, solange kein Reverse-Proxy mit Authentifizierung davorsteht; die FAQ beschreibt die Nginx-Variante. Ein offener Port 11434 ist seit den Vorfällen im LLMjacking-Artikel und der Lücke aus CVE-2026-7482 keine Nachlässigkeit mehr, sondern ein Angebot. Zweitens: Die FAQ warnt ausdrücklich davor, HTTP_PROXY zu setzen – Ollama lädt nur über HTTPS, und die Variable kann Client-Verbindungen zum Server stören. Drittens: Prüfen Sie nach der Abschaltung, dass kein Nutzer einen eigenen API-Schlüssel in seiner Shell hat; OLLAMA_API_KEY in einem Nutzerprofil reicht für direkte Aufrufe an ollama.com/api/web_search, am lokalen Server vorbei. Die nftables-Regel aus Abschnitt /04 fängt auch das.

/06vLLM 0.31 offline: Telemetrie, Hub, lokaler Modellpfad

vLLM hat keine Websuche und keine Cloud-Modelle; seine Außenverbindungen sind Nutzungsstatistik und Hugging-Face-Hub. Die Nutzungsstatistik sammelt laut Dokumentation Systemdaten – eine zufällige UUID, Anbieter, CPU-Zahl und -Typ, Arbeitsspeicher, Architektur, Plattform, GPU-Zahl, GPU-Typ und -Speicher, Modellarchitektur, vLLM-Version und Einstellungen wie Quantisierung und Tensor-Parallelität. Keine Prompts. Trotzdem gehört sie auf einem Server, der als lokal beschafft wurde, aus. Die Dokumentation nennt drei gleichwertige Wege.

# Gewichte einmalig und versioniert holen (auf einer Maschine mit Netz)
hf download Qwen/Qwen3-27B --revision <voller-commit-hash> --local-dir /models/qwen3-27b@2026-10
sha256sum /models/qwen3-27b@2026-10/*.safetensors > /models/qwen3-27b@2026-10/SHA256SUMS

# Serving ohne Netz: lokaler Pfad, Hub offline, keine Statistik
docker run -d --name vllm --gpus all -p 127.0.0.1:8000:8000 \
  -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
  -e HF_HUB_DISABLE_TELEMETRY=1 -e HF_HUB_DISABLE_UPDATE_CHECK=1 \
  -v /models:/models:ro \
  vllm/vllm-openai:v0.31.0 \
  --model /models/qwen3-27b@2026-10 --served-model-name assistent-lokal \
  --max-model-len 65536

# Gegenprobe: der Container darf nichts auflösen und nichts erreichen
docker exec vllm sh -c 'getent hosts huggingface.co || echo "kein DNS: gut"'

Der entscheidende Schalter ist --model /pfad statt --model Qwen/Qwen3-27B. Mit einem Repo-Namen versucht die Hub-Bibliothek einen Versions-Check, auch wenn alle Dateien im Cache liegen; HF_HUB_OFFLINE=1 unterbindet den Aufruf, aber erst der Pfad macht den Server unabhängig vom Cache-Layout. DO_NOT_TRACK=1 wirkt laut Hugging-Face-Dokumentation auf das gesamte Python-Ökosystem (transformers, diffusers, gradio) und laut vLLM-Dokumentation auch auf vLLM – eine Variable für beides.

Mit 0.31 kommt vllm preload dazu. Der Daemon hält quantisierte Gewichte im GPU-Speicher, sodass ein Engine-Neustart nach einer Konfigurationsänderung nicht wieder Minuten lädt. In einem Air-Gap ist das besonders nützlich, weil dort jeder Neustart ohne Hub-Zugriff auskommen muss und die Ladezeit großer Modelle von der lokalen Platte kommt. Wie der Grundaufbau eines OpenAI-kompatiblen Servers aussieht, steht in den Vertiefungen OpenAI-API selbst hosten und Llama auf vLLM: Setup in 40 Minuten; dieser Abschnitt ergänzt nur die Offline-Schalter.

/07Air-Gap: Gewichte vorab ziehen, prüfen, einspielen

Ein Air-Gap-Betrieb ist kein Serverzustand, sondern ein Prozess: Alles, was der Server braucht, kommt über eine kontrollierte Transferstation hinein, und nichts geht hinaus. Für einen Inferenzstack sind das vier Artefaktklassen – Modellgewichte, Container-Images, Python-Pakete und Konfiguration –, und für jede gilt dasselbe Muster: auf der Netzseite holen, Prüfsumme bilden, übertragen, Prüfsumme vergleichen, einspielen.

# Netzseite: Artefakte sammeln
hf download Qwen/Qwen3-27B --revision <voller-commit-hash> --local-dir transfer/qwen3-27b@2026-10
docker pull vllm/vllm-openai:v0.31.0 && docker save vllm/vllm-openai:v0.31.0 | zstd -o transfer/vllm-0.31.0.tar.zst
ollama pull qwen3.8 && tar -C /usr/share/ollama/.ollama -cf transfer/ollama-models.tar models
(cd transfer && find . -type f -not -name SHA256SUMS -exec sha256sum {} + > SHA256SUMS)

# Air-Gap-Seite: prüfen, dann einspielen
(cd /mnt/transfer && sha256sum --check SHA256SUMS --quiet) && echo "Transfer unversehrt"
zstd -dc /mnt/transfer/vllm-0.31.0.tar.zst | docker load
tar -C /usr/share/ollama/.ollama -xf /mnt/transfer/ollama-models.tar
systemctl restart ollama

Zwei Details, die in der Praxis Ärger machen. Erstens: Ollama speichert Modelle als Manifeste plus Blobs; der Tarball muss beide enthalten, sonst zeigt ollama list das Modell, aber ollama run scheitert. Zweitens: Die Hintergrund-Aktualisierung aus 0.40.2 wandelt Modelle beim ersten Start um und legt Sicherungskopien an – in 0.40.3 ist sie ausgesetzt. In einem Air-Gap mit knappem Plattenplatz prüfen Sie vor dem Versionssprung, ob die Funktion wieder aktiv ist, und planen den doppelten Speicherbedarf ein. Die Release Notes sind in diesem Fall Teil des Change-Managements, nicht Lektüre.

Für die Hardware heißt Air-Gap vor allem: kein Nachladen. Was nicht auf der Platte liegt, läuft nicht. Ein ki·spezial System mit 192 GB VRAM im Vollausbau trägt ein 27B-Modell in 4-Bit-Quantisierung neben einem Embedding-Modell, einem Reranker und einem zweiten Kandidatenmodell für Tests; eine 24-GB-Karte trägt eines davon. Welche Modellstände in welchem Transferzyklus eingespielt werden, gehört in einen Plan, der vor dem ersten Air-Gap-Tag steht. Wie ein RAG-System in dieser Umgebung aussieht, haben wir im Artikel zum air-gapped Agentic RAG beschrieben.

/08Websuche behalten, aber selbst suchen: SearXNG statt Hersteller-API – und wann der Air-Gap die falsche Wahl ist

Ehrlich: Die Websuche ist für viele Anwendungsfälle nützlich. Ein Assistent, der zu einer Norm die aktuelle Fassung findet, zu einem Lieferanten die Insolvenzmeldung oder zu einer Fehlermeldung den Herstellereintrag, ist mehr wert als einer, der 2024 stehen geblieben ist. Die Entscheidung lautet deshalb nicht „Websuche ja oder nein", sondern „wer sucht". Ein eigener Metasuchdienst beantwortet die Frage so, dass die Anfrage zwar das Haus verlässt – zu den Suchmaschinen –, aber nicht an einen KI-Anbieter geht, nicht an ein Konto gebunden ist und keinen API-Schlüssel braucht, der in Nutzerprofilen landet.

SearXNG ist das verbreitete Open-Source-Werkzeug dafür. Die Installation per Container ist in der Projektdokumentation beschrieben; für Open WebUI genügen danach vier Umgebungsvariablen. Wichtig ist das JSON-Format in der SearXNG-Konfiguration – ohne es antwortet SearXNG der Oberfläche mit 403.

# SearXNG starten (Dokumentation: docker run)
docker run --name searxng -d -p 127.0.0.1:8888:8080 \
  -v "./config/:/etc/searxng/" -v "./data/:/var/cache/searxng/" \
  docker.io/searxng/searxng:latest

# config/settings.yml – JSON für die Oberfläche freischalten
search:
  formats:
    - html
    - json

# Open WebUI – Suche auf den eigenen Dienst lenken
ENABLE_WEB_SEARCH=True
WEB_SEARCH_ENGINE=searxng
WEB_SEARCH_RESULT_COUNT=3
SEARXNG_QUERY_URL=http://searxng:8080/search

Was der eigene Suchdienst nicht löst: Die Suchmaschinen dahinter sehen die Anfragen weiterhin, nur ohne Ihr Konto und gemischt mit denen aller anderen Nutzer der Instanz. Und das Modell entscheidet nach wie vor selbst, wann es sucht und was es in die Anfrage schreibt. Wer das nicht will, schaltet die Suche für die betroffenen Rollen oder Datenklassen ab – nicht für alle.

Womit die Gegenseite benannt ist: Ein vollständiger Air-Gap ist für die meisten Mittelständler die falsche Wahl. Er kostet Aktualität (kein Nachladen, keine Suche), Betriebsaufwand (jeder Modellwechsel ist ein Transfer) und Komfort (keine Cloud-Modelle als Rückfallebene für Spitzenlasten). Er lohnt sich dort, wo Daten das Netz nicht berühren dürfen – Konstruktionsdaten mit Geheimhaltungsvereinbarung, Patientendaten, Verschlusssachen, KRITIS-Steuerungsnetze. Für ein Haus, das Angebote schreibt und Rechnungen prüft, reicht ein Stack, dessen Außenverbindungen bekannt, auf eine Allowlist beschränkt und protokolliert sind. Das ist nicht „fast Air-Gap", sondern ein anderes, meist passenderes Schutzziel.

/09Entscheidung nach Datenklasse

Die Frage „Was bleibt lokal?" hat keine Antwort für den ganzen Betrieb, nur je Datenklasse. Die meisten Mittelständler kommen mit drei Klassen aus.

Klasse A – öffentlich oder intern ohne Personenbezug (Produktdokumentation, Normen, allgemeine Recherche): Websuche erlaubt, über den eigenen SearXNG. Cloud-Modelle als Rückfallebene zulässig, wenn das Gateway sie nur für diese Klasse freigibt. Telemetrie trotzdem aus – nicht aus Risikogründen, sondern weil ein Server, der grundlos telefoniert, die Inventur verwässert.

Klasse B – vertraulich (Kundendaten, Angebote, Personal, Verträge): Inferenz ausschließlich lokal, Websuche aus oder auf eine Allowlist interner Quellen beschränkt, OLLAMA_NO_CLOUD=1 gesetzt und per Firewall erzwungen, vLLM mit lokalem Pfad und Offline-Schaltern. Modellwechsel über gepinnte Versionen. Außenverbindungen: Proxy für Updates in einem Wartungsfenster, sonst nichts. Das ist für die Mehrheit der Anwendungsfälle der richtige Zustand, und er kostet keinen Komfort, den die Nutzer vermissen würden.

Klasse C – geheim oder regulatorisch isoliert: Air-Gap mit Transferstation nach Abschnitt /07, eigener Transferzyklus für Modelle und Images, kein Proxy, keine Suche. Nur für die Systeme, die diese Daten verarbeiten – nicht für das ganze Haus.

Die Zuordnung treffen nicht die Administratoren, sondern die Fachbereiche mit dem Datenschutzbeauftragten; die Administratoren setzen sie um und messen sie nach – mit den Befehlen aus Abschnitt /04, nach jedem Release. Ollama hat in zwei Wochen vier Versionen veröffentlicht, vLLM eine mit 717 Commits. Die Inventur vom September gilt im Oktober nicht mehr automatisch.

Das ist keine Formsache: Ein Stack, der „lokal" heißt, aber eine Websuche mit Hersteller-Konto, Cloud-Modelle per Tippfehler und Telemetrie beim Start mitbringt, ist in der Datenschutz-Folgenabschätzung etwas anderes als das, was der Fachbereich bestellt hat. Die Differenz steht nirgends im Angebot – sie steht in ss -tnp.