Snowflake vil kutte AI-kostnader med dynamisk modellruting

Snowflake har annonsert dynamisk modellruting for Cortex AI Gateway – en funksjon som skal velge en godkjent AI-modell for hver enkelt oppgave, i stedet for å sende alle forespørsler til den samme kraftigste modellen. Funksjonen ventes snart i privat forhåndsvisning og er derfor foreløpig en annonsert mulighet, ikke en generelt tilgjengelig produktlansering.

Hovedideen er enkel: Rimeligere og mer effektive modeller kan håndtere oppgaver de mestrer, mens de mest avanserte modellene reserveres for arbeid som krever dypere resonnering. Snowflake omtaler dette som «intelligence efficiency» – å optimalisere kostnaden ved et ferdig levert forretningsresultat, ikke bare prisen per modelltoken.

Hva Snowflake har annonsert

Dynamisk modellruting blir tilgjengelig gjennom Cortex AI Gateway og integreres i Snowflakes produkter CoCo og CoWork. Ifølge selskapet kan også tredjeparts AI-agenter som er koblet til gatewayen, bruke funksjonen. Kundene skal kunne bestemme hvilke modeller som er godkjent, og hvilke avveininger en applikasjon skal prioritere – for eksempel kostnad, kvalitet eller svartid.

Ruteren skal velge den rimeligste modellen som administratoren har godkjent, og som med tilstrekkelig sikkerhet kan fullføre oppgaven. Enkle, repetitive eller lite komplekse forespørsler kan sendes til effektive åpne modeller. Oppgaver som krever mer avansert resonnering, kan i stedet rutes til såkalte frontier-modeller fra leverandører som Anthropic, OpenAI og Google.

Organisasjoner beholder også muligheten til å styre manuelt. De kan låse en applikasjon til én bestemt modell eller begrense hvilke modeller ruteren får velge mellom, fremfor å bruke automatisk ruting.

Snowflake sier videre at rutingen kan ta hensyn til krav om datalagring i bestemte regioner og andre styringsregler. Systemet skal også registrere hvilken modell som ble valgt for hver forespørsel. Det gjør funksjonen relevant ikke bare for kostnadskontroll, men også for virksomheter som trenger en etterprøvbar prosess for modellvalg.

Slik skal rutingen fungere

Snowflake har beskrevet to mekanismer for å avgjøre hvor mye modellkapasitet en oppgave trenger.

«Advisor pattern»

I denne modellen forsøker en mindre modell å løse oppgaven først. Hvis den ikke klarer det på en tilfredsstillende måte, kan den hente inn en større modell som et verktøy og fortsette arbeidet derfra.

Målet er å unngå frontier-priser når en mindre modell er god nok, samtidig som systemet beholder en vei videre for vanskeligere oppgaver.

Klassifiseringsbasert ruting

En separat klassifikator kan bruke mønstre fra tidligere forespørsler til å identifisere enkle oppgaver og sende dem til mindre modeller. Dermed får systemet to mulige arbeidsmåter: Det kan enten starte med en liten modell og eskalere ved behov, eller klassifisere forespørselen før det velger modell.

Det avgjørende spørsmålet i praksis er likevel ikke bare om ruteren velger en billigere modell. Et mislykket første forsøk, en eskalering eller en ny forespørsel kan øke både tokenbruken, svartiden og den tekniske kompleksiteten.

Snowflakes rapporterte resultater

Snowflake rapporterer opptil tre ganger bedre token-effektivitet i en intern test av en dbt-datapipeline, forutsatt at dynamisk ruting ga sammenlignbar kvalitet med bruk av frontier-modeller alene. I en separat kodetest sier selskapet at utviklingsteam opprettholdt gjennomstrømmingen av pull requests samtidig som de brukte omtrent 25 prosent færre tokens.

Tallene bør leses som leverandørrapporterte resultater fra interne evalueringer, ikke som uavhengig bekreftede resultater fra kunder. Effekten kan også variere mye mellom arbeidsbelastninger. En ruter som fungerer godt på repetitive dataoppgaver eller koding, kan gi et annet resultat ved lang kontekst, komplisert verktøybruk eller beslutninger med høy risiko.

Det mest nyttige kundemålet er derfor ikke «antall sparte tokens» alene. Bedrifter bør måle kostnaden ved en vellykket og godkjent oppgave, sammen med kvalitet, svartid, pålitelighet og behovet for menneskelig etterarbeid.

Nye modellalternativer: DeepSeek og GLM

Snowflake utvider samtidig modellutvalget i Cortex AI med DeepSeek-V4-Flash 0731 og Z.ai GLM-5.3. DeepSeek-V4-Flash 0731 er annonsert for privat forhåndsvisning, også i CoCo. GLM-5.3 skal etter planen komme til privat forhåndsvisning senere, avhengig av tilgjengelighet.

I intern testing med CoCo som agentplattform rapporterte Snowflake at DeepSeek-V4-Flash oppnådde 74,4 prosent i ADE-bench. Selskapet viste også til tidligere testing av GLM-5.2 – ikke GLM-5.3 – med en rapportert score på 66 prosent og det laveste tokenforbruket i den aktuelle testen. Resultatet for GLM-5.2 må derfor ikke tolkes som en publisert evaluering av GLM-5.3.

Et større utvalg åpne modeller støtter selve rutingstrategien: Jo flere alternativer systemet har, desto større er muligheten for å matche oppgavens krav med riktig kombinasjon av kostnad og ytelse. Kundene får samtidig flere valgmuligheter enn bare de mest kjente frontier-leverandørene.

Snowflakes argument om en kontrollert datagrense

Snowflakes viktigste differensieringsargument er at ruting og modelltilgang knyttes til selskapets eksisterende miljø for styrte data. Selskapet sier at det selv leverer de nye åpne modellene, i stedet for bare å videresende forespørsler til et tredjeparts-API. Data, beregningskraften for inferens, modellvekter og orkestreringen av AI-agenter skal dermed operere innenfor Snowflakes sikkerhetsperimeter. Snowflake viser også til eksisterende rollebasert tilgangskontroll og revisjonsfunksjoner.

Dette er en arkitekturpåstand fra Snowflake, ikke en universell garanti for enhver installasjon. Kunder må fortsatt kontrollere forhold som regionen løsningen kjøres i, krav til datalagring, kontraktsvilkår, logging og hvilke modeller som faktisk er godkjent for den aktuelle arbeidsbelastningen.

Tilnærmingen er særlig interessant for virksomheter som allerede har styrte analyse-data og AI-applikasjoner i Snowflake. Da handler verdien ikke bare om å velge en billigere modell. Modellvalget kan også bli en del av det samme kontroll- og revisjonsrammeverket som brukes for datatilgang.

Hvordan løsningen passer inn i markedet

Snowflake er ikke alene om å tilby modellruting. Amazon Bedrock har for eksempel intelligent prompt-ruting via et serverløst endepunkt som fordeler forespørsler mellom grunnmodeller innenfor samme modellfamilie, basert på forventet kvalitet og kostnad.

Databricks tilbyr på sin side Unity AI Gateway som et sentralt kontrollplan for ruting til modeller og MCP-tjenester, med styring av kapasitet, tilgjengelighet og forbruk på tvers av leverandører.

Den viktigste forskjellen er derfor ikke hvem som «har ruting». Spørsmålet er hvor styringsregler, data, rutinglogikk, modellkjøring og kostnadsoversikt håndteres. Snowflake fremhever en tett integrasjon med sitt styrte datamiljø, mens mer nøytrale gateway-løsninger ofte prioriterer bredere leverandørvalg og portabilitet.

For kjøpere kan følgende tommelfingerregler være nyttige:

• Velg en integrert løsning når styrte data, tilgangskontroller, agentorkestrering og modellbruk allerede er samlet på én dataplattform.
• Prioriter en mer nøytral gateway når fleksibilitet på tvers av leverandører, uavhengig rutinglogikk eller støtte for flere skyer er viktigere enn tett plattformintegrasjon.
• Undersøk modellutvalget nøye. Ikke alle gateway-løsninger kan rute mellom de samme leverandørene, modellfamiliene, regionene eller utrullingsformene.

Hva bør måles før man godtar påstander om besparelser?

En seriøs evaluering bør sammenligne automatisk ruting med en fast frontier-modell på representative produksjonsoppgaver. Mål blant annet:

• Total kostnad per vellykket oppgave, ikke bare tokenprisen til den valgte modellen.
• Kostnader for ruter eller klassifikator, dersom slike belastes separat.
• Ekstra kall som skyldes eskalering, reservevalg, nye forsøk eller mislykket verktøybruk.
• Total svartid, inkludert ruting, informasjonsinnhenting, bygging av kontekst og eventuelle andregangskall.
• Oppgavesuksess og kvalitet fordelt på ulike oppgavetyper.
• Hallusinasjoner, brudd på regler og kvalitetsfall som mindre modeller kan introdusere.
• Kostnader til menneskelig kontroll, korrigering, eskalering og omarbeiding.
• Begrensninger knyttet til datalagring, logging, dataflytting og leverandørbinding.

Snowflake sier at selskapet ikke tar separat betalt for selve rutebeslutningen, men fakturerer tokenforbruk. Eskaleringer og nye forsøk kan likevel øke den samlede bruken og svartiden. Det riktige akseptansekriteriet er derfor om rutingen reduserer kostnaden per godkjente resultat, uten å svekke kravene til kvalitet og styring.

Konklusjonen

Snowflakes kunngjøring består av to deler: dynamisk valg mellom godkjente modeller og et bredere utvalg modeller i Cortex AI. Funksjonen ventes snart i privat forhåndsvisning. DeepSeek-V4-Flash 0731 er allerede annonsert for privat forhåndsvisning, mens GLM-5.3 kommer senere, avhengig av tilgjengelighet.

Den sterkeste strategiske vinklingen er ikke den generelle ideen om å sende enkle forespørsler til rimeligere modeller. Det nye ligger i forsøket på å legge denne beslutningen innenfor Snowflakes eksisterende grense for styrte data og sikkerhet.

Snowflakes rapporterte resultat på opptil tre ganger bedre token-effektivitet er lovende, men kundene bør teste løsningen på sine egne arbeidsbelastninger. Den reelle gevinsten bør vurderes ut fra total kostnad, kvalitet, svartid, pålitelighet og menneskelig korrigering – ikke redusert tokenbruk alene.