Своя LLM в компании — это не модель на сервере, а сервис вокруг неё: раздельные пулы видеокарт под разные типы нагрузки, планировщик с очередью и отложенными задачами, шлюз с правами и квотами, роутеры запросов и обязательная проверка качества после каждого изменения. Такой вывод делает Сергей Нотевский, AI Platform Lead Битрикс24, в разборе от 12 октября 2026 года. Его главная мысль для бизнеса: переезд с внешнего API на свои мощности сам по себе не делает токен дешевле — очереди, кэширование и обработка пиков становятся вашей работой и входят в себестоимость.
Материал подготовлен AIrassvet 13 октября 2026 года по публикации Битрикс24 на Хабре и документации движка vLLM. Он адресован ИТ-директорам, техническим директорам и руководителям, которые выбирают между внешним API и развёртыванием языковой модели на своих серверах. Это практический разбор: что придётся построить, в каком порядке и как проверить готовность. Мы не тестировали инфраструктуру Битрикс24 и не приводим её конфигурацию — в исходной статье её нет. AIrassvet не аффилирован с Битрикс24 и разработчиками vLLM; раздел в конце статьи описывает услуги издателя.
Содержание
- Кратко: что нужно своей LLM, кроме самой модели
- Почему тема стала актуальной
- Внешний API или своя модель: что меняется
- Карточка модели и прод: что проверить до запуска
- Почему один общий пул GPU не работает
- Пулы по профилю нагрузки
- Планировщик, очередь и отложенные задачи
- Шлюз: права, квоты, учёт и псевдонимы моделей
- Семантический роутер и кэш-роутер
- Quality Gate: как не испортить ответы оптимизацией
- Что из этого нужно компании среднего размера
- Чек-лист готовности к self-hosted LLM
- Частые вопросы
- Первоисточники и метод проверки
Кратко: что нужно своей LLM, кроме самой модели
- Проверка модели до запуска: контекст при рабочей параллельности, память не только под веса, но и под KV-cache, совместимость API и вызовов инструментов, лицензия.
- Пулы по профилю нагрузки: быстрый интерактив, длинный контекст и многошаговые агентские задачи — отдельно, с разными лимитами.
- Планировщик: решает, выполнить запрос сейчас, поставить в очередь или отложить до свободных мощностей.
- Шлюз: права доступа, квоты команд и сценариев, учёт расходов, постоянные псевдонимы моделей.
- Роутеры: семантический выбирает путь запроса, кэш-роутер — реплику с уже прогретым префиксом.
- Quality Gate: сравнение текущей конфигурации и изменения на продуктовых сценариях перед каждой выкаткой.
Почему тема стала актуальной
12 октября 2026 года Битрикс24 опубликовал на Хабре статью «Давайте просто развернём свою LLM на 1Т параметров»: что пришлось построить вокруг неё. Автор — Сергей Нотевский, AI Platform Lead Битрикс24; материал основан на его докладе на конференции Saint HighLoad++ в июне. По словам автора, ИИ в продуктах компании работает в CRM, чатах, генерации сайтов и агентах: например, после звонка модель готовит саммари, заполняет карточку CRM и оценивает качество разговора.
Ценность разбора в том, что он описывает не выбор модели, а путь «от продукта с одним endpoint до платформы вокруг моделей» — то, с чем сталкивается любая компания после первого успешного пилота. Какие модели и какое железо выбрать для локального запуска, мы разбирали отдельно в обзоре «Локальные LLM в 2026 году: модели, железо и стоимость». Эта статья — о том, что происходит после запуска.
Внешний API или своя модель: что меняется
Внешний API (MaaS, model-as-a-service) — модель запускает провайдер, а компания платит за токены. Self-hosted — модель работает на мощностях компании или в арендованном контуре, и вся эксплуатация становится её задачей. Битрикс24, по словам автора, начинал с внешних API и при переходе сравнивал варианты по трём осям: данные, гибкость и экономика.
| Ось | Внешний API | Своя модель |
|---|---|---|
| Данные | Нужно решить, какие данные можно передавать провайдеру и где он их обрабатывает | Обработка в своём контуре; требования к данным определяют и допустимые резервные пути |
| Гибкость | Модели, лимиты и приоритеты задаёт провайдер | Свой выбор моделей, лимитов и приоритетов под сценарии |
| Экономика | Оплата за токены; очереди, кэш и пики скрыты за API | Мощности оплачены и в простое; очереди, кэш и пики — ваша работа и ваша себестоимость |
Таблица составлена нами по тексту разбора. Ключевой тезис автора: на стабильной нагрузке есть смысл сравнивать цену API с расходами на мощности и команду, но сам по себе переезд не означает, что токен стал дешевле. Полное сравнение стоимости владения мы приводили в статье «Облачная или локальная LLM: расчёт TCO».
Карточка модели и прод: что проверить до запуска
Обычно всё начинается с карточки модели на Hugging Face: контекст, бенчмарки, требования к памяти. Автор показывает, что каждая строка карточки превращается в отдельный продуктовый вопрос:
| Что написано в карточке | Что нужно проверить для продукта |
|---|---|
| Максимальная длина контекста | Помещается ли нужный контекст при рабочей параллельности и сохраняется ли качество на длинных сценариях |
| Требования к памяти | Хватит ли ресурсов не только на веса, но и на KV-cache одновременно выполняемых запросов |
| Поддержка инструментов | Совместимы ли формат ответов, парсер и API-контракт с вашим приложением |
| Результаты бенчмарков | Решает ли модель ваши задачи на данных, похожих на продуктовые |
Источник таблицы — статья Битрикс24.
KV-cache — это промежуточные вычисления модели по уже обработанному тексту, которые хранятся в памяти видеокарты, пока запрос выполняется. Чем длиннее контекст и чем больше одновременных запросов, тем больше памяти он занимает. Поэтому модель, которая «помещается» на видеокарту по весам, может не выдержать рабочую нагрузку.
Ещё три проверки до запуска, которые называет автор:
- движок инференса может запускать модель, но не поддерживать нужный формат API или ожидаемую оптимизацию;
- формат весов нужно сопоставить с доступным оборудованием;
- лицензия: условия коммерческого использования проверяют до того, как продукт начнёт зависеть от модели; возможность скачать веса этот вопрос не закрывает.
И главное правило выбора размера: если компактная модель справляется, нет смысла занимать дорогой вычислительный пул. Считать нужно стоимость законченной задачи, а не одного вызова: дешёвый вызов мало помогает, если задачу потом приходится решать заново.
Почему один общий пул GPU не работает
Представьте, что в один пул видеокарт одновременно приходят короткий чат, обработка длинного документа и многошаговая агентская задача. Автор объясняет, почему они мешают друг другу:
- Длительность нельзя предсказать по входу. Модель может ответить парой слов или уйти в длинное рассуждение, и всё это время запрос занимает память и место среди выполняемых.
- Лимит параллельности общий. Когда он занят, следующий запрос ждёт — даже если это короткая реплика в чате.
- Число запросов не равно объёму работы. За одним действием пользователя может стоять несколько обращений к модели, а у агента число шагов зависит от хода решения.
Почему бы просто не добавить реплик? Свободные мощности ещё нужно получить, загрузить веса, подготовить окружение и убедиться, что реплика готова принимать запросы. Всплеск интерактивной нагрузки может случиться быстрее. Поэтому запас мощностей нужен заранее, и планировать его приходится с учётом того, какая работа попадёт в пул.
Пулы по профилю нагрузки
Битрикс24 разделяет нагрузку по тому, что ограничивает её выполнение:
| Пул | Что важно | Особенность |
|---|---|---|
| Быстрый интерактив | TTFT — время до первого токена — и скорость ответа | Нужен резерв, даже если часть мощностей простаивает |
| Длинный контекст | Много памяти под KV-cache | Ограничивает допустимую параллельность |
| Многошаговые задачи | Длительность зависит от цепочки вызовов и объёма генерации | Требования к ожиданию задаёт сам сценарий |
Одна и та же модель может работать в разных пулах, если сценариям нужна изоляция нагрузки: выбор модели и выбор пула — разные решения.
Сколько запросов выполнять одновременно в каждом пуле, подбирают по поведению очереди и задержки при росте нагрузки. Автор подчёркивает: средняя утилизация видеокарт не говорит, что у чата всё хорошо — смотреть нужно на то, сколько ждут запросы в «хвосте» распределения. А бесконечно дробить пулы тоже нельзя: в одном мощности простаивают, в соседнем стоит очередь.
Планировщик, очередь и отложенные задачи
Планировщик — это компонент, который получает запрос с метками сценария, требованиями ко времени ответа и примерной оценкой объёма работы и решает: выполнить сейчас, поставить в очередь или отложить. Если в нужном пуле есть место, задача выполняется; если лимит занят — ждёт; если результат не нужен пользователю прямо сейчас — откладывается.
Как работают отложенные задачи в схеме Битрикс24:
- сохраняются входные данные и срок выполнения;
- HTTP-соединение до завершения не держится;
- планировщик возвращает задачу в работу, когда появляются свободные мощности или приближается срок;
- результат доставляется отдельно.
Так появляется полезная работа для мощностей между пиками: задачи, которые допускают ожидание, выполняются в менее загруженные часы. Но объём отложенной работы ограничивают с учётом очереди, задержек и резерва каждого пула — иначе она снова начнёт мешать интерактиву. Для бизнеса это прямой ответ на вопрос из чек-листа автора: «Чем вы займёте мощности между пиками?» — например, ночной обработкой документов, разметкой звонков или переиндексацией базы знаний.
Шлюз: права, квоты, учёт и псевдонимы моделей
Когда моделью пользуются несколько команд и продуктов, у каждого запроса появляется владелец. Перед планировщиком в схеме Битрикс24 стоит шлюз (Gateway) с четырьмя задачами:
- Доступы: определить потребителя и его права.
- Квоты: применить лимиты команды и сценария до отправки на исполнение.
- Учёт и трассировка: связать расход ресурсов с запросом, командой и сценарием.
- Псевдонимы: дать продукту постоянное имя модели, за которым её можно заменить без релиза самого продукта.
Учёт нужен не только для отчётов: по нему сравнивают потребности команд, понимают профиль нагрузки и обсуждают лимиты. Одна общая сумма расходов для этого почти ничего не говорит. Подобную роль в небольших проектах играют готовые шлюзы с открытым кодом — например, LiteLLM даёт единый OpenAI-совместимый адрес, виртуальные ключи с бюджетами и учёт расходов по командам.
Семантический роутер и кэш-роутер
В схеме два разных роутера, и путать их не стоит.
Семантический роутер выбирает путь запроса до постановки в очередь: обычный ответ, обращение к более сильной модели или работа с инструментами. Одной последней реплики для этого мало: «Да, давай» в начале разговора и после предложения выполнить действие — разные запросы. Роутер учитывает контекст, намерение, необходимость поиска или инструментов и ожидаемый объём работы; повторный вопрос может означать, что прошлый ответ не подошёл. О том, как устроены роутеры моделей в бизнес-сценариях, мы писали в статье «Роутер моделей ИИ для бизнеса».
Кэш-роутер выбирает реплику внутри уже выбранного пула. Механика такая: если начало нового запроса совпадает с уже обработанным, общую часть можно не считать заново. По документации vLLM, автоматический prefix caching переиспользует KV-cache запросов с общим префиксом; это ускоряет обработку входа, но не генерацию ответа, и не даёт выигрыша, если префиксы не совпадают или ответы длинные. Типичные выигрышные сценарии — многократные вопросы по одному длинному документу и длинные диалоги.
Нюанс, на который указывает автор Битрикс24: стабильный префикс бесполезен, если следующий запрос попал на другую реплику, где этого префикса нет. Поэтому кэш-роутер учитывает, есть ли на реплике нужный префикс, сколько на ней выполняется запросов и насколько заполнена память. Иногда выгоднее выбрать свободную реплику и пересчитать префикс. И ещё одно уточнение: переиспользованный префикс экономит вычисления, но его KV-cache всё равно занимает память во время генерации.
Quality Gate: как не испортить ответы оптимизацией
Один из способов уменьшить расход памяти — хранить KV-cache с меньшей точностью. Документация vLLM описывает квантование KV-cache в формат FP8: это уменьшает занимаемую память, позволяет держать больше токенов и поддерживать более длинный контекст. Но вычисления при этом меняются. В примере из доклада Битрикс24 на коротком контексте изменение укладывалось в требования к качеству, а на длинном — уже нет. Вывод автора: такое решение принимают отдельно для каждого сценария, и по задержке или расходу памяти его не оценить.
Quality Gate — это обязательное сравнение двух прогонов на одних и тех же продуктовых датасетах: текущей конфигурации (baseline) и предлагаемого изменения (candidate). Поводы для проверки, по словам автора, появляются и без замены модели:
- обновили движок — могли измениться парсер, чат-шаблон или зависимости;
- поменяли параметры запуска, точность вычислений или работу с контекстом;
- поправили политику семантического роутера — запрос стал попадать в другую ветку;
- изменили выбор реплик — поменялись локальность кэша и задержки.
Как устроена проверка:
| Тип проверки | Что проверяют | Чем |
|---|---|---|
| Формальная | Валидный ли JSON, допустимые ли значения, корректны ли вызовы инструментов | Кодом |
| Содержательная | Совпадение с эталоном, соответствие критериям продукта | Сравнением и LLM-судьёй |
| Эксплуатационная | Задержки и стоимость выполнения | Метриками прогона |
По итоговому диффу решают: выкатывать изменение, проверить на ограниченном трафике или заблокировать. Важная деталь: свои сценарии в датасет добавляют продуктовые команды, а если в наборе только короткие запросы, о длинном контексте вы ничего не узнаете.
Что из этого нужно компании среднего размера
Схема Битрикс24 выросла из масштаба продукта с множеством команд. Компании, которая запускает одну-две внутренние ИИ-функции, весь набор сразу не нужен. Ниже — наша редакционная схема поэтапного развития; она не взята из статьи Битрикс24, а выведена из её логики «добавляем блок, когда предыдущего перестаёт хватать».
| Этап | Признак | Что добавить |
|---|---|---|
| 1. Один сценарий | Одна функция, предсказуемая нагрузка | Проверка модели по карточке и на своих данных, лицензия, базовый мониторинг очереди и задержек, небольшой набор эталонных вопросов |
| 2. Несколько сценариев | Чат мешает обработке документов, появляются жалобы на ожидание | Разделение пулов или лимитов по профилю нагрузки, отложенные задачи для фоновой работы |
| 3. Несколько команд | Непонятно, кто сколько тратит и почему растёт нагрузка | Шлюз с правами, квотами, учётом и псевдонимами моделей |
| 4. Агенты и разные модели | Запросам нужны разные модели и инструменты | Семантический роутер, кэш-роутер при нескольких репликах |
| Всегда | Любое изменение модели, движка или параметров | Quality Gate на продуктовых сценариях |
Если нагрузка короткая и редкая, автор советует честно посчитать, сколько времени мощности будут простаивать: в таком случае внешний API или инференс open-source моделей в облаке может оказаться разумнее. Варианты такого размещения мы разбирали в статье «Инференс open-source LLM в российском облаке».
Чек-лист готовности к self-hosted LLM
Первые пять вопросов сформулированы автором Битрикс24, остальные — дополнение AIrassvet.
- Данные. Какие требования к данным ограничивают выбор места обработки? Они же определяют, какие резервные пути допустимы.
- Качество. Можете ли вы запустить на доступных мощностях модель с нужным для ваших задач качеством?
- Загрузка. Чем вы займёте мощности между пиками?
- Команда. Кто будет поддерживать модели и движки, проверять API-контракты, настраивать пулы и разбирать регрессии?
- Регрессии. Как вы заметите ухудшение ответов после обновления?
- Лицензия. Разрешает ли лицензия модели ваше коммерческое использование?
- Метрики. Измеряете ли вы время до первого токена и ожидание в хвосте очереди, а не только среднюю загрузку?
- Датасет. Есть ли у вас набор продуктовых задач с эталонами, включая длинный контекст и вызовы инструментов?
- Резерв. Что произойдёт с пользователями, если пул или реплика выйдут из строя? Подробнее — в статье об отказоустойчивости ИИ-сервисов.
Если на вопросы 2, 4 и 5 пока нет ответа, своё развёртывание преждевременно: начните с пилота на внешнем API или облачном инференсе и соберите датасет для будущего Quality Gate.
Частые вопросы
Станет ли дешевле, если развернуть LLM на своих серверах?
Не обязательно. Автор Битрикс24 подчёркивает, что переезд сам по себе не делает токен дешевле: мощности оплачены и в простое, а очереди, кэширование и обработка пиков становятся задачей компании. Сравнивать нужно цену API с расходами на мощности и команду при вашей реальной нагрузке.
Почему нельзя просто добавить видеокарт при росте нагрузки?
Новую реплику нужно получить, загрузить в неё веса, подготовить окружение и проверить готовность. Всплеск интерактивной нагрузки происходит быстрее, поэтому запас мощностей закладывают заранее и делят нагрузку по пулам.
Что такое KV-cache простыми словами?
Это промежуточные вычисления модели по уже прочитанному тексту, которые хранятся в памяти видеокарты, пока запрос выполняется. Чем длиннее контекст и больше одновременных запросов, тем больше памяти он занимает, поэтому именно он часто ограничивает параллельность.
Что такое prefix cache и когда он помогает?
Это переиспользование вычислений для общего начала запросов, например одинаковой инструкции или одного и того же документа. По документации vLLM, он ускоряет обработку входа, но не генерацию ответа, и помогает при повторных вопросах по длинному документу и в длинных диалогах.
Что такое Quality Gate для LLM?
Это сравнение текущей конфигурации и предлагаемого изменения на одних и тех же продуктовых датасетах с проверками кодом, сравнением с эталоном и LLM-судьёй. По результату изменение выкатывают, проверяют на части трафика или блокируют.
С чего начать компании, которая хочет свою LLM?
С одного сценария: проверьте модель на своих данных и при рабочей параллельности, прочитайте лицензию, соберите набор эталонных задач и настройте мониторинг очереди и задержек. Пулы, шлюз и роутеры добавляйте по мере роста числа сценариев и команд.
Первоисточники и метод проверки
Мы прочитали первоисточники 13 октября 2026 года. Описание архитектуры, решений и чек-листа готовности взято из статьи Битрикс24; конфигурацию оборудования и метрики автор не раскрывает, поэтому мы их не приводим. Сведения о prefix caching и квантовании KV-cache — из документации vLLM. Таблица этапов развития и дополнительные пункты чек-листа — редакционная методика AIrassvet, а не результат нашего тестирования.
- Сергей Нотевский, Битрикс24, Хабр, 12.10.2026: «Давайте просто развернём свою LLM на 1Т параметров»: что пришлось построить вокруг неё в Битрикс24 — пулы, планировщик, шлюз, роутеры, Quality Gate, чек-лист готовности.
- vLLM: Automatic Prefix Caching — механика и ограничения переиспользования префикса.
- vLLM: Quantized KV Cache — хранение KV-cache в FP8 и его влияние на память.
- LiteLLM: документация AI Gateway — пример готового шлюза с ключами, бюджетами и учётом расходов.
Ограничения: разбор описывает логическую схему одной крупной платформы без цифр по оборудованию и метрикам; применимость каждого блока зависит от вашей нагрузки; документация vLLM относится к конкретному движку и может меняться между версиями.
Как AIrassvet помогает развернуть свою LLM как сервис
Если вы решили запускать языковую модель в своём контуре, но хотите заранее понимать, какие блоки платформы нужны именно вам и как не потерять качество ответов при оптимизации, это стоит спроектировать до закупки мощностей. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:
- Развёртывание и дообучение языковых моделей на серверах компании, включая оптимизацию инференса.
- Интеграция моделей в бизнес-процессы и корпоративные ИИ-рабочие места.
- Аудит процессов и подготовка данных, в том числе продуктовых датасетов для проверки качества.
- Разработка MVP, тестирование, запуск, обучение команды и сопровождение.
Первый шаг — выбрать один сценарий, описать текущую нагрузку и требования ко времени ответа, перечислить ограничения по данным и сформулировать критерий, по которому вы признаете качество ответов своей модели достаточным.
Итог: модель — только начало платформы
Опыт Битрикс24 показывает, что своя LLM превращается в сервис только тогда, когда вокруг неё появляются раздельные пулы мощностей, планировщик с отложенными задачами, шлюз с квотами и учётом, роутеры и Quality Gate. Каждая оптимизация памяти или скорости может незаметно изменить ответы, поэтому проверка на продуктовых сценариях — не опция, а условие выкатки.
Начните с одного сценария и честного ответа на чек-лист: данные, качество, загрузка между пиками, команда и способ заметить регрессию. Добавляйте блоки платформы по мере того, как предыдущей схемы перестаёт хватать, и считайте не цену токена, а стоимость законченной задачи.
