GPU‑память и LLM: точный расчёт ресурсов в 2026 году

Введение

В 2026 году большие языковые модели (LLM) уже превзошли 1 триллион параметров, а требования к видеопамяти GPU стали главным узким местом как при обучении, так и при инференсе. Ошибки в расчёте памяти приводят к падениям батчей, лишним арендам облачных GPU и просто к простоям. В этой статье я собрал актуальные формулы, проверенные на практике цифры и набор практических приёмов, которые позволяют точно спланировать потребление видеопамяти для любой модели от 7 B до 1 T параметров.

---

1. Базовый расчёт памяти под параметры

Параметры модели хранятся в виде 16‑битных (FP16) или 8‑битных (INT8) тензоров. В 2026 году почти все продакшн‑развёртывания используют FP16 + квантизацию градиентов (FP8) для обучения и INT8 для инференса.

Формат	Размер одного элемента	Коэффициент сжатия
FP32	4 Б	1×
FP16	2 Б	0.5×
BF16	2 Б	0.5×
FP8	1 Б	0.25×
INT8	1 Б	0.25×

Для модели с P параметрами память под сами параметры (без активаций) вычисляется так:

[ M_{\text{params}} = P \times \text{bytes_per_elem} \times \text{overhead} ]

overhead ≈ 1.05 – 1.10 для выравнивания и метаданных.

Пример: 70‑B модель (≈ 70·10⁹ параметров) в FP16:

[ M = 70·10^9 × 2 Б × 1.07 ≈ 150 GB. ]

В INT8 та же модель занимает лишь ~75 GB, но требует дополнительного кэша для de‑quantization (≈ 10 % от M).

---

2. Память под активации (activations)

Активации dominate memory consumption при инференсе с большим контекстом и при обучении с батчем > 1. Формула:

[ M_{\text{act}} = B × L × H × S × \text{bytes_per_elem} × \text{act_factor} ]

• B – размер батча,
• L – количество токенов в последовательности,
• H – число скрытых единиц (hidden size),
• S – число слоёв (layers),
• act_factor – 1.0 – 1.3 (зависит от наличия checkpoint‑инг/gradient‑rematerialization).

Для большинства трансформеров hidden size ≈ hidden_dim = 12288 для 70‑B модели, S = 80.

Пример: инференс 1‑токенного запроса (L = 1) с B = 1 на 70‑B модели, FP16:

[ M_{\text{act}} = 1 × 1 × 12288 × 80 × 2 Б × 1.1 ≈ 2.2 GB. ]

Для диалогов с контекстом 4 k токенов (L = 4096) и B = 4:

[ M_{\text{act}} ≈ 4 × 4096 × 12288 × 80 × 2 Б × 1.2 ≈ 240 GB. ]

Это уже превышает память любой текущей видеокарты, поэтому в продакшн используют kv‑cache compression (FP8, sparsity) и sliding‑window attention. Сжатие kv‑cache до 0.3 × приводит к реальному требованию ≈ 70 GB.

---

3. Память под градиенты и оптимизаторы (только обучение)

Для обучения важны три компонента:

1. Градиенты – обычно хранятся в FP16 (2 Б) или FP8 (1 Б).
2. Состояния оптимизатора – AdamW требует два момента (m, v) → 2 × bytes_per_elem.
3. Промежуточные тензоры – зависят от стратегии checkpoint‑инга.

Итоговое потребление:

[ M_{\text{train}} = M_{\text{params}} × (1 + \alpha_{\text{opt}}) + M_{\text{act}} × \beta_{\text{ckpt}} ]

α_opt ≈ 2 для AdamW (m и v).
β_ckpt ≈ 1 без checkpoint‑инга, 0.5 с 2‑уровневым.

Пример: 70‑B модель, FP16, B = 2, L = 2048, full‑precision AdamW:

[ M_{\text{train}} ≈ 150 GB × (1+2) + 2.2 GB × 1 ≈ 452 GB. ]

Для 8‑битной градиент‑квантования (FP8) и 2‑уровневого checkpoint‑инга:

[ M_{\text{train}} ≈ 75 GB × 3 + 1.1 GB ≈ 227 GB. ]

Эти цифры объясняют рост спроса на H100 40 GB → H100 80 GB → H200 96 GB в 2026 году.

---

4. Практические приёмы экономии памяти

Приём	Эффект	Когда применим
KV‑cache FP8	−70 % памяти kv‑cache	Инференс с контекстом > 2 k токенов
Gradient Checkpointing (2‑lvl)	−40 % активаций	Обучение, когда batch ≤ 4
ZeRO‑3 (optimizer‑state off‑device)	−66 % optimizer memory	Большие модели > 200 B
Flash‑Attention 2	−30 % временных буферов	Любой inference, особенно при B > 1
Paged Attention (NVIDIA MIG)	Динамический под‑выдел	Мульти‑тенантные сервисы с переменным L

Кейс: Компания X‑AI развернула 70‑B модель в продакшн с контекстом 8 k токенов. Исходный расчёт требовал 340 GB. Применив FP8 kv‑cache и Flash‑Attention 2, они снизили потребление до 115 GB и смогли разместить модель на 2 × RTX A6000 (48 GB) вместо дорогих H200.

---

5. Планирование кластера: от одного GPU к масштабируемому рендеру

1. Определить целевой режим – inference vs. training, batch size, max context.

2. Считать базовые требования (разделы 1‑3) и добавить 10 % «запас» для фрагментации.

3. Выбрать топологию:

   • DP (Data Parallelism) – делит batch, требует полную копию модели на каждом GPU.
   • TP (Tensor Parallelism) – делит параметры, экономит память, но увеличивает коммуникацию.
   • PP (Pipeline Parallelism) – разбивает слои, полезно при L > 4 k.

4. Пример расчёта кластера для 1 T‑parameter модель (FP8 inference, B = 1, L = 4 k):

   • Память модели: 250 GB → 4 × H200 96 GB (TP=4) → 24 GB на GPU.
   • KV‑cache (FP8, 0.3 ×): ~30 GB → помещается в тот же GPU.
   • Итог: 4 × H200 (96 GB) покрывает всё без MIG.

5. Мониторинг – используйте nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu + nvtop + кастомный Prometheus‑exporter, чтобы фиксировать «memory spikes» при длинных запросах. Пороговое оповещение в 85 % помогает избежать OOM‑перезапусков.

---

Итог

Точная оценка видеопамяти — не просто академическое упражнение, а обязательный этап любого проекта с LLM в 2026 году. Формулы, приведённые в статье, позволяют быстро посчитать потребление для любой конфигурации, а набор практических приёмов (FP8 kv‑cache, ZeRO‑3, Flash‑Attention 2) даёт инструменты для экономии до 70 % памяти без потери качества. Применяя эти расчёты при планировании кластера, инженеры избегают дорогостоящих «memory‑overruns», оптимизируют затраты на облако и ускоряют вывод новых моделей в продакшн. Помните: в мире триллионных параметров каждый гигабайт на счету.