Egal ob ich später TensorRT-LLM, Ollama, vLLM oder ein anderes Container-basiertes Inferenz-Framework auf meinem Server laufen lassen will die Grundinstallation ist immer dieselbe: ein aktuelles Ubuntu, der passende NVIDIA-Treiber, Docker, und das NVIDIA Container Toolkit, damit Container überhaupt Zugriff auf die GPU bekommen.

In diesem Beitrag zeige ich dir mein eigenes Setup-Skript server_setup.sh, das diese Grundinstallation auf einem frischen Ubuntu 24.04 in einem Rutsch erledigt. Das Skript ist die Basis, auf die ich in allen meinen anderen Inferenz-Posts verlinke also einmal hier durchgearbeitet, und du hast die Plattform für jedes weitere KI-Projekt.

Was du brauchst

  • Einen Server oder eine Workstation mit einer NVIDIA-GPU
  • Frisch installiertes Ubuntu 24.04 LTS (Server- oder Desktop-Variante egal)
  • Internet-Anbindung (das Skript zieht mehrere GB an Paketen)
  • Mindestens 30 GB freien Speicher für die Basis-Installation (für Container-Images und Modelle später deutlich mehr)
  • Einen Nicht-Root-Benutzer mit sudo-Rechten

Was das Skript macht

Das Skript läuft in sechs klar getrennten Schritten:

  1. System-Update: alle vorhandenen Pakete auf den neuesten Stand bringen
  2. OpenSSH-Server: damit du den Server später headless betreiben kannst
  3. Basis-Pakete: curl, git, gnupg, Midnight Commander und ein paar Helfer
  4. NVIDIA CUDA Toolkit 13.1 + Treiber: die GPU-Schicht
  5. Docker: Container-Runtime aus dem offiziellen Docker-Repo
  6. NVIDIA Container Toolkit: die Brücke, damit Docker-Container auf die GPU zugreifen können

Am Ende ist ein Reboot fällig, dann ist der Server bereit für jeden Container-basierten Inferenz-Stack.

Warum diese Komponenten?

NVIDIA CUDA Toolkit auf dem Host obwohl wir Container nutzen?

Klingt erstmal widersprüchlich, weil Container-basierte Inferenz-Frameworks ihre eigene CUDA-Version im Image mitbringen. Trotzdem installiere ich das CUDA Toolkit auf dem Host. Zwei Gründe:

  • Erstens bringt das cuda-drivers-Paket den passenden NVIDIA-Treiber automatisch mit. Den brauchst du zwingend auf dem Host der Treiber-Userspace (libcuda.so) wird auch von Containern genutzt, weil GPUs nicht containerisierbar sind.
  • Zweitens ist es praktisch, das CUDA Toolkit nativ zur Hand zu haben für gelegentliche schnelle Tests mit nvcc, nvidia-smi und ähnlichen Tools, ohne extra einen Container hochzufahren.

Die Version CUDA 13.1 habe ich gewählt, weil sie zum Zeitpunkt der Skript-Erstellung die stabilste aktuelle Version war. Wenn du das Skript später ausführst, prüfe vorher kurz, ob es eine neuere Version gibt bei NVIDIA ändert sich das im Halbjahres-Rhythmus.

Docker aus dem offiziellen Repo, nicht aus Ubuntu

Ubuntu liefert in seinen Standard-Repos das Paket docker.io mit. Das funktioniert grundsätzlich, ist aber meist deutlich älter als das, was Docker selbst veröffentlicht. Wichtiger noch: Die offiziellen Pakete bringen Docker Compose als Plugins direkt mit, was bei docker.io nicht der Fall ist. Compose brauchst du quasi sofort, sobald du Multi-Container-Setups oder Persistenz mit Volumes machst.

NVIDIA Container Toolkit – die wichtigste Komponente

Das ist das Bindeglied, ohne das Docker-Container nichts mit deiner GPU anfangen können. Das Toolkit konfiguriert Docker so um, dass der Befehl docker run --gpus all ... tatsächlich funktioniert und der Container Zugriff auf die GPU-Devices und den NVIDIA-Treiber bekommt.

Ich pinne im Skript die Version auf 1.19.0-1. Das hat einen pragmatischen Hintergrund: Updates am NVIDIA Container Toolkit haben mir in der Vergangenheit gelegentlich Setups zerschossen, weil die API mit bestimmten Treiber-Versionen nicht mehr kompatibel war. Mit einer gepinnten Version bleibt das Setup reproduzierbar denn ich entscheide bewusst, wann ich update.

Das Skript holen und ausführen

Lade das Skript server_setup.sh aus meinem GitHub-Repository herunter:

Hier geht es zu dem Skript auf GitHub: tensorrt-llm-edge-prep-script

Speichere es auf dem frisch installierten Server. Ich lege immer einen Ordner scripte an der bei mir typischerweise im Home-Verzeichnis liegt:

Dann muss das Skript mit dem folgenden Befehl ausführbar gemacht werden.

Befehl: chmod +x server_setup.sh

Lies das Skript bitte einmal durch, bevor du es ausführst. Bei System-Setup-Skripten ist „ich weiß genau was passiert“ eine gute Gewohnheit. Mit dem jetzt folgenden Befehl führst Du das Skript aus.

Befehl: ./server_setup.sh

Wichtig: Nicht als root ausführen. Das Skript prüft das und bricht sonst ab. Es nutzt sudo, wo es Root-Rechte braucht, behält aber den normalen User-Kontext.

Je nach Internet-Verbindung dauert das ganze 5–15 Minuten. Am Ende erscheint die Abschluss-Meldung mit dem Hinweis auf den nötigen Reboot.

Reboot und Verifikation

Nach dem Skript ist ein Neustart Pflicht. Sowohl wegen des frisch installierten NVIDIA-Treibers als auch wegen der Docker-Gruppenmitgliedschaft (die wird erst bei einem neuen Login aktiv):

sudo reboot

Nach dem Reboot drei kurze Tests, ob alles sauber zusammenarbeitet:

Sind die GPU und der Treiber sichtbar?
Befehl: nvidia-smi
 Es sollte die gewohnte Sicht erscheinen mit deiner GPU, Treiber-Version, Speicherauslastung
NVIDIA SMI Screen

NVIDIA SMI Screen

Jetzt kommt der Test ob Docker auch ohen dem sudo Befehl funktioniert?
Befehl: docker run hello-world
 Du solltest jetzt eine Antwort wie z. B. "Hello from Docker!" als Begrüßung sehen. Es sollten keine keine Permission-Fehler auftauchen. Ist das Container Toolkit installiert? Die Prüfung erfolgt mit dem folgenden Befehl. Befehl: nvidia-ctk --version
 Es sollte jetzt in Versions-Output wie "NVIDIA Container Toolkit CLI version 1.19.0" erscheinen. Der jetzt wohl wichtigste Test kann der Container auf die GPU zugreifen? Befehl: docker run --rm --gpus all ubuntu:24.04 nvidia-smi
 Jetzt sollte auch hier wieder die selbe nvidia-smi-Tabelle wie auf dem Host zu sehen sein, nur eben aus dem Container heraus

Wenn alle vier Tests durchlaufen, hast du eine voll funktionsfähige GPU-Container-Plattform. Das ist die Grundlage, auf der jetzt jedes der gängigen Inferenz-Frameworks lauffähig ist.

Typische Stolpersteine

Zwei Probleme, die mir bei verschiedenen Installationen über die Jahre untergekommen sind:

1. Der Nouveau-Treiber blockiert den NVIDIA-Treiber.

Bei manchen Ubuntu-Installationen lädt der Kernel den Open-Source-Nouveau-Treiber automatisch, der dann den NVIDIA-Treiber blockiert. Symptom: nvidia-smi wirft nach dem Reboot „NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver“ aus. Eine mögliche Lösung konnte wie folgt aussehen:

Befehl: echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf

Befehl: echo "options nouveau modeset=0" | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf

Befehl: sudo update-initramfs -u

Befehl: sudo reboot

Dann sollte nach dem Neustart nvidia-smi funktionieren.

2. „docker permission denied“ trotz korrekter Installation. Du wurdest zwar zur Docker-Gruppe hinzugefügt, aber deine aktuelle Shell-Session weiß das noch nicht. Lösung: Ausloggen und wieder einloggen — oder einfach den ganzen Server rebooten, wie im Skript am Ende empfohlen.

Was nicht im Skript ist (und warum)

Bewusst nicht enthalten sind ein paar Dinge, die jeder Admin individuell entscheiden möchte:

  • Statische IP-Konfiguration: abhängig vom Heimnetz, lieber manuell über Netplan
  • Firewall-Regeln: kommt drauf an, was du später bedienst (HTTP, SSH-Tunnel, OpenAI-API)
  • Samba: hatte ich früher mal drin, aber für reine Inferenz-Server überflüssig

Wenn du diese Dinge brauchst, dann richte diese nach dem Neustart bitte selber ein. Das Skript bleibt damit schlank, reproduzierbar und auf den eigentlichen Zweck fokussiert: GPU + Container-Plattform fokusiert.

Wenn du Verbesserungen am Skript hast oder eine andere CUDA-/Toolkit-Version brauchst – Pull Request auf GitHub oder Kommentar hier, ich freue mich über Feedback.

 



Artikelübersicht - TensorRT-LLM auf der RTX A6000 Ada:

Ubuntu 24.04 Server für KI-Inferenz vorbereiten: CUDA, Docker, NVIDIA Container Toolkit
TensorRT-LLM auf der RTX A6000 Ada: Vorbereitung auf das Edge-LLM Ökosystem
TensorRT-LLM auf Ubuntu 24.04: Setup mit Docker und Helper-Skripten
TensorRT-LLM Pipeline: Persistente Engines bauen mit FP16 und FP8
TensorRT-LLM in Zahlen: FP16 vs. FP8 auf der RTX A6000 Ada