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

// installation

Referenzkonfiguration: 4 × NVIDIA H100 SXM 80 GB

Gilt für

Produkt: Server · Betrieb: durch den Kunden oder durch basebox · Zielgruppe: Platform Operator · Hardware: 4 × NVIDIA H100 SXM 80 GB · Architektur: Einzelner Knoten

Status: Validated

basebox hat genau diese Konfiguration geprüft (siehe den gemessenen Referenz-Workload unten). Eine Referenzkonfiguration dokumentiert ein konkretes, bekanntes Setup; sie bedeutet nicht, dass basebox diese Hardware benötigt – die GPUs dienen den Service-Modellen und der Inferenz. Gemeinsame Installationsschritte werden hier nicht wiederholt; sie stehen im Bare-Metal-Installationsleitfaden. Status-Begriffe: Referenzkonfigurationen.

Konfigurationsübersicht

Diese Konfiguration beschreibt ein Einzelknoten-basebox-Deployment auf einem kundeneigenen Kubernetes-Server mit vier NVIDIA H100 SXM 80 GB GPUs. Zwei komplette GPUs bedienen das Sprachmodell als tensor-paralleles Paar. Die anderen beiden GPUs sind in vier MIG-Instanzen für Retrieval, Dokumentextraktion, OCR und Sprache-zu-Text aufgeteilt.

Das Layout hält die Sprachmodell-Inferenz auf kompletten GPUs und gibt jedem Hilfs-Workload eine eigene GPU-Instanz. Modelle, Dokumente und verarbeitete Ausgaben bleiben im Normalbetrieb auf Ihrer Infrastruktur.

Diese Konfiguration gilt ausdrücklich für NVIDIA H100 SXM 80 GB. H100-PCIe- und H100-NVL-Systeme haben andere Formfaktoren, Interconnects, Leistungsbudgets und Topologieanforderungen und benötigen eigene Konfigurationen.

Auf einen Blick

Element	Diese Konfiguration
Physische GPUs	4 x NVIDIA H100 SXM 80 GB in einem Server
Inferenz-Zuteilung	2 komplette GPUs, Tensor-Parallelismus 2
Service-Zuteilung	2 GPUs im MIG-Modus, je 2 x `3g.40gb`
Kubernetes-GPU-Ressourcen	`nvidia.com/gpu: 2` und `nvidia.com/mig-3g.40gb: 4`
GPU-Workloads	Inferenz, GPU-RAG, Extraktion, OCR, Sprache-zu-Text
Kubernetes-Topologie	Ein einzelner Knoten mit allen vier GPUs
Speicher	Persistenter Speicher für Modellartefakte, Dokumente und Plattformdaten
Artefaktzugang	Registry- und Modell-Repository-Zugang oder freigegebene interne Mirrors

MIG (Multi-Instance GPU) teilt eine physische GPU in isolierte Rechen- und Speicherinstanzen. NVIDIA dokumentiert maximal zwei 3g.40gb-Instanzen auf einer H100 80 GB GPU, was dieser Konfiguration vier Service-Instanzen auf zwei physischen GPUs gibt.

Veröffentlichte GPU-Kennwerte

Die folgenden Zahlen sind NVIDIA-Gerätespezifikationen. Sie beschreiben jede H100-SXM-GPU und sind keine basebox-Leistungs- oder Kapazitätsergebnisse.

Kennwert	H100 SXM
GPU-Speicher	80 GB
Speicherbandbreite	3,35 TB/s
NVLink-Bandbreite	900 GB/s
PCIe-Schnittstelle	Gen5, 128 GB/s
Maximale thermische Verlustleistung	Bis 700 W, konfigurierbar
Maximale `3g.40gb`-MIG-Instanzen je GPU	2

Quellen: NVIDIA H100 specifications und NVIDIA supported MIG profiles.

GPU-Speicher bleibt lokal auf jeder physischen GPU. Zwei 80-GB-Inferenz-GPUs verhalten sich nicht wie ein transparent geteiltes 160-GB-Gerät. Gewähltes Modell, Präzision, Kontextlänge, KV-Cache-Bedarf, Runtime-Konfiguration, Tensor-Parallel- Implementierung und GPU-Interconnect werden gemeinsam qualifiziert.

Hardware-Layout

Physische GPU	Modus	Workload
H100 GPU 0	Komplette GPU	LLM-Inferenz, Tensor-Parallel-Shard 0
H100 GPU 1	Komplette GPU	LLM-Inferenz, Tensor-Parallel-Shard 1
H100 GPU 2	2 x `3g.40gb` MIG	GPU-RAG und Dokumentextraktion
H100 GPU 3	2 x `3g.40gb` MIG	OCR und Sprache-zu-Text

Die GPU-Nummern bezeichnen Rollen nur zur Veranschaulichung. Das Deployment bindet Rollen über stabile GPU-UUIDs und PCI-Adressen, weil sich Geräteindizes über Neustarts und Treiber-Updates ändern können.

graph TB
  subgraph SERVER["Kundenserver – 4 x NVIDIA H100 SXM 80 GB"]
    subgraph NODE["Einzelner Kubernetes-Knoten"]
      subgraph INF["Inferenzpaar – komplette GPUs"]
        G0["H100 GPU 0<br/>Tensor-Parallel-Shard 0"]
        G1["H100 GPU 1<br/>Tensor-Parallel-Shard 1"]
      end
      subgraph SVC2["Service-GPU 2 – MIG-Modus"]
        M20["3g.40gb – GPU-RAG"]
        M21["3g.40gb – Extraktion"]
      end
      subgraph SVC3["Service-GPU 3 – MIG-Modus"]
        M30["3g.40gb – OCR"]
        M31["3g.40gb – Sprache-zu-Text"]
      end
    end
  end
  G0 <-->|"Tensor-Parallel-Verkehr"| G1

  style G0 fill:#dbeafe,stroke:#1e40af,color:#111827
  style G1 fill:#dbeafe,stroke:#1e40af,color:#111827
  style M20 fill:#dcfce7,stroke:#166534,color:#111827
  style M21 fill:#dcfce7,stroke:#166534,color:#111827
  style M30 fill:#dcfce7,stroke:#166534,color:#111827
  style M31 fill:#dcfce7,stroke:#166534,color:#111827

Workload-Zuteilung

GPU-Zuteilung	basebox-Workload	Zweck
2 komplette H100 GPUs	Sprachmodell-Inferenz	Tensor-paralleles Model Serving
Service-GPU 2, Instanz 1	GPU-RAG	Embedding, Retrieval und Reranking
Service-GPU 2, Instanz 2	Dokumentextraktion	Wandelt hochgeladene Dateien in maschinenlesbaren Text
Service-GPU 3, Instanz 1	OCR	Liest Text aus Bildern und gescannten Seiten
Service-GPU 3, Instanz 2	Sprache-zu-Text	Transkribiert Audioaufnahmen

MIG isoliert GPU-Rechenleistung und -Speicher zwischen den Service-Instanzen. Die Service-Workloads können die zwei für die Inferenz reservierten kompletten GPUs nicht verbrauchen. Alle Workloads teilen weiterhin Host-CPU, Arbeitsspeicher, Speicher und Netzwerk. Dienste auf derselben physischen GPU teilen sich außerdem deren Leistungs- und Wärmebudget.

Inferenz-Interconnect und NUMA

Tensor-Parallelismus tauscht bei jeder Generierung Daten zwischen den Inferenz-Shards aus. Die zwei Inferenz-GPUs müssen deshalb anhand der tatsächlichen Servertopologie gewählt werden, nicht anhand ihrer angezeigten Indexnummern.

Stabile GPU-UUID, PCI-Adresse und NUMA-Knoten jeder GPU festhalten.
Den Peer-Pfad mit nvidia-smi topo -m bestätigen.
Peer-to-Peer- und NCCL-Kommunikationsprüfungen vor dem basebox-Deployment ausführen.
Das Inferenzpaar mit seiner CPU-, Speicher- und Netzwerk-Lokalität ausrichten, wenn der Server mehrere NUMA-Knoten hat.
Unterstützte GPU-Bestückung, NVLink- oder NVSwitch-Topologie, Leistung und Kühlung mit dem Serverhersteller bestätigen.

Liefermodell

Die Konfiguration kombiniert das basebox-Helm-Release mit den GPU-Modell-Endpunkten, die die Dokument- und Audioverarbeitung nutzen.

Workload	Bereitstellung
Inferenz	basebox-Inferenz-Chart mit zwei GPU-Ressourcen und Tensor-Parallelismus 2
GPU-RAG	basebox-`ragsrv`-Chart, konfiguriert für eine MIG-Ressource
Dokumentextraktion	basebox-`ragsrv-support`-Chart, konfiguriert für eine MIG-Ressource
OCR-Modelldienst	Separat verwalteter Modell-Endpunkt, mit `ragsrv-support` verbunden
Sprache-zu-Text-Modelldienst	Separat verwalteter vLLM-kompatibler Whisper-Endpunkt, mit basebox verbunden

Das vollständige Deployment ist damit das basebox-Helm-Release plus die OCR- und Sprache-zu-Text-Modell-Endpunkte. Ihre Image-Versionen, Endpunkt-Konfiguration, Ressourcen-Requests und Lebenszyklus werden im Deployment-Manifest festgehalten.

Plattform-Voraussetzungen

Exaktes Host-Sizing und Softwareversionen werden im Solution Design für den gewählten Server, das Modell, den Dokument-Workload und die Plattformumgebung festgelegt.

Kubernetes-Ressourcenvertrag

Der Knoten muss zwei komplette GPUs und vier 3g.40gb-Instanzen anbieten:

nvidia.com/gpu:          2
nvidia.com/mig-3g.40gb:  4

Die Inferenz fordert beide kompletten GPUs an:

resources:
  requests:
    nvidia.com/gpu: 2
  limits:
    nvidia.com/gpu: 2

Jeder Hilfs-Workload fordert eine MIG-Instanz an:

resources:
  requests:
    nvidia.com/mig-3g.40gb: 1
  limits:
    nvidia.com/mig-3g.40gb: 1

Requests und Limits müssen übereinstimmen, und die Ressourcennamen müssen exakt denen entsprechen, die der NVIDIA GPU Operator oder das Device Plugin anbietet.

Deployment-Reihenfolge

Hardware- und Software-Manifest, stabile GPU-Identitäten, Topologie und NUMA-Layout festhalten.
Das Zwei-GPU-Inferenzpaar auswählen und testen.
Das Inferenzpaar als komplette GPUs mit deaktiviertem MIG belassen.
MIG auf den zwei Service-GPUs aktivieren.
Auf jeder Service-GPU zwei 3g.40gb-GPU-Instanzen und Compute-Instanzen anlegen.
Gemischte MIG-Erkennung aktivieren und die GPU-Erkennungskomponenten neu laden.
Bestätigen, dass Kubernetes genau zwei komplette GPUs und vier MIG-Ressourcen anbietet.
Inferenz mit zwei GPU-Ressourcen und Tensor-Parallelismus 2 deployen.
Die vier Hilfs-Workloads mit je einer MIG-Ressource deployen.
Warm-up und funktionale Prüfungen auf Anwendungsebene abschließen.
Eine begrenzte Mischlast über Inferenz und alle Hilfsdienste fahren.
Einen geplanten Neustart testen und bestätigen, dass GPU-Ressourcen und Workloads zurückkehren.
Die abgenommenen Image-Digests, Modellrevisionen, Chart-Version, Treiber, CUDA-Runtime, GPU-Operator- oder Device-Plugin-Version und Firmware festhalten.

flowchart LR
  HW["Hardware-<br/>Inventar"] --> PEER["Peer- und<br/>NCCL-Prüfungen"]
  PEER --> MIG["MIG-<br/>Konfiguration"]
  MIG --> RES["Kubernetes-<br/>Ressourcen"]
  RES --> DEPLOY["basebox-<br/>Deployment"]
  DEPLOY --> TEST["Funktions- und<br/>Mischlastprüfungen"]
  TEST --> REBOOT["Neustart- und<br/>Wiederanlaufprüfung"]
  REBOOT --> ACCEPT["Abgenommene<br/>Konfiguration"]

Prüfung durch den Operator

Physische Topologie und Kubernetes-Ressourcen inspizieren:

nvidia-smi -L
nvidia-smi topo -m
kubectl describe node <node-name>
kubectl get pods -n <basebox-namespace> -o wide

Bestätigen, dass Capacity und Allocatable beide die erwarteten GPU-Ressourcenzahlen zeigen. Nachdem die Workloads bereit sind, mit freigegebenen synthetischen Testdaten je eine authentifizierte Chat-, Dokumentaufnahme-mit-RAG-Suche-, Extraktions-, OCR- und Sprache-zu-Text-Anfrage über den Anwendungspfad abschließen.

Abnahmeprüfungen

Qualifizierungs-Testdaten dürfen keine Kunden-, Patienten-, Medizin-, Personen-, Vertraulichkeits- oder Produktionsdaten enthalten. Halten Sie Betriebsmetadaten und geschwärzte Ergebniszusammenfassungen fest, nicht Zugangsdaten, Tokens, vollständige Prompts, Quelldokumente, Aufnahmen, Transkripte oder Modellantworten.

Geltungsbereich

Diese Konfiguration deckt einen Kubernetes-Knoten mit 4 x NVIDIA H100 SXM 80 GB ab.
Sie gilt nicht automatisch für H100-PCIe- oder H100-NVL-Systeme.
Modell- und Kontexteignung werden auf der gewählten Serverkonfiguration festgestellt.
Die Kapazität hängt von Modellpräzision, Kontextlänge, Dokument-Workload und Verkehrsmuster ab.
Hochverfügbarkeit über mehrere Knoten und Disaster Recovery erfordern eine separate Architektur.
Kundenspezifisches Sizing von CPU, RAM, Speicher, Netzwerk und Kapazität wird im Solution Design abgeschlossen.
Normale Inferenz und Dokumentverarbeitung laufen auf der Kundeninfrastruktur.
Installation und Updates benötigen freigegebenen Artefaktzugang oder interne Mirrors.