Magazine LLM Opensource · 3 November 2026

Clef et Clef-flash : quand Cloudflare invente le LLM qui refuse de parler

Cloudflare a mis en ligne, le 30 septembre 2026, deux modèles open-weight qui ne rédigent rien. Pas de phrases, pas de markdown, pas de « Bien sûr, voici… ». Juste une probabilité par réponse autorisée. Derrière l’apparente austérité, c’est peut-être la première brique d’inférence vraiment pensée pour les pipelines — et un caillou sérieux dans la chaussure de l’écosystème open-weight tel qu’on le connaissait.

Clef, Clef-flash : le jour où Cloudflare a débranché le chatbot

Il faut mesurer ce que Cloudflare vient de faire. Le 30 septembre 2026, la société a publié les poids de Cloudflare/clef-flash sur Hugging Face, puis officialisé le 1er octobre 2026 la sortie de deux modèles open-weight, Clef et Clef-flash, présentés comme des modèles de décision — des modèles qui renvoient des probabilités typées plutôt que du texte libre. Pour un acteur dont le métier historique est de servir des octets au bord du réseau, entrer sur le terrain des LLM avec une proposition qui refuse de générer du texte n’est pas un caprice. C’est un signal.

Cloudflare n’arrive pas en terrain vierge. La société opère Workers AI, une plateforme d’inférence serverless, et AI Gateway, une couche de routage et d’observabilité devant les API de modèles. Elle a noué des partenariats avec Hugging Face, Meta et Mistral pour héberger des modèles ouverts au plus près des utilisateurs. Dans cette architecture, le goulot d’étranglement n’a jamais été la qualité rédactionnelle : c’est la décision. Router une requête vers le bon modèle, choisir une région, décider si un contenu passe un garde-fou, scorer la pertinence d’un résultat — autant d’étapes où l’on a longtemps payé un LLM complet pour produire trois paragraphes dont on ne lisait que le premier token utile.

C’est précisément le problème que Clef et Clef-flash cherchent à résoudre. Et le sujet dépasse largement le lancement produit : il touche à la définition même de ce qu’est un modèle open-weight en 2026, à la manière de le servir, et à la façon de le benchmarker. Trois choses qu’on croyait acquises, et qui viennent de bouger.

Un LLM qui répond « oui à 0,87 » au lieu de rédiger trois paragraphes

La rupture conceptuelle mérite qu’on s’y arrête, parce qu’elle est plus profonde qu’elle n’en a l’air. Un LLM classique, même contraint par grammaire ou par masquage de logits, reste un générateur de texte déguisé. On lui interdit certaines sorties, on le force à produire du JSON valide, on le contraint à choisir parmi deux tokens — mais le mécanisme sous-jacent reste le même : il émet une séquence, token après token, dans un espace de vocabulaire ouvert (ou artificiellement refermé). La contrainte est un filtre posé sur un générateur.

Clef-flash inverse la logique. Il prend en entrée un état et un schéma de questions typées, et renvoie une probabilité calibrée pour chaque réponse autorisée, en une seule passe non autorégressive, sans émettre de texte. Le modèle ne « choisit » pas un token : il évalue la plausibilité de chaque réponse déclarée, et rend un vecteur de probabilités. C’est la différence entre demander à quelqu’un de réciter la liste des capitales possibles et lui demander, carte sur la table, de pointer celle qu’il croit correcte.

Ce glissement change la nature de l’objet manipulé. On ne tokenise plus des mots : on encode des états et des schémas de questions. La « tokenisation des décisions » consiste à transformer une décision structurée — un label, une catégorie, un booléen, un score — en une représentation que le transformer peut traiter, puis à produire en sortie une distribution sur l’espace fermé des réponses autorisées. Ce n’est pas un softmax sur un vocabulaire ouvert de 150 000 tokens, dont on ne garderait que quelques cases. C’est un softmax sur un espace déclaré en entrée, dimensionné à la question posée.

La nuance est cruciale pour les praticiens. Un LLM contraint par grammaire peut toujours, en pratique, produire une sortie hors schéma si la contrainte est mal implémentée, ou noyer la bonne réponse dans une formulation verbeuse. Un modèle de décision, lui, n’a structurellement pas de « prose » à produire : l’espace de sortie est la réponse.

Sous le capot : Qwen dans le moteur, une tête de décision à la place du décodeur

Que sait-on vraiment de l’architecture ? Il faut ici être honnête sur la frontière entre faits confirmés et reconstructions.

Ce qui est confirmé par la fiche Hugging Face et la documentation Workers AI : Cloudflare/clef-flash est un modèle de 9 milliards de paramètres, multimodal (image-texte-vers-sortie typée), basé sur une architecture qwen3_5 (ou qwen3.5), conçu pour des tâches de classification et de sortie structurée, utilisable avec Transformers et vLLM, publié sous une licence nommée « clef ». Les tags associés — cloudflare, systemone, post-train, custom-code, conversational — confirment qu’il s’agit d’un modèle post-entraîné, c’est-à-dire d’un fine-tune plutôt que d’un entraînement from scratch.

La page modèle officielle de Cloudflare apporte des précisions que les premières synthèses n’avaient pas : Clef-flash est décrit comme un « fast 9B multimodal decision model » qui lit l’état sous forme de texte, JSON, images ou vidéo, et renvoie une probabilité pour chaque option autorisée de chaque question. La fenêtre de contexte y est chiffrée à 24 576 tokens — bien loin des 64k avancés par certaines sources secondaires. Le tarif est de 0,038 $ par million de tokens d’entrée, avec rétention zéro des données. La licence renvoie à un fichier LICENSE sur Hugging Face, sans que le texte complet soit accessible dans nos sources.

Ce qui relève de la reconstruction tierce, et qu’il faut prendre avec des pincettes : plusieurs sources secondaires décrivent Clef comme un fine-tune open-weight construit sur une base Qwen3.8-27B, et Clef-flash sur une base Qwen3-8B. Une source unique (cryptobriefing.com) avance pour Clef 27 milliards de paramètres, une fenêtre de contexte de 64k tokens, et des entrées texte/JSON/images/vidéo. Ces chiffres ne sont corroborés ni par la documentation officielle Cloudflare — qui donne 24 576 tokens pour la variante flash — ni par une seconde source indépendante. La prudence s’impose : la fiche Workers AI est la source la plus fiable dont on dispose, et elle contredit la fourchette 64k.

Sur la méthode d’entraînement — supervisé, distillation, RLHF — aucune information fiable n’est disponible. On ne sait pas non plus si le modèle utilise une tête de classification dédiée, un masquage de vocabulaire, ou une autre mécanique. Autrement dit : on connaît l’existence du produit, sa taille pour la variante flash, sa base probable, son format d’entrée-sortie et son prix. On ignore l’essentiel de la cuisine interne.

Cette opacité n’est pas anodine. Pour un modèle dont l’argument central est la fiabilité de la calibration, ne pas publier la méthode d’entraînement ni les métriques de calibration est un angle mort. On y reviendra.

Ce que « probabilité typée » veut dire (et ce que ce n’est pas)

Entrons dans le format d’entrée-sortie, parce que c’est là que se joue la vraie différence pour quiconque doit intégrer le modèle dans un pipeline. La documentation Workers AI est ici précieuse, et elle précise un point que les premières descriptions laissaient flou : le contrat d’API.

La requête comporte un champ model obligatoire, dont la valeur doit correspondre au motif ^\s*(clef|clef-flash)\s*$ — clef pour @cf/cloudflare/clef, clef-flash pour @cf/cloudflare/clef-flash. Puis un champ state, qui porte l’état à évaluer. Puis un objet questions obligatoire, contenant de 1 à 64 questions, chaque identifiant pouvant utiliser lettres, chiffres, _, . et - (100 caractères maximum). Chaque question est typée : noul (booléen oui/non/nul), choice (choix parmi des options déclarées) ou score (évaluation sur une échelle). La réponse renvoie, sous les mêmes identifiants, une probabilité par option autorisée.

S’y ajoute une extension propre à Clef : un tableau images optionnel, de 4 images maximum (PNG, JPEG ou WebP), placées avant l’état, limitées à 4 Mio et 16 mégapixels chacune, 8 Mio au total décodé, et un corps de requête plafonné à 13 Mio. Les URL distantes ne sont pas acceptées — il faut envoyer les octets. La réponse contient aussi un champ model (le modèle qui a effectué l’évaluation) et un objet usage.

Ce que ce n’est pas : ce n’est pas un LLM qui répondrait « oui » et auquel on demanderait ensuite, par un prompt séparé, d’estimer sa confiance. Ce n’est pas non plus un softmax sur vocabulaire ouvert dont on lirait la probabilité du token « oui » — approche notoirement mal calibrée, parce que la probabilité d’un token dépend de tout le contexte de génération et n’a aucune raison de correspondre à une fréquence empirique.

Les garde-fous techniques qui empêchent le modèle de « parler » sont, en l’état des sources, inférés plutôt que documentés : contraintes de décodage, masquage de vocabulaire, ou tête dédiée. La conséquence pratique, elle, est claire et c’est ce qui compte pour l’intégrateur : la réponse est parsable sans post-traitement. Pas de regex pour extraire un JSON d’un bloc markdown, pas de retry quand le modèle a décidé de commenter sa réponse, pas de parsing défensif. Le schéma est déclaré, la réponse est conforme — et les identifiants de questions reviennent tels quels, ce qui simplifie le routage interne du pipeline.

Ce basculement déplace les critères de sélection. Pour un modèle de décision branché dans un gateway, la qualité rédactionnelle n’existe pas comme métrique. Ce qui compte, c’est la latence, le débit, le déterminisme et la calibration. Un modèle de 9B qui rend une décision en une passe non autorégressive n’a pas le même profil de coût qu’un modèle de 70B qui génère 200 tokens pour aboutir à un « oui ».

Routage, scoring, garde-fous, agents : là où un modèle qui ne parle pas gagne

Prenons quatre cas d’usage concrets, du plus évident au plus subtil.

Le routage. Dans un AI Gateway, chaque requête entrante doit être dirigée vers un modèle, une région, un niveau de service. Aujourd’hui, on le fait soit avec des règles, soit avec un LLM classificateur. Clef-flash, avec ses 9B paramètres et sa sortie typée, est taillé pour ça : on déclare les routes possibles comme autant de choice, il rend une probabilité par route. Pas de texte à parser, pas de latence de génération. La complexité d’intégration est réelle mais bornée : il faut définir l’espace de routage, le versionner, et gérer les cas où aucune route n’atteint un seuil de confiance. C’est exactement le terrain de jeu décrit dans notre dossier sur les LLM gateways en 2026 : le gateway est devenu le lieu où l’on arbitre entre modèles, et un modèle de décision logé dans cette couche change l’économie du routage.

Le scoring. Pertinence d’un résultat de recherche, niveau de risque d’un contenu, priorité d’un ticket. Là encore, un modèle qui rend un score typé sur une échelle déclarée évite toute la mécanique de « demande au LLM de noter de 1 à 10 et espère qu’il respecte la consigne ». Le score est une probabilité sur un espace fermé, pas un entier halluciné dans une phrase. La limite de 64 questions par requête est d’ailleurs un indicateur de conception : Clef est pensé pour des batteries de questions courtes et bornées, pas pour un formulaire de 500 items.

Les garde-fous. C’est peut-être le cas le plus convaincant. Un filtre de contenu a besoin d’une décision binaire ou catégorielle avec un seuil de confiance exploitable. Un LLM contraint par grammaire peut produire {"safe": false}, mais la confiance associée est peu fiable. Un modèle de décision calibré, en principe, permet de régler le seuil en connaissance de cause : on accepte les décisions à 0,9, on escalade celles entre 0,5 et 0,9. C’est exactement ce qu’on attend d’un classifieur, pas d’un générateur. La question de la sécurité des agents — et de la façon dont un garde-fou mal calibré peut devenir une passoire — est d’ailleurs au cœur de notre enquête sur NemoClaw et la faille Cyera : un filtre qui dit « sûr » avec une confiance non calibrée n’est pas un filtre, c’est un rite.

Les agents. Dans une boucle d’agent, l’étape « choisir une action » n’a jamais eu besoin de prose. Elle a besoin d’une distribution sur les actions possibles, éventuellement conditionnée par l’état courant. C’est le cœur de ce que fait un modèle de décision. L’apport face à un LLM classique : moins de tokens consommés, moins de latence, et une décision directement exploitable par le contrôleur de l’agent.

Le fil rouge de ces quatre cas : la latence et le déterminisme priment sur la verbosité. C’est précisément le profil d’un déploiement edge, où l’on paie chaque milliseconde et où l’on veut pouvoir reproduire une décision à l’identique pour l’audit.

Calibration, dérive, coût caché : les trois cailloux dans la chaussure

Il serait malhonnête de présenter Clef comme une solution sans friction. Trois problèmes structurels se posent, et ils sont sérieux.

La calibration. Une probabilité n’est utile que si elle est calibrée : quand le modèle dit 0,8, il doit avoir raison environ 80 % du temps. Or la calibration n’est jamais gratuite, et elle se dégrade dès qu’on sort de la distribution d’entraînement. Un modèle de décision entraîné sur des schémas de questions d’un certain type verra sa calibration se dégrader sur des schémas inédits. C’est un problème connu des classifieurs, mais il est ici central puisque toute la promesse repose dessus. Or, à ce jour, aucune métrique de calibration — ECE, Brier score — n’est publiée pour Clef ou Clef-flash. C’est l’angle mort le plus gênant, et il est d’autant plus visible que la documentation officielle détaille le contrat d’API avec précision tout en restant muette sur les performances.

La dérive des schémas. Un modèle de décision est défini par l’espace de sortie qu’on lui déclare. Quand les catégories évoluent — une nouvelle route, une nouvelle classe de risque — il faut réévaluer le modèle. Un LLM génératif encaisse une nouvelle catégorie en changeant le prompt ; un modèle de décision, lui, doit avoir vu cette catégorie à l’entraînement, ou voir sa calibration s’effondrer sur la classe inédite. La limite de 64 questions et le typage strict (noul, choice, score) rendent cette rigidité explicite : c’est un contrat, pas une conversation. Pour les équipes habituées à itérer sur des prompts, c’est un changement de discipline.

Le coût caché. À 0,038 $ par million de tokens d’entrée, Clef-flash semble dérisoire. Mais le coût réel d’un modèle de décision n’est pas le token : c’est l’ingénierie du schéma. Définir les questions, les typer, les versionner, gérer les images (4 maximum, 13 Mio de corps de requête), surveiller la dérive, recetter la calibration à chaque évolution — autant de travail qui n’existait pas quand on se contentait d’un prompt. Et la limite de contexte de 24 576 tokens rappelle que l’« état » qu’on peut soumettre reste borné : pas question d’y glisser un document de 100 pages. C’est un modèle de décision sur état court, pas un analyseur de corpus.

Ce que Clef dit de l’écosystème open-weight en 2026

Replaçons Clef dans le paysage. La rentrée 2026 a été marquée par une vague de modèles ouverts toujours plus gros : Meta a publié le 15 octobre Muse Spark Open, un MoE de 816 milliards de paramètres (42 milliards actifs) avec un contexte d’un million de tokens ; Aleph Alpha a sorti Kolibri-1 le 3 octobre, un MoE de 78,1 milliards (3,46 milliards actifs) sous Apache 2.0 ; NVIDIA a publié le 28 octobre Nemotron 3.5 Transcribe, un modèle vocal ouvert couvrant 40 langues. La course au paramètre et au contexte fait rage — et elle se heurte, comme le documente notre enquête sur le mur de mémoire, à des contraintes matérielles de plus en plus dures.

Clef prend le contre-pied exact. 9 milliards de paramètres, 24 576 tokens de contexte, pas de génération. Ce n’est pas un modèle « plus petit » : c’est un modèle d’une autre nature, qui revendique l’étroitesse comme un choix. Là où Muse Spark Open promet d’écrire du code agentique sur un million de tokens, Clef-flash promet de trancher 64 questions fermées sur un état court, pour 0,038 $ le million de tokens. Les deux sont open-weight ; ils ne jouent pas au même jeu.

Cette divergence éclaire un point que notre dossier sur les licences open-weight soulignait déjà : le mot « ouvert » ne veut plus rien dire de précis. Clef est publié sous une licence maison, « clef », dont le texte n’est accessible que via un fichier sur Hugging Face — ni Apache 2.0 comme Kolibri-1, ni les conditions Llama. Un modèle de décision dont la licence est propre à l’éditeur, dont la méthode d’entraînement n’est pas publiée et dont la calibration n’est pas documentée : c’est « ouvert » au sens des poids téléchargeables, pas au sens de la reproductibilité. Pour un composant destiné à trancher des décisions en production, la distinction compte.

Le lancement s’inscrit aussi dans une actualité d’infrastructure dense. Le 20 octobre, llm-d 1.0 a été présenté à la PyTorch Conference North America comme une pile d’inférence distribuée Kubernetes-native ; le 21 octobre, Google a annoncé les versions TPU de vLLM et SGLang. Autrement dit, l’écosystème de serving mûrit vite — et un modèle de 9B multimodal, servi via vLLM comme le confirme la fiche Hugging Face, s’insère dans cette mécanique sans friction. Clef-flash n’est pas un objet exotique : c’est un modèle Transformers standard avec un contrat d’entrée-sortie inhabituel.

Reste la question de fond, celle qui décidera de l’adoption. Un modèle de décision ne remplace pas un LLM : il le complète dans les étages où la prose est un coût, pas une valeur. Routage, scoring, garde-fous, sélection d’action — ces quatre étages représentent une part considérable des appels en production, et une part disproportionnée du gaspillage. Si Clef-flash tient sa promesse de calibration, il rend obsolète toute une classe de prompts de classification bricolés. S’il ne la tient pas — et rien ne permet aujourd’hui de l’affirmer —, il ne restera qu’un classifieur de plus, avec une jolie API et une licence obscure.

La balle est dans le camp de Cloudflare : publier des métriques de calibration, documenter la méthode d’entraînement, éclaircir la licence. Trois documents qui manquent, et sans lesquels Clef restera, pour l’instant, une très belle idée dont on ne peut pas encore mesurer la fiabilité. C’est le paradoxe de 2026 : les modèles ouverts n’ont jamais été aussi nombreux, et la confiance qu’on peut leur accorder, aussi difficile à établir.

Sources

• Clef-flash — Cloudflare Workers AI docs — fiche modèle officielle : 9B, multimodal, contexte 24 576 tokens, tarif 0,038 $/M tokens d’entrée, schéma de requête (model, state, questions 1-64, images max 4, corps 13 Mio), rétention zéro.
• Introducing Clef: Cloudflare’s first open-source decision models, now on Workers AI — changelog Cloudflare — annonce officielle du 1er octobre 2026.
• Cloudflare/clef-flash — Hugging Face — poids, tags (cloudflare, systemone, post-train, custom-code, conversational), architecture qwen3_5, licence « clef ».
• Cloudflare/clef-flash — LICENSE — fichier de licence référencé par la fiche modèle.
• Introducing Muse Spark Open, The Most Capable US Open-Weight Model to Date — Meta AI Research — 816B total / 42B actifs, contexte 1M, 15 octobre 2026.
• Aleph Alpha Kolibri-1-BF16 — Hugging Face — MoE 78,1B / 3,46B actifs, Apache 2.0, 3 octobre 2026.
• NVIDIA Nemotron 3.5 Transcribe — NVIDIA Research — modèle vocal ouvert 40 langues, 28 octobre 2026.
• llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack — Unite.AI — pile d’inférence Kubernetes-native, 20 octobre 2026.
• 「vLLM」「SGLang」がTPUに対応 — note.com — versions TPU de vLLM et SGLang, 21 octobre 2026.
• 816B, 560B, 120B en un jour : la vague open-weight se heurte désormais à un mur de mémoire — The Agent Report — 16 octobre 2026.
• « Clé » ou « clef » ? — La langue française — rappel orthographique : les deux formes sont admises ; le nom propre du modèle reste « Clef ».

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