Сбои ChatGPT, Claude и Grok: что известно по открытым данным

Почти одновременные ошибки у Grok, ChatGPT/Codex и Claude закономерно породили подозрение в масштабном общем сбое ИИ-инфраструктуры. Однако открытые данные позволяют сделать более узкий вывод: инциденты пересекались по времени, но провайдеры назвали разные причины, а подтверждений единого каскада между всеми тремя сервисами нет.

Что подтверждено по каждому сервису

Grok: подтверждённый сбой вычислительного центра в Мемфисе

SpaceXAI сообщила, что проблемы Grok были вызваны сбоем в её вычислительном центре в Мемфисе, и извинилась перед затронутыми «вычислительными партнёрами». По сообщениям СМИ, неполадки Grok начались примерно в 6:30 по тихоокеанскому времени и продолжались более трёх часов, после чего работа систем была восстановлена. 3941

Это прямое подтверждение инцидента на площадке в Мемфисе и того, что его последствия не ограничились Grok. Но публично не названы ни затронутые партнёры, ни техническая причина сбоя, ни внешние сервисы, если таковые размещались на этих мощностях.

ChatGPT и Codex: подтверждённая ошибка маршрутизации

OpenAI объяснила сбой ChatGPT и Codex ошибкой маршрутизации, начавшейся примерно в 7:43 по тихоокеанскому времени 3 сентября. Около 8:17 PT компания внедрила решение и затем продолжила наблюдать за восстановлением. 39

Это подтверждает проблему на стороне инфраструктуры OpenAI. Однако из этого не следует, что инцидент в Мемфисе стал причиной неполадок OpenAI.

Claude: повышенная частота ошибок и восстановление, но без подробного публичного разбора причин

На странице статуса Anthropic зафиксированы повышенные ошибки у нескольких моделей Claude; воздействие завершилось в 9:16 PT / 16:16 UTC. 33 В материалах того дня событие описывалось как частичный сбой, вызванный инфраструктурной проблемой. 28

При этом доступные публичные материалы не раскрывают детальную первопричину и не устанавливают связь инцидента Claude с мемфисским центром. Корректная формулировка такова: у Claude был реальный и устранённый сбой, но его причина остаётся нераскрытой на уровне доступных публичных деталей.

Совпадение во времени не доказывает общую причину

Сервисы не отказали в один документально зафиксированный момент. Проблемы Grok, согласно сообщениям, начались раньше; OpenAI указала окно ошибки маршрутизации с 7:43 до 8:17 PT; Anthropic сообщила об окончании воздействия на Claude в 9:16 PT. 3339

Для пользователей это пересечение было вполне ощутимым: в один период сразу несколько популярных ИИ-сервисов работали нестабильно. Но временная корреляция не устанавливает техническую причинность. Общая зависимость, переток трафика или цепная реакция остаются гипотезами, пока сами провайдеры не опубликуют подтверждающие данные.

Что остаётся недоказанным

Доступные сведения не подтверждают:

• единый каскадный отказ Grok, ChatGPT/Codex и Claude;
• использование OpenAI или Anthropic производственных мощностей инференса на затронутой площадке в Мемфисе;
• участие Azure, Cloudflare или другого конкретного облачного, CDN- либо сетевого провайдера как общей причины;
• проверенное общее число затронутых пользователей на основе сайтов с пользовательскими жалобами о сбоях;
• что конкретный сбой Cursor, прерывание работы кодового агента или иной нижележащий процесс был вызван именно этими инцидентами, а не проблемой интеграции, авторизации, очереди, лимитов запросов, сети или клиентского приложения.

Страница статуса Cursor действительно сообщала о повышенных ошибках у моделей OpenAI и Anthropic. Это может объяснять часть проблем пользователей Cursor через сбой вышестоящего провайдера, но само по себе не доказывает причину каждого неудачного запуска агента или клиентского процесса. 30

Главный урок: несколько моделей не означают настоящую отказоустойчивость

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

Иными словами, разнообразие провайдеров на уровне API не обязательно означает независимость инфраструктуры. Резервная модельная конечная точка полезна лишь тогда, когда окружающие зависимости тоже переживут рассматриваемую аварию.

Как подготовиться к многочасовым сбоям ИИ-провайдеров

Составить карту всей цепочки зависимостей

Поддерживайте карту сервисов, где указаны все критически важные зависимости: API модели, шлюз, облачный регион, DNS/CDN, система идентификации, векторная база данных, очередь, хостинг кода, интеграции с инструментами и стек наблюдаемости. Отдельно фиксируйте как подтверждённых субподрядчиков, так и существенные неизвестные.

Проверять резервные сценарии на реальной нагрузке

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

Проектировать агентов так, чтобы они безопасно останавливались

Используйте тайм-ауты, ограниченные повторы с джиттером, автоматические предохранители, ключи идемпотентности, устойчивые контрольные точки и явную логику паузы и возобновления. Необратимые действия должны требовать одобрения человека. После сбоя агент должен продолжать работу из сохранённого состояния, а не повторно создавать развёртывание, покупку, заявку или вызов внешнего API.

Заранее определить деградированные режимы

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

Улучшить взаимодействие с поставщиками и сбор доказательств об инцидентах

Подпишитесь на статус-уведомления поставщиков и согласуйте каналы эскалации, ожидания по уведомлениям, требования к отчётам по итогам инцидентов и условия переноса данных — если это позволяет договор. Во время сбоя сохраняйте метки времени в UTC, идентификаторы запросов, заголовки ответов, тела ошибок, трассировки, записи о маршрутизации, состояние агентов, журналы очередей и снимки страниц статуса. Эти данные критичны, чтобы отделить сбой внешнего провайдера от ошибки в собственной интеграции.

Добиваться независимости там, где цена ошибки высока

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

Вывод

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