Air-Gapped-LLM-Server: NVIDIA-Treiber, Container und Modelle offline installieren

Was ein Air-Gapped-LLM-Server braucht

Bei einem Air-Gapped-LLM-Server muss alles, was er sonst herunterladen würde, auf einem Staging-Host mit Netzanbindung geholt, dort geprüft, hinübergebracht und aus lokalen Kopien installiert werden. Dazu gehören der NVIDIA-Treiber und die Kernel-Header, gegen die er gebaut wird, die Container-Runtime, Container-Images, Modellgewichte, Python-Pakete und, nur für vGPU for Compute, Lizenzen. Versionen und Daten in diesem Artikel haben den Stand vom 10. Oktober 2026.

Quellen: Dokumentation von NVIDIA, Hugging Face, vLLM, pip und skopeo, gelesen am 10. Oktober 2026; die Daten sind die auf der jeweiligen Seite angegebenen.

Staging-Host, Transferweg und Prüfsummen

Der Staging-Host steht außerhalb der abgeschotteten Umgebung und hält die Spiegel: eine Kopie des Distributions-Repositorys, NVIDIAs Treiber- und Toolkit-Pakete, eine Image-Registry oder ein Image-Verzeichnis, die Modellablage und ein Wheel-Verzeichnis. Geben Sie ihm dasselbe Betriebssystem-Release und dieselbe Prozessorarchitektur wie den Servern drinnen, denn Pakete, Kernel-Header und Python-Wheels werden je Release und Architektur gebaut. Dateien gelangen über einen einzigen Weg hinüber, über Wechseldatenträger oder ein Einweg-Transfersystem, wie es Ihre Sicherheitsrichtlinie zulässt, und werden auf beiden Seiten geprüft.

1. Laden Sie jede Komponente auf dem Staging-Host in einer exakten Version herunter: Treiberversion, Toolkit-Version, Image-Digest und Modell-Commit.
2. Prüfen Sie sie dort gegen das, was der Herausgeber bereitstellt: signierte Metadaten für Pakete aus einem Netzwerk-Repository, hf cache verify für Gewichte von Hugging Face.
3. Schreiben Sie ein Manifest mit dem SHA-256-Wert jeder Datei, die hinübergeht.
4. Kopieren Sie die Dateien und das Manifest auf das Transfermedium.
5. Prüfen Sie drinnen jede Datei mit sha256sum -c gegen das Manifest, bevor sie in einen Spiegel gelangt.
6. Importieren Sie die Dateien in die internen Spiegel und installieren oder aktualisieren Sie die Server ausschließlich aus diesen Spiegeln.

Hugging Face beschreibt hf cache verify als Weg, „lokale Dateien gegen ihre Prüfsummen auf dem Hub zu validieren“. Der Befehl braucht den Hub und läuft deshalb auf dem Staging-Host. Bei einer Abweichung gibt er eine Liste der Dateien aus und endet mit einem Status ungleich null, eine fehlende Datei erzeugt aber nur eine Warnung, sofern Sie nicht --fail-on-missing-files hinzufügen. Bewahren Sie jedes Manifest auf, denn es hält fest, welche Versionen wann nach drinnen gelangt sind, und eine Wiederherstellung braucht dieselben Aufzeichnungen, wie unser Artikel zum Backup eines KI-Servers erklärt.

NVIDIA-Treiber unter Ubuntu offline installieren

NVIDIAs Treiberinstallationsanleitung, aktualisiert am 23. September 2026 und geschrieben für den Zweig 615, nennt für Ubuntu zwei Methoden: das Einbinden eines lokalen Repositorys und das Einbinden eines Netzwerk-Repositorys. Die folgenden Schritte gelten nur für Ubuntu; Red Hat Enterprise Linux, SUSE, Debian und andere Distributionen haben eigene Seiten in derselben Anleitung. Das Repository kommt als ein Debian-Paket, dessen Name mit nvidia-driver-local-repo- beginnt und mit Distribution, Treiberversion und Architektur weitergeht. Die Anleitung installiert es mit dpkg -i, führt apt update aus und registriert den mitgelieferten GPG-Schlüssel, den sie „ephemeral“ nennt, indem sie dessen Keyring-Datei nach /usr/share/keyrings/ kopiert; apt install nvidia-open installiert danach die offenen Kernelmodule. Da der Schlüssel im Paket selbst steckt, notieren Sie den SHA-256-Wert des Pakets auf dem Staging-Host, wenn Sie es bei NVIDIA herunterladen.

Die Kernel-Header kommen nicht aus diesem Paket. Im Vorbereitungsschritt der Anleitung werden sie für den laufenden Kernel mit apt install linux-headers-$(uname -r) aus dem Repository der Distribution installiert, das auch DKMS liefert, das Framework, mit dem das Paket nvidia-dkms-open die Module baut. Der interne Spiegel muss deshalb die Header für jeden Kernel enthalten, den Ihre Server booten. Installieren Sie das Pinning-Paket nvidia-driver-pinning-<branch> vor dem Treiber; NVIDIA schreibt, es schlage vor, „das Pinning-Paket vor der Installation des Treibers zu installieren“. Ab dem Zweig 590 tragen die Ubuntu-Paketnamen den Zweig nicht mehr, sodass ein Server ohne Pinning auf jeden neueren Zweig wechselt, den Sie später in den Spiegel importieren. Ob R580 oder R595 laufen sollte, behandelt unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen.

Auf KI-Servern, die wir bauen, installieren wir auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime, sodass der Server einsatzbereit für Ihr Team ankommt. Nennen Sie uns Distribution, Kernel und Treiberzweig im Formular unten.

Container Toolkit, Images und Python-Pakete

Die Installationsanleitung des NVIDIA Container Toolkit vom 18. September 2026 hat keinen Abschnitt zum Offline-Betrieb. Sie pinnt vier Pakete auf eine Version, zu diesem Datum 1.20.1-1: nvidia-container-toolkit, nvidia-container-toolkit-base, libnvidia-container-tools und libnvidia-container1. Holen Sie alle vier auf dem Staging-Host aus NVIDIAs Repository und halten Sie sie drinnen auf einer gemeinsamen Version. Die Anleitung nennt den NVIDIA-Treiber als Voraussetzung, also kommt der Treiber zuerst.

Images kommen in eine Registry innerhalb der abgeschotteten Umgebung. Der Befehl skopeo sync kopiert Images zwischen Registrys und lokalen Verzeichnissen, was sein Handbuch als „nützlich beim Synchronisieren eines lokalen Spiegels einer Container-Registry oder zum Befüllen von Registrys, die in Air-Gapped-Umgebungen laufen“ beschreibt. Seine Option --all kopiert jedes Image einer Multi-Architektur-Liste statt nur des Images für die aktuelle Plattform, und --preserve-digests lässt die Kopie fehlschlagen, wenn ein Digest nicht erhalten werden kann. Deployen Sie per Digest statt per Tag; unser Artikel zum Absichern eines GPU-Servers erklärt, warum Images nur aus einer Registry kommen sollten, die Sie kontrollieren.

Ein Serving-Container wie der von vLLM, auf Docker Hub als vllm/vllm-openai veröffentlicht, bringt seine Python-Pakete im Image mit. Python, das direkt auf dem Host installiert ist, braucht stattdessen ein Wheel-Verzeichnis. Das pip-Benutzerhandbuch, Version 26.2.1, beschreibt die Installation „nur aus lokalen Paketen, ohne Datenverkehr zu PyPI“ in zwei Schritten: pip download mit --destination-directory DIR und der Requirements-Datei auf dem Staging-Host, dann drinnen pip install mit --no-index und --find-links=DIR.

GPU Operator in einem abgeschotteten Kubernetes-Cluster

NVIDIAs Air-Gapped-Anleitung für den GPU Operator, aktualisiert am 23. September 2026 für v26.7.1, behandelt vier Fälle, von einem HTTP-Proxy mit vollem Internetzugang bis „Full Air-Gapped (w/o HTTP Proxy)“. Der vollständig abgeschottete Fall braucht innerhalb der Umgebung eine lokale Image-Registry und ein lokales Paket-Repository; NVIDIA ergänzt, dass Cluster, die Precompiled Driver Containers ausführen können, das Paket-Repository nicht brauchen. Die Images werden auf der verbundenen Seite gezogen, für die lokale Registry getaggt und dorthin gepusht, das Chart wird mit helm fetch als Archiv geholt, und values.yaml setzt das Repository-Feld jeder Komponente auf die lokale Registry.

Das Paket-Repository gibt es, weil der Treiber-Container des Operators nach NVIDIAs Worten „erfordert, dass bestimmte Pakete verfügbar sind“. NVIDIA nennt apt-mirror zum Kopieren dieser Pakete, und die Repository-Liste kommt in eine ConfigMap im Namespace des Operators, referenziert über driver.repoConfig.configMapName. Kürzer ist der Weg, den Treiber wie oben beschrieben aus dem lokalen Repository auf den Hosts zu installieren und driver.enabled=false zu setzen. Laut der Getting-Started-Anleitung „verhindert“ diese Einstellung, „dass der Operator den GPU-Treiber auf irgendeinem Knoten im Cluster installiert“. Die Air-Gapped-Anleitung geht auf diesen Fall nicht ein; nach unserer Lesart braucht dann nichts im Cluster das Paket-Repository. Unser Artikel zu einer privaten LLM-Plattform auf Kubernetes beschreibt die Schichten oberhalb des Operators.

Modellgewichte offline: Hugging Face, vLLM und NIM

Laden Sie die Gewichte auf dem Staging-Host mit hf download und --revision in einem festen Commit herunter und ergänzen Sie --local-dir, wenn Sie ein einfaches Verzeichnis statt des Hugging-Face-Caches wollen. Prüfen Sie sie mit hf cache verify, nehmen Sie sie ins Manifest auf und kopieren Sie sie drinnen in die Modellablage. Setzen Sie auf dem Server HF_HUB_OFFLINE=1. Laut der Dokumentation von Hugging Face werden mit dieser Variablen „keine HTTP-Aufrufe an den Hugging Face Hub abgesetzt“; es werden nur zwischengespeicherte Dateien verwendet, und fehlt eine Datei im Cache, löst die Bibliothek einen Fehler aus, statt sie herunterzuladen.

vLLM akzeptiert ein Verzeichnis als Modell, denn sein Argument --model ist „Name oder Pfad des zu verwendenden Hugging-Face-Modells“. Richten Sie es auf die Modellablage und setzen Sie --served-model-name, damit Clients weiter denselben Namen aufrufen, wenn eine neue Revision unter einem neuen Pfad ankommt. Lassen Sie --trust-remote-code ausgeschaltet, sofern das Modell es nicht verlangt, denn als vertrauenswürdig eingestufter Code aus einem Modell-Repository läuft auf dem Server.

NVIDIA NIM hat ein eigenes Verfahren. Seine Air-Gap-Anleitung, aktualisiert am 6. Oktober 2026, teilt die Arbeit in eine Phase mit Netzanbindung, in der download-to-cache oder create-model-store die Modelldateien vorbereitet, und eine Air-Gapped-Phase, in der der isolierte Host sie einbindet und den NIM mit NIM_MODEL_PROFILE auf die Profil-ID gesetzt startet oder mit NIM_MODEL_PATH, das auf den Model Store zeigt. NVIDIA schreibt: „Setzen Sie in der Air-Gapped-Phase weder NGC_API_KEY noch HF_TOKEN.“ Unter Kubernetes muss jedes Image, auf das das Helm-Chart des NIM verweist, in einer Registry liegen, die der Cluster erreicht. Modellprofile und Plattenplatz behandelt unser Artikel zu den Anforderungen von NVIDIA NIM an GPUs und Treiber.

Unsere Leistung Private AI/ML stellt offene und kommerzielle Modelle on-premise mit vLLM, Ollama oder NVIDIA AI Enterprise bereit. Beschreiben Sie die geplanten Modelle und wie Dateien in Ihr Netz gelangen im Formular unten.

Lizenzen ohne Internet: AI Enterprise und der DLS

Auf Bare Metal und in Containern ist kein Lizenzserver beteiligt. NVIDIAs Lizenzierungsanleitung, aktualisiert am 2. September 2026, hält fest, dass „NVIDIA-AI-Enterprise-Software mit oder ohne gültige Verbindung zu einem Lizenzserver läuft“ und dass das NVIDIA License System nur für Treiber von vGPU for Compute erforderlich ist. Die Lizenzbedingungen, zum Beispiel für NIM in der Produktion, gelten trotzdem.

Virtuelle Maschinen mit Compute-Profilen der C-Serie brauchen eine Lizenz, und zwei Methoden funktionieren ohne Internet. Eine Instanz des Delegated License Service (DLS) wird im eigenen Haus betrieben. NVIDIAs Anleitung zum License System, Version 3.6.1 vom 29. Juni 2026, sagt, dass Sie, weil eine DLS-Instanz vollständig vom NVIDIA Licensing Portal getrennt ist, „Lizenzen aus dem NVIDIA Licensing Portal herunterladen und manuell auf die Instanz hochladen müssen“. Für einen Client ohne Netzwerkverbindung beschreibt dieselbe Anleitung die knotengebundene Lizenzierung, mit der ein solcher Client „eine knotengebundene Lizenz für die NVIDIA-vGPU-Software aus einer lokal installierten Datei beziehen kann“, unterstützt seit vGPU-Software 15.0. Wie Lizenzen je GPU gezählt werden, steht in unserem Leitfaden zur Lizenzierung von NVIDIA AI Enterprise.

Updates und Sicherheitspatches auf einem getrennten Server

Auf einem Server ohne Internetzugang nimmt jede Korrektur den Weg über den Staging-Host und braucht einen Zeitplan. NVIDIA gibt einem Production Branch „vierteljährliche (oder bedarfsweise) Bugfix- und Sicherheits-Releases für 1 Jahr“ und einem Long Term Support Branch dasselbe für 3 Jahre, so die Seite zum Treiberlebenszyklus vom 9. September 2026. NVIDIAs Produktsicherheitsteam veröffentlicht seine Bulletins auf GitHub in den Formaten Markdown, CSAF und CVE und parallel dazu auf seiner Website Product Security. NVIDIA rät Kunden, Benachrichtigungen zu abonnieren, und wer den Staging-Host betreibt, sollte sie lesen.

NVIDIA-Seite Product Security und Seite zum Treiberlebenszyklus, gelesen am 10. Oktober 2026; die übrigen Zeilen nennen, wo die Maintainer der jeweiligen Komponente Änderungen veröffentlichen.

Importieren Sie einen neuen Kernel zusammen mit seinen Headern. Behalten Sie das vorherige Treiber-Repository, die Image-Digests und die Modellrevision in den Spiegeln, bis der neue Stand auf einem Testknoten gelaufen ist, damit ein Rollback keinen neuen Transfer braucht. Aktualisieren Sie Treiber, Toolkit und Images als einen getesteten Satz, denn die Images erwarten eine CUDA-Version, die der Treiber unterstützt.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit der RTX PRO 6000 Server Edition, der H200 NVL, der L40S oder der L4, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. NVIDIA-AI-Enterprise- und vGPU-Lizenzen kommen auf dieselbe Rechnung. Modelle, Serving und die Plattform darauf sind unsere Leistung Private AI/ML, umgesetzt von unserem Engineering-Partner Vixen.UNO, mit Support unter einem vereinbarten SLA.

FAQ