«Ваша задача — настроить, а не собрать»: AWS выпустила multi-node Ray LLM DLC для разделения prefill и decode

Почему фазы разделяют

Инференс LLM состоит из двух разных работ: prefill обрабатывает весь входной промпт параллельно и строит KV-кэш, а decode генерирует ответ по одному токену, читая и дописывая этот кэш. Prefill упирается в вычисления, decode — в пропускную способность памяти. Когда обе фазы делят один GPU, они конкурируют за одни и те же ресурсы: «взрывная», насыщенная вычислениями работа prefill мешает ровной и чувствительной к задержке работе decode.

PD-разделение (prefill/decode disaggregation) разносит фазы по разным узлам, чтобы каждая работала, не мешая другой, и масштабировалась независимо. Плата за это — передача: KV-кэш, построенный на prefill-узле, надо отдать decode-узлу, и передача должна быть достаточно быстрой, чтобы не съесть выигрыш. Именно поэтому решающим становится interconnect между узлами.

Что внутри контейнера

Ray LLM DLC — предсобранный и проверенный Docker-образ: движок инференса vLLM, HTTP-слой Ray Serve, NIXL для передачи KV-кэша между узлами и стек EFA (libfabric и aws-ofi-nccl) для связи узел-узел. Компоненты проверяются вместе перед каждым релизом, поэтому между CUDA-рантаймом, фреймворком и слоем обслуживания нет расхождения версий, а патчи безопасности применяются на этапе сборки.

Приложение обслуживания описано блоком YAML: помощник build_pd_openai_app принимает конфигурации prefill и decode и сам связывает передачу KV-кэша за одним OpenAI-совместимым эндпоинтом — ни класса-обработчика, ни архиватора моделей, ни собственного образа собирать не нужно.

Архитектура примера

Кластер EKS живёт в VPC, узлы — в приватных подсетях с выходом через NAT Gateway. CPU-узел m7i.xlarge несёт системные нагрузки, оператор KubeRay и Ray head pod без GPU, а два GPU-узла g6.8xlarge обслуживают фазы и оба тянут образ из Amazon ECR. KubeRay следит за применённым RayService и сам подключает worker-узлы к голове.

GPU-группа привязана к единственной зоне доступности, потому что EFA не пересекает зоны. Рабочие pod'ы запрашивают один GPU и один EFA-интерфейс и запускаются как privileged: NIXL регистрирует память CUDA с EFA-адаптером, и одной возможности IPC_LOCK для этого недостаточно.

Настройки, которые решают исход

Обе фазы описывают одну модель Qwen/Qwen3.5-9B одинаково: max_model_len 4096, dtype bfloat16, gpu_memory_utilization 0.90 и enforce_eager, отключающий захват CUDA-графов ради меньшего пикового расхода памяти. AWS называет критической одну строку — kv_connector_extra_config с backends LIBFABRIC: без неё NIXL по умолчанию выбирает UCX, который на EFA работает на скорости TCP.

Отдельное предупреждение: при невозможности использовать libfabric NIXL молча откатывается на TCP-транспорт и не поднимает ошибку, поэтому выбранный backend стоит подтверждать по логам worker'ов. Эффект кэша виден на перезапуске — для Qwen3.5-9B на g6.8xlarge загрузка весов падает примерно с 145 секунд до примерно 2 секунд.

Порядок развёртывания

Все скрипты делят один файл конфигурации scripts/env.sh. Кластер создаётся за 15–20 минут на первом прогоне, GPU-группа — примерно за 5–20 минут, оператор KubeRay ставится через Helm за 1–2 минуты, а RayService рендерится из манифеста через envsubst и ждёт готовности головы, обоих worker'ов и статуса RUNNING у приложения Serve. Последний шаг занимает несколько минут, потому что модель грузится на каждом узле.

Для примера нужна квота минимум на два g6.8xlarge (не менее 64 vCPU), AWS CLI, kubectl, eksctl, Helm и envsubst. После запуска DLC отдаёт OpenAI-совместимый API: список моделей и чат-запросы уходят стандартными вызовами без собственной схемы, а транспорт проверяется поиском в логах worker'ов строки о выбранном backend'е — LIBFABRIC или UCX.

Что это меняет

Публикация продолжает более ранний материал AWS о Ray Serve DLC, где небольшая модель поднималась за HTTP-эндпоинтом на одном GPU-узле. Сам AWS перечисляет три типовых сценария многоузлового инференса: тензорный и конвейерный параллелизм для моделей, не влезающих в один инстанс, data parallelism для пропускной способности и PD-разделение фаз по разным узлам. Итог авторов — «ваша задача — настроить, а не собрать»: стек собран и протестирован AWS, инженеру остаётся конфигурация.