Kimi K3.1 Pro fonctionne immédiatement dans vLLM : 1 million de tokens et 65,7 % sur Terminal-Bench 4.0

Un nouveau modèle ouvert suit généralement toujours le même parcours. Une version est d’abord publiée, puis il faut attendre plusieurs semaines que la communauté finalise l’inférence, tout en passant entre-temps par l’API d’un tiers. Avec Kimi K3.1 Pro de Moonshot AI, cette étape a été supprimée : le projet vLLM a annoncé la prise en charge du modèle le jour même de sa sortie.

Ce que l’on sait

Trois faits ressortent de l’annonce. Premièrement, Kimi K3.1 Pro dispose d’une fenêtre de contexte de 1 million de tokens. Moonshot positionne le modèle pour les longues sessions de programmation, la création de contenu 3D et les travaux de recherche. Deuxièmement, le modèle obtient 65,7 % sur Terminal-Bench 4.0. Dans ce benchmark, un agent accomplit des tâches directement dans le terminal : il installe des dépendances, répare une compilation et modifie des configurations. La mesure a été réalisée avec le harnais Claude Code. Troisièmement, vLLM promet un service GPU dès le jour zéro, ce qui signifie que le modèle peut être lancé immédiatement, sans attendre des forks ni des correctifs.

La publication ne fournit pas davantage de détails. La taille du modèle, son architecture, sa licence et ses besoins en mémoire n’y sont pas précisés : il faudra donc consulter la documentation de Moonshot et les notes de version de vLLM.

Pourquoi la prise en charge dans vLLM est particulièrement importante

vLLM est depuis longtemps l’un des principaux moteurs d’inférence auto-hébergée. Lorsqu’un modèle y fonctionne dès le premier jour, l’équipe dispose d’un parcours clair : utiliser une image prête à l’emploi, lancer un endpoint compatible avec OpenAI et le connecter aux outils existants. Il n’est pas nécessaire d’écrire son propre serveur ni de gérer des noyaux non standard.

C’est essentiel pour les entreprises soumises à de strictes exigences concernant les données. Le code des clients, les dépôts internes et les journaux d’incidents ne peuvent souvent pas être envoyés vers une API externe. Jusqu’ici, il fallait choisir entre un modèle fermé accessible par API et un modèle ouvert moins performant. Si les résultats annoncés se confirment, une troisième option apparaît : un puissant modèle agentique exécuté sur sa propre infrastructure.

Ce que signifient 1 million de tokens et 65,7 %

Un million de tokens ne signifie pas seulement que « toute la base de code tient dans le contexte ». Une longue session d’agent accumule un historique : sorties de commandes, diffs, journaux de tests et tentatives précédentes. Plus la fenêtre est grande, moins il est nécessaire de compresser le contexte et de perdre des détails. Mais un contexte long a un coût. Le cache KV augmente avec la longueur et, sous une charge réelle, il consomme rapidement la mémoire GPU. « Prend en charge 1 million de tokens » et « gère confortablement 1 million de tokens avec des dizaines de sessions simultanées » sont donc deux réalités différentes, et seuls vos propres tests permettront d’en mesurer l’écart.

Le score de 65,7 % sur Terminal-Bench 4.0 mérite lui aussi d’être nuancé. Le résultat dépend du harnais, et le test utilise ici Claude Code. Avec un autre framework agentique, d’autres prompts et d’autres outils, le chiffre pourrait changer. En outre, ce résultat a été publié par l’équipe qui développe le modèle. La publication ne mentionne aucune reproduction indépendante.

Que faire en pratique

Si vous développez des agents de programmation ou des outils internes destinés aux développeurs, voici une démarche raisonnable :

1. Lisez les notes de version de vLLM et vérifiez le matériel ainsi que les paramètres nécessaires pour les contextes longs.
2. Sélectionnez 20 à 30 tâches réelles dans votre backlog : réparation de la CI, migrations et analyse de tests défaillants. Exécutez-les avec Kimi K3.1 Pro et avec votre modèle actuel.
3. Mesurez non seulement le taux de tâches résolues, mais aussi le coût d’une heure de GPU, la latence pendant les longues sessions et le nombre d’étapes nécessaires pour parvenir au résultat.
4. Effectuez les tests avec votre propre harnais agentique, et pas uniquement avec celui qui a servi à établir le benchmark.

Les équipes produit devraient aussi retenir un autre point : les modèles ouverts arrivent de plus en plus vite sur des infrastructures de production. Le délai entre la publication des poids et la possibilité de les utiliser est désormais nul. Cela réduit le risque de dépendance envers un fournisseur unique et renforce la position des entreprises lors des négociations tarifaires.

En définitive, cette annonce relève davantage de l’infrastructure que d’une révolution. Mais si les chiffres se confirment, les équipes disposant de leurs propres GPU auront accès à une véritable alternative aux modèles agentiques fermés, sans plusieurs semaines de préparation.