Qwen 4 QSA получает параллелизм контекста декодирования: внутри чернового PR vLLM для Qwen3.8-Flash-Next

29 сентября 2026 года в репозитории vLLM появился черновой pull request под названием «[Model][DCP] Support Qwen4Exp QSA», и для модели, которую он описывает, он содержит самые конкретные показатели сервинга, опубликованные кем-либо за весь месяц: парные прогоны Qwen3.8-Flash-Next на четырёх GPU показывают рост ёмкости KV-токенов с 9 759 529 до 17 603 636, увеличение максимальной конкурентности с 37,23× до 67,15× и сокращение времени до первого токена с 1 869 мс до 767 мс. Qwen3.8-Flash-Next — это предварительная версия mixture-of-experts с открытыми весами и 125 млрд параметров, в карточке которой на Hugging Face говорится: «предварительная версия архитектуры Qwen4»; pull request добавляет параллелизм контекста декодирования в путь разреженного внимания, на котором построена эта архитектура. Сам Qwen4 — уровни Qwen4 Max, Flash, Plus и 27B, названные вендором на своей конференции Apsara 22 сентября 2026 года, — всё ещё не выпущен: ни весов, ни идентификатора, ни цены, ни даты. Так что воспринимайте это как то, чем оно является: не запуск, не бенчмарк, а инженерный артефакт, который показывает, как расширяется конверт обслуживания Qwen4 ещё до появления самого семейства.

Это материал в формате «что нам известно на данный момент», и здесь источник значит больше, чем обычно. Пул-реквест — черновик, открыт и не смержен — vllm-project/vllm#59279, открыт 29 сентября 2026 года Сонсу Ха, программным инженером NVIDIA, и по-прежнему находится в статусе черновика. Каждое число ниже — это собственные парные измерения автора, приведённые в описании PR и сделанные на более ранней ревизии той же работы. Ничто здесь не проверено независимо, ничто здесь не вошло в релиз, а оговорка, которую прилагает автор, настолько существенна, что для неё ниже выделен отдельный раздел.

Что на самом деле меняет пул-реквест

Контекстный параллелизм декодирования — DCP — это техника обслуживания, а не изменение модели. Вместо того чтобы одна группа GPU хранила весь KV-кэш, DCP разделяет этот кэш между рангами, так что каждый ранг читает только свой срез контекста, а результаты attention объединяются между рангами в конце. Суть в ёмкости: когда кэш разделён, развёртывание может выдерживать гораздо больше одновременного трафика с длинным контекстом на том же оборудовании, и именно это ограничение становится критичным, когда каждый запрос несёт четверть миллиона токенов.

Сложность в том, что Qwen Sparse Attention — QSA — не является обычным слоем внимания. Как указано в карточке модели Qwen3.8-Flash-Next, лёгкий индексатор сжимает ключи в микроблоки с коэффициентом сжатия 4, оценивает их и сохраняет лучшие 512 блоков, что соответствует примерно 2 048 позициям токенов, тогда как финальный softmax и агрегация значений по-прежнему выполняются по несжатым K и V. Это означает, что QSA хранит больше состояния, чем KV-кэш: есть основной кэш, а также кэш селектора и вспомогательные кэши, которые поддерживает индексатор. Стандартная реализация DCP в vLLM ничего из этого не знает.

Что #59279 делает, согласно его описанию, — это знакомит DCP со специфичными для QSA частями:

• Каждый ранг читает свою часть основного KV-кэша, тогда как селектор QSA и боковые кэши остаются реплицированными между рангами, а не шардированными.

• Результаты attention объединяются между рангами после разделённого чтения.

• Селектор и основной KV-кэш хранятся в одной группе кэша, поэтому они не могут разойтись.

• Синтетическим пакетам V2 запрещено записывать боковые кэши QSA.

Эта последняя пара деталей — как раз самое интересное, если вам важна корректность, а не пропускная способность. Шардированный кэш внимания, который втихую расходится с реплицированным селектором, — это тот род багов, что проявляется как медленная деградация точности на длинном контексте, а не как падение, и в этом изменении явно оговорено, что эти двое должны идти в ногу. Автор также указывает, что использовалась помощь ИИ, и Codex указан как соавтор — об этом стоит сказать прямо, потому что в черновом PR такого рода справедливо спросить, кто что написал.

Парные числа и то, как они были получены

План тестирования достаточно конкретен, чтобы его можно было проверить, поэтому результаты заслуживают того, чтобы их цитировать. Обе ветви запускают Qwen/Qwen3.8-Flash-Next-FP8 на четырёх GPU с тензорным параллелизмом 4 и включённым параллелизмом экспертов, при --gpu-memory-utilization 0.90 с включённым кэшированием префиксов. Единственное различие между двумя ветвями — --decode-context-parallel-size: пропущен для DCP=1, установлен в 2 для DCP=2, с перезапуском между ветвями, чтобы бенчмарк начинался с холодного кэша. Нагрузка — трасса AgentX 256k при 128 пользователях в течение 900 секунд; точность — EvalScope для GSM8K плюс зафиксированный в репозитории MRCR-оценщик, запускаемый шесть раз на ветвь, при этом первый запуск после перезапуска отбрасывается.

Сообщённые изменения пропускной способности, DCP=2 по сравнению с DCP=1:

• KV-токены — 9 759 529 против 17 603 636, увеличение ёмкости кэша в 1,80 раза.

• Максимальная конкурентность — 37,23× против 67,15×, а также 1,80×.

• Запросов в секунду — 1,69 против 2,30, 1,36×.

• Входных токенов в секунду — 128 730 против 179 702, 1,40×.

• Время до первого токена — 1 869 мс против 767 мс, в 2,44 раза меньше.

• Задержка между токенами — 43,48 мс против 26,27 мс, в 1,66 раза ниже.

• Доля попаданий в кэш префиксов в установившемся режиме — 67,85 % против 88,98 %, прирост на 21,1 процентного пункта.

Точность, приведённая как среднее ± выборочное стандартное отклонение по прогонам после прогрева, была практически неизменной: агрегированный показатель MRCR 0.8630 ± 0.0005 при DCP=1 против 0.8697 ± 0.0153 при DCP=2, а GSM8K — 0.9788 ± 0.0020 против 0.9790 ± 0.0016. Образцы MRCR с 2 иглами и с 4 иглами были фиксированы на 0.9960 и 0.9906 в обеих ветвях, поэтому весь разброс от прогона к прогону исходил от образцов с 8 иглами — и один агрегированный прогон при DCP=2 набрал 0.8970, тогда как остальные четыре оказались между 0.8620 и 0.8632. Это реальный разброс, а не шум, от которого можно отмахнуться, и он указан в PR, а не сглажен.

Что эти числа не устанавливают

Оговорка содержится в тексте PR, и она немаленькая. Парные результаты AgentX и оценки точности были измерены на более ранней ревизии QSA DCP с использованием ночной сборки vLLM на основе коммита 3df4ae153eb. Финальный чистый коммит в пул-реквесте включает последующее исправление локализационного ядра QSA и прошёл точечную валидацию на B200 — но полные оценки AgentX и точности не были повторены на этом самом исходном коде. Иными словами: история о пропускной способности и поставляемый дифф — не один и тот же артефакт, и автор это признаёт.

Помимо этого, действуют обычные правила — и здесь они действуют со всей строгостью. Это числа для одной конфигурации, полученные одним участником на одной системе с четырьмя GPU. Они скорее связаны с вендором, чем нейтральны: когда участник разработки фреймворка измеряет изменение во фреймворке, это нормально и полезно, но это не независимый аудит, и ни одна третья сторона не воспроизвела этот запуск. Сегодня не существует выпущенной версии vLLM, которую можно установить и которая содержала бы это изменение, потому что изменение ещё не слито. А DCP=2 — это разбиение на две части для одной конкретной формы; эти дельты не являются обещанием того, как поведут себя DCP=4 или DCP=8, и ничто в PR этого не утверждает.

Почему PR по сервингу для ещё не выпущенной архитектуры всё ещё заслуживает вашего времени

Очевидное возражение: модели из заголовка не существует, так почему это важно? Потому что то, что настраивается, — это не Qwen 4. Это Qwen3.8-Flash-Next, и эта модель существует — Alibaba опубликовала её 24 августа 2026 года как MoE со 125 млрд параметров и 6 млрд активируемых, с таблицей n-граммных эмбеддингов на 51 млрд параметров, 4-миллиардной MTP-головой для спекулятивного декодирования, 48 слоями, организованными как двенадцать повторов трёх блоков Gated DeltaNet, за которыми следует один блок QSA, 512 экспертами, из которых 10 маршрутизируемых и 1 общий активный, и нативным контекстом в 262 144 токена, который, как указано в карточке, расширяется до 1 000 000. Это эталонная реализация архитектуры Qwen4 в открытых весах, и QSA — микроблочное разреженное внимание, которое этот пул-реквест учит DCP шардировать — является самой отличительной её частью.

То, что описывают эти числа, — это то, что происходит, когда вы перестаёте рассматривать контекст в 262K как нечто, что одна группа GPU должна удерживать целиком. Рост в 1,80× по ёмкости KV-токенов и параллелизму — это арифметика разделения кэша на две части, и это наименее удивительный результат в списке. Более интересные показатели — это показатели задержки: время до первого токена ниже в 2,44×, а межтокенная задержка ниже в 1,66× при той же предлагаемой нагрузке, плюс улучшение коэффициента попаданий в префиксный кэш в установившемся режиме на 21 пункт. Они говорят о том, что путь DCP не просто покупает ёмкость ценой задержки — в этом парном прогоне он приобрёл и то, и другое. Именно такая форма изменений важна для всех, кто обслуживает агентный трафик с очень длинными системными промптами, потому что поведение префиксного кэша при длинном контексте — это обычно то место, где пропускная способность на длинном контексте тихо умирает.

И это не изолированный патч. За ту же неделю появился целый кластер работ по движку Qwen4Exp: #59214 добавляет планы GEMM для декодирования с низкой задержкой на SM100 для конфигураций B200, #59010 добавляет нативное разрежённое prefill-ядро SM90 для пути QSA на Hopper, #58977 охватывает эмбеддинги BF16 INC PLE, а #58961 — тот, который действительно был смёржен 2026-09-28 — исправил KV-кэш профилирования, который не давали освободить представления ключей QSA. Если читать их вместе, они очерчивают контур обслуживания архитектуры Qwen4, которая строится открыто, в рантаймах, за месяцы до выхода семейства. Если вы готовитесь к Qwen 4, полезный сигнал — не дата запуска — её нет — а то, что ядра и схемы размещения кэша уже предполагают о том, как вам придётся её обслуживать.

Что вы можете назвать сегодня

Если вы хотите протестировать работу с длинным контекстом на архитектуре, о которой идёт речь в этом PR, то модель, к которой стоит обратиться, — это уровень Flash, который Alibaba реально предоставляет. Qwen3.8-Flash — промышленное развёртывание, построенное на Qwen3.8-Flash-Next, с контекстом в 1 000 000 токенов и максимальным выводом в 131 072 токена, принимающее на вход текст, изображения и видео, — уже доступна, и это один эндпоинт для модели, которая сегодня фактически работает на архитектуре Qwen4Exp, указанный как qwen/qwen3.8-flash, по цене $0,15 за миллион входных токенов и $0,47 за миллион выходных токенов, а чтение из кэша — $0,0184. Поскольку это цены из прайс-листа провайдера, передаваемые без наценки с нашей стороны, изменение цены или лимита у поставщика по этой модели доходит до вас в тот же день, когда о нём объявляют.

Две честные оговорки. Во-первых, сам Qwen3.8-Flash-Next — FP8-веса из тестового плана pull request’а, те самые, которые понадобились бы вам, чтобы локально воспроизвести любое из этих измерений, — отсутствует в нашем каталоге; обслуживаемый тариф Flash — это производственная линейка QwenCloud, а не исходный предварительный чекпойнт. Если вы хотите запустить точную конфигурацию из PR, вам придётся разворачивать её самостоятельно на четырёх GPU. Во-вторых, изменение DCP не влито, так что ничто из того, что сегодня доступно где-либо, его не использует. Обслуживаемый тариф даёт вам способ выяснить, хотя бы подходит ли ваша нагрузка по своей форме для задачи, которую решает DCP: если ваши промпты длинные, агентные и с большим объёмом префиксов, то 1,80× ёмкости и разница в кэше префиксов — это те числа, за которыми стоит следить в ваших собственных трейсах.

И если интересная для вас часть — не одна модель, а вопрос переключения — на каком уровне строить, пока линейка Qwen 4 ещё не имеет названия, — то это проблема маршрутизации, а не обслуживания, и один API для 200+ моделей — это способ сохранить возможность открытой без второго договора или изменения кода, когда семейство наконец появится.

Вопросы, заслуживающие прямого ответа

Означает ли #59279, что Qwen 4 уже вышел или вот-вот выйдет?

Нет. Этот пул-реквест посвящён архитектуре Qwen4Exp в том виде, в каком она реализована в Qwen3.8-Flash-Next, которую Alibaba выпустила 2026-08-24. Семейство Qwen 4 — Max, Flash, Plus и 27B — было названо со сцены в Apsara 2026-09-22 и внесено в корпоративную дорожную карту с линией преемников, рассчитанной на 5–10 триллионов параметров, и у него до сих пор нет карточки модели, нет весов, нет идентификатора API, нет окна контекста, нет цены и нет даты. Пул-реквест во фреймворке, добавляющий режим параллелизма в preview-архитектуру, — это шаг к тому, чтобы хорошо обслуживать Qwen 4. Это не шаг к тому, чтобы Qwen 4 существовал.

Чем параллелизм контекста декодирования отличается от тензорного параллелизма?

Они разбивают разные вещи и дают сбой по-разному. Тензорный параллелизм разбивает веса и вычисления каждого слоя между GPU, поэтому каждый ранг участвует в обработке каждого токена, но видит всю последовательность. Контекстный параллелизм декодирования разбивает KV-кэш как таковой, поэтому каждый ранг хранит и читает только срез контекста, а частичные результаты внимания затем объединяются. TP — это про то, чтобы уместить модель; DCP — про то, чтобы уместить контекст и одновременный трафик, который идёт вместе с ним. Именно это различие и делает данный PR нетривиальным: селектор и побочные кэши QSA нельзя просто шардировать так, как можно шардировать основной KV-кэш, поэтому в рамках этого изменения нужно шардировать один и реплицировать остальные, а затем доказать, что они остаются согласованными.

Если я сегодня вызову Qwen3.8-Flash-Next через хостинговый API, получу ли я уже эти цифры?

Нет, и этот разрыв состоит из трёх частей. Это изменение ещё не влито, поэтому ни один выпущенный билд vLLM его не содержит. Даже после вливания провайдер должен внедрить этот билд и выбрать работу с размером DCP больше единицы — это конфигурация обслуживания, а не значение по умолчанию. А измеренные дельты относятся к более ранней ревизии патча, а не к финальному коммиту, который, по словам автора, пока прошёл только точечную валидацию на B200. Считайте приведённые дельты хорошо документированной верхней границей того, что этот подход даёт в одной конфигурации, а не спецификацией какого-либо эндпоинта, который можно арендовать на этой неделе.

Открытый вопрос

Следить нужно не за тем, вольётся ли этот конкретный черновик, — скорее всего, в той или иной форме это произойдёт, поскольку добавляемая им работа с кэшем, специфичная для QSA, — это настоящий пробел, а не вопрос предпочтений. Следить нужно за тем, получит ли финальный коммит ту же парную оценку, что и промежуточная ревизия. Изменение в сервинге, чьи заявления о пропускной способности исходят из одной сборки, а заявления о корректности — из другой, пока представляет собой хорошо аргументированное предложение, а не измеренный результат; к тому же разброс точности на образцах MRCR с 8 иглами настолько велик, что повторный прогон на исходнике, ушедшем в поставку, был бы самым полезным, что кто-либо мог бы об этом опубликовать. До тех пор: направление читается, итог не подведён, а единственная модель с архитектурой Qwen4 в открытых весах остаётся августовской.