Как планировать GPU-мощности и автоскейлинг для LLMs?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Рассчитывайте общую мощность по измеренному throughput при требуемой латентности, затем проверяйте, что каждая реплика вмещает запланированное число активных последовательностей. Используйте реальные распределения длины промптов и ответов. Округляйте вверх до целых реплик сервинга, включая все GPU, необходимые для тензорного или конвейерного параллелизма.
Проверьте память перед throughput
При обычной организации кэша с полным аттеншном Llama 3.1 70B требует 1.25 GiB данных KV в FP16 для последовательности из 4,096 токенов. Поэтому гипотетический бюджет памяти KV в 40 GiB вмещает не более 32 таких последовательностей без учёта накладных расходов аллокатора и рантайма. При 131,072 токенах одна последовательность занимает все 40 GiB.
Считайте входные и сгенерированные токены вместе. Для архитектур вроде MLA и аттеншна со скользящим окном формула меняется, а выделение памяти на каждом устройстве зависит от шардирования. Это ограничение по памяти, а не прогноз размера батча, который удовлетворяет целям по латентности. Расчёт KV cache в руководстве содержит допущения и вычисления, которые можно выполнить.
Рассчитайте целое число реплик
Допустим, измерения показали, что реплика с двумя GPU стабильно выдаёт 1,200 выходных токенов в секунду при требуемых TTFT и TPOT на фиксированной нагрузке. Ожидаемый пиковый спрос составляет 4,000 выходных токенов в секунду. Гипотетический коэффициент запаса 1.3 даёт:
Пять реплик с двумя GPU требуют десяти GPU. Эти числа иллюстрируют расчёт; это не результаты аппаратных бенчмарков. Повторяйте измерения при изменении модели, распределения длины контекста, топологии или SLO. Коэффициент 1.3 означает throughput на 30% выше спроса до округления, а не 30% неиспользуемой мощности.
Масштабируйте до нарушения сроков ответа
Учитывайте длину очереди и время ожидания вместе с использованием KV, вытеснениями и goodput, который соответствует SLO. Загрузка GPU может оставаться высокой после того, как сервис уже перегружен. vLLM документирует эти метрики сервинга; определяйте пороги по результатам load tests.
Измерьте время скачивания образов, загрузки весов, инициализации модели и прогрева, прежде чем выбирать пороги автомасштабирования. Средства масштабирования деплоев KEDA могут уменьшать число экземпляров до нуля, но не устраняют латентность запуска модели. Держите готовые мощности, если запросы не могут ждать запуска.
Читайте о планировании мощностей и автомасштабировании в руководстве, чтобы узнать о связанных решениях по оборудованию и допуску запросов.