ChatGPT, Claude и Grok упали в один день: сбой в дата-центре Мемфиса и уроки для тех, кто строит на ИИ-API

Утром 3 сентября 2026 года три главных ИИ-сервиса — ChatGPT, Claude и Grok — перестали нормально отвечать почти одновременно. Такое совпадение выглядит статистически невероятным: это прямые конкуренты, у каждого свои модели, свои команды и свои дата-центры. Через несколько часов SpaceXAI опубликовала извинение, из которого стало понятно, что «свои дата-центры» — уже не совсем правда.

Хронология: три статусные страницы за одно утро

Первым посыпался Grok. Компания начала разбираться примерно в 6:30 утра по тихоокеанскому времени (PT), сервис отвечал ошибками перегрузки в веб-версии, в приложениях для Android и iOS и внутри X. Общая длительность сбоя — около трёх с половиной часов.

Почти в то же окно Claude ушёл в состояние повышенных ошибок. По данным статусной страницы Anthropic, инцидент длился 3 часа 6 минут и завершился в 16:16 UTC. Затронуло не только чат: в список попали Claude.ai, Claude Code, Claude Cowork и API — то есть всё, на чём разработчики строят продакшен. Следом отвалился Cursor, который ходит в модели Anthropic и xAI, — типичный пример того, как чужой сбой становится вашим.

OpenAI зафиксировала повышенные ошибки в ChatGPT и Codex. По статусной странице речь шла об ошибке маршрутизации примерно с 7:43 PT, а сообщение о применённом исправлении появилось около 8:17 PT; финальную отметку «инцидент решён» компания поставила позже. Отдельная деталь для тех, кто пользуется удалённым управлением Codex: часть пользователей после восстановления пришлось заново привязывать мобильные устройства.

Единственным крупным сервисом, который не объявлял официального сбоя, оказался Google Gemini: жалобы пользователей были, но Google инцидент не подтверждала. Gemini работает на инфраструктуре Google Cloud — и это ровно та деталь, к которой сводится вся история.

Единственное признание: дата-центр в Мемфисе

Официальное объяснение дала только одна компания из трёх. SpaceXAI написала в своём аккаунте в X: «Приносим извинения за проблемы, которые вы могли испытать с Grok из-за сбоя в нашем вычислительном центре в Мемфисе сегодня утром. Мы также хотим извиниться перед нашими пострадавшими compute partners (партнёрами по вычислениям). Все системы восстановлены и работают штатно».

Ключевые слова здесь — «партнёры по вычислениям». Компания фактически признала, что её мемфисский дата-центр обслуживает не только собственные модели, и что вместе с Grok пострадал кто-то ещё. Кто именно — SpaceXAI не назвала.

Почему у Grok и Claude может быть общая точка отказа

Ответ был опубликован ещё весной. 6 мая 2026 года SpaceXAI и Anthropic объявили о партнёрстве по вычислениям: Anthropic получила доступ к мощностям кластера Colossus 1 — более 220 тысяч ускорителей NVIDIA, включая плотные развёртывания H100, H200 и GB200 нового поколения. В анонсе прямо говорилось, что дополнительные мощности пойдут на повышение качества обслуживания подписчиков Claude Pro и Claude Max.

То есть компания, чью модель вы вызываете из своего кода, и компания, чей чат-бот встроен в соцсеть Илона Маска, в буквальном смысле делят машинный зал. Anthropic официально не подтверждала, что её сбой 3 сентября связан с Мемфисом, — но совпадение окна и формулировка про «пострадавших партнёров» не оставляют много пространства для других версий.

Версии, которые не подтвердились

Первой гипотезой была Cloudflare: её услугами пользуются все три компании, а масштабные сбои Cloudflare уже не раз укладывали половину интернета. Компания версию опровергла жёстко: «Наши сервисы работают нормально, и любые сообщения, которые этому противоречат, неверны».

Вторая гипотеза — Microsoft Azure: в том же временном окне сообщалось о сетевых проблемах в регионе East US, и несколько изданий предположили, что это и есть общий знаменатель. Подтверждения нет: ни OpenAI, ни Anthropic не связывали свои инциденты с Azure, а единая причина для всех трёх сервисов так и не была установлена публично.

Честный итог такой: документально подтверждена одна причина — авария в Мемфисе и признание SpaceXAI о задетых партнёрах. Природа сбоя OpenAI осталась необъяснённой: компания ограничилась формулировкой про ошибку маршрутизации.

Что здесь на самом деле новое

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

Гонка за вычислениями привела к тому, что лаборатории арендуют мощности друг у друга и у одних и тех же владельцев кластеров. Экономически это разумно: строить собственный дата-центр на гигаватты долго и дорого, проще снять готовое (мы писали о том, как разгоняются поставки ускорителей нового поколения, — очередь за ними расписана надолго). Архитектурное следствие менее приятное: мультивендорность на уровне API больше не гарантирует мультивендорности на уровне железа.

Классическая схема отказоустойчивости в приложениях с ИИ выглядит так: основной провайдер плюс запасной от другого вендора. 3 сентября эта схема не сработала бы у тех, кто выбрал парой Claude и Grok: оба ответа пришли бы из одного здания в Мемфисе. Сработала бы связка с Gemini — не потому, что Google лучше, а потому что у него отдельный физический стек.

Что делать, если ваш продукт зависит от ИИ-API

Выводы здесь не про «ИИ ненадёжен», а про обычную инженерную гигиену — ту же, что применяется к платёжным шлюзам и почтовым сервисам.

Практический минимум

• Разнесите фолбэк по инфраструктуре, а не по логотипам. Прежде чем объявлять второго провайдера резервным, выясните, в чьём облаке он крутится. Резерв в том же дата-центре — это не резерв.
• Таймауты и ретраи с экспоненциальной задержкой и джиттером (случайным разбросом). Без джиттера все ваши клиенты пойдут на повтор синхронно и добьют провайдера, который только начал подниматься.
• Ограничьте бюджет ретраев. Трёхчасовой сбой при агрессивных повторах — это не только отказ сервиса, но и внезапный счёт: часть запросов всё же проходит и тарифицируется.
• Деградация вместо ошибки. Если ИИ-функция вспомогательная (саммари, теги, подсказки), лучше показать интерфейс без неё, чем экран с ошибкой. Пользователь простит отсутствие подсказки и не простит белую страницу.
• Асинхронность там, где можно. Генерацию описаний товаров, разбор писем, обработку заявок стоит держать в очереди с повторной обработкой: трёхчасовой сбой такая схема переживает незаметно для пользователя.
• Кэшируйте. Одинаковые запросы к модели — частая история; кэш ответов заодно экономит деньги в обычные дни.
• Подпишитесь на статусные страницы провайдеров и заведите свой синтетический мониторинг: узнавать о сбое от клиентов — худший вариант.
• Заранее напишите текст уведомления. Готовый баннер «внешний ИИ-сервис недоступен, работаем над этим» снимает половину обращений в поддержку.

Что дальше

Ни SpaceXAI, ни Anthropic, ни OpenAI не опубликовали подробного разбора инцидента с техническими деталями. Илон Маск сообщил, что меры будут приняты, но конкретики не привёл. Для отрасли это неудобный сигнал: по мере того как обучение и инференс концентрируются в считанных гигантских кластерах, вероятность «одновременного» падения нескольких независимых на вид сервисов будет только расти.

Практический вывод для команд простой: относитесь к ИИ-провайдеру как к внешней зависимости с реальным SLA, а не как к вечно доступной функции языка. И проверьте, где физически живёт ваш запасной вариант, — до того, как это выяснится в понедельник утром.