Требования к GPU-памяти для LLM: веса, KV-кэш, активации и накладные расходы

Требования к GPU-памяти для LLM — это не просто «размер модели плюс немного запаса». Для задачи инференса или обучения есть несколько отдельных категорий памяти: веса модели, KV-кэш, активации, рабочие области фреймворка, CUDA graphs, временные буферы и операционный запас.

Быстрое правило планирования такое:

required VRAM =
  model weights
+ KV cache for live tokens
+ activation and workspace memory
+ training state, if training or full fine-tuning
+ allocator and safety headroom

Именно поэтому две команды могут запускать одну и ту же модель 70B на одном и том же классе GPU и получать разные результаты. Одна использует короткие промпты, один поток, KV-кэш FP8 и консервативный batching. Другая использует длинный контекст, много одновременных запросов, захват CUDA graphs и высокое значение gpu_memory_utilization. Первая задача помещается. Вторая падает с ошибками out-of-memory или съедает задержку, перекладывая работу в другое место.

Это руководство дает практическую рабочую таблицу по llm gpu memory requirements для инференса, обслуживания в vLLM, fine-tuning и обучения. Используйте его до аренды GPU, выбора емкости H100 вместо H200 вместо B200 или решения, проще ли использовать API модели, чем поддерживать собственную GPU-точку входа.

Краткий ответ по требованиям к GPU-памяти LLM

Для инференса начните с весов, затем оцените размер KV-кэша по длине контекста и уровню параллелизма. Для обучения веса — только начало; состояния оптимизатора, градиенты и сохраненные активации доминируют в плане памяти.

Если вам нужны только ответы модели, сначала сравните прямое обслуживание на GPU с базовым вариантом через API модели. Прямые GPU имеют смысл, когда нужны пользовательские веса, контроль размещения, приватная политика выполнения или нагрузка, которая становится дешевле после измерения утилизации. Если вам в основном нужны надежные ответы API, управляемый маршрут к модели может избавить от недель подбора размера GPU, очередей и операционных задач.

Рабочая таблица требований к GPU-памяти LLM

Используйте эту таблицу перед выбором инстанса.

Самая частая ошибка — разместить веса и забыть про живые токены. Для оценки требований к GPU-памяти LLM при инференсе KV-кэш может стать разницей между стабильной точкой обслуживания и бесконечным OOM-циклом.

Шаг 1: рассчитайте память под веса модели

Веса — самая простая часть требований к GPU-памяти для нагрузок LLM.

weight_memory_gib = parameters x bytes_per_parameter / 1024^3

Эта таблица — нижняя граница. В реальных развертываниях добавляются масштабы квантования, буферы не-параметров, состояние токенизатора/рантайма, временные рабочие области и накладные расходы на обслуживание.

Для оценки требований vLLM к GPU-памяти для модели 70B VRAM одни только веса BF16/FP16 уже превышают возможности одного H100 на 80 GB. Один H200 имеет 141 GB HBM3e согласно странице H200 NVIDIA, так что веса в принципе могут поместиться, но оставшийся KV-кэш и запас для работы рантайма все равно могут вынудить уменьшить контекст, снизить параллелизм, использовать квантование KV-кэша или тензорный параллелизм. NVIDIA указывает H100 SXM как 80 GB, H200 как 141 GB, а DGX B200 — как восемь GPU Blackwell с 1,440 GB общей HBM3e, что фактически означает 180 GB на один GPU B200 в этой системе.

Шаг 2: рассчитайте память KV-кэша для требований LLM к GPU-памяти

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

Для инференса трансформера только с декодером:

kv_cache_bytes =
  active_tokens
x num_layers
x num_kv_heads
x head_dim
x 2
x bytes_per_kv_element

Где:

Например, конфигурация в стиле Llama 70B с 80 слоями, 8 KV-головами и размерностью головы 128 использует:

80 x 8 x 128 x 2 x 2 bytes = 327,680 bytes per token

Это около 0.3125 MiB на один активный токен в KV-кэше BF16/FP16.

Точное значение зависит от архитектуры модели. Модель с большим числом KV-голов использует больше KV-памяти. Модель с multi-query или grouped-query attention может использовать гораздо меньше KV-памяти, чем полноценная реализация multi-head attention.

В документации vLLM описаны несколько важных параметров: --gpu-memory-utilization управляет долей памяти GPU, используемой исполнительным модулем модели, --kv-cache-memory-bytes позволяет явно задать размер KV-кэша, --kv-cache-dtype — выбрать точность кэша, а руководство по экономии памяти рекомендует уменьшать max_model_len и max_num_seqs, когда памяти не хватает. vLLM также документирует FP8 KV-кэш как способ уменьшить объем KV-кэша и поддерживать более длинный контекст или более высокую пропускную способность, при этом все равно требуется проверка точности.

Шаг 3: добавьте активации и накладные расходы рантайма

Для инференса память под активации обычно меньше, чем под веса и KV-кэш, но она не равна нулю. Prefill, CUDA graphs, attention kernels, временные буферы, мультимодальные процессоры, speculative decoding и планирование батчей могут резервировать дополнительную память.

Для обучения память под активации становится одним из ключевых факторов. В материале Hugging Face о строении памяти модели компоненты памяти при обучении перечислены как веса модели, состояния оптимизатора, градиенты, сохраненные для вычисления градиентов forward-активации, временные буферы и память для специализированных функций. Там также отмечается, что память под активации зависит от длины последовательности, скрытого размера и размера батча.

Удобное разбиение для планирования выглядит так:

Не запускайте production на 99% заполнения памяти только потому, что тестовый запрос помещается. Это не оставляет места для более длинных промптов, горячей перезагрузки, захвата CUDA graph, поведения аллокатора или потока трафика, отличающегося от бенчмарка.

Шаг 4: оцените память для обучения и fine-tuning

Память для обучения больше, потому что GPU должен хранить не только веса прямого прохода.

Для полного дообучения с mixed precision и AdamW анализ памяти Hugging Face даёт практическую разбивку: при обучении с mixed precision могут храниться копии весов FP32 и FP16/BF16, состояния оптимизатора AdamW, градиенты, сохранённые активации, временные буферы и память под функционально-специфичные нужды. На той же странице типичная схема mixed-precision AdamW суммируется как 18 байт на параметр модели плюс память под активации.

Это означает:

Именно поэтому запросы вида gpu memory requirements LLM training требуют иного ответа, чем запросы про инференс. Модель 70B, которую можно обслуживать с tensor parallelism и квантованным KV-кэшем, не становится автоматически практичной для полного дообучения на небольшом числе GPU.

Способы снизить потребление памяти при обучении включают:

Для полного обучения формулы помогают получить первую оценку формы кластера. Они не заменяют измеренный прогон фреймворка.

Шаг 5: сопоставьте требования к GPU-памяти для LLM с распространёнными объёмами памяти GPU

Используйте ёмкость GPU-памяти как ограничение, а не как единственный критерий покупки. Пропускная способность памяти, топология NVLink, сеть, хранилище, планирование и загрузка могут быть не менее важны, чем чистый объём VRAM.

Если в вашей таблице указано, что один H200 «едва помещает» модель 70B, это не план развёртывания. Это сигнал провести бенчмарк для следующих настроек:

Для деталей выбора оборудования используйте этот worksheet вместе с гайдами Flatkey: best GPU for LLM inference, H200 vs H100 и B200 vs H200.

Пример: расчёт размеров для инференса 70B в vLLM

Ниже приведён консервативный способ оценить vllm gpu memory requirements 70b model vram до аренды ресурсов.

Предположим:

Затем сравните несколько вариантов обслуживания:

С точки зрения эксплуатации, план на 70B в vLLM обычно попадает в один из следующих сценариев:

Это практический ответ на вопрос о gpu memory requirements for LLM при обслуживании: число параметров показывает, загрузится ли модель; KV-кэш и резерв времени выполнения показывают, сможет ли она обслуживать полезный трафик.

Почему длина контекста меняет ответ

Длинный контекст дорог, потому что кэш растёт вместе с количеством активных токенов. Если увеличить контекст с 8K до 16K, KV-кэш для той же модели, точности и конкуррентности примерно удвоится. Если удвоить конкуррентность при том же контексте, KV-кэш снова примерно удвоится.

Для команд, сравнивающих планы llm hardware requirements gpu memory, это даёт простую схему расчёта размера:

больше пользователей x более длинные промпты x больше выходных токенов = больше KV-кэша

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

Часто это дешевле и стабильнее, чем запуск одного огромного endpoint'а с одним глобальным параметром памяти.

Что измерять в первом бенчмарке

Запустите бенчмарк, похожий на production-трафик, а не один удачный запрос.

Для многонодовых развёртываний дополните это чек-листами GPU cluster architecture и GPU cluster TCO. Модель, которая помещается в память, всё равно может оказаться дорогой, если сеть, хранилище, очереди или утилизация организованы плохо.

Типичные ошибки

Руководство по выбору: арендовать GPU или использовать API модели?

Прямая GPU-мощность — правильный выбор, когда вам нужно одно или несколько из следующего:

Flatkey полезен как базовый путь, когда контроль над железом не является требованием продукта. Он даёт командам одну точку сравнения между официальными моделями и инструментами, так что вы можете сопоставить стоимость аренды GPU со стоимостью вывода через API модели, прежде чем брать на себя обязательства по длительно работающему кластеру. Если бенчмарк покажет, что прямые GPU выигрывают, используйте приведённую выше таблицу памяти, чтобы арендовать минимально надёжный конфиг вместо самого большого и впечатляющего.

Часто задаваемые вопросы

Сколько GPU-памяти нужно 70B LLM?

Весам BF16 или FP16 для модели 70B требуется около 130 GiB ещё до KV-кэша и накладных расходов времени выполнения. Веса INT8 занимают около 65 GiB до метаданных. Веса 4-bit занимают около 33 GiB до метаданных квантизации. Для продуктивного инференса добавьте KV-кэш для контекста и параллельности, резерв фреймворка обслуживания и запас по безопасности.

Почему модель загружается, но падает под нагрузкой?

Тест загрузки может помещать только веса. Реальный трафик добавляет KV-кэш для активных промптов и сгенерированных токенов, накладные расходы батчинга, временные буферы и резервы фреймворка. Более длинные промпты и большее число параллельных последовательностей могут привести ту же модель к OOM.

Что больше всего влияет на требования LLM inference к GPU-памяти?

Наибольшие переменные — размер модели, точность весов, длина контекста, число одновременных последовательностей, точность KV-кэша и настройки фреймворка обслуживания. При обслуживании длинного контекста узким местом часто становится KV-кэш.

Что влияет на аппаратные требования LLM к GPU-памяти при обучении?

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

Снижает ли vLLM требования к GPU-памяти?

vLLM даёт полезные средства управления памятью и эффективное управление KV-кэшем, но не отменяет базовый бюджет памяти. Вам всё равно нужна достаточная VRAM для весов, KV-кэша, активаций, резерва времени выполнения и запаса. Его средства управления памятью помогают выбрать компромисс между длиной контекста, параллельностью, точностью и пропускной способностью.

Может ли FP8 KV-кэш решить проблему нехватки памяти при длинном контексте?

Это может уменьшить объём KV-кэша, и в документации vLLM поддерживается FP8 KV-кэш. Рассматривайте это как настройку для бенчмарка, а не как бесплатный переключатель: проверьте качество вывода, задержку, поддерживаемые аппаратные/программные пути и поведение при сбоях, прежде чем использовать это в продакшене.

Финальный чек-лист

Прежде чем арендовать мощность, ответьте на следующие вопросы:

1. Какой размер модели и какая точность весов у вас обслуживаются?
2. Какова максимальная длина контекста, которую пользователи реально могут отправить?
3. Сколько одновременных последовательностей должно помещаться при нагрузке p95?
4. Какую длину вывода вы резервируете для генерации?
5. KV-кэш использует BF16/FP16, FP8 или другой поддерживаемый формат?
6. Какой запас остаётся после весов и KV-кэша?
7. Используете ли вы tensor parallelism, квантизацию, LoRA, FSDP или ZeRO?
8. Какую точную SKU GPU, ёмкость памяти и топологию выделит провайдер?
9. Какие пороги OOM, задержки и стоимости за принятый вывод определяют успех?
10. Если вам не нужен контроль над железом, какова стоимость базового API модели?

Лучший прогноз требований llm gpu memory — тот, который выдерживает бенчмарк, имитирующий продакшен. Используйте таблицу, чтобы быстро отбраковать невозможные конфигурации GPU, затем проверьте короткий список на реальных длинах контекста, реальной параллельности и с достаточным запасом, чтобы оставаться в сети.

Источники

• Аргументы движка vLLM: gpu_memory_utilization, kv_cache_memory_bytes, kv_cache_dtype и связанные элементы управления кэшем: https://docs.vllm.ai/en/latest/configuration/engine_args.html
• Руководство vLLM по экономии памяти: tensor parallelism, квантизация, длина контекста, размер батча, память CUDA graph и средства управления памятью для мультимодальных сценариев: https://docs.vllm.ai/en/latest/configuration/conserving_memory/
• Руководство vLLM по квантизированному KV-кэшу: варианты FP8 KV-кэша и компромиссы: https://docs.vllm.ai/en/latest/features/quantization/quantized_kvcache.html
• Анатомия памяти моделей Hugging Face Transformers: категории памяти при обучении, состояния оптимизатора, градиенты, активации и примечания по смешанной точности: https://huggingface.co/docs/transformers/v4.57.1/en/model_memory_anatomy
• Страница продукта NVIDIA H100: память H100, пропускная способность, H100 NVL и позиционирование для LLM: https://www.nvidia.com/en-us/data-center/h100/
• Страница продукта NVIDIA H200: 141 GB HBM3e и пропускная способность памяти: https://www.nvidia.com/en-us/data-center/h200/
• Страница продукта NVIDIA DGX B200: восемь GPU B200 и 1,440 GB общей HBM3e: https://www.nvidia.com/en-us/data-center/dgx-b200/