Django de Vreng

Gemma-4 v23 sur le DGX Spark

2026-06-23T00:00:00.000Z

NVFP4 reste le choix pratique par défaut pour Gemma-4 sur le DGX Spark, mais MTP devient la position intermédiaire intéressante. Dans les nouveaux runs vLLM v0.23.0, NVFP4 reste devant en chat et en multi-turn, tandis que MTP dépasse nettement le run BF16 sans passer au re-quant NVIDIA.

J'ai relancé la même famille Gemma-4-26B-A4B sur le DGX Spark, cette fois avec vllm/vllm-openai:v0.23.0-aarch64-cu129-ubuntu2404. Les données brutes sont dans le repo de benchmark au commit 605faab6a599. L'Arena a maintenant trois nouvelles entrées : BF16 v23, MTP v23 et NVFP4 v23.

Le précédent article Gemma parlait surtout du prix du contexte en BF16. Ce run répond à une autre question : qu'est-ce qui change quand la même machine, la même famille de modèles et les mêmes workloads tournent sur vLLM v0.23.0, avec trois profils de serving côte à côte ?

Le setup resté identique

Les trois runs utilisent la même machine et la même forme de benchmark :

Composant	Valeur
Hardware	DGX Spark NVIDIA GB10, 128 GB unified memory
vLLM image	`vllm/vllm-openai:v0.23.0-aarch64-cu129-ubuntu2404`
KV-cache	`fp8`
Prefix caching	désactivé
Max model length	131072
Benchmark commit	`605faab6a599`

Les trois profils :

Profil	Modèle	Served name	Generated
BF16 v23	`google/gemma-4-26B-A4B-it`	`gemma-4-26b-a4b`	2026-06-22T23:16:36+02:00
MTP v23	`google/gemma-4-26B-A4B-it`	`gemma-4-26b-a4b-mtp`	2026-06-23T03:29:52+02:00
NVFP4 v23	`nvidia/Gemma-4-26B-A4B-NVFP4`	`gemma-4-26b-a4b-nvfp4`	2026-06-23T01:35:33+02:00

MTP utilise donc le même chemin de modèle Google que BF16, mais servi avec le profil MTP. NVFP4 utilise le re-quant NVIDIA. Cette distinction compte, sinon tu compares discrètement deux choses à la fois : le comportement de l'engine et l'artefact modèle.

Chat : NVFP4 devant, MTP rattrape BF16

La première comparaison utile est le Run C : 1024 prompttokens, 1024 outputtokens, dix requêtes concurrentes. C'est une forme de chat propre : pas trivialement courte, mais pas non plus un monstre de contexte.

Profil	TTFT c10	Decode/user c10	Decode total c10
BF16 v23	1342.98 ± 449.90 ms	11.47 ± 0.45 tok/s	90.83 ± 7.87 tok/s
MTP v23	1400.13 ± 142.07 ms	17.79 ± 1.55 tok/s	138.97 ± 6.68 tok/s
NVFP4 v23	1138.26 ± 385.15 ms	21.59 ± 0.98 tok/s	151.22 ± 15.96 tok/s

C'est le coeur du résultat. MTP donne environ 55 pourcent de decode par utilisateur en plus que BF16 sur ce run chat. NVFP4 reste au-dessus, mais l'écart entre MTP et NVFP4 est beaucoup plus petit que l'écart entre BF16 et MTP.

La latence jusqu'au premier token reste dans le même ordre de grandeur. NVFP4 est le plus rapide ici, MTP n'est pas plus rapide que BF16 en TTFT. Cela colle au pattern : ces profils changent surtout le débit de decode. Le prefill reste du travail.

Le multi-turn est l'endroit où NVFP4 s'ouvre vraiment

Le Run E est pour moi le test closed-loop le plus proche de la production : cinq tours par conversation, dix conversations en parallèle, 2048 tokens de départ et 512 outputtokens par tour.

Profil	TTFT c10	Decode/user c10	Decode total c10
BF16 v23	2154.60 ± 858.63 ms	10.69 ± 0.25 tok/s	98.35 ± 3.95 tok/s
MTP v23	2368.00 ± 789.47 ms	16.57 ± 1.32 tok/s	143.47 ± 4.67 tok/s
NVFP4 v23	1966.10 ± 735.30 ms	20.01 ± 0.80 tok/s	182.90 ± 6.67 tok/s

C'est là que NVFP4 devient vraiment naturel. 182.90 tok/s au total pour dix conversations multi-turn sur un Spark, ce n'est pas un chiffre de démo, c'est un profil d'inference locale utilisable.

MTP reste utile. Pas comme gagnant, mais comme réponse à : et si je veux garder l'artefact Google BF16 tout en obtenant plus de decode ? Dans ce cas, 16.57 tok/s par utilisateur change beaucoup par rapport à 10.69.

Output long : plus de tokens, pas automatiquement plus de douleur

Pour les agents et la génération de code, le Run G compte : 256 prompttokens, 4096 outputtokens, dix requêtes concurrentes. Cette forme indique si les longues générations font s'écrouler la machine.

Profil	TTFT c10	Decode/user c10	Decode total c10
BF16 v23	490.95 ± 4.88 ms	12.47 ± 0.94 tok/s	87.16 ± 3.88 tok/s
MTP v23	564.16 ± 14.86 ms	17.67 ± 1.92 tok/s	127.52 ± 9.05 tok/s
NVFP4 v23	368.83 ± 54.97 ms	23.69 ± 1.65 tok/s	120.96 ± 50.17 tok/s

Note la forme un peu étrange : NVFP4 a le meilleur decode par utilisateur, mais le decode total a beaucoup plus de variance. MTP est plus bas par utilisateur, mais plus stable dans ce run précis. Je ne regarderais donc pas seulement la barre la plus haute. Pour des agents, tu veux aussi de la prévisibilité, surtout si plusieurs runs continuent de streamer longtemps.

25k de contexte reste le mur

Quantization et MTP ne changent pas le fait qu'un grand contexte est surtout du prefill. À 25k prompttokens et c10, cela donne ceci :

Profil	TTFT c10	Decode/user c10	Decode total c10
BF16 v23	39281.43 ± 20075.74 ms	5.28 ± 2.13 tok/s	28.49 ± 0.62 tok/s
MTP v23	45640.37 ± 23247.85 ms	6.05 ± 3.24 tok/s	27.62 ± 0.27 tok/s
NVFP4 v23	38575.15 ± 19624.30 ms	7.40 ± 4.24 tok/s	33.54 ± 0.03 tok/s

Ce n'est plus du chat. Avec dix prompts concurrents de 25k, tu attends en moyenne entre 39 et 46 secondes avant le premier token. NVFP4 aide encore un peu le decode, mais l'utilisateur ressent surtout une fenêtre vide avant que le stream démarre.

C'est la même leçon que dans le précédent article de benchmark Gemma-4, maintenant avec vLLM v0.23.0 en plus : le contexte n'est pas un champ d'entrée gratuit. Si tu fais porter 25k tokens à un agent local, tu le paies en TTFT.

Open-loop : la forme bureau reste utilisable

Les tests open-loop comptent plus pour le ressenti que les tableaux closed-loop. Ils envoient les requêtes selon un pattern d'arrivée au lieu de tout lancer en même temps.

H : baseline bureau

200 prompts random, request rate 0.3, burstiness 0.7.

Profil	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	200/200	129.92	2835.43 ms	197.57 ms
MTP v23	200/200	132.35	3394.53 ms	178.77 ms
NVFP4 v23	200/200	139.05	2393.78 ms	77.98 ms

NVFP4 est nettement plus agréable ici. Pas grâce à un output throughput beaucoup plus élevé, car 139.05 contre 129.92 tok/s n'est pas une révolution. La différence est dans le TPOT : 77.98 ms p95 contre 197.57 ms pour BF16. Le stream paraît beaucoup plus rapide dès qu'il commence.

I : replay ShareGPT

250 vraies conversations, même request rate.

Profil	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	250/250	60.93	456.10 ms	115.31 ms
MTP v23	250/250	61.47	576.82 ms	77.32 ms
NVFP4 v23	250/250	61.99	225.09 ms	45.30 ms

C'est le meilleur proxy pour le chat normal. Des conversations courtes et réelles. NVFP4 donne un p95 TTFT de 225.09 ms et un p95 TPOT de 45.30 ms. En local, cela ne ressemble pas à un compromis.

J : pic du lundi matin

300 prompts random, target 1.5 rps, max concurrency 25.

Profil	OK	Output tok/s	P95 TTFT	P95 TPOT
BF16 v23	300/300	132.04	3006.73 ms	199.23 ms
MTP v23	300/300	172.32	3870.47 ms	235.91 ms
NVFP4 v23	300/300	218.90	2390.17 ms	124.58 ms

Sous surcharge, NVFP4 reste aussi le plus utilisable. Toutes les requêtes réussissent, mais la queue décide qui ressent la douleur. BF16 et MTP donnent ici des tails moins agréables. MTP a plus d'output throughput que BF16, mais un p95 TTFT et un p95 TPOT plus mauvais. C'est exactement pourquoi je veux voir des percentiles, pas seulement des tokens par seconde.

Ce que je mets dans l'Arena

J'ai ajouté trois nouvelles entrées Arena au lieu d'écraser les anciennes entrées Gemma-4. Les anciens runs v0.20.1 restent utiles comme points de comparaison historiques. Ces nouvelles entrées sont explicitement v23 :

Le classement court pour mon propre usage :

NVFP4 v23 pour le chat local, les agents et la charge bureau.
MTP v23 si tu veux garder l'artefact modèle Google, mais que le decode BF16 est trop lent.
BF16 v23 comme ligne de contrôle et pour les comparaisons où la précision compte plus que la vitesse de serving.

Pour 25k de contexte, aucun des trois ne règle le vrai problème. Là, il faut travailler sur le budget de prompt, le retrieval, la compaction de mémoire et l'architecture d'agent. Pas espérer qu'un profil de serving fasse disparaître l'attente.

Les trois chiffres d'une DGX Spark rapide

2026-05-22T00:00:00.000Z

Peux-tu faire tourner sérieusement des large language models en local sur une DGX Spark ? Oui. C'est la réponse ennuyeuse, et c'est aussi celle que te donne chaque test : un nom de modèle, un chiffre, des tokens par seconde, terminé.

La réponse utile est plus difficile. Un modèle qui gère proprement une seule prompt de démo ne dit rien d'un lundi matin avec dix personnes, un gros contexte, des agent-flows et quelqu'un qui colle un demi-roman dans un ticket. C'est là que ça coince, ou pas. Et ça ne dépend pas de la Spark, ça dépend de ta charge.

J'ai une Spark dans le lab et j'y ai fait tourner une pile de modèles, en BF16, FP8 et NVFP4. Neuf charges de travail, deux méthodes de mesure, et quelques runs refaits parce que les premiers étaient suspects de bons. Ce qui restait après toute cette mesure n'est pas un tableau de scores. C'est une façon de regarder qui a tenu à chaque fois, et elle est ci-dessous. Les chiffres bruts par modèle sont dans les posts séparés, et le guide complet avec la configuration, le coût et pour qui ça marche est sur Faire tourner des LLMs sur la DGX Spark. Ce texte parle de cette seule loupe.

Ce qu'est vraiment l'engin

La DGX Spark est la plus petite machine Blackwell de NVIDIA. Une puce GB10, 128 GB de unified memory, assez petite pour une baie serveur. Pas de carte graphique séparée avec son propre pool mémoire, mais une seule mémoire que le CPU et le GPU partagent ensemble. Retiens ce chiffre, 128 GB. C'est tout ton budget, et tout ce qui suit est une division à l'intérieur de ces 128.

Une chose à savoir d'avance, parce qu'elle explique la moitié des chiffres plus loin. La Spark tourne sur du Blackwell desktop, SM12.1, et cette puce ne sait pas calculer nativement en 4-bit. Le gros Blackwell datacenter, le B200, oui. Conséquence : de la quantization 4-bit tu obtiens sur la Spark tout le gain mémoire, mais pas tout le gain de calcul. vLLM contourne ça en ramenant les poids 4-bit à une précision plus haute pendant le calcul.

Ça marche très bien. Mais c'est justement pour ça que tu ne dois pas coller bêtement les jolis chiffres FP4 d'un B200 sur ta propre Spark.

Ce qui rentre dans 128 GB

En bref : les poids rentrent en premier, le reste est de la KV-cache pour tous les utilisateurs ensemble. La précision est donc un choix de conception à l'avance, pas un bouton après coup, et j'ai écrit un post séparé là-dessus. La question n'est jamais de savoir si un modèle rentre, mais ce qui reste quand il rentre. La division complète est dans le guide.

À quelle vitesse c'est vraiment

C'est là que la plupart des tests de la DGX Spark se trompent. Ils prennent une seule prompt, mesurent les tokens par seconde, et appellent ça « la vitesse ». Mais sur cette machine la vitesse n'est pas un chiffre. Ce sont trois choses, elles se ressentent différemment et se comportent différemment. Sépare-les et toute la Spark se met en place.

Le decode est presque gratuit

Le decode, c'est le texte qui arrive une fois que le modèle génère vraiment. Sur la Spark c'est d'une stabilité ennuyeuse, et ennuyeux est un compliment ici. Un utilisateur sur un modèle 26B atteint entre 23 et 24 tokens par seconde en BF16, que tu lui donnes 4k ou 25k de contexte. Dix utilisateurs en même temps : entre 9 et 12 chacun, et ça reste collé là. Le decode dépend donc du nombre de gens occupés en même temps, pas de la longueur de leur prompt.

Et la quantization tire toute cette ligne vers le haut. NVFP4 a gagné sur le decode dans les neuf tests, de 22 à 92 pour cent selon la charge. Sur un modèle MoE plus léger comme Nemotron-3, le decode single-user frôle même les 60 t/s. Le decode, en somme, n'est pas le problème.

Le prefill est la facture

Le prefill, lui, l'est. Le prefill, c'est le silence avant le premier token, et c'est ça qu'un utilisateur ressent comme « lent », pas les tokens d'après.

Le prefill grimpe avec la taille de ta prompt, et ça fait mal. Une prompt courte est traitée en une demi-seconde, même à dix en même temps. Balance-lui 25k de contexte avec ces mêmes dix utilisateurs et tu attends 35 secondes le premier caractère. Même machine, même concurrency, juste une prompt plus longue. Double la prompt, double grosso modo l'attente.

Et la quantization ? Elle n'aide presque pas ici. Le prefill, c'est du calcul, et le calcul est précisément là où se trouve ce handicap SM12.1. NVFP4 rend ton decode plus rapide. Ton prefill reste du prefill.

Sous pression elle met en file, elle ne plante pas

Reste la question : que fait-elle quand tu lui balances simplement trop de choses ? La réponse est rassurante d'ennui. Elle ne tombe pas. Elle se met dans la file.

Dans le test le plus lourd je voulais pousser 1,5 requests par seconde à travers la machine. Elle en a encaissé presque six fois moins. Et pourtant aucune des 300 requests n'a échoué. Le ralentissement n'est pas non plus allé à tout le monde, il est allé à la queue : l'utilisateur moyen a peu remarqué, le malchanceux un pour cent a attendu six secondes son premier token.

Pour l'on-prem c'est le meilleur résultat que tu puisses espérer. Un crash, c'est un coup de fil. Une file, c'est un peu de patience. Un bureau vit avec le second, pas avec le premier.

C'est tout le modèle. Le decode est presque gratuit, le prefill est la facture, le queueing est ton filet de sécurité. Les chiffres en dessous, neuf charges par modèle et deux méthodes de mesure, sont dans l'arène et dans les posts séparés : la baseline BF16, NVFP4 contre BF16 et Nemotron-3 en trois précisions.

Le reste est dans le guide

Quel moteur je fais tourner (vLLM), ce que coûte une Spark, et pour qui ça marche ou non : c'est le tableau complet, et ça a sa place dans le guide, pas dans cette seule histoire de loupe. La version courte de « pour qui » : le local ne devient intéressant que lorsque les données n'ont pas le droit de sortir du bâtiment. Si tu n'as pas cette exigence et que tu veux juste les tokens les plus rapides et les moins chers, alors une API cloud est la réponse plus honnête.

Faire tourner en local n'est pas un principe. C'est une répartition : ce qui doit rester dedans, et ce qui a le droit de sortir.

Refais-le toi-même

Tout ce qui est en dessous est ouvert. Les modèles sont sur Hugging Face, vLLM est open source, et la sortie brute des benchmarks plus les scripts sont sur GitHub. La méthodologie explique quelles neuf charges je fais tourner et pourquoi.

Si tu as toi-même une Spark, tu devrais pouvoir suivre la même route et obtenir à peu près les mêmes chiffres. Si ça ne marche pas, c'est justement ce que je veux savoir. Écris-moi sans souci.

Pourquoi ce blog et cette arena existent

2026-05-05T00:00:00.000Z

Pour les clients de Kamoo, je mets en place des systèmes d'IA qui doivent parfois rester proches de la maison. Des comptables, des bureaux administratifs, des cabinets avec des données personnelles et des documents financiers. Exactement le genre de données qui ne rendent pas ton auditeur plus serein quand tu lui dis : "on envoie ça vite fait en Amérique".

C'est pour ça qu'on a un DGX Spark ici. 128 GB de unified memory, assez petit pour une armoire serveur, assez grand pour faire tourner des modèles locaux sérieux via vLLM. Ce qui tient dessus en pratique, je le rassemble sur la page de synthèse sur les modèles locaux sur le DGX Spark.

Puis la question pratique a commencé.

Quel modèle utilises-tu pour quoi sur cette machine ? Quelle précision choisis-tu ? Combien de contexte tient encore ? Où la concurrency s'effondre-t-elle ? Que se passe-t-il un lundi ordinaire avec dix personnes qui ne lancent pas toutes un benchmark en même temps, mais font simplement leur travail ?

Je cherchais des chiffres pour exactement ces questions. Pas un leaderboard général avec un score qui fait surtout bonne figure dans une capture d'écran. Juste : cette puce, ces modèles, ces engines, ces workloads, ces limites.

Je ne les ai pas trouvés.

Alors je les construis moi-même.

L'arena est l'établi de mesure

En ce moment, il y a dix profils de benchmarks dans l'arena, avec des runs pour entre autres le context-scaling, la concurrency, l'output-throughput, des workloads façon RAG et un pic du lundi matin.

Cette arena doit faire une chose bien : montrer ce que tu peux attendre en pratique sur un DGX Spark. Pas quel modèle est "le meilleur" dans un sens abstrait, mais quel modèle reste utilisable sur ce matériel sous les workloads que je rencontre dans le travail client.

Pour quelques runs, j'ai déjà noté ce qui a foiré et ce que j'en ai tiré. Par exemple où Gemma-4 commence à coincer sur le Spark, ce que NVFP4 gagne sur BF16 une fois les bugs partis, et comment trois précisions de Nemotron-3 se comparent.

L'output brut est public sur GitHub : djangodevreng/dgx-spark-benchmarks. C'est volontaire. Si tu as un Spark toi-même, tu dois pouvoir suivre le même chemin et obtenir à peu près les mêmes chiffres. Si ça ne marche pas, c'est aussi une donnée intéressante.

L'arena n'est donc pas une petite liste statique. C'est un etabli. De nouveaux modèles dedans, d'autres précisions à côté, des workloads resserrés, des résultats bizarres relancés. Juste assez ennuyeux pour devenir utile.

Le blog est le contexte autour

Les chiffres sont pratiques, mais ils ne racontent pas toute l'histoire.

Un benchmark peut dire que NVFP4 est plus rapide que BF16. Le blog peut raconter que les premiers runs ont cassé sur des bugs de vLLM, qu'un paramètre était mal réglé, qu'un modèle n'est devenu utilisable qu'après avoir baissé la longueur de contexte, ou que la tail-latency se ressentait pire que la moyenne ne le laissait penser.

C'est la couche qui me manquait moi-même quand j'ai commencé. Pas seulement "voici un score", mais : voilà ce que j'ai essayé, ça a cassé, voilà ce que j'ai changé, et voilà ce que je ferais autrement la prochaine fois.

C'est pour ça que le blog et l'arena sont côte à côte. L'arena donne les points de mesure. Le blog donne le raisonnement, les erreurs et les choix pratiques derrière.

Pourquoi local

La vie privée est en général l'explication polie. Elle est vraie aussi. La raison plus pratique : certains clients n'ont pas le choix.

Un cabinet comptable ne peut pas traiter les données client comme si c'était du texte d'exemple dans une demo. Les communes ont des règles. Les documents financiers ont des règles. Les données personnelles ont des règles. En pratique, tout ça revient à la même question : peux-tu mettre ça en place sans que le juridique, la compliance et l'audit ne claquent aussitôt la porte ?

Alors tu as deux options. L'IA n'a pas sa place là, ou tu le fais en local.

On choisit le local quand c'est nécessaire. Le Spark rend ça soudain moins exotique. Il n'est pas bon marché, mais il reste abordable pour un cabinet de PME qui veut faire quelque chose de sérieux sans aussitôt construire son propre data center.

C'est là que se trouve le travail intéressant pour moi : faire tourner des modèles, mesurer la latency, tester des prompts, faire passer des documents dans une pipeline, et regarder où ça casse.

D'habitude, ça casse quelque part d'ennuyeux. Ce sont les meilleurs endroits.

Ce à quoi je veux pouvoir répondre

L'arena doit finalement répondre à des questions qui reviennent sans cesse dans les projets.

Quel modèle est assez rapide pour des questions internes sur documents ? Quelle précision laisse assez de marge pour plusieurs utilisateurs en même temps ? Quand NVFP4 suffit, quand veux-tu du FP8, et quand BF16 est-il surtout un default cher ? Combien de contexte peux-tu donner avant que la latency devienne pénible ? Quel engine convient mieux à quel workload : vLLM, TensorRT-LLM ou SGLang ?

Ce ne sont pas des questions académiques. Elles déterminent comment tu conçois un setup on-prem. Combien de matériel il te faut. Quelles données restent en local. Quelles étapes tu envoies éventuellement vers un modèle hébergé. Et où tu traces la ligne entre "marche dans une demo" et "tient le coup le lundi matin".

Cette dernière ligne est toute la raison pour laquelle ce site existe.

Pourquoi j'écris ça en public

Tout ce que j'utilise pour ça est open ou public : vLLM, des modèles sur Hugging Face, des scripts de benchmark, du JSON en vrac, le site lui-même. Le secret n'est pas l'accès à un dashboard magique. Il est dans des heures à essayer, mesurer, relancer, chasser des bugs et ensuite mesurer encore parce que ton premier run était suspectement bon.

Ça m'a coûté des dizaines d'heures jusqu'ici. Faire tourner des modèles, répéter des runs, démêler des résultats bizarres, et ensuite mesurer encore parce que le premier run était suspectement bon.

Si quelqu'un d'autre suit le même chemin, il n'a pas à trébucher sur tous les mêmes pavés. Et si quelqu'un contredit mes chiffres avec de meilleurs runs : tant mieux. L'arena en devient meilleure.

Il y a aussi une deuxième raison en dessous. Ce site fait lui-même partie de l'expérience. Le blog, l'arena, le flux de l'output de benchmark vers du JSON structuré vers des pages : tout ça a été largement construit en quelques semaines avec des agents qui écrivent et construisent avec moi. J'ai décrit la petite version de ça plus tôt dans le setup OpenClaw sur un Raspberry Pi.

Ce workflow fait partie du travail maintenant. Je balance des trouvailles brutes dans Slack, je laisse un agent lire le repo et le guide d'écriture, je récupère une branche avec une proposition, je lance les checks et je relis la diff moi-même. Ça ne m'épargne pas la réflexion. Mais ça déplace beaucoup de préparation vers une couche qui continue simplement de tourner.

Écrire sur ce processus m'oblige à le rendre moins brouillon que mon historique de terminal. Ça aide. Pas toujours sympa, mais nécessaire.

Ce que je veux construire ensuite

D'abord, plus de benchmarks. vLLM était le point de départ, parce qu'il marche vite et est largement utilisé. TensorRT-LLM est déjà sur l'etabli pour Nemotron-3. SGLang, c'est ce que je veux mettre à côté des mêmes workloads ensuite. C'est seulement avec plusieurs engines que tu vois si ton modèle est lent, si ton engine te met des bâtons dans les roues, ou si tu as juste fait une bêtise.

Ensuite, je veux rendre bench-spark public : le benchmark-runner tel que je l'utilise aujourd'hui. Pas un framework parfait. Mais quelque chose avec quoi quelqu'un sur le même matériel peut poser les mêmes questions sans d'abord reconstruire mes erreurs.

Je veux aussi faire une eval-suite néerlandaise pour les LLMs locaux. Pas un benchmark de reasoning anglais de plus, mais du travail de bureau : jargon comptable, textes juridiques, documents financiers, documents avec une mise en forme bizarre. Exactement les choses sur lesquelles l'IA locale est jugée aux Pays-Bas.

Et il y aura plus de travail autour du RAG local sur de grands jeux de documents. Pas de pitch de plateforme. Juste comprendre comment faire passer plus d'un million de documents dans un setup on-prem sans que le stockage, le retrieval ou l'OCR se mette lentement à te détester.

Ce que je laisse de côté

Pas de newsletter IA quotidienne. Il y a déjà assez d'endroits pour ça, certains même exprès.

Pas d'histoire general-purpose "on fait tout avec l'IA". Trop large, et d'habitude ça ne veut rien dire.

Pas de numéro de thought-leader. Je préfère construire quelque chose qui craque qu'une opinion qui sonne lisse.

Pas non plus de construction d'une plateforme comme OpenClaw. Je l'utilise, j'écris dessus, je construis des flux avec. Mais cette couche elle-même, je la laisse aux gens qui vivent dedans tous les jours.

Ce que ça doit devenir

Pour les clients, ça doit montrer ce que l'IA locale coûte en pratique : matériel, latency, précision, maintenance, cas limites bizarres. Pour moi, c'est l'endroit où je fixe mes propres suppositions avant que le prochain benchmark ne les renverse.

J'essaie de tenir le rythme. Pas de promesse par semaine. S'il n'y a rien à signaler, rien ne s'affiche ici. S'il y a des bugs, des runs et des graphiques bizarres, il y a sans doute trop ici.

Gemma-4 sur la DGX Spark : NVFP4 vs BF16

2026-05-03T00:00:00.000Z

import BenchCard from "../../../components/post/BenchCard.astro"; import BenchCardRow from "../../../components/post/BenchCardRow.astro"; import Note from "../../../components/post/Note.astro";

Dans la baseline BF16 de Gemma-4 sur la DGX Spark, j'ai fait neuf benchmarks avec Gemma-4-26B-A4B en BF16. La vitesse de décodage tenait très bien, le prefill décidait du moment où le mur arrivait, et le système faisait sagement la queue sous pression au lieu de planter. Cette histoire semblait bouclée, jusqu'à ce que NVIDIA sorte une version NVFP4-quantized de ce même modèle.

Même architecture et même fine-tune, même config serveur, seule la précision change. De BF16 (16 bits par paramètre) à NVFP4 (4 bits par paramètre, la variante de NVIDIA sur FP4). Quatre fois plus petit par poids, et si les kernels Blackwell jouent le jeu, nettement plus rapide aussi sur les tâches compute-heavy.

Sur le papier, c'est beau. En pratique : la release officielle vLLM v0.20.1 reconnaît ce checkpoint sans broncher, et les chiffres étaient plus rapides sur toute la ligne que la baseline BF16. Les deux tests tombent sous le guide faire tourner des LLMs sur la DGX Spark.

Pourquoi se pencher là-dessus

Pour un bureau avec une machine IA locale, le budget mémoire est la chose la plus limitante après la puissance de calcul. Un modèle 26B en BF16 prend ~48 Go de mémoire GPU rien que pour les weights. Sur une Spark avec 128 Go de unified memory, il reste environ 65 Go pour le KV-cache. Suffisant pour le scénario de bureau du premier blog, mais pas beaucoup de marge pour faire tourner, disons, 30+ utilisateurs avec un gros contexte côte à côte.

NVFP4 réduit ça à ~18 Go pour les weights. Pas quatre fois moins que BF16 (le vision-encoder reste en BF16, et les scale-factors coûtent aussi de la place), mais environ 2,7× moins. Ça te donne vers 95 Go de KV-cache headroom, ce qui en théorie devrait supporter une concurrency bien plus élevée. À ça s'ajoute qu'il faut moins de trafic mémoire par forward pass, donc par définition moins de pression sur la bandwidth, et c'était déjà le bottleneck en BF16 sous charge multi-utilisateurs. La question était donc simple : combien de ce gain théorique survit en pratique ?

Ce qu'est vraiment NVFP4

NVFP4 est la variante de NVIDIA sur FP4 : des nombres en virgule flottante avec 4 bits par valeur. Quatre bits, pas quatre octets, donc un facteur 4 de moins par paramètre que BF16. En stockant un scaling factor par groupe de weights, l'accuracy reste raisonnablement préservée.

Pour Blackwell, ça marche comme ça. Les cartes datacenter de NVIDIA (B100, B200, SM10.0) ont des tensor cores qui peuvent calculer nativement avec des valeurs 4-bit, et c'est bien plus rapide que le même calcul en FP16 ou BF16. La DGX Spark, en revanche, c'est du Blackwell desktop (GB10, SM12.1) et cette architecture n'a pas de compute FP4 natif.<Note>Sur un B200 datacenter (SM10.0), tu attendrais encore 2 à 3× par-dessus grâce aux tensor cores FP4 natifs. La Spark n'a pas ce chemin matériel, donc tout le gain vient de la bandwidth mémoire, pas du compute.</Note> Ce que tu obtiens dans ce cas, c'est du FP4 "weight-only" : les weights sont physiquement stockés en 4-bit (d'où le gain mémoire), mais pendant le compute ils sont décodés à la volée vers FP16 pour les matrix-multiplications. Un warning vLLM le dit explicitement :

Your GPU does not have native support for FP4 computation but FP4 quantization
is being used. Weight-only FP4 compression will be used leveraging the Marlin kernel.
This may degrade performance for compute-heavy workloads.

Tu obtiens donc le gain mémoire en entier, le gain compute seulement en partie. Le kernel Marlin INT4 GEMM est optimisé, mais pas aussi rapide que le FP4 natif sur SM10.0 le serait. Bon à intégrer dans le calcul quand tu regardes les chiffres plus bas.

Le montage de test

Config serveur identique au premier blog, seul le modèle change :

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:v0.20.1 \
  --model nvidia/Gemma-4-26B-A4B-NVFP4 \
  --served-model-name gemma-4-26b-a4b-nvfp4 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --limit-mm-per-prompt '{"image":0,"audio":0}' \
  --async-scheduling \
  --no-enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

Les tests sont un à un identiques au premier blog : mêmes commandes, mêmes niveaux de concurrency, mêmes datasets pour les tests open-loop, même seed. C'est volontaire, car si tu veux mesurer l'effet d'une variable isolée (ici la précision), tout le reste autour doit rester pareil. La façon exacte dont je mesure ces niveaux de concurrency, ces seeds et ces arrivées open-loop est décrite dans la méthode de mesure de l'Arena.

Comparaison	BF16	NVFP4
Modèle	google/gemma-4-26B-A4B-it	nvidia/Gemma-4-26B-A4B-NVFP4
Active params	4B	4B
Total params	26B	26B
Model memory	~48 Go	~18 Go
KV-cache headroom	~65 Go	~95 Go
MoE backend	(default)	MARLIN (forcé)

Trois chiffres résument où ça aboutit. Clique pour la run complète dans l'Arena, avec tous les seeds, niveaux de concurrency et commandes :

Une version interactive de tous les chiffres se trouve sur la page Arena de Gemma-4-26B-A4B-NVFP4, commandes et percentiles TTFT inclus pour les 9 tests.

<details> <summary>Run A : scaling du contexte de 4k à 25k</summary>

Décodage par utilisateur quand le contexte grandit, c=1/5/10 :

Context	Users	BF16 d/u	NVFP4 d/u	Gain
4k	1	24.08	29.80	+24%
4k	5	12.55	22.01	+75%
4k	10	9.48	16.94	+79%
8k	1	23.69	29.31	+24%
8k	5	11.48	19.28	+68%
8k	10	8.52	14.35	+68%
16k	1	23.34	28.55	+22%
16k	5	10.05	15.67	+56%
16k	10	6.79	10.06	+48%
25k	1	22.75	27.70	+22%
25k	5	8.46	12.46	+47%
25k	10	5.40	7.55	+40%

À c=1, le gain est stable autour de +22-24% à travers tous les contextes. La bandwidth mémoire ne joue presque pas en single-user, donc le gain ici se trouve dans le compute-path lui-même. Le décodage INT4 de Marlin plus le matmul FP16 est un peu plus rapide que le matmul FP16 direct de BF16, malgré les deux étapes.

À c=10, l'écart scale beaucoup plus fort selon le type de workload, de +40% à 25k de contexte à +79% à 4k. C'est parce qu'en multi-utilisateurs la bandwidth mémoire devient le bottleneck, et NVFP4 lit moins d'octets par forward pass. Plus c'est concurrent, plus ça compte, jusqu'à ce que tu retombes sur les KV-cache memory limits (25k de contexte avec plusieurs utilisateurs) et que le gain s'aplatisse.

Le TTFT (premier token) est meilleur aussi :

Context	Users	BF16 TTFT	NVFP4 TTFT
4k	10	4.46s	4.20s
8k	10	7.99s	7.84s
16k	10	18.92s	18.69s
25k	10	35.67s	35.65s

Sur le TTFT, le gain est faible. C'est logique : le prefill est compute-heavy, et sur SM12.1 sans tensor cores FP4 natifs, Marlin doit décoder les weights à la volée pour le matmul. Ça reprend une partie de ce que la bandwidth mémoire avait rapporté. Pour le décodage, la bandwidth compte plus que le compute ; pour le prefill, c'est l'inverse.

</details>

<details> <summary>Run B : 25k de contexte, concurrency jusqu'à 20</summary>

Le stress-test de la première partie :

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
5	8.51 t/s	12.43 t/s	19.86s	19.72s
10	5.37 t/s	7.56 t/s	35.44s	35.51s
20	3.16 t/s	4.26 t/s	67.37s	67.40s

Le plateau de décodage agrégé passe de 32 t/s à 36 t/s à c=20 : un plafond 12% plus haut à 25k de contexte sous pression maximale. Le TTFT est pratiquement identique entre BF16 et NVFP4 parce que le prefill est le mur ici et qu'il n'accélère pas beaucoup sur SM12.1. Le décodage par utilisateur est par contre nettement meilleur : avec vingt prompts 25k en parallèle, tu obtiens 4.26 au lieu de 3.16 t/s, +35%. Toujours pas de la vitesse de chat, mais une différence perceptible dès que les tokens commencent à couler.

</details>

<details> <summary>Run C : prompt 1k, output 1k</summary>

La workload prompt-court + réponse-longue, proche des agent-flows et de la génération de code :

Users	BF16 d/u	NVFP4 d/u	Gain
1	23.86	29.45	+23%
5	13.59	24.69	+82%
10	10.92	20.88	+91%

À c=10, le décodage par utilisateur est bien au-dessus de 20 t/s, au-dessus de la vitesse de lecture et proche d'une UI de streaming confortable. Le décodage agrégé à c=10 atteint 209 t/s au lieu de 86 t/s en BF16, presque le double.

</details>

<details> <summary>Run E : multi-turn (depth 4)</summary>

Cinq tours consécutifs par conversation, dix conversations en parallèle : la shape de bureau la plus réaliste.

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
1	23.97	29.61	0.53s	0.33s
5	13.07	23.98	1.32s	1.11s
10	10.43	19.51	2.13s	1.94s

Pour dix conversations 5-turn en parallèle : 1.94 seconde jusqu'au premier token, 19.51 t/s par utilisateur. Ça rentre confortablement dans ce qu'un lecteur ressent comme du chat, et c'est 87% plus rapide par token que BF16 dans le même test.

</details>

<details> <summary>Run F : mix RAG (prompt 8k)</summary>

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
5	12.11	20.91	4.32s	4.28s
10	9.31	15.96	7.99s	8.00s
20	6.05	10.57	14.61s	14.45s

8k de contexte, c'est à peu près ce qu'un RAG-flow avec quatre chunks de 2k tokens reçoit. À dix utilisateurs, tu attends 8 secondes jusqu'au premier token (quasi pareil que BF16, car bottleneck compute), puis 16 t/s en streaming. Pour les flows "pose une question sur tes documents", c'est largement exploitable, et là où le gain se trouve : dans la vitesse de décodage, pas dans le TTFT.

</details>

<details> <summary>Run G : instruction courte, 4096 tokens d'output</summary>

La shape agent / génération de code :

Users	BF16 d/u	NVFP4 d/u	BF16 TTFT	NVFP4 TTFT
1	24.17	29.59	0.24s	0.11s
5	14.32	25.79	0.38s	0.23s
10	11.75	22.54	0.48s	0.37s

Un TTFT de 110 millisecondes en single-user, c'est très bas, plus bas que ce que la plupart des hosted APIs atteignent à travers le réseau. Et 22.54 t/s par utilisateur à c=10, c'est largement assez pour des agent-streams. Le décodage agrégé à c=10 dans ce test sort à 225 t/s contre 84 t/s en BF16, presque 2,7× autant. Pour une équipe qui fait tourner dix agents simultanés produisant chacun de longues sorties structurées, c'est le chiffre le plus important.

</details>

<details> <summary>Run H : open-loop, workload 4k aléatoire</summary>

La baseline de bureau synthétique avec des arrivées Poisson :

Metric	BF16	NVFP4
Achieved RPS	0.27	0.29
Peak concurrent	36	16
TTFT P50	1286 ms	1006 ms
TTFT P99	3316 ms	2893 ms
TPOT P50	182 ms	64 ms
Total tok/s	1215	1302

Ce qui frappe, c'est que le peak concurrent tombe de 36 à 16 à arrival rate identique (0.3 rps) et prompts identiques. Comme NVFP4 traite chaque requête plus vite, la queue reste plus courte, et c'est un point important pour la planification de capacité : NVFP4 te donne non seulement une latency plus basse par requête, mais aussi moins de pression de queue au même arrival rate. En parallèle, le TPOT P50 tombe de 182ms à 64ms. La latency médiane inter-token est donc presque trois fois plus rapide. Pour une UI de chat qui montre le token-streaming, c'est la différence entre attendre artificiellement une réponse et simplement lire au fil de l'eau.

</details>

<details> <summary>Run I : replay ShareGPT (vraies conversations)</summary>

De vraies données de conversation multi-turn :

Metric	BF16	NVFP4
Peak concurrent	17	10
TTFT P50	353 ms	152 ms
TTFT P99	637 ms	265 ms
TPOT P50	95 ms	39 ms

Un P99 TTFT de 265 millisecondes, pour 99 pour cent des utilisateurs. Un TPOT de 39 ms revient à 25.6 t/s par utilisateur. Tu peux tranquillement appeler ça du chat en temps réel pour 25 collaborateurs avec des prompts réalistes de style ShareGPT.

</details>

<details> <summary>Run J : pic du lundi matin</summary>

Le scénario le plus lourd de la première partie : serveur surchargé, target de 1.5 rps avec max 25 requêtes simultanées.

Metric	BF16	NVFP4
Configured RPS	1.50	1.50
Achieved RPS	0.26	0.44
TTFT P50	1132 ms	920 ms
TTFT P99	6157 ms	6054 ms
TPOT P50	187 ms	108 ms
Total tok/s	1173	1984

Le chiffre le plus mesurable de toute la journée, c'est que l'achieved RPS passe de 0.26 à 0.44. Même target, même cap de concurrency, mêmes arrivées Poisson, et NVFP4 traite 69% de requêtes en plus par seconde avant que la queue ne se bouche.

Le P99 TTFT ne bouge que marginalement (6.16s à 6.05s). Ça colle au schéma : le prefill est compute-bound sur SM12.1, et NVFP4 n'y est pas beaucoup plus rapide. Mais le TPOT P50 tombe de 187ms à 108ms, et le throughput agrégé de tokens grimpe de 1173 à 1984 t/s. Pour un bureau de 25 personnes aux heures de pointe, c'est la différence entre du confortable et du serré : plus de requêtes par seconde traitées, avec un streaming plus rapide pour qui est servi.

</details>

Ce que ça veut dire pour l'IA on-prem

Si tu as une Spark et que tu fais tourner Gemma-4-26B, NVFP4 est l'upgrade. Sur les 9 tests, NVFP4 est le gagnant, et il libère 30 Go de mémoire pour d'autres usages comme plus de KV-cache, un deuxième petit modèle à côté, ou des batch-jobs. Chez Kamoo, cette config NVFP4 est maintenant à côté de la baseline BF16 dans bench-spark/, et une seule commande bascule entre les deux.

Pour un bureau de 25 personnes avec des prompts réalistes de style ShareGPT, tu le remarques tout de suite. Le TPOT P50 tombe de 95 ms à 39 ms, le P99 TTFT de 637 ms à 265 ms. Et quand un pic de charge arrive, le système délivre 69% de requêtes en plus par seconde avant de se remplir. Pour les agent-flows et la génération de code (shape Run G), la Spark en NVFP4 est à son meilleur : dix agents en parallèle, chacun 4096 tokens d'output, 22.5 t/s par utilisateur avec un TTFT sous 400 ms.

Pour le stress à 25k de contexte (Run B), ça reste le mur. NVFP4 ne le baisse presque pas (le TTFT diffère de moins d'une seconde), parce que le prefill reste le prefill, et dix prompts 25k en parallèle attendent 35 secondes le premier token. La quantization n'y change rien sur ce matériel. La vitesse de décodage, par contre, si : 7.56 t/s/utilisateur au lieu de 5.37, donc dès que les tokens arrivent, ils défilent plus vite.

Ce que cette run ne dit pas

Ce n'est pas du NVFP4 sur SM10.0 (Blackwell datacenter). Là, le compute FP4 natif rendrait la différence bien plus grande, avec l'attente d'un speedup supplémentaire de 2-3× par-dessus ce qu'on voit ici. Sur un H100 ou un B200, ces chiffres ne sont donc pas représentatifs ; la Spark a un handicap spécifique SM12.1 (pas de FP4 natif) qui n'existe pas dans le cloud.

Ce n'est pas non plus une comparaison avec Gemma-4-31B dense en NVFP4. Le dense passe par un autre code-path dans le loader de vLLM. Pour un blog de suite, le dense-NVFP4 avec la même suite de tests fournirait un troisième point de données.

Et ce n'est pas une comparaison d'accuracy à long terme. La quantization NVFP4 a des effets d'accuracy potentiellement petits. Pour les tâches typiques d'un bureau (résumé, classification de tickets, RAG) rarement perceptibles, pour les edge-cases peut-être bien.

Ce que NVIDIA a publié, lui, se trouve dans la model-card NVFP4 : sur MMLU-Pro, GPQA-Diamond et LiveCodeBench, NVFP4 reste à 0,2 à 0,7 point de leur propre baseline BF16.<Note>La propre baseline BF16 de NVIDIA s'écarte elle-même des chiffres de la card officielle Gemma-4 de Google. Les eval-harnesses diffèrent plus que la précision elle-même, donc une comparaison croisée entre vendors sans harness identique est branlante.</Note> Ça tombe dans la run-to-run-variance, pas de vraie dégradation. Ce qui est curieux dans ce même tableau, c'est que la baseline BF16 de NVIDIA s'écarte à son tour de ce que Google publie dans la card officielle Gemma-4 : MMLU-Pro 85.0 vs 82.6, GPQA 80.3 vs 82.3, LiveCodeBench 80.5 vs 77.1. Pas parce que la quantization devient meilleure que l'original, mais parce que l'eval-harness compte visiblement plus que la précision elle-même. Autres prompts, autre temperature, autres critères d'arrêt. Les comparaisons croisées entre vendors sont donc difficiles à établir solidement sans le même harness.

Ce qui reste

Le décodage vend le benchmark, le prefill décide de l'expérience. C'était vrai en première partie et ça l'est toujours. Ce que NVFP4 ajoute, c'est que le décodage devient plus rapide dans chaque workload, et le plus là où ça compte : à plus grand contexte et avec plus d'utilisateurs en même temps. Le TTFT reste à peu près pareil sur SM12.1 parce que le prefill est compute-bound et que la Spark n'a pas de tensor cores FP4 natifs. Pour ce que l'utilisateur ressent dès que les tokens commencent à couler, NVFP4 sur ce matériel est nettement meilleur que BF16, et ça ne coûte rien en douleur d'installation : une image officielle vLLM, un flag de modèle, et ça tourne.

Nemotron-3 sur le DGX Spark : BF16 vs FP8 vs NVFP4

2026-05-03T00:00:00.000Z

Dans les posts précédents, j'ai fait tourner Gemma-4 sur le DGX Spark. D'abord juste BF16 comme baseline, puis NVFP4 vs BF16 sur la même suite de tests. Ça donnait un modèle dans deux précisions. Utile, mais pas encore une vraie image du choix que tu dois faire en production.

Pour cet article, je fais tourner trois variantes du même modèle côte à côte : BF16, FP8 et NVFP4 de Nemotron-3-Nano-Omni-30B-A3B-Reasoning. Même Spark. Même version de vLLM. Mêmes prompts. Même suite de benchmarks. Aussi proche d'une comparaison de quantization honnête que je peux l'obtenir sur cette machine.

La version courte : NVFP4 gagne sur la vitesse et le throughput, FP8 gagne plus souvent sur la tail-latency, BF16 reste surtout utile comme baseline. C'est moins net que "4 bits c'est toujours mieux". Heureusement, sinon ce post aurait été court. Fait partie du guide faire tourner des LLMs sur le DGX Spark.

Pourquoi cette expérience

Le post sur Gemma montrait surtout que NVFP4 fonctionne sur le Spark. Avec de la douleur. Cinq bugs vLLM, une nightly build et assez de flags pour qu'une ligne de commande ressemble à un petit aveu.

Mais Gemma ne répondait pas à la question dont j'ai besoin pour les clients : que choisis-tu si tu veux faire tourner un modèle local sur un Spark aujourd'hui ? BF16 parce que ce sont les weights originaux ? FP8 parce que Blackwell y est nativement bon ? Ou NVFP4 parce que tu fais tenir beaucoup plus de modèle et de KV-cache dans la même mémoire ?

D'où cette run. Un modèle dans trois précisions. Pas un score de leaderboard, mais des workloads qui ressemblent au travail de bureau : chat, RAG, réponses plus longues, plusieurs utilisateurs en même temps, et un lundi matin où tout le monde décide soudain que l'IA est bien pratique finalement.

Ce que BF16, FP8 et NVFP4 signifient ici

BF16 est la baseline : 16 bits par paramètre, environ 2 octets. Pour ce modèle ça veut dire à peu près 61,5 GB de checkpoint size. Ça tient sur le Spark, mais ça grignote une grande partie de tes 128 GB de mémoire unifiée avant qu'un seul utilisateur n'ait du contexte dans le KV-cache.

FP8 divise ce poids à peu près par deux. Le checkpoint fait 32,8 GB. Sur Blackwell, FP8 est un choix logique : moins de mémoire, support natif, et en général peu d'embêtements dans vLLM.

NVFP4 va plus loin. Le checkpoint fait 20,9 GB. Pas quatre fois plus petit que BF16, parce que les encoders vision et audio restent en BF16, mais assez petit pour rendre le Spark différent. Plus de place pour le KV-cache, plus de batching, plus de concurrency.

La nuance : le DGX Spark tourne sur du desktop Blackwell SM12.1. Là, NVFP4 n'est pas la même fête que sur du datacenter Blackwell. vLLM utilise Marlin pour décoder les weights FP4 vers FP16 pendant le compute. Tu obtiens le gain mémoire en entier. Le gain compute est moins pur.

Pour ce post, c'est justement ce qui le rend intéressant. Ce n'est pas un post théorique sur la quantization. C'est : que se passe-t-il sur cette machine, avec cette stack, quand tu fais vraiment tourner les trois options ?

Précision	Model size	Budget mémoire restant sur 128 GB
BF16	61.5 GB	~66 GB
FP8	32.8 GB	~95 GB
NVFP4	20.9 GB	~107 GB

Le banc de test

Toutes les runs passent par Docker sur le DGX Spark avec vllm/vllm-openai:v0.20.0. Release officielle, pas de patches.

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  -e HF_TOKEN="***" \
  vllm/vllm-openai:v0.20.0 \
  vllm serve nvidia/Nemotron-3-Nano-Omni-30B-A3B-Reasoning-NVFP4 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --max-num-seqs 256 \
  --max-num-batched-tokens 8192 \
  --trust-remote-code \
  --video-pruning-rate 0.5 \
  --reasoning-parser nemotron_v3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --limit-mm-per-prompt '{"image":0,"audio":0}'

Pour FP8, j'utilise le même profil avec --kv-cache-dtype fp8. BF16 tourne sans ce flag KV-cache. Le reste du test reste identique.

La suite de benchmarks est décrite sur la méthodologie de l'arena. En bref : tests closed-loop pour le decode et le TTFT par utilisateur, plus des tests open-loop avec des arrivées de Poisson pour voir comment le serveur se comporte quand les requests n'attendent pas gentiment l'une l'autre.

Setup

J'ai mal commencé avec nvcr.io/nvidia/vllm:26.02-py3, le container vLLM de NVIDIA. Il avait vLLM 0.15.1 et ne connaissait pas encore l'architecture NemotronH_Nano_Omni_Reasoning_V3.

La solution était plus ennuyeuse : vllm/vllm-openai:v0.20.0. Release officielle, bonnes versions de flashinfer, première run fonctionnelle.

Notre propre CLI bench-spark avait encore besoin de deux petits fixes : contourner l'entrypoint NVIDIA avec --entrypoint vllm, et passer HF_TOKEN automatiquement au container. Après ça, la suite a tourné.

Leçon : commence par la release stable qui supporte l'architecture.

<details> <summary>Run A : context-scaling</summary>

Cette run est la base : que se passe-t-il quand le prompt devient plus long, pendant que le nombre d'utilisateurs grimpe de un à dix ? Ça touche directement au travail de bureau. Un chat court est facile. Une question RAG avec 25k de contexte et plusieurs personnes en même temps, c'est là que le Spark montre combien de place il reste vraiment.

Ici, je regarde deux choses. D'abord le decode par utilisateur : à quelle vitesse le texte revient une fois que la génération tourne ? Ensuite le TTFT : combien de temps attends-tu le premier token ? Avec un long contexte, le TTFT est souvent la douleur que les utilisateurs ressentent en premier. Ils ne voient aucun token, donc on a l'impression que le système est bloqué.

Single-user est surtout une mesure de vitesse pure. Là, NVFP4 double presque BF16. À dix utilisateurs, ça devient plus intéressant : les weights plus petits donnent à vLLM plus de place pour batcher, et là BF16 devient simplement lourd.

Decode/user (tg256), c=1

Contexte	BF16	FP8	NVFP4	NVFP4 vs BF16
4k	29.23	51.68	60.30	+106%
8k	28.59	49.82	55.72	+95%
16k	28.24	47.52	55.24	+96%
25k	28.24	48.85	54.98	+95%

BF16 reste bien plat autour de 28-29 tokens par seconde. C'est stable, mais pas rapide. FP8 met environ 50 t/s en face. NVFP4 se situe autour de 55-60 t/s. Pour un seul utilisateur, c'est la différence entre "correct" et "ça fait local mais pas local-lent".

Decode/user (tg256), c=10

Contexte	BF16	FP8	NVFP4	NVFP4 vs BF16
4k	7.76	13.45	19.69	+154%
8k	7.13	11.14	17.90	+151%
16k	6.30	10.73	14.99	+138%
25k	5.56	8.59	12.99	+134%

À dix utilisateurs, NVFP4 n'est pas "un peu plus rapide". C'est une autre classe. À 25k de contexte, BF16 fait 5,56 tok/s/user. NVFP4 fait 12,99. Ce n'est toujours pas un cluster de GPU cloud, mais la différence de ressenti est grande : BF16 devient de l'attente, NVFP4 continue de travailler.

TTFT (premier token), c=10

Contexte	BF16	FP8	NVFP4
4k	3.90s	2.91s	2.45s
8k	6.49s	5.93s	4.03s
16k	12.63s	10.55s	8.01s
25k	19.82s	16.89s	12.71s

C'est le tableau que je prends le plus au sérieux pour de vrais utilisateurs. À 25k de contexte et dix utilisateurs, tu attends presque 20 secondes le premier token avec BF16. Avec NVFP4 c'est 12,7 secondes. Toujours long, mais pas le même genre de long.

</details>

<details> <summary>Run B : 25k de contexte, concurrency jusqu'à 20</summary>

La Run A montre comment la longueur de contexte scale. La Run B garde le contexte lourd et augmente seulement la concurrency. C'est le test "tout le monde pose une grosse question en même temps".

En pratique, ça n'arrive pas toutes les heures. Dix à vingt personnes cliquent rarement sur envoyer exactement au même moment avec 25k de contexte. Mais si tu poses une machine IA locale devant une équipe, tu veux savoir comment elle échoue. Ralentir calmement est acceptable. Une queue qui a l'air morte, non.

NVFP4 garde le plus d'air ici. Pas parce que le modèle devient plus malin, mais parce que le serveur avec des weights plus petits a plus de place pour le batching et le KV-cache.

Utilisateurs	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 vs BF16
5	9.06	15.33	20.75	+129%
10	5.65	9.18	12.99	+130%
20	3.70	5.97	7.79	+110%

Utilisateurs	BF16 TTFT	FP8 TTFT	NVFP4 TTFT
5	11.01s	8.89s	7.21s
10	19.75s	15.82s	12.74s
20	37.88s	29.91s	24.08s

Vingt utilisateurs avec 25k de contexte, c'est exprès méchant. Pourtant c'est utile. BF16 est à 37,88 secondes de TTFT. Ça fait cassé. NVFP4 est à 24,08 secondes. Pas confortable non plus, mais quand même bien treize secondes plus rapide.

L'aggregate decode montre la même image :

Utilisateurs	BF16	FP8	NVFP4
5	34 t/s	53 t/s	71 t/s
10	38 t/s	59 t/s	77 t/s
20	44 t/s	66 t/s	84 t/s

Le plafond passe de 44 t/s à 84 t/s. Pour un seul utilisateur, c'est abstrait. Pour une équipe, ça veut dire que la queue se vide plus vite.

</details>

<details> <summary>Run C : prompt court, output longue</summary>

C'est le workload pour les agents, la génération de code et les réponses plus longues : peu d'input, beaucoup d'output. Le prompt ne fait que 1024 tokens, donc le prefill n'est pas le problème ici. La question est surtout : à quelle vitesse le modèle continue de tourner une fois que l'output devient longue ?

Donc ici, je regarde le decode par utilisateur. Le TTFT doit rester bas, mais la vraie différence, tu ne la sens qu'après quelques centaines de tokens. Un modèle qui démarre vite mais reste ensuite coincé à 8 tok/s donne quand même une impression de lenteur.

NVFP4 gagne clairement ici. À dix utilisateurs en parallèle, le modèle reste à 22,90 tok/s/user. BF16 tombe à 7,84. C'est encore lisible, mais pour un flow d'agent, on dirait que quelqu'un tape à la main en même temps.

Utilisateurs	BF16 d/u	FP8 d/u	NVFP4 d/u
1	28.65	49.85	55.55
5	12.19	21.32	30.97
10	7.84	15.26	22.90

Pour ce workload, NVFP4 est le default logique. FP8 est correct, mais ici tu cèdes surtout de la vitesse sans que la tail-latency joue le rôle principal.

</details>

<details> <summary>Run E : multi-turn, depth 4</summary>

Le multi-turn est plus proche de l'usage réel qu'un prompt isolé. Cinq tours par conversation, plusieurs conversations en parallèle. Ça ressemble à un employé qui ne pose pas une question, mais relance, corrige et garde le contexte.

Ici, je ne veux pas seulement voir du throughput élevé. Je veux surtout que le serveur ne donne pas l'impression de sortir d'un cold start à chaque tour. Avec dix conversations en même temps, ça devient pertinent : le contexte grandit par conversation, le scheduler doit continuer à partager, et l'utilisateur s'attend à ce que le chat continue de tourner.

C'est pour moi la run de bureau la plus importante. Pas parce qu'elle est parfaitement réelle, mais parce qu'elle se rapproche le plus de "25 personnes utilisent ça réparties sur la journée".

Utilisateurs	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 TTFT
1	28.69	49.72	56.18	596 ms
5	11.50	20.87	30.55	1032 ms
10	7.68	14.88	21.58	1359 ms

À dix conversations en parallèle, NVFP4 est à 21,58 tok/s/user. FP8 est à 14,88. BF16 à 7,68. Ce dernier fonctionne techniquement, mais ça ne donne plus l'impression d'un chat fluide. NVFP4 reste bien au-dessus de la ligne où tu perçois une réponse comme fluide.

</details>

<details> <summary>Run F : mix RAG avec prompt de 8k</summary>

Le RAG n'est en général pas 25k de contexte, mais pas non plus un chat court. Cette run utilise un prompt de 8k et 512 tokens d'output. Pense à quatre chunks d'environ 2k tokens, plus la question et l'instruction.

Avec le RAG, le prefill compte plus que dans la Run C. Tu enfournes à chaque fois une bonne tranche de contexte dans le modèle avant que quelque chose revienne. Ensuite, tu veux garder assez de decode pour rendre la réponse utilement rapide.

La question est donc : la quantization continue-t-elle d'aider quand le prompt s'alourdit ? Oui. NVFP4 reste clairement devant, même à vingt utilisateurs.

Utilisateurs	BF16 d/u	FP8 d/u	NVFP4 d/u
5	12.50	21.02	27.77
10	8.11	14.37	19.65
20	5.51	9.82	14.09

À vingt utilisateurs, NVFP4 délivre 14,09 tok/s/user. BF16 est à 5,51. Pour du batch processing, ça peut encore aller. Pour du RAG temps réel dans un bureau, BF16 fait juste, surtout quand les documents sont en désordre et que les prompts deviennent plus longs que tu l'espérais. Ils le deviennent toujours.

</details>

<details> <summary>Run G : instruction courte, 4096 tokens d'output</summary>

La Run G ressemble à la Run C, mais pousse l'output bien plus loin : 4096 tokens. C'est la shape des agents qui rédigent des plans, génèrent du code, font de longues analyses ou résument plusieurs fichiers.

Pour ce genre de workload, le premier token est presque secondaire. Si la réponse est longue, la vitesse de decode détermine l'expérience. Dix secondes de différence au début, c'est agaçant. Attendre l'output pendant des minutes, c'est pire.

NVFP4 reste le plus fort ici. Plus important : il reste aussi au-dessus de 25 tok/s/user à dix utilisateurs. Pour du hardware local sur une machine de bureau, c'est tout simplement utilisable.

Utilisateurs	BF16 d/u	FP8 d/u	NVFP4 d/u	NVFP4 TTFT
1	28.68	49.75	55.44	179 ms
5	14.32	25.56	34.63	427 ms
10	9.51	18.40	25.18	363 ms

Pour les flows d'agents, c'est assez tranché : BF16 n'est pas cassé, mais tu paies chaque output longue deux fois. D'abord en mémoire, ensuite en temps d'attente.

</details>

<details> <summary>Run H : baseline bureau open-loop</summary>

À partir d'ici, l'interprétation change. Les runs précédentes poussent des batches contrôlés à travers le modèle. La Run H utilise du trafic open-loop : les requests arrivent selon une distribution de Poisson. Le serveur doit donc gérer des arrivées qui n'attendent pas gentiment que la précédente soit finie.

Ça ressemble plus à un bureau. Pas parfait, mais mieux que tout le monde en même temps ou tout à fait séquentiel. Les metrics sont différentes aussi. Le TPOT dit à quelle vitesse les tokens arrivent une fois que c'est ton tour. Le TTFT P50 dit l'expérience normale. Le TTFT P99 dit ce que remarque le malchanceux.

Ici, FP8 devient intéressant. NVFP4 gagne la médiane et le TPOT, mais FP8 gagne la tail. C'est exactement pour ça que je ne veux pas finir avec "NVFP4 est toujours mieux".

Metric	BF16	FP8	NVFP4
Achieved RPS	0.26	0.28	0.29
Peak concurrent	42	18	15
TTFT P50	1229 ms	732 ms	618 ms
TTFT P99	2996 ms	2008 ms	3235 ms
TPOT P50	203 ms	74 ms	39 ms
Aggregate tok/s	1203	1297	1329

Ce peak concurrent de BF16 a l'air bon sur le papier, mais ne l'est pas. La queue monte parce que BF16 la vide moins vite. NVFP4 traite plus vite, donc moins de requests sont ouvertes en même temps. Ce n'est pas une capacité plus faible, c'est moins de file d'attente.

Le vrai choix est entre NVFP4 et FP8. Tu veux la meilleure médiane et l'output la plus rapide, alors NVFP4. Tu veux le P99 le plus propre sur ce workload, alors FP8.

</details>

<details> <summary>Run I : replay ShareGPT</summary>

Le replay ShareGPT est plus brouillon et donc utile. Les vraies conversations ont des longueurs variables, des questions de suivi, des réponses courtes, des réponses longues et des prompts qui n'ont pas été gentiment lissés par un auteur de benchmark.

C'est la run en laquelle j'ai le plus confiance pour le ressenti chat. Pas pour des documents d'entreprise, mais pour la question : qu'est-ce que ça donne quand plusieurs personnes mènent des conversations tout au long de la journée ?

Le pattern de la Run H tient. NVFP4 est le plus rapide pour l'utilisateur moyen. FP8 a le meilleur P99.

Metric	BF16	FP8	NVFP4
Peak concurrent	17	12	10
TTFT P50	433 ms	220 ms	157 ms
TTFT P99	713 ms	422 ms	1361 ms
TPOT P50	118 ms	38 ms	26 ms

NVFP4 donne une impression instantanée pour la plupart des utilisateurs : 157 ms de TTFT P50 et 26 ms de TPOT P50. Mais le P99 est de 1361 ms, là où FP8 reste à 422 ms. C'est une grosse différence.

Pour un chat interne où une seule request plus lente n'est pas un drame, je choisis NVFP4. Pour une UI produit avec une promesse de latence dure, je prendrais FP8 plus au sérieux.

</details>

<details> <summary>Run J : pic du lundi matin</summary>

La Run J est en oversubscribe. La cible est de 1,5 requests par seconde avec une concurrency-cap de 25. Ce n'est pas la journée de travail normale. C'est le test de ce qui se passe quand la demande est plus grande que ce que le serveur peut suivre proprement.

En oversubscribe, je regarde d'abord l'achieved RPS. Pas le configured RPS, parce qu'il est le même pour tout le monde. La question est : combien de requests le serveur traite réellement pendant qu'il est sous pression ?

Là, NVFP4 gagne clairement. FP8 garde la tail plus propre, mais NVFP4 fait passer beaucoup plus de travail par la machine.

Metric	BF16	FP8	NVFP4
Configured RPS	1.50	1.50	1.50
Achieved RPS	0.25	0.43	0.58
Peak concurrent	28	28	28
TTFT P50	1130 ms	757 ms	687 ms
TTFT P99	5184 ms	3388 ms	4462 ms
TPOT P50	197 ms	112 ms	82 ms
Aggregate tok/s	1118	1951	2622

Concrètement : NVFP4 traite environ 35 requests par minute. BF16 environ 15. C'est la différence entre une queue qui se vide lentement et une queue qui fait douter les utilisateurs s'ils doivent cliquer encore une fois. Ne clique pas. Ce deuxième clic n'aide jamais.

</details>

Les trois précisions côte à côte

Si je dois choisir une run de chat réaliste, je prends le replay ShareGPT. C'est là que tu vois la distinction le plus proprement : NVFP4 gagne l'expérience normale, FP8 gagne la tail, BF16 participe mais ne convainc nulle part.

Metric	BF16	FP8	NVFP4	Meilleur choix
TPOT P50	118 ms	38 ms	26 ms	NVFP4
TTFT P50	433 ms	220 ms	157 ms	NVFP4
TTFT P99	713 ms	422 ms	1361 ms	FP8
Peak concurrent	17	12	10	NVFP4
Achieved RPS	0.30	0.30	0.30	égalité

En oversubscribe, la différence se durcit :

Metric	BF16	FP8	NVFP4	Meilleur choix
Achieved RPS	0.25	0.43	0.58	NVFP4
TTFT P50	1130 ms	757 ms	687 ms	NVFP4
TTFT P99	5184 ms	3388 ms	4462 ms	FP8
TPOT P50	197 ms	112 ms	82 ms	NVFP4
Aggregate tok/s	1118	1951	2622	NVFP4

Ça rend le choix plus pratique que je ne le pensais au départ. NVFP4 est le default si tu veux du throughput et une expérience utilisateur normale. FP8 est le choix si tu trouves le P99 plus important que la médiane. BF16 est la baseline qui te sert à vérifier si la quantization démolit ton accuracy.

Pourquoi FP8 gagne le P99

Mon hypothèse : NVFP4 donne à vLLM plus de place mémoire et donc plus de place pour le batching. Ça augmente le throughput et baisse le TPOT, mais des requests individuelles peuvent parfois attendre plus longtemps avant de tomber proprement dans un batch.

FP8 a moins de headroom que NVFP4, mais encore assez pour ce workload. Du coup, le scheduler semble plus prévisible. Moins agressif, moins rapide en médiane, meilleur dans la tail.

BF16 a le pire des deux mondes : gros weights, moins de headroom KV-cache et un decode plus bas. La queue se remplit, mais pas parce que le serveur encaisse tant en même temps. Il en vient juste à bout moins vite.

Je veux creuser ça davantage avec des réglages de scheduler et du prefix caching. Les chiffres bruts et les définitions des tests sont dans l'arena pour que je puisse mesurer les futures runs à la même barre.

Comparaison avec Gemma-4-26B-A4B

Nemotron-NVFP4 est en single-user presque deux fois plus rapide que Gemma-NVFP4. En multi-user, la différence se réduit, mais reste en général positive.

Workload	Gemma-NVFP4 d/u	Nemotron-NVFP4 d/u	Ratio
pp4096 c=1	30.01	60.30	2.0×
pp8192 c=1	29.35	55.72	1.9×
pp25000 c=1	28.00	54.98	2.0×
pp4096 c=10	17.05	19.69	1.2×
pp25000 c=10	7.61	12.99	1.7×

Ce pattern colle à ce qu'est le modèle. Nemotron a 3B de params actifs, Gemma 4B de params actifs. En single-user, ça aide beaucoup. En multi-user, le bottleneck se déplace vers la memory bandwidth et le scheduling, et là la différence se réduit.

Ce que ça veut dire pour l'IA on-prem

Mon choix par défaut pour ce Spark, c'est NVFP4. Pas parce que 4 bits est par principe plus joli, mais parce que les chiffres sur ces workloads le portent : throughput le plus élevé, médiane la plus rapide, TPOT le plus bas, footprint le plus petit.

Je choisis FP8 quand la tail-latency compte plus que la médiane. Pense à une UI où tu veux pouvoir dire que 99 pour cent des requests démarrent dans une certaine limite. Dans les Runs H, I et J, FP8 gagne de façon constante sur le TTFT P99.

Je choisis BF16 seulement comme baseline ou pour de la validation accuracy-critique. Pas comme default de production. Pour ça, c'est trop cher sur le Spark : environ trois fois plus de mémoire que NVFP4 et grosso modo la moitié de la vitesse.

Pour un bureau de 25 personnes avec un workload chat et type RAG, je ferais tourner NVFP4, avec une suite d'eval maison à côté. Pour un chatbot externe avec une promesse de latence serrée, je testerais FP8. Pour BF16, je garderais surtout une run courte pour voir ce que la quantization change sur le fond.

Ce que ces runs ne disent pas

Pas de tests d'accuracy. FP8 et NVFP4 peuvent diverger sur le fond de BF16. Pour la production, tu dois mesurer ça sur tes propres documents, tes propres prompts et ta propre tolérance aux erreurs.

Pas de benchmarks multimodal. Nemotron-3-Nano-Omni est multimodal-aware, mais ces runs sont text-only. La vision et l'audio restent hors champ ici.

Pas de comparaison avec des modèles dense. C'est un modèle MoE. Les modèles dense donnent un ressenti différent, surtout sur la vitesse d'output et la façon dont vLLM les gère.

Pas de conclusion définitive sur le scheduler. La tail FP8-vs-NVFP4 est assez intéressante pour la tester à part avec d'autres réglages de batching et de scheduling.

Où j'atterris

Le choix de précision n'est pas un détail. Sur le Spark, il détermine si la même machine donne l'impression d'une expérience locale ou de quelque chose que tu peux confier à des collègues sans devoir expliquer toutes les cinq minutes.

NVFP4 double dans beaucoup de runs l'expérience utilisable par rapport à BF16. FP8 est moins spectaculaire, mais plus prévisible dans la tail. BF16 reste utile comme point de référence, pas comme terminus.

La leçon pratique de ces trois posts pris ensemble : suis les recettes du vendor, fais tourner l'image stable et mesure ton propre workload. Ne bricole pas toi-même sauf si tu as une bonne raison. Avec Gemma, j'avais une raison. Avec le recul, elle était médiocre.

Gemma-4 sur le DGX Spark : le prix du contexte

2026-05-01T00:00:00.000Z

Je voulais savoir comment un DGX Spark se comporte comme machine d'IA locale pour un environnement de bureau.

Pas en théorie. Juste : charger Gemma-4-26B-A4B-it dans vLLM, lui balancer llama-benchy, agrandir les context windows, allonger l'output, monter la concurrency, ajouter du multi-turn, et regarder où ça reste agréable et où l'attente commence à faire mal. Et quand cette histoire a commencé à se dessiner, une deuxième question est arrivée : et si je n'effectue plus mes tests en lockstep, mais que je laisse les requêtes arriver de façon organique, comme dans un vrai bureau ? Pour ça j'ai pris la suite de benchmark de vLLM elle-même, qui fait ce que llama-benchy ne fait pas : arrivées de Poisson, percentiles, vraies données de conversation. Comment je mesure tout ça, c'est dans la methodologie.

La version courte : pour un usage de bureau normal, ça a l'air bon. Des prompts courts à moyens, des outputs plus longs, et même des conversations sur plusieurs tours restent rapides au ressenti, même avec dix utilisateurs en même temps. Avec de grands context windows, le problème n'est pas les tokens par seconde, mais combien de temps quelqu'un fixe une fenêtre de chat vide avant que le premier token n'arrive. Et si tu surcharges vraiment la machine, elle ne scale pas, elle met en file.

Ça n'en fait pas une histoire de "le DGX Spark y arrive ou pas". Ça en fait une histoire de workload. Neuf tests, deux méthodes, une machine. C'est l'un des build logs sous le guide faire tourner des LLMs sur le DGX Spark.

Pourquoi ce test

Avec l'IA on-prem, tu en viens vite à parler de vie privée, de garder les données plus près et d'être moins dépendant de modèles hébergés. Tout ça est vrai, mais finalement une question plus plate suit.

La machine peut-elle encaisser ?

Un modèle local qui répond proprement à un seul prompt de démo, c'est sympa. Mais la production ressemble rarement à ça. Là tu as plusieurs utilisateurs, un contexte plus grand, des agent flows, des tool-calls, des retries et parfois quelqu'un qui colle un demi-roman dans un ticket.

C'est pourquoi je ne voulais pas mesurer uniquement les tokens par seconde sur un seul prompt. Je voulais voir ce qui se passe quand on charge la machine sous différents angles : de "dix utilisateurs, prompts courts, longues réponses" à "dix utilisateurs, conversations de cinq tours, mémoire croissante" jusqu'à "des requêtes qui arrivent de façon organique comme dans un vrai bureau, pas toutes en même temps et pas toutes du même format".

Pour ces benchmarks j'ai testé un seul modèle :

google/gemma-4-26B-A4B-it
BF16
DGX Spark, NVIDIA GB10, 128 GB unified memory
vLLM comme endpoint compatible OpenAI

Le dense viendra plus tard. MoE vs dense aussi. Cet article ne parle que de Gemma-4-26B-A4B-it sur le DGX Spark. Ce run tourne en BF16 ; ce qui arrive au même Gemma-4 quand tu quantises en NVFP4 est une autre histoire.

Ce que j'attendais au départ

Mon attente était simple : le MoE resterait raisonnablement bon sous requêtes concurrentes, mais je pensais que le DGX Spark atteindrait ses limites plus vite dès que le contexte deviendrait grand.

Surtout à 25k de contexte.

Le contexte coûte cher. Tu payes non seulement le prompt qui entre, mais aussi le KV-cache que vLLM doit tenir à jour. Multiplie ça par plusieurs utilisateurs et ça devient d'un coup un problème de mémoire et un problème de file d'attente.

J'étais curieux de cinq choses :

le decode reste-t-il utilisable quand le contexte grandit ?
combien le prefill ajoute-t-il au temps jusqu'au premier token ?
que se passe-t-il quand le prompt est court mais l'output long ?
comment se comporte-t-il avec des conversations multi-turn, où le contexte s'épaissit à chaque tour ?
et (ajouté seulement plus tard) à quoi ressemble tout ça quand les requêtes n'arrivent pas en lockstep, mais de façon organique ?

Cette dernière question s'est révélée être la moitié de l'histoire.

L'installation de test

Le serveur tournait dans Docker avec l'image officielle de vLLM :

docker run -d --name vllm-bench \
  --gpus all --ipc=host \
  -v appliance_hf-cache:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:v0.20.1 \
  --model google/gemma-4-26B-A4B-it \
  --served-model-name gemma-4-26b-a4b-bf16 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --limit-mm-per-prompt '{"image":0,"audio":0}' \
  --async-scheduling \
  --no-enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

Quelques détails comptent.

Le prefix caching est volontairement coupé. Je voulais d'abord voir le coût brut du prefill, pas un benchmark qui s'embellit parce que les prompts se ressemblent.

Le KV-cache tourne en fp8. Sans ça, 128k de contexte avec plusieurs requêtes en même temps devient vite un exercice de mémoire dont tu ne tires pas grand-chose.

Les neuf tests ci-dessous utilisent exactement cette config serveur. Pas de redémarrage, pas d'ajustement en cours de route. Ce qui varie, c'est le workload : taille du prompt, taille de l'output, concurrency, depth, et pour les tests open-loop aussi l'arrival rate et la burstiness.

Ce que le Spark en fait :

Composant	Valeur
Model weights (BF16)	~48 GB
KV-cache headroom (fp8)	~65 GB
Parallele theorique @ 128k	~4 requests
Parallele theorique @ 8k	~50 requests

À plein contexte par requête, la mémoire est juste. En pratique aucun test n'utilise 128k en même temps par utilisateur, donc le goulot se déplace vers le prefill-compute et le scheduler-batching. On le retrouve ci-dessous.

Run A : agrandir le contexte

Le premier run faisait grandir le contexte de 4k à 25k. La concurrency suivait de 1 à 5 et 10. Closed-loop, donc N utilisateurs en lockstep.

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model gemma-4-26b-a4b-bf16 \
  --pp 4096 8192 16384 25000 \
  --tg 256 \
  --depth 0 \
  --concurrency 1 5 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

pp c'est le prefill, c'est-à-dire combien de prompt tokens entrent. tg c'est le decode, c'est-à-dire combien de tokens le modèle génère ensuite. llama-benchy rapporte mean ± stddev. Pas de p95. C'est important à retenir, car sur la latence tu te racontes sinon vite des histoires.

Voici le résumé du Run A :

Contexte	Users	Prefill total	Decode/user	Decode total	TTFT
4k	1	3677.85 ± 1259.27 tok/s	24.08 ± 0.02 tok/s	24.08 ± 0.02 tok/s	1.37 ± 0.52s
4k	5	5722.96 ± 94.70 tok/s	12.55 ± 0.49 tok/s	57.07 ± 2.64 tok/s	2.29 ± 0.82s
4k	10	5475.53 ± 888.14 tok/s	9.48 ± 0.73 tok/s	84.40 ± 3.08 tok/s	4.46 ± 2.38s
8k	1	6121.87 ± 62.31 tok/s	23.69 ± 0.02 tok/s	23.69 ± 0.02 tok/s	1.39 ± 0.01s
8k	5	5444.57 ± 12.82 tok/s	11.48 ± 0.92 tok/s	49.42 ± 1.60 tok/s	4.34 ± 1.91s
8k	10	5478.98 ± 11.48 tok/s	8.52 ± 1.10 tok/s	67.72 ± 0.91 tok/s	7.99 ± 4.03s
16k	1	4607.64 ± 23.05 tok/s	23.34 ± 0.05 tok/s	23.34 ± 0.05 tok/s	3.42 ± 0.00s
16k	5	4466.35 ± 27.19 tok/s	10.05 ± 1.75 tok/s	38.41 ± 0.12 tok/s	10.43 ± 4.69s
16k	10	4453.92 ± 18.19 tok/s	6.79 ± 1.62 tok/s	45.76 ± 0.43 tok/s	18.92 ± 9.43s
25k	1	3621.25 ± 18.50 tok/s	22.75 ± 0.08 tok/s	22.75 ± 0.08 tok/s	6.39 ± 0.05s
25k	5	3561.78 ± 9.23 tok/s	8.46 ± 2.36 tok/s	27.93 ± 0.08 tok/s	19.63 ± 8.87s
25k	10	3565.35 ± 8.21 tok/s	5.40 ± 2.00 tok/s	30.73 ± 0.12 tok/s	35.67 ± 18.00s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-a-ttfr.webp" width="1425" height="878" loading="lazy" decoding="async" alt="Run A : TTFT vs contexte, une ligne par utilisateurs concurrents (1, 5, 10). Le TTFT grimpe de ~1.4 secondes a 4k jusqu'a 36 secondes a 25k de contexte avec 10 users." /> <figcaption>Run A : temps d'attente du premier token, par utilisateurs concurrents. Double le prompt et tu doubles l'attente.</figcaption> </figure>

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-a-decode.webp" width="1425" height="878" loading="lazy" decoding="async" alt="Run A : vitesse de decode par utilisateur vs contexte. A c=1 le decode reste entre 22.7 et 24.1 tokens par seconde, a c=10 il descend de 9.5 a 5.4 tokens par seconde." /> <figcaption>Run A : decode par utilisateur. Avec un seul utilisateur ça reste presque plat ; ce n'est qu'avec plusieurs users et un grand contexte que ça s'effondre.</figcaption> </figure>

Run B : tenir 25k de contexte, monter la concurrency

Ensuite j'ai poussé le même contexte 25k plus fort. Plus de variation du contexte, juste ajouter des utilisateurs.

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model gemma-4-26b-a4b-bf16 \
  --pp 25000 \
  --tg 256 \
  --depth 0 \
  --concurrency 5 10 20 \
  --runs 3 \
  --latency-mode generation \
  --exit-on-first-fail \
  --format md

Pas d'OOM. Pas de crash. Le DGX Spark a survécu à 20 requêtes concurrentes à 25k de contexte.

Users	Prefill total	Decode/user	Decode total	TTFT
5	3559.17 ± 6.72 tok/s	8.51 ± 2.40 tok/s	27.88 ± 0.05 tok/s	19.86 ± 9.00s
10	3569.77 ± 2.99 tok/s	5.37 ± 1.99 tok/s	30.68 ± 0.09 tok/s	35.44 ± 17.95s
20	3563.64 ± 8.78 tok/s	3.16 ± 1.41 tok/s	32.26 ± 0.10 tok/s	67.37 ± 36.44s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-b-prefill-wall.webp" width="1522" height="843" loading="lazy" decoding="async" alt="Run B : le TTFT croit lineairement avec la concurrency : 19.9s a 5 users, 35.4s a 10, 67.4s a 20. Le decode agrege reste autour de 30 tok/s." /> <figcaption>Run B : le decode agrégé reste à ~30 tok/s ; toute l'attente supplémentaire passe dans le TTFT.</figcaption> </figure>

C'est le bord de stress du benchmark. Le decode agrégé reste autour de 30 tok/s, que tu mettes 5, 10 ou 20 utilisateurs. Par utilisateur il descend de 8.51 à 3.16 tok/s. Mais le vrai problème c'est le TTFT : à 20 utilisateurs la requête moyenne attend 67 secondes avant que le premier token n'arrive. Le serveur n'est pas cassé pour autant. Le workload ne colle juste plus à une attente de chat en temps réel.

Run C : prompt court, output long

Le Run C a inversé la forme. Pas 25k de contexte avec output court, mais 1024 prompt tokens et 1024 output tokens.

Users	Prefill total	Decode/user	Decode total	TTFT
1	4627.12 ± 374.91 tok/s	23.86 ± 0.03 tok/s	23.86 ± 0.03 tok/s	0.31 ± 0.02s
5	5701.55 ± 561.36 tok/s	13.59 ± 1.05 tok/s	54.67 ± 4.90 tok/s	0.76 ± 0.11s
10	6346.87 ± 64.52 tok/s	10.92 ± 0.73 tok/s	86.46 ± 1.74 tok/s	1.26 ± 0.40s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-c-grouped.webp" width="1227" height="777" loading="lazy" decoding="async" alt="Run C : le decode par utilisateur descend de 23.9 (c=1) a 10.9 (c=10), le decode agrege grimpe a 86.5 tok/s." /> <figcaption>Run C : prompt court, output long. Le decode agrégé scale proprement jusqu'à 86 tok/s, le par-utilisateur reste largement lisible.</figcaption> </figure>

À dix utilisateurs en même temps, le TTFT reste à 1.3 seconde. Ça ressemble à du chat.

Run G : output encore plus long

Les Run A, B et C montraient assez pour rendre plausible l'histoire "le decode est stable, le prefill décide de l'attente". Mais un scénario restait ouvert : et si l'output est encore beaucoup plus long ? Un agent qui génère du code. Un tool-call avec output structuré. Un long résumé.

Users	Prefill total	Decode/user	Decode total	TTFT
1	1993.94 ± 262.05 tok/s	24.17 ± 0.02 tok/s	24.17 ± 0.02 tok/s	0.24 ± 0.01s
5	3048.28 ± 496.15 tok/s	14.32 ± 2.18 tok/s	46.11 ± 11.57 tok/s	0.38 ± 0.07s
10	4800.80 ± 50.75 tok/s	11.75 ± 0.68 tok/s	83.77 ± 4.04 tok/s	0.48 ± 0.01s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-g-grouped.webp" width="1227" height="777" loading="lazy" decoding="async" alt="Run G : decode par utilisateur 24.2 (c=1), 14.3 (c=5), 11.8 (c=10) ; agrege 24.2, 46.1, 83.8 tok/s." /> <figcaption>Run G : output 4k : les longues générations sont seulement plus longues, pas plus lentes. Le par-utilisateur reste proche du Run C.</figcaption> </figure>

Le decode/user sur 4096 tokens baisse à peine comparé aux 1024 tokens du C. À c=1 c'est 24.17 (G) vs 23.86 (C). À c=10 c'est 11.75 (G) vs 10.92 (C). Les longues générations ne se cumulent pas, elles durent juste proportionnellement plus longtemps. Et le TTFT est le plus bas ici : sous la demi-seconde à dix utilisateurs en même temps.

Run F : contexte moyen, plus d'utilisateurs

Entre le Run C (1k de contexte) et le Run B (25k de contexte) se trouvait un trou plus proche de la réalité. Un flow RAG typique avec quatre chunks de ~2k tokens arrive autour de 8k.

Users	Prefill total	Decode/user	Decode total	TTFT
5	5439.51 ± 32.60 tok/s	12.11 ± 0.51 tok/s	55.21 ± 1.49 tok/s	4.32 ± 1.90s
10	5466.71 ± 15.65 tok/s	9.31 ± 0.77 tok/s	78.36 ± 1.61 tok/s	7.99 ± 4.02s
20	5532.74 ± 5.39 tok/s	6.05 ± 0.62 tok/s	97.35 ± 3.50 tok/s	14.61 ± 7.72s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-f-ttfr.webp" width="1522" height="843" loading="lazy" decoding="async" alt="Run F : 8k de contexte. Le TTFT monte de 4.3s (c=5) a 8.0s (c=10) a 14.6s (c=20) ; le decode agrege atteint 97.4 tok/s." /> <figcaption>Run F : 8k de contexte. Le TTFT croît linéairement avec la concurrency, le decode agrégé continue de scaler jusqu'à presque 100 tok/s.</figcaption> </figure>

Trois observations.

Le prefill throughput reste à un plat 5.5k tok/s, que ce soit 5, 10 ou 20 utilisateurs. À 8k de contexte la machine est déjà saturée au niveau du prefill. Le decode agrégé continue de scaler : dans le Run B (25k) ça plafonnait à ~30 t/s, ici ça monte jusqu'à 97.4 t/s. Et le plus important : le TTFT à 8k de contexte est grosso modo un quart de ce qu'il est à 25k. Même concurrency, même machine, taille de prompt différente.

Run E : le multi-turn comme vrai travail de bureau

--depth 4 signifie : cinq tours d'affilée par requête (initial + quatre questions de suivi). Concurrency à 10 signifie : dix de ces conversations en parallèle.

Users	Prefill total	Decode/user	Decode total	TTFT
1	4716.21 ± 542.88 tok/s	23.97 ± 0.10 tok/s	23.97 ± 0.10 tok/s	0.53 ± 0.06s
5	5693.39 ± 128.08 tok/s	13.07 ± 0.16 tok/s	59.48 ± 2.26 tok/s	1.32 ± 0.39s
10	6096.81 ± 56.92 tok/s	10.43 ± 0.35 tok/s	92.42 ± 3.33 tok/s	2.13 ± 0.83s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/run-e-multiturn.webp" width="1242" height="777" loading="lazy" decoding="async" alt="Run E : multi-turn. Par-utilisateur 24.0/13.1/10.4 tok/s, agrege 24.0/59.5/92.4 tok/s, le plus haut agrege de tous les runs closed-loop." /> <figcaption>Run E : multi-turn (depth = 4) à 2k de contexte de départ. L'agrégé de 92 tok/s est le plus haut chiffre des six runs closed-loop.</figcaption> </figure>

Trois choses ont attiré l'attention, que je n'avais pas prévues au départ.

Le decode par utilisateur en multi-turn est identique au single-turn. Le multi-turn ne rend pas les tokens plus lents, seul le nombre de prefills augmente. Le decode agrégé à c=10 est de 92.42 t/s, le plus haut de n'importe quel run closed-loop. En multi-turn, vLLM reçoit un flux plus dense de requêtes dépendantes, et peut les batcher plus efficacement que dix prompts single-shot séparés. Et le TTFT à c=10 est en moyenne de 2.13 secondes sur les cinq tours. Sous trois secondes, ça ressemble encore à du chat.

Ce que les six runs closed-loop montrent ensemble

Un tableau qui met tout côte à côte à c=10 :

Run	Prompt	Output	Depth	TTFT (c=10)	Decode/user (c=10)	Decode agrege (c=10)
G	256	4096	0	0.48s	11.75 t/s	83.8 t/s
C	1024	1024	0	1.26s	10.92 t/s	86.5 t/s
E	2048	512	4	2.13s	10.43 t/s	92.4 t/s
F	8192	512	0	7.99s	9.31 t/s	78.4 t/s
A	16384	256	0	18.92s	6.79 t/s	45.8 t/s
A/B	25000	256	0	35.67s	5.40 t/s	30.7 t/s

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/summary-c10.webp" width="1569" height="944" loading="lazy" decoding="async" alt="Nuage de points des six runs closed-loop a c=10. Axe Y decode/user (5 a 12 tok/s), axe X TTFT logarithmique (0.5s a 49s). G et C en haut a gauche, A-25k en bas a droite." /> <figcaption>Les six runs closed-loop à 10 utilisateurs concurrents. Le decode par utilisateur bouge à peine jusqu'à 8k de contexte. Le TTFT bouge partout.</figcaption> </figure>

Deux motifs ressortent.

Le decode/user bouge à peine jusqu'à 8k de contexte. Entre le Run G et le Run F il y a un facteur 32 sur la taille du prompt et un facteur 8 sur la taille de l'output. Pourtant le decode/user y reste entre 9.3 et 11.8 tok/s. Ce n'est qu'à 16k+ que cette bande s'effondre.

Le TTFT bouge partout et est presque une fonction de la seule taille du prompt. Double le prompt et le TTFT double grosso modo avec. La taille de l'output et le depth ne comptent presque rien pour le TTFT.

C'est la conclusion closed-loop. Elle tient, et elle raconte une vraie partie de l'histoire. Mais il y a un trou dedans.

Mais ce sont des tests synthétiques

Les six runs ci-dessus testent la capacité. Des plafonds. Tous dans la même forme : N utilisateurs en lockstep, tous le même format de prompt, tous appuyant sur les boutons d'envoi en même temps. C'est une bonne façon de mesurer où ça casse. C'est une mauvaise façon de mesurer ce que ressent un vrai bureau.

Parce qu'un vrai bureau a 25 employés dont quelques-uns en moyenne font quelque chose en même temps. Un collègue pose une question courte. Un autre est en plein RAG avec 8k de contexte. Le troisième est au tour 4 d'une conversation. Et les requêtes n'arrivent pas en lockstep. Elles arrivent comme un processus de Poisson avec de temps en temps un burst, parce que quelqu'un vient de finir un mail et que trois collègues veulent un café en même temps.

C'est ce que vllm bench serve de vLLM sait faire et que llama-benchy ne sait pas :

Open-loop avec arrival rate. Dispatcher les requêtes selon une distribution de Poisson ou de Gamma, au lieu du lockstep.
Percentiles. P50, P90, P95, P99 sur TTFT, TPOT (time per output token), ITL (inter-token latency) et E2E. Fini les mean ± stddev.
Datasets réalistes. Replay ShareGPT de 94k+ vraies conversations avec des longueurs de prompt qui varient naturellement et une structure multi-turn.
Workloads mixtes. Échantillonner des prompts depuis une distribution au lieu de tester une seule forme fixe.

Trois tests ci-dessous, le même serveur (pas de redémarrage), mais avec ces autres lunettes sur le nez.

Test H : baseline de bureau réaliste

Le scénario : 25 personnes actives en moyenne, chacune envoie un prompt à peu près une fois toutes les 1-2 minutes, les prompts varient fortement en longueur. Les arrivées sont légèrement clumpy.

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model google/gemma-4-26B-A4B-it \
  --tokenizer google/gemma-4-26B-A4B-it \
  --served-model-name gemma-4-26b-a4b-bf16 \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 200 \
  --request-rate 0.3 \
  --burstiness 0.7 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

Avec --random-range-ratio 0.9, les longueurs d'input varient de 399 à 7600 tokens, les outputs de 49 à 950. --burstiness 0.7 est un peu plus clumpy que du Poisson pur. Les gens appuient souvent sur entrée par petites rafales, pas comme un métronome. Target rate de 0.3 req/s = ~18 prompts/min sur 25 utilisateurs.

Metric	Valeur
Successful requests	200 / 200
Achieved RPS	0.27 (target 0.30)
Peak concurrent requests	36
Total token throughput	1215 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	1395	1286	2284	2644	3316
TPOT (ms)	177	182	193	202	214
E2E (ms)	85921	85306	150192	162375	171351

L'utilisateur médian reçoit le premier token en 1.29s. Ça ressemble encore à du chat. Le tail reste dans les clous : le P99 attend 3.3 secondes, largement sous le double de la moyenne.

Et regarde le peak concurrent : 36. À un target rate de seulement 0.3 req/s. Aucun run closed-loop n'en approchait. La seule burstiness de Poisson, combinée à un temps de réponse moyen de ~86 secondes, produit des pics plus violents que n'importe quel stress-test du Run B. C'est la chose que le closed-loop ne peut littéralement pas montrer.

Test I : vraies conversations (replay ShareGPT)

Pattern d'arrivée identique au Test H, mais maintenant avec 250 vraies conversations multi-turn de ShareGPT V3 comme prompts. Certaines sont 1 tour de 200 tokens, d'autres sont 15 tours avec un contexte qui grandit à chaque fois.

docker exec vllm-bench vllm bench serve \
  ... \
  --dataset-name sharegpt \
  --dataset-path /tmp/ShareGPT_V3.json \
  --num-prompts 250 \
  --request-rate 0.3 \
  --burstiness 0.7

Metric	Valeur
Successful requests	250 / 250
Achieved RPS	0.30 (target 0.30)
Peak concurrent requests	17
Total token throughput	133 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	376	353	469	509	637
TPOT (ms)	93	95	117	123	135
E2E (ms)	19600	10923	49525	63036	82596

C'est un autre univers que le Test H. TTFT P99 = 637 ms. 99% des utilisateurs voient le premier token en moins de 650 millisecondes. C'est vraiment une vitesse de chat.

Pattern d'arrivée identique au Test H, expérience totalement différente. La différence tient entièrement à la taille du prompt : les conversations ShareGPT font en moyenne 228 tokens, pas 4000. Prompt court = prefill bon marché = pas de pression de file = TTFT sous la seconde.

Metric	Test H (random 4k)	Test I (ShareGPT)
Achieved RPS	0.27	0.30
Peak concurrent	36	17
TTFT P50	1286 ms	353 ms
TTFT P99	3316 ms	637 ms
TPOT P50	182 ms	95 ms

C'est aussi un avertissement : le workload synthétique du Test H exagère le poids d'un prompt de bureau moyen. Les conversations du monde réel sont plus légères que notre baseline random 4k, donc les chiffres de la pratique sont probablement plus proches du Test I que du Test H.

Test J : pic du lundi matin

Et si tout le monde arrive en même temps et se met à appuyer sur les boutons d'envoi ? Cinq fois la charge, max 25 requêtes concurrentes pour modéliser un vrai bureau.

docker exec vllm-bench vllm bench serve \
  ... \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 300 \
  --request-rate 1.5 \
  --burstiness 1.0 \
  --max-concurrency 25

Metric	Valeur
Successful requests	300 / 300
Configured RPS	1.50
Achieved RPS	0.26
Peak concurrent requests	27
Total token throughput	1173 tok/s

	Mean	P50	P90	P95	P99
TTFT (ms)	1370	1132	1932	2961	6157
TPOT (ms)	185	187	195	199	221
E2E (ms)	92752	91099	165179	172073	179139

C'est le chiffre clé : achieved rate 0.26 à un target de 1.5. Le système est throttle de presque 6x. Pas parce qu'il crashe (les 300 requêtes réussissent, aucun échec), mais parce que la file se remplit jusqu'à 25 et y retient les requêtes jusqu'à ce qu'il y ait de la place.

Compare le Test H (target 0.3) et le Test J (target 1.5) :

Metric	Test H (0.3 rps)	Test J (1.5 rps)
Achieved RPS	0.27	0.26
TTFT P50	1286 ms	1132 ms
TTFT P95	2644 ms	2961 ms
TTFT P99	3316 ms	6157 ms
TPOT P50	182 ms	187 ms

L'expérience médiane est même légèrement meilleure au Test J qu'au Test H (1.13s vs 1.29s). Le cap crée un flux plus régulier. Mais le tail est dramatiquement pire : le P99 double, de 3.3s à 6.2s.

<figure class="breakout-wide"> <img src="/blog/gemma-4-dgx-spark/open-loop-ttft.webp" width="1425" height="882" loading="lazy" decoding="async" alt="Percentiles de TTFT open-loop pour H (random 4k 0.3 rps), I (ShareGPT 0.3 rps) et J (random 4k 1.5 rps). I reste sous la seconde partout ; H monte jusqu'a 6.4s P99 ; J file jusqu'a 14.8s P99." /> <figcaption>Percentiles de TTFT open-loop. La médiane dit peu ; le tail raconte où la surcharge fait mal.</figcaption> </figure>

Le Spark ne scale pas sous oversubscribe, il met en file. C'est une bonne nouvelle : degradation gracieuse au lieu de crashes. Pour l'IA on-prem c'est vraiment le meilleur failure mode.

Ce que le closed-loop cache, ce que l'open-loop exagère

Les deux méthodes racontent chacune une partie différente de l'histoire. Toutes les deux vraies, toutes les deux incomplètes.

Le closed-loop sous-estime la profondeur de la file.

Dans le Run F j'ai testé c=10 comme "dix utilisateurs en même temps". Ça sonne comme une situation de bureau raisonnablement chargée. Mais le Test H montre qu'un arrival rate organique de 0.3 req/s suffit déjà à produire des pics de 36 requêtes concurrentes. La revendication closed-loop "10 utilisateurs" est donc plus optimiste que ce que la pratique montre.

L'open-loop avec du synthétique exagère la charge réelle.

En même temps : le Test H utilise des prompts random 4k. Un vrai bureau ne pose pas 25 prompts moyens de 4k par minute. ShareGPT (Test I) est un bien meilleur proxy de "ce que les gens tapent", en moyenne 228 tokens. Avec cette forme de workload, le peak concurrent est de 17 au lieu de 36, et le P99 TTFT de 637ms au lieu de 3.3s.

La pratique se situe donc entre le Run F et le Test I :

Source	TTFT (P50 ou mean)	Peak concurrent
Run F (closed-loop, 10 users, 8k)	7.99 s	10
Test H (open-loop, 0.3 rps, 4k random)	1.29 s P50 / 3.3s P99	36
Test I (open-loop, 0.3 rps, ShareGPT)	0.35 s P50 / 0.64s P99	17
Test J (open-loop, 1.5 rps, 4k random, cap 25)	1.13 s P50 / 6.2s P99	27

Pour un bureau avec des prompts réalistes et un pattern d'arrivée réaliste, le Test I est le plus proche de ce que ressentent les gens. Pour la planification de capacité ("et si tout le monde pose une question RAG de 8k en même temps ?"), le Run F est le plus proche de ce que la machine peut digérer.

Le tail raconte ce que la moyenne cache

llama-benchy donnait seulement mean ± stddev. Ça a l'air de beaucoup d'information, mais ça cache la partie qui compte le plus pour tes utilisateurs : le tail.

Le mean TTFT du Test I est de 376ms. Ça a l'air bien. Mais qu'est-ce que ça dit du 1% d'utilisateurs où la file a justement grimpé ? Rien. Pour ça il te faut le P99, et il est à 637ms. Dans ce cas pas de problème (les deux sous la seconde), mais c'est le principe que tu dois connaître.

Le mean TTFT du Test H est de 1395ms. Le P99 est de 3316ms. Largement plus de deux fois pire que la moyenne pour le 1% malchanceux.

Le mean TTFT du Test J est de 1370ms. Le P99 est de 6157ms. Largement quatre fois la moyenne.

Pour les décisions de SLA ("notre système répond en moins de 3 secondes à 95% des requêtes") tu as besoin de ces percentiles. Mean ± stddev peut suggérer un SLA que tu ne tiens pas aux moments qui comptent le plus, c'est-à-dire quand c'est chargé.

C'est pourquoi le blog ne peut pas se reposer uniquement sur llama-benchy. Tester la capacité est une chose. Rapporter la tail latency en est une autre.

Le decode n'est pas le problème

Avec un seul utilisateur, le decode reste presque plat.

4k de contexte atteint 24.08 tok/s par utilisateur. 25k de contexte atteint 22.75 tok/s. 4096 output tokens (Run G, c=1) atteint 24.17 tok/s. Multi-turn avec depth 4 (Run E, c=1) atteint 23.97 tok/s. Quatre workloads différents, tous à moins de 6 pourcent les uns des autres.

À dix utilisateurs en même temps il se passe quelque chose de comparable, juste sur une ligne plus basse. Run G : 11.75 tok/s/user. Run C : 10.92. Run E : 10.43. Run F : 9.31. Et dans les tests open-loop : le Test I donne TPOT P50 = 95ms = ~10.5 tok/s/user. Les Test H et J donnent TPOT P50 = ~185ms = ~5.4 tok/s/user (parce que les pics y atteignent 25+ concurrent).

Bref : la vitesse de decode par token est une fonction de la charge concurrente moyenne, pas de la longueur du prompt, de la longueur de l'output, du multi-turn ou du pattern d'arrivée. Ce n'est qu'à 16k+ de contexte combiné à plusieurs utilisateurs (Run A) qu'elle descend vraiment sous 7 t/s/user.

La concurrency en soi n'est pas le problème. Le long output non plus. Le multi-turn non plus. Seul un grand contexte en même temps que plusieurs utilisateurs mange le decode.

Le prefill est le mur

Ce que tu sens en premier, c'est attendre.

Avec un seul utilisateur à 25k de contexte, il faut un bon 6 secondes avant que la première réponse arrive. À cinq utilisateurs ça devient 19.9 secondes. À dix ça devient 35.4 secondes. À vingt ça devient 67.4 secondes.

Le Run F montre que c'est linéaire à la fois en concurrency et en contexte. 8k de contexte à 20 utilisateurs donne 14.6 secondes, environ un quart des 67.4 secondes à 25k de contexte, pour la même concurrency. Coupe le prompt en deux, coupe l'attente en deux.

Et le Test J montre : dès que tu pousses le système au-delà de son plafond de débit, toute cette attente supplémentaire passe dans le tail. Le TTFT médian reste stable autour de 1.1-1.3s, mais le P99 file à 6 secondes. La douleur de la surcharge tombe sur un petit groupe, pas sur tout le monde.

C'est là que se trouve la vraie limite.

Pas : le DGX Spark peut-il générer des tokens ? Oui.

Pas : le KV-cache peut-il encaisser 20 × 25k ? Oui aussi.

Pas : s'arrête-t-il sous surcharge ? Non, il met gentiment en file.

Mais : ça ressemble-t-il encore à du chat ? Pas pour 25k. Pour 8k c'est déjà la zone grise. Pour 2k avec multi-turn tout simplement bien. Pour des prompts réalistes façon ShareGPT avec 25 utilisateurs répartis de façon organique : un oui limpide.

Où ça convient

Ces benchmarks rendent le choix on-prem plus concret.

Oui pour un environnement de bureau où 10 à 25 personnes utilisent de l'IA locale répartie sur la journée. Le Test I est la preuve : 250 vraies conversations ShareGPT, arrival rate de 0.3 req/s, P99 TTFT de 637ms. L'utilisateur médian voit le premier token en 353 millisecondes. C'est exactement le scénario de bureau, et voilà ce que ça donne au ressenti.

Oui pour des flows RAG avec contexte moyen. Le Run F a donné les chiffres au départ : prompt 8k, 10 users, TTFT 8s, streaming 9.3 tok/s. Le Test H confirme que la variante open-loop reste utilisable : P99 TTFT 3.3s. Pas du temps réel, mais dans des limites attendables.

Oui pour les agents et la génération de code. Le Run G est la confirmation : instruction courte, 4k+ tokens d'output, dix tâches parallèles. TTFT sous la demi-seconde, 11.75 tok/s/user.

Oui pour les conversations multi-turn. Le Run E donne 2.1s de TTFT à 10 conversations parallèles de 5 tours. Decode identique au single-turn.

Prudence avec 5+ utilisateurs à 25k de contexte en même temps. 19.9 secondes de TTFT ce n'est plus du chat, mais c'est utilisable pour des analyses.

Prudence avec les revendications de SLA basées sur des moyennes. Le mean TTFT de 1.4s du Test H pourrait sonner acceptable, mais le P99 est à 3.3s. Des décisions basées sur les percentiles, pas sur la moyenne.

Non pour un support-chat où dix à vingt utilisateurs envoient 25k de contexte par session en même temps et attendent tous une réponse en temps réel. Ou : un support-chat sous une charge façon Test J (1.5 rps de prompts 4k). Ça peut techniquement tourner (aucun échec), mais un P99 TTFT de 6 secondes est un cas limite pour du chat.

Ce que ces tests ne disent pas

Ce n'est pas une comparaison MoE-vs-dense. Je veux tester ça à part, et alors pas seulement avec du throughput. Si tu compares MoE et dense, tu dois aussi tester des prompts : résumer, questions de code, choix d'outil, classification de tickets, un long morceau de contexte avec étapes de suivi. Sinon tu mesures seulement à quel point le moteur tourne fort, pas s'il roule dans la bonne direction.

Ce n'est pas non plus un test avec le prefix caching activé. C'est volontaire. Je voulais voir le coût brut du prefill, pas un benchmark qui s'embellit parce que les prompts se ressemblent. Un prochain article l'ajoutera : ces mêmes runs de contexte 8k et 25k et les tests open-loop avec --enable-prefix-caching. Mon intuition : les Test H et J en profitent modestement (données random, peu de recouvrement), le Test I en profite sérieusement (les vraies conversations ont des system prompts et du contexte qui se recouvrent), et le Run F va sensiblement plus vite. Mais il faut le mesurer.

Là où j'atterris

Mon attente au départ était que le DGX Spark avec ce modèle MoE se remplirait plus tôt sur de grands context windows. C'est arrivé, mais autrement que je pensais.

La mémoire n'était pas le show-stopper. Le Run B a tenu 20 utilisateurs à 25k de contexte sans OOM. Le Test J a survécu à 1.5 req/s sans une seule requête échouée. La limite pratique était toujours dans la prefill-latency, pas dans la capacité.

Et après neuf tests il s'avère : c'est en fait la seule limite que tu sens.

Le decode/user est presque une constante pour cette machine. Entre 9 et 12 tokens par seconde à dix utilisateurs concurrents, dans six workloads closed-loop différents. En open-loop avec des prompts ShareGPT réalistes : 10.5 t/s/user. Ce n'est qu'à 16k de contexte ou à des pics synthétiques de 25+ concurrent que ça descend sous 7 t/s.

Ce qui varie, c'est combien de temps quelqu'un attend avant que le texte commence. À 256 prompt tokens c'est une demi-seconde, même avec dix utilisateurs. À 2048 prompt tokens avec cinq tours en moyenne 2.1 secondes. À 8192 prompt tokens avec dix utilisateurs huit secondes. À 25k avec dix utilisateurs 35 secondes. Sous une charge ShareGPT réaliste de 0.3 rps : 353 millisecondes pour la médiane, 637 millisecondes pour le 1% malchanceux.

Et dès que tu pousses le système au-delà de sa capacité, il ne scale pas, il met en file. Le Test J a montré qu'un target de 1.5 req/s se fait throttle à 0.26 achieved, avec la douleur entièrement dans le tail (P99 6.2s) tandis que la médiane reste stable. Pour l'IA on-prem c'est le meilleur failure mode que tu puisses espérer : personne ne crashe, certains attendent plus longtemps.

Ce n'est pas un "cette machine y arrive ou pas". C'est "choisis le workload qui correspond à ce que l'utilisateur attend, et accepte que 1% des requêtes ait une attente désagréable aux moments de pic".

Pour un à trois utilisateurs avec un grand contexte il est utilisable. Pour dix utilisateurs avec un contexte moyen il est très bien. Pour dix utilisateurs avec des conversations multi-turn il est en fait à son meilleur. Pour un bureau de 25 personnes avec des prompts réalistes et un pattern d'arrivée organique il est étonnamment bon : TTFT sous la seconde pour 99% des requêtes, mesuré sur de vraies données de conversation.

Pour des agent-flows avec de longs outputs il est solide. Pour vingt prompts 25k concurrents ou pour 1.5 rps d'oversubscribe ce n'est plus du chat en temps réel. Là tu dois mettre en file, activer le prefix caching, ou router ce type de travail autrement.

Deux méthodes mesurent deux choses. Les benchmarks closed-loop montrent ce que la machine peut faire. Le replay open-loop montre ce que l'utilisateur ressent. Le DGX Spark est une machine d'IA locale solide pour le travail de bureau, tant que tu sais quel bouton décide de ce que tu ressens.

Le decode vend le benchmark. Le prefill décide de l'expérience. Et dès que tu dépasses la limite, le Spark met en file au lieu de casser, et c'est le troisième chiffre qu'un choix on-prem doit pouvoir lire.

J'ai mis un assistant 24/7 sur un Raspberry Pi

2026-05-01T00:00:00.000Z

Je ne voulais pas un meilleur chatbot. Je voulais un agent qui prend du travail tout seul : aller sur internet, lire des tickets, plonger dans un repo, faire une première proposition de modifications de code et ensuite rendre compte là où mon équipe travaille déjà de toute façon.

L'entrée devait être Slack. C'est là que vivent les questions, les threads, les fichiers et les idées à moitié finies. L'agent devait pouvoir utiliser des tools, lire des fichiers, préparer des branches et continuer à tourner quand mon laptop se ferme.

Du coup il y a maintenant un Raspberry Pi 5 avec 4 GB RAM dans mon réseau. Dessus tourne OpenClaw. Slack devant, GPT-5.5 derrière, Tailscale comme porte d'accès quand je ne suis pas chez moi.

Ça sonne plus gros que ce que c'est. Le Pi ne fait pas tourner de modèle de langage local. OpenClaw utilise le Pi comme Gateway always-on : la couche qui reçoit les messages Slack, gère les sessions et le contexte du workspace, lance un agent-run, met des tools à disposition et renvoie la réponse dans le même thread. Dans cette config, le modèle tourne via OpenAI.

Cette distinction est importante. Pour de l'inference entièrement locale j'utilise le DGX Spark, et j'en ai parlé plus tôt dans le post sur la quantization. Ce Pi est la couche agent à côté : toujours allumé, joignable dans Slack, proche de mes fichiers et de mes workflows.

Le truc qui me manquait

J'utilise déjà assez d'outils AI. Claude Code pour construire. ChatGPT pour des questions isolées. Pour les projets clients je travaille avec des API de modèles ou des modèles locaux, selon ce que les données et l'infrastructure permettent.

La couche manquante se trouvait entre ces outils : un agent qui voit le travail arriver et commence déjà. Dans Slack ça peut démarrer petit. Je tape une instruction brouillonne, l'agent lit le repo, va chercher les bonnes règles de tone-of-voice et revient avec quelque chose que je peux évaluer.

Publier reste du travail manuel. La confiance aussi. Le premier travail préparatoire a le droit de se faire automatiquement.

La direction est plus grande que d'écrire des drafts. À terme je veux pouvoir désigner un ticket et dire : trouve ce qu'il faut ici. L'agent lit le contexte, vérifie la documentation, regarde dans la codebase, propose une approche et prépare éventuellement déjà une branche.

Ce travail-là reste souvent en plan parce qu'il ne rentre nulle part proprement. Trop petit pour un sprint. Trop gros pour le faire "vite fait". Avant que tu t'en rendes compte, ce ticket est encore ouvert une semaine plus tard avec les trois mêmes remarques vagues en dessous.

Ce qui tourne sur le Pi

La base est petite :

Raspberry Pi 5, 4 GB RAM
OpenClaw Gateway en local sur le Pi
OpenAI GPT-5.5 comme modèle dans cette config
Slack comme interface
Tailscale pour l'accès distant

Le Pi est surtout disponible ici. C'est son talent.

OpenClaw relie les couches entre elles : channel, session, agent-runtime, model-provider et tools. Un message Slack arrive par la couche channel. OpenClaw en prépare un agent-turn, avec le bon contexte et les bons tools. Le runtime exécute ce turn avec le modèle choisi. Ensuite OpenClaw renvoie la réponse via Slack.

De cette manière, le même agent peut lire des fichiers, lancer des shell-commands, récupérer des pages web, regarder le git-status ou préparer une PR, selon les tools que tu autorises. Le Pi n'est donc pas un mini-GPU. C'est la couche de contrôle locale.

Tailscale garde ça pratique. Je peux atteindre le Pi quand je suis en déplacement. Ouvrir un port public pour un build-log serait un peu trop d'honneur.

Slack comme atelier

Slack était le choix le plus facile parce que j'y suis déjà toute la journée. Mes entreprises ont des workspaces, des channels, des threads, des fichiers et des notifications. Un dashboard en plus ne ferait surtout que ramasser de la poussière d'onglet en plus.

Pour moi c'est ça le cœur : l'agent doit être disponible là où l'équipe travaille. S'il trouve quelque chose à partir d'un ticket, je veux la réponse de retour dans le même flux. L'analyse a sa place à côté de la question, dans le même thread.

OpenClaw supporte plus d'entrées que Slack. Il fonctionne aussi via, entre autres, Telegram, Microsoft Teams, Google Chat, WhatsApp, Discord et iMessage. Slack est mon entrée. L'idée plus large, ce sont des agents sur les canaux de communication existants, avec des tools et de la mémoire derrière.

L'installation était moins palpitante qu'espéré

L'installation était moins dramatique que ce que j'avais prévu. C'est agréable pour moi et mauvais pour le genre "build-log avec du feu".

Le plus gros du temps est parti dans la lecture. OpenClaw a beaucoup de documentation, et tu dois trouver quelle partie correspond à ta config. Slack, Gateway, agents, runtimes, channels, tools : ce sont des couches séparées qui forment au final un seul assistant ensemble.

Configurer Slack a demandé de l'attention aussi. Tu décides quels utilisateurs peuvent DM le bot, dans quels channels il peut parler et s'il réagit à chaque message dans les channels de groupe ou seulement sur un @mention. Ce ne sont pas des détails pour plus tard. Tu dois choisir ces règles à l'avance et les partager avec ton équipe, sinon personne ne comprend quand l'agent participe ou non.

Après environ deux heures, ça marchait. Je tapais dans Slack, le Pi attrapait le message, OpenClaw lançait un run, GPT-5.5 réfléchissait avec moi et la réponse revenait dans le même thread.

Beaucoup de plumbing pour un message texte. Sauf que ce message texte peut maintenant utiliser des tools.

Premier test : ce site

Le premier endroit où j'utilise ça, c'est djangodevreng.nl.

Le contenu doit venir de vrai travail : ce qu'on a construit, ce qui a cassé, quels choix sont restés, où un outil avait l'air bien jusqu'à ce qu'il commence à transpirer sous la charge. L'agent a le droit d'aider avec la forme et l'exécution.

Dès que cet input brut est là, il peut faire beaucoup. Structurer un dump. Faire un premier outline. Réécrire un draft dans mon ton. Enlever le langage marketing. Vérifier si un post sonne comme s'il était tombé d'un carrousel LinkedIn générique.

Le workflow pour ce site commence en général en bazar. Je balance dans Slack ce que je veux dire : quelques observations, une demi-idée, parfois juste du feedback sur un post existant. L'agent va ensuite chercher le bon repo, lit les fichiers pertinents et prend le guide d'écriture du workspace.

Ensuite je lui demande une modification concrète : "réécris l'intro", "enlève le langage marketing" ou "rends cette explication technique plus précise". Plus l'instruction est nette, plus le diff est utilisable. Il modifie le markdown sur une branche, lance les checks et pousse la modification vers une PR.

C'est là que ma partie recommence. Je lis le diff, je donne du feedback dans Slack et je le laisse traiter le tour suivant. Ce n'est que quand le post est juste que je merge moi-même. L'agent fait le travail préparatoire. Je reste responsable de ce qui passe en live.

Un agent qui publie sans que je regarde, ce n'est pas un workflow. C'est une machine à sous avec des droits de commit.

Pourquoi ça ressent différent du chat

Beaucoup d'outils AI donnent l'impression que tu dois amener ton travail vers une fenêtre de chat. Tu copies du contexte, tu colles des logs, tu expliques pour la troisième fois où se trouve le chemin du repo et tu espères que le modèle fasse comme s'il était là.

Cette config tourne plus près du contexte. L'agent peut commencer tout seul parce qu'il voit le workspace, connaît la branche, peut lire les règles du site et sait quels checks doivent être lancés.

Ça n'en fait pas encore un développeur autonome. Il pousse surtout le premier bout ennuyeux vers l'avant.

Pour moi c'est ça la couche agent intéressante : lire en amont, faire une première version, montrer où ça coince. Un collègue junior avec une patience infinie, sans agenda et parfois une confiance inquiétante dans ses propres phrases.

Je vais écrire un post séparé là-dessus, parce qu'OpenClaw mérite en fait plus d'explications que ce qui rentre dans ce build-log. Quels canaux il supporte. Quels tools tu lui accroches. Et surtout : pourquoi ça devient intéressant.

On glisse lentement de l'AI comme partenaire de sparring vers l'AI comme couche d'exécution. Ces dernières années on parlait surtout aux modèles : brainstormer, résumer, réécrire, réfléchir avec. Ça reste utile, mais la vraie différence est dans les agents qui peuvent exécuter du travail dans des systèmes existants.

Les agents ne reprennent pas le travail des gens un pour un. Ce n'est pas aussi simple, heureusement. Le glissement est dans les workflows : trouver des tickets, rassembler du contexte, préparer des drafts, proposer des modifications de code, lancer des checks, rendre compte. Du travail pour lequel tu demandes normalement quelqu'un parce que ça prend du temps, alors que ça demande peu de jugement humain profond.

Étape suivante : tickets et MCP

L'étape suivante, c'est MCP. Je veux accrocher des tools proprement à ce workflow, en commençant par Linear.

Le scénario est simple : un ticket arrive, l'agent lit le contexte pertinent du repo, cherche les fichiers probables, écrit une courte analyse et revient avec une proposition ou une liste de questions.

Le merge autonome, je le saute. D'abord je veux savoir où se trouve la limite entre une préparation utile et un zèle d'action dangereux.

Après ça viennent GitHub, le contexte du repo et peut-être une knowledge base locale. Certains contextes devraient simplement être disponibles, sans que je les recolle dans un prompt à chaque fois.

Workflow après workflow

Cette config Pi est petite. C'est exactement pour ça que je l'aime bien.

Assez petite pour la comprendre. Assez réelle pour en apprendre quelque chose. Assez bon marché pour la laisser allumée tout le temps. Assez locale pour rester proche de mon travail, sans faire comme si le modèle tournait lui-même en local.

Pour de l'AI en production chez des clients, c'est au mieux une couche dans l'architecture. Pour mon propre workflow ça marche déjà très bien : Slack comme entrée, OpenClaw comme Gateway, OpenAI comme model-provider, GitHub comme endroit où le travail se retrouve prêt.

Dans les temps qui viennent je vais bien bricoler avec ça. D'abord ce site. Ensuite les tickets. Ensuite les tools MCP. Ensuite probablement un truc dont je pense encore maintenant qu'il est trop spécifique pour être automatisé.

C'est ça la route intéressante : remplacer workflow après workflow par un agent qui fait le travail préparatoire, rassemble du contexte et prépare des propositions. Étape par étape je développe ma config OpenClaw. Juste comme un assistant pratique qui me retire un peu plus de travail des mains à chaque fois.

Et si ça déraille, il est assez proche pour tirer la prise.

Ce que la quantization s'est révélée être

2026-05-01T00:00:00.000Z

C'était le premier billet que j'ai mis en ligne sur ce site. Quand je l'ai écrit, je venais de faire tourner deux modèles sur la DGX Spark : Gemma-4-26B-A4B-it, un modèle MoE, et un modèle dense 31B. Les deux en local, les deux via vLLM.

À ce moment-là, la quantization restait surtout une question pour moi. Je connaissais le terme, je voyais à peu près de quoi il s'agissait, mais j'avais trop peu de mesures à moi pour en dire quoi que ce soit de solide.

Depuis, on a avancé de quelques rounds de benchmark. D'abord Gemma-4 sur la DGX Spark. Ensuite NVFP4 vs BF16 sur ce même modèle. Et après ça Nemotron-3 en BF16, FP8 et NVFP4. Ensemble, ils forment le guide faire tourner des LLMs sur la DGX Spark.

Du coup, ce billet a vraiment changé. Il parle moins de "c'est quoi la quantization ?" et plus de ce qui se passe quand la quantization cesse d'être un terme de model card pour devenir un choix d'architecture.

La première question, c'était juste : ça rentre ?

Avec les modèles hosted, tu commences souvent par la qualité. Lequel est le plus malin, lequel suit mieux les instructions, lequel écrit du meilleur code ?

En local, tu commences plus brutalement : ça rentre ?

Ça paraît presque trop simple, mais sur ta propre hardware, c'est le premier mur. Un nom de modèle et une model card, c'est de la paperasse ; les poids doivent vraiment tenir en memory. Après ça, tu veux encore de la place pour du contexte, traiter plusieurs requests en même temps, et idéalement voir quelque chose revenir en quelques secondes.

Sur la DGX Spark, tu le sens tout de suite. Tu regardes vLLM travailler : télécharger, charger, réserver la memory, monter en température. Ce n'est qu'après que commence la discussion sur le throughput, la latency et l'utilisabilité.

C'est un autre ressenti qu'un appel API vers Claude ou GPT-5.5. Là, l'infrastructure existe surtout comme une abstraction. Tu envoies du texte et tu récupères du texte. En local, tu vois l'arrière du décor. Parfois c'est sympa. Parfois ça prend surtout du temps.

C'est exactement là qu'intervient la quantization.

Mon premier tableau était trop étroit

Ma première définition de travail était assez propre : la quantization stocke les poids du modèle de façon plus compacte. FP16 ou BF16 prend plus de place que du 8-bit ou du 4-bit. Moins de bits, c'est moins de memory. Moins de memory, c'est un modèle qui rentre plus vite, se charge plus vite, ou laisse de la place pour plus de contexte et plus de requests.

C'est correct, mais c'est trop petit.

Après les benchmarks, je vois ça autrement. La question "est-ce que ce modèle rentre sur cette machine ?" n'est que le début. Vient ensuite la question de ce que tu peux faire avec cette machine une fois que le modèle rentre.

Faire tourner une request, c'est la démo. Faire tourner plusieurs requests, c'est le workflow.

C'est là que se situe la différence pour moi. Un modèle local qui répond proprement à un prompt, c'est sympa. Un modèle local qui encaisse plusieurs utilisateurs, agents ou tâches à la fois sans que la latency s'effondre, ça devient utile.

La quantization décide donc de combien de marge de manœuvre il te reste.

vLLM rend ça concret

J'utilise vLLM parce qu'une request à la fois, ce n'est pas la situation vers laquelle je vais. Lancer un chatbot local, c'est bien pour tester, mais dès que tu parles d'agents, tu obtiens un autre trafic.

Un agent va chercher du contexte, appelle des tools, découpe le travail, demande parfois des choses en parallèle et attend des résultats entre-temps. Pendant ce temps, tu veux qu'une deuxième request n'ait pas à attendre que la première soit complètement terminée.

C'est là que le serving devient important.

vLLM est la couche qui rend ça concret : batching, scheduling, utiliser la memory plus efficacement et gérer plusieurs concurrent requests. Ça rend aussi visible que faire tourner en local, c'est un système. Le modèle, la précision, la longueur de contexte, le nombre de requests simultanées et le scheduler tirent tous sur la même hardware.

Ça a été ma première vraie leçon. La quantization n'est pas un petit truc isolé tout en bas de la stack. Elle influence la façon dont toute la stack se comporte.

BF16 ressemblait d'abord au choix sûr

Tant que tu n'as pas mesuré, une précision plus haute paraît vite plus sûre. BF16 sonne sérieux. Plus de détail, moins de risque de qualité, moins de chances que le modèle se mette à se comporter bizarrement.

C'était aussi mon premier réflexe. Si la hardware encaisse, pourquoi descendre plus bas ?

Les mesures ont rendu ça moins évident. Sur la DGX Spark, BF16 s'est souvent révélé être le choix le moins pratique dans les runs plus tardifs. BF16 n'est pas "mauvais" ; c'est juste que la hardware et la workload pèsent plus lourd que le sentiment propre d'une précision plus haute.

Si une précision plus basse donne beaucoup plus de place pour la concurrency, le contexte ou le throughput, alors en pratique ça peut être mieux. Surtout pour des workloads où la vitesse et la simultanéité comptent plus que le dernier petit bout de qualité de modèle.

C'est le retournement que j'ai trouvé intéressant. La précision la plus haute paraît intuitivement le choix sérieux. Sur cette machine, c'était souvent surtout le plus cher.

NVFP4 a changé la Spark

Le plus grand basculement est venu avec NVFP4. Dans les billets de benchmark et l'arena, tu vois que NVFP4 double presque la DGX Spark pour beaucoup de workloads. Ce n'est plus une petite optimisation. Ça change ce que tu oses tenter sur la même machine.

Pour l'on-prem AI, c'est exactement le point. Tu achètes de la hardware pour un workflow, pas pour un joli prompt. Tu veux savoir combien de vrai travail tu peux caser sur cette boîte.

Si NVFP4 veut dire que tu peux faire tourner plus de requests à la fois, garder plus de marge et te cogner moins vite aux limites de mémoire, alors ce n'est pas un détail dans un tableau. Là, ton architecture change.

Tu peux répartir les tâches autrement. Tu peux garder plus de choses en local. Tu peux expérimenter plus vite avec des étapes d'agent qui sinon partiraient direct vers un modèle hosted.

C'est ce qui a rendu la quantization plus pratique pour moi que je ne le pensais au départ. Ça ne parlait plus d'un modèle plus petit, mais de rendre un autre workflow possible.

FP8 avait un autre genre d'avantage

FP8 ne se situait pas simplement "entre BF16 et NVFP4". Dans les runs Nemotron-3, c'est surtout la tail-latency qui devenait intéressante. Ça attire moins l'attention qu'un gros bond de throughput, mais à l'usage ça compte au moins autant.

Les moyennes ne mentent pas forcément, mais elles te rassurent aux mauvais moments. Un workflow semble lent à cause des quelques requests qui restent coincées.

C'est pour ça que la tail-latency est si pratique. Si un agent-workflow se compose de plusieurs étapes, les retards s'empilent. Une étape lente, c'est pénible. Trois étapes lentes à la suite, on dirait que le système réfléchit à ses choix de vie.

FP8 a l'air utile dans ce coin-là : moins extrême que NVFP4, mais intéressant quand la prévisibilité importe plus que faire tourner un maximum de choses à la fois.

C'est la nuance que je n'avais pas encore dans la première version. La précision n'est pas une échelle où plus bas est toujours plus rapide et moins bon. C'est un ensemble de choix avec des trade-offs différents.

La qualité reste la question ouverte

Les benchmarks répondent sur la memory, le throughput et la latency. Ils disent moins de choses sur le comportement.

Ça reste le côté difficile de la quantization. Tu ne vois pas toujours la perte de qualité proprement dans une seule metric. Parfois une réponse devient plus plate. Parfois le code se trompe un peu plus souvent. Parfois un agent choisit le mauvais tool. Parfois tu ne remarques rien, jusqu'à ce que ta tâche soit juste différente de ton set de test.

Pour des tâches simples, ça peut très bien aller. Pense à la classification, au routing, aux premiers résumés, aux embeddings ou à un passage léger sur des documents internes. Il n'y a pas toujours besoin du modèle le plus lourd là-dessus.

Pour la génération de code et les agent-workflows, c'est plus sensible. Les petites erreurs s'empilent. Un raisonnement moyen, c'est pénible. Un mauvais tool-call, c'est un autre genre de problème.

C'est pour ça que je ne veux pas benchmarker les modèles quantized seulement sur la vitesse. Je veux savoir où j'ose les déployer.

C'est une autre question. Et honnêtement, c'est la seule qui compte.

Le split devient plus clair

Mon attente reste que la meilleure setup on-prem devient un mix. "Tout en local" ça claque, mais c'est en général aussi inutilement strict.

Le split logique ressemble plutôt à ça :

embeddings en local
documents sensibles en local
routing et classification en local
étapes d'agent simples en local
raisonnement lourd vers Claude ou GPT-5.5 quand c'est nécessaire

La quantization décide de l'ampleur que peut prendre cette partie locale. Plus de tâches tournent en local de façon fiable et assez rapide, moins tu dois envoyer dehors.

C'est important pour le travail client. Pas parce que chaque token doit absolument rester entre quatre murs, mais parce que certaines données ont bien leur place là. Et parce que la latency, les coûts et le contrôle comptent tout simplement en production.

Une setup on-prem n'est pas une conviction. C'est une répartition du travail.

Ce que je mesurerais autrement maintenant

Dans la première version de ce billet, j'avais surtout une liste de questions. Combien de temps prend le téléchargement ? Combien de temps prend le chargement ? Combien de VRAM reste-t-il ? Combien de concurrent requests je peux envoyer avant que la latency devienne pénible ?

Ces questions restent utiles, mais c'est le début. Comment je mets exactement ces mesures en place sur la Spark, c'est dans la méthodologie de l'arena.

Maintenant, je mettrais trois choses côte à côte par précision :

comportement système : chargement, memory, throughput, latency et tail-latency
comportement du modèle : sortie en néerlandais, questions de code, contexte plus long, tool-use
adéquation au workflow : quelles tâches j'ose faire tourner en local avec ça

Cette dernière, on la rate vite si on regarde seulement des tableaux de benchmark. Un modèle peut techniquement tourner et rester malgré tout peu pratique. Ou justement scorer moins joliment, mais être exactement assez bon pour du routing ou du résumé.

Pour la production, ça fait la différence. Personne n'achète des "tokens par seconde" tout seuls. Tu achètes de la place dans un workflow.

Ce que je comprends maintenant

Ma définition de travail s'est déplacée.

La quantization rend un modèle plus petit, mais ce n'est que l'entrée. Elle change combien de travail tu sors de la même hardware, quelle latency tu acceptes et quelles tâches tu oses garder en local.

Sur la DGX Spark, la précision la plus haute semble rarement automatiquement le meilleur choix. NVFP4 rend la machine bien plus utilisable pour beaucoup de workloads. FP8 est intéressant quand la tail-latency commence à compter. BF16 reste utile comme point de référence, mais sur cette hardware il ressemble moins souvent au default pratique.

C'est exactement pour ça que je voulais faire ces mesures. Un classement universel aide peu ; de meilleurs choix d'architecture, oui.

La question n'est pas : quel niveau de quantization gagne ?

La question est : quelle tâche a le droit d'aller sur quelle précision, sur quelle machine, avec combien de risque ?

C'est là que l'on-prem AI commence à devenir intéressant pour moi : à la répartition du travail.