SGLang disaggregated prefill: как разделить обработку запроса

Зачем разделять обработку входа и ответа?

Представьте сервис, которому одновременно присылают длинные документы и задают короткие вопросы. Prefill — обработка входного текста, decode — поочерёдная генерация частей ответа. Когда оба этапа делят один сервер, длинный вход может мешать выдаче текущих ответов. Режим PD disaggregation выделяет им разные процессы; между ними нужно передать KV-кеш, то есть внутреннее состояние, вычисленное по входу. Эта передача тоже занимает время: выигрыш по задержке заранее не обещан. s1

В статье один путь: два процесса SGLang на одной Linux-машине, каждый на своей GPU, и SGLang Model Gateway как один адрес для запросов. Это не режим data parallel: там обрабатывают независимые запросы на полных копиях модели, а здесь два процесса выполняют разные этапы одного запроса. Многомашинный DeepSeek-стенд из документации не требуется для первого теста. s1 s2

Что подготовить до запуска?

Сначала по базовому гайду SGLang запустите один обычный сервер с Qwen/Qwen3-0.6B и дождитесь готовности, затем проверьте ответ. Именно эту модель приводит официальный Quickstart; у её закреплённой карточки стоит лицензия Apache-2.0. Это не заявление, что Modelium проверил её совместимость именно с PD. Убедитесь через nvidia-smi, что видны две совместимые видеокарты; оцените память запуском, не по размеру файлов весов. Не заменяйте модель на другую без проверки прав, формата и совместимости. s3 s4 s5

Для отдельного окружения документация SGLang предлагает uv venv --python 3.12, source .venv/bin/activate, uv pip install --prerelease=allow sglang. Дополнительно для выбранного способа переноса установите uv pip install nixl и uv pip install sglang-router — пакеты и модель скачиваются из сети. NIXL по умолчанию использует UCX; его совместимость и сетевой транспорт на конкретной машине нужно проверить, а не предполагать. Одинаковые версии SGLang и модельных файлов на обоих процессах обязательны для честного сравнения; показанный ID Hugging Face сам по себе не фиксирует ревизию загруженных весов. s1 s2 s3 s5

Как проверить маршрут одного запроса?

1. На одной Linux-машине в первом терминале с активным окружением запустите обработчик входа: CUDA_VISIBLE_DEVICES=0 python -m sglang.launch_server --model-path Qwen/Qwen3-0.6B --disaggregation-mode prefill --disaggregation-transfer-backend nixl --host 127.0.0.1 --port 30000 --enable-metrics. Дождитесь готовности; если NIXL/модель не загрузились, дальше не продолжайте. Имена портов и выбор GPU адаптированы для учебного стенда из официального примера с двумя процессами, а не проверены на железе Modelium. s1 s4 s6
2. Во втором терминале активируйте то же окружение и запустите выдачу ответа на другой карте: CUDA_VISIBLE_DEVICES=1 python -m sglang.launch_server --model-path Qwen/Qwen3-0.6B --disaggregation-mode decode --disaggregation-transfer-backend nixl --host 127.0.0.1 --port 30001 --enable-metrics. Документация вместо ограничения видимости GPU использует --base-gpu-id 1; перед тестом сверьте nvidia-smi и журналы обоих процессов — нельзя незаметно запустить оба на одной карте. s1 s6
3. В третьем терминале активируйте окружение и запустите маршрутизатор: python -m sglang_router.launch_router --pd-disaggregation --prefill http://127.0.0.1:30000 --decode http://127.0.0.1:30001 --host 127.0.0.1 --port 8000. Он должен увидеть оба процесса. Порт 8000 здесь открыт только на loopback; публикация интерфейса в сети требует отдельной аутентификации и защиты. s1 s2
4. В четвёртом терминале направьте короткий запрос только через 8000: curl -sS http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"Qwen/Qwen3-0.6B","messages":[{"role":"user","content":"Встреча в четверг. Назови день встречи одним словом."}],"max_tokens":64}'. Проверьте HTTP-ответ: нет поля error, а choices[0].message.content непустой и соответствует входу. Конкретный ответ модели мы не получали; слово «четверг» — критерий для вашего сравнения, не журнал запуска редакции. s2 s4 s5

Как отличить передачу данных от кажущегося успеха?

Сохраните журналы prefill, decode и маршрутизатора для одного запроса: проверьте, что не было тайм-аута передачи KV-кеша, а ответ пришёл через 8000; наличие двух живых процессов само по себе не доказывает передачу. Отдельно снимайте счётчики /metrics на 30000 и 30001 до и после теста, если они доступны в установленной версии: ищите операции на обоих процессах, не складывайте разные типы счётчиков как одну скорость. При ошибке handshake/UCX зафиксируйте текст ошибки, версии и доступные устройства; не объявляйте тест успешным из-за одного HTTP 200 от маршрутизатора. s1 s2 s6

Чтобы проверить смысл настройки, сопоставьте на собственном стенде время до первого токена, интервалы между последующими токенами, долю успешных запросов и задержку целиком при одинаковых модели, длинах входа и ответа, числе клиентов, версии и бюджете GPU. Не принимайте время до HTTP-заголовков за время до первого токена; для этого нужен клиент, который фиксирует поток ответа, либо подходящие метрики вашей версии маршрутизатора. Сравнение одной и двух GPU без указания разного бюджета не доказывает пользу PD. У Modelium нет такого замера. s1 s2

Если одна GPU не видна или нет памяти — возвращайтесь к обычному серверу и меньшей модели. Если не работает NIXL, проверьте UCX/транспорт и совместимость версий; если маршрутизатор не видит обработчик, сверяйте адреса и его журнал. Остановите учебные процессы через Ctrl+C в трёх терминалах. Следующий шаг: разобрать метрики каждого SGLang-процесса до оптимизации. s1 s2 s3