Дата-центры для ИИ: почему KV-кеш, а не веса модели роняет сервис под нагрузкой

Тема дата-центров для ИИ выглядит далёкой от авторов и маркетологов, пока не приходит счёт за облако или пока собственный сервис не зависает на десятом пользователе. Оригинальный разбор, опубликованный в блоге Artificial Analysis, разложил по полочкам то, что обычно скрыто за маркетинговыми терафлопсами: сколько видеопамяти реально съедает модель, почему «влезает в одну карту» не значит «работает под нагрузкой» и где именно узкое место при масштабировании.

Что меняется в расчётах для тех, кто запускает LLM сам?

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

• Модель в формате BF16 на 70 млрд параметров весит 140 ГБ, и это только веса без служебных буферов. Квантование до FP8 сжимает их примерно до 70 ГБ, но качество после сжатия нужно проверять на конкретных задачах.

• Генерация ответа проходит в двух режимах, и тормозят они по-разному. Сначала идёт prefill: модель разом читает весь запрос и заполняет кеш, вычислений много, но они хорошо параллелятся. Потом decode: модель выдаёт ответ по одному токену, и на каждом шаге читает из памяти все веса и весь накопленный кеш. Если первое слово ответа появляется через десять секунд, проблема в очереди и prefill. Если первое слово пришло сразу, а дальше текст ползёт, упираетесь в скорость памяти GPU.

• Prefill и decode мешают друг другу. Новый запрос с длинным документом забирает вычислительное время GPU, и у всех, кто в этот момент получает ответ, текст замирает. В крупных системах эти режимы всё чаще разносят по разным GPU (так делает, например, NVIDIA Dynamo), но тогда KV-кеш нужно перегонять между картами по сети.

• Сеть между GPU важнее терафлопсов. Внутри сервера карты H100 связаны через NVLink со скоростью около 450 ГБ/с в одну сторону. Между серверами данные идут через InfiniBand со скоростью около 50 ГБ/с в одну сторону: разница примерно в девять раз. По данным DeepSeek из отчёта о модели V3, на кластере H800 замер показал 160 ГБ/с по NVLink против 50 ГБ/с по InfiniBand.

• NVIDIA в поколении Blackwell растянула NVLink на всю стойку. В конфигурации GB200 NVL72 семьдесят два GPU связаны друг с другом на скорости NVLink. Граница, за которой начинается медленная сеть, сдвинулась с 8 карт до 72. Модель, которой раньше требовалось девять серверов с медленными межсерверными каналами, теперь целиком живёт внутри одной стойки.

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

Вот ключевой момент, который часто упускают: тестировщик запускает модель на четырёх картах, получает ответ за секунду и рапортует «всё работает». Веса влезли, инференс (генерация ответа моделью) идёт. Но у одного тестировщика KV-кеш занимает килобайты. У десяти пользователей с длинными документами он занимает сотню гигабайт, больше, чем свободной памяти.

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

Как посчитать самому перед арендой или покупкой?

1. Посчитайте объём весов. Количество параметров умножьте на 2 байта для BF16 (или на 1 байт для FP8). Для 70B это 140 ГБ или 70 ГБ соответственно.

2. Посчитайте KV-кеш на одного пользователя. Формула из источника для Llama 3.1 70B: 2 (ключи и значения отдельно) × 80 (слоёв) × 8 (голов) × 128 (размерность головы) × 2 байта. Получается около 320 КБ на токен. Умножьте на длину контекста, который будут использовать ваши клиенты.

3. Умножьте кеш на число одновременных сессий. Десять пользователей с документами по 32 тысячи токенов, это около 107 ГБ сверх весов. Прибавьте к весам и сравните с доступной видеопамятью.

4. Проверьте топологию, если арендуете в облаке. Две карты в одном сервере с NVLink и две карты в разных серверах ведут себя по-разному, хотя в прайс-листе могут стоить одинаково. Для tensor parallelism (тензорный параллелизм, когда каждый слой модели делят между картами) скорость связи критична: карты обмениваются данными больше сотни раз на один токен у модели 70B.

Есть ли смысл сравнивать с российскими сервисами?

Для автора или маркетолога, который не строит свой дата-центр для ИИ, а пользуется API, расклад проще. YandexGPT и GigaChat берут на себя всю инфраструктуру: KV-кеш, сетевую топологию, балансировку нагрузки. Пользователь платит за токены и не думает про видеопамять.

Но если вы запускаете модель с открытыми весами (open weights) на российском облаке (Yandex Cloud, VK Cloud, Selectel), все расчёты из этого разбора применимы напрямую. По моим наблюдениям, в российских облаках карты серии H100 доступны, но конфигурации серверов и топология NVLink различаются у разных провайдеров, и уточнять это нужно до оплаты, а не после.

Что делать с этим прямо сейчас, по ролям?

Автору Дзена, который использует ИИ для контента: если вы работаете через API (YandexGPT, GigaChat, OpenAI), вас это не касается напрямую. Но если вы заметили, что сервис тормозит при длинных промптах (запросах к модели), теперь вы знаете причину: KV-кеш съедает память. Практический вывод: разбивайте длинные документы на части, а не загружайте всё одним запросом.

Маркетологу и руководителю проекта: если команда предлагает «поднять свою модель на четырёх картах», спросите: сколько одновременных пользователей выдержит эта конфигурация с учётом KV-кеша? Формулу из этого разбора может применить любой технический специалист за десять минут.

Предпринимателю в РФ и СНГ: при аренде GPU в облаке уточняйте не только модель карты, но и топологию: NVLink внутри сервера или сеть между серверами. Разница в скорости, по данным из разбора Artificial Analysis, достигает девяти раз, а цена в прайсе может быть одинаковой.

Частые вопросы

Можно ли запустить модель 70B на одной видеокарте?

В формате BF16 (2 байта на параметр) веса занимают 140 ГБ. Ни одна потребительская карта столько не вмещает. Карта H100 SXM с 80 ГБ тоже не вмещает. При квантовании до FP8 веса сжимаются до примерно 70 ГБ, но нужно оставить место для KV-кеша и служебных буферов. Реалистичный минимум для 70B под нагрузкой, две карты по 80 ГБ или одна карта с большим объёмом (например, A100 на 80 ГБ с FP8), но число одновременных пользователей будет сильно ограничено.

Почему две одинаковые карты в облаке могут работать с разной скоростью?

Потому что важна не только карта, но и способ связи между картами. Если две H100 стоят в одном сервере и связаны через NVLink (450 ГБ/с в одну сторону), tensor parallelism работает быстро. Если они в разных серверах и связаны через InfiniBand (около 50 ГБ/с), каждый обмен данными идёт примерно в девять раз медленнее. При генерации одного токена модель 70B делает больше сотни таких обменов. В прайс-листе облака обе конфигурации могут стоить одинаково.

Что такое KV-кеш простыми словами?

KV-кеш (от key-value, «ключ-значение») это память, которую модель выделяет, чтобы не перечитывать весь диалог с начала на каждом шаге. Представьте, что вы пишете конспект лекции: вместо того чтобы каждый раз слушать с начала, вы заглядываете в записи. Модель делает то же самое, только «записи» занимают сотни гигабайт при длинных диалогах и большом числе пользователей. Именно этот кеш, а не веса модели, чаще всего становится причиной того, что сервис «встаёт» под нагрузкой.