Snowflake laat Cortex AI Gateway per taak het juiste AI-model kiezen

Snowflake heeft dynamische modelroutering aangekondigd voor Cortex AI Gateway. De functie moet per taak bepalen welk goedgekeurd AI-model het meest geschikt is, in plaats van elke aanvraag standaard naar hetzelfde krachtige model te sturen. De technologie wordt naar verwachting binnenkort beschikbaar als private preview en is dus nog geen algemeen verkrijgbare productrelease.

De belofte is eenvoudig: gebruik goedkopere, efficiënte modellen wanneer die een taak goed aankunnen en zet krachtigere modellen alleen in wanneer complexer redeneerwerk nodig is. Snowflake noemt dat ‘intelligence efficiency’: niet de prijs van afzonderlijke modeltokens staat centraal, maar de kosten van een zakelijk resultaat dat daadwerkelijk goed wordt afgerond.

Wat Snowflake aankondigt

Dynamische modelroutering komt beschikbaar via Cortex AI Gateway en wordt geïntegreerd in Snowflake CoCo en CoWork. Ook AI-agents van derden die via de gateway zijn verbonden, kunnen de functie gebruiken. Klanten kunnen zelf vastleggen welke modellen mogen worden ingezet en welke afwegingen voor een applicatie het zwaarst wegen, zoals kosten, kwaliteit of latency.

De router moet vervolgens het goedkoopste model kiezen dat volgens het systeem met voldoende zekerheid aan de kwaliteitseisen kan voldoen. Eenvoudige, routinematige of repetitieve verzoeken kunnen naar efficiënte open modellen gaan. Taken die diepere analyse vereisen, kunnen worden doorgestuurd naar frontiermodellen van onder meer Anthropic, OpenAI en Google. Organisaties houden ook handmatige controle: ze kunnen een model vastzetten of de lijst met toegestane modellen beperken.

Volgens Snowflake kan de router bovendien rekening houden met eisen rond dataresidentie en governance. Het systeem registreert welk model voor elke aanvraag is gekozen. Daardoor gaat de functie niet alleen over kostenbeheersing, maar ook over een controleerbaar proces voor modelselectie.

Hoe de routering werkt

Snowflake beschrijft twee manieren om te bepalen hoeveel modelcapaciteit een taak nodig heeft.

Het advisor-patroon

Bij het zogenoemde advisor-patroon probeert eerst een kleiner model de taak uit te voeren. Lukt dat niet goed genoeg, dan kan dit model een groter model als hulpmiddel aanroepen en daarna verdergaan. Zo hoeven bedrijven niet voor elke eenvoudige vraag het tarief van een frontiermodel te betalen, terwijl er wel een escalatieroute beschikbaar blijft voor moeilijkere opdrachten.

Routering met een classifier

Een afzonderlijke classifier kan patronen uit historische aanvragen gebruiken om eenvoudige verzoeken te herkennen. Die worden vervolgens naar lichtere modellen gestuurd. In de praktijk ontstaan daarmee twee routes: het systeem kan klein beginnen en opschalen als dat nodig is, of de aanvraag vooraf classificeren en meteen een passend model selecteren.

De belangrijkste operationele vraag is niet alleen of de router een goedkoper model kiest, maar of de volledige taak daardoor beter uitpakt. Een mislukte eerste poging, escalatie of nieuwe poging kan extra tokens, vertraging en technische complexiteit veroorzaken.

Resultaten volgens Snowflake

Snowflake meldt in een interne test met een dbt-pipeline een tot drie keer hogere tokenefficiëntie wanneer dynamische routering een vergelijkbare kwaliteit opleverde als het gebruik van uitsluitend frontiermodellen. In een aparte test met programmeerwerk zouden engineeringteams dezelfde doorvoer van pull requests hebben behouden met ongeveer 25 procent minder tokens.

Deze cijfers zijn door Snowflake zelf gerapporteerde resultaten uit interne evaluaties. Ze zijn niet onafhankelijk bevestigd in klantomgevingen. Bovendien kunnen de uitkomsten sterk verschillen per workload. Een router die goed presteert bij repetitieve data-engineering- of programmeertaken kan andere resultaten geven bij onderzoek met lange context, complex toolgebruik of beslissingen met een hoog risico.

Voor klanten is ‘bespaarde tokens’ daarom geen afdoende maatstaf. Relevanter is de prijs van een succesvol afgeronde en geaccepteerde taak, gemeten naast kwaliteit, latency, betrouwbaarheid en menselijke nabewerking.

Meer modelkeuze: DeepSeek en GLM

Snowflake breidt het modelaanbod binnen Cortex AI uit met DeepSeek-V4-Flash 0731 en Z.ai’s GLM-5.3. DeepSeek-V4-Flash 0731 is aangekondigd voor een private preview, ook binnen CoCo. GLM-5.3 zou binnenkort volgen, afhankelijk van de beschikbaarheid van het model.

Snowflake zegt dat DeepSeek-V4-Flash in interne tests met CoCo als agentomgeving 74,4 procent scoorde op ADE-bench. Het bedrijf verwijst daarnaast naar eerdere tests met GLM-5.2, niet GLM-5.3, waarin een score van 66 procent werd gemeld bij het laagste tokengebruik in die benchmark. Die GLM-5.2-uitkomst mag daarom niet worden gelezen als een gepubliceerde evaluatie van GLM-5.3.

Een groter aanbod aan open modellen ondersteunt de routeringsstrategie. Hoe meer modellen beschikbaar zijn, hoe meer mogelijkheden er zijn om de vereisten van een taak te koppelen aan een geschikte verhouding tussen prijs en prestaties. Klanten krijgen bovendien meer keuze naast de bekendste frontieraanbieders.

Snowflakes argument rond een beheerde dataomgeving

Snowflakes belangrijkste onderscheidende claim is dat modeltoegang en routering worden gekoppeld aan de bestaande omgeving voor beheerde data. Het bedrijf zegt de nieuwe open modellen zelf aan te bieden in plaats van alleen een API van een derde partij door te sturen. Data, inferentie-infrastructuur, modelgewichten en de orkestratie van agents zouden binnen Snowflakes beveiligingsgrens blijven. Ook wijst Snowflake op bestaande toegangscontrole op basis van rollen en auditmogelijkheden.

Dat is een architectuurclaim van Snowflake, geen universele garantie voor iedere implementatie. Klanten moeten zelf controleren hoe de opzet uitpakt voor hun regio, dataresidentie, contractvoorwaarden, logging en de modellen die voor een specifieke workload daadwerkelijk zijn toegestaan.

De propositie is vooral interessant voor organisaties die hun beheerde analytische data en AI-applicaties al in Snowflake onderbrengen. In dat geval gaat de meerwaarde verder dan een goedkoper model kiezen: modelselectie kan onderdeel worden van hetzelfde controle- en auditkader als de toegang tot data.

Hoe Snowflake zich verhoudt tot andere gateways

Modelroutering is geen uniek Snowflake-concept. Amazon Bedrock biedt bijvoorbeeld intelligente promptroutering via één serverloos endpoint. Dat endpoint verdeelt aanvragen over foundationmodellen binnen dezelfde modelfamilie op basis van de voorspelde kwaliteit en kosten.

Het belangrijkere onderscheid is waar de routeringsbeslissing, governance, modeluitvoering, datatoegang en facturatie-informatie samenkomen. Snowflake legt de nadruk op een strak geïntegreerde grens rond beheerde data. Andere gateways kunnen juist meer nadruk leggen op providerkeuze, verkeersbeheer, failover of overdraagbaarheid. Dat zijn verschillende architectuurprioriteiten, niet simpelweg de vraag welk product ‘routering’ heeft.

Voor inkopers en architectuurteams komt de keuze grofweg hierop neer:

• Kies een geïntegreerde aanpak wanneer beheerde data, toegangsbeheer, agentorkestratie en modelgebruik al rond één dataplatform zijn georganiseerd.
• Geef een neutralere gateway prioriteit wanneer overstappen tussen providers, onafhankelijke routeringslogica of multicloudflexibiliteit belangrijker is dan platformintegratie.
• Controleer de modelpool en ga er niet van uit dat iedere gateway tussen dezelfde providers, modelfamilies, regio’s of implementatietypen kan schakelen.

Waar bedrijven op moeten meten

Een serieuze evaluatie moet automatische routering vergelijken met een vaste baseline, bijvoorbeeld steeds hetzelfde frontiermodel, op representatieve productieworkloads. Meet ten minste:

• de totale kosten per succesvol afgeronde taak, niet alleen de tokenprijs van het gekozen model;
• eventuele kosten voor de router of classifier;
• extra aanvragen door escalaties, fallbacks, retries of mislukte tooluitvoering;
• end-to-end latency, inclusief routering, retrieval, contextopbouw en vervolgaanvragen;
• slagingspercentage en kwaliteit per categorie taak;
• hallucinaties, beleidschendingen en kwaliteitsverlies door kleinere modellen;
• kosten voor menselijke controle, correcties, escalatie en nabewerking;
• beperkingen rond dataresidentie, observability, dataverkeer en afhankelijkheid van een leverancier.

Snowflake zegt geen afzonderlijke kosten voor de routeringsbeslissing in rekening te brengen en in plaats daarvan tokengebruik te factureren. Toch kunnen escalaties en retries het totale verbruik en de latency verhogen. Het juiste criterium is daarom of routering de kosten van een geaccepteerd eindresultaat verlaagt, zonder de kwaliteits- en governance-eisen van de applicatie aan te tasten.

Conclusie

Snowflakes aankondiging bestaat uit twee ontwikkelingen: automatische selectie uit een reeks goedgekeurde modellen en een uitbreiding van het modelaanbod binnen Cortex AI. De dynamische routering wordt binnenkort in private preview verwacht. DeepSeek-V4-Flash 0731 is al voor private preview aangekondigd; GLM-5.3 volgt later, afhankelijk van beschikbaarheid.

De strategische kern is niet alleen dat eenvoudige taken naar goedkopere modellen kunnen gaan. Snowflake probeert die beslissing onder te brengen binnen dezelfde beheerde data- en beveiligingsgrens die bedrijven al gebruiken. De gemelde verbetering van tot drie keer in tokenefficiëntie is veelbelovend, maar organisaties zullen de technologie op hun eigen workloads moeten testen. Uiteindelijk tellen niet alleen minder tokens, maar vooral lagere kosten per afgeronde taak, behoud van kwaliteit, voorspelbare latency, betrouwbaarheid en minder menselijke correctie.