Запуск LLM локально: llama.cpp и подбор железа под модели 7B–70B

Компания хочет внедрить LLM-ассистента для отдела поддержки или внутреннего поиска по документации. Облачные API - OpenAI, Anthropic, Google, закрыты политикой безопасности или попадают под санкционные ограничения. Данные клиентов, переписку и внутренние обращения нельзя передавать наружу: это требование службы безопасности и норма закона. Запуск LLM локально через llama.cpp - рабочий путь: всё остаётся внутри контура, никаких внешних запросов. llama.cpp не единственный вариант, но самый низкопороговый: не требует CUDA-окружения в full-stack, работает на CPU и GPU, разворачивается за день без DevOps-инфраструктуры.

Главный вопрос - на каком оборудовании это работает без компромиссов по скорости и качеству. В статье разбираем требования для моделей 7B, 13B, 34B и 70B: сколько VRAM и ОЗУ нужно, когда достаточно CPU, а когда без GPU класса NVIDIA A100 не обойтись.

llama.cpp - open-source движок для запуска LLM в формате GGUF на CPU, GPU и Apple Silicon. Родился как порт модели LLaMA на C++ для запуска на Mac без видеокарты. Сегодня поддерживает десятки архитектур и работает на Linux, Windows и macOS без сложных зависимостей.

Применяют там, где данные не должны покидать периметр: прототипы LLM-функций, on-premise чат-боты для поддержки и HR, RAG-системы по внутренней документации, инференс дообученных компанией моделей.

Модели 7B и 13B в квантизации Q4_K_M помещаются в 8–16 ГБ ОЗУ и выдают 5–8 токенов/сек на EPYC 9354P (32 ядра) и 12–18 токенов/сек на EPYC 9754 (128 ядер) или Xeon Platinum 8480+. Этого хватает для офлайн-обработки документов, ночных пайплайнов классификации обращений, batch-генерации описаний. Инженер ML запускает задачу на ночь - утром получает размеченный датасет.

Модель 34B на CPU потребует 24–32 ГБ ОЗУ и выдаёт 1–3 токена/сек. Для интерактивного чата неприемлемо: пользователь ждёт ответа минутами. Инференс LLM на CPU оправдан там, где скорость вторична, а экономия на оборудовании принципиальна.

NVIDIA RTX 4090 с 24 ГБ VRAM запускает 13B Q5_K_M или Q6_K со скоростью 40–80 токенов/сек - уровень живого чата. Та же модель в Q8_0 может не влезть полностью и потребует офлоада части слоёв на CPU с падением скорости.

Модель 34B уже упирается в VRAM на одной RTX 4090: либо офлоад части слоёв - скорость падает до 10–20 токенов/сек, либо два GPU.

Для локального запуска 70B модели в квантизации Q4 потребуется 40–48 ГБ VRAM. Варианты: две RTX 4090, NVIDIA RTX 6000 Ada (48 ГБ), NVIDIA A100 (40 или 80 ГБ), NVIDIA H100 или две NVIDIA Tesla V100 32 ГБ. Ориентировочная скорость на A100/H100 - 15–40 токенов/сек в зависимости от квантизации и контекста.

Для прототипа достаточно 13B на одном GPU уровня RTX 4090. Для продакшн-нагрузки с моделями 70B+ нужен сервер с H100/A100 или конфигурация на 2–4 NVIDIA RTX 6000 Ada. Модели 34B - компромисс: офлоад или два GPU.

RTX 4060 (8 ГБ VRAM) — только при контексте до 4k токенов; для RAG-сценариев с контекстом 8k+ нужна RTX 4070/4080 или CPU-режим.

Решение строится вокруг четырёх параметров.

Базовое правило для оценки VRAM: размер модели в GGUF плюс примерно 20% на KV-cache при контексте 4k и ещё плюс 30% при контексте 32k. Под одного пользователя и модель 13B Q4_K_M уверенно работает рабочая станция с NVIDIA RTX 4090 и 32–64 ГБ ОЗУ. Под 10 параллельных пользователей для llama.cpp подбор железа уже означает сервер с двумя RTX 4090 или одним GPU класса NVIDIA A100/H100.

Для 70B в продакшне с десятками одновременных запросов выбирают сервер на HGX-платформе с 4–8 GPU и быстрым NVLink между ними. Для прототипов и задач небольшого отдела достаточно одной мощной рабочей станции - это в разы дешевле и быстрее в развёртывании.

Если задача - поднять пилот быстро, ориентируйтесь на рабочие станции для AI: под одного-трёх пользователей и модели до 13B они закрывают задачу без избыточного бюджета.

Порядок цифр, не смета: рабочая станция с RTX 4090 для моделей до 13B — бюджет уровня мощного инженерного ПК. Сервер с одной A100/H100 для 70B — уже единицы миллионов рублей, основная часть — GPU. Мульти-GPU конфигурация под 50+ одновременных пользователей — бюджет проекта, а не закупки: счёт идёт на десятки миллионов с учётом резервирования и СХД. Цены на GPU волатильны — перед защитой бюджета запрашивайте актуальные котировки у поставщиков.

В реальном проекте llama.cpp редко стоит в одиночку. Поверх ставят Ollama - обёртку, которая берёт на себя загрузку GGUF-файлов, переключение между моделями и управление памятью. Для локальных экспериментов разработчиков удобен LM Studio с графическим интерфейсом: быстро сравнить, как одна модель отвечает в Q4 и Q6. Если профиль нагрузки - десятки параллельных запросов на GPU, рассматривают vLLM как альтернативу с continuous batching: он обгоняет llama.cpp по пропускной способности при высоком RPS.

Поверх инференс-движка строится прикладной слой. Для RAG-систем по внутренней документации - LangChain или LlamaIndex. Для эмбеддингов под векторный поиск - sentence-transformers и модели типа bge или e5. Для отладки промптов - text-generation-webui. За наблюдаемостью следят Prometheus и Grafana: задержки, очередь запросов, утилизация GPU. В прод чаще выбирают llama.cpp + Ollama ради простоты или vLLM ради максимальной производительности при continuous batching.

Когда стек определён, следующий шаг - подобрать оборудование для AI-нагрузок под реальный профиль: число GPU, объём ОЗУ, пропускная способность NVLink.

Короткая матрица выбора: 1–3 пользователя и пилот — llama.cpp + Ollama. 10–50 параллельных запросов на GPU — vLLM. GUI для экспериментов ML-команды — LM Studio.

Запуск LLM внутри периметра не означает автоматической безопасности. Инференс-сервер - это отдельный сервис, к которому применяют те же стандарты, что к любому внутреннему API.

Сетевая изоляция. llama-server по умолчанию слушает на всех интерфейсах. В продакшене его ограничивают localhost или внутренним сетевым интерфейсом и закрывают iptables или firewalld. Тестовый контур с экспериментальными моделями держат отдельно от боевого: риск нестабильности и смешения данных между средами реален.

Контроль доступа. API-ключ к llama-server обязателен даже во внутренней сети. llama-server не имеет встроенной поддержки LDAP — авторизацию реализуют через reverse proxy: nginx с LDAP Auth Daemon или Keycloak в роли OIDC-провайдера перед эндпойнтом. Каждый запрос к модели логируют вместе с промптом и ответом: это требование для аудита и расследования инцидентов.

Ограничения конфигурации. Максимальная длина контекста ограничивается не только по VRAM, но и как защита от prompt injection с гигантскими входными данными. Rate-limit на запросы в минуту предотвращает перегрузку сервера одним процессом. В средах с требованиями ФСТЭК или ЦБ весь стек - llama.cpp, OS, GPU-драйверы, фиксируется по версиям и проходит проверку перед выкаткой.

Алгоритм выбора простой и состоит из четырёх шагов. Сначала определите целевой размер модели - 7B, 13B, 34B или 70B, исходя из требований к качеству ответов, поддержке русского языка и сложности задач. Дальше оцените число параллельных пользователей и допустимую задержку: интерактивный чат требует минимум 20–30 токенов/сек, офлайн-пайплайн работает и при 5–10. Третий шаг - посчитайте VRAM и ОЗУ по правилу «размер модели в GGUF плюс 20–50% на KV-cache в зависимости от длины контекста». И последнее - подберите оборудование под получившиеся требования.

Для пилота достаточно рабочей станции с NVIDIA RTX 4090 и моделью 13B: запуск LLM локально в таком варианте занимает день-два от получения оборудования. Для продакшна с десятками пользователей и моделями 70B нужен сервер с GPU класса NVIDIA H100 или A100 либо конфигурация на нескольких NVIDIA RTX 6000 Ada. Рассчитайте всё заранее: апгрейд GPU на действующем сервере сложнее и дороже, чем правильный выбор с первого раза.