Kiedy udane żądanie nadal jest porażką
Wyobraź sobie, że od tygodni rozmawiasz z tą samą postacią. Jej głos jest znajomy, język spójny, a odpowiedzi bystre i pełne życia.
Nagle, mimo że nie zmieniasz ani postaci, ani modelu, coś zaczyna być nie tak.
Kolejna odpowiedź potrzebuje dziesięciu sekund, by się rozpocząć. Funkcja zależna od structured output przestaje działać. Postać zaczyna mówić bez sensu, wtrąca fragmenty innego języka lub odpowiada w stylu, który wygląda jak wynik znacznie słabszego modelu.
Z perspektywy serwera nic nie zawiodło. API zwróciło 200 OK, tokeny dotarły, a żądanie zostało rozliczone.
Z perspektywy użytkownika model właśnie stał się gorszy.
Ta różnica jest powodem, dla którego zbudowaliśmy dla Reverie system sond canary dostawców i kwarantanny routingu.
Jedna nazwa modelu, wiele środowisk inference
OpenRouter jest naszą główną bramą do modeli. Jedną z jego zalet jest to, że ten sam model może być obsługiwany przez wielu niezależnych dostawców inference. Jeśli jeden jest niedostępny, inny może przejąć żądanie. Daje nam to większą moc, konkurencyjne ceny i lepszą odporność niż zależność od pojedynczego endpointu.
Wprowadza to jednak również niewidoczną zmienną.
Nazwa modelu może pozostać taka sama, podczas gdy infrastruktura obsługująca go zmienia się między żądaniami. Każdy dostawca może używać innego silnika inference, sprzętu, poziomu quantization, parsera, chat template, kolejki lub dodatkowej warstwy polityk.
Dokumentacja routingu dostawców OpenRouter wyjaśnia, że domyślny routing bierze pod uwagę niedawną dostępność i cenę, zachowując innych dostawców jako fallback. To ważne sygnały, lecz endpoint może być dostępny, tani, a mimo to generować wynik nieakceptowalny dla konkretnego produktu.
OpenRouter publicznie opisał także mierzalne różnice między dostawcami obsługującymi ten sam model. Teoretycznie identyczne weights przy tej samej precyzji powinny zachowywać się podobnie. W środowisku produkcyjnym obsługa dużego modelu jest złożona i pojawiają się różnice.
Co rozumiemy przez „degradację modelu”
„Degradacja modelu” nie jest jedną ustandaryzowaną diagnozą. Nie oznacza też automatycznie, że dostawca celowo podmienił model na mniejszy.
Używamy tego terminu operacyjnie: endpoint inference uległ degradacji, jeżeli na reprezentatywnych promptach nie zachowuje już zachowania, możliwości lub wydajności interaktywnej oczekiwanych od żądanego modelu, nawet jeśli samo żądanie technicznie zakończyło się sukcesem.
Dla Reverie najwyraźniejsze formy to:
- Degradacja opóźnienia: połączenie jest udane, ale czas do pierwszego tokenu staje się na tyle długi, że psuje wrażenie rozmowy na żywo.
- Degradacja możliwości: endpoint, który powinien obsługiwać structured output, zwraca źle sformatowany tekst lub przestaje spełniać schema.
- Degradacja zachowania: odpowiedzi są uszkodzone, niespójne, nieoczekiwanie powtarzalne albo wyraźnie przechodzą na inny język.
- Niezgodność polityk: host upstream dodaje własną warstwę filtrowania, zmieniając scenę obsługiwaną przez Reverie w odmowę, pustą odpowiedź lub ucięty tekst.
Przyczyn może być wiele. Quantization o niższej precyzji może wpływać na trudne prompty, co wskazują zarówno dokumentacja OpenRouter, jak i opublikowane badania nad quantization. Nie jest to jednak uniwersalne wyjaśnienie: błędy silnika inference i tool parserów, problemy tokenizerów lub chat template, przeciążone kolejki i middleware dostawcy mogą być równie ważne. OpenRouter zaobserwował, że przy wywołaniach narzędzi implementacje parserów często powodują większe różnice niż sama precyzja.
Ważne pytanie nie brzmi „która przyczyna wydaje się najbardziej podejrzana?”, lecz „czy możemy odizolować endpoint i odtworzyć awarię?”.
Dwa przypadki, które uczyniły problem namacalnym
Nie była to dla nas kwestia czysto teoretyczna.
W porównaniu przypiętym do konkretnych dostawców jeden z nich uszkodził początek 19 z 20 odpowiedzi, wstawiając znak interpunkcyjny lub fragment niezwiązanego tokenu. Na czternastu innych hostach tego samego modelu problem pojawił się 0 razy w 49 odpowiedziach. W roleplayu pierwszy znak często jest znacznikiem wyróżnienia Markdown, więc jeden obcy byte mógł zepsuć formatowanie całej odpowiedzi.
W innym teście jeden endpoint wytworzył poważną mieszankę portugalskiego i hiszpańskiego w 3 z 3 generacji. Ten sam prompt pozostał po portugalsku na oficjalnym hoście modelu i pozostałych testowanych hostach tej samej klasy precyzji. „Model jest po prostu niespójny” przestało być dobrym wyjaśnieniem — usterka podążała za endpointem.
Takie awarie są subtelne, ponieważ nie muszą powodować exception. Tradycyjny monitoring uptime widzi zdrowe API. Użytkownik widzi postać, która nagle nie potrafi prawidłowo mówić.
Nasza odpowiedź: testować każdą trasę, nie tylko model
Co trzydzieści minut nasz canary wykrywa aktywnych dostawców obsługujących domyślny model czatu Reverie. Następnie wysyła do każdego mały zestaw syntetycznych żądań, przypiętych wyłącznie do tego dostawcy, z wyłączonymi fallbackami.
Przypięcie jest kluczowe. Jeśli sonda może użyć fallbacku, drugi zdrowy dostawca ukryje awarię pierwszego. Musimy dokładnie wiedzieć, które środowisko inference wygenerowało wynik.
System sprawdza cztery wąskie kontrakty, które można ocenić za pomocą kodu.
1. Czas do pierwszego tokenu
W rozmowie streamingowej throughput stanowi tylko połowę doświadczenia. Pierwszy token decyduje, jak długo użytkownik patrzy na wskaźnik ładowania.
Mierzymy go bezpośrednio w streamie. Dostawca, który nie wygeneruje tekstu w ciągu dziesięciu sekund, nie przechodzi sondy opóźnienia. Próg jest celowo łagodny, a jedna powolna runda nie wystarcza do usunięcia hosta — chwilowe obciążenie kolejki się zdarza.
2. Filtrowanie i ciche odmowy
Wysyłamy stałą kontynuację roleplayu, reprezentatywną dla ruchu obsługiwanego przez Reverie. Sonda sprawdza powód zakończenia, wzorce odmowy o wysokiej pewności i pusty output.
Uruchamiamy ją również na hostach znanych z filtrowania, używając ich jako kontroli pozytywnej. Jeśli taka kontrola niespodziewanie przejdzie test, nie uznajemy wszystkich pozostałych dostawców za zdrowych — oznaczamy samą sondę jako słabą. Test, który nie wykrywa już znanej usterki, nie stanowi dowodu zdrowia.
3. Structured output
Żądamy małego obiektu o stałej schema i weryfikujemy wynik. Błąd transportu oraz źle sformatowany output traktujemy inaczej: zerwane połączenie oznacza, że dostawca był nieosiągalny, natomiast zakończona generacja niespełniająca schema świadczy o regresji możliwości.
„Endpoint deklaruje obsługę parametru” i „endpoint niezawodnie go przestrzega” nie są tą samą obietnicą.
4. Integralność języka
Reverie obsługuje 17 języków interfejsu, więc smoke test wyłącznie po angielsku pominąłby część usterek, których naprawdę doświadczają nasi użytkownicy.
Canary rotacyjnie sprawdza obsługiwane języki za pomocą syntetycznych promptów roleplay. Lokalny, deterministyczny detektor szuka wyraźnego przełączenia całej odpowiedzi na inny język, trwałego mieszania języków i oczywistych uszkodzeń kodowania. Nie używa prawdziwych rozmów ani nie prosi innego modelu o subiektywną ocenę.
Niejednoznaczny lub zbyt krótki output jest uznawany za nierozstrzygający, a nie wadliwy. Po wykryciu anomalii językowej canary natychmiast wykonuje dwie dodatkowe próby i wymaga większości. Ten sam język jest powtarzany w kolejnej rundzie, aby dostawca nie ominął zasady kolejnych rund tylko dlatego, że rotacja przesunęła się dalej.
System zaprojektowany tak, by nie ufał własnym wnioskom
Automatyczne usuwanie mocy inference jest przydatne, ale false positive może spowodować większą awarię niż pierwotna usterka. Dlatego canary ma kilka zabezpieczeń:
- Błędy transportu nie liczą się jako błędy jakości. Timeouty, rate limits i odpowiedzi 5xx zamrażają wynik zamiast rozwijać serię prowadzącą do suspension.
- Jedna zła runda nie wystarcza. Dostawca musi zawieść w dwóch kolejnych rundach wykonywanych co pół godziny.
- Obserwacja i egzekwowanie są rozdzielone. Możemy uruchomić system w trybie obserwacji, zapisać hosty, które zostałyby zawieszone, powiadomić administratorów i zmierzyć false positives przed włączeniem automatycznych działań.
- Moc ma dolną granicę. Canary nie zawiesi dostawcy, jeśli pozostawiłoby to mniej niż dwa hosty produkcyjne. Zamiast tego powiadomi administratora.
- Odzyskiwanie również jest testowane. Zawieszeni dostawcy nadal otrzymują sondy. Dwie kolejne czyste rundy przywracają hosta wcześniej.
- Powtarzające się awarie eskalują stopniowo. Pierwsze zawieszenie trwa jeden dzień, następne trzy dni, a kolejne siedem dni. Po czternastu dniach bez nowego zawieszenia historia wygasa i drabina zaczyna się od początku.
Celem nie jest karanie dostawców. Chcemy odsunąć ruch użytkowników od trasy, której niesprawność można odtworzyć, i pozostawić jasną drogę powrotu po usunięciu problemu.
Trzy warstwy ochrony
Ostateczna decyzja routingowa łączy trzy rodzaje wykluczeń:
- Przejrzane wykluczenia wbudowane dla zmierzonych usterek lub niezgodności polityk, których nie chcemy przypadkowo przywrócić.
- Wykluczenia incydentów w runtime, które administrator może dodać natychmiast bez oczekiwania na deployment.
- Czasowe zawieszenia canary dla dostawców przekraczających automatyczny próg błędów.
Podczas budowania żądania Reverie łączy te listy w ustawieniu OpenRouter provider.ignore. Użytkownik nie musi ponawiać próby, dopóki przypadek nie wybierze lepszego dostawcy; niesprawna trasa zostaje usunięta z kandydatów.
Każda automatyczna decyzja jest zapisywana, administratorzy otrzymują powiadomienia o istotnych zmianach stanu, a zawieszenie można w razie potrzeby usunąć ręcznie.
Co ten system gwarantuje — a czego nie
Canary jest celowo wąski. Kod może ocenić opóźnienie, poprawność schema, filtrowanie o wysokiej pewności, integralność języka i kodowania. Nie udaje, że potrafi ocenić, czy postać jest wystarczająco zabawna, emocjonalnie spostrzegawcza lub wierna złożonej osobowości.
Te szersze pytania nadal wymagają ewaluacji opartych na reprezentatywnych promptach, ludzkiego przeglądu, production telemetry i — co najważniejsze — zgłoszeń użytkowników.
System nie oznacza też, że każda dziwna odpowiedź dowodzi degradacji. Modele generatywne są probabilistyczne. Długa rozmowa może zgromadzić sprzeczny kontekst, a definicja postaci może zawierać konkurujące instrukcje. Czasem dziwna odpowiedź jest po prostu dziwną odpowiedzią.
Zmieniło się to, że stwierdzenie „to ten sam model” nie kończy już naszego dochodzenia. Możemy odizolować trasę, odtworzyć obiektywne awarie i trzymać późniejszy ruch z dala od niej.
Niezawodność oznacza zachowanie doświadczenia
Routing między wieloma dostawcami pozostaje wartościowy. Daje Reverie moc i odporność potrzebne, by rozmowy były dostępne, gdy poszczególne endpointy przestają działać.
Odporność nie oznacza jednak tylko otrzymania odpowiedzi HTTP. Odpowiedź, która zaczyna się zbyt późno, traci wymaganą strukturę, odrzuca obsługiwane treści lub nagle zmienia język, nie staje się zdrowa tylko dlatego, że faktura oznacza żądanie jako udane.
W produkcie z postaciami AI niezawodność ma bardziej ludzkie znaczenie: postać powinna nadal być sobą, niezależnie od tego, która maszyna akurat mówi w jej imieniu.
Właśnie tego standardu mają chronić nasze nowe zabezpieczenia routingu.
Jeśli zauważysz nagłą zmianę jakości lub języka odpowiedzi, prześlij nam zgłoszenie z nazwą modelu i przybliżonym czasem. Pomoże nam to połączyć Twoje doświadczenie z dokładną trasą, która je obsłużyła.