Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Multi-GPU

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Tensor-Parallelismus über mehrere GPUs für ein Modell, GPU-Pinning per UUID, NUMA- und Interconnect-Aspekte. Validiert in der Referenzkonfiguration 4 × H100 SXM 80 GB, in der zwei H100 als tensor-paralleles Paar (TP=2) das Sprachmodell bedienen.

Wann Tensor-Parallelismus

Wenn das Modell mit dem gewünschten Kontext und der gewünschten Parallelität nicht auf eine GPU passt – oder wenn zwei GPUs mehr Durchsatz liefern sollen als eine. Tensor-Parallelismus (TP) verteilt die Schichten eines Modells auf mehrere GPUs, die bei jeder Generierung Daten austauschen. Er poolt keinen Speicher: Zwei 80-GB-GPUs verhalten sich nicht wie ein 160-GB-Gerät; jede hält ihren Anteil an Gewichten plus KV-Cache.

Beispiele aus den LLM-Empfehlungen: GPT-OSS 120B MXFP4 mit TP=4 auf 4 × H100 für 128k Kontext, TP=2 für 32–64k; Llama 3.3 70B FP8 mit TP=2 oder TP=4; GPT-OSS 120B AWQ braucht auf 4 × L40S alle vier GPUs.

Einschränkungen

• TP muss die Attention-Heads gleichmäßig teilen. GPT-OSS 120B (64 Heads) erlaubt TP=1, 2, 4, 8 – nicht 3. Prüfen Sie num_attention_heads des Modells.
• GPT-OSS 120B: Tensor-, nicht Datenparallelismus. Datenparallelismus erzeugt fehlerhafte Ausgabe.
• Mehr TP = mehr Interconnect-Verkehr. Auf PCIe ohne NVLink sinkt der Nutzen; H100 SXM mit NVLink (900 GB/s) ist dafür gebaut, Workstation-Karten wie die RTX PRO 6000 nicht.
• Alle GPUs eines TP-Paars müssen gleich sein (Modell, VRAM, Firmware).

Konfiguration

Gebündelte Inferenz mit zwei GPUs:

inference:
  resources:
    requests: {cpu: 8000m, memory: 128Gi, nvidia.com/gpu: 2}
    limits:   {cpu: 16000m, memory: 256Gi, nvidia.com/gpu: 2}
  env:
    NUM_GPUS: "2"                 # Tensor-Parallelismus = Anzahl GPUs
    MODEL_ID: "openai/gpt-oss-120b"
    MAX_INPUT_TOKENS: "64000"
    SHM_SIZE: "64gb"
  nodeSelector:
    nvidia.com/gpu: "true"
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"

Requests und Limits müssen übereinstimmen. SHM_SIZE großzügig – TP nutzt Shared Memory für den Austausch; auf dem Host /dev/shm entsprechend groß (64 GB in der geprüften Konfiguration).

Das richtige GPU-Paar wählen

Kubernetes weist nvidia.com/gpu: 2 irgendwelche zwei freien GPUs zu. In einem Server mit mehreren GPUs müssen Sie sicherstellen, dass das TP-Paar den schnellsten Peer-Pfad hat und die Service-GPUs unberührt bleiben:

1. Topologie erfassen:

   nvidia-smi -L                 # UUIDs
   nvidia-smi topo -m            # NV# = NVLink, PIX/PXB/PHB = PCIe-Nähe, SYS = über CPU-Sockel
   

   Wählen Sie das Paar mit NVLink (NV*) oder der engsten PCIe-Beziehung; vermeiden Sie Paare über NUMA-Knoten hinweg (SYS).
2. Service-GPUs aus dem Pool nehmen: Auf MIG-GPUs bietet der Knoten nur MIG-Ressourcen an, keine nvidia.com/gpu – die Inferenz kann sie nicht bekommen. Bei einer dedizierten Service-GPU ohne MIG sorgen Sie über Knoten-Labels/Device-Auswahl dafür, dass die Inferenz sie nicht belegt.
3. Peer-Kommunikation testen, bevor basebox deployt wird: Peer-to-Peer- und NCCL-Prüfungen (etwa nccl-tests) zwischen den gewählten GPUs.
4. NUMA ausrichten: Inferenz-Pod auf den CPU-Sockel pinnen, an dem die GPUs hängen (Topology Manager / CPU-Pinning), wenn der Server mehrere NUMA-Knoten hat.
5. Festhalten: UUIDs, PCI-Adressen, NUMA-Knoten, Topologie im Manifest. Indexnummern ändern sich nach Neustarts oder Treiber-Updates.

Was die 4 × H100 vormacht

GPU	Modus	Workload
GPU 0, GPU 1	Komplett	LLM-Inferenz, TP-Shards 0 und 1
GPU 2	2 × MIG 3g.40gb	GPU-RAG, Dokumentextraktion
GPU 3	2 × MIG 3g.40gb	OCR, Sprache-zu-Text

Knoten bietet nvidia.com/gpu: 2 und nvidia.com/mig-3g.40gb: 4. Deployment-Reihenfolge, Prüfungen und Abnahme: 4 × H100 SXM.

Prüfen

kubectl -n basebox describe pod -l app.kubernetes.io/name=inference | grep -A3 "nvidia.com/gpu"
kubectl -n basebox exec -it <inference-pod> -- nvidia-smi        # zwei GPUs sichtbar
kubectl -n basebox logs -l app.kubernetes.io/name=inference | grep -iE "tensor|parallel|nccl"

Dann eine lange Generierung auslösen und beobachten, dass beide GPUs Last zeigen (nvidia-smi dmon). Startet die Inferenz mit Speicher- oder Collective-Fehlern nicht, stimmt meist TP-Zahl, Head-Teilung oder Peer-Pfad nicht.

Häufige Fehlerbilder

Symptom	Ursache	Lösung
Inferenz startet nicht, „attention heads not divisible"	TP teilt die Heads nicht	TP auf 1, 2, 4, 8 (modellabhängig)
NCCL-Timeouts, Collective-Fehler	Peer-Pfad langsam/blockiert, IOMMU, ACS	nvidia-smi topo -m; NCCL-Tests; BIOS/Kernel-Parameter nach NVIDIA-Doku
Nur eine GPU zeigt Last	NUM_GPUS ≠ Requests, oder Runtime ignoriert TP	Werte angleichen; Runtime-Logs
Deutlich langsamer als erwartet	PCIe statt NVLink, Paar über NUMA-Grenze	Paar neu wählen
Nach Neustart anderes Paar	Indexnummern statt UUID	Zuordnung über stabile Identität

Nächster Schritt: Dedizierte Service-GPU