Pourquoi ce blog et cette arena existent

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.