Voici un retour d’expérience que l’on lit rarement : un résultat négatif. Nous voulions faire tourner notre modèle de production en FP8 sur le GB10 du DGX Spark (architecture Grace-Blackwell, mémoire unifiée). Après cinq tentatives, nous avons abandonné le FP8 sur cette plateforme et basculé sur NVFP4. Voici pourquoi — et ce que ça nous a appris.
Ce qu’on voulait, et pourquoi
Le FP8 est le format « évident » sur Blackwell : support matériel natif, bon compromis qualité/débit, large adoption côté data-center. Sur un nœud always-on, l’objectif était simple : meilleur débit que le GGUF, qualité quasi-intacte, et une empreinte mémoire compatible avec le pool unifié du GB10.
La particularité du Spark, c’est justement cette mémoire unifiée (UMA) : CPU et GPU partagent un seul pool. C’est sa force (pas de copie host↔device) et, on va le voir, son piège.
Le mode de défaillance : une fuite via la mémoire unifiée
À chaque essai, le même scénario : le serveur démarrait, répondait correctement… puis sa consommation mémoire montait requête après requête jusqu’à saturer le pool partagé, suivi d’un crash. Pas une erreur franche au chargement — une fuite progressive.
La cause se situait à l’intersection de trois choses :
- L’allocateur CUDA sur mémoire unifiée : les blocs n’étaient pas réellement rendus au pool.
- Le workspace de FlashInfer (les buffers d’attention) qui croissait sans être recyclé correctement dans ce contexte UMA.
- L’absence de garde-fou : le cgroup ne protège pas d’un runaway sur UMA, et l’ordonnanceur Linux ne distingue pas RAM CPU et VRAM dans ce pool unique — donc rien ne plafonnait la dérive avant le crash.
Cinq tentatives, même mur
Nous avons fait varier ce qui pouvait l’être : versions de la pile (vLLM / FlashInfer), taille du KV-cache, limites mémoire explicites, options d’allocateur. Les cinq configurations ont convergé vers la même fuite. À partir de là, le calcul est simple : continuer, c’était déboguer un chemin amont immature (le support FP8/FlashInfer sur UMA Blackwell) au lieu de livrer. Décision : clore le FP8 sur cette plateforme.
Le pivot qui a marché : NVFP4
Nous sommes passés à la quantization NVFP4 (4 bits, format compressed-tensors, kernels Marlin). Résultat : elle tient dans le budget mémoire du GB10, reste stable dans la durée (pas de fuite), et délivre un meilleur débit. Elle a été promue en production le 2 juin 2026 comme format always-on.
Le contre-intuitif : une quantization 4 bits bien faite a battu le FP8 sur notre matériel. Pas parce que le FP8 est « moins bon » dans l’absolu, mais parce que le chemin 4 bits était mature et stable sur cette plateforme, là où le chemin FP8 ne l’était pas. Voir aussi notre benchmark de quantization 4.75 bits et notre retour d’expérience GB10 sur 3 mois.
Tableau : FP8 vs NVFP4 sur GB10 (notre stack)
| Critère | FP8 | NVFP4 |
|---|---|---|
| Stabilité dans la durée (UMA) | ❌ Fuite progressive | ✅ Stable |
| Empreinte mémoire | ➖ Plus lourde | ✅ Tient dans le pool |
| Débit | ➖ Non mesurable (crash) | ✅ Supérieur |
| Maturité du chemin (notre pile) | ❌ Immature sur UMA | ✅ Mûr |
| Verdict prod | Abandonné après 5 essais | Promu le 02/06/2026 |
Trois leçons
- La mémoire unifiée change les règles. Un format qui « marche partout » ailleurs peut fuir sur UMA. Testez le format sur votre plateforme, pas sur la fiche technique.
- Un résultat négatif a de la valeur. Cinq essais documentés valent mieux qu’un sixième à l’aveugle. Savoir quand arrêter est une compétence d’ingénierie.
- Validez sur un banc figé. Notre verdict NVFP4 vient d’une mesure reproductible, pas d’une impression. C’est ce qui rend une décision d’infrastructure défendable.
Ce retour est le nôtre : notre matériel, nos versions, notre charge. Il ne condamne pas le FP8 en général — il documente précisément où et pourquoi il a échoué chez nous, et le format qui l’a remplacé.