Сколько VRAM нужно для запуска LLM на сервере

Запуск языковой модели на собственном сервере начинается не с выбора фреймворка. Он начинается с одного практического вопроса: хватит ли видеопамяти. Ошибиться здесь легко — модель, которая уверенно отвечала на демо-стенде разработчика, на боевом сервере внезапно упирается в CUDA out of memory. Причина почти всегда одна и та же: объём VRAM для LLM недооценили ещё на этапе планирования инфраструктуры.

В статье разберём, из чего складывается расход видеопамяти при запуске нейросети, как посчитать его заранее для конкретной модели и как выбрать сервер для LLM под разные задачи — от локального чат-бота на 7 миллиардах параметров до продакшен-сервиса на 70B с десятками одновременных запросов.

Что такое VRAM и почему она критична для LLM

VRAM — это видеопамять графического процессора, физически отдельная от оперативной памяти сервера и рассчитанная на высокую пропускную способность. Именно в ней хранятся веса модели и промежуточные данные вычислений: обычная RAM для этой задачи подходит плохо из-за низкой скорости обмена данными с ядрами GPU.

Когда языковая модель обрабатывает запрос, видеокарта выполняет миллионы матричных умножений подряд. Чтобы это происходило быстро, все параметры модели должны находиться в видеопамяти одновременно — иначе GPU будет постоянно ждать подгрузки данных с диска или из RAM, и скорость генерации ответа упадёт в разы. Проще говоря: сколько VRAM для LLM выделено, столько модели и доступно для быстрой работы.

В объём видеопамяти, который расходует запущенная модель, входит несколько компонентов:

• веса модели — сами параметры нейросети, зафиксированные при обучении;
• KV-cache — кэш ключей и значений внимания, который растёт с длиной контекста;
• промежуточные активации — временные тензоры, возникающие при прямом проходе;
• служебные буферы фреймворка — CUDA-контекст, память под батчи и оптимизации рантайма.

Каждый из этих пунктов ведёт себя по-разному в зависимости от размера модели, длины контекста и числа одновременных запросов. Дальше разберём расчёт подробнее.

Как рассчитывается объём видеопамяти для модели

Вес модели и точность вычислений

Базовая величина — количество параметров модели, умноженное на размер одного параметра в байтах. Размер параметра зависит от точности вычислений (precision), в которой загружена модель: в FP32 каждый параметр занимает 4 байта, в FP16 и BF16 — 2 байта, в INT8 — 1 байт, а в INT4-квантовании (GPTQ, AWQ, GGUF Q4) — примерно 0,5 байта с учётом служебных данных квантования. Формула простая: объём VRAM под веса ≈ число параметров × байт на параметр.

Для модели на 7 миллиардов параметров в FP16 получаем примерно 14 ГБ только под веса. В INT4 та же модель займёт около 4 ГБ — разница почти в 3,5 раза при сопоставимом, хотя и не идентичном, качестве ответов.

KV-cache и длина контекста

KV-cache растёт линейно с длиной контекста, числом слоёв трансформера и размером скрытого состояния. Чем длиннее диалог или документ, который обрабатывает модель, тем больше видеопамяти уходит на хранение промежуточных ключей и значений внимания. На практике для модели среднего размера с контекстом в 8–16 тысяч токенов KV-cache добавляет от 10% до 30% к объёму, который занимают веса.

Важно: при работе с очень длинным контекстом — 32K, 128K токенов и выше — KV-cache может сравняться по объёму с весами модели или даже превысить их. Здесь и кроется частая ошибка при первичном расчёте инфраструктуры.

Batch size и параллельные запросы

Сервер, который отвечает одному пользователю, и сервер, который держит десятки параллельных сессий, — две разные задачи по расходу видеопамяти. Каждый одновременный запрос добавляет собственный KV-cache, поэтому для продакшен-нагрузки объём VRAM для LLM рассчитывают по пиковому числу параллельных сессий, с запасом на рост трафика.

Значит ли это, что стоит сразу закладывать двойной запас видеопамяти на всякий случай? Не обязательно — куда важнее точно оценить пиковую нагрузку, чем перестраховываться вслепую. Общее правило для одиночного инференса: суммарный объём видеопамяти обычно составляет 1,2–1,3 от размера весов модели при умеренном контексте.

Цифры в таблице — ориентир для планирования, а не точная формула под любую архитектуру. Модели с механизмом MoE (Mixture of Experts), например Mixtral 8×7B, ведут себя иначе: в видеопамяти нужно держать все веса экспертов, а вычислительно активна лишь часть из них — поэтому расход VRAM для таких архитектур считают отдельно.

Плюсы и минусы разных подходов к экономии видеопамяти

Если модель не помещается в доступную видеокарту, есть несколько путей — и у каждого свой компромисс между стоимостью, скоростью и качеством ответов.

На практике команды редко выбирают что-то одно: квантование сочетают с арендой сервера подходящей конфигурации, а tensor parallelism применяют только для моделей, которые физически не помещаются в одну карту даже после сжатия.

Для запуска и обслуживания моделей чаще всего используют одну из проверенных сред:

Проверить фактическую загрузку видеопамяти на сервере несложно одной командой:

А запустить квантованную модель через llama.cpp с выгрузкой части слоёв на GPU можно так:

Ограничения и риски нехватки видеопамяти

Нехватка VRAM редко проходит незаметно. Чаще всего это выглядит как жёсткий сбой процесса — CUDA out of memory — или как резкое падение скорости из-за того, что фреймворк начинает выгружать часть данных в оперативную память сервера. Второй сценарий коварнее первого: сервис формально работает, но генерация ответа может занимать в 10–20 раз больше времени.

Симптомы, по которым стоит заподозрить нехватку видеопамяти:

• ошибки CUDA out of memory при старте или в середине обработки запроса;
• резкий рост времени ответа при увеличении длины контекста или числа параллельных пользователей;
• нестабильная работа сервиса под нагрузкой при том, что на тестах всё было в порядке.

Есть и обратная проблема — избыточная экономия. Слишком агрессивное квантование, например переход сразу к INT2 без проверки качества, способно заметно испортить связность и точность ответов модели. Здесь важен баланс: снижать точность вычислений стоит ровно настолько, насколько позволяет требуемое качество генерации.

Отдельный риск — многокарточные конфигурации без быстрой связи между GPU. Если карты соединены через обычный PCIe вместо NVLink, обмен данными между ними при tensor parallelism может стать узким местом и свести на нет выигрыш от дополнительной видеопамяти.

Практические сценарии

Чат-бот поддержки на 7B модели

Для внутреннего чат-бота с короткими диалогами и контекстом до 4–8 тысяч токенов достаточно одной видеокарты на 16–24 ГБ. FP16-версия модели на 7B параметров с запасом под KV-cache комфортно помещается на RTX 4090 или A10, а INT4-квантование позволяет обойтись картой попроще — вплоть до 12 ГБ.

RAG-сервис на 13B модели

Когда модель дополняет ответы данными из базы знаний, контекст растёт за счёт вставленных фрагментов документов — иногда до 16–32 тысяч токенов на запрос. Здесь уже нужна карта на 40 ГБ или квантованная версия модели на 24 ГБ с более скромным запасом по параллельным сессиям.

Fine-tuning модели среднего размера

Дообучение требует значительно больше видеопамяти, чем инференс: помимо весов, в VRAM хранятся градиенты и состояния оптимизатора. Для полного fine-tuning 7B модели в FP16 счёт может идти на 60–80 ГБ. Методы вроде LoRA и QLoRA снижают требование в разы, позволяя дообучать ту же модель на одной карте с 24 ГБ.

Продакшен-инференс 70B модели для нескольких клиентов

Крупная модель под серьёзную нагрузку с десятками параллельных запросов — сценарий, где закупка собственного мультикарточного сервера часто не оправдана экономически, особенно на старте проекта. Аренда готового GPU-сервера для LLM с нужной конфигурацией закрывает эту задачу быстрее: инфраструктура разворачивается за часы, а не недели, которые ушли бы на закупку и настройку оборудования.

Частые ошибки при выборе видеопамяти для LLM

• Расчёт VRAM только под веса модели без учёта KV-cache — на длинном контексте это приводит к внезапной нехватке памяти в продакшене.
• Тестирование на коротких диалогах без проверки поведения при максимальной длине контекста, заявленной для модели.
• Выбор конфигурации без запаса под пиковое число параллельных пользователей, а не под средний трафик.
• Слепое доверие к цифрам «из интернета» без проверки на конкретной версии фреймворка и модели — расход памяти отличается между реализациями.
• Агрессивное квантование ради экономии видеопамяти без контрольной проверки качества ответов на реальных задачах.

Отдельно стоит отметить: самая большая модель не всегда оказывается правильным выбором. Модель на 13B с аккуратным квантованием и достаточным контекстом нередко закрывает задачу не хуже 70B, но обходится в разы дешевле по видеопамяти и инфраструктуре в целом.

В итоге

Расчёт видеопамяти для LLM — задача, которую стоит решать до выбора сервера, а не после первого CUDA out of memory в продакшене. Формула простая на бумаге: параметры модели, умноженные на точность вычислений, плюс KV-cache под нужный контекст и число параллельных запросов. На практике в неё легко забыть один из компонентов, и именно это чаще всего приводит к недооценке нужного объёма VRAM для LLM.

Проще говоря: считайте не только вес модели, но и реальный сценарий использования — длину контекста, число пользователей и запас на рост нагрузки. Тогда сервер для LLM подберётся с первого раза, без дорогостоящих апгрейдов на боевой инфраструктуре.

Частые вопросы