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

// installation

Referenzkonfiguration: 2 × NVIDIA H200 141 GB

Gilt für

Produkt: Server · Betrieb: durch den Kunden oder durch basebox · Zielgruppe: Platform Operator · Hardware: 2 × NVIDIA H200 141 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

basebox läuft auf Ihrer eigenen Hardware. Diese Konfiguration beschreibt ein Einzelknoten-Deployment auf einem kundeneigenen Kubernetes-Server mit zwei NVIDIA H200 141 GB GPUs: Eine komplette GPU bedient das Sprachmodell, die zweite ist in vier GPU-Instanzen aufgeteilt, die die Retrieval-, Dokument-, Bild- und Audiodienste ausführen. Ihre Modelle, Dokumente und deren verarbeitete Ausgaben bleiben auf Ihrer Infrastruktur.

Hardware-Layout

Element Diese Konfiguration
GPUs 2 × NVIDIA H200 141 GB in einem Server
Inferenz-GPU Eine komplette H200 141 GB GPU, ausschließlich Sprachmodell-Inferenz
Service-GPU Vier MIG-Instanzen 1g.35gb
Kubernetes-GPU-Ressourcen nvidia.com/gpu: 1 und nvidia.com/mig-1g.35gb: 4
Kubernetes Ein einzelner Knoten mit beiden GPUs
Speicher Persistenter Speicher für Modellartefakte, Dokumente und Plattformdaten
Images Registry-Zugang oder ein interner Image-Mirror

MIG (Multi-Instance GPU) ist die NVIDIA-Funktion, die eine physische GPU in unabhängige Instanzen mit jeweils eigener Speicher- und Rechenpartition aufteilt. Jede 1g.35gb-Instanz stellt etwa 35 GiB GPU-Speicher bereit.

CPU, Arbeitsspeicher, Speicherkapazität, Netzwerk, Treiber, CUDA-Runtime und Firmware-Stände werden gemeinsam mit basebox festgelegt, abhängig von Ihrem gewählten Modell, Dokumentvolumen und Ihrer Plattformumgebung.

GPU-Speicherzuteilung

Die Konfiguration widmet eine komplette GPU der Sprachmodell-Inferenz. Die zweite GPU ist in vier Service-Instanzen aufgeteilt. Die Werte in diesem Diagramm sind ungefähre dezimale GPU-Speicherzuteilungen; Kubernetes verwendet den MIG-Profilnamen 1g.35gb.

pie showData
  title Ungefähre GPU-Speicherzuteilung in der Konfiguration
  "LLM-Inferenz" : 141
  "GPU-RAG" : 35
  "Dokumentextraktion" : 35
  "OCR" : 35
  "Sprache-zu-Text" : 35

Workload-Zuteilung

GPU-Zuteilung basebox-Workload
Komplette H200 141 GB GPU LLM-Inferenz
MIG-Slice 1 GPU-RAG – Retrieval über Ihre eigenen Dokumente
MIG-Slice 2 Dokumentextraktion
MIG-Slice 3 OCR – Text aus Bildern und Scans
MIG-Slice 4 Sprache-zu-Text

Weil die Inferenz auf einer kompletten GPU bleibt, können die Dokument-, Bild- und Audio-Workloads weder Rechenleistung noch VRAM-Zuteilung der Inferenz-GPU verbrauchen. Ein Upload oder eine Transkription wird stattdessen von der Service-GPU bedient. Host-CPU, Arbeitsspeicher, Speicher und Netzwerk bleiben von allen Workloads geteilt und werden deshalb für die Gesamtlast dimensioniert.

Topologie

graph TB
  subgraph SERVER["Kundenserver – 2 × H200 141 GB"]
    subgraph NODE["Kubernetes-Knoten"]
      subgraph G0["Inferenz-GPU – komplett, nicht partitioniert"]
        LLM["LLM-Inferenz"]
      end
      subgraph G1["Service-GPU – 4 × MIG 1g.35gb"]
        S1["Slice 1"]
        S2["Slice 2"]
        S3["Slice 3"]
        S4["Slice 4"]
      end
    end
  end
  S1 --> RAG["GPU-RAG"]
  S2 --> EXT["Dokumentextraktion"]
  S3 --> OCR["OCR"]
  S4 --> STT["Sprache-zu-Text"]

  style LLM fill:#dbeafe,stroke:#1e40af,color:#111827
  style RAG fill:#dcfce7,stroke:#166534,color:#111827
  style EXT fill:#dcfce7,stroke:#166534,color:#111827
  style OCR fill:#dcfce7,stroke:#166534,color:#111827
  style STT fill:#dcfce7,stroke:#166534,color:#111827

Gemessener Referenz-Workload

Die Konfiguration wurde mit Sprachmodell-Verkehr und allen vier GPU-Hilfsdiensten gleichzeitig auf demselben Server erprobt. Diese Zahlen beschreiben den gemessenen Referenz-Workload; das Kunden-Sizing basiert auf gewähltem Modell, Kontextlänge, Dokumentvolumen und erwartetem Verkehr.

Messung Referenzergebnis
Dauer kontinuierlicher Mischlast 60 Minuten
Kurze Sprachmodell-Anfragen 720/720 mit erwartetem Ergebnis abgeschlossen
Sprachmodell-Anfragen mit langem Kontext 12/12 mit erwartetem Ergebnis abgeschlossen
Eingabegröße bei langem Kontext Etwa 258.000 Tokens
Kombinierte RAG-, Extraktions-, OCR- und Sprache-zu-Text-Lastspitzen 12/12 abgeschlossen
Neustarts des Inferenz-Workloads während des Laufs 0
Prüfung des Dokumentverarbeitungsdienstes 120-seitiges PDF in 28,47 Sekunden extrahiert und durchsuchbar gemacht
Prüfung des Sprache-zu-Text-Dienstes 60-minütige synthetische Audiodatei in 31,31 Sekunden transkribiert
Kaltstart-Toleranz der Inferenz Etwa 6 Minuten von Neustart bis Warm-up

Dokument- und Audiozeiten sind Referenzmessungen auf Dienstebene. Die tatsächliche Verarbeitungszeit variiert mit Dateiformat, Inhalt, Modellwahl und Plattformkonfiguration.

flowchart LR
  RUN["60-minütige Mischlast"] --> SHORT["720 kurze LLM-Anfragen"]
  RUN --> LONG["12 LLM-Anfragen mit langem Kontext"]
  RUN --> SERVICES["12 kombinierte Service-Lastspitzen"]
  SHORT --> LLMRESULT["732/732 erwartete LLM-Ergebnisse"]
  LONG --> LLMRESULT
  SERVICES --> SERVICERESULT["12/12 RAG-, Extraktions-, OCR- und STT-Lastspitzen"]
  LLMRESULT --> STABLE["0 Inferenz-Neustarts"]
  SERVICERESULT --> STABLE

Plattform-Voraussetzungen

  • Eine unterstützte Kubernetes-Umgebung mit beiden GPUs auf einem Knoten
  • NVIDIA-Treiber und eine GPU-fähige Container-Runtime auf dem Host installiert
  • NVIDIA GPU Operator oder Device Plugin für gemischte MIG-Ressourcenerkennung konfiguriert, sodass eine komplette GPU und vier MIG-Instanzen gemeinsam angeboten werden
  • Erhöhte Host-Rechte für die NVIDIA-GPU-Systemkomponenten geprüft, die diese für die gemischte MIG-Erkennung benötigen können
  • Eine persistente Storage Class für Modellartefakte, Dokumente und Plattformdaten
  • basebox-Container-Images aus einer Registry erreichbar oder intern gespiegelt
  • Modellartefakte lokal oder über ein freigegebenes Repository verfügbar
  • DNS, TLS, Authentifizierung, Backup und Monitoring durch Ihr eigenes Plattformdesign bereitgestellt

Kubernetes-Ressourcenvertrag

Der Inferenz-Workload fordert die komplette GPU an:

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

Jeder der vier Hilfs-Workloads fordert eine Service-Instanz an:

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

Die Ressourcennamen müssen dem entsprechen, was der NVIDIA GPU Operator oder das Device Plugin auf dem Knoten anbietet. basebox bildet diese Ressourcenverträge beim Deployment auf Inferenz, GPU-RAG, Dokumentextraktion, OCR und Sprache-zu-Text ab.

Deployment-Reihenfolge

  1. Beide GPUs anhand stabiler UUID oder PCI-Adresse identifizieren und festhalten, welche die Inferenzrolle und welche die Servicerolle übernimmt. Nicht auf GPU-Indexnummern verlassen, die sich ändern können.
  2. Die Inferenz-GPU als komplettes Gerät ohne weiteren GPU-Workload reservieren.
  3. MIG auf der Service-GPU aktivieren, adressiert über ihre stabile Identität.
  4. Vier 1g.35gb-GPU-Instanzen und ihre Compute-Instanzen anlegen.
  5. Gemischte MIG-Ressourcenerkennung konfigurieren und die GPU-Erkennungskomponenten neu laden, damit das neue Layout angeboten wird.
  6. Bestätigen, dass der Knoten eine komplette GPU und vier MIG-Ressourcen sowohl unter Capacity als auch unter Allocatable anbietet, bevor etwas deployt wird.
  7. basebox mit gleichen GPU-Ressourcen-Requests und -Limits für jeden der fünf GPU-Workloads deployen.
  8. Dem Modell nach der Kubernetes-Readiness Zeit zum Warm-up geben und eine Warm-up-Generierung abschließen, bevor Nutzer zugelassen werden.
  9. Die Abnahmeprüfungen unten durchführen.

Prüfung durch den Operator

Physische GPUs und MIG-Instanzen auf dem Host bestätigen:

nvidia-smi -L

Den Kubernetes-Knoten inspizieren und die GPU-Ressourcen unter Capacity und Allocatable prüfen:

kubectl describe node <node-name>

Erwartete GPU-Ressourcenzahlen:

nvidia.com/gpu:          1
nvidia.com/mig-1g.35gb:  4

Workload-Platzierung, Readiness und Neustartzähler prüfen:

kubectl get pods -n <basebox-namespace> -o wide

Nachdem die Pods Ready sind, über die basebox-Anwendung eine authentifizierte Chat-Anfrage, eine Dokumentaufnahme mit RAG-Suche, eine OCR-Anfrage und eine Sprache-zu-Text-Anfrage abschließen.

Abnahmeprüfungen

  • Der Knoten bietet nvidia.com/gpu: 1 an
  • Der Knoten bietet nvidia.com/mig-1g.35gb: 4 an
  • Die Inferenz ist an die komplette GPU gebunden
  • Jeder Hilfs-Workload hält eine separate MIG-Instanz
  • Alle fünf GPU-Workloads werden ohne Neustarts Ready
  • Chat-Inferenz funktioniert über die basebox-Anwendung mit Authentifizierung
  • Dokumentaufnahme und RAG-Suche liefern Ergebnisse
  • OCR liefert den erwarteten Text aus einem repräsentativen Dokument
  • Sprache-zu-Text liefert ein Transkript
  • Monitoring und persistenter Speicher sind gesund
  • Nach einem geplanten Neustart kehren die GPU-Ressourcen und alle fünf Workloads zurück

Geltungsbereich

  • Diese Konfiguration deckt ein Einzelknoten-Deployment auf 2 × NVIDIA H200 141 GB ab.
  • Hochverfügbarkeit über mehrere Knoten und Disaster Recovery erfordern eine separate Architektur.
  • Die Kapazität hängt von gewähltem Modell, Kontextlänge, Dokument-Workload und Verkehrsmuster ab.
  • Das kundenspezifische Sizing wird im Solution Design abgeschlossen.
  • Normale Inferenz und Dokumentverarbeitung laufen vollständig auf Ihrer Infrastruktur.
  • Installation und Updates benötigen Zugang zu Registry und Modell-Repository oder lokal vorgehaltene gespiegelte Artefakte.

Nächster Schritt: Bare-Metal-Installation