Представлен PolyGraph: один CUDA Graph вместо 64 для спекулятивного декодирования

Адаптивное спекулятивное декодирование на каждом шаге меняет размер активного батча B и длину черновика d, а CUDA Graph воспроизводит фиксированную конфигурацию запуска. Из-за получающейся ширины проверки M = B·d системам обслуживания приходится выбирать из трёх вариантов: заранее снимать множество графов под разные формы, снимать новые прямо на пути обслуживания запроса или добивать (паддить) каждый шаг до самого длинного черновика.

Авторы препринта на arXiv предлагают PolyGraph, механизм «буфера плана» для собственных ядер на Triton, который снимает необходимость этого выбора. Снимается один граф с максимальной сеткой, а перед каждым воспроизведением в память GPU записывается активная форма. Ядра пропускают тайлы за пределами этой формы, при этом топология графа, выделения памяти, раскладки, указатели и сетки запуска остаются неизменными. Обновление при каждом воспроизведении передаёт всего 28 байт.

Измерения проведены на одной NVIDIA H800 в прототипе, управляемом трассами, с размерностями Qwen2.5-3B. PolyGraph заменяет 64 графа под конкретные формы одним, по наблюдаемой задержке шага совпадает с прогретой базовой схемой (17,7 против 17,8 мс по медиане, P50) и сокращает измеренное время сборки графов до начала обслуживания с 3915 до 93 мс.

Контрольные эксперименты с фиксированным черновиком показывают, что выигрыш даёт отказ от паддинга. Разница по P99 (99-й перцентиль задержки) с базовой схемой MaxPad пренебрежимо мала при нулевых потерях на паддинг, но при 100% потерь достигает снижения на 18,7%. Сами авторы оговаривают рамки: доказан ограниченный механизм формы работы для собственных ядер, а не промышленная система обслуживания, и оценка опирается на синтетические трассы на одном GPU.

Ключевые факты

  • PolyGraph, механизм буфера плана для собственных ядер на Triton: снимается один граф с максимальной сеткой, активная форма записывается в память GPU перед каждым воспроизведением, а ядра пропускают лишние тайлы.
  • Обновление перед воспроизведением передаёт только 28 байт; топология графа, указатели, раскладки и сетки запуска не меняются.
  • В прототипе на одной NVIDIA H800 (размерности Qwen2.5-3B) один граф заменил 64; задержка шага по P50, 17,7 мс против 17,8 мс у прогретой базовой схемы.
  • Время сборки графов до начала обслуживания снизилось с 3915 до 93 мс.
  • Против MaxPad по P99 выигрыш пренебрежимо мал при нулевом паддинге и достигает 18,7% при 100% потерь; авторы подчёркивают, что это не промышленная система и оценка ограничена синтетическими трассами на одном GPU.

Почему это важно

Спекулятивное декодирование с адаптивными параметрами упирается в особенность CUDA Graph: граф воспроизводит фиксированную конфигурацию, а батч и длина черновика меняются от шага к шагу. Известные обходные пути, предварительно снимать много графов, снимать новые на лету или паддить до максимума, имеют цену. PolyGraph показывает на прототипе, что один граф может покрыть все формы без заметного роста медианной задержки шага.

Кому это важно

Прежде всего инженерам, которые пишут собственные ядра на Triton и строят системы обслуживания языковых моделей с адаптивным спекулятивным декодированием. Для них интересны и экономия на числе графов (64 заменены одним), и сокращение времени сборки графов до начала обслуживания с 3915 до 93 мс.

Как это применить

Идея в аннотации описана для собственных ядер на Triton: нужно снимать один граф с максимальной сеткой, передавать активную форму через небольшой буфер в памяти GPU (28 байт на воспроизведение) и добавить в ядра пропуск тайлов за пределами этой формы. Готовых рекомендаций по внедрению в существующие системы обслуживания аннотация не содержит; это механизм для кастомных ядер.

Можно ли доверять

Это препринт на arXiv, пересказ сделан по аннотации. Авторы сами ограничивают выводы: оценка на синтетических трассах, на одной GPU (NVIDIA H800), с размерностями Qwen2.5-3B, и это не промышленная система обслуживания. Равенство задержек (17,7 против 17,8 мс) приведено только по медиане P50; цифра 18,7%, это снижение P99 относительно MaxPad при 100% потерь на паддинг, а не относительно прогретой базовой схемы.

Риски и подводные камни

Выигрыш по P99 зависит от доли паддинга: при нулевых потерях разница с MaxPad пренебрежимо мала, максимум в 18,7% получен при 100% потерь. Результаты получены на одном GPU и синтетических трассах, поэтому переносить цифры на реальный трафик, другие модели или несколько GPU без собственной проверки нельзя. Механизм рассчитан на собственные ядра, которые умеют пропускать тайлы по записанной форме.

«Наши данные подтверждают ограниченный механизм формы работы для собственных ядер, а не промышленную систему обслуживания, и ограничены синтетическими трассами на одном GPU.»

— Авторы PolyGraph, аннотация препринта на arXiv