Битрикс24 развернула LLM на 1Т параметров

В июне на конференции Saint HighLoad++ Сергей Нотевский, AI Platform Lead в Битрикс24, представил доклад «Давайте просто развернём свою LLM на 1Т параметров». В статье он описывает путь от простого продукта с одним endpoint до платформы, обслуживающей несколько сценариев. Основная сложность, по его словам, заключается в слове «просто»: после запуска модели начинается борьба за общие вычислительные ресурсы.

В Битрикс24 AI используется в CRM, чатах, генерации сайтов и агентах. Например, после звонка система помогает менеджеру получить саммари, заполнить карточку CRM и оценить качество разговора. За одним пользовательским запросом может стоять несколько обращений к модели, а у агента число шагов зависит от сложности задачи. Поэтому по количеству запросов в API трудно оценить реальную нагрузку на платформу.

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

При переходе на self-hosted задачи распределения запросов, очередей, кэширования и обработки пиков ложатся на плечи компании и входят в себестоимость. Сам переезд ещё не означает, что токен стал дешевле. Перед запуском модели необходимо проверить, помещается ли нужный контекст при рабочей параллельности, хватит ли ресурсов на веса и KV-cache, совместимы ли формат ответов и API-контракт с приложением, а также решает ли модель задачи на данных, похожих на продуктовые. Отдельно проверяется движок: он может запускать модель, но не поддерживать нужный формат API или оптимизацию.

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

Когда несколько сценариев одновременно используют общие мощности, возникает конкуренция. Чат, обработка длинных документов и многошаговые агенты предъявляют разные требования к задержке и памяти. По размеру входа нельзя заранее сказать, сколько времени займёт генерация: модель может ответить парой слов или уйти в длинный reasoning. Всё это время запрос занимает память и место среди выполняемых. Когда лимит параллельности занят, следующий запрос ждёт, даже если это короткая реплика в чате.

Для управления нагрузкой компания разделяет пулы по типу ограничений: быстрый интерактив (важны TTFT и скорость ответа), длинный контекст (требует много памяти под KV-cache) и многошаговые задачи (длительность зависит от цепочки вызовов). Разделив пулы, можно задать разные лимиты и оставить запас для интерактива. Однако бесконечно дробить пулы неэффективно: в одном мощности простаивают, в соседнем стоит очередь. Поэтому нужен планировщик, который получает запрос с метками сценария, требованиями ко времени ответа и оценкой объёма работы. Он управляет допуском работы к исполнению, может откладывать задачи, сохраняя входные данные и срок выполнения, и возвращать их в работу при появлении свободных мощностей или приближении срока.