Qwen3.6-27B — 27 миллиардов параметров обыграли 397 миллиардов на кодинге. И всё это влезает в одну GPU

Qwen3.6-27B — 27 миллиардов параметров обыграли 397 миллиардов на кодинге. И всё это влезает в одну GPU

22 апреля Alibaba выкатила первую плотную (dense) модель в семействе Qwen3.6. И сделала странную вещь: новая модель в 15 раз меньше их собственного предыдущего флагмана, при этом обходит его на агентном кодинге. 27 миллиардов параметров против 397.

TL;DR: Qwen3.6-27B, 27B dense-модель под Apache 2.0, которая берёт 77.2% на SWE-bench Verified (уровень Claude Opus 4.5) и кладёт на лопатки собственного 397B MoE-предшественника. Влезает в RTX 4090 в Q4-квантизации, поддерживает 262K контекст нативно (до 1M через YaRN), мультимодальная из коробки. На OpenRouter цена $0.32 / $3.20 за миллион токенов.

Почему это вообще важно

Весь 2026 год open-source модели гнались в сторону MoE: DeepSeek V4 Pro (1.6T/49B активных), Kimi K2.6 (1T/32B активных), даже сам Qwen ушёл в MoE с 397B-A17B. Логика простая. Больше параметров, выше качество. Активные параметры, ниже compute.

Qwen3.6-27B идёт против тренда. Все 27 миллиардов параметров активны на каждом forward pass. Никакого роутинга экспертов, никаких MoE-сложностей. Простая dense-модель, которая помещается на одну GPU и при этом бьёт MoE-гиганта в 15 раз больше.

Это работает по двум причинам.

Первая, гибридная архитектура. 64 слоя, паттерн 16 × (3 × Gated DeltaNet → FFN + 1 × Gated Attention → FFN). Три слоя из четырёх работают на линейном внимании (Gated DeltaNet), каждый четвёртый берёт обычный softmax с RoPE. Линейное внимание дешёвое по compute и памяти на длинных контекстах, обычное точнее справляется с короткими зависимостями. В сумме получается компромисс, который для 27B параметров работает лучше чистого softmax-attention.

Вторая, dense-формат компрессится лучше MoE. Qwen3.6-27B в Q4_K_M (~17 GB) помещается в одну RTX 4090. У Qwen3.5-397B-MoE в любой квантизации даже близко не получается. На реальной инференс-ноде разница в стоимости в десятки раз.

Что в цифрах

Данные со страницы модели на Hugging Face и блога Qwen, без независимой перепроверки на момент написания.

Кодинг:

• SWE-bench Verified — 77.2% (Qwen3.6-27B)
• SWE-bench Verified — 72.5% (Qwen3.5-397B-A17B MoE, прошлый флагман)
• Terminal-Bench 2.0 — 59.3 (соответствует Claude Opus 4.5 по заявлению Qwen)
• QwenWebBench — 1487 ELO (внутренний фронтенд-бенчмарк)

Контекст: 262 144 токена нативно. Через YaRN растягивается до 1 010 000, но Qwen рекомендует не опускаться ниже 128K, иначе деградирует thinking-режим.

Языки: 201 язык и диалект.

Мультимодальность: vision encoder встроен в модель, это не отдельный adapter поверх. Принимает текст, картинки, видео.

Лицензия: Apache 2.0, без оговорок. Можно встраивать в коммерцию.

Что говорят пользователи реально. На r/LocalLLaMA пользователь kevin_1994 запустил 27B в Q8 на 48 GB VRAM: «остаётся когерентной за пределами 100K контекста, на ощупь — frontier-уровень». Помог ему дебажить PKCE в OAuth-сервере: модель сама выполняла curl-команды, читала RFC и писала тестовые приложения на Node, пока не воспроизвела баг. Контекст за 100K, всё в одной сессии.

Другой тест на RTX 5090: Qwen3.6-27B AWQ INT4 против Qwen3.6-35B-A3B и Gemma 4 31B на задаче «склеить два архитектурных документа в Masterplan.md». Итог: 27B стала лучшим общим «рабочим конём» по балансу глубины и применимости. 35B-A3B (MoE-собрат) выдала самый объёмный документ, Gemma 4 оказалась самой дисциплинированной.

Thinking Preservation, главная фишка

Это новая опция, которой не было ни у одной модели до этого: сохранение reasoning-следов между ходами разговора. Раньше как было: агент думает, выдаёт ответ, и в следующем ходе всё его «размышление» отбрасывалось из контекста. Каждый раз заново.

Qwen3.6-27B хранит цепочку мыслей в KV-кеше. На итеративных задачах вроде «дебаг → правка» это режет генерацию повторных reasoning-токенов и поднимает попадание в кеш.

В коде это выглядит так. Пример из официальной документации Qwen:

# Активация preserve_thinking режима в API
response = client.chat.completions.create(
    model="qwen3.6-27b",
    messages=[
        {"role": "system", "content": "You are a coding agent."},
        {"role": "user", "content": "Refactor this React component..."},
    ],
    extra_body={
        "preserve_thinking": True,  # сохраняет reasoning из прошлых ходов
        "thinking": True,
    },
)

На длинных агентных циклах (Claude Code, Cline, OpenCode) это даёт ощутимый прирост, особенно когда агент перебирает варианты решения.

Как запустить локально

Минимум: RTX 4090 или Mac M3/M4 Max с 32+ GB. Вот варианты по уровням:

24 GB VRAM (RTX 4090, RTX 3090):

• Берёшь Q4_K_M GGUF от unsloth (16.8 GB)
• Запускаешь через llama.cpp или LM Studio
• На одной 3090 пользователь добился ~50-66 TPS и 218K контекста с патчем PN12

16 GB VRAM (RTX 4080, dual 5060 Ti):

• IQ4_XS (~15 GB) от bartowski, компромисс между размером и качеством
• На двух 5060 Ti 16GB через vLLM выходит 60 tok/s при 204K контекста

80 GB (H100, A100):

• FP8-вариант от Qwen напрямую (~28 GB), Qwen уверяет что качество «практически идентично» BF16
• Использовать с vLLM или SGLang
• На H100 dense 27B FP8 быстрее BF16 на 27% (для сравнения, 35B-MoE FP8 быстрее на 73%, MoE сильнее выигрывает от FP8)

Apple Silicon (M3/M4 Max, 64+ GB):

• MLX 4-bit от mlx-community (~16 GB)
• Через mlx-vlm или LM Studio

Через API (без своей инфры):

• OpenRouter: qwen/qwen3.6-27b, $0.32 input / $3.20 output за миллион токенов, 262K контекст

Подводные камни

Не всё так радужно. Реальные проблемы, на которые жалуются пользователи или которые вылезли в документации:

1. Tool-call падал на vLLM до патча PN12. Длинные tool-output (~25K токенов) консистентно крашили инференс на vLLM dev205+. Это был баг Genesis-патча, который должен был чинить memory issue, но не применялся. Лечится только апгрейдом до dev210+ с PN12. Если ты на старой версии vLLM, словишь это первым же запуском в продакшене.

2. Dense означает «всё или ничего». На H100 в FP8 модель ускоряется на 27%, тогда как MoE-собрат 35B-A3B на 73%. Причина: MoE упирается в bandwidth движения весов экспертов через память, и FP8 режет этот трафик пополам. Dense уже плотно загружен, выигрыша меньше. Если ты выбираешь между 27B dense и 35B-MoE на H100 для serving’а, MoE может оказаться быстрее.

3. Знаний модели не хватает. Тот же kevin_1994 признаётся: «У 27B по сути нет знаний, я подключаю к ней интернет, и тогда она ощущается как frontier». В чистом offline-режиме модель отвечает уверенно даже когда не знает, нужен RAG или web search. Без них получишь много галлюцинаций на фактических вопросах.

4. YaRN-расширение до 1M ломает thinking. Qwen прямо в README пишут: при контексте меньше 128K thinking-режим деградирует. Между «нативные 262K» и «1M через YaRN» лежит заметная пропасть в качестве рассуждений. То есть «1M контекста» это маркетинг для retrieval-сценариев, а не для агентного кодинга.

5. На реальном Intelligence Index модель отстаёт от DeepSeek V4 Pro и Kimi K2.6. По данным Artificial Analysis, Qwen3.6-Plus (близкий вариант) уступил DeepSeek-V4-Pro на 5 из 7 индексных бенчмарков. То есть 27B это «лучший в своём весе», но не frontier raw. Если тебе нужен максимум, смотри в сторону MoE.

Альтернативы

• DeepSeek V4 Pro — 1.6T/49B активных, MIT-лицензия, 80.6% SWE-bench Verified. Frontier-качество, но MoE и нужно много памяти. Берёт там, где Qwen3.6-27B не дотягивает по сложности задач.
• Kimi K2.6 — 1T параметров, 32B активных, 12-часовые автономные сессии, рои до 300 саб-агентов. Anthropic API-compatible. Берёт длинные горизонтальные задачи, где Qwen надо тушить и заводить заново.
• Qwen3.6-35B-A3B — MoE-родственник, всего 3B активных параметров, помещается на ноут. Меньше качество (73.4% SWE), но в 3-5 раз быстрее на одной карте. Если выбираешь между скоростью и точностью, это твой компромисс.
• Gemma 4 31B Dense — Apache 2.0, тоже dense, тоже на одну GPU. Но кодинг слабее, зато стабильнее в сохранении инструкций. Пользователь с RTX 5090 поставил Gemma 4 на первое место по «дисциплине», но на четвёртое по «полезности».

Вердикт

Стоит брать если: у тебя одна-две GPU по 24GB+ и нужен открытый кодинг-агент уровня Claude Opus 4.5. Это сейчас лучшая dense-модель в этом весе. Apache 2.0 без оговорок, мультимодальность из коробки, 262K контекста, и реальные пользователи уже отлаживают на ней OAuth-серверы со 100K контекста.

Не стоит брать если: у тебя нет 24GB VRAM (бери 35B-A3B MoE, собрат помещается на ноут), или ты гонишься за frontier-качеством (бери DeepSeek V4 Pro), или тебе нужны 8-12 часовые автономные сессии (Kimi K2.6 заточен под это).

Подожди до stable-релиза vLLM с PN12 patch, если планируешь продакшен с tool-calling. Иначе словишь крашы на длинных tool-output.

Как попробовать

1. API за минуту: заведи аккаунт на openrouter.ai, пополни на $5, дёрни модель qwen/qwen3.6-27b. Хватит на пару часов экспериментов.

2. Локально через LM Studio (самое простое): скачай LM Studio, найди в каталоге lmstudio-community/Qwen3.6-27B-GGUF, выбери Q4_K_M (16.5 GB), запусти. Работает на 24GB+ GPU.

3. Через llama.cpp вручную:

# скачать GGUF
huggingface-cli download unsloth/Qwen3.6-27B-GGUF \
  --include "Qwen3.6-27B-Q4_K_M.gguf" --local-dir ./models
# запустить
./llama-server -m ./models/Qwen3.6-27B-Q4_K_M.gguf \
  -c 131072 --n-gpu-layers 65 --port 8080

4. Тестовый промпт для агентного кодинга:

   В моём проекте есть OAuth-сервер с PKCE. Юзеры жалуются на
   400 при exchange code → token. Вот код [...вставь]. Используй
   curl чтобы воспроизвести баг и почини его.
   

   В Claude Code или Cline это покажет, как 27B справляется с многоступенчатым агентным циклом.

5. Документация и веса: Qwen3.6-27B на Hugging Face, официальный блог, GitHub репозиторий.