Jak zaprojektować rezerwy LLM bez zrywania umów dotyczących opóźnień, kosztów i wyników

Zastępcza lista to nie tylko lista modeli zapasowych. W przypadku zespołów inżynierskich korzystających z kilku dostawców LLM rezerwa to zasada routingu, która decyduje, kiedy żądanie może zostać przeniesione od jednego dostawcy lub modelu do innego, co musi pozostać niezmienione i w jaki sposób system udowadnia, że ​​alternatywna ścieżka uczyniła aplikację bardziej niezawodną.

Problem z czytnikiem jest zwykle prosty: ogranicza liczbę nieudanych żądań i mniejsze opóźnienia bez cichej zmiany jakości wyjściowej, ważności schematu, bezpieczeństwa lub kosztów. Rozwiązanie jest bardziej szczegółowe niż „wypróbuj innego dostawcę”. Niezawodna strategia zastępcza LLM wymaga klasyfikacji błędów, terminów żądań, zasad zgodności modeli, limitów kosztów, wyłączników automatycznych i obserwowalności na poziomie dostawcy i trasy.

Zacznij od zasad zastępczych, a nie kodu ponownych prób

Ponowne próby i powrót awaryjny rozwiązują różne problemy. Ponowna próba prosi tego samego dostawcę o wykonanie tego samego żądania po przejściowym niepowodzeniu. W przypadku rozwiązania awaryjnego inny model, dostawca, region lub trasa ma zamiast tego dokończyć pracę. Połączenie tych obaw powoduje powstanie systemów, które trudno uzasadnić podczas incydentów.

Fakt: Wytyczne dotyczące niezawodności dostarczane przez dostawców infrastruktury chmurowej często zalecają ograniczone wykładnicze wycofywanie, wahania, maksymalne limity ponownych prób, sprawdzanie idempotencji i unikanie ponownych prób na wielu warstwach, ponieważ burze ponownych prób mogą pogorszyć przeciążenie. Główni dostawcy LLM dokumentują także błędy przejściowe, limity szybkości, odpowiedzi na przeciążenia, przekroczenia limitu czasu i SDK zachowanie podczas ponownych prób.

Zalecenie: zaimplementuj jedną warstwę ponownych prób dla każdej ścieżki żądania. Jeśli brama aplikacji ponawia próbę, usługi podrzędne nie powinny również ponawiać niezależnych prób, chyba że własność ponowienia próby jest wyraźna. Każda ponowna próba powinna zająć ten sam termin wywołującego, a nie tworzyć nowego nieograniczonego limitu czasu.

Minimalne zasady powinny odpowiadać na następujące pytania przed napisaniem jakiegokolwiek kodu:

• Które niepowodzenia można powtórzyć u tego samego dostawcy?
• Które awarie umożliwiają powrót do innego dostawcy lub modelu?
• Które awarie nie mogą nigdy zostać wywołane awaria?
• Jaka umowa wyjściowa musi pozostać taka sama?
• Jaki jest maksymalny dozwolony wzrost kosztów?
• Jaka część terminu żądania może upłynąć, zanim rezerwa zostanie zabroniona?
• Która telemetria potwierdza, czy rezerwa awaryjna pomogła, czy ukryła defekt?

Klasyfikacja błędów przed trasowaniem Im

Reakcja awaryjna jest niebezpieczna, gdy każda non-200 odpowiedź jest traktowana tak samo. Limit czasu dostawcy nie jest tym samym, co źle sformułowane żądanie. Limit prędkości to nie to samo, co odmowa ze względów bezpieczeństwa.Błąd sprawdzania poprawności danych wyjściowych nie jest tym samym, co awaria sieci.

Praktyczna taksonomia powinna obejmować co najmniej następujące klasy:

• Błąd transportu możliwy do ponownej próby: reset połączenia, problem z DNS, tymczasowa awaria sieci lub przekroczenie limitu czasu bramy.
• Przeciążenie dostawcy: udokumentowane przeciążenie lub stan przejściowy po stronie serwera błąd.
• Limit szybkości: żądanie, token, przyspieszenie lub limit tempa przydziału, zwłaszcza gdy podana jest wartość Retry-After.
• Limit czasu dostawcy: dostawca zaakceptował żądanie, ale nie ukończył go w oknie usługi.
• Nieprawidłowy żądanie: zniekształcony ładunek, nieobsługiwany parametr, nieprawidłowy schemat lub opcja niezgodna z modelem.
• Błąd uwierzytelnienia lub konfiguracji: zły klucz, wyłączone konto, brak uprawnień lub wyczerpany limit na poziomie konta.
• Odmowa lub blokada ze względów bezpieczeństwa: dostawca celowo odrzuca lub blokuje treści na podstawie polityka bezpieczeństwa.
• Błąd sprawdzania poprawności danych wyjściowych: model odpowiedział, ale odpowiedź nie spełnia warunków kontraktu aplikacji.

Zalecenie: ponawiaj tylko przejściowe błędy w ramach budżetu opóźnienia obiektu wywołującego. Zezwalaj na powrót tylko w przypadku klas błędów, które zostały wyraźnie zatwierdzone przez zespoły ds. produktu i platformy. Nie polegaj na błędach uwierzytelniania, źle sformułowanych żądaniach, błędach w schemacie deterministycznym ani odmowach dotyczących bezpieczeństwa, chyba że produkt definiuje konkretne alternatywne bezpieczne zachowanie.

To rozróżnienie ma znaczenie, ponieważ w przeciwnym razie rezerwa może ukryć błędy. Jeśli schemat jest nieprawidłowy dla głównego dostawcy i zdarza się, że zostanie zignorowany przez dostawcę rezerwowego, system może wyglądać na zdrowszy, zwracając mniej ograniczone dane wyjściowe. To nie jest niezawodność; to dryf kontraktu.

Stosuj terminy, a nie tylko limity czasu

Problemy z opóźnieniami końcowymi często wynikają z ponownych prób, które są ograniczone technicznie, ale praktycznie zbyt wolne. Żądanie z 15-sekundowym budżetem przeznaczonym dla użytkownika nie powinno kończyć się niepowodzeniem na trasie głównej przez 14 sekund, a następnie rozpoczynać pełną próbę zastępczą, której nie można ukończyć w odpowiednim czasie.

Użyj terminu ostatecznego żądania, który przechodzi przez cały stos. Każda decyzja dotycząca routingu powinna sprawdzić pozostały czas, zanim zostanie podjęta ponownie lub cofnięta. Na przykład:

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Dokładne liczby zależą od obciążenia. Trasa zakończenia czatu może zarezerwować wystarczającą ilość czasu dla jednego alternatywnego modelu. Zadanie wyodrębniania w tle może umożliwiać wiele prób. Ścieżka autouzupełniania w czasie rzeczywistym może preferować szybką awarię zamiast późnej odpowiedzi zastępczej.

Zalecenie: zdefiniuj budżety opóźnień według klasy trasy, a nie globalnie. Trasa interfejsu użytkownika o niskim opóźnieniu, trasa klasyfikacji wsadowej i trasa analizy długiego kontekstu nie powinny dzielić tej samej koperty ponawiania i powrotu.

Definiuj klasy modelu według obciążenia

Nazwy dostawców nie są dobrą abstrakcją w przypadku rozwiązań awaryjnych. Aplikacja uwzględnia właściwości obciążenia: długość kontekstu, głębokość wnioskowania, obsługę narzędzi, zachowanie strukturalnych danych wyjściowych, opóźnienia, ograniczenia obsługi danych i koszt.Trasy awaryjne powinny być zorganizowane wokół tych właściwości.

Przydatne klasy modeli obejmują:

• Szybka wersja robocza: krótkie odpowiedzi, małe opóźnienia, umiarkowana tolerancja jakości.
• Ekstrakcja strukturalna: ścisłe JSON dane wyjściowe, walidacja schematu, niska tolerancja formatu dryf.
• Rozumowanie: analiza wieloetapowa, wyższe wymagania jakościowe, większe akceptowalne opóźnienia.
• Długi kontekst: duże dokumenty, okna o wysokim tokenze, ostrożne zasady obcinania.
• Tania praca wsadowa: zadania asynchroniczne lub niepilne zoptymalizowane pod kątem ekonomia jednostkowa.
• Eskalacja premium: drogie, ale wydajne modele używane tylko wtedy, gdy pozwalają na to zasady.

Dla każdej klasy wypisz dozwolone modele podstawowe, dozwolone modele awaryjne i zabronione ścieżki obniżenia wersji. Żądanie o długim kontekście nie powinno opierać się na modelu o krótkim kontekście, który dyskretnie obcina monit. Ustrukturyzowane zadanie ekstrakcji nie powinno opierać się na modelu, który nie jest w stanie spełnić ograniczeń schematu. Zadanie polegające na wnioskowaniu premium może pozwolić na powrót do innego modelu premium, ale nie do modelu z szybką wersją roboczą, chyba że doświadczenie użytkownika wyraźnie wspiera gorszą odpowiedź.

W przypadku zespołów tworzących przedsiębiorstwo LLM API klasy te powinny znajdować się w danych konfiguracyjnych lub zasadach, a nie być rozproszone pomiędzy usługami aplikacji. Dzięki temu zachowanie routingu jest możliwe do sprawdzenia i łatwiejsze do zmiany w przypadku incydentów dostawcy.

Chroń kontrakty dotyczące ustrukturyzowanych wyników

Awaryjna rezerwa na uporządkowane dane wyjściowe to jedno z najłatwiejszych miejsc do tworzenia subtelnych błędów produkcyjnych. Dostawcy różnią się sposobem obsługi trybu JSON, schematu JSON, wywołań narzędzi, pól odmowy, informacji zwrotnych dotyczących bezpieczeństwa, przyczyn zakończenia i podzbiorów schematu. Nie ma gwarancji, że schemat, który działa z jednym modelem, będzie można przenieść do innego.

Fakt: Niektóre dokumentacje dostawców opisują ścisłe przestrzeganie schematu dla obsługiwanych modeli, podczas gdy inna dokumentacja zauważa obsługę tylko podzbioru JSON schematu. Odpowiedzi dostawcy mogą także zawierać pola odmowy, informacje zwrotne dotyczące monitu, oceny bezpieczeństwa, przyczyny zakończenia lub brak kandydatów, gdy monit jest zablokowany lub nieprawidłowy.

Zalecenie: traktuj weryfikację wyników jako część trasy, a nie opcjonalną kwestię osoby dzwoniącej. Brama powinna sprawdzić ostateczną odpowiedź przed zwróceniem jej do aplikacji. Jeśli weryfikacja się nie powiedzie, trasa powinna sklasyfikować niepowodzenie i zdecydować, czy dozwolona jest próba rozwiązania awaryjnego.

Istnieją dwa wykonalne wzorce:

Użyj przenośnego podzbioru schematu

Trzymaj schematy w miejscu przecięcia funkcji obsługiwanych przez zatwierdzonych dostawców zastępczych. Poprawia to przenośność i zmniejsza złożoność operacyjną. Kompromis jest taki, że możesz utracić bogatsze ograniczenia specyficzne dla dostawcy.

Użyj adapterów schematu specyficznych dla dostawcy

Utrzymuj adaptery, które tłumaczą kontrakt aplikacji na format schematu obsługiwany przez każdego dostawcę. Zachowuje to wydajność, ale zwiększa obciążenie związane z testowaniem i konserwacją.Wymaga to również macierzy zgodności, aby inżynierowie wiedzieli, które trasy mogą bezpiecznie powrócić.

Podstawowy zapis zgodności może wyglądać następująco:

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Zalecenie: nigdy nie zwracaj wyjściowych danych wyjściowych tylko dlatego, że jest to poprawnie sformułowany tekst. Zwróć ją dopiero wtedy, gdy spełni warunki umowy na poziomie aplikacji oczekiwanej w przypadku trasy głównej.

Kontroluj koszty przed wystąpieniem incydentów

Zasilanie awaryjne często powoduje przeniesienie ruchu do droższych modeli dokładnie w momencie, gdy ruch jest zwiększony lub pogarsza się jakość dostawcy. Bez kontroli kosztów mechanizm niezawodności może stać się incydentem związanym z wydatkami.

Ustaw reguły rezerwowe, które obejmują:

• Maksymalny mnożnik ceny rezerwowej na trasę.
• Dozwolone poziomy modeli według organizacji, obszaru roboczego lub środowiska.
• Dzienne lub godzinne wydatki rezerwowe budżety.
• Oddzielne zasady dla obciążeń interaktywnych i wsadowych.
• Zasady określające, czy rezerwa może przekraczać granice dostawcy, regionu lub rodziny modeli.

Zalecenie: mierz koszt udanej odpowiedzi, a nie tylko koszt pierwotnego żądania. Droższe rozwiązanie awaryjne może być uzasadnione, jeśli zapobiega widocznej przez użytkownika awarii na trasie krytycznej. To samo rozwiązanie awaryjne może być niedopuszczalne w przypadku pracy wsadowej o niskim priorytecie.

Polityka kosztowa powinna być również widoczna dla organizacji korzystających z platformy. Zespoły mogą chcieć zezwolić na rezerwową wersję premium dla produkcyjnych przepływów pracy obsługi klienta, blokując ją na potrzeby programowania, testowania lub wewnętrznych eksperymentów. To decyzja dotycząca zarządzania, a nie tylko decyzja o routingu.

Dodaj wyłączniki automatyczne według dostawcy, modelu, regionu i klasy błędu

Naiwne przywracanie sieci zastępczej może zaszkodzić zdegradowanemu dostawcy. Każde nieudane żądanie podstawowe wyzwala kolejną próbę podstawową, a następnie kolejną próbę awaryjną, podczas gdy inne usługi robią to samo. Wyłączniki automatyczne zmniejszają powtarzające się ciśnienie i sprawiają, że zachowanie routingu jest bardziej przewidywalne.

Wyłącznik automatyczny powinien być na tyle konkretny, aby uniknąć nadmiernej reakcji. Nie oznaczaj całego dostawcy w złej kondycji, ponieważ jeden model w jednym regionie zwraca niepowodzenia ustrukturyzowanych danych wyjściowych. Śledź stan według dostawcy, modelu, regionu, trasy i klasy błędu, jeśli to możliwe.

Dla wielu zespołów wystarczy prosta maszyna do sprawdzania stanu wyłącznika:

• Zamknięte: normalny ruch na trasie.
• Otwarte: trasa jest chwilowo omijana po przekroczeniu progów błędu przekroczony.
• Półotwarty: ograniczone testowanie ruchu próbnego przywrócenie ruchu przed wznowieniem pełnego ruchu.

Progi powinny uwzględniać głośność. Dziesięć awarii na minutę może mieć znaczenie w przypadku trasy o niskim natężeniu ruchu, ale nie ma znaczenia w przypadku trasy obsługującej tysiące żądań na minutę. Używaj minimalnych rozmiarów próbek, ruchomych okien i filtrów klas błędów.

Zalecenie: wyłączniki automatyczne powinny nie tylko zliczać HTTP awarie. Powinni także oddzielnie śledzić błędy sprawdzania poprawności danych wyjściowych, wskaźniki przekroczeń limitu czasu, wskaźniki limitów szybkości oraz wzorce odmów lub bloków. Klasy te implikują różne reakcje operacyjne.

Zapisuj decyzję o routingu, a nie tylko błąd końcowy

Przywrócenie działania awaryjnego poprawiające wygodę użytkownika może w dalszym ciągu utrudniać diagnozowanie incydentów.Jeśli dzienniki wskazują tylko ostatecznego, skutecznego dostawcę, inżynierowie tracą dowód na to, że główny dostawca zawiódł.

Każde żądanie powinno rejestrować:

• Oryginalnego dostawcę, model i trasę.
• Zastępczego dostawcę, model i trasę, jeśli są używane.
• Klasę błędu, która wyzwoliła ponowną próbę lub powrót.
• Identyfikatory żądań dostawcy, gdy dostępne.
• Liczba ponownych prób i czas wycofywania.
• Termin upływający przed każdą próbą.
• Wynik walidacji danych wyjściowych.
• Szacowany koszt każdej próby i koszt końcowy.
• Czy ostateczna odpowiedź pochodzi z jednostki podstawowej czy rezerwowej.
• Organizacja, obszar roboczy, środowisko, i metadane aplikacji, jeśli pozwalają na to zasady.

Ta telemetria obsługuje zarówno zarządzanie inżynieryjne, jak i komercyjne. Łączy także zachowanie awaryjne z kontrolą kosztów AI API, gdy różne zespoły, produkty lub klienci mają różne zasady niezawodności i budżetu.

Zmierz, czy rozwiązanie awaryjne faktycznie pomogło

Surowy wskaźnik sukcesu nie wystarczy. Strategia rezerwowa może zwiększyć końcowe 200 odpowiedzi, jednocześnie pogarszając opóźnienie p99, podwajając koszt lub zwracając mniej prawidłowe ustrukturyzowane dane wyjściowe.

Zmierz przynajmniej te wskaźniki według trasy:

• Główny wskaźnik sukcesu.
• Ostateczny wskaźnik powodzenia po ponownej próbie i powrocie.
• p50, Opóźnienie p95 i p99 przed i po powrocie.
• Współczynnik wywołań awaryjnych.
• Koszt na pomyślną odpowiedź.
• Współczynnik odpowiedzi zgodny z umową.
• Współczynnik odmów ze względów bezpieczeństwa lub współczynnik blokowania przez dostawcę.
• Sygnały regresji jakości ze specyficznych dla aplikacji ocena.

Prognoza: w miarę jak coraz więcej firm korzysta z infrastruktury LLM obejmującej wielu dostawców, zasady awaryjne będą bardziej przypominać inżynierię ruchu, a nie doraźną obsługę wyjątków.Zespoły będą oczekiwać kontroli zasad według obszaru roboczego, środowiska i klasy obciążenia, wraz z dziennikami kontroli wyjaśniającymi, dlaczego wybrano model.

Lista kontrolna implementacji

Skorzystaj z tej listy kontrolnej przed włączeniem powrotu na trasę produkcyjną:

• Określ budżet opóźnień trasy i termin żądania.
• Sklasyfikuj błędy dostawcy na możliwe do ponowienia, kwalifikujące się do przywrócenia awaryjnego i klasy terminali.
• Udokumentuj, które awarie nie mogą powodować powrotu do pracy awaryjnej.
• Wyświetl listę zatwierdzonych modeli podstawowych i awaryjnych według klasy obciążenia.
• Sprawdź długość kontekstu, obsługę narzędzi, obsługę schematu i zachowanie bezpieczeństwa dla każdego błędu awaryjnego.
• Sprawdź każdą ostateczną odpowiedź pod kątem kontraktu aplikacji.
• Ustaw maksymalną liczbę ponownych prób, obsługa wycofywania, wahań i ponownych prób.
• Skonfiguruj wyłączniki automatyczne według dostawcy, modelu, regionu i klasy błędu.
• Ustaw mnożniki kosztów i limity wydatków na rezerwę.
• Rejestruj identyfikatory żądań, klasy błędów, próby, wyniki sprawdzania poprawności, opóźnienia i koszty.
• Przejrzyj opóźnienia p95 i p99 po wdrożenie, a nie tylko średnie opóźnienie.
• Przerwa w dostawie testów, limit szybkości, nieprawidłowy schemat, odmowa bezpieczeństwa i scenariusze niepowodzenia sprawdzania poprawności danych wyjściowych.

Wniosek, który można zastosować

Dobra strategia rezerwowa LLM to regulowana polityka routingu. Oddziela ponowne próby od awarii, precyzyjnie klasyfikuje awarie, zachowuje kontrakty wyjściowe, dotrzymuje terminów opóźnień i uwidacznia koszty, zanim wystąpią incydenty.

Kluczową zasadą projektowania jest niezmienność. Zdecyduj, co musi pozostać prawdziwe, gdy ruch zostanie przeniesiony z modelu podstawowego do modelu awaryjnego: ważność schematu, zachowanie bezpieczeństwa, obsługa kontekstu, obsługa narzędzi, limity kosztów i obserwowalność. Następnie zezwól na powrót awaryjny tylko wtedy, gdy można zachować te niezmienniki.

Zacznij od jednej trasy o dużej wartości, a nie globalnego przełącznika awaryjnego. Zdefiniuj taksonomię błędów, kompatybilne modele awaryjne, zasady walidacji, wyłączniki automatyczne i metryki. Przeprowadź ćwiczenia w przypadku awarii na tej trasie. Jeśli ostateczny wskaźnik powodzenia poprawi się bez niedopuszczalnych opóźnień p99, utraty odpowiedzi ważnej w umowie lub wzrostu kosztów, rozszerz zasady do następnej klasy obciążenia.

Powiązana lektura

• alokacja wydatków LLM według zespołu i aplikacji