Как встроить локальную LLM в прод: от выбора модели до мониторинга токенов
Локальный прод делает нас независимыми от внешних API: капризы провайдеров, модерация, отключения или апдейты моделей больше не ломают воркфлоу. Но хайп вокруг локальных моделей часто разбивается о суровую реальность стоимости железа и поддержки. Разбираемся, из чего состоит инфраструктура прода для локальных LLM, что важнее — размер модели или TPS и какие метрики нужно вывести на дашборд, чтобы ничего не упало.
3К открытий8К показов
Зачем вообще городить свой прод
Поднимая модель внутри своего контура, вы получаете контроль и автономию. Данные не уходят на сервер третьей стороны и можно спокойно работать с чувствительными данными и внутренними документами под NDA, не рискуя, что они утекут в логах провайдера.
Горячий аргумент в пользу локальных LLM от юзеров Reddit: пока внешние LLM относительно нейтральны, но это временно. Как только рынок окончательно созреет — корпорации будут закручивать гайки, чтобы зарабатывать больше.
Внешний API — это зависимость. Провайдер может в любой момент поменять правила игры: повысить тарифы, вывести старую модель из эксплуатации, ужесточить модерацию или ограничить доступ в определённом регионе. Качество ответов тоже не гарантировано: апдейты могут ухудшить выдачу, а сервисы могут падать в самый неподходящий момент — как это было с OpenAI API из-за сбоя у Cloudflare в ноябре 2025 года.
Стоимость API. Если у компании очень много запросов, счёт может выйти в копеечку. Локальная модель на собственном сервере — это понятный набор расходов: железо + электричество + обслуживание, который окупается с ростом нагрузки.
Ну и главный плюс on-premise LLM: вы сами решаете, когда обновляться, какие фильтры включать, как модель отвечает, и при желании дообучаете её на своих данных под нужный tone-of-voice.
Как выбрать модель и не пожалеть
Выбирая самую «крутую» модель из лидерборда, можно легко попасть в ловушку. Рейтинги моделей — это усреднённая температура по больнице. Модель может блистать на общих бенчмарках, но провалиться на вашем внутреннем датасете. На практике ориентируйтесь не на хайп, а на три принципа:
Размер имеет значение: больше ≠ лучше
Размер модели напрямую влияет на её возможности. Обычно чем она больше, тем лучше справляется с задачами. Но у этого есть обратная сторона: крупным моделям нужно значительно больше GPU-памяти, а значит — они дороже в обслуживании и поддержке. Если планируете поднимать локальную модель, оцените свои возможности в локальной развёртке моделей: сколько суммарно видеопамяти вообще есть (или сколько она будет стоить), и какой размер модели можно на ней поднять. Естьсервис, где это можно рассчитать:https://huggingface.co/spaces/Vokturz/can-it-run-llm
TPS решает: сколько токенов модель выдаёт в секунду
Скорость работы измеряют по показателю TPS (token-per-second) — сколько токенов (считай символов) генерируется в секунду. Чем больше LLM, тем дольше она отвечает. Обычно 15 TPS — это оптимальное значение для заданной пропускной способности.
Сейчас есть модели с архитектурой MOE (Mixture of Experts), которые во время инференса активируют только часть нейронов. За счёт такого строения модели работают быстрее и не сильно теряют в качестве.
Например, Qwen3-235B-A22B по скорости работает на уровне 14B-модели, но качество ответов намного лучше. Но и маленькие модели не стоит недооценивать — на узких задачах они не уступают своим собратьям побольше, но работают намного быстрее.
Качество на задаче: проверяем на своих данных
В идеальном мире под каждую задачу нужно подбирать или обучать определённую модель, которая умеет хорошо решать конкретно эту задачу. На практике не всегда достаточно ресурсов, чтобы поддерживать столько разных моделей. Качество работы можно оценить по публичным бенчмаркам, близким к вашей задаче. Например, если вы решаете задачу Text2SQL, можно проверить модели и статьи, которые ссылаются на бенчмарк Spider. Но всё же публичные лидерборды стоит учитывать только для первичного отбора моделей и подходов. Лучше собирать свой внутренний бенчмарк и оцениваться в нём.
Протестить open-source модель до того, как закупать железо можно на платформеopenrouter.ai. Обычно модели появляются там через несколько дней после релиза.
Инфраструктура, инструменты, мощности: с чего начать
После того как вы определились с моделью, нужно продумать инфраструктуру и инструменты для инференса. Инференс — это использование модели на практике: когда она получает запрос и генерирует ответ.
Чтобы выстроить минимальный, но надёжный прод для локальной LLM, нужны прямые руки DevOps, настроенный сервер/кластер с Nvidia CUDA и большое желание дебажить. Как собрать такой прод:
🎬 Видеолекция от Мичила Егорова: «Построение инфраструктуры для работы с LLM: опыт X5 Tech»
vLLM
vLLM — высокопроизводительная и удобная библиотека для инференса и обслуживания LLM. Изначально разработана в лаборатории Sky Computing Lab Калифорнийского университета в Беркли.
С чего начать:
- Запуск моделей с открытым исходным кодом: Quickstart Guide.
- Создание приложений с vLLM: User Guide.
- Сборка vLLM: Developer Guide.
llama.cpp
llama.cpp позволяет запускать LLM с минимальной настройкой и по словам разработчиков обеспечивает высокую производительность на разных устройствах — локально и в облаке. Изначально была задумана как библиотека на C/C++ для запуска модели LLaMA.
С чего начать:
- Установка llama.cpp через brew, nix или winget.
- Запуск с Docker.
- Сборка из исходного кода: руководство.
Triton Inference Server
Triton Inference Server — высокопроизводительная платформа от Nvidia для инференса моделей. Поддерживает разнообразные фреймворки (TensorFlow, PyTorch, ONNX, OpenVINO и др.) и позволяет масштабировать модели в продакшне с минимальной доработкой кода.
С чего начать:
- Установка через Docker.
- Установка без контейнеров Docker.
- Сборка из исходного кода: руководство.
Где взять мощности для GPU
Главный вопрос локального продакшна — видеопамять. От её объёма и пропускной способности зависит, сможете ли вы поддерживать стабильный отклик и масштабировать систему. Есть два основных пути: аренда мощностей в облаке или сборка собственного сервера/кластера с GPU.
Перед тем как выбирать стратегию хостинга, стоит заранее прикинуть аппетиты выбранной модели. Нельзя купить видеокарту «на глаз»: если модель не влезет в память, она просто не запустится, а если влезет «впритык» — будет падать при длинных диалогах.
🖩 Инструмент: Can you run it? LLM version — калькулятор VRAM для LLM.
Если у вас стартап — не спешите поднимать свои модели. Современные LLM API закрывают множество задач, вплоть до дообучения LoRa на своих данных. Если вы собираете свой первый продукт — лучше сконцентрироваться на сборе внутреннего бенчмарка, а про локальные LLM подумать уже позже.
Для быстрого старта без вложений в собственное железо можно воспользоваться готовыми облачными GPU‑сервисами.
☁️ Подборка: Где арендовать GPU в 2025: подборка GPU‑хостингов с адекватной ценой и SLA
Собственный сервер требует огромных вложений в моменте и дорог в обслуживании, может долго окупаться и быстро устареть. Я бы не советовал этот путь, если вы еще не определились, что конкретно будете решать, и как скоро можете окупить затраты.
Если ожидается экспоненциальное увеличение нагрузки (например, в стартапе), то лучше арендовать мощности. Если же нагрузка в ближайшее время не увеличится, вы знаете, как окупать эти инвестиции, и хотите играть на долгий срок — лучше идти в сторону своего сервера.
Мониторинг
Недостаточно следить только за общим состоянием сервера и контейнера — жив ли он, какое время ответа, сколько запросов делается в секунду, насколько заполнены диски. Важно отслеживать показатели, связанные с процессом генерации:
- TPS и TPM (token-per-second и token-per-minute) — скорость генерации токенов.
- Размер очереди на генерацию — количество запросов, ожидающих обработки. Если очередь растёт, это означает, что текущей мощности недостаточно для поступающей нагрузки.
- Заполненность KV Cache (пар «ключ-значение») — кэш промежуточных вычислений, ускоряющий работу модели.
В случае с vLLM всё это предоставляется из коробки в Prometheus.
Лимиты токенов
В локальной инфраструктуре мониторинг токенов выполняет две функции: контроль загрузки железа и стабильности. Модель на своём сервере не выставляет вам счёт за токены, но берет своё временем выполнения и энергозатратами.
Если не настроить лимиты и алерты, можно сжечь ресурсы впустую: некорректно сформированная или очень длинная генерация может занять весь GPU и заблокировать всю очередь, вытеснив другие задачи. Если задать лимиты — прод останется стабильным, даже если пользователи попытаются заставить LLM написать «Войну и мир».
В Х5 у каждого пользователя или сервиса есть квота на месяц и выставлены алерты. Также мы настраиваем ограничения по TPM (token-per-minute), чтобы избежать риска случайного или намеренного DDoSа моделей.
Типичные грабли инференса локальных LLM
Даже если прод собран аккуратно и модель подобрана идеально, локальный инференс всё равно подкидывает сюрпризы.
1. Китайские иероглифы и любые странные символы — они характерны для семейства моделей Qwen. На последних версиях такое возникает реже, но раньше промпт не излечивал полностью это поведение. Это можно исправить корректировкой генерации декодера: мы настраивали guided generation и обнуляли вероятности генерации китайских символов.
2. Неправильно подобранные системные токены. Они обозначают начало и конец генераций конкретных ролей (user, assistant, tool etc). Для разных типов моделей, и даже внутри одного типа (Mistral, Qwen, Llama, и др.) системные токены различаются. Например, при смене семейства моделей можно забыть исправить системные токены. А если использовать «чужие» токены или не использовать их вовсе, качество моделей сильно проседает, поэтому нужно внимательно за этим следить.. 3. Перезаполнение памяти. Каждая отдельная генерация и kv cache занимает какое-то количество видеопамяти. Если не уследить, то в какой-то момент память GPU может перезаполниться и весь контейнер упадёт. Поэтому нужно внимательно отслеживать заполнение и ставить лимиты на генерацию, чтобы этого не происходило.
3К открытий8К показов





