4 sierpnia 2026 roku oficjalna strona statusu DeepSeek zarejestrowała dwa incydenty związane z obniżoną wydajnością API.
Pierwszy incydent trwał 1 godzinę i 18 minut, od 02:02 do 03:20 UTC, i dotyczył DeepSeek V4 Flash, V4 Pro oraz trybu Expert. Drugi incydent trwał 36 minut, od 03:43 do 04:20 UTC, i dotyczył API DeepSeek V4 Flash.
Oba incydenty zostały już rozwiązane. OpenCode również zgłosiło, że DeepSeek Flash borykał się z problemami z pojemnością z powodu niespotykanego zapotrzebowania. Jednak oficjalna strona statusu DeepSeek potwierdziła jedynie obniżoną wydajność i nie opublikowała przyczyny.
TL;DR
- Oficjalna strona statusu DeepSeek zarejestrowała dwa incydenty związane z obniżoną wydajnością, które dotyczyły V4 Flash w dniu 4 sierpnia 2026 roku.
- Bezpośrednia integracja z dostawcą tworzy pojedynczy punkt awarii, nawet gdy ten sam model jest dostępny gdzie indziej.
- AIHubMix może ponownie spróbować tego samego modelu w różnych kanałach dostawców, gdy górny szlak zwraca błąd, który można ponownie spróbować.
- Jeśli wszystkie kanały dostawców dla głównego modelu zawiodą, awaryjne przełączenie modelu na poziomie klucza może przełączyć żądanie na skonfigurowane modele zapasowe.
- Routing z wieloma dostawcami zmniejsza zależność od jednego punktu końcowego, ale nie może wyeliminować skorelowanych awarii ani ryzyka na poziomie bramy.
Incydenty takie jak ten podkreślają ważną zasadę infrastruktury:
Wiarygodny model to za mało, jeśli jest dostępny przez pojedynczy punkt końcowy dostawcy.
Jeden model nie musi oznaczać jednego dostawcy
Gdy aplikacja łączy się bezpośrednio z jednym dostawcą, ten punkt końcowy staje się pojedynczym punktem awarii.
Jeśli dostawca doświadcza awarii, osiąga swój limit wydajności lub cierpi na skok opóźnienia, aplikacja nie ma gdzie indziej wysłać żądania. Użytkownicy widzą przekroczenia czasu i błędy, nawet gdy ten sam model pozostaje dostępny przez innych dostawców infrastruktury.
AIHubMix oddziela model od dostawcy, który go obsługuje.
Na przykład, DeepSeek V4 Flash jest dostępny przez wielu dostawców na AIHubMix, w tym DeepSeek, Baidu, DeepInfra i Alibaba Cloud. Aplikacje nadal korzystają z jednego punktu końcowego API zgodnego z OpenAI, podczas gdy AIHubMix zarządza dostępnymi szlakami górnymi.
Tworzy to dwie odrębne warstwy niezawodności.
Warstwa 1: Awaryjne przełączanie dostawcy
Awaryjne przełączanie dostawcy utrzymuje żądany model bez zmian, podczas gdy zmienia dostawcę infrastruktury za nim.
Gdy żądanie dotyczące DeepSeek V4 Flash dociera do AIHubMix, brama wybiera odpowiedni kanał dostawcy. Jeśli ten kanał zwraca błąd, który można ponownie spróbować przed rozpoczęciem odpowiedzi, AIHubMix może spróbować innego dostępnego kanału dla tego samego modelu.
Ścieżka żądania może wyglądać następująco:
- Spróbuj DeepSeek V4 Flash przez Dostawcę A.
- Dostawca A zwraca przekroczenie czasu, błąd 5xx lub błąd pojemności, który można ponownie spróbować.
- Spróbuj tego samego modelu DeepSeek V4 Flash przez Dostawcę B.
- Kontynuuj, aż żądanie zakończy się sukcesem lub wszystkie dostępne kanały zostaną wyczerpane.
Klient nie musi integrować wielu SDK dostawców, zarządzać oddzielnymi kluczami API ani wdrażać własnej logiki ponownego próbowania.
To jest awaryjne przełączanie na poziomie dostawcy: dostawca się zmienia, ale żądany model pozostaje ten sam.
Warstwa 2: Awaryjne przełączanie modelu
Awaryjne przełączanie dostawcy nie pomoże, jeśli każdy dostępny dostawca dla głównego modelu jest niedostępny.
AIHubMix wspiera zatem drugą warstwę niezawodności: awaryjne przełączanie modelu.
Użytkownicy mogą skonfigurować uporządkowaną listę modeli zapasowych dla każdego klucza API. Po tym, jak każdy dostępny kanał dla głównego modelu zwrócił błąd, który można ponownie spróbować, AIHubMix przechodzi do następnego modelu na liście zapasowej.
Na przykład:
- Główny:
deepseek-v4-flash - Pierwszy model zapasowy:
gpt-5.4 - Drugi model zapasowy:
gemini-3.1-pro-preview
Awaryjne przełączanie odbywa się wewnątrz bramy AIHubMix. Istniejące aplikacje nie muszą wysyłać dodatkowych parametrów routingu ani zmieniać swojego kodu klienta.
Rozliczenia są oparte na modelu, który ostatecznie zwraca pomyślną odpowiedź. Programiści mogą zweryfikować zachowanie awaryjnego przełączania poprzez nagłówki odpowiedzi:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
Pełna konfiguracja i zasady wyzwalania są udokumentowane w AIHubMix Model Mapping and Fallback.
Co może obsłużyć automatyczne awaryjne przełączanie
Awaryjne przełączanie dostawcy jest zaprojektowane, aby odzyskać z problemów infrastruktury górnej, takich jak:
- Przekroczenia czasu dostawcy
- Awaria połączenia
- Odpowiedzi 5xx, które można ponownie spróbować
- Limity wydajności dostawcy i błędy pojemności
- Przejrzysta niedostępność kanału górnego
Gdy te awarie występują przed rozpoczęciem odpowiedzi, AIHubMix może przejrzyście spróbować innej trasy.
Czego awaryjne przełączanie nie może rozwiązać
Routing z wieloma dostawcami poprawia dostępność, ale nie czyni bramy nieomylną.
Awaryjne przełączanie nie jest wyzwalane, gdy:
- Klucz API AIHubMix użytkownika jest nieważny, wygasł lub przekroczył limit
- Same żądanie jest nieważne
- Klient rozłącza się lub osiąga własne przekroczenie czasu
- Odpowiedź strumieniowa już się rozpoczęła
- Wybrano konkretny kanał dostawcy
- Awaria dotyczy każdego dostawcy lub samej bramy
Awaria dostawcy może być również skorelowana. Wielu dostawców może zależeć od tej samej podstawowej infrastruktury, wydania modelu lub regionalnej sieci. Z tego powodu dostępność z wieloma dostawcami powinna być mierzona rzeczywistym ruchem, a nie zakładana na podstawie samej liczby dostawców.
Dlaczego agregator może być bardziej niezawodny niż bezpośredni punkt końcowy
Bezpośrednie wywołanie oficjalnego API daje aplikacji jedną trasę do modelu.
Brama z wieloma dostawcami daje jej kilka.
Jeśli te trasy dostawców zawodzą niezależnie, brama może ominąć obniżony punkt końcowy, nie narażając aplikacji na awarię. To zmniejsza zależność od jakiegokolwiek pojedynczego dostawcy i może zapewnić wyższą dostępność niż bezpośrednia integracja z jednym dostawcą.
Różnica jest architektoniczna:
- Bezpośrednie API: jeden model, jeden dostawca, jedna domena awarii
- AIHubMix: jeden model, wielu dostawców, automatyczne awaryjne przełączanie
- AIHubMix z awaryjnym przełączaniem modelu: wielu dostawców plus modele zapasowe
Celem nie jest przewidywanie, który dostawca zawiedzie następny. Chodzi o to, aby incydent górny stał się wewnętrznym zdarzeniem routingu, a nie awarią widoczną dla klienta.
Buduj na następny incydent dostawcy
DeepSeek V4 Flash się odbudował, ale tymczasowe ograniczenia pojemności, limity wydajności i awarie górne są normalnymi elementami produkcyjnej infrastruktury AI.
Aplikacje nie powinny musieć zmieniać kodu za każdym razem, gdy dostawca staje się niestabilny.
Dzięki AIHubMix programiści mogą uzyskać dostęp do wielu dostawców przez jedno API, automatycznie ponownie próbować ten sam model w dostępnych kanałach i konfigurować modele zapasowe dla dodatkowej warstwy ochrony.
Odkryj dostępne modele i dostawców na aihubmix.com/models.
FAQ
Czym jest awaryjne przełączanie z wieloma dostawcami?
Automatycznie ponownie próbuje ten sam model przez innego uprawnionego dostawcę, gdy bieżąca trasa zwraca błąd, który można ponownie spróbować.
Jak awaryjne przełączanie modelu różni się od tego?
Awaryjne przełączanie dostawcy utrzymuje model bez zmian. Awaryjne przełączanie modelu przełącza się na skonfigurowany model zapasowy dopiero po tym, jak wszystkie dostępne kanały dla głównego modelu zawiodą.
Jakie awarie mogą wyzwolić awaryjne przełączanie?
Typowe wyzwalacze to przekroczenia czasu, awarie połączenia, odpowiedzi 5xx, które można ponownie spróbować, limity wydajności i tymczasowe błędy pojemności przed rozpoczęciem odpowiedzi.
Czy awaryjne przełączanie gwarantuje zerowy czas przestoju?
Nie. Skorelowane awarie dostawcy, incydenty na poziomie bramy, błędy, które nie mogą być ponownie spróbowane, oraz awarie po rozpoczęciu strumieniowania mogą nadal dotrzeć do klienta.
Czy muszę zmieniać kod mojej aplikacji?
Nie są wymagane dodatkowe logiki routingu. Aplikacje nadal korzystają z punktu końcowego AIHubMix zgodnego z OpenAI, podczas gdy modele zapasowe mogą być konfigurowane na poziomie klucza API.