Loteria identyfikatora modelu: ten sam request, inny wynik

Za wielodostawczą bramą (multi-provider gateway), identyfikator modelu nie określa, co obsłuży Twój request. Nazywa on zbiór wdrożeń z różnymi konfiguracjami obsługi, a jeśli nie przypniesz konkretnego, każdy request jest losowaniem z tego zbioru. Tego nauczyliśmy się na własnej skórze: podczas oceny modelu moonshotai/kimi-k2.5 przez OpenRouter (186 wywołań, rozpoczętych 2026-04-22, finałowe rundy w kolejnych dniach), ta sama konfiguracja requestu, ten sam identyfikator modelu, ta sama wskazówka provider: { sort: "latency" }, ten sam zestaw dziesięciu promptów, wyprodukował medianę 312 ms czasu do pierwszego tokena z zerem strumieniowanych znaków rozumowania w jednej rundzie (10 na 10 wywołań), a 3073 ms z medianą 2627 znaków rozumowania w późniejszej rundzie (znów 10 na 10). Inny dostawca obsłużył ten sam identyfikator z zupełnie innym zachowaniem, bez żadnej zmiany po naszej stronie. Metadane odpowiedzi wskazują dostawcę obsługującego, jeśli pomyślisz o ich logowaniu; nic nie sygnalizuje, że zachowanie się zmieniło.

Znacznie ostrzejsze odkrycie jest takie, że flaga routingu, której spodziewaliśmy się zapobiec dokładnie temu problemowi, nie zapobiegła mu w naszych testach. Jeśli Twój produkt zależy od głębokości rozumowania, identyfikator modelu w Twojej konfiguracji nie jest tym, co wdrożyłeś. Wdrożyłeś losowy kupon, a kontrolki routingu bramowego są wskazówkami do zweryfikowania, a nie kontraktami, na które możesz polegać.

Ten sam request, dwukrotnie

Benchmarkowaliśmy modele kandydujące dla asystenta zgodnościowego, więc każda konfiguracja uruchamiała te same zestawy promptów: dziesięć standardowych promptów zgodnościowych (wyjaśnij załącznik A.5.1 ISO 27001, artykuł 32 RODO, CC6.1 SOC 2 itd.) oraz pięć trudnych promptów zbudowanych do syntezy wieloramowej — rodzaj pytań, gdzie głębia rozumowania ma znaczenie. Dla każdego wywołania rejestrowaliśmy czas do pierwszego tokena, całkowity czas, strumieniowane znaki rozumowania, strumieniowane znaki treści oraz pole provider, które OpenRouter zwraca w każdym fragmencie strumienia.

Przy sort: "latency" wczesne rundy kierowały wszystkie dziesięć wywołań standardowego zestawu do jednego dostawcy hostingowego (BaseTen): 312 ms mediany do pierwszego tokena, zero strumieniowanych znaków rozumowania we wszystkich wywołaniach. W późniejszej rundzie, dni później, ta sama konfiguracja requestu kierowała wszystkie dziesięć wywołań do innego dostawcy (ModelRun): 3073 ms mediany, 2627 znaków rozumowania mediany. Jeszcze późniejsza runda skierowała z powrotem do pierwszego. Tak działa sort: "latency" z założenia. Dokumentacja OpenRouter dotycząca routingu dostawców (dostępna 2026-07-15) mówi, że przy jawnej sort, „równoważenie obciążenia zostanie wyłączone, a router będzie próbował dostawców w kolejności”, uporządkowanych według mierzonej latencji. Mierzona latencja się zmienia, więc kolejność się zmienia, a wraz z nią — w naszych testach — pojawianie się jakiegokolwiek wyjściowego rozumowania.

10-krotna zmiana opóźnienia jest irytująca. Zmiana zachowania pod stabilnym identyfikatorem modelu to problem innej klasy, bo nic Ci o tym nie powie. Każda odpowiedź była HTTP 200 z płynną treścią i wiarygodnym rozliczeniem tokenów.

Flaga, której spodziewaliśmy się, że to wykryje

Nie przyjęliśmy wyniku z zerowym rozumowaniem za dobrą monetę. Próbowaliśmy wymusić rozumowanie na szybkiej ścieżce przy użyciu każdego parametru oferowanego przez API: reasoning: { enabled: true }, reasoning: { effort: "high" }, reasoning: { max_tokens: 1024 }. Zero strumieniowanych znaków rozumowania, za każdym razem, kiedy request był obsługiwany przez tego dostawcę.

Następnie sięgnęliśmy po kontrolkę routingu. Dokumentacja OpenRouter opisuje require_parameters następująco: „Kiedy ustawisz require_parameters na true, request nie zostanie nawet skierowany do tego dostawcy”, odnosząc się do dostawców, którzy nie obsługują wszystkich parametrów w Twoim requestcie (dokumentacja routingu dostawców, dostępna 2026-07-15). Ustawiliśmy require_parameters: true obok reasoning: { effort: "high" }. Request został i tak skierowany do tego samego dostawcy, a odpowiedź ponownie nie zawierała tekstu rozumowania.

Zanim wyciągnęliśmy jakiekolwiek wnioski, zweryfikowaliśmy format naszych parametrów względem znanych, działających wdrożeń, bo „model nie rozumuje” i „ten endpoint nie udostępnia rozumowania” wyglądają identycznie z zewnątrz. Przypięci do DeepInfra, ten sam identyfikator modelu wyprodukował 3116 znaków rozumowania bez flagi i 3807 z reasoning: { enabled: true }. Przypięci do Novita: 3460 znaków. Te testy rozstrzygają kluczową kwestię: rodzina modeli rozumuje, nasza składnia requestów była prawidłowa, a zmienną był endpoint obsługujący.

Aby precyzyjnie określić, co to pokazuje, a czego nie: require_parameters jest udokumentowany jako filtr dostawców według obsługi parametrów, a na podstawie samych odpowiedzi nie możemy stwierdzić, czy nasze wyniki z zerowym rozumowaniem odzwierciedlały metadane możliwości endpointu, obsługę parametrów po stronie dostawcy, czy konfigurację obsługi, która po prostu nie udostępnia tekstu rozumowania. Endpoint, który nie udostępnia rozumowania, może być świadomym i legalnym wyborem obsługi; 312 ms do pierwszego tokena to realna oferta produktowa, a zero strumieniowanych znaków rozumowania dowodzi jedynie, że rozumowanie nie zostało nam udostępnione — nie że żadne obliczenia nie zostały wykonane. To, co możemy powiedzieć, jest węższe i bardziej użyteczne: w naszych testach z kwietnia 2026 deklarowanie parametru rozumowania jako wymaganego nie skierowało nas do endpointu, którego odpowiedzi zawierały wyjściowe rozumowanie. Niezależnie od mechanizmu, praktyczny kontrakt, który myśleliśmy mieć, nie obowiązywał, a jedynie pomiar wyjściowy nam o tym powiedział.

Dlaczego produkt zgodnościowy to zauważa, a Twój może nie

Oto niewygodna część, przedstawiona wprost: na naszych pięciu trudnych promptach konfiguracja z zerowym rozumowaniem wciąż wyglądała kompetentnie. Poproszeni o znalezienie nakładających się kontroli i konfliktu między ISO 27001, artykułem 32 RODO i PCI DSS dla 50-osobowej firmy SaaS, wyprodukowała ustrukturyzowaną analizę z konkretnymi odniesieniami do klauzul, jak zapisano w naszych notatkach z testów: kontrole załącznika A.9.1 do A.9.4 ISO 27001, art. 32(1)(a) RODO, wymagania 3.4 i 4.1 PCI DSS. Zauważcie niuans w płynności: A.9.x to numeracja przestarzałej edycji ISO/IEC 27001:2013; rewizja z 2022 roku zreorganizowała załącznik A. Odpowiedź wyglądała na autorytatywną i zawierała błąd edycji, którego nic w odpowiedzi nie sygnalizowało; zauważyliśmy to dopiero sprawdzając numerację względem rewizji z 2022 roku. To jest miniaturowy kształt awarii: płynna, ustrukturyzowana, konkretna i cicho niebędąca zachowaniem, które skonfigurowaliście. Gdyby nasza ocena ograniczała się do „rzuć okiem na kilka odpowiedzi, szukając oczywistych błędów”, utrata wyjściowego rozumowania pozostałaby niewidoczna. Ujawniła się, ponieważ rejestrowaliśmy znaki rozumowania na request, jako pierwszorzędową metrykę, a kolumna spadła do zera.

Pozostałe skany rodziny kimi wzmocniły, jak różnie każda ścieżka zawodzi. Wyspecjalizowana odmiana myśląca (moonshotai/kimi-k2-thinking) wyprodukowała wyjściowe rozumowanie we wszystkich trudnych promptach (mediana 4103 znaków), ale osiągnęła 178 618 ms do pierwszego tokena przy jednym głębokim promptcie rozumowania — trzyminutowe wpatrywanie się w kółeczko. Przypięcie kimi-k2.5 do dostawcy zdolnego do rozumowania (Inceptron) wyprodukowało realne rozumowanie, ale nie powiodło 2 z 5 trudnych promptów: odpowiedź zużyła cały budżet 2048 tokenów na rozumowanie i nie wyemitowała żadnej treści. Szybko bez wyjściowego rozumowania, rozumowanie bez ograniczonej latencji lub rozumowanie, które zagłodzi odpowiedź. Trzy tryby awarii w obrębie jednej rodziny modeli, a żaden z nich nie był widoczny w identyfikatorach. Odeszliśmy od każdej z tych ścieżek w produkcji.

Dla asystenta zgodnościowego stawki są konkretne: odpowiedź zasila ocenę ryzyka lub odpowiedź audytową, a odpowiedź może wyglądać na autorytatywną, niosąc dokładnie tę staroć, której audytor szuka. „Płynna, ale nie to zachowanie, które skonfigurowałeś” to najgorszy kształt awarii w tej dziedzinie, bo nic w odpowiedzi nie oznacza jej jako awarię. Własny blog inżynierski OpenRouter przyznaje się do jakościowej strony tej zmienności: „Niektórzy dostawcy obsługują mocno skwantowane warianty modelu, które ustępują temu samemu modelowi hostowanemu gdzie indziej” (Jak działa routing modeli OpenRouter, opublikowany 2026-06-12). Nasze dane dodają wymiar behawioralny do tego obrazu: nie tylko ten sam model gorzej obsłużony, ale także wyjściowe rozumowanie obecne lub nieobecne za stabilnym identyfikatorem.

Loteria identyfikatora modelu

To jest nazwana koncepcja i mentalny model, który teraz stosujemy do każdej integracji bramowej: kiedy jeden identyfikator modelu load-balansuje między dostawcami z różnymi konfiguracjami obsługi, każdy request jest losowaniem, a wydrukowana nazwa na kuponie jest najmniej informacyjną rzeczą o nim**. Identyfikator modelu mówi Ci rodzinę wag. Nie mówi Ci o kwantyzacji, rozkładzie latencji, czy wyjściowe rozumowanie się pojawi, ani czy parametry, które oznaczyłeś jako wymagane, zostaną odzwierciedlone w tym, co otrzymasz. Te są własnościami trójki (model, dostawca, dzień), a dwie z trzech zmiennych są poza Twoim plikiem konfiguracyjnym.

Przenośna lista kontrolna

Jeśli routujesz ruch LLM przez jakąkolwiek wielodostawczą bramę, nie tylko OpenRouter:

• Rejestruj wyjściowe metryki behawioralne jako pierwszorzędowe. Znaki lub tokeny rozumowania na request, wraz z latencją, powiązane z raportowanym dostawcą obsługującym. Zachowanie, które nie jest mierzone na request, może zniknąć bez czyjejkolwiek wiedzy. Ustaw alerty na zapadanie w produkcji, nie tylko w ocenie.
• Traktuj flagi routingu i parametrów jako wskazówki, dopóki nie potwierdzisz ich względem wyjścia. Wyślij request, który wymaga danej możliwości, następnie sprawdź, który dostawca go obsłużył i czy możliwość rzeczywiście pojawiła się w odpowiedzi.
• Zanim wyciągniesz wniosek „ten model nie umie X”, przypnij znanego dobrego dostawcę i przeprowadź A/B test flagi. Nasz request był prawidłowy przez cały czas; zmienną był endpoint obsługujący. Bez przypiętej weryfikacji obwinilibyśmy model.
• Ponownie próbkuj routing w odstępach godzin i dni, nie w jednej sesji. Dziesięć na dziesięć do jednego dostawcy we wtorek to próbka, nie własność. Nasze oscylacje pojawiły się dopiero między rundami oddzielonymi dniami.
• Różnicuj za pomocą trudnych promptów i raportuj rozkłady. Nasze dziesięć łatwych promptów wyprodukowało odpowiedzi, których nie mogliśmy sensownie ocenić; dopiero pięć trudnych promptów rozdzieliło jakość odpowiedzi między konfiguracjami, a mediany ukryły ogon 178-sekundowy. Kolumna „max” to miejsce, gdzie żyją nie nadające się do wdrożenia konfiguracje.
• Jeśli zachowanie deterministyczne ma znaczenie, przypnij dostawcę i ponownie weryfikuj według harmonogramu. Przypinanie rezygnuje z failover i czasami z latencji. Dla regulowanej dziedziny to często właściwy kompromis.

Ograniczenia

To jest jedna ocena: 186 wywołań, 5 do 10 promptów na konfigurację, na naszym zestawie promptów zgodnościowych, rozpoczętych 2026-04-22 z finałowymi rundami w kolejnych dniach (rejestrowaliśmy datę oceny, nie znaczniki czasowe rund). Każda liczba tutaj to nasz własny pomiar na naszych własnych zadaniach w tym oknie, nie roszczenie dotyczące obecnego zachowania, konfiguracji lub intencji jakiegokolwiek sprzedawcy. Identyfikatory modeli to publiczne identyfikatory bramowe, jak żądane w momencie; nie rejestrowaliśmy niezależnie rewizji leżących u podstaw modeli. Wdrożenia dostawców, logika routingu OpenRouter i dokumentacja, którą cytujemy (dostępna 2026-07-15), mogły ulec zmianie od tamtej pory. Obserwacja dotycząca require_parameters dotyczy jednego modelu na jednej parze dostawców; nie przeprowadziliśmy przeglądu katalogu. Zero strumieniowanych znaków rozumowania oznacza jedynie, że rozumowanie nie zostało udostępnione w odpowiedzi — nic więcej. Rozmiary prób są wystarczające dla naszej decyzji o wdrożeniu, kierunkowe dla Twojej. W co jesteśmy pewni, to mechanizm: kiedy zachowanie obsługi zmienia się per dostawca za stabilnym identyfikatorem, jedyną możliwością, którą faktycznie posiadasz, jest ta, którą zmierzyłeś na wyjściu.

Identyfikator modelu w Twojej konfiguracji to nazwa dla rozkładu. Zmierz losowania.