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 може повторити ту ж модель через кілька каналів постачальників, коли верхній маршрут повертає помилку, що підлягає повтору.
- Якщо всі канали постачальників для основної моделі зазнають невдачі, резервна модель на рівні ключа може переключити запит на налаштовані резервні моделі.
- Багатопостачальницьке маршрутизування зменшує залежність від одного кінцевого пункту, але не може усунути корельовані відмови або ризик на рівні шлюзу.
Інциденти, подібні до цього, підкреслюють важливий принцип інфраструктури:
Надійна модель недостатня, якщо вона доступна лише через єдиний кінцевий пункт постачальника.
Одна модель не повинна означати одного постачальника
Коли додаток підключається безпосередньо до одного постачальника, цей кінцевий пункт стає єдиною точкою відмови.
Якщо постачальник зазнає збою, досягає свого ліміту швидкості або страждає від сплеску затримки, у додатку немає куди відправити запит. Користувачі бачать тайм-аути та помилки, навіть коли та сама модель залишається доступною через інших постачальників інфраструктури.
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. Існуючим додаткам не потрібно надсилати додаткові параметри маршрутизації або змінювати свій клієнтський код.
Білінг базується на моделі, яка врешті-решт повертає успішну відповідь. Розробники можуть перевірити поведінку резервування через заголовки відповіді:
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.