1. Главная
  2. Блог
  3. Модели и инфраструктура
  4. Расчёт видеопамяти для LLM: что считать до закупки

Расчёт видеопамяти для LLM: что считать до закупки

15 августа 2026
9

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

Память нужна не только под веса. Полный состав:

Память = веса + память под контекст × число одновременных запросов + накладные расходы

Второе слагаемое и есть то, что чаще всего забывают, а именно оно растёт вместе с нагрузкой.

Слагаемое 1: веса

Считается просто:

Объём весов ≈ число параметров × число байт на параметр

Байт на параметр определяется сжатием — «Квантизация»:

Точность Байт на параметр Модель на 7 млрд параметров На 32 млрд
Полная 4 ~28 ГБ ~128 ГБ
Половинная 2 ~14 ГБ ~64 ГБ
8 бит 1 ~7 ГБ ~32 ГБ
4 бита ~0,5 ~3,5 ГБ ~16 ГБ

Числа округлены и не включают служебные данные формата — реальный размер файла обычно немного больше.

Слагаемое 2: память под контекст

Здесь и находится подвох.

При обработке запроса модель хранит промежуточные представления для каждого токена контекста. Этот объём:

  • растёт линейно с длиной контекста;
  • умножается на число одновременных запросов;
  • зависит от архитектуры модели.

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

Практическое следствие важнее формулы: модель, занимающая 16 ГБ весами, при десяти одновременных запросах с длинным контекстом легко потребует ещё столько же. Карта на 24 ГБ, выглядевшая достаточной, оказывается недостаточной.

Слагаемое 3: накладные расходы

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

Разумный запас — не меньше 10–15% сверх расчёта. Работа впритык означает падения на пиках.

Как считать под нагрузку

Порядок, который избавляет от неприятных открытий.

Шаг 1. Определите пиковую одновременность. Не среднее число запросов в минуту, а сколько их обрабатывается одновременно в пике. Это разные величины, и вторая может быть кратно больше.

Шаг 2. Определите рабочую длину контекста. Не максимальную, поддерживаемую моделью, а ту, что реально передаётся: инструкция плюс найденные фрагменты плюс история.

Шаг 3. Замерьте, а не вычисляйте. Загрузите модель, подайте нагрузку с нужной одновременностью и длиной, посмотрите фактическое потребление. Это надёжнее любой формулы, потому что зависит от среды запуска и настроек.

Шаг 4. Добавьте запас на рост и на накладные расходы.

Методика нагрузочной проверки — «Нагрузочное тестирование».

Разбор: карта, которой не хватило

Задача. Ассистент по внутренней документации, около 30 одновременных пользователей в пике.

Как считали изначально. Взяли модель на 14 млрд параметров, сжатие 4 бита — примерно 8 ГБ весов. Купили карту на 24 ГБ: «запас втрое».

Что произошло на нагрузке. При десяти одновременных запросах система работала. При двадцати начала падать с нехваткой памяти.

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

Формально расчёт был не «втрое с запасом», а «впритык».

Что сделали.

Первое и самое результативное — сократили передаваемый контекст. Добавили переоценку найденных фрагментов и стали передавать четыре вместо десяти — «Реранкинг». Память под контекст сократилась соответственно, а качество ответов при этом выросло: меньше шума.

Второе — ограничили число одновременно обрабатываемых запросов, поставив остальные в очередь. Лучше подождать секунду, чем получить отказ.

Третье — включили в среде запуска приёмы экономии памяти под контекст, которые не были задействованы по умолчанию.

Результат. Уложились в имеющуюся карту при тридцати одновременных пользователях. Докупать ничего не пришлось.

Что стоит забрать. Прежде чем покупать больше памяти, стоит проверить, не тратится ли она впустую. Передача десяти фрагментов вместо четырёх — типичная ситуация, и она бьёт дважды: по памяти и по качеству ответа.

Что ещё влияет

Длина контекста, заданная при запуске. Многие среды резервируют память под максимальную длину заранее. Если вы указали очень большой лимит «на всякий случай», память будет занята независимо от реальных запросов.

Число моделей на карте. Держать две модели одновременно — удвоенные веса. Иногда оправдано (лёгкая для простых задач, тяжёлая для сложных), но считать надо обе.

Модель эмбеддингов. Если поиск по документам работает на той же карте, её вес тоже нужно учесть — «Эмбеддинги для русского».

Несколько карт. Крупные модели распределяются между картами, но это добавляет накладные расходы на обмен между ними и требует поддержки со стороны среды запуска.

Оперативная память. Часть сред умеет выгружать редко используемое в обычную память. Работает, но медленно — как аварийный вариант, а не как план.

Ориентиры для планирования

Иллюстративно, для понимания порядка. Реальные значения зависят от модели и настроек.

Задача Ориентир
Классификация, извлечение полей, небольшая модель карта потребительского класса
Ассистент по документам, средняя модель, единицы пользователей одна карта среднего класса
То же, десятки одновременных пользователей карта с большим объёмом или несколько
Крупная модель, высокая нагрузка серверное решение

Смысл таблицы не в конкретных цифрах, а в том, что одновременность влияет на требования не меньше размера модели.

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

Как рассчитать нужный объём видеопамяти?

Сложить три величины: вес модели (число параметров × байт на параметр), память под контекст (растёт с длиной контекста и числом одновременных запросов) и накладные расходы среды запуска. Плюс запас 10–15%. Вторая величина — та, которую чаще всего забывают, и именно она растёт вместе с нагрузкой.

Почему модель не помещается, хотя по расчёту должна?

Скорее всего, в расчёте учли только веса. Память под контекст при нескольких одновременных запросах с длинными входами может превысить объём весов. Также среда запуска нередко резервирует память под максимальную длину контекста, указанную при старте, независимо от реальных запросов.

Сколько памяти нужно для модели на 7 миллиардов параметров?

Веса при сжатии до 4 бит — около 3,5 ГБ, при 8 битах — около 7 ГБ. Но это только первое слагаемое: с учётом контекста и одновременных запросов реальная потребность может быть в два-три раза выше. Точное значение надёжнее замерить под вашей нагрузкой, чем вычислить.

Можно ли обойтись меньшей картой?

Часто да, если сократить передаваемый контекст, ограничить число одновременных запросов очередью и включить приёмы экономии памяти в среде запуска. Прежде чем докупать оборудование, стоит проверить, не тратится ли имеющаяся память впустую.

Что даёт больше — увеличить память или сжать модель сильнее?

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

Нужно ли считать память под модель эмбеддингов?

Да, если поиск по документам работает на той же карте. Модели векторизации обычно небольшие, но при плотном расчёте несколько гигабайт имеют значение.

Что дальше

Как уменьшить вес модели — «Квантизация». Чем запускать и как настроить экономию памяти — «vLLM, Ollama, llama.cpp». Как проверить расчёт под реальной нагрузкой — «Нагрузочное тестирование». Стоит ли покупать вообще — «Облако или свой сервер».

Расчёт конфигурации под вашу нагрузку до закупки — часть работы по разработке и внедрению ИИ.