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 может повторить запрос к той же модели через несколько каналов провайдеров, если восходящий маршрут возвращает ошибку, допускающую повтор.
- Если все каналы провайдеров для основной модели не работают, Key-level model fallback может перенаправить запрос на настроенные резервные модели.
- Маршрутизация через нескольких провайдеров снижает зависимость от одной конечной точки, но не устраняет коррелированные сбои и риски на уровне шлюза.
Такие инциденты подчеркивают важный принцип инфраструктуры:
Надежной модели недостаточно, если доступ к ней осуществляется через одну конечную точку провайдера.
Одна модель не обязана означать одного провайдера
Когда приложение напрямую подключено к одному провайдеру, эта конечная точка становится единой точкой отказа.
Если у провайдера происходит сбой, он достигает лимита запросов или наблюдается скачок задержки, приложению некуда отправить запрос. Пользователи видят тайм-ауты и ошибки, даже если та же модель остается доступной через другую инфраструктуру провайдеров.
AIHubMix отделяет модель от провайдера, который её обслуживает.
Например, DeepSeek V4 Flash доступна через нескольких провайдеров на AIHubMix, включая DeepSeek, Baidu, DeepInfra и Alibaba Cloud. Приложения продолжают использовать одну совместимую с OpenAI конечную точку API, а 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-ключа.
