O drugiej czterdzieści nad ranem grupa alertów monitoringu zaczęła się zapełniać wiadomościami. Wspieraliśmy technicznie zespół budujący system obsługi klienta dla e-commerce transgranicznego; wskaźnik przekroczeń czasu ich API inteligentnej obsługi klienta wzrósł z codziennych 0,3% aż do 27% i utrzymywał się przez prawie godzinę. Po stronie użytkownika wyglądało to tak: bot obsługi klienta nie odpowiadał przez długi czas, a konsultanci musieli tymczasowo przełączyć się na tryb ręczny.
Po analizie okazało się, że problem nie leżał w naszym kodzie, lecz po stronieupstream — klaster inferencyjny jednego dostawcy modeli doświadczył w tym czasie regionalnego ograniczenia przepustowości. Wszystkie nasze żądania trafiały do jednego dostawcy, bez żadnej alternatywy. W tym artykule opisuję wyczerpująco tamtą awarię i późniejsze rozwiązania modernizacyjne, jakoodniesienie dla kolegów z branży pracujących nad korporacyjną integracją AI.
Trzy pułapki zależności od jednego punktu — przeszliśmy przez wszystkie
Wiele osób myśli, że integracja z API modeli wielkoskalowych to po prostu wypełnienie klucza i wysłanie żądania HTTP. W środowisku produkcyjnym pułapki koncentrują się w trzech miejscach.
Pierwsza to ograniczenia przepustowości. Kwoty QPS dostawcy są przydzielane na poziomie konta; podczas dużych promocji wolumen sesji obsługi klienta wzrósł trzykrotnie, kwota natychmiast się wyczerpała i zwracano 429. Nie zaimplementowaliśmy wtedy kolejkowania żądań ani wycofywania, a logika ponowień była zbyt agresywna, co dodatkowo potęgowało obciążenie.
Druga to przekroczenia czasu. Gdy interfejs strumieniowy (SSE) utknie po stronieupstream, połączenie pozostaje zawieszone przez długi czas bez zwrotu, a klient może tylko czekać. W tamtej awarii znaczna część żądań nie kończyła się błędem, lecz była „pozornie żywa" — połączenie TCP wciąż istniało, ale nie wydobywał się ani jeden token.
Trzecia to różnice protokołów. Różni dostawcy mają odmienne formaty zwracania strumieniowego, znaczniki zakończenia i definicje kodów błędów. Struktura zdarzeń SSE w API GPT-4o i API Claude jest inna, a krajowe API Qwen i API DeepSeek mają własne pola. Jeśli kod biznesowy bezpośrednio integruje wielu dostawców, sam sobie zakopuje stertę if-else.
Rozwiązanie routingu wielu modeli: klasyfikacja, degradacja, normalizacja, agregacja
Po awarii przeprowadziliśmy rundę modernizacji; główna idea polegała na wprowadzeniu warstwy bramy modeli, która wyciąga kwestię „do którego modelu skierować żądanie" z kodu biznesowego.
Klasyfikacja żądań to pierwszy krok. Podzieliliśmy żądania według istotności biznesowej na trzy poziomy: klasa rozmów w czasie rzeczywistym (obsługa klienta, asystent konsultanta) wymaga opóźnienia P99 poniżej 2 sekund; klasa generowania wsadowego (opisy produktów, szkice e-maili) może tolerować poziom minutowy; klasa zadań offline (adnotacja danych, streszczenia raportów) jest całkowicie asynchroniczna. Dopiero po klasyfikacji strategia routingu ma podstawę.
Automatyczna degradacja przy awarii to drugi krok. Dla każdego modelu konfigurujemy kontrole kondycji; gdy kolejne błędy lub przekroczenia czasu przekroczą próg, model jest automatycznie wyłączany, a ruch przełączany na model zapasowy. Przyjęliśmy próg zadziałania przy wskaźniku błędów powyżej 5% w oknie przesuwnym, z interwałem sondowania przywrócenia 30 sekund. Należy tu przypomnieć: degradacja nie polega na bezmyślnym przełączaniu, trzeba uwzględnić typ zadania — w scenariuszach obsługi klienta przełączenie na model o zbliżonych możliwościach jest akceptowalne, ale zadania wymagające złożonego rozumowania po degradacji należy oznaczyć i później zweryfikować ręcznie.
Normalizacja protokołu SSE to trzeci krok i najbardziej pracochłonny. Na warstwie bramy ujednoliciliśmy format wyjścia strumieniowego; strona biznesowa rozpoznaje tylko jedną strukturę zdarzeń, a tłumaczeniem zajmuje się brama niezależnie od tego, z którym dostawcą się łączy. Dzięki temu zmiana modelu nie wymaga modyfikacji kodu biznesowego.
Agregacja zużycia to czwarty krok. Po wdrożeniu wywołań wielu modeli rozliczanie tokenów i statystyki zużycia muszą mieć jednolity standard, inaczej pod koniec miesiąca uzgadnianie faktur doprowadzi do szału. Brama agreguje według trzech wymiarów: najemcy, modelu i typu zadania, i generuje jednolity rachunek.
Później ulepszyliśmy strategię routingu do „automatycznego wyboru optymalnego modelu według zadania" — proste pytania i odpowiedzi kierowane są do tańszych małych modeli, złożone rozumowanie do modeli o większych możliwościach, generowanie kodu do modeli specjalizowanych. Po uruchomieniu tej logiki ogólny koszt wywołań spadł, a odpowiedzi stały się stabilniejsze. W tle opiera się to w rzeczywistości na zdolnościach harmonogramowania po stronie mocy obliczeniowej; mechanizmy takie jak zielone harmonogramowanie mocy obliczeniowej i elastyczne udostępnianie GPU na żądanie pozwalają uniknąć sytuacji, w której zasoby inferencyjne w godzinach szczytu czekają w kolejce w nieskończoność.
O granicach strategii routingu — kilka szczerych uwag
Nie każdy zespół potrzebuje multi-model multi-active. Jeśli dzienny wolumen wywołań wynosi tylko kilkadziesiąt tysięcy, biznes nie jest wrażliwy na opóźnienia, a budżet wystarczający, to wystarczy uczciwie podłączyć jednego dostawcę i dobrze obsłużyć ponowienia oraz przekroczenia czasu; złożoność związana z multi-active wręcz spowalnia iterację.
Prawdziwe scenariusze wartości routingu wielu modeli to: wolumen wywołań tak duży, że grozi ograniczeniem przepustowości, biznes o twardych wymaganiach dostępności, albo potrzeba dynamicznego balansowania między kosztem a jakością. Kryterium oceny jest proste — czy przekroczenia czasu API kiedykolwiek wpłynęły na użytkowników końcowych? Jeśli tak, to ta warstwa bramy jest warta zbudowania.
W naszym projekcie korzystaliśmy również z platformy agregującej API modeli wielkoskalowych token8341 do jednolitej integracji wielu modeli; jednym kluczem można wywoływać GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao i inne wiodące modele, z kompatybilnością z OpenAI SDK — wystarczy zmienić jedną linię base_url, aby przełączyć. Rozwiązuje ona właśnie opisane powyżej problemy normalizacji protokołów i agregacji zużycia, oszczędzając kłopot utrzymywania wielu zestawów SDK na własną rękę. Dla zespołów, które nie chcą budować bramy od zera, rozwiązanie agregacji API AI typu token8341 jest opcją do rozważenia.
Na koniec jedna uwaga: platforma agregująca API modeli wielkoskalowych token8341 dość kompletnie pokrywa modele krajowe — Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark są dostępne, co ułatwia projekty związane ze zgodnością z inicjatywąrodzima innowacja. Ale narzędzie to w końcu narzędzie; sposób projektowania strategii routingu i ustalania progów degradacji nadal trzeba dostroić do własnych danych biznesowych. Najbardziej konkretną lekcją, jakiej nauczyła nas tamta nocna awaria, jest to: dostępności nie da się kupić — ją projektuje się warstwa po warstwie.
Autor: Sun Haoran
Data publikacji: 12 listopada 2026