OpenRouter. Ten sam model różni się obsługą narzędzi u różnych dostawców

Mohamed Moustafa, twórca asystenta Olly działającego w iMessage, opublikował 7 września opis problemów napotkanych przy korzystaniu z OpenRouter. Żądania z tym samym identyfikatorem modelu trafiały do dostawców, którzy inaczej obsługiwali obrazy, parametry rozumowania i wywołania narzędzi. Dla aplikacji wykonującej kolejne kroki zadania zmiana dostawcy mogła oznaczać przerwanie pracy mimo poprawnej odpowiedzi HTTP.

OpenRouter udostępnia wspólne API do modeli uruchamianych przez różne firmy. Operatorzy mogą używać odmiennych konfiguracji obliczeń i oprogramowania przetwarzającego odpowiedź modelu. Nazwa modelu w żądaniu nie identyfikuje zatem całej konfiguracji, od której zależy zachowanie aplikacji.

Pusta odpowiedź i wywołanie narzędzia zapisane jako tekst

Moustafa opisuje przypadki, w których dostawca zwracał kod HTTP 200, ale pole content było puste, a odpowiedź nie zawierała wywołania narzędzia. W innych przypadkach zapis polecenia dla narzędzia trafiał do zwykłego tekstu zamiast do pola przeznaczonego dla aplikacji. Agent nie otrzymywał wtedy operacji w formacie, który potrafił wykonać.

Autor udostępnił także skrypt porównujący ustawienia low, high i max dla reasoning.effort, czyli żądanego nakładu rozumowania. Próba dla deepseek/deepseek-v4-flash-0731 używała jednego pytania, trzech powtórzeń każdego ustawienia, limitu 6000 tokenów i przypisanego dostawcy bez automatycznego przełączenia. Różne zużycie tokenów w tak małej próbie nie rozstrzyga, czy konkretny dostawca ignoruje parametr.

Domyślne kierowanie żądań uwzględnia również jakość narzędzi

Dokumentacja wyboru dostawcy dopuszcza wysłanie żądania do dostawcy, który nie obsługuje wszystkich podanych parametrów. Nieznane parametry mogą zostać zignorowane. Ustawienie provider.require_parameters: true wyklucza takich dostawców z wyboru. Sprawdza ono obsługę parametrów, nie poprawność wyniku zadania.

Przy żądaniach z narzędziami działa ponadto Auto Exacto. Funkcja domyślnie zmienia kolejność dostawców na podstawie przepustowości, wyników testów i błędów wywołań narzędzi. Opis OpenRouter jako usługi wybierającej wyłącznie najtańszy serwer pomija więc obecną konfigurację tych żądań.

Wskaźnik błędów sprawdza między innymi poprawność formatu argumentów, istnienie wskazanej nazwy narzędzia i zgodność argumentów z jego schematem. Nie mierzy, czy agent wybrał właściwą operację albo osiągnął cel użytkownika. Osobno Auto Exacto korzysta z testu wiedzy GPQA Diamond i zadań lotniczych Tau2-Bench. Wyniki są przypisane do konkretnych usług dostawców i agregowane w okresie 32 dni. To szersza kontrola niż sam kod odpowiedzi HTTP, ale nadal nie zastępuje sprawdzenia zachowania własnej aplikacji.

Niezależne pomiary wykrywają też błędy samego testu

ModelIndex, prowadzony przez MapleHill Labs, porównuje podstawowe funkcje usług: zgodność ze schematem danych, instrukcjami, obsługę narzędzi i odszukiwanie informacji w długim wejściu. Autorzy zaznaczają, że te tanie kontrole mogą ujawnić błędną konfigurację usługi, lecz nie są rankingiem inteligencji modeli. Nie potwierdzają też identyczności wag i ustawień u wszystkich dostawców.

Ich własny test początkowo przyznawał zbyt mały budżet odpowiedzi modelom rozumującym. Część zużywała go przed wygenerowaniem widocznego tekstu; zwiększenie limitu usuwało wiele pozornych porażek. Dlatego pustą odpowiedź trzeba badać razem z limitem tokenów i przyczyną zakończenia generacji. Sam objaw nie pozwala przypisać winy dostawcy.

Oddzielny pomiar BenchLM z 1 września wykazał z kolei, że podobne nazwy DeepSeek Flash u różnych pośredników wskazywały różne wydania modelu. Ten wynik dotyczy porównania platform, a nie dostawców wewnątrz jednego żądania OpenRouter. Uzupełnia jednak problem opisany przez Moustafę: przed zestawieniem wyników trzeba ustalić zarówno wersję modelu, jak i usługę, która go uruchomiła. BenchLM sprzedaje monitoring i deklaruje brak relacji afiliacyjnych z ocenianymi platformami.

Wybór dostawcy i warunki uznania odpowiedzi za poprawną

OpenRouter pozwala ograniczyć żądanie do listy provider.only. Pole provider.order określa kolejność prób, a allow_fallbacks: false wyłącza przechodzenie do dostawców spoza tej listy. Ograniczenie wyboru ułatwia powtarzalne pomiary, ale zostawia mniej możliwości obsłużenia żądania podczas awarii. Obsługę parametrów można dodatkowo wymusić przez require_parameters.

W aplikacji agentowej warto osobno rejestrować brak treści, brak poprawnego wywołania narzędzia, wyczerpanie budżetu tokenów i błąd HTTP. Do oceny dostawcy potrzebne są próby obejmujące rzeczywistą historię rozmowy, obrazy i narzędzia używane przez aplikację. Zmiana usługodawcy w środku zadania powinna być widoczna w logach, aby nie przypisywać modelowi różnicy wynikającej z obsługi jego odpowiedzi.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.