How To Deploy NVIDIA Triton Inference Server on GCP
Eine Schritt-für-Schritt-Anleitung für die Bereitstellung von NVIDIA Triton Inference Server auf Google Cloud mit Debian und einer T4-GPU, inklusive Treibern, Storage, Container-Toolkit und Inferenz-Validierung.
Wir bauen KI-Systeme, die komplexe Finanz- und Buchhaltungsdokumente für KMU verarbeiten. Einige dieser Workloads verwenden mehrere Deep-Learning-Modelle für OCR, Klassifikation und semantisches Verständnis, weshalb Inferenzgeschwindigkeit und Reproduzierbarkeit wichtig sind.
Im Rahmen dieser Arbeit haben wir NVIDIA Triton Inference Server auf einer Google-Cloud-VM mit Debian und T4-GPU getestet. Diese Anleitung beschreibt das verwendete Setup Schritt für Schritt und erklärt, warum die einzelnen Entscheidungen für Stabilität, Performance und Wiederholbarkeit relevant sind.
GPU und Betriebssystem prüfen
Zu Beginn sollte überprüft werden, ob die VM die NVIDIA-Hardware korrekt sieht und welches Betriebssystem tatsächlich läuft:
lspci | grep -i nvidia
cat /etc/os-release | grep PRETTY_NAME
Damit erhält man direkt zwei wichtige Signale:
- die T4-GPU ist für die VM sichtbar
- die Debian-Version ist klar, bevor Kernel-Header und Treiber installiert werden
Auf GCP bevorzuge ich den cloud-optimierten Kernel, weil er in der Praxis besser mit GPU-Treibern zusammenspielt:
sudo apt install -y linux-image-cloud-amd64 linux-headers-cloud-amd64
sudo init 6
Nach dem Neustart ist die Maschine bereit für die Treiberinstallation auf einer stabilen Kernel-Basis.
NVIDIA-Treiber mit expliziter Version installieren
Für Inferenz-Workloads ist Version-Pinning meist besser als ein generisches Paket-Install. So lässt sich dieselbe Umgebung einfacher über Entwicklung, Test und Produktion hinweg reproduzieren.
curl -O https://storage.googleapis.com/nvidia-drivers-us-public/tesla/550.90.12/NVIDIA-Linux-x86_64-550.90.12.run
chmod +x NVIDIA-Linux-x86_64-550.90.12.run
sudo ./NVIDIA-Linux-x86_64-550.90.12.run --silent
Der Schalter --silent ist besonders nützlich, wenn das Setup automatisiert für Image-Builds oder wiederholtes Provisioning verwendet werden soll.
Separaten Storage für Modelle und Laufzeitdaten mounten
Model-Repositories, Logs und Zwischenartefakte wachsen oft schnell. Statt das Root-Volume der VM zu überladen, ist es meist sauberer und günstiger, eine separate Persistent Disk anzubinden.
Das hat mehrere Vorteile:
- Storage kann unabhängig von der VM vergrößert werden
- die Disk kann getrennt oder ersetzt werden, ohne die ganze Instanz neu aufzubauen
- Modelldaten bleiben bei einer Neuerstellung der VM klarer erhalten
Ein einfaches Setup-Muster sieht so aus:
sudo mkfs.ext4 /dev/sdb
sudo mkdir /mnt/data
sudo mount /dev/sdb /mnt/data
sudo rsync -av /home/ /mnt/data/home/
sudo rsync -av /var/lib/ /mnt/data/var_lib/
Anschließend werden persistente Mounts in /etc/fstab hinterlegt:
/dev/sdb /mnt/data ext4 defaults 0 0
/mnt/data/home /home none bind 0 0
/mnt/data/var_lib /var/lib none bind 0 0
Dieses Layout ist besonders hilfreich, wenn Model-Repositories oder Datensätze unabhängig vom Boot-Volume wachsen sollen.
NVIDIA Container Toolkit installieren
Triton läuft typischerweise in einem Container, daher benötigt Docker GPU-Zugriff über den aktuellen NVIDIA-Container-Toolkit-Stack statt über ältere nvidia-docker2-Muster.
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.17.8-1
sudo apt-get install -y \
nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \
libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
Den GPU-Zugriff innerhalb von Docker kann man anschließend so validieren:
sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi
Wenn die T4 dort korrekt erscheint, ist die Container-Laufzeit für GPU-Workloads bereit.
Triton mit expliziter Container-Version starten
Ich bevorzuge explizite Image-Tags statt gleitender Versionen, damit Upgrades bewusst und nachvollziehbar erfolgen.
docker pull nvcr.io/nvidia/tritonserver:25.09-py3
Danach kann der Server mit gemountetem Model-Repository gestartet werden:
docker run --gpus=1 --rm --shm-size=1g --ulimit memlock=-1 --ulimit stack=67108864 \
-p8000:8000 -p8001:8001 -p8002:8002 \
-v /home/user/server/docs/examples/model_repository:/models \
nvcr.io/nvidia/tritonserver:25.09-py3 tritonserver --model-repository=/models
Die wichtigsten Parameter dabei sind:
--shm-size=1gfür Frameworks, die mehr Shared Memory benötigen--ulimit memlock=-1, um Speicher-Locking-Probleme bei der Inferenz zu reduzieren--ulimit stack=67108864für tiefere Modell-Stacks- Ports
8000,8001und8002für REST, gRPC und Metrics
Sobald der Container läuft, sollte die Readiness geprüft werden:
curl -v localhost:8000/v2/health/ready
Inferenz mit dem Triton-SDK-Container testen
Für einen End-to-End-Test eignet sich das NVIDIA-SDK-Image, da es die Client-Tools direkt mitbringt.
docker pull nvcr.io/nvidia/tritonserver:25.09-py3-sdk
docker run -it --rm --net=host nvcr.io/nvidia/tritonserver:25.09-py3-sdk
Innerhalb dieses Containers kann man eine Beispielinferenz ausführen:
/workspace/install/bin/image_client -m inception_onnx -s INCEPTION /workspace/images/mug.jpg
python /workspace/install/python/image_client.py -m inception_onnx -s INCEPTION /workspace/images/mug.jpg
exit
Damit lässt sich die komplette Kette aus Serving-Layer, Modellzugriff und GPU-Runtime schnell validieren.
Erkenntnisse
Das Setup hat gut funktioniert, aber einige Punkte waren deutlich wichtiger als andere:
- Treiber- und Container-Versionen sollten für Reproduzierbarkeit fest gepinnt werden
- ein separates Volume für Model-Repositories und Laufzeitdaten vereinfacht Skalierung und Wartung
- das moderne NVIDIA Container Toolkit sollte älteren Runtime-Mustern vorgezogen werden
- Triton-Metriken auf Port
8002erleichtern die Anbindung an Prometheus und Grafana
Empfehlung
Wenn Triton für ernsthafte Experimente oder frühe Produktions-Workloads eingesetzt wird, reicht es nicht, den Container nur einmal erfolgreich zu starten. Entscheidend ist ein Setup, das sich reproduzierbar neu aufbauen, sauber beobachten und ohne Überraschungen skalieren lässt. Auf GCP bedeutet das in der Praxis meist: explizite Versionen, klare Storage-Trennung und eine GPU-Runtime-Konfiguration, die sich Schritt für Schritt verifizieren lässt.