AWS показала, как запустить одну LLM на двух GPU-узлах EKS через Ray LLM DLC

AWS опубликовала пошаговое руководство по запуску одной большой языковой модели на двух GPU-узлах Amazon EKS. Один узел выполняет prefill, второй decode, а снаружи всё выглядит как один OpenAI-совместимый эндпоинт. В основе лежат multi-node Ray LLM Deep Learning Containers. Это готовые образы, в которые уже упакован весь стек инференса. Сборка компонентов уходит из задач команды, остаётся конфигурация деплоя.

Что именно разворачивают

Схема короткая. Есть одна модель, два GPU-узла в кластере Amazon EKS и два разных этапа обработки запроса, разнесённых по разным машинам. Клиентское приложение ничего о топологии не знает. Оно обращается к одному адресу по привычному OpenAI-протоколу, и существующие SDK и обвязка продолжают работать без правок.

Главное в релизе не сама идея, а упаковка. Раньше собрать multi-node инференс означало самому подбирать совместимые версии движка, оркестратора, драйверов и сетевых библиотек. Теперь AWS поставляет это как предсобранный контейнер из линейки Deep Learning Containers. Поддержка Ray в таком образе логична: Ray давно служит слоем оркестрации распределённых нагрузок, а его LLM-надстройка рассчитана на раздачу моделей через единый API.

Зачем разделять prefill и decode

У генерации текста две фазы с разным профилем нагрузки. Prefill обрабатывает входной промпт целиком. Это плотные вычисления, и они упираются в производительность GPU. Decode выдаёт токены по одному и чаще упирается в пропускную способность памяти и размер KV-кэша.

Если держать обе фазы на одних и тех же ускорителях, они мешают друг другу. Длинный промпт одного пользователя задерживает выдачу токенов другим. Разделение по узлам позволяет настраивать каждую сторону отдельно: подбирать параллелизм, размер батча и объём памяти под свою задачу. Цена такого подхода известна. Между узлами нужно передавать KV-кэш, поэтому важны сеть и корректная настройка коннектора. Именно эту часть контейнер и берёт на себя.

Ключевые параметры схемы

• Модель: одна большая LLM, распределённая между узлами.
• Топология: два GPU-узла, один выделен под prefill, второй под decode.
• Платформа: Amazon EKS, то есть обычный Kubernetes в управляемом виде.
• Интерфейс: единый OpenAI-совместимый эндпоинт для всех клиентов.
• Поставка: предсобранный multi-node Ray LLM Deep Learning Container с полным стеком инференса.
• Подход к настройке: конфигурация деплоя без ручной сборки компонентов.

Практика: на что смотреть перед внедрением

Такая архитектура оправдана не везде. Для небольшой модели, которая помещается на один узел, дезагрегация только добавит сетевых хопов и точек отказа. Она имеет смысл там, где модель не помещается в память одного узла или где профиль трафика резко неоднороден. Например, длинные контексты на входе при коротких ответах на выходе, или наоборот.

Перед пилотом стоит проверить несколько вещей:

• Связность между узлами. Передача KV-кэша чувствительна к задержке и пропускной способности, поэтому размещайте узлы в одной зоне доступности и сверяйтесь с документацией AWS по поддерживаемым типам инстансов и сетевым адаптерам.
• Метрики по фазам. Следите за временем до первого токена, которое зависит от prefill, и за скоростью выдачи токенов, которая зависит от decode. Общая средняя задержка скроет перекос.
• Баланс узлов. Один узел на каждую фазу даёт стартовую точку. Если очередь копится на одной стороне, придётся масштабировать её независимо.
• Совместимость клиентов. OpenAI-совместимый API упрощает миграцию, но поведение редких параметров запроса лучше проверить на собственных сценариях.

Для команд, которые уже живут на EKS и ищут способ раздавать крупные модели без собственной инференс-платформы, это быстрый путь к рабочему прототипу. Стоимость и реальные показатели производительности каждый должен измерить на своём трафике: руководство описывает развёртывание, а не гарантирует конкретный выигрыш.