Snowflakes dynamiske modelrouting skal sænke AI-omkostningerne uden at gå på kompromis med kvaliteten

Kunderne kan definere, hvilke modeller der må anvendes, og hvilke hensyn en applikation skal prioritere – eksempelvis pris, kvalitet eller svartid. Routeren skal derefter vælge den billigste model, som den vurderer med tilstrækkelig sikkerhed kan løse opgaven.

Det betyder i praksis, at enkle, gentagne eller lavkomplekse forespørgsler kan sendes til effektive open source-modeller, mens opgaver med større krav til ræsonnering kan gå videre til frontier-modeller fra eksempelvis Anthropic, OpenAI og Google. Virksomheder kan fortsat styre valget manuelt ved at fastlåse en bestemt model eller begrænse puljen af modeller, der må vælges.

Snowflake oplyser desuden, at routingen kan tage hensyn til krav om dataresidens og organisationens governance-politikker. Systemet skal også registrere, hvilken model der blev valgt til hver forespørgsel. Det gør funktionen relevant både som et værktøj til omkostningsstyring og som del af en revisionssporbar modelstyring.

Sådan skal modelvalget fungere

Snowflake har beskrevet to mekanismer til at afgøre, hvor meget modelkapacitet en opgave kræver.

Advisor-mønstret

I det såkaldte advisor-mønster forsøger en mindre model først at løse opgaven. Hvis den ikke kan levere et tilfredsstillende resultat, kan den kalde en større model som værktøj og fortsætte arbejdet derfra.

Formålet er at undgå frontier-priser på forespørgsler, som en mindre model sagtens kan håndtere, samtidig med at der findes en vej videre til en stærkere model, når opgaven er vanskeligere.

Klassifikatorbaseret routing

En separat klassifikator kan bruge mønstre fra historiske forespørgsler til at identificere ligetil opgaver og sende dem til enklere modeller. Dermed opstår der to mulige arbejdsgange: Systemet kan enten begynde med en mindre model og eskalere efter behov, eller klassificere forespørgslen, før modellen vælges.

Det afgørende spørgsmål er dog ikke kun, om systemet vælger en billigere model. Et mislykket første forsøg, en eskalering eller en gentagelse kan øge både tokenforbruget, svartiden og den tekniske kompleksitet.

Snowflakes egne resultater

Snowflake rapporterer op til 3 gange bedre token-effektivitet i en intern test af en dbt-pipeline, hvor dynamisk routing leverede sammenlignelig kvalitet med en løsning, der udelukkende brugte frontier-modeller. I en separat test af kodningsopgaver oplyser virksomheden, at udviklingsteams fastholdt samme gennemløb af pull requests, mens de brugte omkring 25 procent færre tokens.

Resultaterne er virksomhedens egne interne evalueringer og ikke uafhængigt validerede kundedata. De kan også variere markant fra arbejdsbelastning til arbejdsbelastning. En router, der fungerer godt til gentagne data engineering- eller kodningsopgaver, vil ikke nødvendigvis give samme resultat ved lang kontekst, komplekst værktøjsbrug eller beslutninger med høj risiko.

Den mest relevante kundemåling er derfor ikke “sparede tokens” alene. Det bør være den samlede pris for en opgave, der faktisk bliver løst og accepteret – målt sammen med kvalitet, svartid, driftssikkerhed og behovet for menneskelig efterbehandling.

Nye modeller: DeepSeek og GLM

Snowflake udvider samtidig udvalget af modeller i Cortex AI med DeepSeek-V4-Flash 0731 og Z.ai’s GLM-5.3. DeepSeek-V4-Flash 0731 er annonceret til private preview, også i CoCo, mens GLM-5.3 efter planen kommer i private preview senere, afhængigt af tilgængelighed.

I en intern test med CoCo som agentramme oplyser Snowflake, at DeepSeek-V4-Flash opnåede 74,4 procent på ADE-bench. Virksomheden henviser også til en tidligere test af GLM-5.2 – ikke GLM-5.3 – hvor modellen opnåede 66 procent og havde det laveste tokenforbrug i den pågældende benchmark. Resultatet for GLM-5.2 bør derfor ikke læses som en offentlig evaluering af GLM-5.3.

Et større udvalg af open source-modeller understøtter Snowflakes routingstrategi. Jo flere modeller systemet kan vælge imellem, desto flere muligheder har det for at matche opgavens krav med en passende kombination af pris og ydeevne.

Snowflakes argument om en kontrolleret datagrænse

Snowflakes vigtigste differentieringsargument er, at modelrouting og modeladgang knyttes til virksomhedens eksisterende miljø for kontrollerede data. Snowflake siger, at de nye open source-modeller leveres af Snowflake selv frem for blot at blive videresendt til en tredjeparts-API. Ifølge virksomheden foregår data, inferensberegning, modelvægte og agentorkestrering inden for Snowflakes sikkerhedsperimeter, som også omfatter eksisterende rollebaseret adgangskontrol og revisionsmekanismer.

Det er et arkitekturargument fra Snowflake og ikke en universel garanti for enhver installation. Kunder bør stadig kontrollere forhold som regionen, hvor løsningen kører, krav til dataresidens, kontraktvilkår, logning og hvilke modeller der rent faktisk er godkendt til den konkrete arbejdsbelastning.

Fordelen er mest oplagt for organisationer, der allerede har deres kontrollerede analysedata og AI-applikationer i Snowflake. Her handler værdien ikke kun om at vælge en billigere model, men også om at gøre modelvalget til en del af det samme kontrol- og revisionssystem, som bruges til dataadgang.

Hvordan passer løsningen ind på routingmarkedet?

Modelrouting er ikke en idé, Snowflake står alene med. Amazon Bedrock tilbyder eksempelvis intelligent prompt-routing via et serverløst slutpunkt, der sender forespørgsler mellem foundation-modeller inden for samme modelserie på baggrund af forventet svarkvalitet og pris.

Den mere interessante forskel er, hvor beslutningen om routing, governance-politikken, modelkørslen, dataadgangen og faktureringen håndteres. Snowflake fremhæver en tæt integreret datagrænse med governance. Andre gateways kan i højere grad prioritere valg på tværs af leverandører, trafikstyring, fejlhåndtering eller portabilitet.

For købere bør valget derfor afhænge af driftsmiljøet:

• Vælg en integreret løsning, hvis kontrollerede data, adgangsregler, agentorkestrering og modelbrug allerede er samlet på én datap platform.
• Prioritér en mere neutral gateway, hvis portabilitet på tværs af leverandører, uafhængig routinglogik eller multi-cloud-fleksibilitet er vigtigere end tæt platformintegration.
• Undersøg modelpuljen, og antag ikke, at alle gateways kan route mellem de samme leverandører, modelserier, regioner eller implementeringstyper.

Hvad bør virksomheder måle, før de accepterer besparelserne?

En seriøs evaluering bør sammenligne automatisk routing med en fast frontier-model på repræsentative produktionsopgaver. Som minimum bør virksomheder følge:

• Samlet pris pr. gennemført og accepteret opgave – ikke kun tokenprisen for den valgte model.
• Eventuelle udgifter til router eller klassifikator.
• Ekstra kald som følge af advisor-eskalering, fallback, gentagelser eller mislykket værktøjsbrug.
• End-to-end-svartid, inklusive routing, informationssøgning, samling af kontekst og ekstra modelkald.
• Succesrate og kvalitet fordelt på opgavetyper.
• Hallucinationer, brud på politikker og forringelser, som mindre modeller kan introducere.
• Omkostninger til menneskelig kontrol, korrektion, eskalering og efterarbejde.
• Begrænsninger knyttet til dataresidens, observerbarhed, dataudførsel og leverandørafhængighed.

Snowflake siger, at virksomheden ikke opkræver en særskilt pris for selve routingbeslutningen, men i stedet fakturerer tokenforbruget. Eskaleringer og gentagelser kan dog stadig øge det samlede forbrug og svartiden. Det rigtige succeskriterium er derfor, om routingen sænker prisen for et accepteret resultat uden at svække applikationens krav til kvalitet og governance.

Konklusion

Snowflakes annoncering består af to tæt forbundne tiltag: dynamisk valg mellem godkendte modeller og et større udvalg af modeller i Cortex AI. Funktionen forventes snart i private preview. DeepSeek-V4-Flash 0731 er allerede annonceret til private preview, mens GLM-5.3 følger senere, hvis modellen er tilgængelig.

Den stærkeste strategiske pointe er ikke blot, at nemme opgaver kan sendes til billigere modeller. Det er forsøget på at placere beslutningen inden for Snowflakes kontrollerede data- og sikkerhedsgrænse. Den rapporterede gevinst på op til 3 gange bedre token-effektivitet er lovende, men virksomheder bør teste løsningen på deres egne arbejdsbelastninger og vurdere den på samlet pris, kvalitet, svartid, driftssikkerhed og menneskelig efterbehandling – ikke på tokenreduktion alene.