Анатомия AI-инфраструктуры: почему LLM не работает на одной видеокарте

На Хабре опубликована статья «LLM работает не на одной видеокарте: анатомия AI-инфраструктуры 2026». Автор разбирает, почему запуск большой языковой модели — это не просто деление размера модели на объём памяти одной карты. Сервис, собранный по такой прикидке, выдерживает одного тестировщика, но падает при первых десяти пользователях с большими документами.

Память: веса и KV-кеш

В формате BF16 каждый параметр занимает два байта. Для модели на 70 млрд параметров это 140 ГБ только на веса. У NVIDIA H100 всего 80 ГБ памяти, поэтому веса туда не помещаются. У H200 — 141 ГБ, то есть впритык, и под кеш почти ничего не остаётся. У B200 — 180 ГБ, у B300, AMD MI355X и NVIDIA Rubin — по 288 ГБ.

Помимо весов, в видеопамяти живёт KV-кеш каждого диалога. Модель хранит ключи и значения для всех уже обработанных токенов, чтобы не перечитывать диалог на каждом шаге. Для Llama 3.1 70B с 80 слоями, 8 головами для ключей и значений и размерностью головы 128 это около 320 КБ на один токен. Один диалог на полный контекст в 128 тысяч токенов занимает уже около 43 ГБ. Десять пользователей с документами по 32 тысячи токенов — около 107 ГБ, три четверти от объёма самих весов.

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

Prefill и decode

Пока пользователь ждёт ответа, 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 ГБ/с суммарно в обе стороны. Между серверами данные идут через сетевые адаптеры: в DGX H100 у каждого GPU свой InfiniBand на 400 Гбит/с, около 50 ГБ/с в каждую сторону. Разница примерно девятикратная.

С новыми поколениями разрыв не сократился. У Rubin NVLink 6 даёт 3,6 ТБ/с на GPU в обе стороны, а сетевой адаптер ConnectX-9 рассчитан на 1,6 Тбит/с, то есть 200 ГБ/с. Снова примерно девять раз.

NVIDIA в поколении Blackwell пошла в обход: вместо того чтобы подтягивать сеть до NVLink, она растянула NVLink на всю стойку. В GB200 NVL72, а теперь и в Vera Rubin NVL72 семьдесят два GPU связаны между собой так же, как восемь карт внутри обычного сервера. Граница, за которой начинается медленная сеть, отодвинулась с 8 карт до 72. Автор статьи считает это самым важным изменением в железе за последние пару лет.