Wie man LLM-Inferenz in einer isolierten Umgebung (Air-Gapped) ausführt

Kurze Antwort: Sie benötigen vier Dinge. Modellgewichte, die vor dem Start der Inferenz lokal vorhanden sind, einen Inferenzprozess, der für ausgehende Netzwerkzugriffe blockiert ist, einen selbst gehosteten Modellkatalog und keine Telemetrie in der Plattform selbst. Wenn Sie auch nur eines davon vergessen, haben Sie ein System, das sich meistens innerhalb Ihres Sicherheitsbereichs befindet, was nicht dasselbe ist.

Dieser Leitfaden deckt jeden dieser Punkte ab und befasst sich anschließend mit dem Teil, der normalerweise übersprungen wird: wie man überprüft, ob wirklich nichts nach außen dringt.

Was „Air-Gapped“ tatsächlich erfordert

Die meisten Teams kümmern sich um den offensichtlichen Teil. Die Inferenz läuft auf Ihrer Hardware, Prompts gehen an einen lokalen Endpunkt, Antworten kommen lokal zurück. Erledigt.

Dann greift trotzdem irgendetwas nach außen. Die üblichen Verdächtigen, in der ungefähren Reihenfolge, wie oft sie die Leute überraschen:

Beschaffung der Modellgewichte. Die Gewichte müssen irgendwie auf die Maschine gelangen. Die Frage ist, welche Komponente sie wann abruft. Wenn die Inferenz-Engine einen Tokenizer oder einen Shard zur Ladezeit abruft, haben Sie eine ausgehende Verbindung innerhalb Ihres Bereitstellungspfads, die durch einen Cache-Miss ausgelöst wird, mit dem niemand gerechnet hat. Wenn ein Provisionierungsschritt sie einmalig vor der Bereitstellung abruft, haben Sie einen eingegrenzten Vorgang, den Sie prüfen und dann abschalten können. Derselbe Download, andere Architektur, ganz anderes Risiko.

Modellkatalog-Abfragen. Die Verwaltungsebene fragt einen Remote-Dienst ab, welche Modelle existieren, was ihre Spezifikationen sind und welche Treiber-Strings zu verwenden sind. Dabei handelt es sich eher um Metadaten als um Ihre Daten, was dazu führt, dass man dies leicht übersieht, obwohl es sich dennoch um einen Netzwerkaufruf aus einem Netzwerk handelt, das eigentlich keine machen sollte.

Telemetrie und Analysen. Nutzungs-Pings, Absturzberichte, Lizenzprüfungen, Update-Prüfungen. Standardverhalten von Anbietern, häufig undokumentiert, gelegentlich standardmäßig aktiviert.

Tool- und Retrieval-Integrationen. Websuche, Abrufen von Seiten, externe API-Aufrufe innerhalb einer Agentenschleife. Diese benötigen per Definition Internetzugang. Die Frage ist, ob sie standardmäßig deaktiviert sind oder erst später entdeckt werden.

Eine Air-Gapped-Bereitstellung ist eine, bei der Sie alle vier Punkte bewusst angegangen sind, und nicht eine, bei der die Inferenz zufällig lokal ausgeführt wird.

Schritt 1: Entscheiden Sie, wo die Gewichtebeschaffung stattfindet

Zwei Muster funktionieren. Wählen Sie eines aus, bevor Sie mit dem Aufbau beginnen.

Das strikte Muster. Laden Sie die Gewichte auf einer verbundenen Maschine herunter, überprüfen Sie die Prüfsummen, übertragen Sie sie in die Umgebung und platzieren Sie sie dort, wo die Engine sie erwartet. Nichts innerhalb der Umgebung kontaktiert jemals einen Modell-Hub. Das ist es, was ein echter Air Gap bedeutet, und es ist die richtige Antwort für geheime, militärische und einige stark regulierte Bereitstellungen.

Das praktische Muster. Erlauben Sie einer einzelnen Komponente auf einem bewussten Bereitstellungspfad, Gewichte von Hugging Face abzurufen. Alles andere bleibt blockiert. Die meisten Teams, die von „Air-Gapped“ sprechen, wollen genau das. Jedes Modell und jede Quantisierung manuell bereitzustellen, ist ein echter betrieblicher Aufwand, und das Gegenteil zu behaupten bedeutet nur, dass man nie damit anfängt.

In jedem Fall darf die Serving-Engine niemals selbst Daten abrufen. Für vLLM und alles andere, was auf den Hugging-Face-Bibliotheken aufbaut, bedeutet das HF_HUB_OFFLINE=1. Ohne diese Einstellung führt eine fehlende Tokenizer-Datei zu einer ausgehenden Anfrage anstelle einer klaren Fehlermeldung. Sie wollen die klare Fehlermeldung. Ein Fehler zeigt Ihnen, dass Ihre Bereitstellung unvollständig war. Ein lautloser, erfolgreicher Download sagt Ihnen nichts und macht den eigentlichen Zweck zunichte.

In Xinity läuft vLLM standardmäßig im Offline-Modus. Die Gewichtebeschaffung liegt vollständig außerhalb der Engine: Die Verwaltungsebene prüft, ob das Modell bereits lokal vorhanden ist, und reiht einen Download nur dann in die Warteschlange ein, wenn dies nicht der Fall ist. Der Serving-Prozess hat überhaupt keinen Abrufpfad, und die einzige Komponente, die Hugging Face erreichen kann, ist ein Provisionierungsschritt, den Sie überprüfen, planen, auf ein Wartungsfenster beschränken oder ganz blockieren können, sobald Ihre Modelle bereitgestellt sind.

Das ist der entscheidende Unterschied, und es geht nicht um Pull vs. Vorabbereitstellung. Es geht darum, ob der Abruf innerhalb oder außerhalb des Serving-Prozesses stattfindet. Ein Tool, das ein Modell zur Laufzeit aus einer Registry auflöst, führt eine ausgehende Abhängigkeit in Ihren Inferenzpfad ein, und Sie können diese nicht entfernen, ohne auf den Komfort zu verzichten. Ein separater Provisionierungsschritt kann gekappt werden, ohne die Engine zu berühren.

Schritt 2: Blockieren Sie den ausgehenden Datenverkehr auf Ebene des Inferenzprozesses, nicht nur an der Firewall

Perimeter-Firewall-Regeln sind notwendig, aber nicht ausreichend, da sie von einem anderen Team in einem anderen Änderungszyklus verwaltet werden als die Inferenzplattform. Eine Regel, die aus einem anderen Grund gelockert wird, öffnet den Pfad im Hintergrund wieder.

Führen Sie den Inferenzprozess in einem Containernetzwerk ohne ausgehende Route aus. Der Prozess kann das Internet dann unabhängig von den Freigaben des Perimeters nicht erreichen, und die Garantie liegt direkt beim Workload und nicht drei Teams weiter entfernt.

Dies ist Defense-in-Depth im klassischen Sinne: Perimeter-Regeln sind die äußere Schicht, das Containernetzwerk ist die innere Schicht, und Sie wollen die innere Schicht, weil sie im Fehlerfall geschlossen bleibt (fail-closed).

Schritt 3: Hosten Sie den Modellkatalog selbst

Die Verwaltungsebene muss wissen, welche Modelle verfügbar sind, wie hoch deren Speicherbedarf ist, welche Quantisierungsoptionen es gibt und wie die Treiberkonfiguration aussieht. Dieser Katalog wird häufig von einem vom Anbieter gehosteten Endpunkt abgerufen.

Hosten Sie ihn selbst. Im Fall von Xinity ist dies der Info Server, ein zustandsloser Dienst, der einen lokalen YAML-Katalog liest. Verweisen Sie die Plattform auf Ihre eigene Instanz, und die Katalogabfragen bleiben intern. Wenn kein selbst gehosteter Info Server konfiguriert ist, weicht das Dashboard auf einen von Xinity gehosteten Metadaten-Endpunkt aus.

Dieses Fallback-Verhalten ist der Punkt, den Sie bei jeder zu bewertenden Plattform prüfen müssen, und die Frage dazu ist konkret: Was macht dieses System, wenn eine Komponente nicht konfiguriert ist? Ein lautloses Ausweichen auf einen Anbieter-Endpunkt ist ein üblicher und sinnvoller Standard für mehr Komfort – und in einer Air-Gapped-Bereitstellung ist es genau das Verhalten, das Sie abschalten müssen. Fragen Sie nach der Liste der Endpunkte, die die Plattform kontaktieren kann, und unter welchen Bedingungen. Ein Anbieter, der diese Liste nicht vorlegen kann, hat sich über Ihre Bereitstellung keine Gedanken gemacht.

Schritt 4: Bestätigen Sie, dass keine obligatorische Telemetrie vorhanden ist

Es gibt einen echten Unterschied zwischen einer Plattform mit Telemetrie, die Sie deaktivieren können, und einer Plattform, die im Kernpfad überhaupt keine besitzt.

Ersteres erfordert, dass Sie einem Konfigurations-Flag vertrauen und dieses nach jedem Upgrade neu überprüfen. Letzteres erfordert kein Vertrauen, da es nichts abzuschalten gibt.

Fragen Sie, ob Inferenzanfragen, Antworten, Modellgewichte und GPU-Telemetrie standardmäßig lokal verbleiben und ob für den Kernbetrieb ein externer Aufruf erforderlich ist. Fragen Sie dann, welche ausgehenden Aufrufe als Opt-in-Funktionen existieren, denn ein System ohne optionale Integrationen ist ein System ohne Websuche oder Retrieval-Tools – und diese möchten Sie möglicherweise in einer anderen Bereitstellung nutzen, selbst wenn dies hier nicht der Fall ist. Open Source hilft hier: Sie können den Code lesen, anstatt sich auf das Datenblatt zu verlassen.

Schritt 5: Authentifizierung intern halten

Den Inferenzpfad abzuriegeln (Air-Gapping) und sich dann gegenüber einem Cloud-Identitätsanbieter zu authentifizieren, ist eine häufige Inkonsistenz.

Praktikable Optionen innerhalb des Sicherheitsbereichs: OIDC gegen Ihren internen Identitätsanbieter, Passkeys mittels WebAuthn oder FIDO2 mit Hardware-Schlüsseln oder Plattform-Authentifikatoren sowie TOTP-Zwei-Faktor-Authentifizierung mit Backup-Codes. Alle funktionieren ohne externe Aufrufe. Stellen Sie sicher, dass die Domänenverifizierung, falls die Plattform diese nutzt, im Rahmen des Logins keine DNS-Abfrage gegen einen öffentlichen Resolver durchführt.

Schritt 6: Überprüfen und nach Upgrades erneut überprüfen

Dies ist der Schritt, der eine bloße Behauptung von einer echten Kontrolle unterscheidet, und fast niemand dokumentiert ihn.

Erfassen Sie den Datenverkehr an der Grenze. Führen Sie tcpdump oder ein entsprechendes Tool auf dem Inferenz-Host und dem Control-Plane-Host während eines vollständigen Durchlaufs aus: Kaltstart, Laden des Modells, Inferenz, Modellwechsel, Dashboard-Nutzung, ein gezielter Fehler. Analysieren Sie jeden ausgehenden Verbindungsversuch. Auch blockierte Versuche zeigen Ihnen, was die Software tun wollte, und das sind genau die Informationen, die Sie benötigen.

Testen Sie beide Schichten separat. Löschen Sie eine Tokenizer-Datei und bestätigen Sie, dass die Engine einen Fehler ausgibt, anstatt Daten abzurufen. Prüfen Sie dann, wie die Schicht über der Engine damit umgeht. Denn eine Verwaltungsebene, die fehlende Gewichte durch Herunterladen repariert, tut zwar ihren Job, aber Sie müssen wissen, dass dies passiert ist, anstatt anzunehmen, dass die Engine einfach still geblieben ist. Stoppen Sie den lokalen Katalogdienst und bestätigen Sie, dass das Dashboard einen Fehler anzeigt, anstatt auf ein Fallback auszuweichen. Fordern Sie ein Modell an, das nicht bereitgestellt ist. Der fehlerfreie Pfad zeigt niemals ein Fallback. Nur der fehlerhafte Pfad tut dies.

DNS prüfen. Abfrage-Logs auf Ihrem internen Resolver zeigen Suchen nach externen Hostnamen, selbst wenn die Verbindungen selbst fehlschlagen. Dies ist oft der schnellste Weg, um eine Komponente zu finden, von der Ihnen niemand erzählt hat.

Nach jedem Upgrade erneut ausführen. Neue Versionen bringen neue Funktionen, und Funktionen bringen neue Endpunkte. Was auch immer Sie für Version 1.2 überprüft haben, gilt nicht als verifiziert für Version 1.4. Machen Sie dies zu einem Teil der Upgrade-Checkliste und nicht zu einem einmaligen Abnahmetest.

Checkliste

• Muster zur Gewichtebeschaffung bewusst gewählt: manuelle Bereitstellung oder ein eingegrenzter Provisionierungs-Abruf

• Prüfsummen bei jedem in die Umgebung eingehenden Gewichtesatz überprüft

• Offline-Modus in der Serving-Engine erzwungen und nach Upgrades erneut bestätigt

• Kein Abrufpfad innerhalb des Inferenzprozesses selbst

• Inferenzprozess in einem Netzwerk ohne ausgehende Route

• Modellkatalog selbst gehostet und konfiguriert, sodass kein Fallback auf einen Anbieter-Endpunkt erfolgt

• Keine Telemetrie für den Kernbetrieb erforderlich

• Optionale ausgehende Integrationen explizit deaktiviert

• Authentifizierung wird intern aufgelöst

• Paketerfassung und DNS-Protokolle bei Kaltstart, Inferenz, Modellwechsel und Fehler überprüft

• Überprüfung als Teil des Upgrade-Prozesses wiederholt

Xinity Runtime ist Open Source unter Apache 2.0. Für die Bereitstellung von Inferenzen ist kein ausgehender Aufruf erforderlich. Anfragen, Antworten, Labels, Modellgewichte und GPU-Telemetrie verbleiben standardmäßig in Ihrer Infrastruktur, und jede optionale ausgehende Integration ist ein Opt-in. Die Gewichtebeschaffung ist der einzige ausgehende Pfad in einer Standardbereitstellung: Sie läuft in der Verwaltungsebene statt in der Inferenz-Engine, sie bringt öffentliche Modellgewichte hinein, anstatt Ihre Daten nach außen zu senden, und Sie können sie durch eine manuelle Bereitstellung ersetzen, wenn Ihre Richtlinien einen strikten Air Gap erfordern. Sie können den Code lesen, anstatt sich auf unser Wort zu verlassen.

[Architektur-Whitepaper lesen →]