Qwen4-Exp QSA приходит на Ascend от Huawei: внутри опционального CANN prefill PR в SGLang

30 сентября 2026 года один контрибьютор открыл пул-реквест #41855 в SGLang под названием «[NPU] Добавить опциональное разреженное внимание CANN для QSA-префилла Qwen4-Exp», и самое интересное здесь не арифметика. Это аппаратное обеспечение. У архитектуры Qwen4Exp теперь есть написанный вручную путь разреженного внимания для ускорителя Huawei Ascend 910C, за флагом, по умолчанию отключённым, в черновом пул-реквесте, который ещё не влит, — тогда как модель, к которой относится это название архитектуры, Qwen4-Exp, никогда не публиковалась ни в каком виде. Единственный чекпоинт, который несёт эту архитектуру в открытых весах, — по-прежнему Qwen3.8-Flash-Next, превью mixture-of-experts на 125 миллиардов параметров, выпущенное вендором 24 августа 2026 года на Hugging Face, и в карточке которого архитектура фактически указана как qwen4_exp. Сама Qwen 4 — уровни Max, Flash, Plus и 27B, названные вендором на своей конференции Apsara 22 сентября 2026 года, — по-прежнему не имеет ни весов, ни идентификатора, ни цены, ни даты. Так что это материал в формате «что нам известно на данный момент» об инженерном артефакте, а не о запуске: ещё один стек обслуживания вендора тихо решает, что невыпущенную архитектуру стоит поддержать заранее.

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

Изменение намеренно небольшое и намеренно узкое. Пять файлов, один коммит, +355 строк относительно главной ветки на коммите b87a241, с меткой SGLang npu. Автор, w1ida, сразу заявляет о намерении: опциональный путь основного внимания CANN для Qwen4-Exp QSA eager prefill, построенный на torch_npu.npu_sparse_flash_attention, при этом индексатор, выбор Top-K, бюджет токенов и содержимое KV-кэша остались в точности такими, как были.

Приём, который он использует, чтобы этого достичь, заслуживает отдельного абзаца, потому что он объясняет, почему это адаптер компоновки, а не новое ядро внимания. Для уже повёрнутых Q и K этот путь упаковывает кэш как C = [K, V], а запрос как Q' = [Q, 0]. Произведение Q' @ C.T тогда равно Q @ K.T, и поскольку дополненный запрос ничего не вносит, softmax(scale * Q' @ C.T) @ C возвращает [P @ K, P @ V], сложенные вместе — так что половину с V можно вырезать. По словам самого автора, это «эмбеддинг компоновки внимания, а не изменение внимания модели или низкоранговое сжатие KV». Каждая голова KV становится независимым батчем в нативной компоновке MLA, исходный масштаб D256 сохраняется, а вспомогательный RoPE обнуляется.

Операционные детали важны так же, как и математика:

• Включение — SGLANG_NPU_QSA_NATIVE_PREFILL=1, по умолчанию выключено. Только обычный ForwardMode.EXTEND включает эту функцию; декодирование, спекулятивные режимы, смешанный forward и захват графа — все остаются на существующих путях, а захват графа полностью обходит адаптер.

• Аппаратное обеспечение и dtype — BF16 с размерностью головы 256, Ascend 910C (Ascend910_93*), протестировано с CANN 9.0 и torch-npu 2.10. Любой неподдерживаемый dtype или форма без предупреждения возвращается к эталонному пути.

• Формы голов — поддерживаемые локальные (голов Q, голов KV) пары: (16,2), (24,2), (12,1), (6,1) и (3,1). CANN наотрез отвергает соотношение query/KV, равное 12 — его тайлер принимает только степени двойки — поэтому головы дополняются 12→16, 6→8 или 3→4, а добавленные выходы отбрасываются. Это самый явный признак во всём PR того, что аппаратное обеспечение не проектировалось с учётом соотношений голов для разреженного внимания, и адаптер поглощает это несоответствие, вместо того чтобы модель меняла форму под него.

• Границы размеров — упаковывается только указанная физическая область кэша, с ограничением в 262 144 токена, что, по расчётам автора, составляет не более 512 МиБ для упакованного тензора K/V в BF16 при двух KV-головах. Внутренний -1 паддинг обнаруживается и направляется в резервный путь, поскольку CANN требует непрерывных допустимых слотов; полностью маскированные строки сохраняют существующее соглашение о нулевом выводе.

• Почему только предзаполнение — проверка экстента и раскладки копирует два скаляра на хост, а временные копии вместе с нативным рабочим пространством занимают память. Именно из-за этой синхронизации этот путь ограничен предзаполнением в режиме eager и не используется во время захвата.

Девять пройденных тестов и показатель скорости, который пришёл не из этой ветки

Доказательства корректности конкретны и воспроизводимы — это больше, чем даёт большинство PR-ов для ядер. Автор сообщает о 9 пройденных тестах за 40,772 секунды на Ascend 910C (Ascend910_9362) с CANN 9.0 и torch-npu 2.10.0, при этом контрольная точка не требуется: ненулевые случайные BF16 Q/K/V против эталона FP32 на CPU, вычисленного из тех же входных данных BF16, неупорядоченные физические слоты при ширинах 1/63/64/65/2051, масштабы по умолчанию и заданные явно, полностью замаскированные строки, нулевые строки, нулевая ширина выборки, несмежные тензоры, остатки причинного хвоста от 0 до 3 при коэффициенте сжатия 4, физическое отображение двух запросов с общим префиксом, повторное использование содержимого кэша и локальные формы голов Flash-Next при 1 и 257 строках запросов.

Основной сценарий — длинный prefill: 7 810 токенов запроса против кэша на 65 536 токенов с 2 051 выбранными слотами на запрос, все выходы конечны, а восемь выборочных строк сравнены с эталоном FP32. Наблюдаемая относительная ошибка L2 достигла 0,209 % в случаях с малой формой головы и 0,231 % на выборочных строках длинного prefill, при тестовых порогах atol=0.025, rtol=0.025 и относительной L2 менее 0,008, при этом пустые строки должны быть строго равны нулю. Пиковый выделенный объём памяти NPU для этого запуска указан как 1 042,7 MiB — и автор обозначает его как метрику аллокатора PyTorch, а не HBM на плате и не память всей модели, и это именно та правильная оговорка, которую стоит сделать.

А есть ещё число, которое будут цитировать, хотя не следовало бы. В теле PR приводится таблица скорости, показывающая существующий путь локального внимания на уровне 2,270.79 новых токенов в секунду и нативное упакованное основное внимание на 3,890.06 — прирост 1.713× / +71.3%, при этом среднее время до первого токена снижается с 3.109 с до 1.812 с. Автор прямо указывает, что это исторические измерения прототипа, выполненные 2026-09-29 на адаптированном Whittle-Next-26B-A3B чекпойнте, запущенном при TP1 с весами W8A8 и вниманием BF16 на 910C под CANN 9.0, с использованием официального sglang.bench_serving стенда при параллелизме 1 с шестью запросами, по одному выходному токену каждый, и 36,096 кэшированных префиксных токенов исключены из пропускной способности по новым токенам. Они не являются бенчмарком вышестоящей ветки в PR, исходные JSON-артефакты обслуживания отсутствуют в рабочей копии, а более поздние локальные результаты около 5,000 токенов в секунду использовали дополнительную работу нативного индексатора и block4, которая явно не относится к этому изменению. Автор также отмечает, что веса индексатора адаптированного чекпойнта инертны, а его бюджет отличается от исходного, поэтому ничто из этого не является доказательством корректности индексатора или качества генерации при полном бюджете.

Одно уточнение по названию, поскольку оно собьёт с толку любого, кто будет искать этот чекпойнт: модель, использованная в бенчмарке, — это собственный адаптированный артефакт контрибьютора. Отдельно: «Whittle-Next» — это также название публичной серии MoE-файнтюнов на основе Qwen3.8, опубликованной сторонним аккаунтом Hugging Face, включая вариант 26B-A3B, загруженный в сентябре. Это не та модель Qwen4Exp, на которую нацелен данный PR, и их не следует воспринимать как конфигурацию бенчмарка, стоящую за показателем 1.713×.

Ещё две оговорки исходят от автора, а не от меня. Полноценная интеграция с обслуживанием, распределённый тензорный параллелизм и полная модель Qwen3.8-Flash-Next не были проверены в этой ветке; контрибьютор говорит, что намеренно оставляет её в статусе черновика, пока обсуждается вопрос интеграции и зависимостей, и даже спрашивает в теле PR, должен ли адаптер находиться в SGLang или в отдельном sgl-kernel-npu репозитории. С CI тоже не всё гладко — в блоке состояния в теле PR показаны сбои в PR Test (Base), PR Test (Extra) и в запуске AMD ROCm 10. Описанная выше корректность относится к уровню операторов; в PR ничего не утверждается о сквозной точности или пропускной способности на интегрированном стеке.

Почему QSA — неудобная часть, в цифрах

Qwen Sparse Attention — это не обычный слой внимания, и опубликованная конфигурация показывает, почему производителю ускорителей приходится писать для него специализированный путь. Из конфигурации Qwen3.8-Flash-Next: 48 слоёв, организованных как двенадцать повторов трёх блоков Gated DeltaNet, за которыми следует один блок полного внимания, full_attention_interval 4, размер скрытого слоя — 2 560, размерность головы внимания — 256, 24 головы запросов против 2 KV-голов, размерность RoPE — 64. Индексатор, который делает внимание разреженным, представляет собой многозапросную структуру, в которой 4 головы запросов совместно используют 1 голову ключей, размерность головы — 128, коэффициент сжатия — 4, а бюджет — 2 048 выбранных микроблоков на запрос.

Именно этот бюджет PR и оставляет фиксированным. Размер разреженного блока остаётся 1, разреженный режим остаётся 0, режим внимания остаётся 2, а интерфейс выбранных токенов не затрагивается; нативные оптимизации индексатора и block4 явно вне рамок. Так что это адаптер, прикрученный под существующий механизм выбора, а не повторная реализация QSA — что также объясняет, почему автор может убедительно утверждать, что содержимое KV-кэша не изменилось.

В карточке модели прямо изложен замысел дизайна: вместо выбора отдельных токенов QSA работает на уровне микроблоков, чтобы сократить задержку при длинном контексте, и именно эта гранулярность микроблоков вместе с сопутствующим ей реплицированным состоянием селектора как раз и не ложится без проблем на универсальное ядро paged-attention ни на кремнии одного, ни на кремнии другого производителя.

Какое место это занимает в развёртывании сервиса Qwen4Exp

Если смотреть в отдельности, один черновой PR по одному ускорителю — это курьёз. Если же смотреть на фоне остального сентября, это четвёртая или пятая доска платформы, которая собирается публично ещё до того, как появится семейство, которому она служит:

• Архитектура в открытых весах — Qwen3.8-Flash-Next, 2026-08-24, MoE на 125 млрд параметров с 6 млрд активируемых, таблица n-граммных эмбеддингов на 51 млрд параметров и MTP-голова на 4 млрд параметров, с указанием model_type: qwen4_exp и architectures Qwen4ExpForConditionalGeneration.

• Сторона vLLM — #53909, PR «qwen4 fuse op», добавляющий ядра HyperConnection, QSA и PLE, всё ещё открыт и не влит с 2026-08-26; #59279, который добавляет параллелизм контекста декодирования в тот же путь QSA, черновик, открытый 2026-09-29; и работа по выгрузке PLE, вошедшая в кодовую базу в течение сентября.

• Сторона SGLang — #38642 для захвата скрытых состояний DFlash, #39548 для выгрузки PLE на CPU в Qwen4-Exp на Ascend, #40235 добавляет хост-стейджинг для файловой PLE-таблицы, и теперь #41855 для пути внимания Ascend.

• Линия включения NPU — sglang #37570, добавляющий Qwen3.8-Flash-Next в SGLang на NPU с воспроизведением графа, MTP и ядрами Triton (открыт 2026-09-02, всё ещё открыт, +2 590 строк в 20 файлах), и sgl-kernel-npu #807 для сопутствующих ядер Triton (открыт 2026-09-17, +4 643 строки). Оба от одного и того же контрибьютора. #41855 — это слой внимания, который находится внутри этих более масштабных усилий по включению.

Два наблюдения, на которые читатель может опереться. Во-первых, вся история Ascend Qwen4Exp держится на очень небольшом числе контрибьюторов — PR-ы по включению поддержки и репозиторий ядер делят одного автора, а адаптер внимания — другой. Такая концентрация — справедливая оценка того, насколько обслуживание Ascend Qwen4Exp далеко от того, чтобы быть поддерживаемым продуктовым путём, а не экспериментом. Во-вторых, узкое место на уровне ядер не зависит от вендора: две проблемы SGLang, зарегистрированные 2026-08-28, описывают декодирование Qwen4Exp на NVIDIA DGX Spark, где доминирует время выполнения ядер QSA, PLE и Gated DeltaNet, и где KV-кэш NVFP4, согласно измерениям, замедлял декодирование примерно на 29% по сравнению с fp8_e4m3. Слои внимания и эмбеддингов в этой архитектуре — сложная часть повсюду.

Что это не означает

Это не означает, что Qwen 4 вышла или близка к выходу. Семейство Qwen 4, которое Alibaba назвала 22 сентября 2026 года — Max, Flash, Plus и уровень 27B — остаётся дорожной картой без карточки модели, без весов, без идентификатора API, без контекстного окна, без лицензии и без цены. Адаптер фреймворка, нацеленный на внутреннее название архитектуры, — это шаг к тому, чтобы однажды обеспечить качественное обслуживание этого семейства; это не шаг к тому, чтобы семейство существовало.

Это не значит, что вы можете запустить это уже сегодня. PR — это черновик с падающим CI и без даты слияния. Даже после слияния этому пути требуются Ascend 910C, BF16, CANN 9.0 с torch-npu 2.10 и одна из пяти конкретных локальных форм голов, и он включается по желанию — то есть при развёртывании его нужно явно выбрать. Автор также не стал заявлять о валидации на уровне сервера, а именно она действительно показала бы, выдерживает ли это реальный батчинг.

И это не означает, что Qwen3.8-Flash-Next — поддерживаемый продукт на Ascend или где-либо ещё в поставляемой сборке движка. Пути Qwen4Exp в обоих основных открытых рантаймах существуют только в виде невлитых пул-реквестов. Нет ни одной выпущенной версии SGLang или vLLM, которую можно установить и которая бы нативно обслуживала эту архитектуру, — удобство хостируемого эндпоинта в стиле FastAPI — это не то же самое, что ядро, которое можно запустить самостоятельно, и разрыв между ними — ровно то, для чего нужны PR вроде этого.

Что вы действительно можете вызвать, пока ждёте

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

Две честные оговорки — и это те же самые две, которые несут родственные разборы по этой архитектуре. Сам Qwen3.8-Flash-Next — предварительный чекпоинт в FP8, то, что понадобилось бы вам, чтобы локально воспроизвести любые из этих измерений ядер, — отсутствует в нашем каталоге; обслуживаемый уровень Flash — это производственное развёртывание, собранное на его основе, а не исходный предварительный артефакт. И ничего из описанной выше работы по Ascend или DCP не существует ни в чём, что можно было бы вызвать, потому что ни одна её часть не была смерджена. Что обслуживаемый уровень действительно даёт, так это дешёвый способ выяснить, заточены ли ваши рабочие нагрузки под задачу, которую решают эти ядра, — длинные, насыщенные префиксами агентные промпты в условиях очень длинного контекста. Если да, то пропускная способность и поведение кэша, которые вы там наблюдаете, — это то же поведение, которое стек обслуживания Qwen 4 будет настроен защищать.

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

Три вопроса, на которые стоит ответить прямо.

Означает ли SGLang #41855, что Qwen 4 уже вышел или доступен для предварительного просмотра?

Нет, и по обоим пунктам. Этот пул-реквест нацелен на архитектуру Qwen4Exp в том виде, в каком она реализована в Qwen3.8-Flash-Next, которую Alibaba выпустила 24 августа 2026 года. Он не затрагивает веса Qwen 4, и ни у одного уровня Qwen 4 нет весов, которые можно было бы затронуть. Сигнал, который здесь следует прочитать, касается мощности обслуживания для preview-архитектуры, а не доступности семейства.

Если в карточке модели указано qwen4_exp, то это Qwen 4?

Нет — и это ловушка именования во всей этой истории. qwen4_exp — это внутренний идентификатор архитектуры, и именно его вы найдёте в config.json для Qwen3.8-Flash-Next и его FP8-собрата. «Экспериментальная архитектура» — здесь ключевое слово: веса опубликованы, архитектура реальна, а модель — это превью того, на чём, как ожидается, будет строиться семейство Qwen 4. Поиск по идентификатору и найденный PR в SGLang или vLLM с Qwen4Exp в заголовке говорят о работе над движком, а не о релизе.

Это история противостояния Ascend и NVIDIA?

Не совсем. Тот же путь внимания потребовал специализированного адаптера и на стороне NVIDIA — параллелизм контекста декодирования для QSA в vLLM и нативное разреженное ядро prefill для Hopper, — а проблемы DGX Spark показывают, что время работы ядер QSA, PLE и Gated DeltaNet и там тоже доминирует при декодировании. Микроблочный индексатор QSA и его реплицированное состояние селектора — это просто не то, что предполагают универсальные ядра paged-attention. Вклад Ascend в эту картину — более жёсткое ограничение: тайлер по соотношению голов, который принимает только степени двойки, что вынуждает добавлять паддинг, который адаптеру приходится скрывать.

То, за чем стоит следить

Дело не в том, будет ли это объединено. Адаптер честно признаёт, что он адаптер, тесты корректности воспроизводимы без контрольной точки, и автор обозначил вопрос интеграции, а не сделал вид, что он решён. Следить нужно за тем, что произойдёт после того, как линия включения NPU и этот путь внимания будут объединены, — получит ли интегрированная ветка сквозной прогон, которого не было ни у одного из них, на реальном батчинге с полной моделью, а не на локальных тензорах формы головы. Цифра 1.713× — это та, что будет ходить по рукам, и она вычислена на другой сборке, на адаптированной контрольной точке, с инертным индексатором. Измеренное число на готовом стеке стоило бы значительно больше, чем историческое.

До тех пор честное резюме — то, которого придерживается сам PR: арифметика сходится, флаг по умолчанию отключён, CI красный, а модель из заголовка всё ещё не существует.