Cloudflare Clef-omni étend les décisions multimodales, mais la précision reste la limite

Cloudflare Clef-omni a été lancé le 9 octobre avec un traitement natif de l’audio, de la vidéo, des images et du texte dans un même pipeline de décision. L’entreprise a également réduit les tarifs de Clef-flash et accéléré l’inférence Clef hébergée jusqu’à 2,0x. Ensemble, ces évolutions font d’une famille de modèles vieille d’à peine une semaine un défi plus large pour les systèmes à plusieurs étapes que les développeurs utilisent aujourd’hui pour automatiser les décisions.

Le changement important n’est pas simplement qu’un nouveau modèle accepte les médias. Les modèles généralistes le font déjà. Cloudflare présente la compréhension multimodale comme un service de décision contraint, qui renvoie des probabilités pour des réponses autorisées plutôt que de générer du texte ouvert.

Cette distinction place Cloudflare face à Jev de TypeSafe et à une architecture plus établie : connecter séparément des composants de transcription, de vision, de langage et de classification. Clef-omni invite les développeurs à remplacer cette chaîne par un seul appel de modèle. Cette approche promet moins d’orchestration, mais les propres résultats de benchmark de Cloudflare montrent que réduire le nombre de composants ne conduit pas automatiquement à de meilleures décisions.

Cloudflare Clef-omni transforme quatre types d’entrée en une décision

Cloudflare Clef-omni est conçu pour évaluer directement des médias mixtes, sans convertir au préalable chaque entrée en texte.

Le modèle accepte du texte, des images, de l’audio WAV ou MP3, ainsi que de la vidéo MP4 ou WebM. Une requête peut associer plusieurs de ces entrées à un schéma décrivant les questions auxquelles le modèle doit répondre. La réponse attribue un niveau de confiance aux options autorisées plutôt que de composer une réponse narrative.

Cloudflare illustre ce modèle avec une inspection d’équipement. Un développeur peut envoyer une photographie d’étiquette, un enregistrement audio d’une machine et une vidéo de son ventilateur. Le modèle peut alors déterminer si l’étiquette est visible, si la machine semble fonctionner normalement et si le ventilateur tourne.

Ce flux de travail nécessite habituellement plusieurs étapes. Un modèle transcrit l’audio, un autre échantillonne ou sous-titre la vidéo, puis le code de l’application relie ces sorties. Un classificateur final ou un modèle de langage convertit ensuite les éléments de preuve accumulés en décision.

Clef-omni associe au contraire les médias dans une séquence unifiée. Cloudflare affirme que l’audio synchronisé et les images vidéo restent disponibles pour un traitement conjoint. Le modèle évalue chaque réponse valide à partir de cette représentation combinée, sans générer de transcription ni de légende intermédiaire.

Il s’agit d’une différence importante pour les signaux qui perdent leur contexte lors de la conversion. Une transcription peut préserver les mots prononcés tout en écartant le ton, le bruit ambiant, le rythme et la relation entre le son et le mouvement. Un ensemble de légendes vidéo peut décrire des objets visibles tout en manquant le fait qu’un son s’est produit au même moment qu’une panne mécanique.

Cloudflare a construit le modèle sur Qwen3-Omni-30B-A3B-Instruct, une base de type mixture-of-experts. Un modèle mixture-of-experts oriente différentes entrées vers des groupes de paramètres sélectionnés, plutôt que d’activer l’ensemble du réseau à chaque calcul. Cloudflare a conservé la structure de compréhension du modèle de base, mais a supprimé ses composants de sortie de synthèse vocale.

L’entreprise a ensuite gelé la structure Qwen3 et entraîné des adaptateurs de bas rang, ou modules LoRA. LoRA met à jour un ensemble plus restreint de paramètres ajoutés tout en laissant inchangée la majeure partie du modèle de base. Cloudflare a également appliqué un entraînement par entropie croisée avec lissage des étiquettes et un étalonnage par score de Brier, qui mesure à quel point les probabilités prédites correspondent aux résultats observés.

Ses poids de modèle ouverts permettent aux chercheurs d’inspecter ou d’auto-héberger le modèle. La documentation du modèle hébergé fournit la structure des requêtes pour Workers AI.

Cette architecture fait du modèle multimodal Clef davantage qu’un chatbot capable de traiter des médias. C’est un système de notation lié à un schéma, conçu pour des applications qui savent déjà à quelles questions elles doivent répondre. Cette orientation crée aussi sa limite centrale : le système ne peut prendre des décisions utiles que si le schéma, les éléments de preuve et les choix autorisés reflètent le problème réel.

Le modèle multimodal Clef cible la complexité des pipelines

Cloudflare rivalise avec le coût et la fragilité des pipelines de modèles connectés, et pas seulement avec un autre fournisseur de modèles.

Un flux de travail multimédia à plusieurs étapes crée des dépendances opérationnelles. La reconnaissance vocale peut échouer face aux accents ou aux enregistrements bruyants. L’échantillonnage vidéo peut ignorer une image pertinente. Un modèle de génération de légendes peut omettre un détail qui s’avère ensuite important. Le système de décision final ne voit que les sorties transformées, y compris chaque erreur introduite en amont.

Chaque étape possède aussi sa propre latence, sa propre observabilité, son comportement de mise à l’échelle et sa propre réponse aux défaillances. Les développeurs doivent décider s’ils réessaient une transcription ayant échoué, s’ils poursuivent avec des éléments de preuve partiels ou s’ils interrompent toute la requête. Ils doivent préserver les liens entre les horodatages, les images vidéo et le texte dérivé si la décision finale dépend du timing.

Le traitement direct de Clef-omni réduit ces transferts. Cloudflare indique que le modèle hébergé prend des décisions portant uniquement sur du texte avec une latence médiane d’environ 130 millisecondes. Les requêtes d’images prennent environ 150 millisecondes, tandis que les entrées audio nécessitent plusieurs centaines de millisecondes.

Dans l’exemple de l’entreprise, une vidéo de 21 secondes comportant du son reçoit un score en environ 1,5 seconde. Il s’agit de mesures de Cloudflare, et non de garanties indépendantes. La latence réelle dépendra de la taille de la charge utile, de la distance réseau, de la concurrence et de la manière dont une application structure ses questions.

Le bénéfice potentiel reste clair. Une plateforme de support pourrait évaluer dans une seule requête la description écrite d’un client, la photographie d’un produit et un enregistrement vocal. Un flux de sécurité pourrait combiner une capture d’écran, une narration orale et des données d’incident structurées. Une application de contrôle qualité pourrait comparer un mouvement visible à un bruit mécanique.

Le format de sortie compte autant que le format d’entrée. Les modèles Clef produisent des probabilités contraintes par un schéma, de sorte qu’une application peut exploiter la réponse sans analyser une prose conversationnelle. Un système de modération peut demander une catégorie autorisée, tandis qu’un système de routage peut évaluer plusieurs destinations.

Cela n’élimine pas la logique applicative. Les équipes ont toujours besoin de seuils de confiance, de règles d’escalade, de journaux d’audit et d’une révision humaine pour les cas à fortes conséquences. Elles ont aussi besoin d’une politique pour les résultats incertains, car une distribution de probabilités ne garantit pas l’exactitude.

Ce changement se comprend mieux comme une consolidation. Au lieu de maintenir des étapes distinctes de perception et de classification, les développeurs peuvent vérifier si un seul endpoint couvre une part suffisante du flux de travail. Cela peut réduire le travail d’infrastructure même lorsque le modèle n’est pas le plus performant dans chaque évaluation.

Le même principe s’applique aux flux de travail impliquant des informations personnelles. Un système qui combine des réunions, des documents et des médias capturés a toujours besoin d’une récupération fiable et d’une bonne gestion du contexte. Les outils fondés sur le knowledge blending illustrent la demande plus large de connexion entre des informations hétérogènes sans contraindre les utilisateurs à reconstruire manuellement le contexte.

Cloudflare parie que les développeurs souhaitent une consolidation comparable au sein des parcours de décision automatisée. Si le modèle multimodal Clef préserve des éléments de preuve utiles entre les médias, une architecture plus simple devient un avantage concurrentiel. S’il manque des signaux propres à un domaine, les équipes reviendront vers des composants spécialisés malgré la complexité supplémentaire.

Une inférence Clef plus rapide change l’équation du déploiement

La mise à jour de Clef relève en partie de l’infrastructure de service, l’accélération médiane maximale rapportée atteignant 2,0x.

Cloudflare n’a pas publié de nouveaux poids pour la version plus rapide de son modèle Clef initial. L’entreprise affirme que les améliorations proviennent principalement de sa couche de service hébergée. Cela signifie que les utilisateurs qui auto-hébergent le modèle ne bénéficient pas automatiquement des mêmes gains en téléchargeant à nouveau le modèle existant.

Pour des entrées proches de 800 tokens, Cloudflare indique que la latence médiane est passée de 262 millisecondes à 152 millisecondes. La latence au 95e percentile est passée de 438 millisecondes à 351 millisecondes. Cela représente une amélioration de 1,7x à la médiane.

À environ 3 400 tokens, la latence médiane serait passée de 616 millisecondes à 305 millisecondes. Le 95e percentile est passé de 777 millisecondes à 531 millisecondes. C’est pour cette charge de travail que Cloudflare rapporte son accélération médiane maximale de 2,0x.

Pour des entrées proches de 16 000 tokens, l’entreprise indique une réduction médiane de 2 721 millisecondes à 1 635 millisecondes. Son chiffre au 95e percentile est passé de 3 250 millisecondes à 1 805 millisecondes. L’amélioration médiane à cette taille est de 1,7x.

Ces mesures comptent, car les modèles de décision s’insèrent souvent dans une autre opération. Une décision de routage peut intervenir avant qu’un agent ne choisisse un outil. Un score de sécurité peut bloquer une publication. Une classification de sécurité peut déterminer si un événement reçoit une attention immédiate.

La latence s’accumule dans ces positions. Une application qui appelle le modèle de manière répétée dans une boucle d’agent peut transformer quelques centaines de millisecondes en délai perceptible. La latence en queue de distribution compte également, car les utilisateurs ressentent les requêtes lentes, pas seulement la requête médiane.

Cloudflare attribue une partie de l’amélioration de la vitesse d’inférence de Clef à son passage à SGLang, un framework de service open source pour les modèles de langage et multimodaux. Cloudflare a collaboré avec le projet pour ajouter la prise en charge de Clef via une contribution SGLang intégrée en amont.

Cette coopération compte au-delà du service hébergé. Elle offre aux utilisateurs d’auto-hébergement une voie de service prise en charge, même si leurs résultats varieront selon le matériel et la configuration. Elle suggère aussi que les performances d’un modèle ne peuvent pas être évaluées indépendamment du logiciel d’inférence.

Le modèle hébergé plus rapide renforce l’argument de plateforme de Cloudflare. Les développeurs utilisant Workers AI peuvent associer l’exécution de modèles, le code applicatif et les contrôles AI Gateway chez le même fournisseur. Une latence plus faible réduit le coût d’insertion d’une étape de décision dans un Worker existant.

Cependant, l’optimisation de l’infrastructure n’améliore pas le jugement du modèle. Une mauvaise réponse renvoyée deux fois plus vite reste une mauvaise réponse. Les développeurs devraient donc distinguer deux questions d’évaluation : si Clef répond à leurs besoins de précision et d’étalonnage, et si la couche de service de Cloudflare atteint leur objectif de latence.

Cette distinction évite que les accélérations mises en avant ne masquent le risque applicatif. Un modèle de modération rapide peut traiter davantage de contenu, mais aussi amplifier les faux positifs. Un modèle de routage rapide peut accélérer les agents, mais de mauvaises estimations de confiance peuvent diriger davantage de requêtes vers les mauvais outils.

Un Clef-flash moins cher s’accompagne d’un contexte hébergé plus réduit

Cloudflare a réduit le coût de Clef-flash en acceptant un compromis produit visible : sa fenêtre de contexte hébergée est désormais nettement plus courte.

L’entreprise affirme que Clef-flash est désormais moins cher que Jev, son point de comparaison le plus direct parmi les modèles de décision. Les chiffres commerciaux exacts peuvent évoluer ; les acheteurs devraient donc consulter la documentation actuelle plutôt que de considérer une annonce de lancement comme une grille tarifaire permanente.

Le fait le plus durable est la réduction du contexte. Clef-flash hébergé annonçait auparavant une fenêtre de 64 000 tokens. Il accepte désormais jusqu’à 24 000 tokens via Workers AI.

Cloudflare indique que seulement 0,24 % des requêtes Clef-flash observées dépassaient la nouvelle limite. Sur la base de cet usage, l’entreprise a choisi d’abaisser le plafond hébergé et de réduire le coût du service. Le modèle Clef plus grand conserve son contexte hébergé de 64 000 tokens.

Les poids Clef-flash téléchargeables restent inchangés. Cloudflare indique que ces poids ont été entraînés pour prendre en charge un contexte de 256 000 tokens en auto-hébergement. Cela crée une différence nette entre la capacité théorique du modèle et la limite configurée du produit managé.

Pour de nombreuses tâches de classification, 24 000 tokens restent suffisants. Un ticket client, un extrait de politique, un résumé d’incident ou une courte trace d’agent peuvent y tenir sans difficulté. Les équipes qui traitent de longs documents, des traces étendues ou de vastes ensembles d’éléments probants doivent toutefois composer avec cette nouvelle limite.

Elles peuvent tronquer l’entrée, la résumer, ne récupérer que les passages pertinents, utiliser le service Clef plus vaste ou auto-héberger Clef-flash. Chaque option modifie le système. La troncature risque de supprimer des éléments décisifs, tandis que la synthèse peut introduire un autre modèle et une autre source d’erreur.

La récupération peut maîtriser la taille des entrées, mais le résultat dépend alors de ce que la couche de récupération sélectionne. L’auto-hébergement préserve davantage de contexte, tout en ajoutant la planification de capacité, les mises à jour, le travail de sécurité et l’ingénierie d’inférence.

C’est pourquoi l’histoire du Clef-flash moins cher ne se résume pas à une baisse de prix. Cloudflare optimise pour l’écrasante majorité des requêtes qu’elle observe actuellement. Les clients ayant des entrées inhabituellement longues en supportent le coût par la migration ou des changements d’architecture.

Cette décision clarifie aussi le positionnement de la famille. Clef-flash cible des décisions fréquentes et sensibles à la latence, avec un contexte relativement borné. Clef complet traite les cas plus volumineux ou plus exigeants. Clef-omni s’adresse aux flux de travail où l’information décisive traverse le texte, l’audio, les images et la vidéo.

Un modèle de routage par niveaux en découle naturellement. Une application peut commencer avec Clef-flash et faire remonter les cas longs ou incertains vers un autre modèle. Ce modèle exige toutefois un calibrage attentif. Un seuil de confiance qui paraît raisonnable sur un benchmark générique peut se comporter différemment avec les propres données d’une entreprise.

Les développeurs devraient tester les limites de contexte avec des exemples de production complets, et non avec la longueur moyenne des entrées. La rare requête qui dépasse 24 000 tokens peut aussi être la requête complexe pour laquelle un contexte manquant cause le plus de dommages.

Cloudflare Clef-omni reste confronté à un test de précision

Les résultats publiés par Cloudflare montrent un modèle capable, mais pas un vainqueur universel pour l’ensemble des tâches ou modalités.

Sur l’ensemble de benchmarks de Cloudflare, Clef-omni obtient de solides résultats dans plusieurs évaluations orientées texte. Il atteint 98,2 en correspondance exacte de cas BFCL et 97,7 de macro-F1 sur CLINC150 avec des exemples hors périmètre. Il affiche également 94,8 de macro-F1 sur BANKING77.

Cependant, le modèle est devancé par un autre membre de la famille Clef dans plusieurs tests. Clef complet obtient de meilleurs scores sur ToolRet, les décisions relatives aux appareils électroménagers, When2Call, BRIGHT et PhishNChips. Clef-flash domine sur BFCL, API-Bank et l’évaluation des appareils électroménagers.

Jev conserve également des avantages. Le tableau de Cloudflare montre Jev en tête sur When2Call et BRIGHT. Ces résultats plaident contre l’idée qu’une plus grande étendue des entrées implique automatiquement une supériorité.

Le même tableau contrasté apparaît dans les évaluations de flux de travail. Dans les évaluations de modèles de décision publiées, Clef-omni est derrière Clef complet pour le traitement des factures. Il est également derrière Clef-flash pour les actions exactes de service client et les actions principales de traces d’agent.

Pour les incidents de sécurité, Clef-omni égale Clef-flash et Jev sur les actions exactes tout en restant sous Clef complet. Ces différences comptent, car les flux de travail métier combinent généralement plusieurs choix corrects. Un modèle peut sélectionner correctement l’action principale tout en manquant une action secondaire qui affecte la conformité ou le suivi.

Les benchmarks fournissent également peu d’éléments concernant les nouvelles modalités. Nombre des évaluations répertoriées se concentrent sur la classification de texte, la récupération, l’utilisation d’outils ou les flux de travail structurés. Elles n’établissent pas avec quelle fiabilité Clef-omni raisonne à travers la parole, les sons, les mouvements et les images synchronisés dans des environnements de production variés.

Cloudflare indique une latence multimodale, mais le matériel de lancement ne fournit pas de ventilation publique tout aussi détaillée de la précision audio et vidéo. Des questions subsistent concernant les enregistrements bruyants, les intervenants multiples, les mouvements de caméra, la vidéo compressée, les sons qui se chevauchent et les éléments probants contradictoires selon les modalités.

Cette lacune de vérification devrait orienter l’adoption. Une équipe évaluant des inspections d’usine devrait créer des exemples comprenant des sons normaux et anormaux dans des conditions réalistes de bruit de fond. Une organisation de support devrait tester des accents variés, des microphones d’appareils différents et des enregistrements clients incomplets.

Les équipes de sécurité devraient mesurer séparément les faux positifs et les faux négatifs. Un score de précision unique peut masquer un système performant simplement parce qu’il favorise la classe la plus fréquente. Le calibrage mérite aussi d’être testé, car l’automatisation en aval dépend souvent de la correspondance entre les valeurs de confiance et les taux d’erreur réels.

Le calendrier de développement rapide de Cloudflare accroît le besoin d’une évaluation indépendante. L’entreprise affirme que l’effort Clef initial est passé d’une décision interne à un lancement en moins d’une semaine. La vitesse d’itération est impressionnante, mais elle ne remplace pas des tests externes étendus.

Les poids ouverts sont utiles. Les chercheurs peuvent reproduire les tests, examiner le comportement et comparer les résultats auto-hébergés avec Workers AI. Pourtant, la disponibilité ouverte ne rend pas un benchmark neutre. Les chiffres rapportés passent toujours par la sélection de Cloudflare en matière de modèles, de prompts, d’infrastructure et de métriques.

La conclusion la plus défendable est plus limitée que le cadrage du lancement. Cloudflare Clef-omni propose une architecture crédible à appel unique pour les décisions multimodales. Son amélioration d’un flux de travail réel dépend d’éléments propres au domaine que les benchmarks de lancement ne fournissent pas encore.

Ce que les développeurs devraient surveiller ensuite

La prochaine phase sera déterminée par des tests multimodaux indépendants, l’adoption en production et les réponses concurrentielles plutôt que par des listes de fonctionnalités.

Le premier signal concerne la couverture des évaluations. Les développeurs devraient rechercher des tests publics exigeant des preuves provenant simultanément de l’audio et de la vidéo, en particulier lorsque ces signaux divergent. Un benchmark utile testerait si le modèle remarque qu’une machine visible fonctionne normalement alors que son audio révèle une panne intermittente.

De tels résultats renforceraient l’affirmation de Cloudflare selon laquelle un pipeline unifié préserve des informations perdues par la transcription et le sous-titrage. De faibles résultats suggéreraient que l’ingestion native est pratique, mais pas nécessairement plus précise que des composants spécialisés.

Le deuxième signal est le comportement en production. Cloudflare décrit déjà des déploiements internes de Clef destinés à clôturer des problèmes de spam, modérer des bibliothèques de plugins contre le phishing, identifier d’éventuelles informations personnelles et détecter des domaines malveillants. Ces exemples impliquent des classifications conséquentes, mais ils établissent surtout l’usage plutôt qu’une fiabilité mesurée.

Les développeurs ont besoin de taux d’erreur, de résultats de calibrage, de schémas d’escalade et de latence de queue sous trafic soutenu. Ils devraient également observer si les équipes adoptent Clef-omni pour des décisions réellement multimodales ou l’utilisent principalement comme un autre évaluateur de texte et d’images.

Le troisième signal est la réponse des concurrents. Jev demeure la comparaison directe la plus évidente, car Clef prend en charge sa forme d’API et Cloudflare l’évalue à plusieurs reprises. La compatibilité réduit les frictions de changement, de sorte que TypeSafe doit défendre sa position par la précision, l’économie, la latence ou des outils spécialisés.

Les fournisseurs de modèles multimodaux généralistes comptent également, même s’ils ne présentent pas leurs systèmes comme des modèles de décision. La sortie structurée, le décodage contraint et les endpoints de classification dédiés peuvent réduire les différences opérationnelles. Les systèmes audio et de vision spécialisés resteront attrayants lorsque la précision dans un domaine l’emporte sur la simplicité du pipeline.

Pour les développeurs, l’étape pratique suivante consiste en une évaluation contrôlée à partir d’exemples réels. Comparez le modèle unifié au pipeline existant, puis mesurez la précision des actions complètes, le calibrage, la latence et la gestion des défaillances. Incluez des entrées longues rares et des médias de faible qualité, car les moyennes masquent souvent les cas qui déterminent le risque opérationnel.

Ne commencez pas par demander si le modèle comprend quatre modalités. Demandez s’il prend la bonne décision bornée à partir de ces modalités, avec un taux d’erreur acceptable. Testez ensuite ce qui se passe lorsqu’il est incertain, reçoit des éléments contradictoires ou dépasse la limite de contexte hébergée.

Cloudflare a facilité l’exécution de l’expérience. L’entreprise n’a pas supprimé la nécessité de la mener. La valeur de Cloudflare Clef-omni dépendra au final de la capacité d’une architecture plus simple à résister au contact de données de production désordonnées, et non de la capacité technique d’un endpoint à accepter tous les types de fichiers.