# vLLM data parallel: две копии модели для одновременных запросов

Источник: https://modelium.tech/zhurnal/vllm-data-parallel/

Data parallel в vLLM запускает отдельную копию модели на каждом из двух GPU и распределяет между ними независимые запросы. Это полезно, когда модель уже помещается на одной карте, но нужно обслуживать несколько пользователей; если она не помещается, нужен другой способ распределения. Ниже — сценарий для Linux и двух совместимых NVIDIA GPU, сверенный по документации, но не воспроизведённый редакцией.

**Инженерный сценарий, не домашний рецепт.** Нужны Linux, два совместимых NVIDIA GPU (видеокарты) и навыки работы с терминалом. Сведения сверены с документацией vLLM на Git-ревизии `a5105db` и карточкой Qwen на ревизии `a09a354`; Modelium не запускал сервер или модель. Для установки и первого скачивания весов нужна сеть. Запросы к `127.0.0.1` после подготовки идут на локальный API (адрес сервера для запросов), но без отдельного сетевого теста это не доказательство полностью офлайн-системы. [s1](#src-s1) [s3](#src-s3) [s5](#src-s5)

## Зачем нужны две копии модели?

Представьте двух сотрудников, которые одновременно просят локального помощника кратко изложить разные заметки. **Data parallel (DP)** запускает две копии одной модели и направляет независимые запросы в разные рабочие процессы; с `--data-parallel-size 2` у сервера один адрес API и внутреннее распределение. Это вариант для модели, которая уже помещается на **одном** GPU. Если веса и рабочий контекст не помещаются на одной карте, **tensor parallel (TP)** делит одну копию между картами: это другая задача. [s1](#src-s1) [s2](#src-s2)

## Что понадобится перед запуском?

Для этого маршрута нужны Linux, Python 3.10–3.13, `uv`, две видимые NVIDIA CUDA-карты с compute capability от 7.5 и совместимые драйверы. Размер видеопамяти, оперативной памяти и свободного диска для **этой пары модель + нагрузка** источники не задают универсальным минимумом: выясните его в однокарточном пробном запуске, не выводите из названия модели или размера файла. Если одной карте не хватает памяти, не переходите сразу к DP=2 — сначала разберите TP или выберите меньшую модель. [s2](#src-s2) [s3](#src-s3) [s4](#src-s4)

Для примера выбрана конкретная instruction-модель `Qwen/Qwen2.5-7B-Instruct`; карточка автора рекомендует vLLM и помечает лицензию Apache-2.0. Зафиксированная ревизия карточки — `a09a35458c702b33eeacc393d103063234e8bc28`, но команда с именем репозитория **не закрепляет скачиваемые веса**: для повторяемого измерения укажите локальный snapshot нужной ревизии и запишите её вместе с версией vLLM и драйвера. Не публикуйте токены доступа или документы пользователей. [s5](#src-s5)

## Как получить первый ответ с двумя репликами?

- Проверьте обе карты командой `nvidia-smi --query-gpu=index,name,memory.total --format=csv`. Должны появиться две строки с ожидаемыми устройствами; если карта не видна, остановитесь до установки модели. Сверьте драйвер и CUDA с [базовым руководством vLLM](/zhurnal/vllm/) и документацией установки. [s3](#src-s3) [s4](#src-s4)

- В отдельной рабочей папке установите `uv` по его документации, затем выполните `uv venv --python 3.12 --seed`, `source .venv/bin/activate`, `uv pip install vllm --torch-backend=auto` и `vllm --version`. Последняя команда должна вывести реально установленную версию; не считайте совпадение Git-ревизии документации и версии пакета гарантированным. [s3](#src-s3) [s4](#src-s4)

- Сначала проверьте, что выбранный checkpoint работает **на одной** карте и хватает памяти: `CUDA_VISIBLE_DEVICES=0 vllm serve Qwen/Qwen2.5-7B-Instruct --host 127.0.0.1 --max-model-len 2048`. Дождитесь готовности API, откройте `http://127.0.0.1:8000/v1/models` и убедитесь, что ID модели присутствует. Сокращённый контекст — настройка первого теста, а не заявленный минимум памяти. Остановите сервер `Ctrl+C` перед следующим шагом. Если одна копия не загрузилась, этот DP-сценарий пока не подходит. [s2](#src-s2) [s3](#src-s3)

- Теперь запустите `CUDA_VISIBLE_DEVICES=0,1 vllm serve Qwen/Qwen2.5-7B-Instruct --data-parallel-size 2 --host 127.0.0.1 --max-model-len 2048`. Ожидайте готовности того же `/v1/models` и двух рабочих движков в журнале; `--data-parallel-size 2` создаёт две реплики и один входной HTTP-порт. При иной версии сначала проверьте `vllm serve --help`; модели с MoE-экспертами могут вести себя сложнее, чем этот пример с обычной моделью. [s1](#src-s1) [s3](#src-s3)

- Во втором терминале отправьте короткий запрос: `curl -sS 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":"Заметка: Во вторник Оля отправит список вопросов. Назови человека и действие, без придуманной даты."}],"max_tokens":80}'`. Ожидается JSON с непустым `choices[0].message.content`; сверьте имя и действие с заметкой, а не принимайте наш ожидаемый смысл за реально полученный редакцией ответ. Один запрос показывает только доступность API, **не** распределение нагрузки. [s3](#src-s3) [s5](#src-s5)

## Как проверить распределение, а не только два процесса?

Пока сервер запущен, сохраните исходный снимок `curl -sS http://127.0.0.1:8000/metrics -o metrics-before.txt`. Из второго терминала на том же Linux-компьютере отправьте четыре **одновременных** запроса: `for i in 1 2 3 4; do curl -sS 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":"Назови один шаг проверки локального ответа."}],"max_tokens":80}' -o "reply-$i.json" & done; wait`. Должны появиться четыре файла `reply-1.json`…`reply-4.json` с непустым полем `choices`, если запросы завершились успешно. Это лишь малый учебный опыт: при коротких запросах он может **не успеть** загрузить обе реплики. Затем снимите `curl -sS http://127.0.0.1:8000/metrics -o metrics-after.txt`. Сравните ряды по индексу движка, особенно счётчик `vllm:request_success_total`, до/после для обоих индексов; также смотрите процессы и память обеих карт. Проверьте фактические имена меток в установленной версии. Если оба индекса не видны или растёт только один, не объявляйте распределение доказанным: повторите на достаточной **одновременной** нагрузке с руководством по бенчмарку ниже. Две аллокации GPU доказывают загрузку, но не равномерную маршрутизацию. [s1](#src-s1) [s3](#src-s3) [s6](#src-s6)

Затем сравните DP=1 и DP=2 на одной модели, одинаковом наборе запросов и длине контекста. Зафиксируйте число одновременных клиентов, среднюю и хвостовую задержку, число завершённых запросов и загрузку каждого GPU; для этого есть отдельное [руководство по `vllm bench serve`](/zhurnal/vllm-bench-serve/). **Не** обещайте удвоения скорости: реальные показатели зависят от памяти, очередей и профиля запросов. Внутренний балансировщик vLLM учитывает выполняемые и ожидающие запросы; лимит `--max-num-seqs` задаётся на каждую реплику, а ограничения общей очереди — на весь API-сервер. [s1](#src-s1)

## Если тест не получился

- Нет второго GPU в `nvidia-smi` или ошибка CUDA: проверьте видимость устройств, драйвер, совместимость GPU и установленной сборки; Linux-путь NVIDIA не переносите на AMD, Mac или Windows без отдельных инструкций. [s3](#src-s3) [s4](#src-s4)

- Однокарточный запуск завершился ошибкой нехватки памяти: не ожидайте, что DP поделит модель; вернитесь к [распределению одной модели между картами](/zhurnal/vllm-neskolko-gpu/) или другой модели. [s1](#src-s1) [s2](#src-s2)

- `/v1/models` отвечает, но нет генерации: проверьте ID в запросе, JSON-ошибку и журнал. Для сравнения двух режимов не меняйте одновременно модель, контекст и число клиентов. [s3](#src-s3)

**Следующий шаг:** [сравните задержку при DP=1 и DP=2 на одинаковой нагрузке](/zhurnal/vllm-bench-serve/). Остановите учебный сервер через `Ctrl+C`; публичный доступ к API отдельно не открывайте без продуманной защиты.

## Источники

1. [vLLM — Data Parallel Deployment, закреплённый Git commit](https://raw.githubusercontent.com/vllm-project/vllm/a5105dba05616d74dde5d40267fc500a4422b3db/docs/serving/data_parallel_deployment.md) — получено 2026-10-07
2. [vLLM — Parallelism and Scaling, закреплённый Git commit](https://raw.githubusercontent.com/vllm-project/vllm/a5105dba05616d74dde5d40267fc500a4422b3db/docs/serving/parallelism_scaling.md) — получено 2026-10-07
3. [vLLM — Quickstart, установка и локальный API](https://raw.githubusercontent.com/vllm-project/vllm/a5105dba05616d74dde5d40267fc500a4422b3db/docs/getting_started/quickstart.md) — получено 2026-10-07
4. [vLLM — NVIDIA CUDA installation requirements](https://raw.githubusercontent.com/vllm-project/vllm/a5105dba05616d74dde5d40267fc500a4422b3db/docs/getting_started/installation/gpu.cuda.inc.md) — получено 2026-10-07
5. [Qwen/Qwen2.5-7B-Instruct — карточка автора, закреплённая ревизия](https://huggingface.co/Qwen/Qwen2.5-7B-Instruct/resolve/a09a35458c702b33eeacc393d103063234e8bc28/README.md) — получено 2026-10-07
6. [vLLM — Production Metrics, закреплённый Git commit](https://raw.githubusercontent.com/vllm-project/vllm/a5105dba05616d74dde5d40267fc500a4422b3db/docs/usage/metrics.md) — получено 2026-10-07