Prise en charge des H100 par DeepInfer : ce que révèle la liste officielle

La réponse courte pour les équipes H100 et RTX

DeepInfer n’annonce ni ne documente officiellement la prise en charge des H100. Il en va de même pour les GPU RTX. La version actuelle cible DeepSeek-V4.1-Flash et répertorie le matériel NVIDIA SM100 avec CUDA 13, ou l’Ascend 950 avec CANN 9.2. Le dépôt requiert également Linux, GCC 13 ou une version ultérieure, ainsi que Python 3.12 (dépôt officiel de DeepInfer).

Une architecture absente de la liste est considérée comme non prise en charge pour les achats et la mise en production. Cela ne prouve pas qu’un correctif expérimental ne pourra jamais être compilé.

Le périmètre officiellement pris en charge par DeepInfer

La compatibilité ne se résume pas à « GPU NVIDIA » ou « modèle DeepSeek ». Elle dépend d’une génération d’accélérateur précise, d’une pile logicielle donnée et d’un chemin d’exécution défini.

La FAQ de DeepSeek sur le déploiement indique des topologies de référence de 4 GPU SM100 pour le prefill et de 64 GPU SM100 pour le decode dans un domaine scale-up. Ces mesures concernent les SM100, pas les capacités des H100.

Pourquoi SM100 n’implique pas automatiquement H100 ou RTX

La liste officielle de DeepInfer ne mentionne ni H100, ni SM90, ni aucun modèle RTX. La compatibilité CUDA, à elle seule, ne suffit donc pas à établir la compatibilité avec DeepInfer.

Le dépôt intègre des composants sensibles à l’architecture, notamment FlashMLA, DeepGEMM, DeepEP et des opérations TileLang (documentation du projet). Même lorsqu’un GPU est reconnu comme cible, l’exécution peut échouer, produire des résultats incorrects ou perdre les performances qui justifiaient la migration.

Il faut donc distinguer trois niveaux de validation :

1. Le code se compile pour une architecture donnée.
2. Le modèle s’exécute avec des résultats corrects et un comportement distribué stable.
3. Le déploiement atteint une latence et un débit réellement utiles.

Une compilation réussie ne permet d’établir que le premier point. Les documents publics de DeepInfer ne fournissent ni benchmark H100 ou RTX, ni procédure officielle de compilation pour SM90, ni configuration RTX grand public validée.

Les options de migration pour les infrastructures existantes

Si votre cluster repose sur des H100 ou une autre architecture Hopper

Ne remplacez pas une pile de serving H100 opérationnelle uniquement pour tester DeepInfer. Considérez plutôt le portage comme un projet expérimental, et non comme un déploiement officiellement pris en charge.

Une démarche raisonnable consiste à :

1. Conserver le serveur de modèles de production tel quel.
2. Créer une branche isolée avec des versions figées de DeepInfer, CUDA, des pilotes, du compilateur et du modèle.
3. Recenser les dépendances spécifiques à l’architecture avant de lancer la compilation.
4. Comparer les résultats numériques avec un runtime de référence dont le bon fonctionnement est établi.
5. Mesurer la latence du prefill, la latence du decode, la concurrence, la consommation mémoire et la reprise après incident.
6. Ne retenir le portage que s’il améliore la charge de travail qui compte réellement pour votre équipe.

L’autre approche consiste à évaluer un runtime de serving qui documente explicitement votre configuration H100, comme vLLM, SGLang ou TensorRT-LLM. Le choix doit dépendre du checkpoint DeepSeek utilisé, de la quantification, des fonctions d’API et de la topologie distribuée nécessaires, pas des chiffres SM100 de DeepInfer.

Si votre équipe utilise des stations de travail ou des serveurs RTX

La liste officielle de DeepInfer ne mentionne aucun modèle RTX. Sa topologie de référence vise l’inférence à grande échelle : une seule carte RTX ou un petit pool de GPU RTX ne doit donc pas être considéré comme un équivalent économique des configurations de 4 GPU pour le prefill ou de 64 GPU pour le decode.

Pour le développement, l’évaluation ou un endpoint auto-hébergé de plus petite taille, privilégiez un runtime généraliste d’inférence locale. Gardez DeepInfer dans votre veille en vue d’un futur portage spécifique à l’architecture, mais ne construisez pas votre budget sur la base d’un ticket non fusionné ou d’une affirmation publiée sur un forum.

Si vous avez accès à des GPU SM100 ou à un Ascend 950

C’est la seule voie qui correspond à la matrice officielle actuelle. Même dans ce cas, DeepInfer ne constitue pas un service d’API en ligne complet : les notes officielles de déploiement signalent l’absence de composants de production tels que le cache KV persistant, l’orchestration prefill/decode et l’équilibrage de charge entre réplicas.

DeepInfer convient donc davantage aux équipes qui souhaitent étudier ou évaluer le moteur, disposent de la topologie d’accélérateurs requise et sont prêtes à construire la plateforme autour. Ce n’est pas automatiquement le meilleur choix pour une passerelle d’API multi-modèles.

Les contraintes de déploiement qui dépassent le choix du GPU

La prise en charge matérielle n’est qu’un des critères à franchir avant une migration. La version publique est présentée comme un outil d’inférence hors ligne, et non comme un serveur OpenAI-compatible prêt à l’emploi. Les éléments manquants ont un impact direct sur l’architecture :

Le projet distinct deepseek-recipe convertit les formats Messages, Chat Completions et Responses, mais il n’exécute pas l’inférence et ne fournit pas à lui seul le service de production complet.

La checklist à vérifier avant de changer de matériel

Avant d’approuver une migration vers DeepInfer, exigez des éléments probants pour chacun des points suivants :

1. Prise en charge officielle de l’architecture et de la compilation : le GPU exact figure-t-il dans la liste, et une machine propre permet-elle de reproduire l’environnement figé ?
2. Couverture des kernels et exactitude des résultats : les kernels d’attention, GEMM et de parallélisme des experts produisent-ils des sorties identiques, des réponses structurées et un comportement correct sur de longs contextes ?
3. Performances distribuées : le nombre de GPU et la topologie d’interconnexion visés restent-ils stables avec vos objectifs de concurrence et de mémoire ?
4. Complétude du service : d’où viennent le cache KV, le routage, l’authentification, le transport HTTP et l’équilibrage entre réplicas ?

Si la réponse à la première question est « non », classez le projet comme expérimental. Si les réponses concernant le service sont « externe », intégrez également ce travail d’ingénierie au coût de migration.

FAQ sur la prise en charge des H100 par DeepInfer

DeepInfer peut-il fonctionner sur un NVIDIA H100 ?

La prise en charge des H100 n’est pas documentée officiellement. L’entrée actuelle pour NVIDIA concerne les SM100. Un portage expérimental est peut-être possible, mais les documents cités ne fournissent ni procédure officielle de compilation pour H100, ni benchmark H100 validé.

DeepInfer prend-il en charge les RTX 4090, 5090 ou d’autres cartes RTX ?

La prise en charge des RTX n’est pas répertoriée officiellement. Les documents officiels cités ne présentent aucune configuration RTX validée. Considérez les déploiements RTX comme non pris en charge tant que le projet amont n’a pas documenté l’architecture concernée et validé ses kernels.

Que devrait utiliser une équipe équipée de H100 ?

Conservez ou évaluez un runtime dont la prise en charge des H100 est explicite, puis comparez les résultats avec votre propre checkpoint et votre propre profil de trafic. vLLM, SGLang et TensorRT-LLM sont de bons points de départ, tandis que DeepInfer doit plutôt être considéré comme une cible de portage future ou comme une raison d’évaluer une infrastructure SM100.

Considérez tout portage H100 ou RTX comme expérimental tant que l’architecture exacte, les kernels, la couche de service et les résultats sur votre charge de travail ne sont pas documentés.