DeepInfer-Unterstützung für H100: Was die offizielle Liste wirklich aussagt

Die Kurzfassung für H100- und RTX-Teams

DeepInfer unterstützt H100 derzeit weder offiziell noch laut Dokumentation. Auch RTX wird nicht offiziell dokumentiert. Das aktuelle Release zielt auf DeepSeek-V4.1-Flash und nennt NVIDIA-Hardware mit SM100 und CUDA 13 oder Ascend 950 mit CANN 9.2. Außerdem setzt das Repository Linux, GCC 13 oder neuer sowie Python 3.12 voraus (offizielles DeepInfer-Repository).

„Nicht aufgeführt“ ist eine Aussage für Beschaffung und Produktionsplanung – aber kein Beweis dafür, dass ein experimenteller Port niemals kompiliert werden kann.

Welche Hardware DeepInfer derzeit offiziell unterstützt

Die Support-Grenze lautet nicht einfach „NVIDIA-GPU“ oder „DeepSeek-Modell“. Entscheidend ist die konkrete Kombination aus Beschleunigergeneration, Software-Stack und Modellpfad.

Die Deployment-Q&A von DeepSeek nennt für Benchmarks 4 SM100-GPUs für Prefill und 64 SM100-GPUs für Decode innerhalb einer Scale-up-Domäne. Das sind Messwerte für SM100 – keine Kapazitätsschätzungen für H100.

Warum SM100 nicht automatisch H100 oder RTX bedeutet

In der offiziellen DeepInfer-Liste tauchen weder H100 noch SM90 oder ein RTX-Modell auf. CUDA-Kompatibilität allein sagt daher noch nichts über die Kompatibilität mit DeepInfer aus.

Das Repository bindet architekturabhängige Komponenten wie FlashMLA, DeepGEMM, DeepEP und TileLang-Operationen ein (Projektdokumentation). Selbst wenn eine GPU als Ziel erkannt wird, kann der Code zur Laufzeit scheitern, falsche Ergebnisse liefern oder genau die Leistung vermissen lassen, die den Wechsel ursprünglich attraktiv gemacht hat.

Deshalb müssen drei Aussagen sauber getrennt werden:

1. Der Code lässt sich für eine Architektur kompilieren.
2. Das Modell läuft mit korrekten Ergebnissen und stabilem verteiltem Verhalten.
3. Das Deployment erreicht eine für den Einsatzzweck brauchbare Latenz und einen entsprechenden Durchsatz.

Nur die erste Aussage lässt sich durch einen erfolgreichen Build belegen. Die öffentlichen DeepInfer-Materialien enthalten weder einen H100- oder RTX-Benchmark noch ein offizielles SM90-Build-Rezept oder eine validierte Konfiguration für Consumer-RTX-Karten.

Migrationswege für bestehende Infrastrukturen

Wenn euer Cluster auf H100 oder einer anderen Hopper-Plattform läuft

Ersetzt keinen funktionierenden H100-Serving-Stack allein, um DeepInfer auszuprobieren. Behandelt einen solchen Versuch als experimentelles Portierungsprojekt und nicht als unterstütztes Deployment.

Ein sinnvoller Migrationsplan sieht so aus:

1. Den produktiven Model-Server unverändert weiterbetreiben.
2. Einen isolierten Branch mit festgepinnten Versionen von DeepInfer, CUDA, Treiber, Compiler und Modell anlegen.
3. Architekturabhängige Abhängigkeiten vor dem Kompilieren erfassen.
4. Numerische Vergleichstests gegen eine bekannte funktionierende Laufzeitumgebung ausführen.
5. Prefill-Latenz, Decode-Latenz, Nebenläufigkeit, Speichernutzung und Wiederanlauf nach Fehlern messen.
6. Den Port nur dann weiter ausrollen, wenn er die für euer Team relevante Workload tatsächlich verbessert.

Die pragmatische Alternative besteht darin, eine Serving-Laufzeit zu prüfen, die eure H100-Konfiguration ausdrücklich dokumentiert – etwa vLLM, SGLang oder TensorRT-LLM. Entscheidend sind dabei der konkrete DeepSeek-Checkpoint, die Quantisierung, die benötigten API-Funktionen und die verteilte Topologie – nicht die SM100-Zahlen von DeepInfer.

Wenn ihr RTX-Workstations oder RTX-Server einsetzt

Die offizielle DeepInfer-Liste nennt kein einziges RTX-Modell. Die dokumentierte Benchmark-Topologie ist auf Inferenz im großen Maßstab ausgelegt. Eine einzelne RTX-Karte oder ein kleiner RTX-Pool ist daher kein günstiger Ersatz für die Konfigurationen mit 4 GPUs für Prefill oder 64 GPUs für Decode.

Geht für Entwicklung, Evaluierung oder einen kleineren selbst gehosteten Endpunkt besser mit einer allgemeinen lokalen Inferenz-Laufzeit an die Aufgabe heran. Behaltet DeepInfer für einen künftigen architekturspezifischen Port im Blick, plant aber nicht auf Basis eines ungeklärten Issues oder einer Forenaussage.

Wenn ihr Zugriff auf SM100 oder Ascend 950 habt

Das ist derzeit der einzige Weg, der zur offiziellen Support-Matrix passt. Auch dann ist DeepInfer aber noch kein vollständiger Online-API-Dienst: In den offiziellen Deployment-Hinweisen werden fehlende Produktionskomponenten wie persistenter KV-Cache, Prefill-/Decode-Orchestrierung und Load-Balancing für Replikas genannt.

DeepInfer eignet sich damit eher für Teams, die die Engine untersuchen oder benchmarken möchten, über die erforderliche Beschleuniger-Topologie verfügen und bereit sind, die umgebende Plattform selbst aufzubauen. Für ein Gateway mit mehreren Modellen ist es nicht automatisch die beste Wahl.

Deployment-Hürden jenseits der GPU

Die Hardware-Unterstützung ist nur eine von mehreren Hürden bei der Migration. Das öffentliche Release wird als Offline-Inferenz beschrieben, nicht als fertiger OpenAI-kompatibler Server. Die fehlenden Bausteine wirken sich direkt auf die Architektur aus:

Das separate Projekt deepseek-recipe übersetzt die Formate Messages, Chat Completions und Responses. Es führt jedoch keine Inferenz aus und stellt auch keinen vollständigen Produktionsdienst bereit.

Checkliste zur Überprüfung vor einem Hardwarewechsel

Bevor ihr eine DeepInfer-Migration freigebt, sollte für jeden Punkt ein belastbarer Nachweis vorliegen:

1. Offizielle Architektur- und Build-Unterstützung: Ist die konkrete GPU aufgeführt, und lässt sich die festgelegte Umgebung auf einer sauberen Maschine reproduzieren?
2. Abdeckung von Kernels und Korrektheit: Liefern Attention-, GEMM- und Expert-Parallel-Kernels übereinstimmende Ergebnisse, strukturierte Antworten und stabiles Verhalten bei langen Kontexten?
3. Verteilte Leistung: Bleiben die geplante GPU-Anzahl und die Interconnect-Topologie bei den vorgesehenen Werten für Nebenläufigkeit und Speichernutzung stabil?
4. Vollständigkeit des Dienstes: Woher kommen KV-Cache, Routing, Authentifizierung, HTTP-Transport und das Balancing der Replikas?

Wenn die Antwort auf die erste Frage „nein“ lautet, sollte das Projekt als Experiment gekennzeichnet werden. Sind die Antworten auf die Fragen zum Service „extern“, muss dieser zusätzliche Engineering-Aufwand in die Migrationskosten einfließen.

FAQ zur DeepInfer-Unterstützung für H100

Läuft DeepInfer auf einer NVIDIA H100?

H100-Unterstützung ist nicht offiziell dokumentiert. Der aktuelle NVIDIA-Eintrag nennt SM100. Ein experimenteller Port ist möglicherweise machbar, aber in den zitierten Materialien gibt es weder ein offizielles H100-Build-Rezept noch einen validierten H100-Benchmark.

Unterstützt DeepInfer RTX 4090, 5090 oder andere RTX-Karten?

RTX-Unterstützung ist nicht offiziell aufgeführt. Die zitierten offiziellen Materialien enthalten keine validierte RTX-Konfiguration. Behandelt ein RTX-Deployment als nicht unterstützt, bis das Upstream-Projekt die Architektur dokumentiert und seine Kernels validiert.

Was sollte ein H100-Team stattdessen einsetzen?

Behaltet eine Laufzeit mit expliziter H100-Unterstützung bei oder prüft eine solche und vergleicht sie mit eurem eigenen Checkpoint und Traffic-Muster. vLLM, SGLang und TensorRT-LLM sind praktische Ausgangspunkte. DeepInfer sollte dagegen eher als künftiges Portierungsziel oder als Anlass verstanden werden, SM100-Infrastruktur zu evaluieren.

Behandelt einen H100- oder RTX-Port als experimentell, bis die konkrete Architektur, die Kernels, die Serviceschicht und die Ergebnisse für die eigene Workload dokumentiert sind.