Snowflake Dynamic Model Routing: come Cortex AI Gateway sceglie il modello più adatto

Il router dovrebbe selezionare il modello approvato più economico che, secondo il sistema, può completare con sufficiente affidabilità il compito richiesto. Le richieste ripetitive o poco complesse possono essere affidate a modelli open più efficienti; le attività che richiedono maggiore capacità di ragionamento possono essere indirizzate verso modelli frontier di fornitori come Anthropic, OpenAI e Google. Chi preferisce mantenere un controllo manuale può bloccare un modello specifico o ridurre l’elenco dei modelli disponibili.

Snowflake afferma inoltre che il routing può rispettare i requisiti di localizzazione dei dati e le policy di governance, registrando il modello scelto per ogni richiesta. In questo modo, la funzione non riguarda soltanto la gestione dei costi, ma anche la possibilità di sottoporre la selezione del modello a controlli e verifiche.

Come dovrebbe funzionare il routing

Snowflake ha descritto due meccanismi principali per determinare quanta capacità di modello serva a una determinata attività.

Il modello “advisor”

Nel cosiddetto advisor pattern, un modello più piccolo prova innanzitutto a svolgere il compito. Se non riesce a completarlo in modo adeguato, può chiamare un modello più grande come strumento e proseguire il lavoro.

L’approccio mira a evitare il costo dei modelli frontier per le richieste che un modello compatto è in grado di gestire, mantenendo però una via di escalation per i casi più difficili.

Il routing basato su classificatore

Un classificatore separato può usare i modelli ricavati dalle richieste storiche per riconoscere le attività più semplici e indirizzarle verso modelli meno costosi. In pratica, il sistema offre due percorsi: può partire da un modello piccolo e aumentare la capacità quando necessario, oppure classificare la richiesta prima di scegliere il modello.

Il punto operativo più importante è capire se questi meccanismi migliorano il risultato complessivo, non soltanto se selezionano un modello dal prezzo inferiore. Un primo tentativo fallito, un’escalation o un nuovo tentativo possono infatti aggiungere token, latenza e complessità tecnica.

I risultati di efficienza dichiarati da Snowflake

Snowflake riferisce fino a 3 volte maggiore efficienza nell’uso dei token in un test interno su un carico di lavoro dedicato alla costruzione di pipeline dbt, a fronte di una qualità comparabile rispetto all’utilizzo esclusivo di modelli frontier. In un test separato su attività di programmazione, la società afferma che i team di sviluppo hanno mantenuto il volume di pull request utilizzando circa il 25% di token in meno.

Sono risultati dichiarati dall’azienda e ottenuti in valutazioni interne, non risultati indipendentemente verificati presso clienti. Inoltre, possono cambiare sensibilmente in base al tipo di attività. Un router efficace su compiti ripetitivi di data engineering o programmazione potrebbe comportarsi diversamente con ricerche a contesto lungo, uso complesso di strumenti o decisioni ad alto rischio.

Per questo, il parametro più utile non è il numero di “token risparmiati” preso isolatamente. La metrica da osservare è il costo di un’attività completata e accettata, insieme a qualità, latenza, affidabilità e lavoro umano di revisione.

I nuovi modelli: DeepSeek e GLM

Snowflake sta ampliando il gruppo di modelli disponibili attraverso Cortex AI con DeepSeek-V4-Flash 0731 e GLM-5.3 di Z.ai. DeepSeek-V4-Flash 0731 è stato annunciato per l’anteprima privata, anche all’interno di CoCo. GLM-5.3 dovrebbe arrivare presto in anteprima privata, in base alla sua disponibilità.

Snowflake riferisce che DeepSeek-V4-Flash ha ottenuto un punteggio del 74,4% su ADE-bench in un test interno condotto usando CoCo come ambiente per l’agente. La società cita inoltre un test precedente di GLM-5.2, non di GLM-5.3, con un risultato dichiarato del 66% e il minor consumo di token nel benchmark. Il dato relativo a GLM-5.2 non deve quindi essere interpretato come una valutazione pubblicata di GLM-5.3.

Un catalogo più ampio di modelli open rafforza la logica del routing: più opzioni significano maggiori possibilità di abbinare ogni compito al giusto equilibrio tra capacità, prestazioni e costo. Per i clienti, significa anche poter scegliere tra più alternative rispetto ai principali fornitori di modelli frontier.

Il tema del perimetro dei dati governati

La principale differenziazione rivendicata da Snowflake è il collegamento tra routing, accesso ai modelli e ambiente di dati già sottoposto a governance. L’azienda afferma di servire direttamente i nuovi modelli open, invece di limitarsi a fare da proxy per API di terze parti, e sostiene che dati, calcolo per l’inferenza, pesi dei modelli e orchestrazione degli agenti operino all’interno del perimetro di sicurezza di Snowflake. Richiama inoltre i controlli di accesso basati sui ruoli e i meccanismi di audit già esistenti.

Si tratta di un’asserzione architetturale di Snowflake, non di una garanzia universale valida per ogni configurazione. Prima di adottare la funzione, le aziende dovranno verificare elementi come regione di distribuzione, requisiti di residenza dei dati, condizioni contrattuali, comportamento dei log e modelli effettivamente autorizzati per ciascun carico di lavoro.

Il vantaggio potenziale è maggiore per le organizzazioni che già gestiscono in Snowflake dati analitici governati e applicazioni di IA. In questo scenario, il valore non consiste soltanto nel trovare un modello più economico: la scelta del modello può diventare parte dello stesso sistema di controllo e audit usato per l’accesso ai dati.

Come si colloca rispetto alle alternative

Il routing dei modelli non è un’esclusiva di Snowflake. Amazon Bedrock, per esempio, offre l’intelligent prompt routing attraverso un endpoint serverless che distribuisce le richieste tra modelli fondazionali appartenenti alla stessa famiglia, sulla base della qualità prevista della risposta e del costo.

Il confronto più significativo riguarda quindi il luogo in cui vengono gestiti governance, policy di routing, accesso ai dati, esecuzione dei modelli e visibilità sulla fatturazione. Snowflake insiste su un perimetro strettamente integrato con i dati governati. Altri gateway possono puntare maggiormente sulla scelta tra fornitori, sulla gestione del traffico, sul failover o sulla portabilità.

Per chi deve acquistare o adottare una soluzione, la decisione dipende soprattutto dall’ambiente operativo:

• Un approccio integrato è più adatto quando dati governati, controlli di accesso, orchestrazione degli agenti e utilizzo dei modelli ruotano già attorno a un’unica piattaforma dati.
• Un gateway più neutrale può essere preferibile quando contano di più la portabilità tra fornitori, una logica di routing indipendente o la flessibilità multi-cloud.
• Il catalogo dei modelli va verificato: non tutti i gateway possono instradare le richieste verso gli stessi fornitori, famiglie di modelli, regioni o modalità di distribuzione.

Che cosa misurare prima di dare per acquisiti i risparmi

La valutazione dovrebbe confrontare il routing automatico con una configurazione di riferimento basata su un singolo modello frontier, usando carichi di lavoro rappresentativi della produzione. Tra gli indicatori da monitorare:

• costo totale per attività completata con successo, non soltanto prezzo dei token del modello selezionato;
• eventuali costi del router o del classificatore;
• chiamate aggiuntive dovute a escalation, fallback, retry o errori nell’esecuzione degli strumenti;
• latenza end-to-end, inclusi routing, recupero dei dati, assemblaggio del contesto e chiamate successive;
• tasso di successo e qualità per categoria di attività;
• allucinazioni, violazioni delle policy e regressioni introdotte dai modelli più piccoli;
• costi di revisione, correzione, escalation e rilavorazione da parte delle persone;
• vincoli relativi a residenza dei dati, osservabilità, trasferimento dei dati e dipendenza dal fornitore.

Snowflake afferma di non applicare un costo separato per la decisione di routing e di fatturare invece il consumo dei token. Anche così, escalation e retry possono aumentare il consumo complessivo e la latenza. Il criterio corretto è quindi capire se il routing riduce il costo di un risultato accettato mantenendo i requisiti di qualità e governance dell’applicazione.

In sintesi

L’annuncio di Snowflake combina due iniziative: la selezione dinamica tra modelli approvati e l’ampliamento del catalogo disponibile all’interno di Cortex AI. La funzione di routing è attesa presto in anteprima privata; DeepSeek-V4-Flash 0731 è già stato annunciato per l’anteprima privata, mentre GLM-5.3 arriverà successivamente, in base alla disponibilità.

La vera ambizione strategica non è semplicemente inviare le richieste facili a modelli più economici. È portare quella decisione dentro il perimetro di dati, sicurezza e governance di Snowflake. Il dato dichiarato di un’efficienza fino a 3 volte superiore è interessante, ma ogni azienda dovrebbe testare la funzione sui propri carichi di lavoro e giudicarla in base a costo complessivo, qualità, latenza, affidabilità e correzioni umane, non alla sola riduzione dei token.