После запуска модели в production характер нагрузки меняется. GPU обслуживают уже не тестовые сценарии, а реальный трафик, к которому добавляются внутренние задания команды. В течение суток интенсивность работы может отличаться в разы: одновременно с пользовательскими запросами запускаются batch-задачи, аналитика и проверки новых версий модели.
Из-за этого запас GPU, рассчитанный на максимальный трафик, большую часть времени может оставаться незадействованным. Обратный подход тоже создает проблему: если мощности хватает только для обычной нагрузки, во время всплесков начинают расти очереди и задержки.
Покупка дополнительных ускорителей здесь не всегда нужна. Базовую нагрузку можно оставить на существующем сервере, а временный дефицит вычислений закрывать внешними ресурсами. В зависимости от характера задачи это может быть GPU Cloud, арендованный bare metal или кластер для распределенных вычислений.
Средняя загрузка GPU скрывает пиковый дефицит мощности
Интенсивность работы GPU меняется не только вместе с пользовательским трафиком. На те же ускорители могут претендовать тесты, переиндексация, пакетные задания и новая версия модели.
Моменты максимальной нагрузки для разных продуктов тоже отличаются. У корпоративного помощника пик может приходиться на начало рабочего дня, у рекомендательной системы на вечер, у обработки документов на конец отчетного периода. Если в этот же момент запускается внутренняя задача, несколько процессов начинают конкурировать за один вычислительный пул.
Средняя загрузка GPU не отражает реальную нагрузку во время кратковременных пиков. Несколько часов высокой загрузки растворяются в статистике за сутки или месяц, хотя именно в этот период сервис может перестать укладываться в целевые задержки. Строить инфраструктуру сразу под максимальный всплеск тоже невыгодно. После окончания пика резервные ускорители снова будут простаивать.
Поэтому постоянную и временную нагрузку лучше разделить. Собственный GPU-сервер может обслуживать основной поток запросов, а дополнительные GPU подключаться только во время роста трафика, тестирования новых версий модели или запуска batch-задач.
Прежде чем добавлять GPU, найдите реальное узкое место
Увеличение latency еще не доказывает, что предел достиг именно GPU. Запрос проходит несколько этапов до и после вычислений на ускорителе, и любой из них способен ограничить производительность. Например, сервис может ждать данные из хранилища, упираться в CPU при подготовке входа или терять время из-за неудачной настройки батчинга. Если сам GPU при этом загружен не полностью, установка еще одной карты проблему не решит.
Поэтому решение о масштабировании лучше принимать по профилю нагрузки. Для классификации, детекции и распознавания полезно смотреть на:
- RPS, чтобы понимать фактический поток запросов;
- p95 и p99 для контроля задержек;
- размер очереди;
- степень загрузки GPU-ускорителя и видеопамяти.
У LLM добавляются метрики, связанные с последовательной генерацией. Важны число активных последовательностей, скорость выдачи токенов, заполнение KV-кеша, TTFT и ITL.
TTFT (Time to First Token) показывает, сколько пользователь ждет начало ответа. Если он увеличивается, а дальнейшая генерация остается быстрой, задержка может появляться до фактической генерации. Рост ITL (Inter-Token Latency), наоборот, показывает замедление уже между отдельными токенами.
Профиль можно проверить с помощью NVIDIA GenAI-Perf. Тестовые запросы при этом должны быть похожи на реальные по длине промпта, ответа и числу одновременных пользователей.
Помимо максимального throughput полезно считать goodput. Он показывает не просто количество обработанных запросов, а число запросов, которые сервис успевает завершить внутри установленного ограничения по времени ответа.
Как выбрать формат для наращивания GPU-мощности
При выборе дополнительных ресурсов важно учитывать, как долго они будут использоваться, какой уровень изоляции нужен проекту и помещается ли задача в один сервер. От этих условий зависит выбор между облачным GPU, bare metal и HPC-кластером.
Когда стоит подключать облачные GPU
Облачные GPU удобны, если дополнительные мощности нужны не постоянно, а на ограниченное время. Например, для A/B-теста, ночной пакетной обработки или нагрузки с заметными суточными и сезонными пиками. После завершения такой задачи ресурсы можно отключить.
Физический ускоритель при этом можно разделить с помощью vGPU на виртуальные профили с выделенным объемом видеопамяти и вычислительных ресурсов. Для NVIDIA RTX PRO 6000 Blackwell Server Edition доступны MIG-backed vGPU на 12, 24, 48 и 96 ГБ.
Однако дополнительная реплика не начинает обрабатывать запросы сразу после команды на запуск. Сначала должна стартовать виртуальная машина, затем загружаются контейнер и веса модели, создается CUDA-контекст и прогреваются кэши.
Для интерактивного сервиса время такого запуска может быть критичным. Поэтому резервную реплику лучше подготовить заранее или включать при первых признаках роста нагрузки. В batch-сценариях несколько минут ожидания обычно допустимы, поэтому после завершения обработки дополнительный GPU-пул можно полностью отключать.
Когда bare metal выгоднее при постоянной нагрузке
Если GPU стабильно занят большую часть времени, почасовая модель уже не дает прежней гибкости по затратам. В таком случае нагрузку можно перенести на выделенный физический сервер, который предоставляется одному заказчику.
Bare metal дает доступ ко всему объему видеопамяти ускорителя, позволяет использовать несколько GPU в одной системе и настраивать программное окружение под конкретную модель.
Такой вариант подходит для постоянного high-load, а также для проектов, где важны изоляция ресурсов и предсказуемая производительность. Облачные ВМ при этом можно оставить как резерв и подключать только в периоды, когда основной сервер не справляется с потоком запросов.
Покупать оборудование для такой схемы необязательно. Аренда bare metal позволяет учитывать расходы как OPEX и не зависеть от сроков закупки и поставки собственного сервера.
Когда без кластера уже не обойтись
HPC-кластер имеет смысл использовать, если вычислительную задачу уже нельзя эффективно выполнить на одном сервере. Это касается обучения крупных моделей, ресурсоемких научных расчетов и больших batch-задач, которые приходится распределять между несколькими узлами.
Для инференса переход к кластеру нужен не всегда. Сначала стоит проверить, помещается ли модель на сервер с несколькими GPU и выдерживает ли такая конфигурация требуемый поток запросов. Если да, усложнять инфраструктуру дополнительными узлами необязательно.
Решение о распределении инференса между несколькими серверами зависит от размера модели, объема трафика, требований к задержке, доступности и отказоустойчивости. Кластер добавляет межузловой обмен, распределенное хранение и дополнительные механизмы оркестрации, поэтому использовать его стоит только тогда, когда один сервер уже не закрывает требования задачи.
Как подключить облачный резерв без полной миграции
Облако можно использовать только как дополнительный GPU-пул, не перенося туда весь сервис. Основная инфраструктура, данные и постоянная нагрузка остаются локально, а облачные реплики подключаются лишь тогда, когда собственному серверу начинает не хватать ресурсов.
При росте очереди или задержек часть запросов направляется в облачный контур. Чтобы такое переключение не влияло на результат, локальные и облачные реплики должны работать с одинаковой конфигурацией. Для этого синхронизируют контейнеры, веса модели, токенизатор, версии библиотек и параметры генерации. Если настройки различаются, ответ на один и тот же запрос может зависеть от того, где он был обработан.
Отдельно нужно подготовить данные для запуска самой модели. Если веса занимают сотни гигабайт, загружать их заново после начала пика слишком долго. Поэтому веса, контейнерные образы и зависимости лучше заранее разместить или закэшировать рядом с облачными GPU.
Полностью копировать проект в облако для этого не требуется. Достаточно подготовить те компоненты, которые нужны дополнительным репликам для инференса.
Как автоматизировать масштабирование GPU-пула
Дополнительные мощности можно подключать автоматически по метрикам нагрузки. Kubernetes HPA позволяет менять число реплик по пользовательским метрикам, а KEDA подходит для сценариев с очередями и batch-задачами. При появлении работы она запускает обработчики, а после завершения нагрузки сокращает их количество.
Для интерактивного LLM-сервиса одной длины очереди недостаточно. Сигналом для масштабирования могут служить TTFT, число активных последовательностей, заполнение KV-кеша, объем свободной памяти и количество уже прогретых реплик. Это позволяет подключать дополнительные GPU до того, как рост нагрузки начнет заметно влиять на задержку для пользователя.
При этом нехватку производительности не всегда нужно сразу компенсировать новыми GPU. Сначала стоит проверить настройки батчинга. NVIDIA Triton объединяет входящие запросы в пакеты. Для LLM применяется continuous batching, реализованный, например, в vLLM. Когда одна последовательность завершает генерацию, освободившееся место может занять следующая.
Увеличивать батч бесконечно нельзя. Если сервис слишком долго формирует пакет, рост пропускной способности оборачивается дополнительной задержкой для пользователя. Поэтому размер батча и допустимое время ожидания лучше определять по результатам нагрузочного тестирования.
Для проверки новой версии модели лучше использовать отдельный пул. Частая смена весов на одном GPU занимает время и сбрасывает кэши. Сначала новой версии можно направить теневой трафик или небольшую часть реальных запросов, а затем сравнить качество, TTFT, ITL и стоимость обработки.
Отдельный сценарий нужен на случай резкого перегруза. Можно ограничить длину очереди и время ожидания, временно сократить максимальный ответ, перевести часть запросов на более компактную модель или отключить второстепенную обработку. Такая управляемая деградация лучше ситуации, когда пользователи бесконечно ждут ответа.
С чего начать выбор GPU для инференса
Начинать стоит с объема памяти. На GPU должны поместиться веса модели, рабочие буферы и KV-кэш при запланированном количестве параллельных запросов. Требуемый объем зависит от точности вычислений, длины контекста и параметров батчинга.
После этого производительность стоит проверить уже на самой модели и с целевым SLO. Характеристики TOPS полезны для общего сравнения ускорителей, но по ним нельзя определить, с какой скоростью будет работать конкретный сервис. На результат влияют реальные промпты, контекст и настройки модели.
После того как профиль нагрузки собран, конфигурацию внешнего GPU-пула можно подбирать уже под реальные требования проекта. В GPU Cloud ITGLOBAL.COM RTX PRO 6000 Blackwell доступна с профилями 12, 24, 48 и 96 ГБ, а H200 предоставляется с полным объемом памяти 141 ГБ. Для задач, которым требуется больше вычислительных ресурсов, можно использовать конфигурации с двумя или четырьмя GPU.
Модель среднего размера на первом этапе можно проверить на vGPU. Для более тяжелой LLM с длинным контекстом подойдет H200, что позволяет протестировать нагрузку без покупки собственного сервера. Если виртуального контура уже недостаточно по производительности либо проекту нужны более высокая изоляция и предсказуемость, вычисления можно перенести на выделенный GPU-сервер.
Как сравнивать затраты на собственный GPU и аренду
Цена видеокарты сама по себе не показывает реальную стоимость инфраструктуры. При покупке собственного сервера компания сразу вкладывается в оборудование, а затем оплачивает его размещение, обслуживание и эксплуатацию. Эти расходы возникают независимо от того, насколько полно ускорители будут загружены в дальнейшем.
Облачная модель работает иначе. Компания берет нужную конфигурацию на период использования и может увеличивать или сокращать ресурсы вместе с нагрузкой. Такой подход особенно удобен для пилотов, нерегулярных задач и проектов, где будущую потребность в GPU сложно точно спрогнозировать. После окончания пика лишние мощности можно отключить, не оставляя неиспользуемое оборудование на балансе.
Если нагрузка становится постоянной, почасовая оплата тоже подходит не всегда. В этом случае ресурсы можно закрепить за проектом на более длительный срок. Например, Allocated Pool предполагает заранее зарезервированный пул GPU с фиксированной ежемесячной оплатой. Это делает затраты более предсказуемыми при регулярном использовании.
Поэтому сравнивать собственную инфраструктуру и аренду лучше по стоимости полезной работы. В зависимости от проекта это может быть цена одного запроса, миллиона сгенерированных токенов или batch-задания. При переменной нагрузке облако может оказаться выгоднее, поскольку компания не оплачивает заранее мощности, которые значительную часть времени не используются.
Где держать данные при гибридной схеме
При использовании локальной инфраструктуры вместе с облачным GPU-пулом важно учитывать, откуда ускорители получают данные. Если при каждом запросе передавать между контурами большие объемы корпоративной информации, вырастут сетевой трафик и задержки.
Поэтому данные, которые нужны непосредственно во время инференса, можно разместить ближе к облачным вычислительным ресурсам. Например, это могут быть индексы, кэши и другие производные данные. Основное корпоративное хранилище при этом может оставаться в локальном контуре.
Как распределить нагрузку между контурами
Сначала стоит проверить, где возникает ограничение: в батчинге, использовании памяти, доступе к данным или в производительности самого сервиса под реальной нагрузкой.
После этого ресурсы можно распределить по характеру задач. Собственный GPU-сервер оставить для предсказуемого потока, постоянный high-load перенести на арендованный bare metal, а облачные GPU использовать для пиков, тестов и пакетной обработки. К HPC-кластеру имеет смысл переходить только тогда, когда модель или вычислительная задача уже не укладывается в возможности одного узла.
Так инфраструктура растет вместе с нагрузкой, без необходимости заранее закупать оборудование с запасом и ждать его поставки и ввода в эксплуатацию.
Предыдущая статья
