В этом материале
При prefill-decode disaggregation в SGLang задержку передачи KV нужно отделять от вычислений обеих стадий.
При prefill-decode disaggregation в SGLang задержку передачи KV нужно отделять от вычислений обеих стадий. Быстрый prefill не гарантирует быстрый первый выходной токен, если состояние долго перемещается между workers. Постройте временную линию запроса и проверьте выбранный transport. Увеличение мощности decode GPU без такой локализации может не устранить причину ожидания и лишь изменить другую часть общей системы исполнения.
Разложите путь запроса
Сначала вход обрабатывает prefill worker, затем подготовленное состояние должно стать доступным decode worker. Руководство PD disaggregation описывает варианты transport, включая Mooncake и NIXL, и необходимые условия взаимодействия. Это не просто два HTTP сервера с одинаковой моделью. Перед измерением проверьте согласованность конфигурации, идентификацию workers и требования к передаче. Нельзя считать совпадение model name достаточным доказательством совместимости формата состояния или правильного маршрута его доставки в выбранной реализации.
Проверьте отображение оборудования
Сохраните соответствие GPU, сетевых устройств и процессов. Физически доступный быстрый интерфейс не означает, что transport действительно использует нужный путь. Проверяйте конфигурацию и диагностические сообщения, а не выводите маршрут только из модели сетевой карты. Также отделяйте передачу внутри узла от передачи между узлами: топология и ограничения отличаются. Если transport требует дополнительных библиотек или определенной поддержки среды, зафиксируйте их версии до сравнения. Само наличие открытого порта не подтверждает работоспособность data path.
Пример временной карточки
Для одного запроса запишите прием, окончание prefill, начало и конец передачи состояния, начало decode и первый ответ клиенту, насколько эти точки доступны наблюдению. Недоступные отметки явно пометьте, не выдумывая точное время transport из остатка без учета других этапов. Сравните короткий и длинный вход при одинаковом контроле вывода. Если растет интервал между окончанием prefill и началом decode, исследуйте передачу и ожидание принимающей стороны, а не только скорость вычисления attention на отправителе.
Профилируйте workers раздельно
Официальное руководство profiling указывает на необходимость отдельного профилирования при PD. Синхронизируйте наблюдения по request identity и временной шкале. Один GPU trace не показывает, что происходило на другом worker, а средняя загрузка двух GPU способна скрыть передачу. Повторите серию с зафиксированным размещением и без параллельного изменения scheduler budgets. Если receiving worker занят, transport ожидание нужно отличать от фактического копирования, иначе неверно выбранный слой станет целью последующих оптимизаций.
Как сформулировать вывод
Отчет должен содержать topology, transport, версии, длины запросов и наблюдаемые границы стадий. Укажите, что измерялось непосредственно, а что оценивалось косвенно. Отдельно проверьте ошибки доставки и возможность повторного исполнения запроса, не обещая бесшовного восстановления любой разорванной передачи. При смене transport повторите функциональную и временную приемку. Практический результат — локализованное узкое место и воспроизводимая карточка запроса, а не общий совет покупать более быстрые GPU или сеть. Разделение стадий полезно лишь тогда, когда полный путь удовлетворяет требованиям workload; оно не устраняет автоматически стоимость перемещения KV и не доказывает преимущество над совместным prefill/decode на одном процессе без отдельного сравнения.
Связанные материалы
Prefill и decode: какую работу выполняет ваш GPU при инференсе; PCIe и GPU-хостинг: когда соединение ограничивает модель.