Утечка Qwen 4: SGLang шардирует префилл Qwen4Exp для ускорения TTFT на 18% и возврата гибибайта на каждый GPU

Пул-реквест, открытый в репозитории SGLang сегодня утром, 2026-10-08, в 03:47 UTC, обещает нечто такое, чего пока не дал ни один анонс Qwen 4: цифру. Он озаглавлен feat(qwen4-exp): включить параллелизм последовательностей LayerNorm для GR и PLE, и на четырёх GPU H20, запускающих открытый по весам чекпойнт Qwen3.8-Flash-Next в FP8, его автор сообщает об улучшении времени до первого токена на 17,7–18,4 % при длине входа 32K и на 14,6–14,7 % при длине входа 235K, о примерно гигабайте пиковой памяти, высвобождаемом на каждый GPU, и о до 22 % большей пропускной способности по входу. Qwen 4 сам по себе — семейство, которое вендор назвал, но не выпустил на конференции Apsara в Ханчжоу 2026-09-22, — всё ещё не выпущен: без весов, без идентификатора и без цены. Единственная модель, которая сегодня реализует архитектуру Qwen4Exp, — это Qwen3.8-Flash-Next, опубликованная 2026-08-26, а её управляемый собрат Qwen3.8-Flash — это версия, до которой вызывающий API действительно может добраться. Так что читайте дальнейшее ровно как то, чем оно является: парные измерения одного инженера, приложенные к открытому черновому неслитому пул-реквесту, о границах обслуживания семейства моделей, которого пока не существует.

Сначала об источниках, потому что это утечка, и это различие действительно важно. Сигнал — sgl-project/sglang#43048, открыт 2026-10-08 в 03:47 UTC GitHub-аккаунтом shiyang814-cpu, последнее изменение — 03:55 UTC, и по-прежнему помечен как черновик, без зафиксированного одобряющего ревью и без слияния. Он меняет шесть файлов — два тестовых файла, файл модели Qwen4Exp, модуль LayerNorm-SP, фабрику границ слоёв и хук группы аргументов — на +345 и −50 строк. Каждая приведённая ниже цифра производительности взята из описания PR, является собственным парным измерением автора OFF/ON и никем не воспроизведена. Три запуска CI на ревизии на конце ветки помечены как неуспешные. Здесь нет ничего, что уже выпущено.

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

Параллелизм по последовательности — это не изменение модели и не новая возможность. Это перекоммутация того, где несколько слоёв выполняют свою арифметику. Его происхождение восходит к параллелизму по последовательности в стиле Megatron — приёму из arXiv:2205.05198 — и SGLang уже поставляет его: собственный docstring модуля объясняет механизм, который он переиспользует, а именно что при чистом тензорном параллелизме параллельный по строкам all_reduce алгебраически является reduce_scatter, за которым следует all_gather. Поскольку эти две коллективные операции перемещают ровно столько же байтов, сколько единственный all_reduce, который они заменяют, такое разделение операции вообще не требует дополнительного объёма коммуникации. Что это даёт — свободу позволить областям нормализации и остаточных связей работать на сегментированных по последовательности активациях — каждый тензорно-параллельный ранг хранит одну 1/tp-ю долю строк токенов — что сокращает объём временной памяти активаций, который нужно удерживать при предзаполнении длинного контекста.

Этот конкретный pull request расширяет существующий путь с архитектуры, на которой он был проверен, на архитектуру Qwen4Exp. Во время prefill активации Gated Residual и Per-Layer Embedding остаются шардированными по измерению токенов внутри TP-группы. Перед attention, перед GDN, перед QSA и перед запуском блока Mixture-of-Experts полные строки токенов собираются обратно через all-gather, существующее тензорно-параллельное вычисление по полным строкам выполняется без изменений за общим fallback, а затем reduce-scatter суммирует частичные вклады и восстанавливает шард каждого ранга. Decode вообще не затрагивает новый путь. Функция доступна через уже существующую опцию — --enable-layernorm-sp — без специфичного для Qwen4Exp флага, и при отсутствии флага код ведёт себя в точности так же, как раньше.

Почему Qwen4Exp — это архитектура, которой это нужно

Причина, по которой это важно именно для Qwen4Exp, а не в равной степени для каждой модели, кроется в самом дизайне архитектуры. Qwen3.8-Flash-Next применяет Gated Residual проекции ко всем токенным строкам в каждом декодерном слое — конфигурация объявляет четыре residual-потока и ранг узкого места 320 по всем 48 слоям — а Per-Layer Embedding добавляет вторую реплицированную проекцию, применяемую к каждой строке токена, поверх этого. При тензорном параллелизме обе эти операции дублируются одинаково на каждом ранге, поскольку у них нет собственной весовой матрицы, шардированной по TP, которая заставила бы их разделиться. Шардирование их токенного измерения напрямую устраняет дублируемую работу, и, как сказано в разделе мотивации PR, это происходит с сохранением существующей тензорно-параллельной раскладки и семантики редукции для внимания, GDN/QSA и MoE — а именно это делает изменение безопасным, а не остроумным.

Стоит прямо сказать, что это значит для читателя. Интересное в этом PR не то, что SGLang становится быстрее. А то, что архитектура Qwen4 несёт послойные затраты, которые масштабируются с количеством токенов, а не с количеством параметров, и именно эти затраты становятся проблемой при длинных префиллах. Это отпечаток дизайна, и это то, о чём в спецификации никогда не пишут.

Измеренные дельты

Бенчмарк автора фиксирует одну конфигурацию и переключает флаг: четыре GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, тензорный параллелизм 4 и экспертный параллелизм 4, размер chunked prefill 8192, бэкенды FlashInfer для линейного внимания на этапах prefill и decode, одна и та же конфигурация сервера для OFF и ON, чередующиеся перезапуски сервиса OFF → ON → OFF → ON, а также фиксированные входные токены с запросами прогрева. Каждый показатель ниже получен из этой конфигурации и не прошёл аудит:

• Входные данные 32K, размер пакета 1 — TTFT улучшился на 17,72–18,36%, сквозная задержка — примерно на 16%, пропускная способность ввода — примерно на 20%

• Вход 235K, размер батча 1 — TTFT улучшился на 14,63–14,71%, сквозная задержка — около 14%, пропускная способность входных данных — около 17%

• Входные данные 32K, размер пакета 4 — TTFT улучшился на 18,74 %, сквозная задержка — на 18,14 %, пропускная способность входных данных — на 22,14 %

• Пиковое потребление памяти — примерно на 1,0 ГиБ меньше на каждый GPU

• Decode, размер батча 1 — время на выходной токен практически не изменилось

Последнюю строку стоит перечитать дважды, и автор откровенно объясняет почему: эта оптимизация включена только для префилла, так что однопоточный декод ничего от неё не получает. Улучшение времени на токен при батче из 4, там где оно проявляется, отражает сокращение задержек планирования из-за одновременных длинных префиллов, а не более быстрый кернел декодирования. Если вы надеялись, что это история про пропускную способность, то это не так — это история про задержку до первого токена и память, и именно эти два ограничения решают, можно ли вообще обслужить запрос в 235 тыс. токенов.

Баг вёрстки, который им пришлось исправить в первую очередь

Самая информативная часть пул-реквеста — не таблица ускорения. Это раздел о физической компоновке строк PLE, потому что он показывает, что стек сервинга Qwen4Exp всё ещё делает неправильно.

Per-Layer Embedding работает с фиксированным физическим бакетом CUDA-графа, при этом только префикс строк в этом бакете содержит реальные токены. Поэтому паддинг должен применяться до того, как последовательность будет шардирована, а не после. В последнем чанке запроса на 235K токенов числа автора таковы: 5 624 обработанных токена внутри физического бакета на 8 192 строки при TP 4, и единственно правильная раскладка — ранг 0 содержит 2 048 строк, ранг 1 содержит 2 048 валидных строк, ранг содержит 1 528 валидных строк плюс 520 строк паддинга, а ранг 3 содержит 2 048 строк паддинга. Если сначала шардировать 5 624 обработанные строки — очевидная реализация — паддинг вставляется между глобально непрерывными валидными диапазонами и портит результат. Автор отмечает, что реальный тест OFF/ON на 235K дал идентичный жадный вывод из 16 токенов только после того, как эта раскладка была.

Это мелкая деталь с большими последствиями. Путь PLE в SGLang был добавлен настолько недавно, что баг с порядком токенов такого рода всё ещё мог проявиться, а человек, который его нашёл, писал расширение для sequence-parallel. Поддержка сервинга этой архитектуры с первого дня ещё не завершена; её активно создают — публично, силами контрибьюторов, по одной раскладке за раз.

Чего это вам стоит: ограничения

Флаг, который помогает лишь некоторым развёртываниям, полезен только тогда, когда известно, каким именно. В PR явно указаны его требования, а конфигурации, не соответствующие им, вызывают ошибку при валидации аргументов, а не деградируют молча:

• Размер тензорного параллелизма должен быть больше 1 — развёртывание на одном GPU ничего не даёт, поскольку нет ранга, по которому можно было бы шардировать данные

• Размер экспертного параллелизма должен быть равен размеру тензорного параллелизма

• Размер параллелизма конвейера должен быть равен 1

• Внимание с параллелизмом по данным должно быть отключено

• Спекулятивное декодирование должно быть отключено

Последнее ограничение — то, за которым стоит реальное решение. Для разреженной модели, активирующей около 6B параметров на токен, спекулятивное декодирование — один из немногих рычагов, ускоряющих декодирование, и эта функция явно отключает этот рычаг в обмен на выигрыш в prefill. Если ваша рабочая нагрузка — длинный промпт и короткий вывод (анализ документов и кодовой базы, суммаризация видео, однократное чтение большого контекста), такой размен однозначно выгоден. Если ваша рабочая нагрузка — короткий промпт и длинная генерация, вы отказываетесь от того, что вам помогало, и покупаете метрику, которая к вам не применима. Требование равенства expert-parallel и tensor-parallel — это второе, на что стоит обратить внимание: оно означает, что геометрия шардирования moe должна точно совпадать с геометрией TP, что исключает ряд в остальном разумных многоузловых конфигураций.

Что это говорит о сроках выхода Qwen 4

Прочитайте diff иначе — и вы получите календарь. Модуль LayerNorm-SP в SGLang в основной ветке на сегодняшний день несёт явный список разрешённых архитектур, для которых эта функция была проверена, и на момент написания этот список содержит ровно одну запись, Qwen3ForCausalLM — любая другая архитектура отклоняется при создании, если вы передадите этот флаг. Добавление Qwen4Exp в этот путь — тем самым не доработка зрелой абстракции; это первый случай, когда архитектура Qwen4 была подключена к оптимизации, которая появилась на несколько поколений раньше неё.

Сопоставьте это с публичными данными — и картина сходится. 22 сентября 2026 года производитель объявил, что Qwen 4 находится в обучении, и анонсировал четыре названия уровней — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus и Qwen 4 27B — не приложив к ним никаких спецификаций. Открытая по весам предварительная версия с той же архитектурой, Qwen3.8-Flash-Next, доступна для скачивания с 26 августа 2026 года. То, что происходит за три недели с тех пор, — ровно то, чего следует ожидать между «в обучении» и «запуском»: авторы движков обкатывают среду выполнения, чтобы поддержка в день выхода была реальной, а не номинальной. Pull request, который заставляет оптимизацию сервинга работать на этой архитектуре, открытый утром 8 октября 2026 года и всё ещё находящийся в черновике, — лучший сигнал о том, насколько Qwen 4 близок к тому, чтобы его можно было обслуживать, чем любая дата, которую кто-либо называл. И это, подчеркнём, вовсе не дата релиза: флаг по умолчанию отключён, изменение не смерджено, а модель, на которой оно проводит бенчмарки, — это предварительная версия, а не Qwen 4.

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

Ничто из этого не меняет того, что реально доступно сегодня днём. Qwen3.8-Flash-Next существует, его веса лежат на Hugging Face, и вы можете развернуть его у себя — но в нашем каталоге его нет, и мы не будем делать вид, что это не так. Уровень, который мы действительно предоставляем, — это qwen/qwen3.8-flash, управляемый собрат, работающий на той же архитектуре Qwen4-preview с контекстным окном в 1 млн токенов и поддержкой текста, изображений и видео, по цене $0,15 за миллион входных токенов, $0,47 за миллион выходных и $0,0184 за миллион чтений из кэша. Это прайс-листовая цена, передаваемая с 0% наценкой, поэтому когда поставщик меняет её, число в вашем счёте меняется в тот же день, а не когда посредник в очередной раз опубликует таблицу.

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

Отсюда стоит следить за двумя вещами, и ни одну из них мы не можем предсказать. Первая — будет ли это вообще смёржено: это черновик с тремя неудачными прогонами CI на изменении, затрагивающем шесть файлов, от аккаунта контрибьютора без прежней истории в репозитории, а подвижность работы над лимитом строк PLE говорит о том, что автор всё ещё продолжает итерации. Список разрешённых растёт — если Qwen4Exp присоединится к Qwen3ForCausalLM как валидированная архитектура, то это перестаёт быть утечкой и становится способом по умолчанию, с помощью которого модель семейства Qwen4 обслуживается на длинном контексте. Пока не произойдёт одно из этих событий, относитесь к 18% как к обещанию о том, куда движется среда выполнения, а не как к числу, которое можно арендовать.