Magazine LLM Opensource · 7 November 2026

Inkling de Thinking Machines : anatomie du nouveau prétendant occidental aux open weights

Un modèle open weight signé d’un laboratoire de moins de deux ans, présenté par la presse comme le « nouveau géant occidental » de l’IA ouverte. Derrière le titre d’agence, que reste-t-il de vérifiable ? Et surtout : un praticien a-t-il intérêt à migrer dès maintenant ?

Il y a des semaines où l’écosystème open weight ressemble à un champ de bataille, et d’autres où il ressemble à une salle de rédaction. La sortie d’Inkling, le modèle à poids ouverts attribué à Thinking Machines Lab, appartient clairement à la seconde catégorie. En quelques heures, la formule « nouveau leader des open weights occidentaux » a circulé dans les fils d’actualité, reprise d’agence en reprise d’agence, sans qu’un seul chiffre ne l’accompagne dans les extraits que nous avons pu consulter. C’est un phénomène connu : un nom de lab qui claque, un fondateur médiatique, un mot-valise séduisant (« Inkling », l’intuition, le pressentiment), et voilà un titre qui s’écrit tout seul.

Le problème, c’est que ce titre ne dit rien à un praticien. Un praticien, lui, veut savoir combien de paramètres, quelle licence, quel support dans vLLM, combien de VRAM en FP8, et si le fine-tuning LoRA tient sur une seule machine. Et sur ce terrain-là, notre matière documentaire est cruellement mince : un titre MSN, aucune model card accessible, aucun blog officiel, aucun benchmark primaire. Nous allons donc devoir faire un travail d’archéologie — distinguer ce qui est affirmé, ce qui est plausible, ce qui est vérifiable, et ce qui relève du pur bruit de recherche (les extraits collectés comprennent, ironie de l’automatisation, des définitions du mot anglais thinking et le site d’une marque de vêtements barcelonaise).

C’est précisément cet exercice qui a de la valeur. Parce que la question n’est pas « Inkling est-il le meilleur modèle du monde ? » — question à laquelle personne ne peut répondre sérieusement sur la base d’un titre d’agence — mais « que peut-on raisonnablement conclure, et à quelles conditions un praticien devrait-il bouger ? »

De Mira Murati à Inkling : la trajectoire d’un lab qui n’a pas deux ans

Ce que l’on peut établir sur Thinking Machines Lab tient, dans notre corpus, à un fil ténu : le nom du lab, le nom du modèle, et l’existence d’une couverture presse. Le reste — capital levé, tours de financement, partenaires, premières publications — n’est pas documenté dans les sources fournies. Il faut le dire net : nous n’avons pas de source primaire.

Cela dit, l’absence de documentation n’est pas neutre, elle est en soi une information. Un laboratoire qui sortait, selon la rumeur, un modèle destiné à « prendre la tête des modèles occidentaux » aurait publié, en temps normal, une model card détaillée, un rapport technique, un billet de blog positionnant le modèle face aux concurrents, et un dépôt Hugging Face avec les poids. Rien de tout cela n’apparaît dans notre matière. Deux hypothèses, également inconfortables :

1. La communication a été délibérément minimale — poids sur Hugging Face, licence en fichier texte, pas de rapport technique. C’est une pratique qui existe (certains labs chinois l’ont fait), mais elle est rare pour un lab occidental qui cherche à s’imposer comme référence.
2. La couverture presse a précédé la documentation, ou l’a largement dépassée. Le titre MSN repris dans notre corpus ressemble à une reprise d’agence, pas à une analyse.

Dans les deux cas, le mode de communication du lab en dit long : Thinking Machines semble jouer la carte de la rareté narrative plutôt que celle de la transparence technique. C’est un choix stratégique défendable — il crée de l’attention — mais c’est un mauvais signal pour un praticien qui doit décider, en entreprise, s’il engage une équipe sur six mois de migration.

Rappelons le contexte concurrentiel immédiat, qui rend cette sortie intéressante malgré tout. Le 15 octobre 2026, Meta a publié Muse Spark Open : un MoE de 816 milliards de paramètres totaux, 42 milliards actifs, avec une fenêtre de contexte d’un million de tokens, positionné explicitement par Meta comme « le modèle open weight américain le plus capable à ce jour » et optimisé pour le coding et le travail agentique, jusqu’à tourner sur des Mac Studio Apple M5 Ultra. Le 16 octobre, le magazine notait déjà que « 816B, 560B, 120B en un jour : la vague open-weight se heurte désormais à un mur de mémoire ». Autrement dit : le terrain sur lequel Inkling prétend « passer devant » est déjà occupé, et par un acteur qui, lui, a publié ses spécifications.

Sous le capot : ce qu’Inkling dit de son architecture (et ce qu’il cache)

C’est ici que la matière nous manque le plus. Aucune source primaire ne documente, pour Inkling : le choix dense vs MoE, le nombre de paramètres totaux et actifs, la fenêtre de contexte, le tokenizer, le volume de tokens d’entraînement, les phases SFT/RLHF, ni une éventuelle distillation. Nous ne pouvons donc pas, en toute rigueur, dresser un tableau comparatif chiffré avec Llama, DeepSeek, Qwen ou Mistral. Nous ne le ferons pas, et nous invitons le lecteur à se méfier de tout article qui le ferait sans citer de source.

Ce que l’on peut faire, en revanche, c’est rappeler à quoi ressemble l’état de l’art sur ce terrain, pour que chacun puisse situer Inkling quand les chiffres seront publiés. Trois familles d’architectures coexistent aujourd’hui dans l’open weight :

• Les MoE à très forte proportion de paramètres actifs : c’est la voie choisie par Meta avec Muse Spark Open (816B/42B, ratio d’activation d’environ 5 %), et par la plupart des labs chinois. L’idée : garder une capacité de raisonnement élevée tout en réduisant le coût de calcul par token.
• Les MoE à faible activation : c’est le choix d’Aleph Alpha avec Kolibri-1, publié le 3 octobre 2026 sous Apache 2.0 — 78,1 milliards de paramètres totaux, 3,46 milliards actifs par token (ratio d’activation d’environ 4,4 %), contexte maximal de 1 048 576 tokens (avec une fenêtre recommandée en production d’environ 262 144 tokens), poids en BF16 et FP8, langues principales allemand et anglais. Un modèle explicitement pensé pour le déploiement souverain européen.
• Les denses classiques, plus simples à servir, plus prévisibles en latence, mais plus chers au token.

Si Inkling appartient à la première catégorie, il faudra surveiller le ratio d’activation : c’est lui qui détermine le coût réel d’inférence, bien plus que le nombre total de paramètres. Un 800B/40B ne coûte pas plus cher à servir qu’un 80B dense, à contexte égal. Si Inkling est dense et gros, la facture sera tout autre. Sans cette donnée, impossible de trancher.

Un point de méthode, enfin, sur les données d’entraînement. La matière ne dit rien de la composition du corpus, ni du volume de tokens. C’est un angle mort classique, mais qui prend une importance particulière ici : sans documentation, impossible d’évaluer le risque de contamination des benchmarks, impossible de savoir si le français est bien couvert, impossible de savoir si le modèle a été distillé d’un modèle fermé — pratique courante, mais dont les conditions d’usage (chez OpenAI, Anthropic, Google) interdisent souvent la redistribution des poids. C’est un risque juridique majeur pour quiconque voudrait redistribuer Inkling en production.

Benchmarks : les chiffres qui circulent, les réserves qui manquent

Soyons clairs : dans la matière collectée, aucun score n’est documenté pour Inkling. Pas de MMLU-Pro, pas de GPQA, pas de HumanEval, pas de SWE-bench, pas de MATH, pas d’Arena Elo, pas de LiveBench. Les seules mentions de benchmarks dans notre corpus concernent d’autres modèles — par exemple les scores d’Aleph Alpha Kolibri-1 (BFCL v4 à 61,4 %, Tau2-Bench Airline à 76,7 %, Retail à 69,9 %, Telecom à 94,7 %, Tau3-Bench Banking à 38,1 %) — et ils ne nous aident pas à situer Inkling.

Face à ce vide, deux attitudes sont possibles. La première consiste à relayer les scores « qui circulent » sur les réseaux. C’est ce que font beaucoup de comptes, et c’est précisément ce qui rend le débat inutilisable. La seconde consiste à rappeler pourquoi les scores auto-déclarés d’un modèle open weight doivent être pris avec des pincettes, et à quoi ressemble une évaluation honnête.

Quatre réserves, en particulier, méritent d’être systématiquement posées :

1. La contamination. Un modèle entraîné sur des données web a très probablement vu passer les questions de MMLU ou de HumanEval. Sans documentation du corpus ni procédure de décontamination, un score élevé peut refléter de la mémorisation, pas de la compétence. C’est un problème connu depuis des années, et qui n’a pas disparu.
2. L’auto-évaluation. Quand le lab qui entraîne le modèle est aussi celui qui publie les scores, il choisit les prompts, les configurations d’inférence (température, top-p, nombre d’échantillons, vote majoritaire), et les versions des benchmarks. Un score de 78 % sur GPQA avec 32 échantillons et vote majoritaire n’est pas comparable à un score de 72 % en zero-shot greedy.
3. La comparaison biaisée. Comparer un modèle à DeepSeek-V3/R1, Qwen2.5/3, Llama 3.3/4 ou Mistral Large n’a de sens que si les versions exactes, les configs et les prompts sont documentés. Or, dans la pratique, les tableaux de communication comparent souvent le nouveau venu à des versions antérieures des concurrents.
4. Le décalage entre benchmark et usage. Un score élevé sur SWE-bench ne garantit pas qu’un agent de coding fonctionne en production sur un dépôt réel de 200 000 lignes. Un score élevé sur MMLU-Pro ne garantit pas un bon RAG en français.

Tant qu’aucune de ces quatre réserves ne peut être levée pour Inkling, la seule lecture défendable est : « on ne sait pas ». Ce n’est pas une position confortable pour un magazine, mais c’est la seule honnête.

Licence : open weights n’est pas open source, et le diable est dans les clauses

C’est peut-être le point le plus critique pour un praticien, et c’est aussi celui sur lequel la matière est la plus silencieuse. La licence d’Inkling n’est pas documentée dans nos sources. Nous ne savons donc pas :

• s’il s’agit d’une licence OSI-approved (Apache 2.0, MIT) ou d’une licence custom de type « open weights mais restrictions d’usage » ;
• s’il existe des seuils d’utilisateurs (comme la clause des 700 millions d’utilisateurs mensuels de la licence Llama) ou des seuils de revenu ;
• si l’attribution est obligatoire ;
• si l’usage militaire est interdit ;
• si la distillation vers un autre modèle est autorisée ;
• quelle est la politique de mise à jour (les poids peuvent-ils être retirés ? la licence peut-elle être révisée rétroactivement ?).

Ce sont des questions qui ont des conséquences juridiques concrètes. Une entreprise qui déploie Inkling en production sans avoir lu la licence prend un risque : si la licence interdit l’usage commercial au-delà d’un seuil, la facture peut être rétroactive. Si elle interdit la redistribution des poids fine-tunés, l’entreprise ne peut pas partager son modèle affiné avec ses filiales. Si elle est révocable, la pérennité du déploiement est en question.

À titre de comparaison, les régimes connus dans l’écosystème sont très hétérogènes. Aleph Alpha Kolibri-1 est publié sous Apache 2.0 — le régime le plus permissif, qui autorise usage commercial, modification et redistribution sans condition de seuil. Meta Muse Spark Open est publié sous une licence propre à Meta, dont les clauses exactes ne sont pas détaillées dans notre corpus mais qui, historiquement, imposent des conditions d’attribution et des seuils. Les modèles Qwen d’Alibaba sont généralement publiés sous Apache 2.0 pour les tailles petites et moyennes, sous licence custom pour les très gros modèles. Mistral alterne entre Apache 2.0 (petits modèles) et licences de recherche non commerciales (gros modèles). DeepSeek utilise une licence custom avec des restrictions.

Autrement dit : le mot « open weight » ne dit rien sur ce que l’on peut faire du modèle. C’est une étiquette technique (les poids sont téléchargeables), pas une étiquette juridique. Un modèle open weight sous licence restrictive est, pour une entreprise, à peu près aussi utilisable qu’un modèle fermé — à la différence près qu’on peut l’héberger soi-même.

Recommandation pratique : tant que la licence d’Inkling n’est pas publiée et lue par un juriste, aucun déploiement en production ne devrait être engagé. Un POC en interne, oui. Une migration de stack, non.

Combien ça coûte vraiment : VRAM, débit et prix au million de tokens

Même constat : aucun chiffre de déploiement n’est documenté pour Inkling dans notre matière. Ni VRAM en FP8, ni VRAM en INT4, ni VRAM en GGUF, ni débit, ni latence, ni tarif chez Together, Fireworks, Groq ou Bedrock. Nous ne pouvons donc pas répondre à la question « à partir de quel volume Inkling devient-il économiquement rationnel ? » avec des chiffres.

Ce que l’on peut faire, c’est poser la méthode de calcul, pour que chacun puisse l’appliquer dès que les specs seront publiées. Trois régimes de coût coexistent :

• API hébergée : le coût est linéaire, exprimé en dollars par million de tokens (entrée et sortie). Il dépend du prix fixé par l’hébergeur, qui dépend lui-même du coût de calcul du modèle. Un MoE à 42B actifs coûte, à contexte égal, bien moins cher à servir qu’un dense de 400B.
• Auto-hébergement sur GPU : le coût est dominé par l’amortissement du matériel et l’électricité. Il faut compter, pour un modèle de taille moyenne, plusieurs GPU H100/H200 ou MI300, et un débit qui dépend fortement du batch et de la longueur de contexte. Un modèle à contexte long (1M tokens) peut saturer la mémoire KV cache bien avant de saturer la mémoire des poids.
• Inférence locale (GGUF, llama.cpp, Ollama) : le coût marginal est nul, mais le débit et la qualité (quantification) sont dégradés. C’est le régime des POC et des usages personnels, pas de la production.

Pour situer, le marché a récemment donné un point de repère : Inception Mercury 3, modèle à diffusion sorti le 19 octobre 2026, est annoncé à 0,10 dollar par million de tokens en entrée — un tarif agressif qui montre à quel point la pression sur les prix est forte. Un modèle open weight qui ne tiendrait pas ce niveau de coût aurait intérêt à offrir une qualité nettement supérieure pour justifier l’écart.

Règle empirique : un modèle open weight devient économiquement rationnel en auto-hébergement à partir du moment où le coût d’API équivalent dépasse, sur 12 à 18 mois, le coût d’amortissement du matériel. En dessous, l’API reste plus intéressante. Au-dessus, l’auto-hébergement se justifie — à condition d’avoir les compétences internes pour l’exploiter, ce qui est loin d’être trivial (vLLM, monitoring, gestion des versions, sécurité).

L’outillage suit-il ? vLLM, SGLang, llama.cpp et la réalité des premiers jours

Là encore, aucune source ne documente le support d’Inkling dans vLLM, SGLang, TensorRT-LLM, llama.cpp, Ollama ou LM Studio, ni la disponibilité des poids sur Hugging Face, ni les recettes de fine-tuning LoRA/QLoRA avec Unsloth ou Axolotl, ni les retours de praticiens sur GitHub ou r/LocalLLaMA. Nous ne pouvons donc pas distinguer ce qui marche déjà de ce qui relève de la promesse.

Ce que l’on peut dire, en revanche, c’est que l’écosystème d’outillage a beaucoup bougé ces dernières semaines, et que cela change la donne pour tout nouveau modèle :

• vLLM et SGLang ont été portés sur TPU par Google, annoncé le 20 octobre 2026 sur le Google Developers Blog. Cela élargit les options d’infrastructure au-delà de NVIDIA et AMD.
• llm-d 1.0 a été présenté le 20 octobre 2026 à la PyTorch Conference North America : une pile d’inférence distribuée Kubernetes-native, pensée pour la production. C’est le genre de brique qui manquait pour industrialiser le déploiement de modèles open weight à grande échelle.
• Le débat sur le routing des MoE s’est intensifié : un article du 28 octobre 2026 détaille comment la sélection sparse des paramètres actifs, le top-k gating et l’équilibrage de charge entre experts réduisent la charge GPU en entreprise sans sacrifier la profondeur de raisonnement. C’est exactement le type de connaissance nécessaire pour optimiser le déploiement d’un MoE comme Inkling — si Inkling est un MoE.

La leçon est simple : un modèle open weight sans support dans vLLM/SGLang au jour J est un modèle qui ne se déploie pas en production au jour J. Les premiers jours sont toujours chaotiques : les poids arrivent, les tokenizers divergent, les kernels spécialisés manquent, les issues GitHub s’accumulent. Un lab sérieux publie, en même temps que les poids, les recettes de serving et les configs de référence. Sans cela, la communauté fait le travail à sa place, en quelques jours ou semaines — mais avec des résultats inégaux.

Là où Inkling gagne, là où il déçoit : coding, RAG français, contexte long, on-premise

Sans données, impossible de trancher cas par cas. Mais on peut poser les critères de décision et les alternatives crédibles, cas par cas.

Coding agentique. C’est le terrain de jeu déclaré de Meta Muse Spark Open (816B/42B, contexte 1M, optimisé pour le travail agentique). Si Inkling veut s’y imposer, il devra démontrer des performances sur SWE-bench et, surtout, sur des tâches agentiques réelles (édition de dépôts, exécution de tests, itérations). Un score élevé sur HumanEval ne suffit pas. À vérifier avant migration.

RAG multilingue, dont le français. Aucune donnée. Le français est explicitement couvert par Nemotron 3.5 Transcribe de NVIDIA (40 langues, publié le 28 octobre 2026) côté speech, mais rien ne dit ce qu’il en est d’Inkling côté texte. Un modèle entraîné majoritairement sur de l’anglais aura des performances dégradées en français, surtout sur les tâches de raisonnement. À tester sur un corpus français réel avant tout engagement.

Raisonnement long et contexte long. Le standard s’est déplacé : Meta Muse Spark Open annonce 1M de tokens, Aleph Alpha Kolibri-1 1 048 576 tokens (avec une fenêtre recommandée en production d’environ 262 144 tokens, ce qui est déjà énorme). Si Inkling est en dessous, il faudra segmenter — et la segmentation a un coût en qualité. À vérifier dans la model card.

Function calling. Les benchmarks de référence sont BFCL v4 et Tau2-Bench. Kolibri-1 affiche 61,4 % sur BFCL v4, 76,7 % sur Tau2-Bench Airline, 69,9 % sur Retail, 94,7 % sur Telecom, mais seulement 38,1 % sur Tau3-Bench Banking — ce qui montre à quel point les résultats varient selon les domaines. Un modèle peut être excellent en réservation aérienne et médiocre en banque. À tester sur votre domaine.

On-premise souverain. C’est le point où Inkling pourrait le plus se distinguer, s’il est publié sous licence permissive (Apache 2.0 ou équivalent) et avec des poids en BF16/FP8. Aleph Alpha a fait ce choix explicitement avec Kolibri-1, en mettant en avant l’allemand et l’anglais pour le marché européen. Si Inkling est sous licence restrictive, l’argument souverain s’effondre.

Les angles morts : données d’entraînement, dépendance à un jeune lab, licence révocable

Récapitulons les zones d’ombre, car c’est d’elles que dépend le verdict.

Opacité des données d’entraînement. Aucune information. C’est un problème à trois titres : (1) risque de contamination des benchmarks, (2) incertitude sur la couverture linguistique, (3) risque juridique si le corpus contient des données sous copyright ou issues d’un modèle fermé dont les conditions d’usage interdisent la distillation.

Dépendance à un lab de moins de deux ans. Thinking Machines est jeune, et sa pérennité n’est pas garantie. Un modèle open weight survit à son lab — les poids sont téléchargeables, la communauté peut les maintenir — mais l’écosystème (tokenizer, recettes de fine-tuning, patches de sécurité, support vLLM) dépend du lab. Si le lab disparaît, le modèle devient orphelin. C’est un risque à intégrer dans la décision.

Licence révocable. Si la licence d’Inkling est custom et révocable, un déploiement en production peut être remis en cause du jour au lendemain. C’est un scénario qui s’est produit dans l’écosystème (changements de licence rétroactifs), et qui rend les directions juridiques nerveuses.

Réaction des concurrents. Meta a publié Muse Spark Open le 15 octobre 2026, avec des specs détaillées et un positionnement clair. Aleph Alpha a publié Kolibri-1 le 3 octobre 2026 sous Apache 2.0. Les labs chinois continuent de publier à un rythme soutenu. La pression concurrentielle va probablement pousser Thinking Machines à publier des specs détaillées dans les semaines qui viennent — ou à disparaître du radar.

Scénarios qui invalideraient la migration dans les 12 mois :

1. Publication d’une licence restrictive (usage commercial conditionnel, seuil d’utilisateurs, interdiction de distillation) qui rend le déploiement en production impossible sans renégociation.
2. Absence de support vLLM/SGLang au-delà de quelques semaines, ce qui condamne le modèle à l’expérimentation.
3. Révélation d’une contamination massive des benchmarks, qui invaliderait les scores annoncés.
4. Publication par Meta, Aleph Alpha ou un lab chinois d’un modèle aux specs supérieures sous licence permissive, ce qui rendrait Inkling obsolète avant même d’être adopté.
5. Disparition ou pivot du lab, qui laisserait le modèle sans maintenance.

Verdict : ni migration, ni abandon — un POC, et des critères

Que vaut Inkling, en définitive ? Sur la base de la matière disponible, la réponse honnête est : on ne sait pas encore, et c’est précisément ce qu’il faut retenir.

Ce que l’on sait : Thinking Machines a publié un modèle open weight nommé Inkling, la presse l’a présenté comme un possible nouveau leader occidental des open weights, et le contexte concurrentiel est dominé par Meta (Muse Spark Open, 816B/42B, contexte 1M, publié le 15 octobre 2026) et par les labs chinois. Ce que l’on ne sait pas : l’architecture, les paramètres, la licence, les benchmarks, le support outillage, le coût de déploiement.

Pour un praticien, la recommandation est donc graduée :

• Ne pas migrer une stack en production sur la base d’un titre d’agence. Le risque juridique (licence inconnue) et le risque technique (outillage inconnu) sont trop élevés.
• Faire un POC dès que les poids et la licence sont publiés, sur un cas d’usage précis (RAG français, coding agentique, function calling sur votre domaine), avec des métriques définies à l’avance.
• Surveiller quatre signaux dans les 6 à 12 mois : (1) publication d’une model card détaillée ; (2) publication d’une licence lisible et permissive ; (3) support effectif dans vLLM et SGLang avec des configs de référence ; (4) benchmarks indépendants (LiveBench, Arena Elo) qui confirment ou infirment les scores annoncés.
• Garder un plan B : Meta Muse Spark Open, Aleph Alpha Kolibri-1 (Apache 2.0, contexte 1M, orienté souveraineté européenne), ou un modèle chinois selon le cas d’usage.

Le titre de l’article — « Thinking Machines passe devant » — est, en l’état, une affirmation non étayée. Elle peut devenir vraie dans les semaines qui viennent, si le lab publie ce qu’il doit publier. Elle peut aussi rester un titre. C’est au lab de faire le travail, pas aux praticiens de parier à l’aveugle.

Sources

• MSN — reprise d’article sur la sortie d’Inkling par Thinking Machines Lab
• Meta — Introducing Muse Spark Open, The Most Capable US Open-Weight Model to Date (15 octobre 2026)
• iaexpertos.net — Meta lance Muse Spark Open : MoE de 816 milliards, contexte 1M (16 octobre 2026)
• blockchain.news — Meta unveils Muse Spark Open with 1M context, 42B active (15 octobre 2026)
• the-agent-report.com — 816B, 560B, 120B en un jour : la vague open-weight se heurte à un mur de mémoire (16 octobre 2026)
• Aleph Alpha — Kolibri-1, publication du 3 octobre 2026 (Apache 2.0, 78,1B/3,46B, contexte 1 048 576 tokens)
• unite.ai — Inception Releases Mercury 3, Its Flagship Diffusion LLM (19 octobre 2026)
• note.com — vLLM et SGLang portés sur TPU par Google (20 octobre 2026)
• unite.ai — llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack (20 octobre 2026)
• topai-tools.org — Deconstructing Mixture-of-Experts (MoE) Routing in Open-Weight Models (28 octobre 2026)
• NVIDIA — Nemotron 3.5 Transcribe (28 octobre 2026)
• the-agent-report.com — couverture de la vague open-weight (16 octobre 2026)

Article recherché et rédigé automatiquement · Magazine Electrosens