Конфигурация складывается из четырёх факторов: сколько памяти требует модель в выбранном режиме, какой тип параллелизма использует движок, сколько трафика этот параллелизм создаёт между картами и что вы готовы платить за простой оборудования. NVLink здесь не универсальное решение: в одних режимах он даёт кратный выигрыш, в других не участвует вообще.
Как устроен мультиGPU-хост: NVLink, NVSwitch и PCIe
Ускорители обмениваются данными либо через PCIe с участием корневого комплекса процессора, либо напрямую по выделенному интерконнекту GPU–GPU. NVLink — второй путь. Разница не только в скорости: PCIe работает как пакетная транспортная шина, а NVLink даёт семантику памяти — ядро на одном GPU адресует память соседнего почти как свою, с аппаратной когерентностью.
Здесь кроется главное заблуждение. Объединение памяти через NVLink не означает, что два ускорителя по 80 ГБ превращаются в один со 160 ГБ. Адресное пространство становится общим, обращение к чужой памяти дешевеет, но физически память остаётся раздельной, и модель по-прежнему нужно разложить по картам средствами фреймворка.
Поколения NVLink и честное сравнение полосы с PCIe
Половина путаницы в цифрах — из-за единиц измерения: производители указывают суммарную двунаправленную полосу, инженеры оперируют однонаправленной. Ниже всё в двунаправленном виде.
| Поколение | Архитектура | Флагманский ускоритель | Полоса на чип (двунапр.) |
|---|---|---|---|
| NVLink 1.0 | Pascal | P100 | \~160 ГБ/с |
| NVLink 2.0 | Volta | V100 | \~300 ГБ/с |
| NVLink 3.0 | Ampere | A100 | \~600 ГБ/с |
| NVLink 4.0 | Hopper | H100, H200 | \~900 ГБ/с |
| NVLink 5.0 | Blackwell | B200, GB200 | \~1800 ГБ/с |
PCIe 4.0 x16 даёт около 64 ГБ/с суммарно, PCIe 5.0 x16 — около 128 ГБ/с. То есть H200 с NVLink 4.0 обменивается с соседом примерно в 7 раз быстрее, и это без учёта задержки, которая на прямом линке заметно ниже. Реальная полоса всегда ниже табличной: 85–92% от паспорта, на мелких сообщениях — меньше.
Поддержка NVLink есть у A100, H100, H200, B200, GB200/GH200, у профессиональных RTX A6000 и A5000 (через мост) и у RTX PRO 6000 Blackwell, но её нет ни в игровых GeForce начиная с RTX 40, ни в рабочих станциях на Ada Lovelace, включая RTX 6000 Ada.
Мост, NVSwitch и почему 8 GPU в узле — архитектурная константа HGX
- Мост (NVLink Bridge) — планка, соединяющая ровно две карты: RTX A6000, A5000, PCIe-версии A100, H100 и H200 NVL. Между разными парами обмен идёт по PCIe.
- NVSwitch внутри узла — коммутирующие микросхемы на плате-носителе HGX/DGX: каждый GPU обменивается с каждым на полной скорости.
- NVLink-C2C — линк процессор–ускоритель в суперчипах Grace Hopper и Grace Blackwell с когерентным доступом к общей памяти.
Почему восемь? Число упирается в количество портов NVSwitch и линков на ускорителе: полносвязная топология на полной полосе укладывается в восемь чипов и четыре коммутатора. Девятый потребует либо сокращения полосы, либо второго уровня коммутации. А ещё физика: восемь ускорителей по 700 Вт — около 5,6 кВт только на GPU в корпусе 8U.
Выше узла начинается NVLink Switch System — внешние коммутаторы, собирающие комплексы вроде GB200 NVL72 в единый домен. Это штучное решение уровня ИИ-фабрики; большинству компаний доступен 8-карточный узел как верхняя граница вертикального масштабирования, дальше начинается горизонтальное по InfiniBand или Ethernet с RoCE.
Обучение больших моделей: как посчитать нужное число ускорителей
Здесь чаще всего и рушатся планы: команда считает память по весам, берёт две карты «с запасом» и упирается в нехватку памяти на первом шаге оптимизатора.
Формула бюджета памяти для тренировки и пример расчёта на 70B
- Веса модели. В BF16 — 2 байта на параметр.
- Градиенты. Ещё 2 байта на параметр.
- Состояния оптимизатора. Для Adam/AdamW — моменты первого и второго порядка в FP32 плюс мастер-копия весов: около 12 байт на параметр.
- Активации. Зависят от батча, длины последовательности, числа слоёв и техники контрольных точек — от единиц до сотен гигабайт.
Первые три статьи дают 16 байт на параметр для полного обучения в смешанной точности, плюс 10–15% на фрагментацию аллокатора.
Проверим на 70B: веса в BF16 — 140 ГБ, градиенты — 140 ГБ, состояния AdamW — около 840 ГБ. Статическая часть — 1120 ГБ, плюс активации 100–200 ГБ на узел. Округлим до 1,3 ТБ. Узел из восьми H200 по 141 ГБ даёт 1128 ГБ HBM3e — впритык. То есть полное дообучение 70B — это минимум два узла по восемь карт. При LoRA градиенты и состояния оптимизатора считаются лишь для 0,1–1% параметров, но веса всё равно надо держать в памяти.
| Модель | Режим | Память (веса + градиенты + оптимизатор + активации) | Конфигурация |
|---|---|---|---|
| 7B | Полное дообучение, BF16 | \~130 ГБ | 2× H100 80 ГБ |
| 7B | LoRA, BF16 | \~25 ГБ | 1× RTX A6000 48 ГБ |
| 7B | QLoRA, 4 бита | \~10 ГБ | 1× RTX 4090 24 ГБ |
| 13B | Полное дообучение, BF16 | \~240 ГБ | 4× H100 80 ГБ |
| 13B | LoRA, BF16 | \~40 ГБ | 1× H100 80 ГБ |
| 70B | Полное дообучение, BF16 | \~1300 ГБ | 2 узла × 8 H200 |
| 70B | LoRA, BF16 | \~190 ГБ | 4× H200 141 ГБ |
| 70B | QLoRA, 4 бита | \~65 ГБ | 1× H200 141 ГБ |
Отклонение на 20–30% в обе стороны — обычная ситуация. Главное следствие: выбор режима обучения меняет требования к оборудованию сильнее, чем выбор самого оборудования.
Где проходит граница 2 → 4 → 8 карт
Одна карта → две. Модель перестала помещаться в память одного ускорителя. На двух картах с мостом работают LoRA-дообучение средних моделей и инференс с тензорным параллелизмом степени 2.
Две → четыре. Четыре карты на мостах — две независимые пары, обмен между парами идёт через PCIe, в 7–10 раз медленнее. Для параллелизма данных терпимо, для тензорного параллелизма степени 4 — нет. Нужен NVSwitch, а не набор мостов.
Четыре → восемь. Узел HGX берут ради равномерности: любая пара карт обменивается на одинаковой скорости, снимается и вопрос привязки к NUMA-доменам.
Восемь → кластер. Внутри узла полоса измеряется сотнями гигабайт в секунду, между узлами — десятками. Типовой выбор — InfiniBand NDR 400 Гбит/с (50 ГБ/с) на ускоритель с GPUDirect RDMA. Обычная сеть 25 Гбит/с обнуляет выигрыш от NVLink: восемь карт во втором узле дадут прибавку процентов в двадцать вместо удвоения.
Практическое правило: если модель помещается в один узел — держите её в одном узле, даже ценой более дорогих карт с большей памятью.
Инференс крупных LLM: что реально определяет число карт
Веса статичны и занимают предсказуемый объём, а всё остальное растёт вместе с нагрузкой.
KV-кэш, длина контекста и число параллельных сессий
KV-кэш — сохранённые ключи и значения внимания для обработанных токенов. Объём считается так:
2 × число_слоёв × размер_скрытого_состояния × длина_контекста × байт_на_элемент × число_сессий
Для 70B (80 слоёв, скрытое состояние 8192) при кэше в FP16 одна сессия с контекстом 8000 токенов занимает около 20 ГБ. Тридцать параллельных сессий потребуют порядка 600 ГБ только под кэш — вчетверо больше, чем веса в квантованном виде.
Группированное внимание (GQA) сокращает кэш в 4–8 раз, квантизация кэша до 8 бит — вдвое. Но порядок величин остаётся: в продуктиве число карт задаёт не размер весов, а произведение длины контекста на число сессий.
Отсюда два режима оптимизации:
- Под задержку. Важны TTFT и скорость генерации для одного пользователя. Помогает тензорный параллелизм, но растёт объём коммуникаций.
- Под пропускную способность. Выгоднее держать несколько независимых копий модели на разных картах — коммуникаций между GPU нет вовсе.
Прежде чем закладывать закупку под пиковую нагрузку, имеет смысл снять метрики на арендованных мощностях. Под такие задачи у Cloud4U есть аренда сервера с GPU: облачные конфигурации с ускорителями NVIDIA (Tesla P100/M40/M60, RTX 4090) разворачиваются вместе с IaaS-инфраструктурой, оплата помесячно по факту потребления, без капитальных вложений. Для профилирования KV-кэша и проверки гипотез по квантизации этого достаточно, а полученные цифры уже можно класть в обоснование закупки.
Тензорный параллелизм против послойного разбиения: когда NVLink даёт эффект
Послойное разбиение (pipeline). Слои 1–40 на первой карте, 41–80 — на второй. Трафик между картами — один тензор активаций на границе, десятки мегабайт; в любой момент работает одна карта, вторая ждёт. Так по умолчанию делают llama.cpp и Ollama. Интерконнект здесь нагрузить нечем.
Тензорный параллелизм. Каждая матрица весов разрезана по всем картам, после каждого слоя выполняется all-reduce. Для 70B при генерации это сотни обменов в секунду, и разница между NVLink и PCIe на четырёх картах достигает 1,5–2 раз по скорости генерации. Так работают vLLM, TensorRT-LLM, SGLang при tensor_parallel_size > 1; в llama.cpp тензорный параллелизм тоже появился, но включать его нужно явно.
Как отличить одно от другого на стенде: запустите nvidia-smi dmon во время генерации. При послойном разбиении загрузка идёт «волной», каждая карта в районе 40–50%; при тензорном параллелизме все карты загружены одновременно и одинаково. Второй признак — счётчики трафика NVLink (nvidia-smi nvlink -gt d).
Вывод: сначала выберите движок и режим параллелизма, и только потом решайте, нужен ли быстрый интерконнект.
Проверка конфигурации: диагностика интерконнекта и типовые ошибки
Значительная часть жалоб «обучение идёт медленнее, чем на одной карте» объясняется конфигурацией оборудования, которую никто не проверил.
Команды диагностики топологии и пороговые значения полосы
nvidia-smi topo -m
Матрица связей: NV# — прямое соединение NVLink, PIX — общий коммутатор PCIe (приемлемо), PHB — связь через корневой комплекс, SYS — карты в разных NUMA-доменах. Если вы платили за NVSwitch, а видите SYS между половиной карт — это проблема.
nvidia-smi nvlink -s
Состояние и скорость каждого линка: все должны быть Active. Один неактивный линк из восемнадцати на H100 — минус 5% полосы, но чаще он сигнализирует о плохо посаженном модуле.
lspci -vvv | grep -E "LnkCap|LnkSta"
LnkSta должна совпадать с LnkCap. Классическая ошибка сборки — карта в слоте x16, работающая на x4 из-за распределения линий на материнской плате.
Дальше — измерение полосы: p2pBandwidthLatencyTest из CUDA Samples и all_reduce_perf из NCCL Tests.
| Метрика | Норма для 8× H100/H200 | Признак проблемы |
|---|---|---|
| P2P-полоса между парой GPU (однонапр.) | 350–400 ГБ/с | Ниже 100 ГБ/с — обмен идёт через PCIe |
| P2P-задержка | 1,5–3 мкс | Выше 10 мкс — нет прямого пути |
| All-reduce bus bandwidth на 8 GPU (буфер 1 ГБ) | 180–230 ГБ/с | Ниже 50 ГБ/с — NCCL выбрал не тот транспорт |
Если all-reduce проседает, запустите обучение с NCCL_DEBUG=INFO: строки via NET/Socket вместо via NVL означают, что NCCL не нашёл путь по NVLink — обычно из-за контейнера без проброшенных /dev/nvidia-caps или без --ipc=host.
Виртуализация, проброс GPU, MIG и vGPU: что происходит с фабрикой
NVLink-топология не переживает произвольную виртуализацию. При пробросе всех карт по PCIe в одну ВМ топология сохраняется. Но если гипервизор раздал четыре карты из восьмикарточного узла одной ВМ, а четыре другой, NVSwitch программируется на изоляцию разделов, и между картами разных ВМ обмена нет. Проверять топологию надо в своей ВМ, а не на хосте.
Отдельная ловушка: провайдер отдаёт «8 GPU», которые физически стоят в двух серверах и соединены сетью. Формально обещание выполнено, для тензорного параллелизма конфигурация непригодна.
MIG разделяет ускоритель на изолированные экземпляры — до семи на A100/H100; при включённом MIG рассчитывать на NVLink-обмен между картами не стоит. vGPU — разделение карты по времени между ВМ; сценарий не для обучения, а для рабочих мест.
Экономика мультиGPU: собственный узел против аренды
У узла на восемь ускорителей стоимость GPU составляет порядка 70% капитальных затрат, а оставшиеся 30% плюс операционная часть определяют, окупится решение или останется невостребованным.
Киловатты, охлаждение и требования к площадке для узла на 8 GPU
Энергетика узла на H200 (TDP 700 Вт): ускорители 8 × 700 = 5600 Вт, два процессора \~700 Вт, память, NVMe, сеть и вентиляторы \~700 Вт, потери БП (КПД \~94%) +450 Вт. Итого около 7,4 кВт на узел высотой 8U. Типовая офисная стойка проектируется под 5–7 кВт целиком.
Отсюда требования, которых нет в серверной среднего предприятия:
- Ввод питания на стойку от 10 кВт с резервированием по двум лучам и ИБП.
- Отвод 7,4 кВт тепла с двух квадратных метров пола. Воздух справляется до 15–20 кВт на стойку при изоляции коридоров, выше — жидкостное охлаждение.
- Шум порядка 80 дБ и вес 60–90 кг: размещение в офисе исключено.
Если у компании нет машинного зала с подготовленным электропитанием и холодом, к стоимости узла прибавляется либо стройка, либо размещение в коммерческом ЦОДе. Для одного-двух узлов размещение почти всегда дешевле.
Расчёт ТСО за 3 года: покупка против аренды при утилизации 30%, 60% и 90%
Конфигурация для сравнения: узел на 8 ускорителях класса H200 с NVSwitch, период 36 месяцев.
Методика расчёта и допущения. Чтобы сравнение было объективным и не рекламировало конкретный подход, мы взяли консервативные среднерыночные показатели для enterprise-сегмента РФ (III кв. 2026 г.). Эти цифры включают стандартные логистические и дилерские наценки при покупке, а также типовые on-demand тарифы крупных облачных площадок.
- Стоимость узла (62 млн ₽): складывается из 8 ускорителей H200, базовой платы HGX, двух высокопроизводительных CPU, 1 ТБ RAM и NVMe-накопителей с учётом текущих условий поставок.
- Размещение в ЦОД (190 тыс. ₽/мес): рассчитано по тарифам для высокоплотных стоек (\~23–25 тыс. ₽ за 1 кВт/мес) с учётом половины юнитов стойки (8U) и кросс-коннектов.
- Ставка аренды (2100 ₽/GPU-час): усреднённая рыночная ставка для выделенных (bare-metal) инстансов, включающая амортизацию, электропитание и техподдержку. Важно: специализированные провайдеры (включая Cloud4U) часто предлагают более низкие эффективные ставки за счёт оптимизированной архитектуры, гибких планов резервирования и отсутствия скрытых комиссий.
- Эксплуатация: 4% от стоимости оборудования в год — стандартная цена расширенной SLA-поддержки вендора, 0,3 FTE инженера (54 тыс. ₽/мес) — адекватная нагрузка для мониторинга одного узла.
Вариант 1. Покупка узла и размещение в коммерческом ЦОДе
| Статья | Расчёт | Сумма за 3 года |
|---|---|---|
| Узел 8× H200 (с платформой, процессорами, памятью, NVMe) | капитальные затраты | 62 000 000 ₽ |
| Сетевое оборудование (InfiniBand-адаптеры, коммутатор, оптика) | капитальные затраты | 3 500 000 ₽ |
| Проектирование, монтаж, ввод в эксплуатацию | разово | 900 000 ₽ |
| Размещение в ЦОДе (½ стойки, 8 кВт) | 190 000 ₽/мес × 36 | 6 840 000 ₽ |
| Расширенная гарантия и сервисная поддержка вендора | 4% от стоимости узла в год × 3 | 7 440 000 ₽ |
| Администрирование (0,3 ставки инженера) | 54 000 ₽/мес × 36 | 1 944 000 ₽ |
| Лицензии на платформу виртуализации и управление | 320 000 ₽/год × 3 | 960 000 ₽ |
| Итого ТСО за 36 месяцев | 83 584 000 ₽ |
Вариант 2. Аренда эквивалентных мощностей
Рыночная ставка — ориентировочно 2100 ₽ за GPU-час, то есть 16 800 ₽/час за узел. Плюс разовые затраты на перенос данных и настройку окружения — 600 000 ₽ и хранение датасетов и контрольных точек (50 ТБ) — 55 000 ₽/мес. Часов в 36 месяцах — 26 280.
| Утилизация | Оплаченных часов | Аренда за 3 года | + хранение и внедрение | ТСО аренды | ТСО покупки | Разница |
|---|---|---|---|---|---|---|
| 30% | 7 884 | 132 451 200 ₽ | 2 580 000 ₽ | 135 031 200 ₽ | 83 584 000 ₽ | аренда дороже на 51 447 200 ₽ |
| 60% | 15 768 | 264 902 400 ₽ | 2 580 000 ₽ | 267 482 400 ₽ | 83 584 000 ₽ | аренда дороже на 183 898 400 ₽ |
| 90% | 23 652 | 397 353 600 ₽ | 2 580 000 ₽ | 399 933 600 ₽ | 83 584 000 ₽ | аренда дороже на 316 349 600 ₽ |
Точка безубыточности: 83 584 000 ₽ минус 2 580 000 ₽ постоянных расходов аренды даёт 81 004 000 ₽ на оплату часов, то есть 4 822 часа, или около 18% загрузки за три года. При этом важно помнить: данный расчёт построен по верхним границам рыночных ставок. При работе со специализированным провайдером, таким как Cloud4U, точка безубыточности смещается в пользу аренды ещё сильнее за счёт более конкурентных часовых тарифов и нулевых затрат на внедрение.
Но чистые деньги — не единственный критерий:
- Срок поставки. 8-карточная платформа приходит в Россию за 3–6 месяцев с момента оплаты, облачные мощности доступны за несколько рабочих дней.
- Риск простоя. За расчётом при 30% утилизации стоит узел за 62 млн ₽, который две трети времени не приносит отдачи. При непредсказуемом графике проектов аренда переводит капитальные затраты в операционные.
- Размещение данных. Персональные данные требуют соответствия 152-ФЗ, аттестации и сертификаций у провайдера.
Суммы ориентировочны: итог сдвинется на ±25% в зависимости от поставщика и договорной ставки — при годовом обязательстве облачные ставки обычно опускаются на 30–40% от почасовых.
Главные выводы
Число ускорителей выводится не из мощности карт, а из трёх ответов: сколько памяти требует выбранный режим, какой параллелизм использует движок и сколько коммуникаций он создаёт. Полное дообучение 70B требует порядка 1,3 ТБ памяти и выходит за пределы одного узла, тогда как LoRA на той же модели укладывается в четыре карты. На инференсе конфигурацию задаёт KV-кэш, растущий пропорционально длине контекста и числу сессий. NVLink даёт кратный выигрыш при тензорном параллелизме и не даёт ничего при послойном разбиении.
При высокой и предсказуемой загрузке собственный узел окупается за несколько месяцев, но требует машинного зала на 7,4 кВт и полугода ожидания поставки. Аренда закрывает другие задачи — быстрый старт, проверку гипотез, пиковые нагрузки и проекты с ограниченным горизонтом. Прежде чем защищать бюджет закупки, снимите метрики на арендованной конфигурации: реальные цифры по утилизации, длине контекста и профилю коммуникаций стоят дороже любых паспортных характеристик.
