Cline atteint 11 840 tokens/s sur une seule station NVIDIA DGX Station

L'équipe de Cline a porté le débit total de génération d'un modèle ouvert sur un seul GPU à 11 840 tokens de sortie par seconde. Ce record a été enregistré le 15 octobre sur une station NVIDIA, à laquelle les ingénieurs avaient accès grâce à leur partenariat avec NVIDIA. Le point de départ était déjà élevé : vLLM 0.32.0rc1 sans modification délivrait 6 058 tokens/s sur un test avec 512 tokens en entrée et 512 en sortie, à 256 flux simultanés. Le résultat final est environ 1,95 fois supérieur.

Le modèle a été conçu comme une bête de somme locale et rapide pour des tâches variées : analyse de documents, codage, comptabilité financière. Sur une seule machine, il dispose d'un budget de mémoire GPU de 252 Go. Dans la démonstration de Cline, 32 instances de Cline tournent en parallèle sur une telle station, sans accélération vidéo, au-dessus de Nemotron 3.5 Super VL.

Cinq étapes pour passer de 6 058 à 11 840

Cline ne décrit pas une trouvaille unique, mais une série d'expériences, dont cinq ont fonctionné :

• Tête MTP intégrée. Le multi-token prediction était fourni avec le modèle. Les ingénieurs sont partis de MTP3, soit trois tokens de brouillon par pas, et ont fixé OMP1 : un seul thread CPU est préférable, car plusieurs threads ajoutent un surcoût de coordination.
• Planification asynchrone. Sous forte concurrence, le GPU est occupé par les noyaux de calcul, tandis que le CPU est occupé par la planification. Le mode asynchrone évite au planificateur d'attendre que le GPU ait terminé son travail.
• Noyau Mamba sur FlashInfer. Le modèle est hybride : les couches d'attention utilisent un cache KV, tandis que les couches Mamba stockent un état récurrent et un court historique de convolution. Le retour au noyau FlashInfer a produit un bond notable. Les auteurs n'ont pas totalement compris pourquoi, et l'effet pourrait ne pas se reproduire sur un autre matériel.
• MTP1 au lieu de MTP3. Une étape contre-intuitive, qui a de nouveau fait grimper le débit.
• État Mamba en FP16 au lieu de FP32, avec arrondi stochastique. Cela réduit la précision et, potentiellement, les métriques sur les benchmarks, mais pour l'objectif « un maximum de tokens par seconde », le prix s'est révélé acceptable.

Pourquoi moins de tokens de brouillon va plus vite

Le décodage spéculatif ressemble à un bonus gratuit : plus on prédit de tokens de brouillon, plus on a de chances d'en accepter plusieurs d'un coup. Mais chaque brouillon doit être vérifié. Si la vérification échoue, le temps de calcul du modèle est gaspillé. À 256 flux parallèles, le GPU est déjà plein de travail utile, et la vérification supplémentaire ne se rentabilise pas. C'est pourquoi MTP1 a devancé MTP3.

Le gain apporté par MTP peut sembler inverse à faible charge et à forte concurrence. La même recette pourrait donc nuire sur un autre profil de trafic. Cline le dit sans détour : l'ingénierie d'inférence est extrêmement contextuelle, et le passage à l'échelle dépend de la forme du trafic.

Économie : 66% de moins que le prix de l'API

La principale conclusion pratique, Cline la calcule sur un coin de nappe. En comparant le paiement à l'API avec un GPU pleinement chargé, on obtient une remise de 66% sur l'inférence. La condition est stricte : le GPU doit être occupé presque tout le temps. Dans ce cas, il revient moins cher d'appliquer la recette de Cline et de payer le matériel que de passer par un routeur de modèles et de payer chaque appel.

L'équipe en tire deux prévisions. La première : l'auto-hébergement de dizaines d'agents locaux en parallèle deviendra une pratique courante, et les 32 instances de Cline sur une seule station en donnent déjà un aperçu. La seconde : l'autoscaling de l'inférence deviendra agentique. Un agent ayant accès aux métriques Grafana pourra lancer des tests de charge sur un GPU dédié, sans toucher au trafic de production. Il cherchera la meilleure configuration pour la forme réelle des requêtes, puis y basculera le trafic avec précaution. Un tel système « auto-réparateur » ajustera la consommation de GPU en fonction de l'heure de la journée et de la charge.

Ce qu'il faut vérifier avant de reproduire la recette

La recette ne se copie pas à l'aveugle. Il faut d'abord établir son propre profil : longueurs des prompts et des réponses, nombre de flux simultanés, latence admissible. Ensuite, il est utile de tester les cinq réglages un par un. Pour une forte concurrence, il vaut la peine de comparer MTP1 et MTP3, alors qu'avec un faible nombre de flux, l'effet peut s'inverser. Le passage de FP32 à FP16 pour l'état Mamba exige impérativement de relancer les jeux d'évaluation, car la vitesse est ici achetée au prix de la précision. Enfin, le calcul d'une économie de 66% n'est valable qu'avec une forte utilisation du GPU : si la station reste inactive, l'API redevient plus avantageuse.