Les poids d'Inkling 2 Small sont disponibles : 394 Go, Apache 2.0 et une facture de la taille d'un nœud

Le premier commit de poids dans le dépôt Inkling 2 Small est horodaté du 12 novembre 2026 à 19 h 53 UTC — neuf heures avant la rédaction de ces lignes. Jusque-là, le modèle n’était qu’une grille tarifaire et un tableau de benchmarks : Thinking Machines Lab l’a lancé le 5 novembre avec des poids fermés, un endpoint Tinker et l’intention annoncée de publier les checkpoints sous Apache 2.0 « la semaine suivante ». Le modèle lui-même a donc huit jours. Ce qui est nouveau, c’est qu’on peut le télécharger, et le téléchargement n’est pas un petit fichier.

Deux dépôts sont publics. Le point de contrôle principal fait 393,5 Go répartis sur 36 fichiers, dont 24 fragments safetensors. La variante MXFP8 fait 622,8 Go. Les deux sont déclarés sous Apache 2.0 dans les métadonnées de la fiche de modèle. C’est tout ce que contient l’annonce à ce jour : la fiche de modèle, les dépôts et une mise à jour d’un paragraphe ajoutée à l’article de lancement. Tout ce qui suit est tiré de ces sources primaires, ainsi que des deux guides de déploiement publiés en même temps, et il faut être direct sur ce qui manque encore : les tests de sûreté externes, qui étaient la condition préalable annoncée à l’ouverture de ces poids, n’ont pas été publiés.

Qu’y a-t-il réellement dans le téléchargement ?

Commencez par la taille, car c’est la première chose qui détermine si ce modèle vous est réellement accessible. La configuration en précision mixte explique presque exactement ce chiffre, ce qui est bon signe : les valeurs publiées sont cohérentes entre elles plutôt que de la simple communication marketing.

• Répartition du checkpoint — experts NVFP4 dans les couches 0 à 39, experts MXFP8 dans les couches 40 à 47, selon le cookbook SGLang.

• Taille prévue — une moyenne de 5,33 bits par paramètre sur cette répartition 40/48 et 8/48 donne 396 Go pour 594 milliards de paramètres.

• Taille mesurée — 393,5 Go pour le dépôt principal, y compris le tokenizer et les fichiers de configuration.

• Dépôt MXFP8 — 622,8 Go, et l’index safetensors compte 612,4 milliards de paramètres stockés contre 383,1 milliards pour le dépôt principal, car le conditionnement des poids d’experts sur quatre bits réduit le nombre d’éléments comptés, et non le modèle.

L’architecture sous-jacente est un transformateur décodeur uniquement de 48 couches avec un bloc feed-forward à mélange d’experts clairsemé : 384 experts routés, 8 actifs par jeton, une largeur cachée de 4 608, 48 têtes d’attention sur 8 têtes clé-valeur de 128 dimensions chacune, et un vocabulaire de 201 024 jetons. L’attention est hybride plutôt qu’uniforme — 40 des 48 couches utilisent une fenêtre glissante de 1 024 jetons et seules 8 sont globales, ce qui constitue la source du budget de contexte long. La tour de vision est un transformateur séparé de 23 couches avec une largeur cachée de 1 024 et 16 têtes, lisant des patchs de 20×20 pixels avec une fusion 2×2, de sorte que chaque jeton d’image couvre une région de 40×40 pixels ; la fiche demande des images dont le côté mesure entre 40 et 4 096 pixels.

Il y a aussi une tête de prédiction multi-jetons ajoutée pour le décodage spéculatif — cinq couches, une taille de bloc de 8, un rang de Markov de 256, et des couches cibles à 5, 11, 17, 23, 29, 35, 41 et le bloc final. Ce sont précisément les huit couches d’attention globale, le détail qui montre que la tête de brouillon a été conçue autour de la pile hybride plutôt qu’ajoutée après coup. Thinking Machines appelle le décodeur résultant « DSpark ».

Un point de maintenance pour quiconque dont la revue juridique exige des documents : la licence est déclarée dans les métadonnées de la fiche du modèle comme Apache 2.0 et la fiche renvoie au résumé standard, mais il n’y a aucun fichier LICENSE, LICENSE.md, LICENSE.txt ou NOTICE dans l’arborescence du dépôt. Les quatre ne renvoient rien. La déclaration est réelle et sans ambiguïté ; l’artefact que la plupart des équipes juridiques s’attendent à trouver n’est pas là.

La liste du matériel, et les points sur lesquels le fournisseur et le guide de recettes ne sont pas d’accord

La fiche du modèle donne un plancher de VRAM. Les recettes de service donnent une topologie. Ce ne sont pas les mêmes chiffres, et l’écart entre les deux est l’élément le plus concret de cette page.

• NVFP4 principal — au moins 500 Go de VRAM agrégée ; les exemples pour cette carte sont 2× B300 ou 4× H200.

• Variante MXFP8 — au moins 800 Go ; exemples : 4× B300 ou 8× H200.

• SGLang, topologie par GPU — GB200, GB300 et B300 en TP 4 / EP 4 ; B200 en TP 4 / EP 4, avec TP 8 recommandé pour la réserve KV ; H200 avec NVFP4 en TP 8 / EP 8 ; MI350X et MI355X en TP 8 / EP 8 ; Vera Rubin en TP 4 / EP 4 ; TPU7x en 8 / 8 sur un hôte à quatre puces.

• MXFP8 sur B200 ou GB200 — TP 8 / EP 8, environ 151 Go de poids par GPU.

• La contrainte derrière tout cela — le parallélisme des experts doit être égal au parallélisme tensoriel, car les échelles d’activation des experts NVFP4 couvrent toute la largeur d’entrée de chaque expert et ne peuvent pas être découpées en parallélisme tensoriel.

Ainsi, l'exemple 4× H200 de la fiche respecte bien le plancher de 500 Go, mais ne correspond pas à une topologie que le cookbook valide ; le H200 y est répertorié en 8 voies. Les planchers de stockage et de mémoire vous indiquent si cela tient. Ils ne vous disent pas si cela tourne, et pour ce checkpoint, le second chiffre est le double du premier sur le matériel dont dispose la plupart des gens. Si vous dimensionnez votre infrastructure, fiez-vous à la recette, pas au plancher.

Le chemin AMD a deux jours et n’est pas fusionné.

Le radar qui a fait remonter cet article a repéré la pull request de prise en charge d’AMD plutôt que la publication des poids, et, pour être honnête, cette PR prise isolément relève du travail sur le moteur — le genre de chose qui ne fait pas l’actualité. Elle ne compte ici que parce qu’elle est arrivée la même semaine que les checkpoints, et parce qu’il s’agit du deuxième fournisseur de silicium à proposer une image de conteneur.

La pull request ajoute la prise en charge de gfx950 pour MI350X et MI355X, empilée sur le port de base d’Inkling 2 Small. Ce qu’elle change : les noyaux ROCm résident dans des modules *_hip.py distincts accessibles uniquement sous HIP, les chemins CUDA et NPU sont inchangés, le pool KV unifié et le préremplissage en graphe complet deviennent des valeurs par défaut au lancement, MegaMoE est refusé plutôt que tenté, et la quantification quick-reduce est ignorée sauf si un indicateur d’environnement l’autorise. gfx950 est requis, sauf si une seconde variable d’environnement le remplace — ce qui signifie que les cartes de classe MI300 sont refusées au lancement, et l’auteur de la PR indique que gfx942 « n’a pas été exécuté ».

Les mesures présentées dans la PR, qui sont propres à l’auteur et non révisées : 426 tests unitaires réussis sur un MI350X, 98,0 % sur GSM8K-200 en mode équilibré et 97,5 % avec DSpark pour une longueur d’acceptation de 4,04, et un temps par jeton de sortie, pour 2 048 en entrée et 512 en sortie, de 5,15 ms en mode équilibré contre 2,10 ms avec DSpark. Cela correspond à environ 194 et 476 jetons de sortie par seconde sur un seul flux sur huit accélérateurs. Avec AITer activé, les chiffres de précision passent à 97,5 % et 96,5 %.

L'état de la PR est « brouillon ». La CI n'a pas été exécutée dessus — le job de base est bloqué par une étiquette manquante et aucune exécution AMD n'est enregistrée pour le commit en cours de revue — et tous les propriétaires de code listés attendent toujours une revue. Considérez la prise en charge de MI350X comme quelque chose que vous pouvez compiler depuis les sources cette semaine, et non comme quelque chose que vous pouvez acheter.

Le servir implique une image de développement, pas une version publiée

Les deux principales stacks bénéficient d’une prise en charge dès le premier jour, et aucune ne l’a encore livrée. SGLang indique clairement que cette prise en charge n’est encore présente dans aucune version et renvoie aux builds dev-inkling-2-small, avec des images distinctes pour Hopper et Blackwell, Vera Rubin, MI35x et TPU7x. vLLM demande une version nightly ou plus récente, ou l’image vllm/vllm-openai:inkling-2-small. C’est normal pour un modèle de cette taille et aussi récent, mais cela change le sens de « pris en charge » : vous suivez une branche, et un rebase peut casser votre déploiement.

Les détails opérationnels qui vont réellement poser problème :

• Contexte — la recette TP 4 de vLLM est plafonnée à 262 144 tokens sur un seul plateau ; la fenêtre complète de 1 048 576 tokens nécessite TP 8 sur deux nœuds. En TP 4, une seule requête de 1 M de tokens nécessite 64,47 Gio de cache KV, soit plus que ce qu’il reste disponible sur un plateau.

• Décodage spéculatif — SGLang vérifie 8 jetons par étape avec la tête DSpark intégrée ; l’équivalent de vLLM définit 7 jetons spéculatifs avec une génération de propositions probabiliste. La recette avertit que le taux d’acceptation chute de 15 à 25 % à une température de 1,0 si vous générez les propositions de manière gloutonne.

• Analyseurs — le raisonnement utilise inkling, les appels d'outils utilisent inkling2, et SGLang sélectionne automatiquement les deux lorsque rien n'est défini. L'analyseur d'appels d'outils de vLLM est à activation facultative, et la recette indique que l'appel d'outils n'a pas été évalué de bout en bout, seulement testé unitairement.

• Désagrégation prefill/decode — validée uniquement en 1P1D sur un plateau GB300 à quatre GPU, NVFP4, sans MegaMoE, avec la fraction de mémoire statique forcée à 0,86 car la valeur automatique de 0,963 épuisait la mémoire. Le découpage ne convient pas au checkpoint MXFP8.

• Désagrégation de l’encodeur — pas encore dans les images, et le serveur de langage s’arrête si aucun encodeur sain n’est joignable.

• Marge mémoire — sur les modules B200 ou GB200 de 192 Go en TP 4, la capacité KV ne représente qu'environ un tiers de ce que fournit un châssis GB300, ce qui constitue la véritable limite de la concurrence en contexte long, plutôt que la taille de fenêtre imprimée sur la carte.

Il existe également un rapport communautaire sur la fiche du modèle elle-même, datant des premières heures suivant le téléversement, intitulé « Les cartes Hopper ne sont actuellement pas compatibles avec l’image vllm ». Aucune réponse d’un mainteneur n’est visible et je n’ai pas pu le reproduire, donc considérez-le comme un signalement plutôt qu’un constat, et vérifiez avant de valider un nœud Hopper. Du côté de SGLang, le H200 est bien listé en 8-way, donc la voie Hopper n’est pas fermée — elle n’est simplement pas celle que décrit la recette de vLLM.

Ce que coûte l’auto-hébergement, et pourquoi la réponse est rarement le prix

La raison de télécharger 394 Go tient au contrôle, non à l’économie unitaire, et le calcul le montre rapidement.

Sur Tinker, le modèle est proposé à 0,30 $ par million de tokens d'entrée, 0,03 $ par million de tokens d'entrée en cache et 1,00 $ par million de tokens de sortie, avec un contexte de 256K. Artificial Analysis mesure 84 tokens de sortie par seconde et 67,71 secondes jusqu'au premier token de réponse, à 1,18 $ par tâche d'index et 29,6 minutes par tâche, contre 154 M de tokens de sortie sur l'ensemble de la suite et une médiane des pairs de 89,8 M. Ce nombre de tokens est révélateur : il s'agit d'un modèle qui réfléchit longuement avant de répondre, et au tarif catalogue des tokens de sortie, un seul flux fonctionnant à plein régime pendant une heure produit environ 302 000 tokens, soit environ trente cents de sortie. Pour battre un nœud qui coûte un dollar de l'heure, il faut maintenir environ quatre flux occupés ; pour battre un nœud à vingt dollars de l'heure, il en faut soixante-six. Très peu de charges de travail d'évaluation, et encore moins de charges agentiques, soutiennent un tel niveau de concurrence face à un modèle dont le temps jusqu'au premier token est de 67 secondes.

Ce que vous obtenez en possédant les poids plutôt : la fenêtre complète de 1M selon vos propres conditions, plutôt qu’au palier de service 256K de Tinker ; aucune liste d’attente bêta avant la production ; le fine-tuning sur votre propre stack ; des données qui ne quittent jamais votre réseau ; et des balayages d’évaluation non facturés au token. Ce à quoi vous renoncez : une build de release fonctionnelle, la topologie à huit voies que vous devez acheter plutôt que louer, et une stack de serving que vous maintenez désormais.

Telle est la forme honnête de la décision, et c’est aussi là qu’une couche de routage trouve sa place sans qu’on lui demande de prétendre héberger ce qu’elle n’héberge pas. Inkling 2 Small ne figure pas au catalogue OrcaRouter — nous avons vérifié la liste des modèles en direct cette semaine et aucune entrée inkling ne figure parmi les 215 — le chemin API de ce modèle reste donc la plateforme Tinker de Thinking Machines elle-même et, selon la mise à jour de lancement, plusieurs fournisseurs d’inférence tiers. Ce que plus de 200 modèles derrière une seule clé vous apporte, c’est une solution de repli : vous pouvez mener l’expérience d’auto-hébergement sur un seul nœud et garder la production sur les modèles que nous routons, avec bascule automatique si l’expérience échoue, et sur les modèles que nous routons le prix catalogue du fournisseur est répercuté sans modification. Lorsqu’un deuxième et un troisième hébergeur reprennent ces checkpoints, la branche de bascule cesse d’être théorique — et l’enfermement propriétaire, qui constitue le principal argument en faveur du téléchargement de 394 Go au départ, s’affaiblit.

Où il se trouve maintenant qu’il est ouvert

Le score n’a pas changé lorsque les poids ont été publiés ; ce qui a changé, c’est qu’il appartient désormais à un classement dont il était auparavant exclu. Dans le classement des modèles à poids ouverts d’Artificial Analysis, Inkling 2 Small occupe la quatrième place sur 28 avec un Intelligence Index de 31, contre une médiane de 24 pour l’ensemble de comparaison.

• Kimi K3.1 Pro — 46.

• DeepSeek V4.1 Flash 1017 avec effort maximal — 33.

• GLM-5.3 en effort maximal — 32.

• Inkling 2 Small — 31.

• MiMo-V2.6-Pro et Ling 3.1 Flash 1019 — 30 pièces chacun.

• Mistral Large 4 avec un effort élevé — 26.

• Qwen3.8 27B en xhigh — 20.

La colonne intéressante de cette liste n’est pas le sommet. Tous les modèles au-dessus d’Inkling 2 Small proviennent d’un laboratoire chinois, et le meilleur modèle à poids ouverts d’un laboratoire non chinois était Mistral Large 4, à 26. L’ouverture de ces poids ramène cet écart précis de vingt points à quinze et déplace le sommet de la colonne non chinoise. Cela ne touche pas la frontière : le meilleur modèle ouvert a quinze points d’avance, et les modèles fermés se situent encore plus loin.

Le tableau d'évaluation du fournisseur est plus long et plus flatteur, et chacun de ses chiffres a été produit par Thinking Machines sur son propre banc d'essai en effort élevé — non reproduit, et donc un plafond plutôt qu'une attente. Les lignes qui comptent pour le travail agentique : SWE-bench Pro v2 Hard 86,3 %, DeepSWE v1.1 72,1 %, Vibe Code Bench v1.1 81,6 %, BrowseComp 90,2 % et DeepSearchQA 90,9 % tous deux avec compaction, MCP Atlas 85,4 % complet et 85,0 % public, HLE 44,1 % en texte seul, FrontierCode v2.0 25,4 %. La ligne qui va dans l'autre sens est Terminal Bench Science à 5,7 %, ce qui est faible en termes absolus et cohérent avec le profil de long horizon et de longue délibération plutôt qu'avec une revendication de capacité large. Le fournisseur affiche 30,6 pour l'Intelligence Index là où le tableau en direct montre 31 — une différence d'instantané, pas une contestation.

Qu’est-ce qui changerait cette évaluation ?

Trois choses, par ordre d'importance.

Le processus de sécurité censé conditionner cette publication n’a pas été publié. Le billet de Thinking Machines de juillet sur une voie sûre vers des poids ouverts décrit quatre organisations externes effectuant des tests avant déploiement sur l’Inkling de première génération, et le billet de lancement du 5 novembre liait cette publication à « des tests de sécurité externes et du red-teaming ». La mise à jour du 12 novembre annonçant les poids contient une phrase et un lien — vers le dépôt Hugging Face — et aucun résultat d’évaluation, aucun constat de red-team et aucune révision des conditions antérieures. Cela ne signifie pas que les tests n’ont pas eu lieu. Cela signifie qu’un lecteur ne peut pas le vérifier, et qu’une organisation dotée d’une politique d’achat exigeant les preuves ne les trouvera pas ici.

Un support de qualité production changerait qui peut l’adopter. Pour l’instant, le choix se limite à une branche de développement dans SGLang, à une version nightly de vLLM, ou à construire le chemin AMD depuis les sources à partir d’une ébauche non fusionnée. Dès que le support est intégré à une version taguée, le modèle devient une décision de déploiement plutôt qu’un projet d’ingénierie, et la topologie à huit voies cesse d’être un montage de recherche.

Une reproduction indépendante aux paramètres par défaut vous dirait ce que vaut 31 en pratique. Les lignes agentiques sont celles à surveiller — SWE-bench Pro à 86,3 et DeepSWE à 72,1 sont des affirmations solides pour un modèle doté de 17 B de paramètres actifs, et elles ont été obtenues à effort maximal. Les exécutions de tiers à l'effort par défaut donnent toujours des scores plus bas. La question est de savoir de combien, et personne en dehors de Thinking Machines n'y a encore répondu.

Jusqu’à ce qu’au moins l’un de ces éléments se concrétise, la description correcte d’Inkling 2 Small est d’une précision inhabituelle : un checkpoint Apache 2.0 que l’on peut télécharger dès aujourd’hui, qu’aucune pile de serving publiée ne prend en charge, dont les affirmations les plus fortes émanent du laboratoire qui l’a créé, et dont le verrou de licence s’est ouvert sans les documents qui étaient censés le précéder. C’est une véritable publication et un véritable écart, et c’est l’écart qu’il faut surveiller.