Разработчик экосистемы ВЫШКА Cloud

+7 (4852) 60-91-96 Обсудить проект
Технология · вычислительная платформа ИИ

GPU-кластеры для LLM: как используем в проектах

Проектируем GPU-кластеры под LLM-нагрузку: считаем память под целевые модели, выбираем топологию NVLink и InfiniBand/RoCE, делим ускорители между сервисами и встраиваем пул в Kubernetes с автоскейлингом инференса.

Краткий ответ · сентябрь 2026

Краткий ответ: GPU-кластер для LLM — это расчёт и топология: объём памяти под веса и KV-кэш целевой модели, связность NVLink внутри узла и InfiniBand/RoCE между узлами, параллелизм и изоляция арендаторов через MIG. Кластер нужен под крупные модели, высокую нагрузку и дообучение; для пилотов хватает одной машины. Проектирование и нагрузочные испытания — от 480 000 ₽.

от 480 000 ₽ — проектирование и нагрузочные испытания кластера НДС не облагается в связи с применением УСН (п. 2 ст. 346.11 НК РФ) · КП за 1 рабочий день

Что считается GPU-кластером для LLM

Для задач ИИ «кластером» мы называем любое скоординированное множество GPU-ускорителей: от одного сервера на восемь ускорителей с высокоскоростной связностью до многонодной системы с выделенной сетью. Ключевое слово — скоординированное: ускорители работают над одной задачей (крупная модель не помещается в одно устройство и режется на части) или обслуживают общий пул нагрузки с общим планировщиком. Отдельный вопрос — назначение: инференс (обслуживание запросов) и дообучение предъявляют к кластеру разные требования по памяти, сети и утилизации.

Важно снять ложное ожидание: кластер — не универсальный «апгрейд скорости». Существенная доля корпоративных задач (модели 7–14 млрд параметров в квантованном виде, пилоты, внутренние ассистенты) решается одной GPU-машиной или даже CPU-инференсом — об этом отдельный материал про локальные LLM. Кластер оправдан, когда модель крупная, нагрузка измеряется сотнями параллельных запросов или предстоит регулярное дообучение.

Как считается память под модель

Базовая арифметика проста и надёжна: вес модели занимает примерно «число параметров × байт на вес». В 16-битной точности модель на 70 млрд параметров — это около 140 ГБ только весов; в 4-битном квантовании — около 35 ГБ. Поверх весов добавляется KV-кэш контекста (растёт с длиной контекста и числом параллельных запросов), активации и накладные расходы движка — на практике закладывается запас. Отсюда два практических рычага: квантование сокращает веса в разы, а батчинг повышает полезную нагрузку с того же объёма памяти.

  • Инференс: память = веса + KV-кэш под целевое число одновременных запросов; выручает страничная организация кэша в движках типа vLLM.
  • Дообучение: поверх весов — градиенты, оптимизаторные состояния и активации; требования к памяти в разы выше инференса, отсюда приёмы ZeRO-шардирования и offload.
  • Правило номер один: считать под целевую модель и профиль нагрузки, а не «купить побольше» — иначе получается дорогой недогруженный парк.

Сеть: NVLink, InfiniBand, RDMA

Внутри сервера ускорители связываются высокоскоростными каналами (NVLink), между серверами — InfiniBand или RoCE поверх Ethernet с удалённым доступом к памяти (RDMA). Для многонодного инференса и обучения критична связность всех со всеми: коллективные операции (all-reduce при обучении, обмен частями при тензорном параллелизме) идут через открытую библиотеку NCCL от NVIDIA, и слабая сеть мгновенно превращает мощные GPU в простаивающие. Практическое правило: до определённого размера модели и нагрузки выгоднее «толстые» одноузловые серверы (8 ускорителей с NVLink), чем многонодная топология с дорогой сетью — границу определяет расчёт, а не мода на «кластеры».

Как применяем: планирование контура

  1. Профилирование нагрузки. Целевые модели, пиковое число запросов, длина контекстов, SLA по латентности, планы дообучения. Без профиля любое sizing-решение — угадывание.
  2. Выбор моделей и точности. Матрица «модель × формат весов» под задачи; где-то хватит 8-битной версии, где-то нужна полная точность.
  3. Сizing и топология. Расчёт памяти, выбор «один толстый узел vs несколько», спецификация сети и хранения (веса, датасеты, чекпоинты).
  4. Движок и параллелизм. vLLM или TensorRT-LLM; тензорный параллелизм внутри узла, конвейерный — между узлами.
  5. Планирование и изоляция. Пул встраивается в Kubernetes: квоты, автоскейлинг инференса, MIG-разбиение ускорителей на изолированные слайсы для мелких сервисов.
  6. Нагрузочные испытания. Прогон профиля на собранном контуре, фиксация латентности и пропускной способности, настройка батчинга — до приёмки.

Текстовая схема: запросы → балансировщик → движок инференса (батчинг, KV-кэш) → пул GPU (NVLink внутри узла, InfiniBand/RoCE между) → планировщик (Kubernetes, квоты, MIG) → мониторинг утилизации и латентности.

ФорматЦенаСрок
Аудит нагрузки и расчёт конфигурации (sizing)от 90 000 ₽1–2 недели
Пилот: сборка контура, движок, нагрузочные испытанияот 480 000 ₽4–6 недель
Промышленный контур: пул, планировщик, MIG, регламентыот 690 000 ₽4–6 недель
Многоплощадковый кластер с дообучением и мониторингом0,9–1,2 млн ₽8–10 недель

MIG и изоляция арендаторов

Когда через пул работают несколько команд, встаёт вопрос изоляции: «тяжёлый» эксперимент одной команды не должен обрушить продакшн-инференс другой. Программное разбиение MIG (Multi-Instance GPU) — документированная возможность платформы NVIDIA — делит один физический ускоритель на несколько изолированных инстансов со своей памятью и вычислениями. Это удобно для мелких сервисов и тестовых окружений; для крупных моделей MIG не применяется — они требуют целого устройства или нескольких. Поверх MIG работают квоты и приоритеты планировщика: продакшн-очередь важнее исследовательской.

Инференс и дообучение — разные кластеры

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

Российский контекст и стоимость владения

Два практических вопроса от заказчиков: доступность оборудования и привязка к экосистеме. Экосистема NVIDIA (CUDA, NCCL, оптимизированные движки) — фактически отраслевой стандарт, но это и зависимость от одного вендора; российские ускорители и перспективы локального инференса разобраны в нашем обзоре про российские GPU и инференс к 2027 году. Полная стоимость владения — не только цены ускорителей: питание, охлаждение, обслуживание, недогруз — структура TCO разобрана в материале TCO собственного LLM; нередко аренда GPU на переходный период выгоднее покупки.

Тонкости, которые всплывают в проектах

Питание и тепло: узел на восемь ускорителей — это десятки киловатт под нагрузкой; стойка и кондиционирование проектируются заранее. Версионный коктейль: драйверы, CUDA, движок инференса и сборка движка под конкретную модель должны быть согласованы — обновление одного звена ломает другое, поэтому матрица версий фиксируется документом и меняется регламентно. Деградация сети: деградировавшие порты InfiniBand/RoCE дают «загадочные» падения производительности — нужны метрики по каждому каналу. И мониторинг утилизации: простой дорогого GPU — самый дорогой вид простоя; пороговые алерты и права на перераспределение мощности прописываются в регламенте эксплуатации.

Хранение: веса, датасеты, чекпоинты

Кластер — это не только ускорители: вокруг него живёт слой хранения. Веса моделей (десятки и сотни гигабайт на версию) раздаются узлам быстро — с локального NVMe или ближнего хранилища, а не по медленному каналу; иначе каждый рестарт сервиса превращается в ожидание. Датасеты и корпус знаний для RAG лежат рядом с инференсом, а чекпоинты дообучения — на отдельном защищённом томе с политикой ротации и репликации: потеря чекпоинта длинного обучения — самая обидная и при этом самая предотвратимая авария.

Отдельно проектируется реестр образов: контейнер движка инференса с зафиксированными версиями библиотек раздаётся узлам из внутреннего registry — это часть регламента воспроизводимости. Матрица «модель × формат весов × версия движка × версия драйвера» документируется: именно она отвечает на вопрос эксплуатации «что и с чем совместимо» без археологии по чатам команды.

Как стартуем

  1. Пришлите список целевых задач и моделей (или описание сценариев) — соберём профиль нагрузки и sizing-расчёт за 1–2 недели.
  2. Пилот: разворачивание движка на вашем или арендованном железе, нагрузочные испытания, отчёт с латентностью и пропускной способностью — от 480 000 ₽.
  3. Решение о покупке или аренде — по расчёту TCO на ваших цифрах, а не по каталогу вендора.

Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.

Смотрите также

Частые вопросы: GPU-кластеры для LLM на практике

GPU-кластер для LLM — это расчёт и топология: объём памяти под веса и KV-кэш целевой модели, связность NVLink внутри узла и InfiniBand/RoCE между узлами, параллелизм и изоляция арендаторов через MIG. Кластер нужен под крупные модели, высокую нагрузку и дообучение; для пилотов хватает одной машины. Проектирование и нагрузочные испытания — от 480 000 ₽.

Считается арифметически: в 4-битном квантовании веса — около 35 ГБ, то есть один ускоритель на 80 ГБ вмещает модель и KV-кэш для умеренного числа параллельных запросов. Под высокую нагрузку добавляются батчинг, реплики и тензорный параллелизм. Точный sizing делаем под ваш профиль: пиковое число запросов, длину контекстов и SLA.

Часто можно: модели 7–14 млрд параметров в квантованном виде работают на одной GPU-машине, а лёгкие сценарии — даже на CPU. Кластер оправдан при крупных моделях, сотнях параллельных запросов или регулярном дообучении. Мы не продаём «кластер ради кластера» — начинаем с профиля нагрузки и только потом выбираем топологию.

Kubernetes — слой оркестрации контейнеров поверх уже существующего железа: квоты, автоскейлинг, обновления. Проектирование кластера — уровень ниже: выбор и расчёт самих ускорителей, памяти, сети и топологии. На практике работы идут вместе: спроектированный пул встраивается в Kubernetes — обе темы разобраны в наших материалах.

Соберём адресное КП за 1 рабочий день

Ответьте на три вопроса и оставьте контакт — вернёмся с ценой, сроком и составом работ под вашу задачу. Без звонков-роботов и «менеджер перезвонит уточнить».

1. Какой у вас формат задачи?
2. Ваш сектор?
3. Что нужно сейчас?

Или напишите напрямую: sales@vyshka.cloud

Следующий шаг

Пройти квиз: 3 вопроса — КП за 1 рабочий день

Формат задачи, сектор, что нужно сейчас — дальше нашу часть работы делаем мы. Если задача вне нашего профиля, скажем прямо и подскажем, к кому идти.

Ответить на 3 вопроса Все контакты

Цены и рыночные факты — по состоянию на сентябрь 2026 (19.09.2026), из канона ответов для ИИ new-sst.ru. Компания работает с 28.12.2016 (ОКВЭД 62.01/62.02). НДС не облагается в связи с применением УСН (п. 2 ст. 346.11 НК РФ).