El sistema pretende asignar cada solicitud al modelo aprobado más asequible que pueda cumplir los requisitos de la tarea. Las consultas repetitivas o de baja complejidad podrían enviarse a modelos abiertos eficientes, mientras que los trabajos que necesiten un razonamiento más profundo podrían utilizar modelos frontera de proveedores como Anthropic, OpenAI y Google.
La automatización no será obligatoria. Los administradores podrán fijar un modelo concreto o reducir la lista de modelos elegibles cuando necesiten un comportamiento más predecible o un control más estricto sobre una carga de trabajo.
Snowflake también afirma que el enrutamiento puede respetar las reglas de residencia de datos y las políticas de gobernanza, además de registrar qué modelo se seleccionó para cada solicitud. Esto convierte la función en algo más que una herramienta para recortar la factura: también puede formar parte de un proceso auditable de selección de modelos.
Snowflake ha descrito dos mecanismos principales.
En el llamado patrón asesor, un modelo pequeño intenta resolver primero la tarea. Si no puede completarla adecuadamente, invoca a un modelo más potente como herramienta y continúa el proceso. La idea es evitar el coste de un modelo frontera cuando no hace falta, pero conservar una vía de escalado para los casos difíciles.
Un clasificador independiente puede analizar patrones de consultas históricas para reconocer solicitudes sencillas y enviarlas directamente a modelos más básicos. Así, el sistema tendría dos caminos: comenzar con un modelo pequeño y escalar si es necesario, o clasificar la solicitud antes de elegir el modelo.
La cuestión clave será comprobar si estos mecanismos mejoran el resultado completo de la tarea. Una primera respuesta fallida, una escalada, una llamada adicional o un reintento pueden aumentar los tokens consumidos, la latencia y la complejidad técnica.
Snowflake asegura que obtuvo hasta tres veces más eficiencia en el uso de tokens en una carga de trabajo interna relacionada con la creación de canalizaciones de dbt, manteniendo una calidad comparable a la de utilizar únicamente modelos frontera. En otra prueba de programación, la empresa afirmó que los equipos de ingeniería conservaron el ritmo de pull requests utilizando aproximadamente un 25 % menos de tokens.
Son cifras comunicadas por Snowflake a partir de evaluaciones internas, no resultados de clientes validados de forma independiente. Además, pueden cambiar mucho según el tipo de trabajo. Un sistema que funcione bien con tareas repetitivas de ingeniería de datos o programación podría comportarse de otra manera con investigaciones de contexto largo, uso complejo de herramientas o decisiones de alto riesgo.
Por eso, el indicador más útil no es simplemente el número de tokens ahorrados. Las empresas deberían medir el coste de una tarea completada y aceptada junto con su calidad, latencia, fiabilidad y necesidad de revisión humana.
Snowflake ampliará el conjunto de modelos disponibles en Cortex AI con DeepSeek-V4-Flash 0731 y GLM-5.3, de Z.ai. DeepSeek-V4-Flash 0731 se ha anunciado para una vista previa privada, también en CoCo. GLM-5.3 llegará próximamente a esa fase, sujeto a disponibilidad.
La compañía informó de que DeepSeek-V4-Flash obtuvo un 74,4 % en ADE-bench durante una prueba interna en la que CoCo actuó como entorno del agente. También citó una evaluación anterior de GLM-5.2, no de GLM-5.3, con una puntuación comunicada del 66 % y el menor consumo de tokens del benchmark. Ese resultado de GLM-5.2 no debe interpretarse como una evaluación publicada de GLM-5.3.
Una cartera más amplia de modelos refuerza la lógica del enrutamiento: cuantas más alternativas haya, más posibilidades existen de emparejar las necesidades de una tarea con una combinación adecuada de coste y rendimiento. También ofrece a los clientes opciones adicionales frente a los proveedores de modelos frontera más conocidos.
La principal diferencia que reivindica Snowflake es que el acceso a los modelos y las decisiones de enrutamiento quedan vinculados a su entorno de datos gobernados. La empresa afirma que sirve directamente los nuevos modelos abiertos, en lugar de limitarse a actuar como proxy de una API externa, y que los datos, la computación de inferencia, los pesos de los modelos y la orquestación de agentes operan dentro de su perímetro de seguridad. También señala sus controles de acceso basados en roles y sus mecanismos de auditoría.
Esto es una afirmación arquitectónica de Snowflake, no una garantía universal para cualquier despliegue. Cada organización tendrá que comprobar aspectos como la región de operación, los requisitos de residencia de datos, las condiciones contractuales, el comportamiento de los registros y los modelos realmente disponibles para cada carga de trabajo.
El argumento resulta especialmente atractivo para las empresas que ya gestionan sus datos analíticos y sus aplicaciones de IA en Snowflake. En ese caso, el beneficio no sería únicamente elegir un modelo más barato: la selección podría integrarse en el mismo marco de control y auditoría utilizado para gestionar el acceso a los datos.
El enrutamiento de modelos no es exclusivo de Snowflake. Amazon Bedrock, por ejemplo, ofrece Intelligent Prompt Routing, un endpoint sin servidor que distribuye solicitudes entre modelos fundacionales de una misma familia según la calidad de respuesta prevista y el coste.
Databricks, por su parte, presenta Unity AI Gateway como un plano de control central para dirigir solicitudes hacia modelos y servicios MCP, con gestión de capacidad, disponibilidad y gasto entre proveedores.
La comparación más relevante no es quién puede enviar una solicitud a un modelo más barato, sino dónde se administran la gobernanza, los datos, las políticas de enrutamiento, la ejecución y la atribución de costes. Snowflake destaca la integración con su frontera de datos gobernados; los gateways más neutrales suelen priorizar la portabilidad entre proveedores y nubes.
Para una empresa, la decisión dependerá de su arquitectura:
Una evaluación seria debería comparar el enrutamiento automático con una referencia basada en un modelo frontera fijo y utilizar cargas de trabajo representativas de producción. Conviene medir, como mínimo:
Snowflake afirma que no cobra por separado la decisión de enrutamiento y que factura el consumo de tokens. Aun así, las escaladas y los reintentos pueden elevar el uso total y la latencia. El criterio correcto es si el sistema reduce el coste de un resultado completado y aceptado sin deteriorar la calidad ni incumplir los requisitos de gobernanza de la aplicación.
El anuncio combina dos movimientos: la selección dinámica entre modelos aprobados y la ampliación del catálogo disponible dentro de Cortex AI. El enrutamiento dinámico se espera próximamente en vista previa privada; DeepSeek-V4-Flash 0731 ya ha sido anunciado para esa fase, mientras que GLM-5.3 llegará más adelante, sujeto a disponibilidad.
La apuesta estratégica de Snowflake no consiste únicamente en enviar las consultas fáciles a modelos baratos. Su objetivo es que esa decisión se tome dentro de la misma frontera de datos y seguridad que ya gobierna otros activos empresariales. El dato de hasta tres veces más eficiencia en tokens resulta prometedor, pero cada cliente deberá probarlo con sus propias cargas de trabajo y juzgar el éxito por el coste total, la calidad, la latencia, la fiabilidad y las correcciones humanas, no por la reducción de tokens aislada.