Глава 14. Локальный запуск моделей

Учебник «Большие языковые модели»

Модели с доступными весами можно запускать на своём оборудовании — от ноутбука до GPU-кластера. Мотивы: данные (тексты можно удерживать в контролируемом периметре, если отключены внешняя телеметрия, сетевые зависимости и небезопасные логи), независимость (зафиксированную версию можно обслуживать, пока доступны артефакты, лицензия, оборудование и компетенции), экономика при больших стабильных объёмах (глава 16) и просто контроль: полный доступ к параметрам генерации, логитам, дообучение (глава 12). Плата — администрирование и железо. Глава о том, как оценить требования, чем запускать и что выбрать.

14.1. Арифметика памяти

Первый вопрос локального запуска — «влезет ли?», и отвечается он умножением. Веса: N параметров × b байт. В обучении и «полном» инференсе b = 2 (fp16/bf16): модель 8B — 16 ГБ, 70B — 140 ГБ. Квантизация (см. термин «Квантизация» в глоссарии) снижает разрядность хранения весов. Грубый размер равен числу параметров, умноженному на битность, плюс масштабы, метаданные и служебные буферы; поэтому 4-битный файл модели 8B занимает несколько гигабайт, но не ровно 4 ГБ. Потеря качества зависит от метода квантизации, модели и задачи: сравнивайте варианты на своём eval, а не переносите универсальный порог. Распространённые форматы: GGUF (экосистема llama.cpp), AWQ и GPTQ (GPU-серверы). Сторонний файл модели — элемент цепочки поставок: проверяйте источник, лицензию и контрольную сумму, предпочитайте безопасные форматы тензоров и осторожно относитесь к загрузке произвольного кода (например, trust_remote_code). К весам прибавьте KV-кэш — формулу и калькулятор мы вывели в главе 7; при длинных контекстах или большом числе запросов он может быть сопоставим с весами. Добавьте память активаций, буферов движка и запас под пик нагрузки; одной пропорции «миллиарды параметров = гигабайты» для выбора сервера недостаточно.

Оценка деградации от квантизации — не вопрос веры: прогоните свой eval (глава 13) на нужных вариантах и посмотрите на качество, память, пропускную способность и задержку.

14.2. Чем запускать

Инструменты делятся по сценарию.

Один пользователь / рабочая станция: llama.cpp и Ollama. llama.cpp — двигатель экосистемы: C++, GGUF, работает на CPU и поддерживает несколько GPU-бэкендов, включая Apple Silicon; совместимость зависит от сборки, модели и операций, умеет разделять слои между GPU и CPU, если модель не помещается в видеопамять целиком (ценой скорости — каждый слой на CPU заметно тормозит генерацию). Ollama — удобная обёртка над ним: реестр моделей, загрузка одной командой, управление версиями.

# Ollama: модель за одну команду
ollama run qwen3:8b "Объясни, что такое SSI, в двух предложениях."

# HTTP-сервис (OpenAI-совместимый) на 11434 порту
ollama serve

# llama.cpp напрямую: полный контроль
llama-server -m /path/to/model-q5_k_m.gguf \
             --ctx-size 16384 --n-gpu-layers 99 --port 8080

Оба предоставляют маршруты, совместимые с частью OpenAI API: см. документацию llama-server и Ollama. Это удобно для общего клиентского слоя, но не обещает полной совместимости: проверяйте нужные маршруты Responses/Chat Completions, потоковые события, схемы, инструменты, usage и chat template. Прозрачное переключение возможно только после интеграционных и качественных тестов.

Сервер под нагрузкой: vLLM. Для параллельных запросов многих пользователей нужен движок с непрерывной пакетизацией (continuous batching: запросы разной длины уплотняются в общие проходы GPU, повышая загрузку ускорителя) и эффективным управлением KV-кэшем (PagedAttention — страничная организация кэша, давшая имя проекту vLLM). Запуск столь же прост:

pip install vllm
vllm serve Qwen/Qwen3-8B --max-model-len 16384
# OpenAI-совместимый API на http://localhost:8000/v1

Для рабочей станции и простого локального сервиса часто начинают с Ollama или llama.cpp; для конкурентной серверной нагрузки рассматривают vLLM и аналоги. Выбор делают по профилю запросов и измерениям p50/p95 задержки, пропускной способности, памяти и стабильности.

14.3. Выбор модели под железо

Порядок действий: сначала определить требования к качеству, контексту, параллелизму и задержке; затем для каждой модели посчитать веса, KV-кэш и служебный запас; после этого проверить реально доступную сборку. Число параметров само по себе не предсказывает качество: имеют значение данные, архитектура, пост-обучение, язык и квантизация. Кандидатов выбирают по лицензии и поддержке движком, затем прогоняют на своём eval и нагрузочном тесте. Если подходящий кандидат не помещается или не выдерживает SLA, сравнивают несколько ускорителей, CPU-offload, меньшую модель и API (глава 16).

Из скоростных характеристик различайте две (глава 7): скорость чтения промпта и скорость генерации. Они по-разному зависят от вычислений, памяти, батча и длины; одна цифра tokens/s не описывает сервис. Измеряйте время до первого токена, скорость decode, полную задержку и throughput на реальном распределении запросов.

14.4. Эксплуатационные мелочи, которые не мелочи

Чек-лист развёртывания. Шаблон диалога: убедитесь, что сервер применяет правильный chat template модели — несовпадение даёт глуповатые или бесконечные ответы (глава 1; современные GGUF несут шаблон в себе, но проверка одним запросом обязательна). Токен остановки: неожиданная генерация до лимита часто указывает на ошибку шаблона или настроек остановки. Версионируйте модель как артефакт: конкретный файл с контрольной суммой, а не «последняя из реестра» — обновление модели это релиз, с прогоном eval (глава 13). Доступ: сервер модели может не иметь аутентификации или слушать не тот интерфейс — проверьте bind-адрес и не публикуйте его напрямую. Нужны сетевой экран, TLS, сильная аутентификация, авторизация по клиентам, rate limits и лимиты ресурсов; одной Basic-аутентификации недостаточно для многопользовательского сервиса. Мониторинг: память ускорителя и хоста, температура, очередь, KV-кэш, p50/p95 задержки, throughput, ошибки и перезапуски. Переполнение памяти лечат на основании профиля нагрузки: длиной контекста, параллелизмом, батчем, форматом кэша или размером модели.

14.5. Итоги

Локальный запуск начинается с арифметики весов, KV-кэша, буферов и параллельных запросов; деградацию каждой квантизации меряют своим eval. llama.cpp/Ollama удобны на рабочей станции, vLLM и аналоги рассчитаны на серверную нагрузку, но выбор подтверждает нагрузочный тест. Совместимость с OpenAI API частична и тоже требует тестов. Эксплуатация включает проверку лицензии и происхождения модели, правильный шаблон, фиксированные версии, защищённый доступ и мониторинг. Локальность удерживает данные в периметре только при контроле всего программного и сетевого контура. Решает ли локальный запуск вопрос денег — тема следующих глав: сначала безопасность (глава 15), затем экономика (глава 16).

Упражнения

1. По формулам из 14.1 и главы 7 определите, какую самую крупную модель (класс и квантизация) потянет ваш компьютер с контекстом 16К. Скачайте её через Ollama и измерьте скорость генерации.

2. Прогоните свой eval из главы 13 на одной модели в квантизациях Q8 и Q4. Есть ли измеримая разница? А в скорости и памяти?

3. Подключите конвейер из главы 9 к локальной модели и зафиксируйте, какие маршруты, события и функции совместимы, а какие пришлось адаптировать. Сравните на своём eval качество и стоимость (амортизацию железа посчитаете после главы 16 — пока хотя бы электричество).