/ Модель

Характеристики

Контекст
262 144 токена
Размер весов
17,1 ГБ
Лицензия
Apache 2.0
Архитектура
qwen3_5 · dense
Базовая модель
Qwen3.8-27B
Опубликована
16 авг 2026

Qwen3.8-27B-AWQ-5.0bpw-Sharp

Изображение и текст → текст15 профессий

Квантизованная мультимодальная модель Qwen на 27,8 млрд параметров для диалогов, анализа изображений, программирования и многошаговых задач на Apple Silicon.

111скачиваний за 30 дней0лайковвеса обновлены16 авг 2026

Бенчмарки

Как модель справилась с задачами пользователей ailist и что о ней публикуют открытые лидерборды

Публичные оценки

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

В подключённых источниках результатов для этой модели пока нет.

Что умеет модель

Описание составлено по карточке модели и метаданным Hugging Face

Qwen3.8-27B-AWQ-5.0bpw-Sharp — мультимодальная плотная модель на базе Qwen/Qwen3.8-27B, подготовленная mrKola для запуска на Apple Silicon через oMLX. Это вариант с квантизацией AWQ 5,00 бита на параметр и группами размера 64; модель занимает около 17,36 ГБ. Архитектура сочетает GatedDeltaNet и полнослойное внимание, включает визуальный модуль и встроенную голову MTP. Базовая модель имеет контекст до 256 тысяч токенов.

Модель предназначена для диалогов, анализа изображений, программирования, рассуждений и многошаговых задач; интерфейс также предусматривает вызов инструментов. Калибровка учитывала текст и изображения, включая диаграммы и фотографии. В README приведены результаты HumanEval, GSM8K и MMLU, однако они сравнивают две квантизованные сборки, а не дают независимую оценку качества. Указанные скорости измерены на M5 Max с oMLX и не гарантируют такую же производительность на другом оборудовании.

Модель распространяется по лицензии Apache-2.0. Качество на длинном контексте с ускорением SpecPrefill и моделью-черновиком с несовпадающим токенизатором не измерено; README рекомендует проверять такие сценарии на собственных данных.

Сценарии применения

  • ответы на вопросы по изображениям и фотографиям
  • анализ диаграмм и графиков
  • помощь в написании и разборе кода
  • диалоговые ответы и рассуждения по тексту
  • выполнение многошаговых задач с вызовом инструментов

Ограничения

Показатели скорости получены на M5 Max с oMLX и могут отличаться на другом оборудовании. Точность извлечения информации на длинном контексте при использовании SpecPrefill с несовпадающим токенизатором не проверена.

Для каких профессий подходит15

Разделы каталога профессий, в задачах которых используется эта модель

Все профессии

Также подходит для

Карточка модели

README от автора на Hugging Face, как он его опубликовал

Открыть на Hugging Face

Qwen3.8-27B — AWQ 5.0bpw (group size 64, multimodal calibration)

AWQ-calibrated quantization of Qwen/Qwen3.8-27B (27.8B dense, 64 layers, hybrid GatedDeltaNet + full attention, 256K context, MTP head, vision tower) for Apple Silicon via oMLX.

17.36 GB · BPW 5.00 · 3.2× smaller than bf16

A group-size-64 variant of Qwen3.8-27B-AWQ-4.85bpw, calibrated with images as well as text. Costs +0.53 GB over that build and buys two things: full prefill speed with no workaround, and a vision tower that was actually exercised during calibration.

componentbitswhy
MLP gate_proj / up_proj / down_proj4-bit gs6462% of weights; gs64 reaches oMLX's NAX kernel path
GDN in_proj_{qkv,z,a,b}5-bit gs642nd most concentrated (participation ratio 0.0040)
GDN out_proj4-bit gs64middling
attention q/k/v_proj8-bit gs64most concentrated by 135× (PR 0.0022), only 4% of weights
attention o_proj4-bit gs64flat
embed_tokens4-bit gs128lookup, not a matmul
lm_head6-bit gs128output projection over a 248k vocab
vision tower8-bit gs128now calibrated (see below)
MTP head8/6/4-bitrejection-verified drafter

No 3-bit anywhere: oMLX's qwen35_prefill kernels expose q2/q4/q5/q6/q8 but not q3, so 3-bit in the MLP silently drops prefill to a slow path.

Why group size 64

oMLX routes 4-bit MLP matmuls to a native kernel above 2048 tokens, and that kernel's speed comes from the NAX tensor-unit path — which is gated to group_size == 64. At gs128 it demotes to a slower path, costing ~1.8× prefill on M5 hardware unless you disable the routing (jundot/omlx#2657).

Measured at pp 4096 / tg 128, no environment variables, same machine:

buildppTPSTTFT
gs128, kernel routing active513.27982 ms
gs128 + routing disabled930.64401 ms
this build (gs64)894.44580 ms

So gs64 gets essentially full prefill speed with no workaround and no local patching, which is the practical argument for the extra 0.53 GB.

Speed

M5 Max, oMLX, no environment variables. Two separate options are on: native MTP (the checkpoint's built-in multi-token-prediction heads, accelerating decode) and SpecPrefill with a small draft model (accelerating prefill above 8K tokens).

A note on the SpecPrefill drafter, because the obvious choice is not the fast one. SpecPrefill feeds the target's token ids straight to the drafter, so a drafter from the same tokenizer family (vocab_size 248,320, e.g. Qwen/Qwen3.5-0.8B) is the only one whose importance scores describe the actual prompt — a smaller-vocab drafter gets zero vectors for every out-of-range id rather than an error, and shares only 0.19% of id-to-token meanings with this model.

Measured, though, a 4-bit Qwen2.5-0.5B drafter is faster and much lighter at long context — 1467 vs 876 ppTPS and 33.1 vs 53.1 GB peak at 200K — because the drafter must prefill every token to score it, and a Qwen3.5-family drafter carries head_dim 256, GDN state and a 248k-row embedding.

Both figures above are throughput only. Whether the tokenizer mismatch costs long-context accuracy is not measured here, and the quality benchmarks in this card all sit below SpecPrefill's 8192-token trigger, so they do not answer it either. Test retrieval at depth on your own workload before committing.

contextTTFTTPOTppTPStgTPSE2Epeak mem
pp 1k / tg 1281224 ms23.5 ms83742.84.2 s17.6 GB
pp 4k / tg 1285214 ms17.8 ms78656.57.5 s19.2 GB
pp 8k / tg 12810109 ms18.6 ms81054.312.5 s20.2 GB
pp 16k / tg 1286565 ms20.3 ms249649.69.2 s21.4 GB
pp 32k / tg 12814766 ms21.2 ms221947.517.5 s22.8 GB
pp 64k / tg 12832029 ms23.8 ms204642.335.1 s24.7 GB
pp 128k / tg 12875917 ms25.1 ms172740.179.1 s28.5 GB
pp 200k / tg 128136381 ms33.1 ms146730.4140.6 s33.1 GB

Two separate accelerators are active, and they show up in different columns. Native MTP drives the decode side (tgTPS). SpecPrefill drives the prefill side: a small draft model scores token importance and only the top ~20% are prefilled on the target. It engages above 8192 tokens, which is exactly where ppTPS steps from ~810 to ~2500 and TTFT falls from 10.1 s at 8K to 6.6 s at 16K. Those tail rows are still cold prefills — they are sparse, not cached — so they are legitimately faster, just not measuring the same work as the ≤8K rows.

The tail also shows the memory story: the full 200K window costs 33.1 GB and still decodes at 30 tok/s.

Batched, same machine:

batchtgTPSavg TTFTE2Espeedup
142.81224 ms4.2 s1.00×
247.63253 ms9.4 s1.11×
477.25315 ms15.3 s1.80×
8115.910158 ms27.2 s2.71×

Calibration

352 prompts × 1024 tokens, 234,477 real tokens, rendered through Qwen's own chat template with a 50/50 think/nothink split. Unlike the 4.85bpw build, this one includes images, so the vision tower actually executed during calibration rather than having its bits assigned by guesswork:

domainshare
text (coding, tool use, agentic, reasoning)66%
charts (ChartQA)11%
natural photographs (VQAv2)11%
GLSL / raymarching renders11%

Sequential AWQ over the dense MLP: each layer is calibrated on activations from the already-quantized layers above it. Everything outside the MLP is RTN at the widths above.

MTP

The MTP head ships inside the checkpoint (31 tensors under mtp.*) and is quantized: 8-bit attention, 6-bit fc, 4-bit MLP. Turn it on with oMLX's mtp_enabled, which uses those heads to draft and verify during decode.

Fixed 2026-08-16 — re-download if you pulled this before that date. The head shipped in raw-HF norm convention while the backbone was already converted to MLX's, so mtp.layers.0.input_layernorm averaged 0.0361 instead of ~1.036 and two norms were negative. Drafts stopped matching the target and acceptance collapsed. On a loader with no compensation this made MTP slower than no speculation at all (22.4 vs 24.6 tok/s); repaired, the same setup runs 43.7 tok/s. Inside oMLX the damage was partly masked — its norm_repair shifts any head norm averaging below 0.5, which caught 3 of the 7 and left q_norm (0.78), k_norm (0.79) and mtp.norm (1.25) raw; repairing those three measured +9% decode (median 53.3 vs 48.8 tok/s, pp 4096 / tg 128, three runs each, no overlap between the groups).

Only model-00005-of-00005.safetensors changed. Benchmarks below are unaffected: they were run with MTP off, and MTP is rejection-verified, so a degraded head costs acceptance rate but never output correctness.

Quantizing the head is safe — drafts are rejection-verified by the target model, so head error costs acceptance rate, never output correctness. Leaving it at bf16 inside a quantized model measurably halves throughput.

MTP is a distinct feature from speculative decoding with an external draft model, and the two accelerate different phases. They compose: the speed table above was measured with native MTP on the decode side and SpecPrefill driving prefill from a Qwen2.5-0.5B-Instruct draft model, which is what produces the ~3× prefill step above 8K.

Quality

Same questions, same harness, against the 4.85bpw sibling:

benchmarkthis build (5.0bpw gs64)4.85bpw gs128
HumanEval91.5% (150/164)93.3% (153/164)
GSM8K92.5% (185/200)92.0% (184/200)
MMLU84.0% (168/200)83.0% (166/200)
total503 / 564503 / 564

The totals are identical. Three questions lost on HumanEval, three regained across GSM8K and MMLU — that is what noise looks like at this sample size, not a capability difference, and neither per-benchmark gap is significant on its own. Both builds sit four questions behind bf16.

So the extra 0.53 GB does not buy accuracy. It buys the prefill speed above without an oMLX patch, and a vision tower that was calibrated on real images rather than assigned its bit width by guesswork. Pick on that basis.

One caveat on attribution: this build changes two variables at once relative to the 4.85bpw one — group size and calibration data. Since the aggregate result is a tie, neither variable moved the needle enough to need separating.

Requires oMLX

The checkpoint keeps its mtp.* weights so the MTP head can bind. Stock mlx_vlm sees those keys, flips its should_shift_norm_weights heuristic, and applies a +1.0 offset to layernorms that already have it — the model still loads and still produces fluent text, but the text is wrong. oMLX patches sanitize to gate that on conv1d layout instead, which is correct here.

Do not load this outside oMLX.

Sampling

The chat template takes reasoning_effort of xhigh (default), medium or low, and raises on anything else. It also accepts enable_thinking and preserve_thinking. Pass via chat_template_kwargs.

Caveats

  • 27 vision linear_fc2 modules stay at bf16: their input dim (4304) is not divisible by any supported group size.
  • Built with mlx-compress.

Как запустить

На своей GPU в ailist. Цена — по текущим предложениям провайдеров

GPU в ailist

Универсальный рантайм

Нельзя запустить

MLX-модели работают только на Apple Silicon.

Класс архитектуры
Qwen3_5ForConditionalGeneration
Ревизия весов
52aeb07

0 моделей