Сколько памяти нужно для LLM: как рассчитать HBM для модели 7B, 70B и 400B

Приветствую всех, кто хоть раз открывал страницу с характеристиками GPU-сервера, видел строчку «80 ГБ HBM2e» и думал: «А хватит ли мне этого для моей модели?». Заваривайте кофе, потому что сейчас мы разберёмся с вопросом, который маркетинговые брошюры старательно обходят стороной — как именно посчитать, сколько памяти реально съест ваша языковая модель, и почему ответ «больше — лучше» является одновременно правдой и бесполезным советом.

Мы поговорим о цифрах. Конкретных. С формулами и таблицами. Без «зависит от задачи» и «проконсультируйтесь со специалистом».

Когда вы слышите «модель на 7 миллиардов параметров», мозг автоматически рисует что-то среднее. Не гигантское, не крошечное. Звучит как хороший рабочий инструмент, который должен влезть в одну современную видеокарту. И вот тут начинается первое расхождение с реальностью.

Каждый параметр модели — это число. Конкретное числовое значение веса нейронной сети, которое нужно где-то хранить. И хранить его надо в оперативной памяти GPU (той самой HBM — High Bandwidth Memory), потому что именно там происходят все вычисления. Данные, которые не помещаются в GPU-память, либо не помещаются вообще (и модель просто не запустится), либо начинают гонять туда-сюда между GPU и системной RAM, превращая ваш дорогостоящий кластер в черепаху.

Вот базовая формула, которая открывает глаза:

Память для весов (ГБ) = (Число параметров × Байт на параметр) / 1 073 741 824

Теперь про «байт на параметр» — и вот здесь начинается настоящий разговор.

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

• FP32 (float32) — 4 байта на параметр. Полная точность. Используется при обучении с нуля.
• FP16 / BF16 — 2 байта на параметр. Стандарт для инференса и смешанного обучения.
• INT8 — 1 байт на параметр. Квантование. Небольшая потеря качества, вдвое меньше памяти.
• INT4 / GPTQ — 0,5 байта на параметр. Агрессивное квантование. Для края бюджета.

Запомните это как «правило бытового расчёта»: когда кто-то говорит «у меня модель 7B», не зная формата — это как сказать «у меня машина» без уточнения, легковая это или фура.

Давайте пройдёмся по трём реальным классам моделей и посмотрим на цифры. Будем считать для инференса (запуск уже обученной модели) в формате BF16, потому что именно это сейчас наиболее распространённый сценарий.

7 000 000 000 × 2 байта = 14 000 000 000 байт ≈ 13 ГБ

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

KV-кэш (Key-Value cache) — это память, которую модель использует для хранения «контекста» разговора. Чем длиннее контекст, тем больше кэш. Для 7B модели с контекстом 4096 токенов это ещё порядка 1–2 ГБ, с контекстом 32К — уже 8–12 ГБ.
Активации и промежуточные буферы — ещё 1–3 ГБ в зависимости от batch size.
Фреймворк (vLLM, TGI, TensorRT-LLM) — ещё 1–2 ГБ накладных расходов.
Реальный итог для 7B (BF16, контекст 4K): ~18–20 ГБ

Вывод: A10G на 24 ГБ справится впритык. RTX 3090/4090 (24 ГБ GDDR6X) — тоже, но помните, что GDDR6X — это не HBM, и пропускная способность у неё в 2–3 раза ниже. Ощутите разницу при высоком трафике.

70 000 000 000 × 2 байта ≈ 130 ГБ

Уже сто тридцать гигабайт только на веса. Ни одна современная одиночная GPU не вместит это в BF16. Одна карта A100 80 ГБ или H100 80 ГБ — не вариант. Нужно минимум две.

Реальный итог для 70B (BF16, контекст 4K, batch 8): ~160–180 ГБ

Конфигурации:

2 × H100 SXM 80 ГБ — минимальный рабочий вариант. Впритык.
4 × A100 80 ГБ — комфортно, есть запас на контекст и батчинг.
8 × A100 40 ГБ — тоже работает, но NVLink-топология становится критичной.
И вот здесь начинается тема, о которой надо говорить отдельно: восемь видеокарт — это не восемь раз по одной видеокарте. Но об этом чуть позже.

400 000 000 000 × 2 байта ≈ 744 ГБ

Семьсот сорок четыре гигабайта только на веса. Плюс кэш, плюс батчинг, плюс фреймворк — и мы переваливаем за терабайт.

Реальный итог для 400B (BF16, контекст 8K, batch 16): 900 ГБ — 1,2 ТБ

Конфигурации:

8 × H100 SXM5 80 ГБ — 640 ГБ суммарно. Не хватает. Придётся использовать INT8 квантование.
8 × H100 SXM5 80 ГБ + INT8 — ~380 ГБ весов, влезает. Но качество чуть снижается.
16 × H100 80 ГБ — комфортный BF16 инференс с запасом.
8 × H200 141 ГБ — 1128 ГБ суммарно. Влезает в BF16 с хорошим запасом. HBM3e, максимальная пропускная способность.

Всё, что написано выше — это про инференс, то есть просто запуск готовой модели. Если вы хотите дообучать модель (fine-tuning) или тренировать с нуля, умножайте на три — и это ещё оптимистичная оценка.

При полном обучении в памяти одновременно живут:

Веса модели (×2 или ×4 байта в зависимости от формата)
Градиенты (столько же, сколько весов)
Состояния оптимизатора Adam — ещё ×8 байт на параметр при FP32
Формула для полного обучения в FP32:

Память ≈ 16 × N_параметров (байт)

Для модели 7B это уже 112 ГБ. Именно поэтому никто не обучает 7B-модели с нуля на одной карточке, и именно поэтому LoRA, QLoRA и другие методы эффективной дообучки стали такими популярными — они хирургически сокращают объём обучаемых параметров.

Вы посчитали память под веса, умножили на два для запаса, заказали сервер — и при первом же боевом запуске с длинным контекстом всё упало с ошибкой OOM (Out of Memory). Знакомая история?

Виноват KV-кэш. И вот почему его нельзя игнорировать ни в одном расчёте.

Когда трансформер обрабатывает текст, на каждом слое он вычисляет ключи (K) и значения (V) для каждого токена в контексте. Эти вычисления нужны снова и снова при генерации следующего токена — поэтому их кэшируют в памяти GPU, а не пересчитывают каждый раз заново. Это правильное решение с точки зрения скорости. Но с точки зрения памяти — это черная дыра, которая растёт линейно с длиной контекста.

Формула KV-кэша:
KV-кэш (байт) = 2 × num_layers × num_heads × head_dim × seq_len × batch_size × байт_на_элемент

Для Llama 3 70B (80 слоёв, контекст 8К, batch 8, BF16):
2 × 80 × 8192 × (8К токенов) × 8 (batch) × 2 байта ≈ 84 ГБ

Восемьдесят четыре гигабайта только кэша. Сверх ста тридцати гигабайт весов.

Теперь понятно, почему при планировании инфраструктуры для продакшн-сервиса (где batch size не единица, а десятки и сотни параллельных запросов) цифры вырастают до совершенно других порядков.

Ошибка первая: «У меня 80 ГБ, значит влезет модель 40B»

Линейный счёт в лоб — это ловушка. Модель 40B в BF16 весит примерно 74 ГБ весов. Кажется, что 80 ГБ хватит. Не хватит. На реальном инференсе с разумным batch size и контекстом 4К вы упрётесь в потолок при первых же нагрузочных тестах. Правило практика: к весам добавляйте минимум 20-25% под оверхед фреймворка, активации и кэш при минимальном batch.

Ошибка вторая: Квантование как волшебная таблетка

«Поставлю INT4, модель похудеет вчетверо, всё влезет в одну карту» — звучит отлично. Но квантование на практике работает неравномерно: часть слоёв (особенно первый и последний) квантуются плохо и могут оставаться в FP16. Плюс KV-кэш обычно остаётся в FP16 независимо от квантования весов. Итоговое сжатие в реальных условиях — 2,5–3 раза, а не 4. И да, для некоторых задач (длинные рассуждения, точная математика, кодогенерация) агрессивное INT4-квантование заметно роняет качество.

Ошибка третья: Считать только один GPU

Когда модель не помещается на одну карту и вы начинаете распределять её между несколькими GPU, появляется новая статья расходов — коммуникации. Каждый слой, который «переезжает» с одного GPU на другой, требует передачи активаций по шине. Если у вас NVLink — это быстро и терпимо. Если PCIe — вы потеряете значительную долю производительности на ожидание данных. Пропускная способность интерконнекта становится не менее важной, чем объём памяти. Но об этом — в отдельной статье.

Если нужно быстро прикинуть конфигурацию, не вдаваясь в формулы, используйте следующий порядок действий:

Шаг 1. Определите базовый объём весов:

Число параметров (в миллиардах) × 2 = приблизительный объём в ГБ при BF16
Число параметров × 1 = объём при INT8
Число параметров × 0,5 = объём при INT4
Шаг 2. Добавьте KV-кэш:

Короткий контекст (до 4К), небольшой batch (до 4): +15-20% от объёма весов
Средний контекст (8–16К), batch 8–16: +40-80% от объёма весов
Длинный контекст (32К+), batch 32+: KV-кэш может превысить объём весов
Шаг 3. Добавьте 15% на накладные расходы фреймворка — и вы получите минимальный порог.

Если итоговая цифра превышает суммарный объём памяти вашей конфигурации GPU — вам нужно либо больше карт, либо более агрессивное квантование, либо меньший batch/контекст.

Мы всю статью говорим о гигабайтах, но HBM — это не просто «много памяти». Это другая физическая архитектура, и она важна именно для LLM.

Представьте стандартную видеокарту на GDDR6X. Память расположена на отдельных чипах вокруг GPU, соединена с ним относительно узкой шиной. A100 на GDDR6 дала бы вам, условно, 672 ГБ/с пропускной способности. Неплохо для игр.

Но A100 на HBM2e даёт 2 000 ГБ/с. Почти в три раза больше. Потому что HBM — это стопка тонких чипов памяти, которые буквально уложены стопкой прямо рядом с GPU (или сверху него, через TSV — сквозные кремниевые переходы). Шина между ними огромная по ширине и очень короткая.

Почему это критично именно для LLM? Потому что трансформеры при инференсе — это задача, ограниченная пропускной способностью памяти, а не вычислительной мощностью. Упрощённо: GPU успевает посчитать раньше, чем успевает прочитать следующий кусок весов из памяти. Чем шире канал памяти — тем быстрее модель генерирует токены. Вот почему H100 на HBM3 (3,35 ТБ/с) генерирует текст заметно быстрее, чем математически сравнимая по FLOPS карта с GDDR6.

Характеристики GPU по памяти и пропускной способности:

• H200 SXM — тип памяти HBM3e, объём 141 ГБ, пропускная способность 4,8 ТБ/с.
• H100 SXM — тип памяти HBM3, объём 80 ГБ, пропускная способность 3,35 ТБ/с.
• A100 SXM — тип памяти HBM2e, объём 80 ГБ, пропускная способность 2,0 ТБ/с.
• A100 PCIe — тип памяти HBM2e, объём 40/80 ГБ, пропускная способность 1,6 ТБ/с.
• RTX 4090 — тип памяти GDDR6X, объём 24 ГБ, пропускная способность 1,0 ТБ/с.

Подытожим всё, о чём мы говорили, в несколько честных тезисов.

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

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

Третье. Квантование — не волшебство, а компромисс. Оно помогает, но не заменяет правильный расчёт.

Четвёртое. HBM — это не просто «больше гигабайт». Это другая пропускная способность, которая напрямую определяет скорость генерации. Для LLM инференса пропускная способность памяти зачастую важнее пиковых FLOPS.

Пятое. Если вы строите серьёзную инфраструктуру, а не домашний стенд — считайте с запасом 30-40%. Потому что контексты будут расти, batch size будет увеличиваться, а модели будут обновляться.

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

Команда ltrade.su занимается поставками GPU-кластеров, ASIC-систем и серверной инфраструктуры для ИИ-задач. Если вы планируете развернуть LLM в продакшене — они помогут рассчитать конфигурацию под ваши реальные нагрузки, а не под красивые цифры из маркетинговых таблиц.

Оставьте заявку на ltrade.su — и получите честный технический расчёт под ваш сценарий использования, без продажи лишнего железа.

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

Успешного инференса и пусть ваш KV-кэш всегда помещается в память!