Inkling expliqué : le modèle d'IA à poids ouverts de Thinking Machines

Qu'est-ce qu'Inkling ?

Inkling est le premier modèle public de Thinking Machines Lab, et le laboratoire est étonnamment franc sur le fait qu'il ne cherche pas à remporter le classement. L'argument, c'est une base ouverte large et équilibrée que vous affinez pour votre propre usage, via la plateforme Tinker du labo. Autrement dit, Inkling se veut un point de départ à façonner, pas un chatbot auquel on s'abonne.

Les caractéristiques qui comptent, directement issues de la fiche modèle :

• Architecture : un transformer Mixture-of-Experts (MoE), 975 Md de paramètres au total avec 41 Md actifs par token (il route chaque token vers 6 des 256 experts, plus 2 experts partagés). C'est pourquoi un modèle d'environ mille milliards de paramètres peut être servi à une vitesse raisonnable : seule une fraction fonctionne pour chaque token.
• Entrées : texte, images et audio (WAV 16 kHz, de préférence moins de 20 minutes environ). La sortie est uniquement du texte.
• Fenêtre de contexte : jusqu'à 1 M de tokens, ce qui le place dans le groupe de tête des modèles en matière de longueur.
• Licence : Apache 2.0, l'usage commercial est donc autorisé et les poids sont sur Hugging Face.
• Sortie : 15 juillet 2026.

La partie audio est l'élément inédit. Comme l'a formulé le commentaire le plus populaire du fil de lancement, c'est le "plus grand modèle à poids ouverts qui prend en charge l'audio", ce qui compte si vous voulez un jour qu'un modèle écoute un appel de support plutôt que de simplement lire sa transcription.

Comment Inkling est construit

Pour les amateurs de plomberie technique, Inkling fait quelques choix d'architecture inhabituels. Au lieu des désormais standard rotary position embeddings (RoPE), le rapport de l'équipe décrit un schéma de position relative intégré directement dans les logits d'attention, plus de courtes convolutions sur les keys et values avant qu'elles n'atteignent le cache. L'objectif pratique est le même que celui de tout modèle à long contexte : garder l'attention stable et peu coûteuse quand le contexte s'étire vers le million de tokens.

Pas besoin de décortiquer le schéma pour saisir l'essentiel : Inkling est conçu autour du contexte long et du raisonnement efficace, pas pour dominer un seul benchmark. Cela se retrouve aussi dans sa façon de "réfléchir".

Le curseur d'effort de raisonnement

Inkling est un modèle de raisonnement et propose un réglage d'"effort de réflexion" ajustable. Dans l'intégration Hugging Face, c'est un niveau reasoning_effort qui va de none et minimal jusqu'à low, medium, high, xhigh et max. Baissez-le et le modèle répond vite et à moindre coût ; montez-le et il dépense plus de tokens à réfléchir avant de répondre.

L'argument sur lequel Thinking Machines s'appuie ici est l'efficacité en tokens : ils affirment qu'Inkling atteint le même score Terminal-Bench que Nemotron 3 Ultra en dépensant environ un tiers des tokens pour y arriver. Pour quiconque paie au token ou loue un GPU, "même réponse, moins de tokens" est un chiffre plus utile qu'une victoire de justesse sur un benchmark.

Les benchmarks : solide, mais pas roi

C'est ici qu'il faut séparer l'argumentaire du fournisseur de la lecture indépendante. Les propres tableaux de Thinking Machines montrent des chiffres flatteurs à effort maximal, mais le signal le plus propre vient d'Artificial Analysis, qui benchmarke tout le monde de la même façon.

Leur verdict : Inkling obtient 41 points sur l'AA Intelligence Index, ce qui le classe #10 sur 97 sur leur classement sélectionné, bien au-dessus de la moyenne d'environ 25 pour les modèles à poids ouverts de cette taille. C'est donc un modèle intelligent. Mais il se situe en dessous des leaders de pointe (Claude Fable 5, GPT-5.6, Kimi K3, Grok 4.5, GLM-5.2) et atterrit dans un groupe avec des pairs comme DeepSeek V4 Flash. Les classements communautaires qui incluent davantage de modèles le placent encore plus bas, plus proche du #41, d'où vient le débat sur la légitimité du terme "compétitif".

En lisant ce tableau honnêtement, on obtient une vraie personnalité : Inkling est solide en raisonnement scientifique et à long contexte, et nettement faible en physique et en fiabilité brute des connaissances (son indice de fiabilité des connaissances AA-Omniscience n'est que de 2 sur une échelle de −100 à 100). C'est un modèle avec des angles marqués, pas un généraliste bien lissé.

Le fil de lancement a saisi la même chose. Éloges et scepticisme se côtoyaient :

"Je viens de regarder les benchmarks et j'ai été un peu déçu qu'il semble se situer entre KimiK2.6 et KimiK2.7 sur la plupart d'entre eux."

juliangoetze, Hacker News

Et la réponse la plus utile de tout le fil, celle qu'il vaut la peine d'afficher au-dessus de son écran avant de faire confiance à n'importe quelle comparaison de modèles :

"Vous voulez savoir à quel point un modèle est bon ? Faites-le tourner sur votre propre benchmark non public, c'est fondamentalement la seule façon d'avoir des réponses fiables auxquelles on peut à peu près se fier, tout le reste est manipulé, mal compris ou surestimé."

embedding-shape, Hacker News

Cet instinct, que le seul benchmark qui compte, ce sont vos propres données, est exactement celui qu'il faut garder en tête si vous braquez un jour un modèle sur votre file de support. Plus de détails plus bas.

Combien coûte Inkling ?

C'est la partie qui m'a surpris. Inkling est à poids ouverts, et pourtant, sur l'API propre de Thinking Machines, il est tarifé comme un modèle de pointe propriétaire. Selon Artificial Analysis, il se classe #81 sur 97 côté prix, c'est-à-dire parmi les plus chers de sa catégorie.

Deux choses ressortent. D'abord, il n'y a actuellement qu'un seul fournisseur d'API, Thinking Machines lui-même, donc aucun hébergeur tiers moins cher ne vient encore casser les prix. Ensuite, "poids ouverts" ne rend le modèle gratuit que si vous êtes prêt à le faire tourner vous-même, ce qui est une vraie décision, pas une note de bas de page.

Faire tourner Inkling soi-même

Comme les poids sont ouverts, la communauté l'a fait tourner en local dès le premier jour. Le blog de lancement Hugging Face présente trois paliers approximatifs, que l'échelle ci-dessus résume : le checkpoint complet en BF16 demande environ 2 To de VRAM (territoire de datacenter), la quantification NVFP4 ramène cela à environ 600 Go sur du matériel Blackwell, et les versions GGUF 1 bit de la communauté réduisent cela d'environ 95 %, assez pour faire tourner une version fortement quantifiée sur une station de travail costaude.

Le support est arrivé rapidement aussi : intégration dès le jour zéro dans transformers 5.14, SGLang, vLLM et llama.cpp/Unsloth, plus des couches de brouillon pour le décodage spéculatif offrant une accélération sans perte. Voici un modèle en 1 bit tournant réellement dans le studio d'Unsloth, écrivant un jeu HTML complet et "réfléchissant" pendant 321 secondes avec une fenêtre d'un million de tokens :

Cette histoire de "faites-le tourner vous-même" est la vraie raison de s'intéresser à Inkling. Si vous hésitez entre un modèle ouvert et un modèle fermé, le compromis se joue entre contrôle et confort : vous possédez les poids, vos données ne quittent jamais votre infrastructure, et personne ne peut vous retirer le modèle sous les pieds, mais vous voilà désormais responsable des GPU.

L'angle entreprise

Pour les équipes qui veulent le contrôle sans surveiller un cluster de GPU, Inkling est apparu sur Databricks dès le jour zéro, accessible via l'Unity AI Gateway avec la gouvernance intégrée. L'argument entreprise avancé est le même que celui qui rend les poids ouverts attractifs : affiner sur vos propres données, rester dans votre périmètre de gouvernance, et éviter la tarification au token.

Devriez-vous choisir Inkling ?

Plutôt qu'une échappatoire du type "ça dépend de vos besoins", voici un chemin de décision direct basé sur ce en quoi Inkling est réellement bon et mauvais.

Ce que la communauté en pense vraiment

Le fil de lancement sur Hacker News (1 214 points, ~292 commentaires) est l'instantané le plus clair de la façon dont les développeurs ont accueilli Inkling. L'ambiance était enthousiaste mais mesurée, et l'excitation portait moins sur les scores que sur qui l'a lancé :

"Sans oublier que c'est américain. C'est le premier modèle à poids ouverts compétitif non chinois depuis, quoi, Llama 3 ?"

paxys, Hacker News

Ce cadrage a suscité des objections (des gens ont cité Mistral, North de Cohere, Gemma et d'autres comme contre-exemples), mais le sentiment sous-jacent, qu'une option occidentale crédible à poids ouverts se faisait attendre, a traversé tout le fil. Il y avait aussi une bonne dose de "comment une entreprise qui donne son modèle survit-elle ?", la réponse retombant sur Tinker, l'activité de fine-tuning hébergée :

"L'histoire de la tech est jonchée des cadavres de services "open source mais on vend l'hébergement". Les modèles coûtent tellement cher à entraîner qu'on ne peut pas se permettre de perdre les gros clients une fois qu'ils deviennent vraiment rentables."

tyre, Hacker News

Reste la question ouverte de savoir si ce modèle économique tient la route. Mais pour l'instant, les développeurs ont eu droit à un modèle capable, multimodal et entièrement ouvert à explorer, et la plupart en étaient satisfaits.

Ce qu'un modèle comme Inkling signifie pour le support client

Voilà où j'ai passé ces dernières années, alors permettez-moi d'être direct. Je construis la couche d'agent qui se place au-dessus de modèles comme Inkling, et ce que j'ai appris en observant de vrais déploiements, c'est ceci : un meilleur modèle de base change rarement ce qui finit réellement par arriver dans une file de support.

Un modèle brut, aussi intelligent soit-il, ne connaît pas votre politique de remboursement, ne peut pas voir les 40 000 derniers tickets que votre équipe a déjà résolus, et n'a aucune idée du moment où il devrait se taire et passer la main à un humain. Pointez-le directement vers vos clients et il répondra avec assurance et de façon incorrecte, ce qui est pire que de ne pas répondre du tout. Ce mode d'échec, le bot confiant mais faux, est exactement la raison pour laquelle les hallucinations d'IA dans le support coûtent cher aux équipes, et pourquoi le modèle n'est jamais que le moteur.

La voiture, c'est la couche autour. C'est ce qu'est eesel : elle apprend de vos tickets résolus et de votre documentation d'aide (pas juste d'une page marketing), route selon le niveau de confiance pour que les réponses peu fiables soient mises en brouillon plutôt qu'envoyées, et, le point qui me tient le plus à cœur, elle vous permet de simuler l'agent sur vos propres tickets passés avant qu'un seul client ne le voie. Cette simulation, c'est le conseil "testez-le sur votre propre benchmark" de Hacker News, transformé en étape produit.

Cela signifie aussi que vous n'avez pas besoin de miser toute votre pile de support sur un seul modèle. Le meilleur modèle change toutes les quelques semaines (Inkling aujourd'hui, un autre le mois prochain), donc eesel reste indépendant du modèle et s'appuie sur le plus performant à chaque instant, tandis que ce qui compte vraiment pour vos clients, la connaissance, les garde-fous, le tri des tickets, reste stable.

Essayez eesel

Inkling est une sortie intéressante, mais une fiche modèle n'est pas un agent de support. Si votre véritable objectif est d'automatiser le support de niveau 1, ce qu'il vous faut, c'est la couche qui transforme n'importe quel modèle performant en coéquipier : eesel se branche sur votre helpdesk existant (Zendesk, Freshdesk, Gorgias, HubSpot, Front et plus de 100 autres), apprend de votre historique, et vous permet de simuler sur de vrais tickets passés avant de passer en production, pour que vous voyiez la couverture et la précision en amont, pas après qu'un client ait repéré une mauvaise réponse. Gridwise a utilisé exactement cette approche pour résoudre 73 % des demandes de niveau 1 dès son premier mois.

La tarification est basée sur l'usage, à environ 0,40 $ par ticket résolu, sans frais par siège, et vous pouvez commencer gratuitement. C'est la différence entre admirer un excellent moteur et vraiment aller quelque part.