На 4 август 2026 г. официалната статус страница на DeepSeek записа два инцидента с понижена производителност на API.
Първият инцидент продължи 1 час и 18 минути, от 02:02 до 03:20 UTC, и засегна DeepSeek V4 Flash, V4 Pro и Expert Mode. Вторият инцидент продължи 36 минути, от 03:43 до 04:20 UTC, и засегна API на DeepSeek V4 Flash.
И двата инцидента вече са разрешени. OpenCode също съобщи, че DeepSeek Flash е изпитвал проблеми с капацитета поради безпрецедентно търсене. Въпреки това, официалната статус страница на DeepSeek само потвърди понижената производителност и не публикува основна причина.
TL;DR
- Официалната статус страница на DeepSeek записа два инцидента с понижена производителност, засягащи V4 Flash на 4 август 2026 г.
- Директната интеграция с провайдера създава единна точка на провал, дори когато същият модел е наличен на друго място.
- AIHubMix може да повтори същия модел през множество канали на провайдера, когато горният маршрут върне грешка, която може да бъде повторена.
- Ако всички канали на провайдера за основния модел се провалят, резервният модел на ниво ключ може да пренасочи заявката към конфигурирани резервни модели.
- Многопровайдерското маршрутизиране намалява зависимостта от една крайна точка, но не може да елиминира корелираните провали или риска на ниво шлюз.
Инциденти като този подчертават важен принцип на инфраструктурата:
Надеждният модел не е достатъчен, ако се достъпва през единна крайна точка на провайдера.
Един модел не трябва да означава един провайдер
Когато приложение се свързва директно с един провайдер, тази крайна точка става единна точка на провал.
Ако провайдерът изпитва прекъсване, достига лимита си на скорост или страда от пик на латентността, приложението няма къде другаде да изпрати заявката. Потребителите виждат таймаути и грешки, дори когато същият модел остава наличен през други инфраструктурни провайдери.
AIHubMix разделя модела от провайдера, който го обслужва.
Например, DeepSeek V4 Flash е наличен през множество провайдери на AIHubMix, включително DeepSeek, Baidu, DeepInfra и Alibaba Cloud. Приложенията продължават да използват една крайна точка, съвместима с OpenAI, докато AIHubMix управлява наличните горни маршрути.
Това създава два различни слоя на надеждност.
Слой 1: Фейловер на провайдера
Фейловерът на провайдера запазва искания модел непроменен, докато сменя инфраструктурния провайдер зад него.
Когато заявка за DeepSeek V4 Flash достигне AIHubMix, шлюзът избира подходящ канал на провайдера. Ако този канал върне грешка, която може да бъде повторена, преди отговорът да започне, AIHubMix може да опита друг наличен канал за същия модел.
Пътят на заявката може да изглежда така:
- Опитайте DeepSeek V4 Flash през Провайдер A.
- Провайдер A връща таймаут, грешка 5xx или грешка с капацитет, която може да бъде повторена.
- Опитайте същия модел DeepSeek V4 Flash през Провайдер B.
- Продължете, докато заявката не успее или всички подходящи канали не бъдат изчерпани.
Клиентът не трябва да интегрира множество SDK на провайдера, да управлява отделни API ключове или да реализира собствена логика за повторение.
Това е фейловер на ниво провайдер: провайдерът се променя, но исканият модел остава същият.
Слой 2: Резервен модел
Фейловерът на провайдера не може да помогне, ако всеки наличен провайдер за основния модел е недостъпен.
Затова AIHubMix поддържа втори слой на надеждност: резервен модел.
Потребителите могат да конфигурират подреден списък на резервни модели за всеки API ключ. След като всеки подходящ канал за основния модел е върнал грешка, която може да бъде повторена, AIHubMix преминава към следващия модел в списъка с резерви.
Например:
- Основен:
deepseek-v4-flash - Първи резерв:
gpt-5.4 - Втори резерв:
gemini-3.1-pro-preview
Резервирането се извършва вътре в шлюза на AIHubMix. Съществуващите приложения не трябва да изпращат допълнителни параметри за маршрутизиране или да променят клиентския си код.
Таксуването се основава на модела, който в крайна сметка връща успешния отговор. Разработчиците могат да проверят поведението на резервирането чрез заглавките на отговора:
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
Пълната конфигурация и правила за задействане са документирани в AIHubMix Model Mapping and Fallback.
Какво може да обработи автоматичният фейловер
Фейловерът на провайдера е проектиран да се възстанови от проблеми с горната инфраструктура, като:
- Таймаути на провайдера
- Провали на свързаност
- Грешки 5xx, които могат да бъдат повторени
- Лимити на скоростта и грешки с капацитет на провайдера
- Временна недостъпност на горен канал
Когато тези провали се случат преди началото на отговора, AIHubMix може прозрачно да опита друг маршрут.
Какво не може да реши фейловерът
Многопровайдерското маршрутизиране подобрява наличността, но не прави шлюза непогрешим.
Резервирането не се задейства, когато:
- API ключът на потребителя AIHubMix е невалиден, изтекъл или извън квота
- Самата заявка е невалидна
- Клиентът се разединява или достига собствен таймаут
- Отговорът на стрийминг вече е започнал
- Определен канал на провайдера е изрично избран
- Провалът засяга всеки провайдер или самия шлюз
Провалите на провайдера могат също да бъдат корелирани. Множество провайдери могат да зависят от същата основна инфраструктура, версия на модела или регионална мрежа. Поради тази причина, наличността на многопровайдерите трябва да се измерва с реален трафик, а не да се предполага от броя на провайдителите самостоятелно.
Защо агрегаторът може да бъде по-надежден от директната крайна точка
Директното извикване на официален API дава на приложението един маршрут до модела.
Многопровайдерският шлюз му дава няколко.
Ако тези маршрути на провайдера се провалят независимо, шлюзът може да маршрутизира около понижената крайна точка, без да излага провала на приложението. Това намалява зависимостта от всеки един провайдер и може да осигури по-висока наличност от директна интеграция с един провайдер.
Разликата е архитектурна:
- Директен API: един модел, един провайдер, една домейн на провал
- AIHubMix: един модел, множество провайдери, автоматичен фейловер
- AIHubMix с резервен модел: множество провайдери плюс резервни модели
Целта не е да се предвиди кой провайдер ще се провали следващия. Целта е да се направи инцидент в горната част на инфраструктурата вътрешно събитие на маршрутизиране, вместо прекъсване, видимо за клиента.
Подгответе се за следващия инцидент с провайдера
DeepSeek V4 Flash се възстанови, но временните ограничения на капацитета, лимитите на скоростта и прекъсванията в горната част са нормални части от производствената AI инфраструктура.
Приложенията не трябва да променят кода си всеки път, когато един провайдер стане нестабилен.
С AIHubMix разработчиците могат да получат достъп до множество провайдери чрез един API, автоматично да повторят същия модел през наличните канали и да конфигурират резервни модели за допълнителен слой защита.
Разгледайте наличните модели и провайдери на aihubmix.com/models.
Често задавани въпроси
Какво е многопровайдерски фейловер?
Той автоматично повтаря същия модел през друг подходящ провайдер, когато текущият маршрут върне грешка, която може да бъде повторена.
Как резервният модел се различава?
Фейловерът на провайдера запазва модела непроменен. Резервният модел преминава към конфигуриран резервен модел само след като всички подходящи канали за основния модел се провалят.
Кои провали могат да задействат фейловера?
Типичните задействания включват таймаути, провали на свързаност, грешки 5xx, които могат да бъдат повторени, лимити на скоростта и временни грешки с капацитет преди началото на отговора.
Гарантира ли фейловерът нулево време на престой?
Не. Корелираните провали на провайдера, инциденти на ниво шлюз, не повтарящи се грешки и провали след началото на стрийминг все още могат да достигнат клиента.
Трябва ли да променям кода на приложението си?
Не се изисква допълнителна логика за маршрутизиране. Приложенията продължават да използват крайната точка, съвместима с OpenAI на AIHubMix, докато резервните модели могат да бъдат конфигурирани на ниво API ключ.