English translation is not available yet. Showing Russian content.

Развернуть 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 — симулируем ограниченно:

  1. Использовать облачную инстанцию с минимальными требованиями (например, 4 × T4 → TP=4), ускорение будет меньше.
  2. Либо выполнить только на 1 GPU, без требования 2x (но признак успеха формально не будет достигнут).
  3. Допускается уменьшение модели до 1B параметров, чтобы поместиться в доступную память.

3. Технологический стек

КомпонентИнструментыНазначение
МодельLLaMA-3-8B / Mistral-7BТестовая LLM
Inference-серверvLLMServing с tensor parallelism
Параллелизация--tensor-parallel-size 8Разделение весов между 8 GPU
Бенчмаркингbenchmark_throughput.py + vllm serveНагрузочное тестирование
Мониторингnvidia-smi, vllm metrics (опционально Prometheus)Использование GPU, память
Python3.9+Обработка результатов, склейка данных
OSLinux (Ubuntu 20.04+)Целевая платформа

4. Этапы выполнения

Этап 1: Подготовка окружения и baseline на 1 GPU (оценка: 1–1.5 часа)

Действия

  1. Проверить доступность GPU

    • Выполнить nvidia-smi — убедиться, что все 8 GPU видны, нет ошибок ECC, достаточно памяти.
    • Определить модель GPU (например, A100-80GB).
  2. Создать виртуальное окружение и установить 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
    
  3. Загрузить модель с HuggingFace

    • Использовать huggingface-cli download meta-llama/Llama-3.2-8B (требуется токен).
    • Сохранить путь к локальной папке $MODEL_PATH.
  4. Отключить все GPU, кроме одной, для baseline:

    export CUDA_VISIBLE_DEVICES=0
    
  5. Запустить vLLM сервер на 1 GPU (без tensor parallelism):

    python -m vllm.entrypoints.openai.api_server \
        --model $MODEL_PATH \
        --tensor-parallel-size 1 \
        --port 8000 &
    
  6. Прогреть сервер (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.

  7. Остановить сервер (kill %1).

Ожидаемый результат этапа Получены метрики throughput (token/s) для конфигурации с 1 GPU. Сервер стабильно отвечает, nvidia-smi показывает ~90–100% utilisation.

Этап 2: Развёртывание на 8 GPU с tensor parallelism (оценка: 1 час)

Действия

  1. Убрать ограничение CUDA_VISIBLE_DEVICES

    unset CUDA_VISIBLE_DEVICES
    
  2. Запустить 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".

  3. Проверить, что все GPU задействованы:

    • nvidia-smi — 8 процессов vLLM используют память равномерно.
  4. Выполнить аналогичный бенчмарк (с теми же параметрами):

    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 минут)

Действия

  1. Повторить замер при других --request-rate (например, 1, 5, 20) для оценки насыщения.
  2. Изменить --input-len / --output-len (например, 1024/512) — проверить влияние длины последовательности.
  3. Если позволяет время — запуститьbenchmark_serving.py** (есть в репозитории vLLM) для имитации реальной нагрузки с Poisson arrival.

Ожидаемый результат этапа Массив данных для построения графика scaling (throughput vs number of GPUs / batch size).

Этап 4: Анализ и сравнение результатов (оценка: 45 минут)

Действия

  1. Извлечь из логов ключевые метрики

  2. Вычислить ускорение

    speedup = throughput_tp8 / throughput_tp1
    
  3. Построить таблицу и график (matplotlib / pandas):

    КонфигурацияGPUThroughput (tok/s)Ускорение
    TP=11X1x
    TP=88YY / X
  4. Проверить, достигнуто ли условие speedup >= 2.0.
    Если нет — объяснить возможные причины (узкое место в коммуникации, маленький batch, модель недостаточно большая).

Ожидаемый результат этапа Численное подтверждение (или опровержение) гипотезы, отчёт с графиками.

Этап 5: Документирование и выводы (оценка: 30 минут)

Действия

  1. Написать summary в файл report.md с включением:
    • Команды запуска и версии ПО
    • Таблицы метрик
    • График scaling
    • Выводы: выполнено ли требование 2x, при каких условиях
  2. Упаковать логи в архив 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 GPU1 ч. 30 мин.
2. Развёртывание на 8 GPU + замер1 ч. 00 мин.
3. Дополнительные замеры (вариации)0 ч. 45 мин.
4. Анализ и сравнение0 ч. 45 мин.
5. Документирование0 ч. 30 мин.
Итого4 ч. 30 мин

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


9. Связанные вопросы из базы знаний

ВопросТема
55Tensor parallelism: разделение весов по GPU
123vLLM: установка и конфигурация
231Управление GPU памятью при serving
342Метрики throughput и latency
450Оптимизация inference (batch size, kv-cache)
567CUDA и NCCL коммуникационные паттерны
678Инструменты бенчмаркинга для LLM
789Multi-GPU развёртывание (single-node)
890Scaling law: ускорение vs число GPU
900vLLM 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).