Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Обучение диффузионных драфтеров с длинным контекстом можно распараллелить так, чтобы обмен данными не рос вместе с контекстом. В препринте Geng Zhang и коллег, который не прошёл рецензирование, приведены собственные замеры авторов: Split-KV ускорил обучение до 3,67 раза при разделении контекста между 64 ускорителями. Метод позволяет увеличивать учебный контекст, не оплачивая его длину пропорциональным ростом сетевого обмена на каждом слое.
Короткого запроса хватило для длинного контекста
Диффузионный драфтер предлагает сразу блок токенов, а целевая модель проверяет их за один проход. При обучении драфтер выбирает в ответах опорные позиции и строит для них короткий набор запросов, которые обращаются к гораздо более длинному контексту через блочно-разреженную маску внимания.
Длина контекста зависит от учебных примеров, а число запросов задаёт бюджет опорных позиций. Эти величины не обязаны расти вместе, но до этой работы было неясно, ухудшится ли драфтер, если оставить бюджет запросов прежним при увеличении контекста.
Авторы обучили DFlash для Qwen3.5-9B и Qwen3.5-35B-A3B. Когда максимальный контекст увеличили в 16 раз при прежнем бюджете запросов, средняя длина принятого черновика изменилась не более чем на 0,82%. Эта метрика показывает, сколько токенов целевая модель в среднем принимает за один шаг проверки.
Рост бюджета запросов улучшал результат, но отдача снижалась: последнее удвоение прибавило не более 1,57%. Это создаёт полезный для инфраструктуры режим: контекст остаётся длинным, а набор запросов — сравнительно коротким.
Split-KV двигает запросы, а не ключи и значения
Контекстный параллелизм делит одну длинную последовательность между несколькими ускорителями. Ring Attention и ряд других методов передают между ними части ключей и значений, поэтому объём обмена растёт вместе с контекстом. Для диффузионного драфтера это перенос самой крупной части состояния.
Split-KV оставляет части ключей и значений на тех ускорителях, где они были рассчитаны. Вместо них система собирает на каждом участнике полный набор запросов, вычисляет локальные части внимания, согласует нормировку и распределяет готовый результат обратно владельцам запросов. Поскольку передаются короткие запросы и их градиенты, обмен на слое зависит от их размера, а не от длины контекста.
Такое разбиение не приближает исходное внимание, а точно воспроизводит результат вычисления на одном устройстве. Это отличает метод от способов, которые сокращают стоимость ценой изменённой маски или отбора ключей.
Выборка опорных позиций создаёт ещё одну проблему: разные участки контекста получают разную нагрузку. Split-KV видит все запросы и может заранее вычислить стоимость каждого участка. Алгоритм LPT сортирует участки от самых дорогих к дешёвым и каждый следующий назначает на наименее загруженный ускоритель.
При увеличении объёма работы вместе с числом ускорителей Split-KV сохранил 85–91% идеальной эффективности. LPT удержал перекос нагрузки ниже 1% и строил план почти на три порядка быстрее DCP, который использует более общий и дорогой разделитель графа. В отдельных замерах одна только балансировка сократила время шага обучения в 1,15–1,42 раза.
Когда метод меняет инфраструктурный план
Работа относится не к обучению любой LLM, а к диффузионным драфтерам с выборкой опорных позиций и короткими запросами к длинному контексту. Качество проверяли на DFlash и двух моделях Qwen, используя GSM8K, MATH-500, HumanEval, MBPP и MT-Bench. Системную часть сравнивали с Ulysses, Ring Attention, RingX, LV-XAttn, Zigzag и DCP.
Для команды, которая обучает такой драфтер, Split-KV разделяет два решения. Бюджет запросов можно выбирать по качеству черновиков, а длину контекста — по данным продукта; инфраструктура больше не требует автоматически увеличивать первое вслед за вторым. Это особенно заметно там, где сеть между GPU уже ограничивает масштабирование.
Метод не обещает ускорить само рабочее декодирование: он сокращает стоимость обучения драфтера. Для обычного авторегрессионного обучения с плотным вниманием профиль нагрузки другой, поэтому переносить заявленное ускорение на него нельзя. Практический кандидат на внедрение — обучение DFlash, Domino или DSpark, поскольку в работе для них указан тот же шаблон внимания.
Архитектурный вывод шире конкретной реализации: при разреженном внимании схему параллелизма стоит строить вокруг того, какая часть состояния действительно мала. Если запросы короче контекста, выгоднее размножить запросы и оставить длинные ключи и значения на месте, чем механически переносить схему из обучения обычной LLM.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
