Router ma wybierać najtańszy model zatwierdzony przez administratora, który z odpowiednio wysoką pewnością poradzi sobie z danym zadaniem. Proste, rutynowe lub powtarzalne zapytania mogą trafiać do wydajnych modeli otwartych, natomiast bardziej złożone zadania — do modeli frontier oferowanych między innymi przez Anthropic, OpenAI i Google.
Firmy nie będą jednak zmuszone do pełnej automatyzacji. Mogą przypiąć konkretny model albo ograniczyć pulę modeli, spośród których router może wybierać. Snowflake deklaruje również uwzględnianie zasad zarządzania danymi i rezydencji danych oraz rejestrowanie modelu wybranego dla każdego żądania. To może mieć znaczenie dla organizacji, które potrzebują audytowalnego procesu wyboru modelu.
Snowflake opisał dwa mechanizmy decydowania, czy zadanie wymaga większych możliwości modelu.
W tak zwanym advisor pattern mniejszy model próbuje najpierw wykonać zadanie. Jeśli nie jest w stanie zrobić tego wystarczająco dobrze, może wywołać większy model jako narzędzie i kontynuować pracę.
Takie podejście ma ograniczyć koszty obsługi prostych próśb, a jednocześnie zachować ścieżkę eskalacji w trudniejszych przypadkach. Trzeba jednak pamiętać, że dodatkowe wywołanie może zwiększyć zarówno zużycie tokenów, jak i czas odpowiedzi.
Drugi mechanizm wykorzystuje klasyfikator uczony na podstawie wzorców z wcześniejszych zapytań. Ma on rozpoznawać proste zadania i kierować je od razu do prostszych modeli.
W praktyce powstają więc dwie ścieżki: system może rozpocząć pracę od małego modelu i eskalować w razie potrzeby albo sklasyfikować zapytanie jeszcze przed wyborem modelu. Kluczowe pytanie brzmi jednak nie „czy wybrano tańszy model?”, lecz „czy zadanie zostało wykonane dobrze za niższą cenę?”. Nieudana pierwsza próba, eskalacja lub ponowienie żądania mogą bowiem zwiększyć koszty i opóźnienia.
Snowflake podał, że w wewnętrznym obciążeniu związanym z budowaniem potoków dbt dynamiczne routowanie zapewniło do 3 razy większą efektywność tokenową przy porównywalnej jakości względem korzystania wyłącznie z modeli frontier. W osobnym teście dotyczącym programowania zespoły inżynieryjne miały utrzymać tę samą liczbę obsłużonych pull requestów, zużywając około 25 proc. mniej tokenów.
To wyniki przedstawione przez producenta na podstawie wewnętrznych ewaluacji, a nie niezależnie potwierdzone rezultaty klientów. Mogą też znacząco różnić się w zależności od rodzaju pracy. Router dobrze radzący sobie z powtarzalnymi zadaniami inżynierii danych lub kodowania nie musi działać równie dobrze przy długim kontekście, złożonym korzystaniu z narzędzi czy decyzjach obarczonych wysokim ryzykiem.
Najlepszym miernikiem nie jest więc sama liczba zaoszczędzonych tokenów. Firmy powinny sprawdzać koszt poprawnie zakończonego zadania, jednocześnie mierząc jakość, opóźnienia, niezawodność i zakres pracy wymaganej później od człowieka.
Snowflake rozszerza ofertę modeli dostępnych w Cortex AI o DeepSeek-V4-Flash 0731 oraz GLM-5.3 firmy Z.ai. DeepSeek-V4-Flash 0731 został zapowiedziany w prywatnej wersji testowej, również w produkcie CoCo. GLM-5.3 ma trafić do prywatnych testów w późniejszym terminie, zależnie od dostępności modelu.
Snowflake podał, że w wewnętrznym teście z użyciem CoCo jako środowiska agenta DeepSeek-V4-Flash uzyskał 74,4 proc. w benchmarku ADE-bench. Firma przywołała też wcześniejszy test modelu GLM-5.2 — nie GLM-5.3 — w którym uzyskano wynik 66 proc. przy najniższym zużyciu tokenów w tym benchmarku. Wyniku GLM-5.2 nie należy traktować jako opublikowanej oceny GLM-5.3.
Większa liczba dostępnych modeli wzmacnia sens routowania: im szersza pula, tym więcej możliwości dopasowania wymagań zadania do właściwego profilu kosztów i wydajności. Dla klientów oznacza to również większy wybór poza najbardziej znanymi dostawcami modeli frontier.
Najważniejszym elementem strategii Snowflake nie jest samo kierowanie zapytań między modelami. Firma podkreśla, że routowanie i dostęp do modeli są powiązane z jej środowiskiem zarządzania danymi.
Snowflake twierdzi, że samodzielnie udostępnia nowe modele otwarte, zamiast jedynie przekazywać żądania do zewnętrznego API. Według firmy dane, moc obliczeniowa potrzebna do inferencji, wagi modeli i orkiestracja agentów działają w ramach jej granicy bezpieczeństwa. Snowflake wskazuje także na istniejące mechanizmy kontroli dostępu opartej na rolach oraz audytu.
To deklaracja architektoniczna Snowflake, a nie uniwersalna gwarancja dla każdego wdrożenia. Klienci nadal powinni sprawdzić szczegóły istotne dla własnego środowiska: region wdrożenia, wymagania dotyczące lokalizacji danych, warunki umów, sposób logowania oraz listę modeli faktycznie dopuszczonych do konkretnego obciążenia.
Największa korzyść może pojawić się w organizacjach, które już przechowują zarządzane dane analityczne i aplikacje AI w Snowflake. W takim układzie wybór modelu może zostać włączony do tego samego systemu kontroli i audytu, który reguluje dostęp do danych.
Dynamiczne routowanie nie jest rozwiązaniem unikalnym dla Snowflake. Amazon Bedrock oferuje na przykład inteligentne routowanie promptów przez bezserwerowy punkt końcowy. Mechanizm kieruje żądania między modelami bazowymi w ramach tej samej rodziny, przewidując jakość odpowiedzi i uwzględniając koszt.
Databricks wykorzystuje Unity AI Gateway jako centralny punkt kierowania ruchu do modeli i usług MCP, z kontrolą pojemności, dostępności i wydatków między dostawcami.
Nvidia przedstawia NeMo Switchyard jako niezależną od dostawcy warstwę routowania, która oddziela logikę wyboru modelu od konkretnych punktów końcowych. Z kolei OpenRouter koncentruje się na agregacji wielu dostawców i routowaniu między nimi, domyślnie równoważąc ruch między odpowiednimi dostawcami, aby zwiększać dostępność usługi.
Różnica nie sprowadza się więc do pytania, kto potrafi wybrać tańszy model. Ważniejsze jest to, gdzie znajdują się zasady zarządzania, dostęp do danych, logika routowania, wykonanie modelu i rozliczanie użycia.
Poważna ewaluacja powinna porównywać automatyczne routowanie ze stałym wykorzystaniem jednego modelu frontier na reprezentatywnych danych produkcyjnych. Warto mierzyć co najmniej:
Snowflake deklaruje, że nie pobiera osobnej opłaty za samą decyzję routującą i rozlicza zużycie tokenów. Mimo to eskalacje i ponowienia mogą zwiększyć łączne wykorzystanie oraz opóźnienie. Właściwym kryterium akceptacji jest zatem obniżenie kosztu zaakceptowanego rezultatu przy zachowaniu wymaganej jakości i poziomu zarządzania.
Zapowiedź Snowflake łączy dwa działania: automatyczny wybór modelu spośród zatwierdzonych opcji oraz rozszerzenie katalogu modeli dostępnych w Cortex AI. Funkcja dynamicznego routowania ma wkrótce wejść do prywatnych testów. DeepSeek-V4-Flash 0731 został już zapowiedziany w prywatnej wersji testowej, natomiast GLM-5.3 ma pojawić się później, zależnie od dostępności.
Najmocniejszym argumentem Snowflake nie jest sam pomysł wysyłania prostych próśb do tańszych modeli — podobne mechanizmy rozwija już wiele platform. Firma próbuje przede wszystkim umieścić tę decyzję w zarządzanym środowisku danych i bezpieczeństwa Snowflake.
Raportowana trzykrotna poprawa efektywności tokenowej wygląda obiecująco, ale nie powinna być traktowana jako gwarantowana oszczędność. Klienci muszą przetestować rozwiązanie na własnych obciążeniach i oceniać je na podstawie kosztu końcowego, jakości, opóźnień, niezawodności oraz pracy człowieka potrzebnej do korekt — nie zaś samej redukcji liczby tokenów.