Как запустить LLM локально на своём сервере: требования к железу

Локальный запуск языковой модели, будь то Llama, Qwen, Mistral или дистилляты DeepSeek, решает сразу несколько задач: данные не уходят к внешнему API, стоимость не зависит от количества токенов, а модель можно настроить под свои сценарии. Но прежде чем поднимать сервис, нужно понять, какое железо реально способно потянуть выбранную модель. Ключевой ресурс здесь один: видеопамять (VRAM). Именно от неё зависит, модель какого размера поместится на карту, с каким квантованием и с какой скоростью она будет отвечать. Разбираем, сколько VRAM нужно под разные модели, какую роль играют CPU, RAM и диск, когда без нескольких видеокарт не обойтись и что выгоднее: готовый сервер или сборка своими руками.

Что определяет требования к железу: параметры модели и квантизация

Требования к видеопамяти считаются от количества параметров модели и от того, в каком формате эти параметры хранятся в памяти, то есть от квантизации. Каждый параметр модели, это число (вес), и чем меньше бит выделено на одно число, тем меньше видеопамяти нужно, но тем сильнее модель теряет в точности.

FP16 или BF16, 16 бит на параметр, это исходная точность, в которой большинство моделей опубликовано. Формула простая: число параметров умножить на 2 байта. Для модели на 7 миллиардов параметров получается около 14 ГБ только под веса, без учёта контекста. Q8, 8 бит на параметр, урезает объём вдвое: та же модель весит уже около 7 ГБ, а потеря качества почти не заметна на практике. Q4, 4 бита на параметр, самый популярный формат для домашнего и небольшого серверного использования (GGUF Q4_K_M, GPTQ, AWQ), даёт около 4–4.5 ГБ для той же 7B модели. Ответы становятся чуть менее точными на сложных задачах вроде многошаговой математики, но для чата, суммаризации и большинства прикладных сценариев разница почти не ощущается.

К весам модели нужно прибавить память под контекст, так называемый KV-кэш. Он растёт с длиной промпта и количеством одновременных запросов. Для одного пользователя и контекста на 4–8 тысяч токенов это обычно 1–3 ГБ сверху, а для сервера с несколькими параллельными диалогами и контекстом от 32 тысяч токенов память под кэш может сравняться по объёму с весами самой модели. Поэтому при подборе видеокарты для сервера, а не для личного ноутбука, закладывайте запас в 20–30% сверх «сухого» веса модели.

Сколько VRAM нужно под разные модели

Ниже, ориентировочные значения для самых востребованных размеров моделей (Llama, Qwen, Mistral, дистилляты DeepSeek-R1). Цифры даны уже с запасом под контекст и служебные накладные расходы CUDA.

Одна видеокарта или несколько: когда нужен мультиGPU

Пока модель и контекст помещаются в память одной карты, мультиGPU не нужен: распределение весов между картами добавляет накладные расходы на обмен данными и усложняет настройку. Порог, после которого без нескольких карт не обойтись, это модели от 30B и выше в Q4, а также любые модели в FP16 начиная примерно с 13B.

Здесь два разных сценария. Первый, это разделение весов одной модели между картами (llama.cpp, тензорный параллелизм в vLLM): модель физически делится на части, и каждая карта считает свой кусок. В этом случае критична пропускная способность между картами, на плате с ограниченным числом линий PCIe карты часто работают в режиме x4–x8 вместо полных x16, и скорость генерации заметно падает. Второй сценарий, это несколько независимых карт под разные модели или разные сервисы, здесь скорость обмена между картами не важна, каждая карта работает со своей копией модели.

Для первого сценария нужна платформа с достаточным количеством полноскоростных линий PCIe, это как раз то, для чего проектируются серверные платы на Xeon Scalable или EPYC, в отличие от потребительских плат, где 16–24 линии PCIe делятся между всеми слотами и накопителями. Подробный разбор, какие видеокарты и в каком количестве имеет смысл ставить в сервер под нейросети, есть в статье Сервер для нейросетей: какие GPU нужны.

CPU, оперативная память и диск: второстепенные, но не лишние

Основные вычисления при инференсе выполняет видеокарта, поэтому CPU не обязан быть топовым. Но три момента влияют на результат напрямую.

Число линий PCIe у процессора и чипсета определяет, сколько видеокарт можно поставить на полной скорости x16 и насколько быстро карты обмениваются данными в мультиGPU-сборке. Оперативная память нужна с запасом: если модель не помещается в VRAM целиком, часть слоёв можно выгрузить в RAM (llama.cpp поддерживает частичный offload), это работает, но заметно медленнее GPU, поэтому рассчитывать на постоянную работу в таком режиме не стоит. Как минимум RAM должна в 1.5–2 раза превышать объём VRAM, чтобы система, драйверы и инференс-сервер не упирались в память при загрузке модели и параллельных запросах. Тема серверной памяти с ECC для многокарточных сборок отдельно разобрана в статье Серверная память DDR4 ECC REG: как выбрать.

Диск определяет только скорость загрузки модели, а не скорость генерации ответов. Файлы моделей весят от 4–5 ГБ (7B в Q4) до 140 с лишним ГБ (70B в FP16), а при хранении нескольких моделей и чекпоинтов набегает несколько сотен гигабайт. NVMe SSD обязателен: HDD или SATA SSD заметно увеличивают время старта сервиса при каждой перезагрузке или смене модели.

Софт для локального запуска

Железо без правильного софта не заработает само. Для старта достаточно трёх слоёв. Инференс-движок: Ollama для самого простого старта с автоматическим подбором квантизации, llama.cpp для гибкой настройки и поддержки CPU-offload в формате GGUF, vLLM для продакшн-уровня с максимальной скоростью на нескольких параллельных запросах и тензорным параллелизмом между GPU. Веб-интерфейс или API: text-generation-webui, Open WebUI, либо прямой доступ по OpenAI-совместимому API, который Ollama и vLLM отдают из коробки, это удобно, если модель нужно подключить к внутренним сервисам компании. Драйверы и окружение: свежие драйверы NVIDIA и CUDA (или ROCm для AMD), для сервера почти всегда используется Linux, он стабильнее под долгую работу и проще в автоматизации через Docker.

Выбор движка и формата модели напрямую влияет на итоговую потребность в VRAM: GGUF-модели в Q4 экономичнее по памяти, чем те же веса, поднятые в нативном формате. Поэтому для тестовой сборки часто выгоднее начать с Ollama или llama.cpp и только потом переходить на vLLM под нагрузку с большим числом пользователей.

Готовый сервер или сборка своими руками

Самостоятельная сборка кажется дешевле на бумаге, но добавляет риски: совместимость материнской платы с нужным числом карт, запас блока питания, охлаждение при длительной нагрузке (инференс под серией запросов греет карту почти как обучение) и время на подбор и тестирование компонентов. Для одной потребительской видеокарты под модели 7–14B такая сборка чаще всего оправданна, разница в деньгах и рисках небольшая.

Для конфигураций от 70B и выше, где нужны две и более карты профессионального уровня, готовый сервер на серверной платформе, где производитель уже проверил совместимость видеокарт, блока питания, охлаждения и линий PCIe, экономит время и снимает риск ошибки в конфигурации, которая на серверном железе обходится куда дороже, чем на домашнем ПК.

Из чего складывается цена решения

Три статьи расходов формируют итоговый бюджет. Видеокарта или несколько карт, обычно это самая большая часть бюджета: для входного уровня (7–8B, Q4) достаточно одной карты потребительского класса, а для 70B-класса счёт идёт на профессиональные карты с 48 ГБ и больше или на несколько карт сразу, и цена растёт нелинейно. Платформа, то есть материнская плата, процессор и память: для мультиGPU-сборки нужна плата с достаточным числом линий PCIe, а это уже серверный, а не потребительский сегмент. Корпус, охлаждение и блок питания с запасом по мощности под пиковую нагрузку всех карт одновременно. Обзор актуальных карт для таких задач есть в статье Как выбрать видеокарту для ИИ и нейросетей. Точную конфигурацию и стоимость под конкретную модель и нагрузку проще один раз обсудить с инженером, чем угадывать по общим цифрам.

Что нужно для запуска: чеклист

• Определить модель и её размер (7B, 14B, 70B) под конкретную задачу: не берите модель с запасом, если задача простая, лишние параметры только замедлят ответ.
• Выбрать квантизацию: Q4 для старта и большинства прикладных задач, Q8 или FP16, если критична точность на сложных задачах.
• Посчитать VRAM с запасом 20–30% на контекст и параллельные запросы, а не только по «сухому» весу модели.
• Решить, нужен ли мультиGPU, и если да, выбрать платформу с достаточным числом полноскоростных линий PCIe.
• Заложить RAM в 1.5–2 раза больше объёма VRAM и NVMe SSD под хранение нескольких моделей.
• Проверить запас блока питания и охлаждения под длительную нагрузку, а не только пиковую цифру из характеристик карты.
• Выбрать программный стек: Ollama или llama.cpp для старта, vLLM для продакшна с несколькими пользователями.
• Настроить Linux, драйверы NVIDIA или CUDA и Docker-окружение для стабильной работы сервиса.

Мы, huananzhi.ru, официальный дистрибьютор HUANANZHI в России, подбираем серверные конфигурации под локальный запуск LLM: от одной видеокарты для модели 7–14B до мультиGPU-сервера под 70B и выше. В каталоге Серверы для нейросетей (GPU AI) собраны готовые платформы под такие задачи, а если нужна отдельная карта расширения, посмотрите раздел Видеокарты для ИИ. Напишите нам модель, которую планируете запускать, и ожидаемую нагрузку, поможем подобрать конфигурацию под VRAM и бюджет, выставим счёт и организуем доставку по всей России, на всё поставляемое железо действует гарантия.

Частые ошибки

• Считать нужную VRAM только по весу модели без учёта контекста: реальный расход почти всегда на 20–30% выше «сухой» цифры из характеристик модели.
• Брать одну самую дорогую видеокарту вместо серверной платформы с несколькими картами меньшего объёма: при той же суммарной VRAM это часто выходит дороже и не решает вопрос масштабирования.
• Экономить на блоке питания и охлаждении: инференс под непрерывной нагрузкой держит карту близко к её тепловому и энергетическому пределу почти так же, как обучение.
• Ставить несколько карт в потребительскую материнскую плату без учёта линий PCIe: в режиме x4 вместо x16 карты обмениваются данными в разы медленнее, и итоговая скорость генерации падает.

Автор статьи