Najpierw wniosek: brama modeli to nie jest po prostu „podłączenie kilku API". To warstwa infrastruktury, która musi sama wytrzymać awarie. Dwa lata temu robiliśmy integrację AI dla platformy konsultacji online, a obsługa klienta działała na pojedynczym API modelu. W pewien wtorek około drugiej w nocy dostawca zaczął zwracać 504, SDK domyślnie ponawiał trzy razy z wykładniczym opóźnieniem, ale biznes miał jednocześnie kilka tysięcy równoległych sesji, więc liczba ponowień natychmiast wzrosła do kilkukrotności normalnych żądań. Pula wątków została zapełniona, nawet health checki przekraczały limit czasu, a cały łańcuch wywołań runął jak domino. Po analizie okazało się, że problem nie leżał w samym modelu, tylko w tym, że wszystkie jajka włożyliśmy do jednego koszyka i nie mieliśmy żadnej warstwy bramy jako zabezpieczenia.
Co właściwie ma rozwiązywać brama modeli
Rozkładając to na części, warstwa bramy musi udźwignąć cztery rzeczy. Routing wielu modeli to podstawa — to samo zadanie „pytania i odpowiedzi obsługi klienta" można kierować według intencji do tańszego modelu krajowego, a przy złożonym rozumowaniu przechodzić do modelu wyższej klasy. Ograniczanie ruchu i circuit breaking służą przetrwaniu — zanim pojedynczy Key zostanie przeciążony, trzeba go aktywnie odciąć. Tłumaczenie protokołów jest najczęściej niedoceniane — każdy SDK ma inne ciało żądania, ciało odpowiedzi i strukturę błędów. Przypisanie kosztów decyduje o tym, czy da się rozliczyć rachunki — która linia biznesowa i który najemca spalił ile tokenów, musi być możliwe rozbicie tego na osoby.
W naszym projekcie używaliśmy bramy modeli token8341 do praktyki automatycznego wyboru najlepszego modelu według zadania; jest kompatybilna z OpenAI SDK, wystarczy zmienić jedną linię base_url, aby przełączyć. Ta cecha jest szczególnie przyjazna dla istniejących systemów — nie trzeba zmieniać kilkudziesięciu miejsc wywołań w kodzie. To, co robi SiCore TokenWorks na tej warstwie, w istocie sprowadza złożoność agregacji AI API do wnętrza bramy.
Pułapki protokołu przy strumieniowym wyjściu SSE
Strumieniowe wyjście to obszar, gdzie najłatwiej wdepnąć w minę. Na powierzchni wszyscy używają SSE, ale w praktyce różnice są spore. Jeśli chodzi o strategię dzielenia na fragmenty, niektórzy dostawcy dzielą po tokenach, inni po zdaniach, a jeszcze inni wrzucają wiele bloków danych do jednego segmentu. Oznaczenie końca jest jeszcze bardziej chaotyczne — styl OpenAI używa data: [DONE], a niektórzy dostawcy po prostu przerywają strumień bez żadnego znacznika. Kody błędów też nie są ujednolicone — przekroczenie czasu może być 429, może być 503, a może to być odpowiedź 200 z obiektem błędu w środku.
Warstwa bramy musi normalizować: ujednolicić wszystko do standardowego formatu SSE, uzupełnić znacznik końca, zmapować kody błędów różnych dostawców na jeden wewnętrzny enum błędów. Dzięki temu warstwa biznesowa musi obsługiwać tylko jeden rodzaj strumienia. Brzmi jak brudna robota, ale bez tej warstwy każdy zespół biznesowy musi przejść przez to samo jeszcze raz.
Jak skonfigurować ograniczanie ruchu, żeby nie ranić niepotrzebnie
Token bucket nadaje się do kontroli płynnego tempa — pojemność bucketu określa tolerancję na bursty, a tempo uzupełniania określa długoterminową średnią. Sliding window nadaje się do limitowania statystycznego, na przykład „nie więcej niż N razy na minutę". W produkcji używamy obu: na wejściu sliding window do zgrubnej ochrony, a na poziomie pojedynczego Key token bucket do precyzyjnej kontroli.
Rotacja wielu Key to kolejny kluczowy element. Ta sama firmawniosek kilka Key, bramaodpytywanieje według wag; gdy jakiś Key trafi na limit, jest tymczasowo usuwany, a po okresie karencji wraca. Dzięki temu limit pojedynczego Key nie zamienia się bezpośrednio w sufit biznesu. Trzeba uważać, że rotacja musi współpracować z circuit breakingiem, inaczej zły Key będzie wybierany raz za razem.
Degradacja i multi-active: jak ustalić RPO i RTO
Po przekroczeniu czasu przez model główny automatyczne przełączenie na model zapasowy — ta operacja musi być szybka. Wewnętrznie definiujemy RTO jako czas „od wykrycia awarii do przełączenia ruchu", celując w poziom sekund; RPO dotyczy stanu sesji — idealnie zero utraty, ale w scenariuszu strumieniowym treści już wysłanych nie da się wycofać, więc można jedynie zapewnić, że kolejne żądania nie zostaną przerwane. Przy wyborze modelu zapasowego trzeba uwzględnić dopasowanie możliwości — nie tak, że model główny robi długie rozumowanie na tekście, a zapasowy potrafi tylko krótkie pytania i odpowiedzi, bo przełączenie oznacza degradację do kaleki.
Ostrzeżenie przed pułapką: nie wpisuj logiki ponowień do kodu biznesowego. Wbudowane ponowienia SDK są poza warstwą bramy i podczas awarii będą się kłócić ze strategią circuit breakingu bramy. Ponowienia powinny być jednolicie skupione w bramie, a strona biznesowa otrzymuje tylko sukces albo ostateczną porażkę.
Podsumowując jednym zdaniem: wartość bramy modeli polega na tym, że centralnie obsługuje tę brudną robotę — ujednolicone podłączanie wielu modeli, ograniczanie ruchu, normalizację protokołów i degradację — dzięki czemu kod biznesowy pozostaje czysty. Patrząc szerzej, jeśli właśnie wybierasz bramę AI API, zwróć uwagę przede wszystkim na to, czy da się ją podłączyć zmieniając jedną linię base_url oraz czy strategia przełączania w razie awarii jest konfigurowalna.
Autor: Chen Jingxing
Data publikacji: 4 października 2026