Лучшие облачные GPU для обслуживания и развертывания больших языковых моделей
Обслуживание больших языковых моделей в производстве требует GPU с достаточным объёмом видеопамяти для хранения весов модели, высокой пропускной способностью памяти для генерации токенов и инфраструктуры, поддерживающей автоматическое масштабирование. Для оптимизации пропускной способности вывода LLM часто используются фреймворки, такие как vLLM, TGI и TensorRT-LLM. В этом руководстве перечислены облачные провайдеры GPU, хорошо подходящие для хостинга и обслуживания LLM в масштабах.
Пока не найдено подходящих провайдеров GPU для этого руководства. Проверьте позже.
Что на самом деле требует обслуживание LLM от арендуемого GPU
Обслуживание большой языковой модели — это принципиально иной тип нагрузки по сравнению с её обучением. Обучение ограничено пропускной способностью и терпимо к задержкам; обслуживание чувствительно к задержкам, ограничено памятью и имеет всплески нагрузки. Когда вы арендуете GPU для развертывания LLM через API, узким местом редко бывают сырые FLOPS. Главное — сколько модели и её KV-кэша вы можете разместить в VRAM, насколько быстро эта память работает и сколько одновременных запросов вы можете объединить в батч, прежде чем скорость токенов в секунду на пользователя резко упадёт.
KV-кэш — это часть, которую большинство недооценивает. Каждый активный запрос хранит ключи и значения внимания для своего контекста, и этот объём растёт с длиной последовательности и количеством одновременных пользователей. Модель, которая комфортно помещается в памяти в состоянии покоя, может исчерпать память, как только вы начнёте обрабатывать реальный трафик с длинными подсказками. Вот почему при развертывании обслуживания часто требуется больше VRAM, чем предполагают только веса модели.
Как подобрать размер GPU под модель
Практический первый вопрос — помещается ли модель на одном GPU или её нужно распределять на несколько. Сравнивая приведённые выше параметры с вашей моделью, учитывайте следующие факторы:
- Ёмкость VRAM определяет, какие модели можно разместить. Квантованная модель 7B–13B в FP8 или INT8 можно обслуживать на одном ускорителе среднего уровня, тогда как модель 70B в BF16 обычно требует карты с большой памятью или узла с несколькими GPU. Очень крупные модели класса frontier фактически требуют нескольких топовых GPU, связанных вместе.
- Пропускная способность памяти определяет скорость генерации токенов. Автогрессивное декодирование читает полный набор весов для каждого сгенерированного токена, поэтому память класса HBM (как на картах для дата-центров) генерирует токены значительно быстрее, чем потребительские карты с памятью GDDR при одинаковом размере модели. Для интерактивного чата пропускная способность часто важнее вычислительной мощности.
- Поддерживаемые точности определяют, насколько агрессивно можно уменьшить размер модели. Карты с поддержкой тензоров FP8 и INT8 позволяют обслуживать более крупные модели на меньшем объёме VRAM и с большей пропускной способностью, при условии совместимости стека обслуживания и схемы квантования модели.
- Интерконнект важен, когда модель распределена на несколько GPU. Тензорно-параллельное обслуживание обменивается активациями между GPU на каждом слое, поэтому NVLink-класса соединения внутри узла обеспечивают значительно лучшую задержку, чем конфигурации только с PCIe. Для развертываний на одном GPU интерконнект не имеет значения.
Обслуживание на одном GPU против нескольких GPU
Если ваша модель и её максимальный KV-кэш помещаются на одном GPU, оставьте её там. Обслуживание на одном GPU полностью избегает накладных расходов на межустройственную коммуникацию и проще в эксплуатации. Переходите к тензорно-параллельному обслуживанию или мультиузловому только если модель действительно не помещается, поскольку каждый дополнительный GPU добавляет затраты на синхронизацию и усложняет автоскейлинг. Если нужны несколько GPU, выбирайте инстансы из приведённого выше списка, которые сочетают карты с большой памятью и быстрый внутрикластерный интерконнект, а не объединяйте слабо связанные карты.
Особенности провайдера, важные для обслуживания, а не для обучения
Помимо кремния, операционная модель провайдера определяет, насколько жизнеспособно развертывание. При рассмотрении сравнения выше для нагрузки обслуживания, а не обучения, приоритеты меняются:
- Время холодного старта и настройки становятся первостепенными. Точка обслуживания, которая масштабируется до нуля между всплесками трафика, платит стоимость холодного старта при каждом масштабировании вверх, поэтому быстрая подготовка и кэширование образов напрямую влияют на задержки в хвосте распределения.
- Гранулярность биллинга меняет экономику всплесков трафика. Оплата посекундно или поминутно подходит для автоскейлинговых эндпоинтов, которые запускают и останавливают инстансы; грубая почасовая тарификация штрафует такую модель.
- Надёжность on-demand по сравнению со spot обычно предпочтительнее. Прерываемые или spot-инстансы отлично подходят для обучения и пакетных задач, но рискованны для пользовательских интерактивных эндпоинтов, где прерывание во время запроса приводит к потере живого трафика. Spot всё ещё хорошо подходит для неинтерактивного пакетного инференса.
- Постоянное хранилище и быстрая загрузка модели уменьшают боль при перезапуске. Многогигобайтные веса, которые загружаются из холодного объектного хранилища при каждом перезапуске, добавляют минуты простоя; кэшированные или подключённые тома сокращают это время.
- Сеть и исходящий трафик влияют на стоимость в масштабе. Высокопропускной инференс может генерировать большой объём исходящих данных; перед развертыванием с высоким трафиком проверьте условия исходящего трафика.
Пакетный режим против реального времени и где лежат затраты
Решите заранее, какой режим вы оптимизируете. Реальное интерактивное обслуживание ценит низкое время до первого токена и стабильную скорость токенов на пользователя, что требует памяти с высокой пропускной способностью и умеренных размеров батчей. Пакетный или офлайн инференс ценит общую пропускную способность и может упаковывать большие батчи на более дешёвом или прерываемом оборудовании, жертвуя задержкой на запрос ради лучшей стоимости за токен. Многие команды используют оба подхода: отзывчивый on-demand уровень для живых пользователей и пакетный уровень на spot-инстансах для массовой генерации.
По стоимости аренды обслуживание охватывает весь спектр. Небольшая квантованная модель на карте среднего уровня недорогая и широко доступная; frontier-модели на мульти-GPU узлах с большой памятью редки, дороже и иногда ограничены по ёмкости в периоды пикового спроса. Поскольку тарифы постоянно меняются и зависят от региона и обязательств, рассматривайте приведённое выше сравнение как источник истины, а не фиксированную цифру, и сравнивайте инстансы по VRAM, классу пропускной способности, интерконнекту и модели биллинга, а не только по цене.
Часто задаваемые вопросы
Сколько VRAM нужно для обслуживания LLM?
Рассчитывайте на вес модели в выбранной точности плюс значительный запас для KV-кэша, который растёт с длиной контекста и количеством одновременных пользователей. В качестве приблизительного ориентира, квантованные маленькие и средние модели обслуживаются на одной карте среднего уровня, тогда как крупные модели в более высокой точности требуют карты с большой памятью или нескольких GPU. Всегда рассчитывайте на пиковую одновременность, а не на простой режим.
Подходят ли spot или прерываемые GPU для обслуживания LLM?
Для пользовательских интерактивных эндпоинтов обычно нет, поскольку прерывание может привести к потере живых запросов и необходимости холодных перезапусков. Spot-инстансы хорошо подходят для офлайн или пакетного инференса, где прерывания лишь задерживают пропускную способность, а не разрывают интерактивную сессию. Многие команды держат on-demand ресурсы для живого трафика и используют spot для массовых задач.
Почему пропускная способность памяти важнее вычислительной мощности для обслуживания?
Декодирование токен за токеном читает веса модели из памяти для каждого сгенерированного токена, поэтому скорость генерации ограничена тем, насколько быстро GPU может читать память, а не его пиковыми FLOPS. Вот почему карты с памятью HBM для дата-центров генерируют токены быстрее, чем потребительские карты с той же моделью, и почему пропускная способность памяти — ключевой параметр для сравнения.
Стоит ли обслуживать на одном GPU или распределять на несколько?
Используйте один GPU, когда модель и её максимальный KV-кэш помещаются, так как это избегает межустройственной коммуникации и упрощает масштабирование. Переходите к мульти-GPU тензорно-параллельному обслуживанию только если модель действительно не помещается, и в этом случае выбирайте инстансы с картами большой памяти и быстрым внутрикластерным интерконнектом.