# Modele zapasowe dla agentów AI: jak zapewnić działanie agenta po awarii modelu

> Jak działają modele zapasowe agentów AI, które błędy powinny uruchamiać fallback, dlaczego model zapasowy zachowuje się inaczej i jak przetestować go przed awarią.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/pl/blog/ai-agent-backup-models

*Ostatnia aktualizacja: wrzesień 2026 r. Strony statusu, raporty incydentów i dokumentacja sprawdzone 28 września 2026 r.*

**Model Twojego agenta prędzej czy później zawiedzie, a model zapasowy skonfigurowany na taką sytuację nie zachowa się tak jak model, na którym przeprowadzono testy.** 28 września 2026 r. strona statusu Claude API pokazywała dostępność na poziomie 99,52% w ciągu poprzednich 90 dni. Brzmi niemal idealnie — dopóki nie wykonasz obliczeń: 0,48% z 90 dni to odpowiednik około 10 godzin ograniczonej dostępności lub niedostępności usługi w ciągu kwartału. Model zapasowy agenta AI pozwala agentowi działać także w tych godzinach. Jeśli skonfigurujesz go niedbale, zadanie po cichu wykona się tylko częściowo na modelu, którego nikt wcześniej nie sprawdził.

Ten poradnik jest przeznaczony dla właścicieli firm i osób zarządzających, które uruchamiają agentów według harmonogramu lub udostępniają ich klientom. Omawiamy w nim typowe awarie, błędy, które powinny uruchamiać przełączenie, sposób obsługi takich sytuacji przez najpopularniejsze narzędzia routingu oraz metody sprawdzenia, czy fallback działa, zanim będzie potrzebny.

- **Z zewnątrz trzy różne awarie wyglądają podobnie:** niedostępność usługi, limity zapytań i wycofane modele. Tylko niektóre z tych sytuacji wymagają modelu zapasowego
- **Najpierw ponów próbę, dopiero potem przełącz model.** Wiele problemów znika po krótkim ponowieniu żądania lub przełączeniu na innego hosta obsługującego ten sam model
- **Model zapasowy nie jest kopią działającą na zasadzie plug-and-play.** Nowsze modele odrzucają parametry akceptowane przez starsze, inaczej obsługują wywołania narzędzi, a rozgrzana pamięć podręczna promptu znika
- **Fallbacki kosztują więcej na każdy krok, niż można się spodziewać,** ponieważ model zapasowy zaczyna z pustą pamięcią podręczną
- **Nieprzetestowany fallback to tylko zgadywanie.** Wymuś awarię, uruchom na modelu zapasowym rzeczywiste zadania i rejestruj, który model udzielił odpowiedzi

## Czym jest model zapasowy agenta AI

Model zapasowy agenta AI, często nazywany fallbackiem LLM, to drugi model skonfigurowany z wyprzedzeniem, aby przejąć działanie, gdy główny model agenta nie może udzielić odpowiedzi. Przełączenie zwykle odbywa się automatycznie: router lub gateway wykrywa błąd, wysyła to samo żądanie do kolejnego modelu na liście i zwraca odpowiedź tak, jakby nic się nie wydarzyło.

To jedna z czterech warstw ochrony. Powinna być trzecią opcją, po którą sięgasz, a nie pierwszą:

| Warstwa | Działanie | Rozwiązuje | Zmienia model? |
|---|---|---|---|
| **Ponowienie** | Wysyła to samo żądanie ponownie po krótkim oczekiwaniu | Krótkie skoki obciążenia, pojedyncze przekroczenia limitu czasu | Nie |
| **Przełączenie hosta** | Wysyła żądanie do innego dostawcy obsługującego ten sam model | Awaria jednego centrum danych lub hosta | Nie |
| **Fallback modelu** | Wysyła żądanie do innego modelu | Całkowita niedostępność usługi, wyczerpane limity | Tak |
| **Planowana migracja** | Celowo przenosi agenta na nowy model | Wycofanie modelu i zakończenie jego wsparcia | Tak, na stałe |

Kolejność ma znaczenie, ponieważ każdy kolejny krok w tabeli bardziej zmienia sposób działania agenta. Ponowienie nie zmienia niczego. Inny model zmienia niemal wszystko, co pokażemy w dalszej części.

## Trzy sposoby awarii głównego modelu

### Niedostępność usług

Każdy większy dostawca doświadczył takich awarii, a raporty z incydentów są publiczne. 11 grudnia 2024 r. [wszystkie usługi OpenAI były znacząco ograniczone lub niedostępne](https://status.openai.com/incidents/ctrsv3lwd797) od 15:16 do 19:38 czasu pacyficznego — łącznie przez 4 godziny i 22 minuty. Problem dotyczył ChatGPT, API i Sora. Przyczyną była nowa usługa telemetryczna, która przeciążyła płaszczyznę sterowania Kubernetes w OpenAI. Błąd występował tylko w dużych klastrach, dlatego testy go nie wykryły.

![Incydent na stronie statusu OpenAI z 11 grudnia 2024 r., oznaczony jako rozwiązany i całkowita awaria; pokazuje 9 dotkniętych komponentów API oraz 5 dotkniętych komponentów ChatGPT z czerwonymi i bursztynowymi paskami statusu](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Krótsze incydenty są znacznie częstsze. 4 marca 2026 r. OpenAI odnotowało [30 minut podwyższonej liczby błędów API](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up) po jednoczesnym wykonaniu partii opóźnionych zmian w zakresie przepustowości, które wyłączyły silniki wnioskowania z obsługi. Strona statusu Anthropic pokazuje ten sam wzorzec: długie okresy oznaczone na zielono z regularnie pojawiającymi się krótkimi dniami czerwonymi i bursztynowymi.

![Strona statusu Claude pokazująca stan „Wszystkie systemy działają” oraz 90-dniowe paski dostępności: claude.ai — 99,43%, Claude Console — 99,95%, Claude API — 99,52%](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

30-minutowa awaria prawie nie ma znaczenia podczas rozmowy. Ma ogromne znaczenie, gdy w tym czasie uruchamia się zaplanowane zadanie, bo nikogo nie ma wtedy przy klawiaturze, aby ponowić próbę.

### Limity zapytań i błędy 429

Błąd 429 oznacza, że dostawca działa, ale w tej chwili nie obsłuży Twojego żądania. Najczęściej chodzi o limit liczby żądań w danej minucie: API Anthropic korzysta z [wiadra tokenów, które stale się uzupełnia](https://platform.claude.com/docs/en/api/rate-limits), i wysyła nagłówek `retry-after` informujący, ile sekund należy odczekać. W takiej sytuacji właściwym rozwiązaniem jest odczekanie wskazanego czasu i ponowienie próby z użyciem tego samego modelu.

Nie każdy błąd 429 jest jednak tymczasowy. Gdy organizacja Anthropic osiągnie miesięczny limit wydatków, API zwraca błąd 429 **bez** nagłówka `retry-after`, a dokumentacja mówi wprost: „Ponowienie próby, w tym automatyczne ponowienia wykonywane przez SDK, nie powiedzie się do czasu przywrócenia dostępu”. Dostęp wraca na początku kolejnego miesiąca. Agent, który traktuje każdy błąd 429 jako „odczekaj i ponów”, może próbować całą noc, mimo że limit nie zostanie zresetowany przez kilka tygodni.

### Wycofanie i zakończenie obsługi modeli

Modele są wycofywane zgodnie z harmonogramem, a wycofany model nie przechodzi łagodnie w stan niedostępności. [Polityka wycofywania modeli Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) gwarantuje co najmniej 60 dni wyprzedzenia w przypadku modeli udostępnionych publicznie i stwierdza, że „żądania kierowane do modeli po dacie wycofania zakończą się niepowodzeniem”. Niedawnym przykładem jest Claude Opus 4.1: deweloperów powiadomiono 5 czerwca 2026 r., a model wycofano 5 sierpnia 2026 r.

![Strona dokumentacji Claude Platform dotycząca wycofywania modeli, wyjaśniająca etapy cyklu życia: aktywny, starszy, przestarzały i wycofany; zawiera ostrzeżenie, że przestarzałe modele prawdopodobnie będą mniej niezawodne niż aktywne](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

[Strona OpenAI dotycząca wycofywania modeli](https://developers.openai.com/api/docs/deprecations) zapewnia modelom ogólnie dostępnym co najmniej sześć miesięcy wyprzedzenia, ale modele w wersji preview „mogą zostać wycofane ze znacznie krótszym wyprzedzeniem, na przykład 2 tygodni”. W czerwcu 2026 r. OpenAI ogłosiło, że snapshoty GPT-5 i o3 zostaną wyłączone 11 grudnia 2026 r. Model zapasowy nie rozwiązuje problemu wycofania. Ukrywa go tylko do czasu nadejścia daty wycofania samego modelu zapasowego.

### Awaria, której nie wykryje żaden fallback

Najbardziej kosztowna awaria nigdy nie zgłasza błędu. W 2025 r. Anthropic opublikowało [analizę poawaryjną trzech błędów infrastruktury](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues), które przez kilka tygodni pogarszały odpowiedzi Claude. W najgorszej godzinie jeden z nich dotknął 16% żądań kierowanych do Sonnet 4. Jednym z powodów, dla których tak długo trwało znalezienie problemu, było to, że „Claude często dobrze radzi sobie z pojedynczymi błędami”, przez co problem pozostawał niezauważony.

Żaden łańcuch fallbacków nie zareaguje na gorszą odpowiedź, ponieważ gorsza odpowiedź nadal może zwrócić kod 200. Do tego służą [wyrywkowe kontrole wyników generowanych przez agenta](/pl/blog/human-in-the-loop-ai-agents), a nie routing.

## Które awarie powinny uruchamiać model zapasowy agenta AI

Zanim zareagujesz, odczytaj błąd. To samo stwierdzenie „model nie zadziałał” może oznaczać: odczekaj pięć sekund, przełącz teraz albo popraw własne żądanie.

![Pięć awarii dostawcy i właściwa reakcja na każdą z nich: odczekaj i ponów przy błędzie 429 z nagłówkiem retry-after, przełącz na model zapasowy przy błędzie 429 bez retry-after, ponów, zmień hosta, a następnie przełącz model przy błędach 5xx lub przekroczeniu limitu czasu, popraw żądanie przy błędzie 400 i wypromuj zastępstwo przed datą wycofania](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

Dwa wiersze wymagają bliższego omówienia:

- **Błędy 5xx, przeciążenie i przekroczenie limitu czasu.** [Dokumentacja błędów Anthropic](https://platform.claude.com/docs/en/api/errors) wymienia błąd 529 `overloaded_error` przy dużym ruchu u wszystkich użytkowników, a SDK automatycznie ponawia przejściowe błędy dwa razy z wykładniczym zwiększaniem odstępów. Jeszcze jedno ponowienie jest w porządku. Pięć ponowień zamienia 30-sekundowy problem w 10-minutowe zatrzymanie
- **Błędy 400.** Nieprawidłowy parametr lub źle sformatowane żądanie zakończy się błędem także na modelu zapasowym, często z tego samego powodu. Wyjątkiem jest zbyt długi prompt: niektóre routery kierują go zamiast tego do modelu z większym oknem kontekstu — to przykład fallbacku, który rzeczywiście pomaga

## Jak działają łańcuchy fallbacków i routing

Rzadko trzeba samodzielnie budować logikę fallbacku. Zajmuje się tym warstwa routingu między agentem a dostawcami. Najczęściej spotyka się cztery rozwiązania:

| Narzędzie | Konfiguracja modelu zapasowego | Co uruchamia przełączenie | Jak sprawdzić, który model odpowiedział |
|---|---|---|---|
| **OpenRouter** | Tablica `models` uporządkowana według priorytetu | Niedostępność, limity zapytań, błędy długości kontekstu, flagi moderacji | Pole `model` w odpowiedzi |
| **LiteLLM** | `fallbacks` oraz osobne fallbacki dla okna kontekstu i zasad treści | Limity zapytań i błędy serwera, z przerwami po kolejnych awariach | Logi proxy i callbacki |
| **Vercel AI Gateway** | Tablica `models` połączona z dostawcą `order` | Każda awaria wszystkich dostawców danego modelu | Lista `modelAttempts` w metadanych dostawcy |
| **Cloudflare AI Gateway** | Lista kroków na endpointcie Universal | Błędy i przekroczenia limitu czasu żądania | Nagłówek odpowiedzi `cf-aig-step` |

[Fallbacki modeli w OpenRouter](https://openrouter.ai/docs/guides/routing/model-fallbacks) najłatwiej sobie wyobrazić: przekazujesz listę identyfikatorów modeli, a „jeśli pierwszy model zwróci błąd, OpenRouter automatycznie spróbuje użyć kolejnego modelu z listy”. Opłata za żądanie jest naliczana według ceny modelu, który ostatecznie odpowiedział. Niezależnie od tego [routing dostawcy](https://openrouter.ai/docs/guides/routing/provider-selection) obsługuje przełączenie hosta dla tego samego modelu. Domyślnie preferowani są dostawcy, którzy „nie odnotowali znaczących awarii w ciągu ostatnich 30 sekund”, a `allow_fallbacks` pozostaje włączone, dopóki go nie wyłączysz.

![Strona dokumentacji OpenRouter dotycząca fallbacków modeli, wyjaśniająca, że parametr models automatycznie próbuje użyć innych modeli, jeśli dostawcy głównego modelu są niedostępni, objęci limitem lub odmawiają odpowiedzi](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

[Ustawienia niezawodności LiteLLM](https://docs.litellm.ai/docs/proxy/reliability) dzielą ten problem bardziej szczegółowo. Standardowe `fallbacks` obsługują limity zapytań i błędy serwera, `context_window_fallbacks` kierują zbyt długi prompt do większego modelu, a `content_policy_fallbacks` przechwytują błędy zasad treści. `allowed_fails` i `cooldown_time` tymczasowo wyłączają zawodny model z rotacji, dzięki czemu przeciążony dostawca nie jest obciążany przy każdym żądaniu.

[Fallbacki modeli w Vercel AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) łączą obie warstwy: narzędzie próbuje użyć każdego dozwolonego dostawcy głównego modelu, następnie przechodzi do kolejnego modelu w tablicy `models` i rejestruje każdą próbę. [Fallbacki Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) działają na endpoincie Universal i w nagłówku informują, skąd pochodzi odpowiedź: `cf-aig-step: 0` oznacza odpowiedź głównego modelu, a `1` — odpowiedź pierwszego modelu zapasowego.

Jedno zastrzeżenie dotyczy wszystkich czterech rozwiązań. **Gateway sam również jest zależnością.** Własna sieć Cloudflare doświadczyła poważnej awarii [18 listopada 2025 r.](https://blog.cloudflare.com/18-november-2025-outage/) — od 11:20 do 17:06 UTC — po tym, jak nieprawidłowy plik konfiguracyjny rozprzestrzenił się w całej infrastrukturze. Łańcuch fallbacków chroni przed awarią dostawcy modelu. Nie chroni jednak przed awarią warstwy, która obsługuje ten łańcuch.

## Dlaczego model zapasowy agenta AI zachowuje się inaczej

Fallback, który zwraca odpowiedź, niekoniecznie wykonał zadanie. Agenci są pod tym względem bardziej wrażliwi niż chatboty, ponieważ w chwili przełączenia agent znajduje się w środku wieloetapowego zadania i ma za sobą długą historię wywołań narzędzi, którą nowy model musi przejąć.

![Co zmienia się po przełączeniu agenta między modelami: przejście na ten sam model u innego hosta zachowuje działanie promptu, format wywołań narzędzi, parametry i okno kontekstu, natomiast nowszy model tego samego dostawcy lub model innego dostawcy zmienia większość z tych elementów; każde przełączenie powoduje utratę rozgrzanej pamięci podręcznej promptu](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Parametry akceptowane przez jeden model, ale odrzucane przez inny

Ten problem występuje nawet w obrębie jednego dostawcy. Zgodnie z [informacjami Anthropic o wycofywaniu modeli](https://platform.claude.com/docs/en/about-claude/model-deprecations) i [dokumentacją błędów](https://platform.claude.com/docs/en/api/errors):

- Ustawienie `temperature`, `top_p` lub `top_k` na wartość inną niż domyślna zwraca błąd 400 w Claude Opus 4.7 i nowszych
- Wymuszenie konkretnego narzędzia za pomocą `tool_choice` zwraca błąd 400 w Claude Opus 5.5, Sonnet 5.5 i Fable 5.1
- Wstępne uzupełnienie początku odpowiedzi asystenta zwraca błąd 400 w Claude 4.6 i nowszych modelach

Łańcuch, który przełącza się ze starszego modelu na nowszy, „lepszy” model, może więc natychmiast zakończyć się błędem, którego główny model nigdy nie zwrócił. Opcja `require_parameters` w [OpenRouter](https://openrouter.ai/docs/guides/routing/provider-selection) istnieje częściowo właśnie z tego powodu: kieruje żądanie tylko do dostawców obsługujących wszystkie przesłane parametry.

### Wywołania narzędzi i prompty

Różni dostawcy oczekują narzędzi, wyników i danych dotyczących rozumowania w różnych formatach, dlatego fallback między dostawcami zależy od prawidłowego przetłumaczenia rozmowy przez gateway. Nawet jeśli format zostanie zachowany, model zapasowy nie jest modelem, na którym dostrajano instrukcje. Może wywoływać narzędzia w innej kolejności, kończyć pracę wcześniej albo rozumieć polecenie „odpowiadaj zwięźle” jako „pomiń sprawdzenie”. Niektóre dane dotyczące rozumowania w ogóle nie są przekazywane: Anthropic informuje, że blok thinking „pochodzący z modelu, którego model docelowy nie potrafi odczytać, jest usuwany”.

### Okna kontekstu

Jeśli model zapasowy obsługuje mniejszy kontekst niż model główny, długa sesja agenta może okazać się dla niego zbyt obszerna w chwili przejęcia zadania. Dlatego OpenRouter wymienia błędy długości kontekstu jako wyzwalacz fallbacku, a LiteLLM udostępnia dla nich osobną listę fallbacków. Umieść w łańcuchu model zapasowy z oknem kontekstu co najmniej tak dużym jak w modelu głównym albo przed przełączeniem każ agentowi skrócić starszą historię.

## Ile kosztują fallbacki

Model zapasowy zmienia wysokość rachunku na trzy sposoby — i żadnego z nich nie widać w tabeli cenowej.

**Rozgrzana pamięć podręczna znika.** Caching promptów w dużej mierze decyduje o tym, że agenci pozostają przystępni cenowo: instrukcje, definicje narzędzi i historia są wysyłane ponownie przy każdym kroku i w większości rozliczane według stawki dla danych w pamięci podręcznej. Pamięci podręczne są powiązane z konkretnym modelem u konkretnego dostawcy, dlatego OpenRouter korzysta ze [sticky routing](https://openrouter.ai/docs/guides/best-practices/prompt-caching), aby „kierować kolejne żądania do tego samego endpointu dostawcy po żądaniu obsłużonym z użyciem pamięci podręcznej”. Po przełączeniu kolejny krok kosztuje pełną stawkę. Przy [cenie katalogowej Claude Sonnet 5.5](https://platform.claude.com/docs/en/about-claude/pricing) wynoszącej 2,00 USD za milion tokenów wejściowych i 0,20 USD za tokeny z pamięci podręcznej historia agenta zawierająca 50 000 tokenów kosztuje około 0,01 USD przy ponownym wysłaniu z pamięci podręcznej i około 0,10 USD bez niej. To dziesięciokrotnie więcej za każdy krok, dopóki pamięć podręczna modelu zapasowego się nie rozgrzeje.

**Płacisz za model, który odpowiedział, według jego własnych tokenów.** OpenRouter rozlicza model, który ostatecznie udzielił odpowiedzi, więc fallback do droższego modelu kosztuje więcej. Tańszy model zapasowy, który potrzebuje dodatkowych kroków, również może okazać się droższy. Liczby tokenów nie są przenośne: [strona cenowa Anthropic](https://platform.claude.com/docs/en/about-claude/pricing) informuje, że modele Claude 4.7 i nowsze korzystają z nowszego tokenizera, który generuje około 30% więcej tokenów dla tego samego tekstu.

**Ponowienia również są płatne.** Żądanie, które kończy się niepowodzeniem w połowie strumienia, często zdążyło już wygenerować płatne tokeny, a każde ponowienie ponownie wysyła cały kontekst. Opisaliśmy ten mechanizm w artykule [Koszty działania agentów AI](/pl/blog/ai-agent-running-costs): nieudane uruchomienia i pętle tworzą długi ogon kosztów, który może przekroczyć średnią.

Żaden z tych argumentów nie przemawia przeciwko modelom zapasowym. Przemawia za tym, aby rzeczywiście pozostawały zapasowe — z ponowieniami i przełączeniem hosta obsługującymi codzienne błędy, tak aby kosztowne przełączenie modelu następowało tylko podczas prawdziwych awarii.

## Przetestuj fallback, zanim będzie potrzebny

Większość łańcuchów fallbacków jest uruchamiana po raz pierwszy podczas incydentu — czyli w najgorszym możliwym momencie, aby odkryć, że model zapasowy nie potrafi wywoływać narzędzi. Krótkie ćwiczenie raz na kwartał i po każdej zmianie modelu pozwala wykryć większość problemów:

1. **Wymuś awarię.** Skieruj główny model do nieistniejącego identyfikatora albo użyj przełącznika testowego routera. LiteLLM udostępnia w SDK funkcję `mock_testing_fallbacks=True` i zaleca wywołanie rzeczywistego błędu dostawcy w środowisku nieprodukcyjnym dla proxy
2. **Uruchom rzeczywiste zadania, nie prompt typu „hello world”.** Wybierz trzy lub cztery faktyczne zadania agenta, w tym jedno długie zadanie intensywnie korzystające z narzędzi, i pozwól modelowi zapasowemu wykonać je w całości
3. **Porównaj wyniki.** Czy model wywołał te same narzędzia, zakończył pracę w tym samym miejscu i przestrzegał zasad formatowania? Czytaj transkrypcje, nie tylko końcową odpowiedź
4. **Potwierdź, który model odpowiedział.** Sprawdź pole `model` w odpowiedzi, `modelAttempts` lub nagłówek `cf-aig-step`. Ćwiczenie, podczas którego po cichu odpowiedział model główny, niczego nie dowodzi
5. **Ustaw alerty dla fallbacków.** Model zapasowy uruchamiany codziennie przestaje być zapasowy. Staje się Twoim rzeczywistym modelem, nieprzetestowanym przy takiej skali użycia — i warto o tym wiedzieć
6. **Wpisz daty wycofania do kalendarza.** Sprawdzaj strony dotyczące wycofywania zarówno głównego, jak i zapasowego modelu, a na model zastępczy przechodź długo przed którąkolwiek z tych dat

W przypadku zadań uruchamianych według harmonogramu połącz to z planem obsługi uruchomienia, które mimo wszystko zakończy się niepowodzeniem. Nasz poradnik [Jak planować cykliczne zadania agentów AI](/pl/blog/schedule-recurring-ai-agent-tasks) wyjaśnia, jak wygląda prawidłowa obsługa błędu: częściowy wynik, prosty komunikat i zadanie, które samo się zatrzymuje zamiast ponawiać próbę w nieskończoność.

## Jak agent Crevio obsługuje awarie modeli

[Crevio](https://crevio.co/) to narzędzie AI do budowania biznesu: opisujesz, co chcesz sprzedawać, a agent tworzy, uruchamia i obsługuje związane z tym działania. Crevio wybiera modele dla agenta i uruchamia je za Ciebie, więc nie musisz zarządzać kontami dostawców, kluczami ani wersjami modeli. Poniżej wyjaśniamy prostymi słowami, co dzieje się podczas nieprawidłowego działania modelu — również czego Crevio jeszcze nie robi.

**Co robi obecnie:**

- **Automatycznie ponawia próbę z użyciem tego samego modelu.** Gdy wywołanie modelu kończy się przeciążeniem, limitem zapytań, błędem serwera, przekroczeniem limitu czasu lub odpowiedzią przerwaną w połowie strumienia, agent ponawia próbę maksymalnie trzy razy, za każdym razem czekając nieco dłużej — około 2, 4 i 8 sekund. Błędy, których ponowienie nie może naprawić, takie jak nieprawidłowo sformatowane żądanie, nie są ponawiane
- **Omija hosta, na którym właśnie wystąpiła awaria.** W przypadku modeli, które mogą być obsługiwane przez więcej niż jednego hosta, ponowienie po błędzie hosta pomija hosta, który go zwrócił
- **Skraca długie rozmowy.** Jeśli rozmowa przekroczy zakres, który model potrafi odczytać, agent podsumowuje starszą historię i próbuje jeszcze raz zamiast się zatrzymać
- **Sprawdza listę modeli przy każdym wydaniu.** Przy każdej aktualizacji Crevio potwierdza, że wszystkie modele, od których zależy agent, są nadal oferowane. Jeśli któregoś zabraknie, wydanie zostaje oznaczone jako nieudane

![Formularz nowego zadania w Crevio dotyczący codziennego porannego podsumowania sprzedaży; instrukcje wymagają wskazania niedostępnego źródła danych, zadanie ma powtarzać się codziennie, a opcja Notify via jest ustawiona na powiadomienie w aplikacji i e-mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Co dzieje się, gdy to nie wystarczy:** nieudane uruchomienie zaplanowanego zadania jest zgłaszane za pośrednictwem kanałów określonych w ustawieniu **Notify via**, wraz z informacją o wykonanych działaniach i przyczynie problemu. Domyślnie zadanie cykliczne wyłącza się po trzech kolejnych nieudanych uruchomieniach i informuje Cię o tym, zamiast każdego ranka po cichu kończyć się błędem. W czacie na żywo odpowiedź, która wyczerpie limit ponowień, po prostu się zatrzymuje — wtedy należy wysłać wiadomość ponownie.

**Czego jeszcze nie robi:** agent Crevio nie przełącza automatycznie na inny model w trakcie zadania, gdy główny model jest niedostępny. Obecnie ochrona obejmuje ponowienia i przełączenie hosta w ramach tego samego modelu. Nie możesz też wybrać modelu agenta ani podłączyć własnego klucza dostawcy. Jeśli potrzebujesz ręcznie dostrojonego łańcucha fallbacków między dostawcami, narzędzie routingu z powyższej tabeli, uruchomione we własnym stosie, zapewni Ci taką kontrolę.

[Crevio](https://crevio.co/) możesz zacząć używać bezpłatnie, a plan Starter obejmuje 20 kredytów AI miesięcznie.

## FAQ

### Czy potrzebuję modelu zapasowego, jeśli już korzystam z gatewaya AI?

Gateway to miejsce, w którym konfigurujesz model zapasowy — sam gateway nim nie jest. Niektóre gatewaye samodzielnie ponawiają próbę lub przełączają między hostami tego samego modelu, ale fallback modelu nastąpi tylko wtedy, gdy dodasz model do listy. Gateway tworzy też własną zależność, dlatego sprawdź, jak zachowywał się podczas wcześniejszych incydentów.

### Czy model zapasowy agenta AI powinien pochodzić od innego dostawcy?

W przypadku awarii — tak. Model zapasowy od tego samego dostawcy często przestaje działać podczas tego samego incydentu. W przypadku limitów zapytań wystarczyć może drugi model tego samego dostawcy, ponieważ limity są zwykle ustalane dla każdego modelu osobno. Kompromisem jest zgodność: im bardziej model zapasowy różni się od głównego, tym dokładniej trzeba przetestować na nim prompty, wywołania narzędzi i parametry.

### Jak często testować fallback LLM?

Przeprowadź ćwiczenie po każdej zmianie głównego modelu, modelu zapasowego, instrukcji agenta lub używanych narzędzi, a w pozostałych przypadkach co najmniej raz na kwartał. Za każdym razem sprawdzaj też daty wycofania obu modeli — model zapasowy, który został wycofany, zawiedzie dokładnie wtedy, gdy będzie potrzebny.

## Model zapasowy, którego nigdy nie uruchomiono, to tylko zgadywanie

Awarie, limity zapytań i wycofania modeli stały się codziennością, a dobry model zapasowy agenta AI zmienia je z nieotrzymanego porannego raportu w raport dostarczony z niewielkim opóźnieniem. Liczy się jednak kolejność działań: ponowienie, następnie inny host, potem inny model — i tylko z modelem zapasowym, którego działanie obserwowano podczas wykonywania rzeczywistych zadań. Jeśli go nie przetestowano, nie masz fallbacku. Masz drugą rzecz, która może zawieść.

## Powiązane wpisy na blogu

- [Koszty działania agenta AI: ile naprawdę kosztuje jeden agent miesięcznie](/pl/blog/ai-agent-running-costs)
- [Jak planować cykliczne zadania agentów AI, które działają bez Twojego udziału](/pl/blog/schedule-recurring-ai-agent-tasks)
- [Agenci AI z udziałem człowieka: co zatwierdzać, a co pozostawić do samodzielnego działania](/pl/blog/human-in-the-loop-ai-agents)
- [Agenci AI w biznesie: co wdrażać najpierw, dział po dziale](/pl/blog/ai-agents-for-business)