Когда крупная лаборатория молчит, о новой модели приходится узнавать по косвенным уликам: строке в таблице идентификаторов, незавершённому запросу на слияние, названию файла в чужом репозитории. С Qwen4 вышло именно так. Официально Alibaba сообщила одно: модель в обучении. Неофициально на конференции Apsara в Амстердаме 29 октября от технического директора Alibaba Cloud Фэйфэй Ли, по пересказам участников, прозвучал срок в одну неделю, а 6 ноября в официальном аккаунте команды Qwen появился загадочный тизер. На 7 ноября ни весов, ни карточки модели, ни цен нет. Зато есть открытое превью архитектуры, Qwen3.8 Flash Next, и россыпь следов в коде. Ниже разобрано, что из этого можно считать надёжным, что оказалось слухом и как заранее подготовить стек, чтобы в день выхода менять только имя модели.
Срок выхода Qwen4 не подтверждён, тизер вышел 6 ноября, а весов и карточки модели до сих пор нет
Официальная картина укладывается в три строки. 22 сентября на конференции Apsara компания в пресс-релизе назвала Qwen4 моделью, которая находится в обучении. Названия уровней в релиз не вошли, их озвучили на сцене: Max, Flash, Plus и 27B, без параметров, дат и размеров контекста. О том, будут ли открыты веса, не сказано ничего.
Всё остальное пришло из пересказов. Сроком в одну неделю заявление в Амстердаме 29 октября запомнили не все одинаково: в одних источниках звучит "на следующей неделе", в других "в течение недели". Расхождение в самих словах подсказывает, как относиться к такой цитате. Письменных материалов с датой у компании нет, а два предыдущих ожидаемых окна, сентябрьское и от октября до начала ноября, прошли без выхода.
В пятницу 6 ноября команда опубликовала тизер: птицы над тёмным морем, чей строй складывается в силуэт рыбы, фраза из древнекитайского трактата с пропущенным последним иероглифом и короткая английская строка о том, что превращение начинается. Пропущенный знак угадывается легко: речь о Куне, гигантской рыбе из книги Чжуан-цзы, которая превращается в птицу Пэн. Названия модели, даты и цифр в тизере нет. Внимательные комментаторы замечают, что слово Qwen4 в этой истории добавляют заголовки и подписи к картинке, а не сам плакат.
Итог на 7 ноября сухой: карточки модели, весов, идентификатора в API, цен и лицензии для Qwen4 нет. Единственное, что можно скачать и запустить, это превью архитектуры Qwen3.8 Flash Next. О нём и пойдёт разговор дальше.
Превью Qwen3.8 Flash Next показывает архитектуру, на которой, по словам авторов, строится Qwen4
Превью появилось в открытом доступе в конце августа 2026 года под лицензией qwen-community-1.0. В карточке оно названо экспериментальным превью архитектуры, которая ляжет в основу Qwen4. Здесь нужна оговорка: Alibaba не подтверждала, что какой-либо уровень Qwen4 унаследует эту схему целиком. Все цифры ниже - заявления самих авторов или разборы сообщества.
Модель мультимодальная и построена как сверхразреженная смесь экспертов: 125 миллиардов параметров в сумме и около 6 миллиардов активных на каждый токен. Арифметика простая: 6 разделить на 125 даёт 4,8 процента, то есть на токен работает меньше двадцатой части экспертного тела. Точное число экспертов и ширину маршрутизации в проверенных источниках найти не удалось, поэтому здесь они не называются.
Слои устроены по схеме три к одному. Три слоя из каждых четырёх используют Gated DeltaNet - вариант линейного внимания, который сжимает историю в состояние фиксированного размера. Каждый четвёртый слой - Qwen Sparse Attention, разреженное внимание для дальнего поиска. Идея знакомая: растущий кэш держит только четверть слоёв, как в трибридной схеме LFM3, где глобальных слоёв шесть из двадцати четырёх. Общее число слоёв в проверенных источниках не указано, поэтому точную раскладку по типам назвать нельзя.
Три детали дополняют картину. Первая - четыре параллельные ветки остаточных связей с вентилями вместо одного потока: слой сам решает, откуда читать и куда писать. Вторая - встроенный модуль многотокенного предсказания, MTP, для спекулятивного декодирования. Третья и главная для железа - таблица эмбеддингов по сочетаниям токенов на 51 миллиард параметров, которая подмешивается в модель через слой PLE. С ней суммарный размер доходит до 176 миллиардов. Родной контекст составляет 262 144 токена, а до миллиона его растягивают через YaRN, причём авторы рецепта советуют сначала проверить качество на коротких контекстах.
Следы в коде говорят меньше, чем пишут в пересказах, а запрос на слияние в vLLM показывает лишь архитектуру превью
Громче всего прозвучал запрос на слияние в vLLM под названием "Add qwen4 fuse op". В пересказах он выглядит как утечка архитектуры накануне анонса и даже как уже принятая правка. Проверка по первоисточнику даёт скромную картину. Запрос с номером 53909 открыт 26 августа 2026 года из чужого форка и закрыт 14 октября без слияния. Сопровождающий проекта просил микробенчмарки и сквозную проверку точности, а в закрывающем комментарии написал, что в проекте уже есть более удачные ядра. Утверждение про слияние неверно: в код vLLM этот запрос не попал.
Содержимое при этом информативно. В нём три ядра для HyperConnection, то есть для вентильных остаточных связей, три ядра для QSA с обёртками над вендорскими реализациями, ядра сбора состояний и маскированной записи для PLE и 13 проходящих тестов. Защитные проверки на хосте устроены так, что при неподходящих условиях код падает с ошибкой, а не тихо переключается на общий путь Torch. Но слово qwen4 есть только в заголовке, а в описании названо превью Qwen3.8 Flash Next. Связь между операциями и Qwen4 остаётся чтением, а не заявлением авторов. Ядра подтверждают архитектуру превью, и больше ничего.
Второй след лежит в репозитории инструмента qwen-code. В слияние от 28 октября попали идентификаторы qwen4-max, qwen4-plus и qwen4-coder-plus с контекстом в миллион токенов. В описании запроса прямо сказано, что реальный адрес Qwen4 не вызывался, а размер окна не подтверждён. Это подсказка о том, какие имена готовятся, но не доказательство готовности.
Полезно держать в голове лестницу надёжности: письменное заявление компании, карточка модели, слитый код проекта, открытый запрос, комментарий в обсуждении, пересказ в прессе. Каждая следующая ступень ненадёжнее предыдущей, а закрытый без слияния запрос стоит ниже слитого. Проверять такие следы можно самостоятельно тремя командами:
gh search prs qwen4 --repo vllm-project/vllm --limit 20
git log --all --oneline -S"qwen4" -- vllm/
grep -rn "qwen4" --include="*.py" --include="*.json" .
Когда у модели появится конфигурация, первым делом стоит сверить поля про слои и экспертов с конфигурацией превью. У мультимодальных моделей они могут лежать во вложенном разделе text_config, поэтому простой фильтр по ключам выглядит так:
python3 -c "import json;c=json.load(open('config.json'));print({k:v for k,v in c.items() if 'expert' in k or 'layer' in k})"
Таблица по сочетаниям токенов может жить в оперативной памяти, потому что её строки известны заранее
Главная идея архитектуры - развести два вида памяти. Эксперты выбираются маршрутизатором после того, как слой увидел скрытое состояние, поэтому заранее неизвестно, какие из них понадобятся. Таблица эмбеддингов по сочетаниям токенов устроена иначе: номера нужных строк зависят только от самих токенов, которые известны ещё до прохода по слоям. Значит, строки можно выбрать и подтянуть из оперативной памяти асинхронно, пока видеокарта занята предыдущими слоями. Вот почему 51 миллиард параметров таблицы не мешают скорости так, как мешали бы 51 миллиард параметров экспертов.
Размеры таблицы в разных форматах легко проверить арифметикой. Если в таблице 51,2 миллиарда параметров, то получается:
51,2 млрд x 16 бит / 8 = 102,4 ГБ (BF16)
51,2 млрд x 8,5 бит / 8 = 54,4 ГБ (Q8_0)
51,2 млрд x 6 бит / 8 = 38,4 ГБ (Q5_1)
51,2 млрд x 4,5 бит / 8 = 28,8 ГБ (IQ4_NL)
Эти цифры совпадают с размерами вариантов таблицы в сборках GGUF от сообщества, так что 51,2 миллиарда выглядят верным числом. В vLLM для варианта таблицы в 8 бит нужно не меньше 51 ГБ оперативной памяти хоста плюс запас, а выгрузка работает асинхронно и пока только на видеокартах NVIDIA. По умолчанию она включена, обязательна при схеме DEP и для TP или TEP на картах по 80 ГБ вроде H100, на H200 и выше необязательна. В первой реализации она не поддерживается с конвейерным параллелизмом, на XPU и TPU. Явно включается так: --engram-config '{"cpu_offload":true}'.
Есть и неочевидное следствие для квантизации. Таблица не квантуется ниже четырёх бит из-за случайного характера обращений, поэтому даже самый агрессивный вариант выходит больше ожидаемого. Файл UD-IQ1_S весит 72,5 ГБ на 176 миллиардов параметров, то есть в среднем 3,3 бита на параметр. Если таблица в нём лежит в IQ4_NL и занимает 28,8 ГБ, на остальные 125 миллиардов остаётся 43,7 ГБ, или примерно 2,8 бита. Это допущение, но оно хорошо объясняет, почему "однобитная" версия занимает больше 72 ГБ.
Первые замеры на слабом железе, от ноутбука с 8 ГБ видеопамяти до карты на 96 ГБ
Для оценки реальных скоростей есть несколько самостоятельных сообщений. Все они получены владельцами железа, разными квантизациями и разными программами, поэтому прямо сравнивать их нельзя. Тем не менее порядок величин видно.
На видеокарте с 96 ГБ памяти и сборке UD-Q4_K_XL размером около 111 ГБ автор руководства получил примерно 80 токенов в секунду в начале разговора и около 64 по мере роста контекста. Спад на пятую часть, от 80 до 64, неплохо согласуется с идеей из первого раздела: в большинстве слоёв растущего кэша нет, и скорость падает умеренно. На карте RTX 5070 с 12 ГБ и 32 ГБ памяти DDR4-2400 энтузиаст со своей надстройкой над llama.cpp, которая подтягивает эксперты по мере надобности, сообщил о 11,5 токена в секунду на тесте и 14-15 в обычном диалоге.
Самое громкое сообщение пришло 26 октября из обсуждения энтузиастов локальных моделей: ноутбук с видеокартой на 8 ГБ, 32 ГБ оперативной памяти DDR5 и быстрым NVMe, двухбитная квантизация в сторонней программе Strata, до 900 токенов в секунду на обработке запроса и 30 на генерации. Автор говорит, что модель размазана по видеопамяти, оперативной памяти и диску, причём таблица лежит на диске. Это правдоподобно, если посчитать: двухбитный вариант занимает около 37,6 ГБ суммарно, а на машине доступно 8 + 32 = 40 ГБ. Запаса почти нет, часть чтения неизбежно идёт с диска, а таблица в IQ4_NL на 28,8 ГБ в 32 ГБ оперативной памяти вместе с системой просто не поместится. Но цифры остаются одиночным сообщением без воспроизводимых настроек. Качество двухбитного варианта комментаторы оценивают по-разному.
Отдельный совет из обсуждений: при длинных запросах обработка важнее генерации. Для запроса агента в 20 000 токенов время до первого токена при 70 токенах в секунду составляет 20 000 / 70, то есть около 286 секунд, почти пять минут. При 900 токенах в секунду те же 20 000 токенов обрабатываются за 22 секунды. Разница в тринадцать раз и делает один и тот же агент либо пригодным, либо невозможным. Для генерации арифметика мягче: ответ в 1 000 токенов при 30 в секунду занимает около 33 секунд.
Ещё одна подсказка из рецептов: спекулятивное декодирование с MTP даёт ускорение примерно в 1,3-1,7 раза без потери точности, например около 170 токенов в секунду против 100 на карте RTX PRO 6000. На платформах с низкой пропускной способностью памяти выигрыш скромнее.
Подготовка стека заранее с командами для vLLM и llama.cpp и порядком проверки перед выходом Qwen4
Подготовка укладывается в пять шагов:
- Скачать и проверить на своём железе уже вышедшее превью Qwen3.8 Flash Next, чтобы знать, где упирается память;
- Вынести имя модели, путь к файлам и параметры сэмплирования в конфигурацию, чтобы менять их одной строкой;
- Собрать набор из десятка реальных запросов разной длины и записать эталонное время до первого токена и скорость генерации;
- Проверить запас на диске, потому что файлы по 90-190 ГБ скачиваются часами, а в день выхода каналы перегружены;
- Заранее выбрать запасной вариант, например Qwen3.8 27B или Flash через API, чтобы сравнивать новинку с рабочей моделью, а не с пустотой.
Для серверной стороны есть проверенный рецепт vLLM. Он требует стабильную версию 0.30.0 или новее либо ночную сборку, на которой рецепт и проверялся. Конфигурация для четырёх GB300 с весами FP8 выглядит так:
vllm serve Qwen/Qwen3.8-Flash-Next-FP8 \
--tensor-parallel-size 4 --enable-expert-parallel \
--gpu-memory-utilization 0.90 --max-num-seqs 256 \
--enable-prefix-caching --kv-cache-dtype fp8 \
--attention-config.indexer_kv_dtype fp8 \
--speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
--enable-auto-tool-choice --tool-call-parser qwen3_coder \
--reasoning-parser qwen3
Несколько оговорок из рецепта стоит запомнить. Блоки квантизации FP8 имеют ширину 128, поэтому обычный TP8 несовместим и нужна схема TEP8. На восьми H100 нужны TEP8, бэкенд --moe-backend triton и выгрузка таблицы в оперативную память, а на четырёх H100 по 80 ГБ без неё запуск падает по памяти. Значение num_speculative_tokens равно 3 в большинстве конфигураций и снижается при нехватке памяти, а производительность стоит мерить на наборе speed_bench, а не на случайных запросах.
Для домашней машины подойдёт llama.cpp. Поддержка архитектуры появилась в основной ветке в конце августа, но часть руководств использует ветки с доработками, и это стоит проверить перед сборкой. Стартовая команда выглядит так:
llama-server -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-IQ4_XS -ngl 99 --cpu-moe -c 32768 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0
Ключ -ngl 99 отправляет на видеокарту всё, что помещается, а --cpu-moe уводит все эксперты в оперативную память, так что на карте остаются внимание, общие слои и кэш. Если запас памяти больше, есть вариант --n-cpu-moe N, который выгружает эксперты только первых N слоёв, и ключ --load-mode для управления загрузкой через mmap. Одно из сообщений утверждает, что режим none дал примерно на 50 процентов более быструю обработку запроса, чем mmap по умолчанию, но это единичное наблюдение на конкретной машине. Параметры сэмплирования выше - рекомендация Qwen, а жадное декодирование с температурой 0 названо частой причиной плохих результатов.
Отдельная ловушка: одно сообщение описывает сбой запуска ядра CUDA ровно на 262 144 токенах, тогда как 261 888 проходит. Число 262 144 - это 2 в 18 степени, и, возможно, граница связана с размером блока. Безопасный запас в 256 токенов под контекстом стоит оставить, пока проблема не закрыта.
Какие допущения придётся пересмотреть после анонса, а какие уже можно считать надёжными
Надёжным можно считать немногое. Превью существует, открыто, запускается, и его архитектура описана самими авторами: смесь экспертов 125 миллиардов с шестью активными, чередование GDN и QSA три к одному, четыре ветки остаточных связей, таблица на 51 миллиард параметров с выгрузкой в оперативную память. Следы в коде vLLM подтверждают только это, и закрытый запрос с названием qwen4 ничего не добавляет к архитектуре Qwen4.
Пересматривать придётся три вещи. Первая - сама архитектура: Alibaba не обещала, что Qwen4 повторит превью, и размеры, число экспертов и схема внимания могут измениться. Вторая - открытость весов. Qwen 3.6 вышла с открытыми весами, Qwen 3.7 только через облачный API, как и Qwen3.8 Omni Flash от 18 сентября. Зато Qwen3.8 27B вышла в открытом виде 5 августа, а превью Flash Next открыто. На вопросы разработчиков, сворачивается ли открытость, компания не отвечала. Рабочая гипотеза такая: самые крупные уровни останутся в облаке, а открытыми окажутся уровни поменьше. Это гипотеза, а не факт, и подтверждений у неё нет.
Третья вещь - срок. Для интереса можно посчитать ритм открытых релизов линейки 27B: Qwen3.5 вышла 24 февраля, Qwen3.6 21 апреля, Qwen3.8 5 августа. Интервалы составили 56 и 106 дней. Если прибавить их к 5 августа, получится окно от 30 сентября до 19 ноября, а 8 ноября как раз 95-й день после релиза. Ожидание в ближайшие недели не противоречит ритму, но такой ритм слишком груб, чтобы назвать дату, а два прежних прогнозных окна уже промахнулись. Это прикидка по трём точкам, а не сведения от компании.
Практический вывод не в том, чтобы угадать день, а в том, чтобы убрать трение. Тот, у кого конфигурация вынесена в файл, эталонные замеры записаны, а диск свободен, проверит новинку за вечер. Остальным придётся сначала разбираться с собственной кухней. Следы в коде остаются подсказкой, а не расписанием, и лучшая разведка - та, после которой нечего догонять.