Cline multiplie la vitesse d'un modèle open source jusqu'à 11 840 tokens par seconde sur un seul GPU

Un départ déjà solide

Le 15 octobre, l'équipe de Cline a publié un rapport détaillant comment elle est parvenue à pousser un modèle de langage ouvert jusqu'à 11 840 tokens par seconde au total, sur une seule carte graphique. Il s'agit d'un modèle compact, conçu spécifiquement pour une exécution locale — il ne prétend pas être le plus intelligent, mais doit fonctionner rapidement et de manière stable sur plusieurs tâches à la fois : analyse de documents, programmation, calculs financiers. C'est précisément cette combinaison de vitesse et d'économie qui rend ce type de modèle intéressant — on peut l'affiner pour des besoins spécifiques d'une entreprise et le faire tourner sur son propre matériel, plutôt que de payer pour chaque appel à une API tierce.

Cette expérience a été rendue possible grâce à un partenariat avec NVIDIA — Cline a eu accès à un serveur puissant équipé d'un seul GPU doté de 252 Go de mémoire vidéo. L'objectif était simple : extraire le maximum de tokens par seconde de cette configuration sous une forte charge parallèle.

Un point de départ déjà performant

Dès le départ, avec la version du moteur vLLM 0.32.0rc1.dev190+g3f1bcfd82 et les réglages par défaut, le modèle affichait 6 058 tokens par seconde sur un test utilisant 512 tokens d'entrée et 512 tokens de sortie avec 256 flux de requêtes simultanés. Pour Cline, ce fut une surprise : la configuration de base du modèle s'est révélée déjà bien optimisée pour une charge élevée, et l'équipe a considéré ce chiffre comme un point de départ honorable plutôt qu'un échec à corriger héroïquement.

Cinq étapes qui ont presque doublé la vitesse

Les ingénieurs ont ensuite enchaîné une série d'expériences, en modifiant un paramètre à la fois :

• Prédiction multi-tokens (MTP3). Le modèle est livré avec une tête capable de prédire plusieurs tokens suivants à la fois. L'activation du mode MTP3 avec exécution mono-thread (OMP1) — afin d'éviter les coûts de coordination entre threads — a apporté le premier gain de vitesse.
• Ordonnanceur asynchrone. Avec un grand nombre de requêtes parallèles, le GPU est occupé par les calculs tandis que le CPU gère l'ordonnancement des tâches. Le passage de l'ordonnanceur en mode asynchrone a éliminé les temps morts du GPU en attente du CPU.
• Remplacement du bloc Mamba par FlashInfer. Le modèle utilise deux types de couches : des couches d'attention classiques avec cache KV, et des couches Mamba, qui stockent l'état différemment — via une mémoire récurrente et une convolution courte sur l'historique. Le basculement du moteur de calcul des couches Mamba vers FlashInfer a apporté, de manière inattendue, un gain de performance notable. L'équipe reconnaît honnêtement ne pas comprendre entièrement pourquoi cela a fonctionné — l'effet est peut-être lié à cette configuration GPU précise et pourrait ne pas se reproduire sur un autre matériel.
• Réduction de MTP de 3 à 1. On pourrait penser que plus le modèle prédit de tokens à l'avance, plus la génération devrait être rapide. En pratique, c'est l'inverse : chaque prédiction doit ensuite être vérifiée, et si la vérification échoue, le temps est perdu. Avec 256 flux parallèles, le GPU est déjà occupé par un travail utile, donc les paris supplémentaires sur des prédictions ne faisaient que nuire. La réduction de la profondeur de prédiction à MTP1 a encore augmenté la vitesse.
• État Mamba en FP16. La dernière étape a consisté à convertir l'état interne des couches Mamba d'une précision 32 bits vers 16 bits, avec un arrondi stochastique. Cela réduit la précision des calculs et peut légèrement dégrader la qualité des réponses du modèle, mais pour l'objectif de l'expérience — la vitesse maximale — ce compromis a été jugé justifié.

Au total, ces cinq ajustements ont fait passer la vitesse agrégée de 6 058 à 11 840 tokens par seconde — presque un doublement, sans changer de matériel.

Ce que cela signifie pour les ingénieurs

La conclusion principale de l'équipe Cline ne ressemble pas à une recette, mais à un avertissement : l'ingénierie d'inférence dépend énormément du contexte. Les astuces qui ont fonctionné ici — MTP1 au lieu de MTP3, FlashInfer au lieu du noyau Mamba standard — pourraient, sur un trafic de forme différente (un autre ratio tokens d'entrée/sortie, un autre nombre de requêtes parallèles), au contraire réduire la vitesse. C'est pourquoi Cline conseille de ne pas copier aveuglément la configuration d'autrui, mais de d'abord comprendre la forme de son propre trafic avant de régler l'inférence en conséquence.

L'équipe a également partagé trois prévisions pour l'avenir. Premièrement, l'exécution locale de dizaines de flux d'agents en parallèle deviendra chose courante — en exemple, une démonstration de 32 sessions Cline simultanées sur le modèle Nemotron 3.5 Super VL, exécutée sur une seule station NVIDIA DGX, enregistrée sans accélération vidéo.

Deuxièmement, lorsque le GPU est pleinement sollicité, l'hébergement autonome des modèles peut s'avérer plus rentable que le paiement d'une API — selon les calculs de Cline, dans leur cas, l'économie s'est élevée à environ 66 %. Troisièmement, les auteurs estiment que la recherche de la configuration d'inférence optimale deviendra elle-même, à terme, une tâche confiée à des agents IA : un agent ayant accès aux métriques Grafana pourrait exécuter des tests de charge sur un GPU de réserve, trouver la meilleure configuration pour un trafic donné, et basculer la production vers celle-ci en toute sécurité — faisant ainsi de l'autoscaling de l'inférence une tâche agentique.