На 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 обаче потвърди само влошена производителност и не публикува първопричина.
Накратко
- Официалната страница със състоянието на DeepSeek регистрира два инцидента с влошена производителност, засегнали V4 Flash, на 4 август 2026 г.
- Директната интеграция с един доставчик създава единична точка на отказ, дори когато същият модел е наличен и другаде.
- AIHubMix може да опита повторно същия модел през няколко канала на доставчици, когато горестоящият маршрут върне грешка, която може да се повтори.
- Ако всички канали на доставчици за основния модел се провалят, резервирането на модел на ниво ключ може да пренасочи заявката към конфигурирани резервни модели.
- Маршрутизирането през няколко доставчика намалява зависимостта от една крайна точка, но не може да елиминира корелирани откази или риска на ниво шлюз.
Инциденти като този подчертават един важен принцип на инфраструктурата:
Надежден модел не е достатъчен, ако до него се достига през една-единствена крайна точка на доставчик.
Един модел не трябва да означава един доставчик
Когато приложението се свързва директно с един доставчик, тази крайна точка става единична точка на отказ.
Ако доставчикът има прекъсване, достигне лимита си на заявки или получи скок в латентността, приложението няма друго място, към което да изпрати заявката. Потребителите виждат прekъсвания на времето и грешки, дори когато същият модел остава наличен чрез други инфраструктурни доставчици.
AIHubMix отделя модела от доставчика, който го обслужва.
Например DeepSeek V4 Flash е наличен чрез няколко доставчика в AIHubMix, включително DeepSeek, Baidu, DeepInfra и Alibaba Cloud. Приложенията продължават да използват една крайна точка на API, съвместима с 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. Съществуващите приложения не трябва да изпращат допълнителни параметри за маршрутизиране или да променят клиентския си код.
Таксуването се основава на модела, който в крайна сметка връща успешния отговор. Разработчиците могат да проверят поведението при резервиране чрез HTTP заглавията на отговора:
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, които могат да се повторят, лимити на заявки и временни грешки за капацитет преди започване на отговора.
Гарантира ли резервирането нулев престой?
Не. Корелирани откази при доставчици, инциденти на ниво шлюз, грешки, които не могат да се повторят, и откази след започнало потоково предаване все още могат да стигнат до клиента.
Трябва ли да променя кода на приложението си?
Не е необходима допълнителна логика за маршрутизиране. Приложенията продължават да използват крайната точка на AIHubMix, съвместима с OpenAI, а резервните модели могат да се конфигурират на ниво API ключ.
