Надёжность и аптайм LLM API провайдеров во второй половине 2026: паттерны сбоев, пробелы SLA и архитектура fallback-маршрутизации

Каждый провайдер рано или поздно ложится. Вопрос в том, ляжет ли ваше приложение вместе с ним.

За первые восемь месяцев 2026 года мы наблюдали, как LLM API провайдеры выпускали фичи с темпом, от которого классические SaaS-релизы кажутся замедленной съёмкой, попутно роняя продакшн. Этот пост собирает данные по надёжности, которые мы отслеживали для OpenAI, Anthropic, Google, DeepSeek, DashScope и SiliconFlow, и превращает их в фреймворк принятия решений по fallback-маршрутизации.

OpenAI-совместимость означает, что провайдер предоставляет endpoint chat-completions, чей контракт запроса и ответа достаточно близок к API OpenAI, чтобы немодифицированный вызов OpenAI SDK работал после замены трёх значений: API key, base URL, название модели. Минимальная поверхность на практике —POST /v1/chat/completions с messages, model и потоковым ответом в форме OpenAI.

Ландшафт надёжности в 2026 году

AI и ML API — наименее надёжная категория API среди 215+ отслеживаемых сервисов, согласно отчёту Nordic APIs по надёжности, охватывающему период с октября 2025 по февраль 2026 года. Stripe работает с аптаймом примерно 99,99%. Linear показывает 99,96%. Лучшие LLM API провайдеры колеблются в районе 99,85–99,90%, худшие опускаются ниже 98%.

Отчёт ModelUptime за май 2026 — независимый кросс-провайдерный мониторинг 9 провайдеров и 29 моделей — зафиксировал 177 инцидентов за один месяц при среднем аптайме 99,28%.

Эти цифры показывают, что индустрия ещё далеко не решила проблему надёжности.

Профили надёжности по провайдерам

В таблице ниже собраны данные из публичных страниц статуса, независимых мониторов (ModelUptime, isDown.app, StatusGator, IncidentHub) и отчёта Nordic APIs.

Источники: status.openai.com, status.claude.com/uptime, status.deepseek.com, ModelUptime — май 2026, Отчёт Nordic APIs

Основные наблюдения:

• Разрыв между заявленным и независимо измеренным аптаймом реален. DeepSeek показывает 99,88% на своей странице статуса, тогда как ModelUptime измерил 98,16% за тот же период. Провайдеры сами решают, что считать «инцидентом». Независимые мониторы ловят то, что провайдеры пропускают.
• Количество инцидентов не равно времени простоя. У Anthropic было 18 инцидентов против 6 у OpenAI, но их показатели аптайма практически совпали (99,85% против 99,86%). Anthropic в среднем решает проблемы быстрее.
• У Google больше всего серьёзных инцидентов. 12 из 35 инцидентов классифицированы как серьёзные — самый высокий показатель среди всех провайдеров. Надёжность Gemini API была нестабильной.
• DashScope и SiliconFlow не имеют независимого мониторинга. Это необязательно означает низкую надёжность — инфраструктура Alibaba Cloud зрелая — но мы не можем верифицировать заявления так же, как для провайдеров с публичной историей инцидентов.

Паттерны сбоев и частота инцидентов

OpenAI

OpenAI зафиксировал 11 инцидентов за 28 дней в январе 2026 — один каждые 2,5 дня. К середине года частота инцидентов значительно снизилась: 6 инцидентов в мае, а страница статуса показывает аптайм 99,93% за период с июня по сентябрь. Большинство инцидентов решается за 30–90 минут.

OpenAI предлагает гарантии аптайма только через программу Scale Tier. Стандартные API-клиенты не имеют контрактного SLA. С июля 2026 трафик Scale Tier автоматически перетекает в Fast-режим при ограничениях ёмкости.

Anthropic

Claude API от Anthropic пережил тяжёлый Q1 2026. Инцидент с Claude Opus 4.5 в конце января потребовал 30 часов на решение. Сетевой инцидент 26–27 марта вызвал повышенную частоту ошибок для Opus 4.6 и Sonnet 4.6. К середине года месячный аптайм улучшился с 99,01% (июль) до 99,59% (август).

Последний инцидент на момент написания произошёл 11 сентября 2026: повышенная частота ошибок для Claude Mythos 5.1 и Claude Fable 5.1, по данным isDown.app. Anthropic не публикует формальный SLA по аптайму API для стандартных клиентов.

Google

Gemini API от Google показал худшее соотношение серьёзных инцидентов в мае 2026: 12 серьёзных из 35 всего. Независимый мониторинг зафиксировал аптайм 98,22%, значительно ниже остальных крупных западных провайдеров. Google не публикует SLA по аптайму, специфичный для Gemini; клиенты Vertex AI могут ориентироваться на общие SLA Google Cloud.

DeepSeek

DeepSeek стал слабейшим провайдером в отчёте ModelUptime за май 2026 с аптаймом 98,16% и 50 инцидентами. 4 августа 2026 API V4 Flash столкнулся с двумя инцидентами деградации производительности в один день, первый продолжался 1 час 18 минут. Собственная страница статуса DeepSeek показывает аптайм 99,88% за июнь–сентябрь — заметное расхождение с независимыми измерениями.

DeepSeek не публикует SLA по rate limit или аптайму. В периоды пикового спроса (особенно после крупных запусков моделей) API исторически испытывал затяжные ограничения ёмкости.

DashScope (Alibaba Cloud Model Studio)

DashScope использует production-grade инфраструктуру Alibaba Cloud. Отдельная публичная история инцидентов для Model Studio не ведётся, и ни один крупный независимый монитор не отслеживает аптайм DashScope API отдельно от общего состояния сервисов Alibaba Cloud.

По нашему опыту маршрутизации трафика через DashScope, производительность стабильна в нормальных условиях, с периодическими пиками задержки в рабочие часы по Китаю (09:00–18:00 CST), коррелирующими с высоким региональным спросом.

SiliconFlow

SiliconFlow не публикует публичную страницу статуса или историю инцидентов. Как более молодая платформа, ориентированная на экономичный инференс, их послужной список по надёжности сложнее оценить независимо. По нашим наблюдениям, API-ответы для популярных моделей в целом стабильны, с периодическими ответами 429 (rate limit) для моделей бесплатного уровня в часы пик.

Реальное положение дел с SLA

Большинство LLM API провайдеров не предлагают контрактных SLA по аптайму стандартным API-клиентам. Вот что реально существует:

Пропасть между «у нас есть страница статуса» и «мы компенсируем, когда сломается» огромна. Для большинства провайдеров страница статуса — жест вежливости, а не обязательство.

Три типа сбоев, к которым нужен план

1. Полный простой

API возвращает ошибки 5xx или таймаут. Это проще всего обнаружить — мониторинг ловит сразу. Проблема в том, что у большинства команд нет автоматического fallback. Инженеры открывают страницу статуса, ждут и переключаются на другие задачи.

Для команды из 50 инженеров при ставке $80–$150/час каждый час простоя критической зависимости обходится в $4 000–$7 500 потерянной продуктивности, по анализу BuildMVPFast.

2. Деградация качества

API возвращает 200 OK, но вывод ошибочный, медленный или обрезанный. Health check проходит, модель отвечает — просто плохо. Задержка вырастает с 500 мс до 8 секунд. Структурированные ответы начинают проваливать schema validation. Этот тип сбоя сложнее обнаружить и опаснее, чем чистый простой.

3. Каскадные отказы

Ваш AI-провайдер работает нормально, но что-то сломалось выше по цепочке. Инцидент AWS DynamoDB в октябре 2025 каскадировал на 141 затронутый сервис. Сбой Cloudflare в ноябре повалил часть самого OpenAI. Ваша цепочка зависимостей глубже, чем вы думаете.

Архитектура fallback: мультипровайдерное решение

Данные делают кейс за мультипровайдерную маршрутизацию лучше любого маркетинга. Когда основной провайдер ложится, ваше приложение должно автоматически маршрутизировать на резервный провайдер, а не вызывать инженера.

Минимальная конфигурация fallback через OpenAI-совместимый routing layer:

from openai import OpenAI

# Основной маршрут: через TheRouter с настроенным fallback
client = OpenAI(
    base_url="https://api.therouter.ai/v1",
    api_key="your-therouter-key"
)

response = client.chat.completions.create(
    model="openai/gpt-4o",  # основной провайдер
    messages=[{"role": "user", "content": "Hello"}],
    # TheRouter переключает на anthropic/claude-sonnet-4.6,
    # если OpenAI возвращает 5xx или превышает порог задержки
)

С провайдерной fallback-маршрутизацией код приложения не меняется. Routing layer поглощает нестабильность провайдера и возвращает ответ от того, кто сейчас здоров.

Рекомендуемые fallback-цепочки

На основе данных по надёжности выше — fallback-цепочки для максимального покрытия:

Ключевой принцип: никогда не ставьте fallback на ту же инфраструктуру. OpenAI и модели Microsoft используют Azure. DashScope-hosted DeepSeek и прямой DeepSeek API работают на бэкенде DeepSeek. Эффективные fallback-цепочки пересекают границы инфраструктуры.

Фреймворк решений: минимальная глубина fallback по требованиям к надёжности

Математика: если провайдер A имеет аптайм 99,85% и провайдер B тоже 99,85% независимо, маршрутизация через оба даёт примерно 99,9998% аптайма — при условии, что их сбои не коррелируют. Общая инфраструктура или общие upstream-зависимости снижают это преимущество.

Построение стека наблюдаемости

Обнаружение деградации до того, как это заметят пользователи, требует AI-специфичного мониторинга:

1. Отслеживайте распределение задержек по провайдерам, а не только средние значения. Провайдер со стабильным p50, но волатильным p95 деградирует периодически.
2. Мониторьте error rate по кодам ошибок. Всплеск 429 означает rate limiting; всплеск 500 означает инфраструктурный сбой. Реакция различается.
3. Валидируйте качество вывода. 200 OK с мусором в ответе хуже, чем чистый 503. Schema validation структурированных ответов ловит это.
4. Настройте webhook на страницы статуса. Все провайдеры из списка выше публикуют обновления на страницах статуса. Подпишитесь. 10-минутное предупреждение о развивающемся инциденте лучше, чем узнать о нём через жалобы пользователей.

Подробное сравнение инструментов мониторинга LLM — в нашем сравнении инструментов наблюдаемости и мониторинга LLM API.

FAQ

Какой LLM API провайдер самый надёжный?

Ни один провайдер не удерживает первое место стабильно. Microsoft возглавил рейтинг ModelUptime за май 2026 с 99,90%, но у Microsoft отслеживалась только одна модель (Phi-4). Среди крупных провайдеров с широким набором моделей OpenAI (99,86%) и Anthropic (99,85%) различались на 0,01%. Месячная волатильность значительна.

Стоит ли менять провайдера на основании данных по надёжности?

Менять провайдера на основании данных за один месяц преждевременно. Лучший подход — мультипровайдерная маршрутизация: оставьте основного провайдера ради качества и добавьте fallback ради надёжности. Детали реализации — в нашем руководстве по fallback-маршрутизации LLM API.

Как мониторить аптайм моего LLM API провайдера?

Подпишитесь на страницу статуса вашего провайдера (все крупные провайдеры их имеют). Добавьте независимый мониторинг: ModelUptime, isDown.app и StatusGator отслеживают LLM API провайдеров. Для собственного трафика инструментируйте задержку и error rate на уровне запроса в приложении.

Почему существует разрыв между заявленным и независимо измеренным аптаймом?

Провайдеры сами решают, что квалифицируется как «инцидент» на их странице статуса. 10-минутный пик задержки может не попасть на страницу статуса, но будет зафиксирован независимыми мониторами. Заявленный аптайм также исключает «деградацию производительности» из расчёта более агрессивно, чем это делают независимые мониторы.

Мультипровайдерная маршрутизация увеличивает задержку?

Хорошо настроенный routing layer добавляет 1–5 мс overhead на запрос для выбора провайдера. Это ничтожно мало по сравнению с типичным временем ответа LLM в 500–3000 мс. Задержка от routing значительно меньше задержки от ожидания медленного ответа деградирующего провайдера.

Как выбрать fallback-провайдеров для моего сценария?

Приоритизируйте разнообразие инфраструктуры над сходством моделей. Ваш fallback должен работать на другой инфраструктуре, чем основной провайдер. OpenAI и Azure OpenAI делят инфраструктуру. Прямой API DeepSeek и DashScope-hosted DeepSeek работают на бэкенде DeepSeek. Пересекайте эти границы. Подробнее о том, как разные провайдеры ломаются — в справочнике по обработке ошибок.

---

Данные по надёжности в этом посте основаны на публично доступных страницах статуса и отчётах независимых мониторов. Показатели аптайма являются приближёнными оценками на основе отчётов об инцидентах, а не SLA-grade измерениями. Надёжность провайдеров меняется со временем — проверяйте актуальное состояние по ссылкам на страницы статуса.