Падение GigaChat: как три модели спасли нас от таймаутов

14:32, вторник. Приходит заявка на расчёт лизинга, спиннер крутится уже минуту, потом таймаут. Через три минуты в логах 142 ошибки и Slack орёт. GigaChat Pro отдавал 502, статус-page подтвердил инцидент. Клиентам, конечно, плевать на чужие проблемы — им нужен работающий сервис.

Мы подняли резерв за восемь минут без видимого даунтайма. Вот как это было устроено и где я раньше наступал на грабли.

Почему обычные ретраи не спасают

Сначала кажется: «поставим exponential backoff и будет ок». На практике ретраи просто жрут соединения и таймауты, когда модель лежит полностью. В первый серьёзный инцидент у нас из-за этого лёг даже FastAPI — запросы без LLM тоже встали. Вывод простой: ретраи — это про мелкие сетевые hiccup, а при полном падении нужен fallback на другом уровне.

Как у нас выглядит цепочка

Сейчас в проде три уровня:

• Основной — GigaChat Pro (лучшее качество и function calling).
• Резерв — YandexGPT 5 Pro (чуть слабее на сложном JSON, но стабильнее).
• Аварийка — self-hosted T-Lite на своём GPU (просто, независимо, но требует упрощённых промптов).

Каждый уровень — это не просто «слабее», а своя роль. Совать T-Lite промпт, заточенный под GigaChat, — верный путь к галлюцинациям.

Circuit breaker вместо try/except

Простой try/except здесь убивает latency: каждый запрос будет ждать таймаут основного провайдера (15–30 секунд), а потом только идти в резерв. Поэтому используем circuit breaker на Redis: считает ошибки за 60 секунд, при 5 подряд или 30 % ошибок открывается на 120 секунд и сразу шлёт трафик в Yandex. В тот день брейкер сработал к 14:33 и весь поток полетел мимо GigaChat.

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

Первая версия fallback технично переключалась, но по качеству была ужасной. Yandex на промптах под GigaChat начал оборачивать JSON в markdown и менять названия полей. Пришлось сделать три вещи:

• Отдельный промпт под каждую модель (версионируем).
• Слой нормализации: выдираем JSON из блоков кода, чиним опечатки и валидируем через Pydantic.
• Автогенерация описания function calls под синтаксис каждого провайдера.

После этого Yandex стал выдавать 94 % валидных ответов вместо 71 %.

Что получилось по цифрам

GigaChat лежал 38 минут. За это время:

• 87 % запросов успешно обработал YandexGPT,
• 10 % ушли на T-Lite после неудачной валидации,
• 3 % отправились оператору.

Средняя задержка выросла с 2.1 до 3.4 секунды, жалоб было всего четыре вместо ожидаемых 80–100. Три процента «человек разберётся» — это осознанный выбор: лучше честно сказать, чем отдать галлюцинацию.

Где подход не работает

Fallback не ловит проблемы качества (когда модель отвечает 200, но плохо). Тут нужны метрики качества и canary. Плюс Yandex дороже, поэтому держим алерт: если резерв тянет больше 20 % трафика дольше 10 минут — инженеру пинг.

Что стоит взять на вооружение

Если у вас один LLM-провайдер — это SPOF, который однажды выстрелит. Минимальный набор, который я бы закладывал сразу:

• два независимых провайдера,
• circuit breaker, а не try/except,
• промпты под каждую модель,
• слой нормализации ответов,
• путь «человек посмотрит» как последняя страховка.

Сейчас в российском ландшауме уже есть из чего собирать: GigaChat, YandexGPT, T-Lite, Saiga. Главное — не ждать вторника 14:32, чтобы понять, что плана Б нет.