Что произошло
3 сентября 2026 года пользователи одновременно начали фиксировать ошибки в ChatGPT (OpenAI), Claude (Anthropic) и Grok (xAI), а также в продуктах, построенных поверх их API, — в частности в Cursor. Отраслевые медиа оценили масштаб как затронувший миллионы пользователей по всему миру и назвали событие «rare triple outage» и «unprecedented». Сбои проявлялись по-разному: у части пользователей ChatGPT не отдавал ответы, ломались логины, загрузка файлов, голосовой режим и генерация изображений; в Claude отваливались веб-интерфейс, Claude Code и API; Grok показывал сообщение «This model is overloaded right now. Please try again shortly or pick a different model.»
Официальные формулировки различались по содержанию, но совпадали по уровню абстракции. OpenAI сообщила The Register: ошибка маршрутизации, начавшаяся около 7:43 am PT в четверг 3 сентября, сделала ChatGPT и Codex недоступными для части пользователей на всех платформах; примерно к 8:17 am PT решение было применено и оставалось под наблюдением. На статус-странице фигурировали формулировки «elevated errors across ChatGPT and Codex» и «applied a mitigation and monitoring recovery». Anthropic заявила: Claude полностью восстановлен после инфраструктурной проблемы, вызвавшей частичный отказ Claude.ai, Claude Code, Claude Cowork и Claude API, сервис восстановлен в 16:16 UTC. В отдельных обновлениях уточнялось, что ошибки затрагивали конкретные версии моделей — Mythos 5.1, Fable 5.1, Opus 5, — причём часть моделей возвращалась к baseline error rate раньше остальных.
xAI не публиковала детального разбора: подтверждалась перегрузка модели без конкретного времени восстановления. Представитель техотдела Anthropic CJ Avilla в соцсетях назвал причиной «infrastructure issues». Ни одна из трёх компаний к моменту выхода первых публикаций не предъявила единый технический root cause, связывающий три инцидента в одну аварию — статусы описывали их как отдельные события с разными компонентами и разным временем восстановления.
Журналисты и наблюдатели выдвинули ведущую гипотезу: общая зависимость от Microsoft Azure, у которого в тот же период фиксировался всплеск сообщений об отказах. Все три платформы в той или иной форме используют Azure — compute, storage, networking или вспомогательные компоненты. Обсуждались и другие shared dependencies: общие сетевые магистрали, крупные DNS-платформы, вероятность DDoS-атак на сетевую инфраструктуру ИИ. Официального подтверждения Azure как root cause не было — это корреляция, а не установленная причинно-следственная связь, и именно эта неопределённость важнее самой аварии.
Как это устроено
Routing error: отказ произошёл не в модели, а на пути к ней
Формулировка OpenAI — «routing error» — указывает на уровень маршрутизации запросов, а не на логику вывода модели. Anthropic говорит об «infrastructure issue», затронувшем сразу несколько интерфейсов: веб, CLI-агент, корпоративный клиент и API. Практический вывод для архитектора: работоспособность весов модели и доступность сервиса — разные метрики. GPT, Claude и Grok могли быть полностью исправны как модели и при этом недоступны из-за аутентификации, API-шлюзов, сетевого маршрута, внутренней балансировки или распределённого хранилища, обслуживающего контекст.
По нашему опыту проектов именно этот слой мониторится хуже всего. Команды проверяют «модель отвечает» синтетическим запросом раз в минуту, но не различают отказ аутентификации, деградацию латентности шлюза и rate-limit конкретного региона. При тройном сбое 3 сентября разница была принципиальной: часть моделей Anthropic вернулась к нормальному уровню ошибок раньше других, то есть корректная стратегия фолбэка в тот момент — переключение не на другого вендора, а на другую модель того же вендора.
Почему формальная мультивендорность не сработала
Типовая схема «страховки» выглядит так: основной провайдер OpenAI, резервный Anthropic, третий xAI или Google. Юридически это три контракта, три SLA, три независимых компании. Инфраструктурно — возможно, одно облако, один набор магистральных операторов и один-два DNS-провайдера. Единой точкой отказа становится не LLM, а слой ниже: облако, сеть, DNS, региональные сервисы. Мультивендорность на уровне модели не равна отказоустойчивости на уровне инфраструктуры, и 3 сентября это было продемонстрировано публично.
Отдельная сложность в том, что клиент не видит карту зависимостей своих поставщиков. Провайдеры не раскрывают, какие компоненты в каких регионах на чьём железе работают, а постмортемы после 3 сентября остались на уровне «infrastructure issue». Это ограничивает возможность считать корреляцию отказов: без данных нельзя посчитать вероятность одновременного простоя двух «независимых» вендоров.
Экономика второго контура
Резервирование стоит денег в трёх статьях: дублирующая интеграция и её поддержка, тестирование поведения моделей при переключении, простаивающие мощности локального фолбэка. Первые две статьи — постоянный инженерный расход: каждая новая версия промпта и каждая новая функция должны проверяться минимум на двух движках. Третья зависит от того, держите вы GPU в горячем резерве или поднимаете модель по требованию: горячий резерв даёт секунды переключения и постоянный счёт, холодный — минуты и дешевле.
Экономический контекст сентября 2026 года работает в пользу резервирования. Anthropic вывела Claude Fable 5.1 в GA при неизменном прайсинге и заявленном двукратном росте бенчмарков; Alibaba продвигает Qwen3.8-Flash-Next на архитектуре Mixture of Experts, где на задачу активируется лишь часть экспертов; NVIDIA 3 сентября объявила о покупке Hugging Face примерно за $12,93 млрд, консолидируя крупнейший репозиторий открытых моделей. Качество на единицу стоимости растёт быстрее, чем растут требования типовых корпоративных задач — значит, роль дешёвого второго контура закрывается всё меньшими моделями.
Ограничения мульти-LLM-роутинга
Переключение между провайдерами не бесплатно с точки зрения качества. Модели различаются тональностью, форматом вывода, поддержкой инструментов и function calling, поведением при длинном контексте, реакцией на системный промпт. Прямая переадресация одного и того же промпта на резервного вендора в типовом сценарии даёт всплеск брака: ломается JSON-схема, меняется длина ответа, теряются вызовы инструментов. Поэтому фолбэк требует нормализации промптов и отдельного набора регрессионных тестов на каждую модель, включённую в контур.
Второе ограничение — состояние. Диалоги, кеши контекста, идентификаторы загруженных файлов и результаты промежуточных шагов агента привязаны к конкретному провайдеру. Переключение посередине сессии либо теряет контекст, либо требует внешнего хранилища состояния, независимого от вендора. Это архитектурное решение, которое принимается до, а не во время аварии.
SLA-метрики: что измерять вместо аптайма
Аптайм провайдера в такой архитектуре малоинформативен: он считается по его компонентам, а не по вашему пользовательскому пути. Измерять нужно сквозные метрики на своей стороне.
| Метрика | Что показывает | Как задаётся порог |
|---|---|---|
| Успешность сквозного запроса | Доля запросов, завершившихся валидным ответом после всех ретраев и фолбэков | Из продуктового требования, а не из SLA вендора |
| Latency p95/p99 по провайдеру | Раннюю деградацию до появления 5xx | По базовой линии за спокойный период |
| Доля фолбэков | Насколько часто основной путь не справляется | Тревога при устойчивом росте, а не при одиночных пиках |
| Качество на фолбэке | Расхождение по схеме и по оценке результата с основной моделью | Регрессионный набор, прогон при каждом релизе |
| Time to fallback | Скорость автоматического переключения | Секунды, иначе таймауты клиента съедают эффект |
| Стоимость запроса по маршруту | Экономику деградации | Отдельный бюджет на аварийный режим |
Как это выглядит на практике
Первый сценарий — SaaS с ИИ-функциями внутри продукта. 3 сентября пострадали не только чат-интерфейсы, но и клиенты поверх API: Cursor попал в списки затронутых сервисов вместе с ChatGPT, Claude и Grok. В таком продукте ИИ-функция обычно не одна: есть автодополнение, есть суммаризация, есть агентные сценарии. Правильная реакция — не общее «сервис недоступен», а выборочное отключение: тяжёлая агентная часть уходит в очередь, автодополнение переключается на локальную модель, суммаризация отдаёт кешированный результат.
Второй сценарий — внутренний copilot для разработки и поддержки. У Anthropic 3 сентября отказ был частичным и по-разному затрагивал Mythos 5.1, Fable 5.1 и Opus 5, а Grok отвечал прямой подсказкой «pick a different model». В обоих случаях первый уровень фолбэка — другая модель того же провайдера, второй — другой провайдер, третий — локальный контур. В наших проектах именно первый уровень закрывает большинство инцидентов и стоит дешевле всего, поскольку не требует смены SDK и схемы аутентификации.
Третий сценарий — клиентский контакт-центр и голосовые агенты. Здесь простой измеряется не в проценте ошибок, а в брошенных обращениях: пользователь не ждёт 40 минут, пока применят mitigation. Практика: распознавание речи и генерация ответа разводятся по разным поставщикам, для типовых обращений держится набор заготовленных сценариев без свободной генерации, а при деградации разговор маршрутизируется оператору с пометкой причины. Graceful degradation в голосовом канале — это не худший ответ, а честная передача человеку.
Что это значит для российской компании
Публичные материалы об инциденте не рассматривают российский контекст и не содержат данных о санкционных ограничениях, поэтому переносить выводы нужно на уровне принципов, а не готовых конфигураций. Фактическая рамка для российских компаний известна и без источников по аварии: ограниченная доступность части зарубежных ИИ-платформ, сложности с платёжными инструментами, требования к обработке персональных данных и локализации. Это означает, что «второй зарубежный вендор» для многих российских продуктов — не резерв, а второй источник того же класса риска, к техническому добавляется юридический и платёжный.
| Контур | Роль в архитектуре | Ключевые ограничения | Что закрывает при аварии |
|---|---|---|---|
| Зарубежный API (OpenAI, Anthropic, xAI) | Основной для сложного reasoning и агентов | Доступность из РФ, платежи, правовой режим данных, отсутствие детальных постмортемов | Ничего, если авария на общем инфраслое |
| Российское облако с LLM-сервисом | Основной или первый фолбэк для данных с ограничениями | Уточнять SLA и регионы у поставщика: публичных данных в источниках по инциденту нет | Отказ зарубежного слоя целиком |
| Открытые модели on-prem или в собственном контуре | Второй фолбэк и обработка чувствительных данных | Требуются GPU, MLOps-компетенции, качество ниже фронтира | Отказ внешней связности и облаков |
| Детерминированные заготовки без LLM | Последний уровень деградации | Узкий охват сценариев | Полный отказ ИИ-контура |
Влияние на бюджеты предсказуемое: резервирование добавляет постоянную статью на дублирующую интеграцию и тесты плюс капитальные или арендные расходы на локальный контур. Компенсируется это тем, что покупка NVIDIA репозитория Hugging Face и выход эффективных MoE-моделей вроде Qwen3.8-Flash-Next снижают стоимость приемлемого по качеству локального фолбэка. Отдельно стоит держать в поле зрения регуляторный фон: Европейская комиссия 2 сентября 2026 года направила запросы информации более чем 30 ИИ-компаниям в рамках AI Act, а FTC изучает применение потребительского права к ИИ-системам — компаниям, работающим на внешних рынках, придётся документировать и модели, и контуры резервирования.
Что делать: пошагово
- Постройте карту зависимостей пользовательского пути, а не список вендоров: аутентификация, DNS, CDN, API-шлюз, регион инференса, хранилище контекста. Отметьте компоненты, общие для «независимых» провайдеров, — именно они дают common-mode failure.
- Разделите ИИ-функции по критичности на три группы: останавливающие бизнес-процесс, ухудшающие опыт, косметические. Резервировать полностью нужно только первую, для остальных достаточно правил деградации.
- Введите двухуровневый фолбэк внутри провайдера прежде, чем строить межвендорный: другая модель, другой регион, другой эндпойнт. Это самое дешёвое покрытие и, по опыту, самое востребованное.
- Реализуйте health-checks по каждой паре «провайдер — модель» с политиками переключения по коду ошибки, по росту латентности и по исчерпанию квоты. Пороги задавайте от базовой линии своих метрик, а не от обещаний вендора.
- Вынесите состояние диалога и промпты во внешний вендор-независимый слой: история, схемы вывода, описания инструментов, кеши. Без этого переключение теряет контекст и генерирует брак.
- Разверните локальный фолбэк на открытых весах для классификации, извлечения сущностей, простой генерации и суммаризации. Достаточно, чтобы сервис сохранял функциональность, а не паритет качества с фронтирной моделью.
- Опишите режим graceful degradation как продуктовое требование: какие функции выключаются, какие сообщения видит пользователь, куда уходят очереди задач, когда происходит возврат к нормальному режиму.
- Проведите учение с отключением основного провайдера в рабочее время и зафиксируйте time to fallback, долю брака и стоимость запроса в аварийном режиме. Учение без нагрузки не считается проверкой.
Типичные ошибки
- Считать два зарубежных API независимым резервом. 3 сентября показало обратное: три формально независимых вендора отдавали ошибки одновременно, а общего root cause публично так и не назвали. Цена ошибки — ложное чувство защищённости и отсутствие третьего контура.
- Проверять доступность одним синтетическим запросом «модель, ответь». Такой чек не отличает отказ аутентификации от деградации шлюза и не видит частичного отказа отдельных версий моделей, как это было с Mythos 5.1, Fable 5.1 и Opus 5.
- Переключать трафик на резервную модель без регрессионных тестов. В типовом сценарии ломается JSON-схема и вызовы инструментов, и вместо простоя вы получаете тихий поток некорректных ответов — хуже, чем честная ошибка.
- Ставить агрессивные ретраи без backoff и без бюджета времени. При перегрузке провайдера ретраи усиливают её и превращают частичный отказ в полный, а счёт за токены растёт на фоне нулевой пользы.
- Полагаться на SLA как на инструмент управления риском. Компенсация по SLA не покрывает потерянные обращения и репутацию, а детальных постмортемов после 3 сентября не опубликовал никто из трёх провайдеров.
- Оставлять локальный фолбэк в статусе «когда-нибудь развернём». Модель, которую не поднимали под нагрузкой, при аварии не запускается: не хватает памяти, квот, актуального промпта или прав доступа.
Как понять, что вы на верном пути
- Есть актуальная карта зависимостей, в которой видно, какие внешние компоненты общие для основного и резервного провайдеров.
- Автоматическое переключение измеряется секундами и срабатывает без участия дежурного инженера, а факт переключения виден в метриках и в логах запросов.
- Регрессионный набор прогоняется по всем моделям контура при каждом релизе промптов, а расхождение по схеме вывода фиксируется числом, а не мнением.
- Продукт умеет работать в трёх режимах — полном, деградированном и минимальном, — и режим отображается пользователю понятным сообщением.
- Локальный контур запускался под реальной нагрузкой в течение последнего квартала, и известно, какую долю трафика он выдерживает.
- Стоимость запроса в аварийном режиме посчитана и заложена в бюджет, а не выясняется по факту счёта за месяц.
Вопросы, которые нам задают
Достаточно ли подключить два зарубежных провайдера LLM
Нет, и событие 3 сентября 2026 года — прямое подтверждение. ChatGPT, Claude и Grok — три разные компании с разными моделями и разными контрактами, но их отказы совпали по времени, и ведущая гипотеза наблюдателей указывала на общее облако и общую сетевую инфраструктуру. Официального подтверждения этой гипотезы нет, но для планирования достаточно самого факта корреляции. Второй провайдер закрывает отказ конкретного вендора, а не отказ слоя, на котором стоят все вендоры.
Насколько сильной должна быть локальная фолбэк-модель
Не фронтирной. Задача локального контура — сохранить работоспособность сервиса, а не воспроизвести качество основной модели: классификация обращений, извлечение сущностей, суммаризация, короткая генерация по шаблону покрываются небольшими открытыми моделями. Экономика здесь улучшается: MoE-архитектуры вроде Qwen3.8-Flash-Next активируют лишь часть экспертов на задачу, а доступность открытых весов после покупки Hugging Face компанией NVIDIA за $12,93 млрд остаётся ключевым фактором, за которым стоит следить. Планируйте фолбэк по перечню функций, а не по бенчмаркам.
Как считать простой, если отказ был частичным
Считать нужно по пользовательскому пути, а не по статус-странице провайдера. У Anthropic 3 сентября часть моделей вернулась к baseline error rate раньше остальных, у OpenAI недоступность затронула «some users across platforms» — в обоих случаях агрегированный аптайм выглядел бы приемлемо. Рабочая метрика — доля сквозных запросов, завершившихся валидным ответом, с разрезом по функциям, регионам и провайдерам. Дополнительно фиксируйте latency p95 и p99: рост латентности предшествует ошибкам и даёт время переключиться заранее.
С чего начать компании, у которой один провайдер и нет бюджета на переделку
С трёх недорогих шагов. Первый — фолбэк внутри текущего провайдера на другую модель и другой регион, это меняет конфигурацию, а не архитектуру. Второй — режим деградации в продукте: список функций, отключаемых при ошибках, и корректное сообщение пользователю вместо пустого экрана. Третий — учение с искусственным отключением основного эндпойнта, которое покажет реальный time to fallback и даст аргументы для бюджета на локальный контур.
Источники
- The Register: ChatGPT, Claude and Grok all had outages at the same time
- Datacenter Dynamics: ChatGPT, Claude and Grok hit by simultaneous outages
- Axios: ChatGPT, Claude, Grok outages
- Startup Fortune: ChatGPT, Claude and Grok crashed together in a rare triple outage
- Livemint: ChatGPT, Claude, Grok experience outages, users report errors
- Suhas Bhairav: How multi-LLM fallback routing eliminates external provider API downtime risks