Как устроена ИИ-инфраструктура 2026 года: почему для работы LLM нужна не одна видеокарта

«Сколько графических ускорителей потребуется для запуска 70B-модели?» На первый взгляд, это элементарная арифметика: соотнести вес модели с объемом видеопамяти одной карты и округлить в большую сторону. Конфигурация, выстроенная по такому принципу, безупречно обслужит одиночного тестировщика. Однако стоит подключиться первой десятке пользователей с массивными текстами, как система мгновенно исчерпывает ресурсы.

Нейросеть — лишь один из постоянных обитателей видеопамяти. Соседство с ней разделяет KV-кэш каждого активного диалога, к которому мы вернемся чуть позже. За периметром GPU функционирует межсетевая инфраструктура, центральный процессор, распределяющий потоки задач, и дисковая подсистема, откуда эти данные подгружаются. Более того, за последние пару лет ландшафт усложнился: появились стоки энергопотреблением выше ста киловатт и архитектуры с триллионом параметров, где в обработке каждого конкретного токена задействована лишь крошечная доля.

Оцениваем емкость памяти на базовом уровне

В стандарте BF16 каждый параметр весит два байта. Модель на 70 миллиардов параметров требует 140 ГБ исключительно под весовые коэффициенты. Ниже приведены актуальные и перспективные показатели памяти ускорителей, функционирующих в современных дата-центрах:

Ускоритель	Память на GPU	Пропускная способность памяти	Остаток после размещения весов 70B в BF16
NVIDIA H100	80 ГБ HBM3	3,35 ТБ/с	веса не помещаются
NVIDIA H200	141 ГБ HBM3e	4,8 ТБ/с	впритык, под кэш места практически нет
NVIDIA B200	180 ГБ HBM3e	около 8 ТБ/с	порядка 40 ГБ
NVIDIA B300	288 ГБ HBM3e	около 8 ТБ/с	порядка 148 ГБ
AMD MI355X	288 ГБ HBM3e	8 ТБ/с	порядка 148 ГБ
NVIDIA Rubin	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 (декодирования), когда модель выдает текст по одному токену. Каждый последующий токен обусловлен предыдущими, объем математических операций здесь невелик, зато на каждом шаге требуется вычитывать из памяти полный массив весов и накопленный кэш.

Именно поэтому задержки сервиса могут возникать по двум разным причинам. Если первое слово появляется с задержкой в десяток секунд, узким местом выступает очередь и префилл. Если же старт происходит мгновенно, но далее текст генерируется медленно, мы упираемся в декодирование и пропускную способность памяти, указанную в таблице выше. В бенчмарках MLCommons эти метрики разделены: TTFT (Time to First Token) измеряет время до первого токена, а TPOT (Time Per Output Token) фиксирует скорость генерации последующих.

Более того, эти режимы конкурируют за ресурсы. Поступление нового запроса с объемным документом инициирует ресурсоемкий префилл, способный на мгновение «подморозить» выдачу текста для всех текущих пользователей. В масштабных инсталляциях префилл и декодирование все чаще разводят по разным группам графических ускорителей, как это реализовано в NVIDIA Dynamo. Платой за такое разделение становится нагрузка на сеть, поскольку KV-кэш необходимо оперативно транслировать между картами.

Шардинг модели: внутри узла и между серверами

Если весовые коэффициенты превышают емкость одного ускорителя, модель подвергают сегментации. Существует два базовых подхода, которые в производственных средах регулярно комбинируют. При использовании тензорного параллелизма (tensor parallelism) каждый отдельный слой распределяется по нескольким GPU: каждая карта обрабатывает свой фрагмент матриц, после чего узлы обмениваются результатами. При конвейерном параллелизме (pipeline parallelism) ускорители выстраиваются последовательно: первый рассчитывает начальные слои, второй подхватывает эстафету.

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

Начнем с аппаратной памяти, так как ее дефицит проявляется в первую очередь.

Наиболее критичен к сетевым задержкам тензорный параллелизм: в нем синхронизация карт происходит неоднократно на каждом слое, что для 70B-модели трансформируется в сотни обменов данными на один токен. Внутри серверного шасси GPU объединены через интерфейс NVLink — для архитектуры H100 это 900 ГБ/с суммарно в дуплексном режиме (по 450 ГБ/с в каждую сторону). Межсерверный обмен задействует специализированные сетевые адаптеры. В конфигурации DGX H100 каждый ускоритель снабжен собственным InfiniBand-адаптером на 400 Гбит/с, что составляет порядка 50 ГБ/с в каждом направлении. В сопоставимых единицах измерения разрыв составляет примерно девятикратную величину.

Реальные показатели производительности нередко уступают паспортным. В техническом отчете о модели V3 разработчики DeepSeek фиксируют для своего кластера H800 скорость по NVLink на уровне 160 ГБ/с против 50 ГБ/с по InfiniBand, причем, по их утверждению, это замеры в одностороннем порядке. Интерфейс NVLink на картах H800 аппаратно урезан, поэтому итоговый разрыв там сократился примерно до трех раз.

С выходом новых поколений эта пропорция не изменилась. В архитектуре Rubin интерфейс NVLink 6 обеспечивает до 3,6 ТБ/с суммарного трафика на GPU (1,8 ТБ/с в каждую сторону). Сетевой адаптер ConnectX-9 рассчитан на пропускную способность в 1,6 Тбит/с, что эквивалентно 200 ГБ/с. Соотношение вновь остается на отметке около девяти раз.

Начиная с поколения Blackwell, компания NVIDIA нашла принципиальный обходной путь. Вместо попыток подтянуть пропускную способность стандартных сетей до уровня NVLink, инженеры масштабировали саму шину NVLink на уровень целой серверной стойки. В системах GB200 NVL72, а позднее и в Vera Rubin NVL72, все семьдесят два графических процессора объединены по тому же высокоскоростному принципу, что и восемь плат в границах одного корпуса. Рубеж, за которым начинается относительно медленная сетевая инфраструктура, сдвинулся с 8 до 72 устройств. По нашему мнению, это важнейшая аппаратная трансформация последних лет, превосходящая по значимости простой прирост терафлопс. Модель, ранее требовавшая девяти серверов со связью через межсетевой интерфейс, теперь целиком умещается в рамках единого монтажного шкафа.

Данное обстоятельство критически важно учитывать при облачной аренде инфраструктуры. Арендуя ускоритель, вы одновременно арендуете его положение в физической топологии дата-центра. Пара карт H100 в пределах одного шасси с NVLink и пара таких же карт, разнесенных по разным серверам, продемонстрируют совершенно разную производительность при одинаковой стоимости в прайс-листе. Межсерверный транспорт также вариативен: помимо InfiniBand, активно применяется стандарт Ethernet с поддержкой технологии RDMA (RoCE) — именно на такой сетевой базе компания Meta, например, проводила обучение Llama 3 405B. Прежде чем развертывать распределенную инсталляцию, обязательно уточняйте у облачного провайдера особенности внутренней коммутации узлов.

MoE-модели: аппетит гиганта при скромных вычислительных аппетитах

Пока мы рассматривали плотную (dense) 70B-архитектуру, индустрия массово переключилась на Mixture of Experts (модели смешанных экспертов). В подобных системах задействовано множество изолированных блоков-экспертов, причем для обработки каждого токена активируется лишь часть из них. Так, DeepSeek-V3 оперирует 671 миллиардом параметров, из которых на один токен приходится 37 миллиардов. А в бенчмарке MLPerf Inference 6.1 компания Lambda в рамках открытой категории продемонстрировала работу Kimi K2.6 — триллионной MoE-модели.

Для инфраструктурных инженеров это создает неприятную асимметрию. Объем вычислений соответствует скромной модели на 37B, однако хранить в памяти приходится все 671 млрд параметров, поскольку заранее невозможно предугадать, какой именно эксперт понадобится на следующем шаге. Экспертов распределяют по разным GPU (этот метод называют expert parallelism), и токен перенаправляется именно на то устройство, где располагается нужный компонент. Межмодульный обмен идет непрерывно по схеме «все со всеми», возвращая сетевой вопрос на передний план. Для MoE-архитектур указания одного общего числа параметров уже недостаточно. Полный объем отражает требования к памяти, а количество активных параметров — скорость генерации. Мы бы рекомендовали всегда запрашивать обе метрики.

В отчете о модели V3 инженеры DeepSeek приводят свою рабочую конфигурацию: для фазы префилла задействовано минимум 4 узла (32 GPU), а под генерацию ответов выделено 40 узлов (320 GPU). Притом что веса в квантовании FP8 физически помещаются в единственный сервер с восемью картами H200, для обслуживания потокового пользовательского трафика требуется именно такой масштаб.

Зачем GPU-серверу мощный CPU, системная RAM и NVMe-накопители

Удобнее всего разобрать этот аспект на примере спецификации DGX H100, чью полную архитектуру открыто публикует NVIDIA. Помимо восьми ускорителей, сервер укомплектован двумя 56-ядерными процессорами Xeon, 2 ТБ оперативной памяти и восемью накопителями NVMe емкостью по 3,84 ТБ для кеширования данных. Объем системной RAM почти в три раза превосходит видеопамять, а дисковое пространство суммарно превышает 31 ТБ.

Центральный процессор выполняет критические задачи, без которых ускорители простаивают: принимает входящие запросы, токенизирует текст, управляет очередями и своевременно подает конвейер данных на GPU. Если CPU не справляется с потоком, мониторинг показывает недогрузку видеокарт, создавая иллюзию избытка вычислительной мощности.

Дисковая подсистема востребована при первоначальной загрузке весов в видеопамять. 140 ГБ — существенный массив, и частая ротация моделей на сервере приводит к затяжным холодным стартам. Однако за последние пару лет у RAM и NVMe появилась куда более ответственная роль: они аккумулируют KV-кэш, не поместившийся в лимиты GPU.

Представьте сценарий, когда пользователь возвращается к давней сессии диалога спустя десять минут, либо сотня клиентов одновременно обращаются к одному и тому же объёмному документу. Пересчет кэша с нуля эквивалентен повторному прогону префилла, поэтому гораздо эффективнее извлечь готовый результат из более медленной памяти. Инструментарий NVIDIA Dynamo поддерживает выгрузку кэша из видеопамяти в оперативную память узла, а оттуда на локальные накопители. На выставке CES 2026 компания продемонстрировала специализированную платформу хранения для кэша на базе NVMe SSD и DPU BlueField-4, коммерческий релиз которой запланирован на вторую половину 2026 года.

 

Источник