Битрикс24 описала, что строят вокруг собственной LLM на 1 трлн параметров

Битрикс24 рассказала на Saint HighLoad++, что начинается после слов «мы развернули свою LLM» на 1 трлн параметров. Одни только веса такой модели занимают около 1 ТБ даже в FP8, то есть почти целый восьмиГПУ-сервер. На этом же железе одновременно работают чаты, обработка длинных документов и агенты. В анонсе на Habr изложена лишь постановка задачи, подробности остались в полной статье. Ниже разбор того, какие инженерные вопросы за ней стоят.

Где кончается «просто»

Арифметика у проекта жёсткая. Один параметр в FP8 весит байт, и модель на 1 трлн параметров это около 1 ТБ памяти до первого запроса. В BF16 выйдет около 2 ТБ, в 4-битном виде около 0,5 ТБ. Восемь H200 дают 1128 ГБ HBM, так что весам в FP8 почти хватает одного узла, а под KV-кэш остаётся совсем немного. Поэтому платформа почти неизбежно упирается в распараллеливание по нескольким узлам и в экономию памяти.

В самой модели при этом нет ничего сложного: открытые веса такого масштаба существуют, как правило, это MoE-архитектуры, где на токен активна лишь часть параметров. Основная работа начинается вокруг неё, и именно ей посвящён доклад.

Три нагрузки на одних GPU

Автор исходит из того, что мощности делят три разных типа трафика, и у каждого свои требования:

• Чаты. Короткие запросы, пользователь смотрит на экран. Важны время до первого токена и стабильная скорость генерации.
• Длинные документы. Тяжёлая стадия prefill, которая может надолго занять GPU и затормозить соседей.
• Агенты. Цепочки из десятков вызовов, часто с общим префиксом. Критична пропускная способность, а отдельная задержка не так важна.

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

Оптимизации и риск тихой деградации

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

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

Что проверить до запуска

Тем, кто смотрит в сторону собственной крупной модели, стоит пройти по короткому списку:

• Посчитать память: веса, KV-кэш при реальной длине контекста и запас под пики.
• Разделить трафик по классам и заранее договориться, какой класс можно задерживать.
• Определить, чем будет заполняться простой, и как эти задачи прерываются.
• Собрать собственный набор оценки качества до первой оптимизации, а не после.
• Измерять не только среднюю скорость, но и хвосты задержек: p95 и p99 для чатов, пропускную способность для агентов.

Главная мысль доклада в том, что собственная LLM на 1 трлн параметров это платформа с планировщиком, очередями и системой контроля качества, а не одна модель на сервере. Конкретные цифры нагрузки и конфигурацию кластера Битрикс24 раскрывает в полной версии материала на Habr.