Das Routing soll jeweils das günstigste von der Administration genehmigte Modell auswählen, das eine Aufgabe mit ausreichender Sicherheit erledigen kann. Einfache, repetitive Anfragen könnten an effiziente Open Models gehen. Aufgaben mit höherem Anspruch an die Schlussfolgerungsfähigkeit lassen sich dagegen an Frontier-Modelle von Anbietern wie Anthropic, OpenAI oder Google weiterleiten. Wer die automatische Auswahl nicht nutzen möchte, kann ein Modell fest vorgeben oder die Zahl der zulässigen Modelle einschränken.
Snowflake zufolge berücksichtigt das Verfahren außerdem Anforderungen an Datenresidenz und Governance. Für jede Anfrage soll festgehalten werden, welches Modell zum Einsatz kam. Damit zielt die Funktion nicht nur auf Kostenkontrolle, sondern auch auf einen nachvollziehbaren und prüfbaren Auswahlprozess.
Snowflake beschreibt zwei Mechanismen, mit denen das System den benötigten Grad an Modellleistung bestimmen kann.
Beim sogenannten Advisor-Muster versucht zunächst ein kleineres Modell, die Aufgabe zu lösen. Reichen seine Fähigkeiten nicht aus, kann es ein größeres Modell als Werkzeug aufrufen und die Bearbeitung fortsetzen. So sollen Unternehmen nicht für jede Anfrage den Preis eines Frontier-Modells zahlen müssen, während für schwierigere Fälle dennoch ein Eskalationsweg offensteht.
Ein separater Klassifikator kann anhand von Mustern aus früheren Anfragen besonders einfache Aufgaben erkennen und an simplere Modelle weiterleiten. Damit entstehen zwei mögliche Wege: Das System startet mit einem kleineren Modell und eskaliert bei Bedarf – oder es klassifiziert die Anfrage zunächst und wählt danach ein passendes Modell aus.
Entscheidend ist dabei das Ergebnis der gesamten Aufgabe. Ein zunächst erfolgloser Versuch, eine Eskalation oder ein erneuter Aufruf kann zusätzliche Tokens, höhere Latenz und mehr technische Komplexität verursachen. Ein günstigeres ausgewähltes Modell bedeutet deshalb nicht automatisch geringere Gesamtkosten.
In einem internen Test mit einer dbt-Pipeline meldete Snowflake eine bis zu 3× höhere Token-Effizienz, wenn Dynamic Routing bei vergleichbarer Qualität eingesetzt wurde, statt ausschließlich Frontier-Modelle zu verwenden. In einem separaten Coding-Test sollen Entwicklerteams ihren Pull-Request-Durchsatz beibehalten und dabei etwa 25 % weniger Tokens verbraucht haben.
Diese Werte stammen aus internen, vom Anbieter gemeldeten Untersuchungen und sind keine unabhängig validierten Ergebnisse aus Kundenumgebungen. Außerdem dürften sie stark von der jeweiligen Arbeitslast abhängen. Ein Router, der bei wiederkehrenden Data-Engineering- oder Coding-Aufgaben gut funktioniert, kann bei Recherche mit langem Kontext, komplexen Tool-Aufrufen oder risikoreichen Entscheidungen anders abschneiden.
Für Kunden ist daher nicht die isolierte Zahl eingesparter Tokens die wichtigste Kennzahl. Aussagekräftiger sind die Kosten einer erfolgreich erledigten und akzeptierten Aufgabe – zusammen mit Qualität, Latenz, Zuverlässigkeit und notwendiger menschlicher Nacharbeit.
Snowflake erweitert den Modellpool von Cortex AI um DeepSeek-V4-Flash 0731 und GLM-5.3 von Z.ai. DeepSeek-V4-Flash 0731 wurde für eine Private Preview angekündigt, auch innerhalb von CoCo. GLM-5.3 soll vorbehaltlich seiner Verfügbarkeit zu einem späteren Zeitpunkt in die Private Preview aufgenommen werden.
Snowflake zufolge erreichte DeepSeek-V4-Flash in einem internen Test mit CoCo als Agenten-Umgebung 74,4 % im ADE-Bench. Zusätzlich verwies das Unternehmen auf einen früheren Test mit GLM-5.2, nicht mit GLM-5.3: Dieses Modell soll dort 66 % erreicht und den geringsten Token-Verbrauch gehabt haben. Das Ergebnis zu GLM-5.2 ist daher nicht als veröffentlichte Bewertung von GLM-5.3 zu verstehen.
Ein größerer Pool verfügbarer Open Models stärkt die Routing-Strategie. Je mehr Optionen zur Verfügung stehen, desto eher lässt sich eine Aufgabe einem Modell zuordnen, dessen Kosten- und Leistungsprofil zu den Anforderungen passt.
Snowflakes wichtigstes Differenzierungsargument ist nicht das Routing an sich, sondern seine Verbindung mit der bereits bestehenden Umgebung für kontrollierte Unternehmensdaten. Das Unternehmen erklärt, die neuen Open Models selbst bereitzustellen, statt lediglich eine API eines Drittanbieters weiterzureichen. Daten, Inferenz-Rechenleistung, Modellgewichte und die Orchestrierung der Agenten sollen innerhalb von Snowflakes Sicherheitsperimeter betrieben werden. Zudem verweist Snowflake auf vorhandene rollenbasierte Zugriffskontrollen und Prüfmechanismen.
Das ist eine architektonische Aussage von Snowflake und keine pauschale Garantie für jede Implementierung. Unternehmen müssen weiterhin prüfen, in welcher Region ein Modell bereitgestellt wird, welche Anforderungen an die Datenresidenz gelten, wie Verträge und Protokollierung gestaltet sind und welche Modelle für eine konkrete Arbeitslast tatsächlich zugelassen werden können.
Besonders attraktiv ist der Ansatz für Organisationen, die ihre kontrollierten Analyse-Daten und KI-Anwendungen ohnehin in Snowflake betreiben. Dort geht es nicht nur um die Wahl eines günstigeren Modells: Die Modellauswahl kann in dasselbe Kontroll- und Prüfmodell eingebunden werden, das bereits für den Datenzugriff gilt.
Dynamisches Model-Routing ist kein Alleinstellungsmerkmal von Snowflake. Amazon Bedrock bietet beispielsweise Intelligent Prompt Routing über einen serverlosen Endpunkt. Dieser leitet Anfragen innerhalb derselben Modellfamilie anhand der erwarteten Antwortqualität und der Kosten zwischen Foundation Models weiter.
Der aussagekräftigere Vergleich lautet deshalb: Wo werden Routing-Entscheidung, Governance-Regeln, Modellausführung, Datenzugriff und Abrechnungssichtbarkeit verwaltet? Snowflake betont eine eng integrierte, von kontrollierten Unternehmensdaten ausgehende Umgebung. Andere Gateways können stärker auf Anbieterunabhängigkeit, Failover, Verkehrssteuerung oder Portabilität ausgerichtet sein. Es handelt sich dabei um unterschiedliche Architekturprioritäten – nicht um die einfache Frage, welches Produkt überhaupt Routing anbietet.
Für die Auswahl sollten Unternehmen vor allem ihre Betriebsumgebung betrachten:
Ein belastbarer Test sollte automatisches Routing mit einem festen Frontier-Modell als Referenz vergleichen und repräsentative Produktionsaufgaben einbeziehen. Mindestens diese Faktoren gehören in die Bewertung:
Snowflake erklärt, für die Routing-Entscheidung keine separate Gebühr zu erheben und stattdessen den Token-Verbrauch abzurechnen. Eskalationen und Wiederholungen können den Gesamtverbrauch und die Latenz dennoch erhöhen. Die richtige Akzeptanzbedingung lautet daher: Senkt das Routing die Kosten eines akzeptierten Ergebnisses, ohne die Qualitäts- und Governance-Anforderungen der Anwendung zu verletzen?
Snowflakes Ankündigung verbindet zwei Entwicklungen: die dynamische Auswahl zwischen zugelassenen Modellen und die Erweiterung des in Cortex AI verfügbaren Modellangebots. Dynamic Model Routing soll zunächst als Private Preview starten. DeepSeek-V4-Flash 0731 wurde bereits für die Private Preview angekündigt, während GLM-5.3 vorbehaltlich der Verfügbarkeit folgen soll.
Der strategisch interessanteste Punkt ist nicht die allgemeine Idee, einfache Anfragen an günstigere Modelle zu schicken. Entscheidend ist der Versuch, diese Entscheidung innerhalb von Snowflakes kontrollierter Daten- und Sicherheitsumgebung zu verankern. Das gemeldete Ergebnis von bis zu 3× höherer Token-Effizienz klingt vielversprechend – muss aber an den eigenen Arbeitslasten gemessen werden. Am Ende zählen Gesamtkosten, Qualität, Latenz, Zuverlässigkeit und menschliche Nacharbeit, nicht die Token-Ersparnis allein.