Почему self-hosted LLM падает в проде

В сфере искусственного интеллекта произошло заметное событие. pandy 12 минут назад Почему self-hosted LLM падает в проде Уровень сложности Средний Время на прочтение 14 мин Охват и читатели 262 Блог компании Битрикс24 DevOps * Искусственный интеллект Кейс Привет! Меня зовут Андрей Пахомов, я разработчик в AI Platform Битрикс24. Сегодня расскажу, почему self-hosted LLM ломается в проде, где на самом деле возникают проблемы и какие метрики помогают вовремя это увидеть.

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

Технические детали

Мы расширили его с 64k до 85k и сняли 73. 5% ошибок прежней конфигурации. Но заметный хвост запросов продолжил падать.

Это наглядно показывает: точечные улучшения не решают проблему целиком, если вы не понимаете, где именно система деградирует и почему. TL;DR — краткое саммари по статье Для стабильной эксплуатации self-hosted LLM достаточно базового набора из пяти метрик: queue depth; active workers; processing latency; TTFB; потребление ОЗУ контейнером воркера. Очередь между API и инференсом полезна не только для backpressure, но и потому, что делает деградацию наблюдаемой.

Увеличение контекстного окна помогает, но само по себе не решает класс проблем: по нашим логам переход с 64k на 85k закрыл 73. 5% ошибок, а верхний хвост остался. Предобработка во воркере может привести к тем же сбоям, что и перегруженный GPU-пул, поэтому за памятью воркеров нужно следить так же внимательно, как за latency.

Отраслевые последствия

MaaS vs Self-hosted: когда свой стек действительно оправдан Когда команда обсуждает запуск LLM у себя, разговор обычно начинается с качества ответов и заканчивается бюджетом на GPU. Но на практике сначала нужно решить более приземлённый вопрос: где физически и юридически живут данные. Если в запросах есть ПДн, коммерчески чувствительная информация или внутренние документы, внешний MaaS означает не только технический, но и комплаенс-риск.

MaaS выигрывает скоростью запуска: зарегистрировались, получили API-ключ, интегрировали за пару дней. Для MVP это отличный путь. Если ваши запросы нерегулярные, в них мало чувствительных данных и нет жёстких требований к периметру, MaaS почти всегда дешевле по времени команды.

Self-hosted выигрывает в других сценариях: Чувствительные данные в промптах. Если в запросах есть клиентские документы, внутренние отчёты, кейсы поддержки или персональные данные, контроль периметра становится критичным. Предсказуемость нагрузки.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.