Snowflake mise sur le routage dynamique pour payer chaque tâche d’IA au juste prix

Snowflake veut s’attaquer à un problème très concret pour les entreprises qui déploient des agents d’IA : faut-il vraiment utiliser le modèle le plus puissant pour chaque requête ? Sa réponse prend la forme d’un routage dynamique des modèles dans Cortex AI Gateway, une fonctionnalité annoncée pour un aperçu privé prochain. Il ne s’agit donc pas encore d’une mise à disposition générale.

L’idée est simple : confier les tâches faciles à des modèles moins coûteux et réserver les modèles de pointe aux demandes qui exigent davantage de raisonnement. Snowflake présente cette approche sous le nom d’« efficacité de l’intelligence » (intelligence efficiency) : l’objectif n’est pas seulement de réduire le prix des tokens, mais d’optimiser le coût d’un résultat métier réellement obtenu et accepté.

Ce que Snowflake a annoncé

Le routage dynamique sera proposé via Cortex AI Gateway et intégré aux produits Snowflake CoCo et Snowflake CoWork. Les agents d’IA tiers connectés à la passerelle pourront également utiliser cette capacité. Les clients pourront définir les modèles autorisés ainsi que les compromis à privilégier pour une application ou une charge de travail : coût, qualité ou temps de réponse, par exemple.

Le routeur doit sélectionner le modèle approuvé le plus économique qui est suffisamment sûr de pouvoir accomplir la tâche. Les requêtes répétitives ou peu complexes pourront être envoyées vers des modèles ouverts efficaces, tandis que les travaux nécessitant un raisonnement plus poussé pourront être confiés à des modèles de pointe proposés notamment par Anthropic, OpenAI et Google.

Les équipes conserveront toutefois un contrôle manuel. Elles pourront imposer un modèle précis ou réduire la liste des modèles éligibles au lieu d’activer le routage automatique. Snowflake indique également que le mécanisme peut tenir compte des exigences de résidence des données, des politiques de gouvernance et du suivi du modèle choisi pour chaque requête.

Cette traçabilité donne au projet une portée plus large que la seule réduction de facture : la sélection du modèle peut devenir une décision contrôlée et auditable, au même titre que les accès aux données.

Deux mécanismes pour choisir le bon modèle

Snowflake a décrit deux façons de déterminer le niveau de capacité nécessaire pour une tâche.

Le modèle « advisor »

Dans ce scénario, un petit modèle tente d’abord de traiter la demande. S’il n’y parvient pas correctement, il peut appeler un modèle plus puissant comme outil, puis poursuivre l’exécution. L’objectif est d’éviter de facturer systématiquement le tarif d’un modèle de pointe tout en conservant une voie d’escalade pour les cas plus difficiles.

Le routage par classificateur

Un autre classificateur peut s’appuyer sur les caractéristiques de requêtes historiques pour repérer les demandes simples et les orienter directement vers des modèles plus légers. Le système dispose ainsi de deux chemins : commencer par un petit modèle et augmenter la puissance si nécessaire, ou classer la requête avant de sélectionner le modèle approprié.

Le point crucial, en production, sera de mesurer le résultat complet. Un premier essai insuffisant, une escalade vers un autre modèle ou une nouvelle tentative peuvent ajouter des tokens, de la latence et de la complexité technique. Choisir un modèle moins cher ne garantit donc pas, à lui seul, une opération moins coûteuse.

Des gains d’efficacité annoncés par Snowflake

Dans une évaluation interne portant sur un pipeline dbt, Snowflake affirme avoir obtenu jusqu’à 3 fois plus d’efficacité en tokens, avec une qualité comparable à celle d’une approche utilisant uniquement des modèles de pointe. Dans un autre test consacré au développement logiciel, l’entreprise indique que les équipes ont conservé leur volume de pull requests tout en consommant environ 25 % de tokens en moins.

Ces chiffres restent des résultats internes communiqués par le fournisseur, et non des résultats clients validés indépendamment. Ils peuvent aussi varier fortement selon les usages. Un routeur performant sur des tâches répétitives de data engineering ou de programmation ne produira pas nécessairement les mêmes résultats pour une recherche exploitant un long contexte, un enchaînement complexe d’outils ou une décision à haut risque.

Le bon indicateur n’est donc pas le nombre de tokens économisés pris isolément. Il faut plutôt calculer le coût d’une tâche réussie et acceptée, en le comparant à sa qualité, sa latence, sa fiabilité et au temps de reprise humaine nécessaire.

DeepSeek et GLM élargissent le choix des modèles

Snowflake élargit également le catalogue accessible dans Cortex AI avec DeepSeek-V4-Flash 0731 et GLM-5.3 de Z.ai. DeepSeek-V4-Flash 0731 a été annoncé en aperçu privé, notamment dans CoCo. GLM-5.3 doit arriver prochainement en aperçu privé, sous réserve de disponibilité.

Snowflake indique que DeepSeek-V4-Flash a obtenu 74,4 % à ADE-bench lors d’un test interne mené avec CoCo comme environnement d’agent. L’entreprise cite aussi un test antérieur de GLM-5.2, et non de GLM-5.3, avec un score annoncé de 66 % et la plus faible consommation de tokens sur ce benchmark. Ce résultat de GLM-5.2 ne doit pas être interprété comme une évaluation publiée de GLM-5.3.

L’ajout de modèles ouverts renforce la logique du routage : plus le choix est large, plus il devient possible d’associer une tâche à un compromis adapté entre coût, performances et rapidité. Les entreprises disposent aussi d’alternatives aux fournisseurs de modèles de pointe les plus connus.

L’argument de la frontière de données gouvernée

La principale différence mise en avant par Snowflake concerne l’environnement dans lequel s’effectue le routage. L’entreprise affirme qu’elle sert elle-même les nouveaux modèles ouverts, plutôt que de se limiter à relayer l’API d’un tiers. Selon Snowflake, les données, le calcul d’inférence, les poids des modèles et l’orchestration des agents fonctionnent à l’intérieur de son périmètre de sécurité, avec ses mécanismes existants de contrôle d’accès par rôle et d’audit.

Il s’agit d’une affirmation architecturale de Snowflake, pas d’une garantie universelle valable pour tous les déploiements. Chaque client devra vérifier les détails pertinents pour son environnement : région de déploiement, exigences de résidence des données, clauses contractuelles, comportement des journaux et modèles réellement autorisés pour chaque charge de travail.

L’intérêt sera particulièrement important pour les organisations qui hébergent déjà leurs données analytiques gouvernées et leurs applications d’IA dans Snowflake. Dans ce cas, la promesse ne se limite pas à choisir un modèle moins cher : la décision peut s’inscrire dans le même cadre de contrôle et d’audit que les accès aux données.

Un marché où le routage n’est pas nouveau

Snowflake n’est pas le seul acteur à proposer une forme de routage entre modèles. Amazon Bedrock propose par exemple un routage intelligent des prompts via un point d’accès serverless, capable de répartir les requêtes entre plusieurs modèles fondamentaux d’une même famille selon la qualité de réponse prédite et le coût.

La comparaison pertinente ne consiste donc pas simplement à demander quel produit « sait router ». Il faut regarder où sont gérés la décision de routage, les règles de gouvernance, l’exécution des modèles, l’accès aux données et la visibilité sur la facturation.

Snowflake met l’accent sur une intégration étroite avec les données gouvernées et les contrôles de sa plateforme. D’autres passerelles peuvent privilégier le choix entre fournisseurs, la gestion du trafic, la reprise après incident ou la portabilité. Pour un acheteur, le choix dépendra surtout de l’environnement d’exploitation :

• Une approche intégrée est cohérente lorsque les données gouvernées, les contrôles d’accès, l’orchestration des agents et l’usage des modèles sont déjà centrés sur une même plateforme.
• Une passerelle plus neutre peut être préférable lorsque la portabilité entre fournisseurs, l’indépendance de la logique de routage ou la flexibilité multicloud sont prioritaires.
• Le catalogue doit être vérifié : toutes les passerelles ne permettent pas de router entre les mêmes fournisseurs, familles de modèles, régions ou types de déploiement.

Ce qu’il faut mesurer avant de parler d’économies

Une évaluation sérieuse doit comparer le routage automatique à une référence utilisant systématiquement un modèle de pointe, sur des charges de travail représentatives de la production. Il faut notamment suivre :

• le coût total par tâche réussie, et pas seulement le prix des tokens du modèle sélectionné ;
• les éventuels frais du routeur ou du classificateur ;
• les appels supplémentaires liés à l’escalade, aux solutions de repli, aux nouvelles tentatives ou à l’échec d’un outil ;
• la latence de bout en bout, y compris le routage, la recherche de contexte, l’assemblage des données et les appels de second passage ;
• le taux de réussite et la qualité selon chaque catégorie de tâche ;
• les hallucinations, les violations de politique et les régressions dues aux modèles plus petits ;
• le coût de la vérification humaine, des corrections, des escalades et de la reprise du travail ;
• les contraintes liées à la résidence des données, à l’observabilité, à la sortie des données et à la dépendance au fournisseur.

Snowflake affirme ne pas facturer séparément la décision de routage et facturer plutôt la consommation de tokens. Les escalades et les nouvelles tentatives peuvent néanmoins augmenter la consommation totale et la latence. Le critère d’acceptation devrait donc être le suivant : le routage réduit-il le coût d’un résultat terminé et accepté, tout en respectant les exigences de qualité et de gouvernance ?

En résumé

L’annonce de Snowflake combine deux évolutions : la sélection dynamique d’un modèle approuvé pour chaque tâche et l’élargissement du catalogue disponible dans Cortex AI. La fonctionnalité doit prochainement entrer en aperçu privé ; DeepSeek-V4-Flash 0731 a déjà été annoncé dans ce cadre, tandis que GLM-5.3 suivra sous réserve de disponibilité.

La véritable ambition de Snowflake ne réside pas dans l’idée, désormais largement répandue, de réserver les modèles coûteux aux tâches difficiles. Elle consiste à intégrer cette décision dans une frontière de données gouvernée et dans les contrôles de sécurité de la plateforme. Les gains annoncés sont prometteurs, mais les entreprises devront les vérifier sur leurs propres usages et juger la réussite sur le coût, la qualité, la latence, la fiabilité et le travail humain de correction — pas sur la seule baisse du nombre de tokens.