«Сколько нужно видеокарт, чтобы запустить 70B?» Кажется, что это задачка на деление: просто взять размер модели, разделить на память одной карты и округлить вверх. Сервис, собранный по такому расчёту, прекрасно отвечает одному тестировщику. А потом приходят первые десять пользователей с большими документами, и он встаёт.
Модель только один из жильцов видеопамяти. Рядом с ней живёт KV-кеш каждого диалога, о нём чуть ниже. За пределами GPU есть ещё сеть между картами и серверами, процессор, который раздаёт запросы, и диски, с которых всё это загружается. А за последние два года добавились стойки больше чем на сотню киловатт и модели с триллионом параметров, из которых на каждый токен работает малая часть.
Считаем память на пальцах
В формате BF16 каждый параметр занимает два байта. Для модели на 70 млрд параметров это 140 ГБ, и это только веса. Вот сколько памяти у ускорителей, которые уже стоят или вот-вот появятся в дата-центрах:
Ускоритель | Память на GPU | Скорость памяти | Останется после весов 70B в BF16 |
80 ГБ HBM3 | 3,35 ТБ/с | веса не поместятся | |
141 ГБ HBM3e | 4,8 ТБ/с | впритык, под кеш почти ничего | |
180 ГБ HBM3e | около 8 ТБ/с | около 40 ГБ | |
288 ГБ HBM3e | около 8 ТБ/с | около 148 ГБ | |
288 ГБ HBM3e | 8 ТБ/с | около 148 ГБ | |
288 ГБ HBM4 | до 22 ТБ/с | около 148 ГБ |
Прикидка грубая, ведь движок инференса и служебные буферы тоже занимают память. Но порядок величин виден сразу. Скорость памяти пригодится чуть позже, когда дойдём до генерации ответа.
Теперь добавим пользователей. Чтобы на каждом шаге не перечитывать весь диалог, модель хранит ключи и значения для каждого уже обработанного токена. Это и есть KV-кеш, и его размер считается прямо по конфигурации модели. У Llama 3.1 70B 80 слоёв, 8 «голов» для ключей и значений и размерность головы 128. Ключи и значения хранятся отдельно, каждое число занимает 2 байта. Перемножаем: 2 × 80 × 8 × 128 × 2 байта, получается около 320 КБ на один токен.
Треть мегабайта звучит безобидно. Но один диалог на полный контекст в 128 тысяч токенов занимает уже около 43 ГБ. А десять человек, каждый из которых загрузил документ на 32 тысячи токенов, займут около 107 ГБ, это три четверти от объёма самих весов.
Веса занимают фиксированный объём, а кеш растёт с каждым новым диалогом, и под нагрузкой память съедает именно он. Вычислительные блоки GPU в этот момент могут быть заняты наполовину, а новые запросы уже стоят в очереди.
Веса можно ужать. В FP8 та же 70B займёт около 70 ГБ, но качество после квантования придётся проверять на своих задачах. Можно взять модель поменьше. Если не подходит ни то, ни другое, модель делят между несколькими картами, и с этого момента в расчёт входит сеть.
Один ответ, две разные нагрузки
Пока пользователь ждёт ответа, GPU работает в двух очень непохожих режимах. Сначала идёт prefill. Модель разом читает весь запрос и заполняет KV-кеш, вычислений тут много, зато они хорошо параллелятся. Потом начинается decode, и модель выдаёт ответ по одному токену. Каждый следующий токен зависит от предыдущего, считать на шаге нужно немного, а вот читать из памяти приходится все веса и весь накопленный кеш.
Поэтому и тормозить сервис может двумя способами. Если первое слово появляется через десять секунд, смотрите на очередь и prefill. Если первое слово пришло сразу, а дальше текст ползёт, значит, вы упираетесь в decode и скорость памяти из таблицы выше. MLCommons в своих тестах измеряет эти задержки отдельно: TTFT – время до первого токена, TPOT – время на каждый следующий.
Режимы ещё и мешают друг другу. Пришёл новый запрос с длинным документом, его prefill забирает время GPU, и у всех, кто сейчас получает ответ, текст на мгновение замирает. В крупных системах prefill и decode всё чаще разносят по разным GPU, как это делает NVIDIA Dynamo. Расплачиваться приходится сетью, ведь KV-кеш нужно перегнать с одних карт на другие.
Делим модель: внутри сервера и между серверами
Если веса не влезают в одну карту, модель режут. Есть два основных способа, и в реальных конфигурациях их часто совмещают. При tensor parallelism каждый слой делят между несколькими GPU, каждая карта считает свой кусок матрицы, а потом все обмениваются результатами. При pipeline parallelism карты выстраиваются в конвейер: первая считает начальные слои, вторая продолжает.
Бывает и так, что резать ничего не нужно. Если модель помещается в одну карту, можно поставить по копии на каждую и раздавать им разные запросы. Весь сервис обслужит больше людей, но конкретный ответ быстрее не станет.
Начнём с памяти, она обычно заканчивается первой.
Больше всего от сети зависит tensor parallelism: там карты синхронизируются пару раз на каждом слое, у 70B это больше сотни обменов на один токен. Внутри сервера GPU соединены через NVLink, и у H100 это 900 ГБ/с суммарно в обе стороны, то есть 450 ГБ/с в каждую. Между серверами данные идут через сетевые адаптеры. В DGX H100 у каждого GPU свой адаптер InfiniBand на 400 Гбит/с, это около 50 ГБ/с в каждую сторону. В одинаковых единицах разница примерно девятикратная.
В реальной работе скорость обычно ниже, чем в спецификациях. DeepSeek в отчёте о V3 указывает для своего кластера H800 160 ГБ/с по NVLink против 50 ГБ/с по InfiniBand, и, по словам разработчиков, это замер в одну сторону. NVLink у H800 к тому же урезан, так что разрыв там около трёх раз.
С новыми поколениями разрыв не сократился. У Rubin NVLink 6 даёт 3,6 ТБ/с на GPU в обе стороны, то есть 1,8 ТБ/с в каждую. Сетевой адаптер ConnectX-9 рассчитан на 1,6 Тбит/с, это 200 ГБ/с. Снова примерно девять раз.
NVIDIA ещё в поколении Blackwell пошла в обход. Вместо того чтобы подтягивать сеть до NVLink, она растянула NVLink на всю стойку. В GB200 NVL72, а теперь и в Vera Rubin NVL72 семьдесят два GPU связаны между собой так же, как восемь карт внутри обычного сервера. Граница, за которой начинается медленная сеть, отодвинулась с 8 карт до 72. Нам кажется, что это самое важное изменение в железе за последние пару лет, важнее прироста терафлопс. Модель, которой раньше нужно было девять серверов и медленная сеть между ними, теперь целиком живёт внутри одной стойки.
Это стоит держать в голо Больше всего от сети зависит tensor parallelism ве, если вы арендуете GPU в облаке. Вместе с картой вы арендуете её место в чужой топологии. Две H100 в одном сервере с NVLink и две H100 в разных серверах ведут себя по-разному, хотя в прайсе строки могут выглядеть одинаково. Сеть между узлами тоже бывает разной: кроме InfiniBand, используют Ethernet с RDMA (RoCE), на такой сети Meta, например, обучала Llama 3 405B. Перед арендой под распределённую модель спросите у провайдера, как соединены карты внутри узла и что стоит между узлами.
MoE: память как у гиганта, вычисления как у середнячка
Пока мы считали плотную 70B, многие крупные открытые модели перешли на Mixture of Experts. Внутри такой модели много «экспертов», отдельных блоков, и на каждый токен включаются только некоторые из них. У DeepSeek-V3 671 млрд параметров, из которых на один токен работают 37 млрд. А в MLPerf Inference 6.1 компания Lambda в открытой категории запустила Kimi K2.6, MoE-модель с триллионом параметров.
Для инфраструктуры это неприятная асимметрия. Считать приходится как для модели на 37B, а хранить нужно все 671B, потому что заранее неизвестно, какой эксперт понадобится следующему токену. Экспертов раскладывают по разным GPU (это называют expert parallelism), и каждый токен отправляется туда, где лежит нужный ему эксперт. Обмен идёт постоянно и по схеме «все со всеми», так что сеть снова выходит на первый план. С MoE одной цифры в названии модели уже не хватает. По общему числу параметров видно, сколько понадобится памяти, а по числу активных – насколько быстро модель будет отвечать. Мы бы всегда уточняли обе.
В отчёте о V3 DeepSeek описывает свою рабочую конфигурацию. Для обработки входящих запросов (prefill) минимум 4 узла и 32 GPU, для генерации ответов – 40 узлов и 320 GPU. Сами веса в FP8 помещаются и в один сервер с восемью H200, но для потока пользователей DeepSeek разворачивает модель вот так.
Зачем серверу с GPU процессор, RAM и NVMe
Удобнее всего разбирать на примере DGX H100, потому что NVIDIA публикует его полный состав. Кроме восьми GPU там два 56-ядерных Xeon, 2 ТБ оперативной памяти и восемь NVMe по 3,84 ТБ под кеш данных. Оперативной памяти в три с лишним раза больше, чем видеопамяти, а на дисках почти 31 ТБ.
Процессор делает работу, без которой ускорители простаивают. Он принимает запросы, режет текст на токены, ведёт очередь и подаёт данные на GPU. Если CPU не успевает, видеокарты в мониторинге выглядят недогруженными, и легко решить, что мощности с запасом.
Диски нужны при запуске, чтобы загрузить веса в видеопамять. 140 ГБ – заметный объём, и чем чаще сервис переключает модели, тем чаще повторяется холодный старт. Но в последние год-два у RAM и NVMe нашлась работа поважнее. Они хранят KV-кеш, который не поместился в видеопамять.
Представьте, что пользователь вернулся к диалогу через десять минут. Или сто человек задают вопросы по одному и тому же длинному документу. Пересчитать кеш значит ещё раз прогнать prefill, и проще достать готовый кеш с уровня пониже. NVIDIA Dynamo умеет выгружать его из видеопамяти в RAM, а оттуда на локальный диск. На CES 2026 NVIDIA показала отдельную платформу хранения под такой кеш на NVMe с DPU BlueField-4, поставки обещаны во второй половине 2026 года.
