Развернуть vLLM на 8 GPU с Tensor Parallelism и замерить throughput
ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Развернуть vLLM на 8 GPU с Tensor Parallelism и замерить throughput
1. Цель задачи
Освоить развёртывание LLM inference-сервера vLLM на нескольких GPU с использованием tensor parallelism. На практике измерить throughput (токенов/сек) при serving модели на 1 и 8 GPU, количественно убедиться в ускорении (ожидается ≥2x). Приобрести навыки конфигурирования параметров параллелизации, нагрузочного тестирования и интерпретации метрик производительности.
Ключевой результат Воспроизводимый бенчмарк, демонстрирующий ускорение throughput не менее чем в 2 раза при переходе с 1 GPU на 8 GPU (tensor‑parallel‑size=8) для выбранной LLM.
2. Исходные данные
Перед началом необходимо иметь:
| Что нужно | Откуда взять |
|---|---|
| Машина с 8 совместимыми GPU (NVIDIA, не менее 16 GB VRAM каждая, CUDA 11.8+) | Облачный инстанс (AWS p4d.24xlarge, GCP a2-megagpu-8gpu) или on-prem кластер |
| Выбранная LLM (например, LLaMA-3-8B или Mistral-7B) в HuggingFace формате | HuggingFace Hub (huggingface.co/meta-llama) |
| Установленный Python 3.9+, pip, git, NVIDIA драйверы, CUDA toolkit | Стандартная настройка окружения |
| vLLM (v0.4.0 или новее) | pip install vllm |
| Нагрузочный инструмент | Встроенный в vLLM benchmarks/benchmark_throughput.py или vllm serve + curl |
Если нет реального доступа к 8 GPU — симулируем ограниченно:
- Использовать облачную инстанцию с минимальными требованиями (например, 4 × T4 → TP=4), ускорение будет меньше.
- Либо выполнить только на 1 GPU, без требования 2x (но признак успеха формально не будет достигнут).
- Допускается уменьшение модели до 1B параметров, чтобы поместиться в доступную память.
3. Технологический стек
| Компонент | Инструменты | Назначение |
|---|---|---|
| Модель | LLaMA-3-8B / Mistral-7B | Тестовая LLM |
| Inference-сервер | vLLM | Serving с tensor parallelism |
| Параллелизация | --tensor-parallel-size 8 | Разделение весов между 8 GPU |
| Бенчмаркинг | benchmark_throughput.py + vllm serve | Нагрузочное тестирование |
| Мониторинг | nvidia-smi, vllm metrics (опционально Prometheus) | Использование GPU, память |
| Python | 3.9+ | Обработка результатов, склейка данных |
| OS | Linux (Ubuntu 20.04+) | Целевая платформа |
4. Этапы выполнения
Этап 1: Подготовка окружения и baseline на 1 GPU (оценка: 1–1.5 часа)
Действия
-
Проверить доступность GPU
- Выполнить
nvidia-smi— убедиться, что все 8 GPU видны, нет ошибок ECC, достаточно памяти. - Определить модель GPU (например, A100-80GB).
- Выполнить
-
Создать виртуальное окружение и установить vLLM:
python -m venv vllm_env source vllm_env/bin/activate pip install vllm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 -
Загрузить модель с HuggingFace
- Использовать
huggingface-cli download meta-llama/Llama-3.2-8B(требуется токен). - Сохранить путь к локальной папке
$MODEL_PATH.
- Использовать
-
Отключить все GPU, кроме одной, для baseline:
export CUDA_VISIBLE_DEVICES=0 -
Запустить vLLM сервер на 1 GPU (без tensor parallelism):
python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --tensor-parallel-size 1 \ --port 8000 & -
Прогреть сервер (5–10 запросов) и провести замер throughput с помощью встроенного бенчмарка:
git clone https://github.com/vllm-project/vllm.git cd vllm/benchmarks python benchmark_throughput.py \ --backend vllm \ --model $MODEL_PATH \ --num-prompts 100 \ --input-len 512 \ --output-len 256 \ --request-rate 10 \ --port 8000Сохранить вывод в файл
baseline_1gpu.log. -
Остановить сервер (
kill %1).
Ожидаемый результат этапа Получены метрики throughput (token/s) для конфигурации с 1 GPU. Сервер стабильно отвечает, nvidia-smi показывает ~90–100% utilisation.
Этап 2: Развёртывание на 8 GPU с tensor parallelism (оценка: 1 час)
Действия
-
Убрать ограничение CUDA_VISIBLE_DEVICES
unset CUDA_VISIBLE_DEVICES -
Запустить vLLM с tensor-parallel-size=8
python -m vllm.entrypoints.openai.api_server \ --model $MODEL_PATH \ --tensor-parallel-size 8 \ --port 8001 &Дождаться сообщения "Uvicorn running on http://0.0.0.0:8001".
-
Проверить, что все GPU задействованы:
nvidia-smi— 8 процессов vLLM используют память равномерно.
-
Выполнить аналогичный бенчмарк (с теми же параметрами):
cd vllm/benchmarks python benchmark_throughput.py \ --backend vllm \ --model $MODEL_PATH \ --num-prompts 100 \ --input-len 512 \ --output-len 256 \ --request-rate 10 \ --port 8001Сохранить вывод в
tp8_8gpu.log.
Ожидаемый результат этапа Успешный ответ на запросы, все GPU загружены, throughput зафиксирован.
Этап 3: Дополнительные замеры (вариации) (оценка: 30 минут)
Действия
- Повторить замер при других
--request-rate(например, 1, 5, 20) для оценки насыщения. - Изменить
--input-len/--output-len(например, 1024/512) — проверить влияние длины последовательности. - Если позволяет время — запустить
benchmark_serving.py** (есть в репозитории vLLM) для имитации реальной нагрузки с Poisson arrival.
Ожидаемый результат этапа Массив данных для построения графика scaling (throughput vs number of GPUs / batch size).
Этап 4: Анализ и сравнение результатов (оценка: 45 минут)
Действия
-
Извлечь из логов ключевые метрики
- Total generated tokens
- Total time (s)
- Throughput (tokens/s)
- Latency per request (p50, p99)
-
Вычислить ускорение
speedup = throughput_tp8 / throughput_tp1 -
Построить таблицу и график (matplotlib / pandas):
Конфигурация GPU Throughput (tok/s) Ускорение TP=1 1 X 1x TP=8 8 Y Y / X -
Проверить, достигнуто ли условие
speedup >= 2.0.
Если нет — объяснить возможные причины (узкое место в коммуникации, маленький batch, модель недостаточно большая).
Ожидаемый результат этапа Численное подтверждение (или опровержение) гипотезы, отчёт с графиками.
Этап 5: Документирование и выводы (оценка: 30 минут)
Действия
- Написать summary в файл
report.mdс включением:- Команды запуска и версии ПО
- Таблицы метрик
- График scaling
- Выводы: выполнено ли требование 2x, при каких условиях
- Упаковать логи в архив
benchmark_data.zip.
Ожидаемый результат этапа Готовый к публикации отчёт.
5. Критерии приемки (Definition of Done)
- Установлена vLLM версии ≥0.4.0.
- Сервер запускается с
--tensor-parallel-size 8без ошибок. - Baseline на 1 GPU получен и зафиксирован.
- Throughput для 8 GPU измерен минимум в 3 прогонах (среднее).
- Вычислено ускорение относительно 1 GPU.
- Ускорение ≥2.0 (целевое значение).
- Отчёт
report.mdсодержит таблицу, график и интерпретацию. - Все данные и скрипты приложены к репозиторию или архиву.
6. Ожидаемый результат
Основной артефакт
Файл report.md (или отчёт в GitHub Gist/Jupyter Notebook) со следующей структурой:
- Цель, окружение, версия модели.
- Команды запуска и конфигурация.
- Результаты замеров (таблица throughput, latency).
- График “Throughput vs Number of GPUs” (2 точки: 1 и 8, можно добавить 2 и 4 при наличии).
- Вывод о соответствии целевого ускорения.
Дополнительные артефакты
- Лог-файлы
baseline_1gpu.log,tp8_8gpu.log. - Скрипт
run_benchmark.sh(автоматизация запуска). - Исходный код для построения графика (Python-ноутбук).
7. Возможные сложности и их решение
| Сложность | Решение |
|---|---|
| Нет доступа к 8 GPU | Использовать облачный инстанс (AWS p4d, GCP a2-highgpu-8gpu) с почасовой оплатой. Уменьшить модель до 1–3B, чтобы поместилась в память на меньшем числе GPU (тогда ускорение будет ниже). |
| OOM (переполнение памяти) | Уменьшить max-model-len, max-num-seqs, использовать --gpu-memory-utilization 0.85. Переключиться на модель меньшего размера (Mistral-7B, LLaMA-2-7B). |
| Проблемы с CUDA версией | Установить совместимые пакеты (PyTorch 2.0+ с CUDA 11.8/12.1). Использовать Docker-образ vllm/vllm-openai:latest. |
| Медленная межсоединительная шина (NVLINK vs PCIe) | Ускорение будет менее 2x. В отчёте указать фактическое значение и объяснить влиянием коммуникации. Запустить профилирование с NCCL_DEBUG=INFO. |
| Нестабильный throughput при малом числе запросов | Увеличить число промптов до 500, добавить прогрев в 20 запросов. |
| Сервер не отвечает после запуска с TP=8 | Проверить CUDA_VISIBLE_DEVICES (должны быть все 8), логи vLLM. Убедиться, что модель успешно загрузилась (не превышен лимит VRAM). |
8. Бюджет времени (оценка)
| Этап | Время |
|---|---|
| 1. Подготовка и baseline на 1 GPU | 1 ч. 30 мин. |
| 2. Развёртывание на 8 GPU + замер | 1 ч. 00 мин. |
| 3. Дополнительные замеры (вариации) | 0 ч. 45 мин. |
| 4. Анализ и сравнение | 0 ч. 45 мин. |
| 5. Документирование | 0 ч. 30 мин. |
| Итого | 4 ч. 30 мин |
Примечание Если выполняется впервые, заложите дополнительный час на установку драйверов и решение проблем совместимости.
9. Связанные вопросы из базы знаний
| Вопрос | Тема |
|---|---|
| 55 | Tensor parallelism: разделение весов по GPU |
| 123 | vLLM: установка и конфигурация |
| 231 | Управление GPU памятью при serving |
| 342 | Метрики throughput и latency |
| 450 | Оптимизация inference (batch size, kv-cache) |
| 567 | CUDA и NCCL коммуникационные паттерны |
| 678 | Инструменты бенчмаркинга для LLM |
| 789 | Multi-GPU развёртывание (single-node) |
| 890 | Scaling law: ускорение vs число GPU |
| 900 | vLLM metrics (Prometheus, мониторинг) |
10. Чек-лист самопроверки
- Я проверил, что доступно не менее 8 GPU с суммарной памятью > 2× веса модели.
- Я записал точную версию vLLM, PyTorch и модели.
- Я выставил
--tensor-parallel-size 8и--gpu-memory-utilization 0.9. - Я прогнал baseline на 1 GPU с теми же параметрами запросов (длина in/out, request rate).
- Я сделал минимум 3 прогона для каждой конфигурации и взял среднее.
- Я построил график скорости приёма токенов и сравнил с ожидаемым 2x.
- Я зафиксировал команды и вывод в отчёт, приложил скрипты.
- Если ускорение ниже 2x, я указал возможные причины (узкое место, малая модель, PCIe).