# vLLM на нескольких GPU: tensor, pipeline и data parallel Источник: https://modelium.tech/zhurnal/vllm-neskolko-gpu/ Для одной модели, которая не помещается на одном GPU, vLLM предлагает tensor parallelism: на машине с двумя совместимыми картами начните с `--tensor-parallel-size 2`. Pipeline parallelism делит слои, а data parallelism создаёт отдельные реплики для потока запросов — это разные задачи. Проверьте реальный ответ API, журнал и загрузку обеих карт; две карты сами по себе не гарантируют ускорения или достаточной памяти. **Проверено по документации 24 сентября 2026 года.** Ниже — воспроизводимый сценарий для владельца двух поддерживаемых GPU на Linux, а не отчёт о запуске Modelium. Версию runtime и версию скачанных весов запишите для собственного прогона. Запрос `vllm multi gpu` подтверждён подсказками Google, но частотность не измерена. ## Когда нужны два GPU, а когда достаточно одного? Если модель с нужным контекстом и нагрузкой уже работает на одной карте, документация vLLM рекомендует не усложнять развёртывание распределённым выводом [s1](#src-s1). Второй GPU не удваивает автоматически скорость: tensor parallelism обменивается данными между картами, а реальный выигрыш зависит от модели, соединения и профиля запросов. Мы здесь не приводим ни одной измеренной скорости. Если **одна копия модели** не помещается на одну карту, но помещается в суммарную рабочую конфигурацию одного сервера, начните с tensor parallelism (`TP`): для двух карт укажите `--tensor-parallel-size 2` [s7](#src-s7). Если у модели неудобное разбиение или нет быстрого межкарточного соединения, руководство предлагает pipeline parallelism (`PP`): слои исполняются стадиями, а не разделяются внутри слоя; для проверки альтернативы задайте `--tensor-parallel-size 1 --pipeline-parallel-size 2` [s7](#src-s7). Не обещайте, что PP всегда быстрее: это гипотеза для сравнения на своей машине. Если модель уже помещается на одном GPU и нужно обслуживать больше **независимых запросов**, data parallelism (`DP`) поднимает отдельные реплики: `--data-parallel-size 2` на двух GPU — другой путь, не способ вместить одну модель на две карты [s5](#src-s5). Задача Первая конфигурация на одном узле Что проверить `

Одна модель не помещается на одном GPU

--tensor-parallel-size 2

API-ответ, оба процесса и память каждой карты s7

TP не подходит из-за деления или соединения

--tensor-parallel-size 1 --pipeline-parallel-size 2

Те же тесты и измерение на своей нагрузке s7

Две независимые реплики одной небольшой модели

--data-parallel-size 2

Обе реплики, маршрутизацию и пропускную способность s5

Для нескольких узлов официальный пример комбинирует TP по числу карт в узле и PP по числу узлов, но требует согласованной среды, сетевой настройки и закрытого внутреннего сегмента; это не рецепт «просто подключить второй компьютер» s7. В этой статье основной маршрут — два GPU в одной Linux-машине.

Что подготовить для пробного запуска?

Проверьте поддержку своего GPU и соответствие драйвера/CUDA именно выбранному пакету: документация GPU-установки перечисляет платформы отдельно и не обещает, что Linux-команда для NVIDIA подходит AMD, Intel или Mac. Нативный Windows-путь не поддерживается; WSL — отдельный сценарий с проверкой совместимости s2. Для примера ниже предполагаются Linux, два видимых NVIDIA GPU, установленный uv, доступ к Hugging Face и свободное место для весов. На рабочем узле не ставьте пакет в системный Python; если драйвер/пакет не согласованы, остановитесь до скачивания модели.

Тестовый кандидат — официальный Qwen/Qwen2.5-7B-Instruct: карточка автора описывает instruction-вариант с меткой Apache-2.0 и рекомендует vLLM для развёртывания; текст лицензии конкретного репозитория сохранён отдельно, а условия других весов могут отличаться s6. В его закреплённом config.json — 28 attention heads, четыре KV heads и max_position_embeddings: 32768; заявленный в карточке более длинный контекст требует отдельной настройки, которую мы здесь не включаем s8 s6. Это не заявление, что модель требует двух карт или имеет определённый минимум VRAM. Она нужна как один фиксированный кандидат для проверки параллелизма. Перед запуском оцените память под веса и контекст; даже на двух GPU можно получить OOM из-за KV-кэша, графов и нагрузки s4.

Идентификатор карточки в источниках закреплён SHA a09a35458c702b33eeacc393d103063234e8bc28, но команда vllm serve Qwen/Qwen2.5-7B-Instruct без явного snapshot-пути не закрепляет скачиваемые файлы s6. Для повторяемого теста заранее получите snapshot нужной ревизии проверенным HF-клиентом и укажите локальный путь к нему; не публикуйте HF-токены или содержимое кэша. Сохраните версии runtime, драйвера, CUDA и ревизию фактически загруженных весов.

Как поднять сервер на двух GPU?

На подготовленной Linux-машине создайте отдельное окружение, установите vLLM и проверьте видимость обеих карт. Установку CUDA-колёс и её платформенные ограничения сверьте с официальной инструкцией vLLM и актуальной документацией производителя s2. Пример фиксирует опубликованную версию 0.18.0 для согласования с версионированным руководством параллелизма s1:

nvidia-smi --query-gpu=index,name,memory.total --format=csv
uv venv .venv --python 3.12
uv pip install --python .venv/bin/python 'vllm==0.18.0'
CUDA_VISIBLE_DEVICES=0,1 .venv/bin/vllm serve Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 2 \
--max-model-len 2048 \
--host 127.0.0.1 --port 8000

Форма vllm serve ... --tensor-parallel-size есть в официальном руководстве s1 s7. Ограничение --max-model-len 2048 здесь — редакционный выбор для первого короткого запроса, а не дефолт модели или обещание, что памяти хватит: документация отдельно описывает уменьшение длины контекста и batch-size как способы сократить расход s4. CUDA_VISIBLE_DEVICES=0,1 выбирает две карты в процессе; проверьте реальные ID и доступность в nvidia-smi до запуска. --host 127.0.0.1 намеренно оставляет тестовый API внутри машины, а не выставляет его в сеть. Первая загрузка может обращаться к HF; закрытый контур проверяют отдельно после локальной загрузки весов.

Не меняйте сразу TP, размер контекста и модель: иначе ошибка или улучшение скорости не имеют понятной причины. Если подготовленный snapshot лежит на диске, подставьте его путь вместо имени HF-репозитория; это помогает воспроизвести точную ревизию при последующем сравнении. Версия документации и версия бинарного пакета должны совпасть по смыслу опций, но для своей системы проверьте доступные флаги через .venv/bin/vllm serve --help, прежде чем автоматизировать развёртывание.

Как убедиться, что участвуют обе карты?

Из другого терминала отправьте короткий Chat Completions-запрос к локальному серверу. Для этого endpoint модель должна иметь chat template — у выбранной instruction-модели он предусмотрен в карточке/репозитории; у произвольного базового чекпойнта наличие шаблона проверяют отдельно s3 s6.

curl -sS -i http://127.0.0.1:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"Ответь одним предложением: что такое tensor parallelism?"}],"max_tokens":80}'
nvidia-smi --query-compute-apps=gpu_uuid,pid,used_gpu_memory --format=csv

Сохраните фактический HTTP-статус, непустой choices[0].message.content, имя модели, журнал старта и процессную память обеих карт. Если имя модели в API отличается от запроса, сначала посмотрите /v1/models и используйте возвращённый id; это не повод менять checkpoint молча s3. Два процесса с аллокацией на двух картах и успешный ответ — проверка участия обеих карт в одном тесте; это не доказательство линейного ускорения, устойчивости под нагрузкой или правильности ответа в вашей предметной области. Документация советует также читать строки GPU KV cache size и Maximum concurrency: это оценка доступной ёмкости/параллелизма при данном контексте, а не опубликованный минимум VRAM s7.

Для сравнения с однокарточным вариантом сохраните одинаковые ревизию модели, runtime, параметры запроса и длину контекста; измерьте latency и throughput на разрешённых тестовых запросах, пока ничего иного не изменено. Если одна карта не помещает модель, сравнение с TP=1 на той же конфигурации невозможно — не подменяйте его меньшей моделью без явной оговорки.

Что делать при ошибке и как откатиться?

Сервер не стартует или виден один GPU. Сверьте CUDA_VISIBLE_DEVICES, вывод nvidia-smi, драйвер и совместимость платформы с выбранным колесом; не переносите рецепт NVIDIA на AMD/Windows без их документации s2.
Ошибки деления голов или неправильной раскладки. На примере Qwen конфигурация указывает 28 Q-heads и четыре KV-heads; это совместимо с делением на две группы, но не является гарантией, что любой backend, квант или иная модель заведётся с TP=2 s8. Если деление не поддерживается или соединение медленное, попробуйте отдельный PP-тест на тех же двух картах, без заявления о превосходстве скорости s7.
OOM или недостаточно места для KV-кэша. Уменьшите --max-model-len, нагрузку/--max-num-seqs или выберите другой конкретный checkpoint; сверяйте фактическую память обеих карт. Размер файла весов нельзя называть минимальным VRAM s4.
API молчит при видимых процессах. Проверьте журнал запуска, HTTP-статус, адрес 127.0.0.1:8000, /v1/models и имя модели в теле запроса. Наличие процессов не означает готовность Chat Completions s3.
Сбой при распределении между узлами. Не выставляйте внутренние Ray/NCCL-порты в публичную сеть: документация предупреждает о нешифрованном межузловом трафике и необходимости приватного сегмента; диагностику NCCL выполняйте на закрытом стенде s7.

Для остановки нажмите Ctrl+C в терминале сервера; затем проверьте отсутствие занятых GPU-процессов. Удалять .venv можно только в каталоге собственного эксперимента, а общий HF-кэш не удаляйте без проверки других пользователей. Тестовую конфигурацию не переносите в production без проверки доступа к API, нагрузки, памяти, логов и восстановления после отказа.

Следующий шаг: зафиксируйте реальный ответ API и память каждой карты, затем оцените запас под рабочую модель и контекст. Если нужна альтернативная серверная реализация, откройте SGLang и сравнивайте только при одинаковой задаче, ревизии весов и железе.

` ## Источники 1. [vLLM 0.18.0 — Parallelism and Scaling](https://docs.vllm.ai/en/v0.18.0/serving/parallelism_scaling/) — получено 2026-09-24 2. [vLLM — GPU Installation](https://docs.vllm.ai/en/latest/getting_started/installation/gpu/) — получено 2026-09-24 3. [vLLM — Online Serving](https://docs.vllm.ai/en/latest/serving/online_serving/) — получено 2026-09-24 4. [vLLM — Conserving Memory](https://docs.vllm.ai/en/latest/configuration/conserving_memory/) — получено 2026-09-24 5. [vLLM — Data Parallel Deployment](https://docs.vllm.ai/en/latest/serving/data_parallel_deployment/) — получено 2026-09-24 6. [Qwen/Qwen2.5-7B-Instruct — карточка закреплённой ревизии](https://huggingface.co/Qwen/Qwen2.5-7B-Instruct/resolve/a09a35458c702b33eeacc393d103063234e8bc28/README.md) — получено 2026-09-24 7. [vLLM — Parallelism and Scaling, закреплённый Git commit](https://raw.githubusercontent.com/vllm-project/vllm/8b84e15066b07cf0064a0ff05f153cc85cb42817/docs/serving/parallelism_scaling.md) — получено 2026-09-24 8. [Qwen/Qwen2.5-7B-Instruct — config.json закреплённой ревизии](https://huggingface.co/Qwen/Qwen2.5-7B-Instruct/resolve/a09a35458c702b33eeacc393d103063234e8bc28/config.json) — получено 2026-09-24