muse-glimmer

muse-glimmer-30b (muse-glimmer-30b.md)

Muse Glimmer 30B (Meta Superintelligence Labs, Apache 2.0, released 2026-08-10)

is served as muse-glimmer on port 9140 via llama-swap. Dense ~28B decoder +

~1.8B ViT-G/14 perception encoder, 52 layers, GQA 32q/2kv, attention pattern

[Local,Local,Local,Global] with a 2048 sliding window. Weights on ssk500

(/mnt/ssk500/gguf/muse-glimmer-30B-*): 19.7 GB kquant-dynamic + 1.4 mmproj +

1.6 dflash.

VERDICT 2026-08-12: KEEP, DEMOTED — moved off the nvme to ssk500. It wins no

role outright: [[gemma-4-26b-awq-vllm]] beats it on office (18/18 vs ~7/9), speed

(93 vs 45 tok/s) and context (248k verified vs a HARD 131072); [[fable-711-27b]]

matches its vision, beats its coding 23/23, and closes the KLayout loop UNAIDED

which this does 0-3/4; [[qwen36-35b-awq-trial]] already ties its KLayout+ref. My

earlier "it fills gemma's KLayout gap" was wrong — I compared against gemma alone

instead of the whole roster, and 7/8 is a TIE, not a win. **The disqualifier is the

real-case GATE at 1 pass in 4** — that is the actual mask work, so do NOT point

this model at KLayout production.

**Kept for the one thing it does win: the FASTEST verified 21/21 vision on the

box** (~45 tok/s vs fable-fusion's 33.4 and bonsai's 36.3), and the only vision

score here measured 4x with zero variance. Also non-Qwen lineage, which only

gemma-awq otherwise provides.

Cold load from ssk500 measured at 99s vs 30s from the nvme (+69s), consistent

with [[nvme-working-set]]; decode speed and VRAM are unaffected by the move.

What would flip it: Layout.cells() is missing from the realcase API_REF and

is 2 of its 3 failures — fix that, re-run the gate, and it becomes a genuine

KLayout contender worth re-weighing against fable-fusion.

GRILLED 4 BATTERIES 2026-08-11/12 — 3 repeats at the archive protocol

(temp 0.2) plus 1 arm at Meta's recommended Reasoning strength: high. ~47 min

each, ZERO cap-hits in any of the 56 suite runs.

| suite | default (n=3) | reasonhigh (n=1) |

|---|---|---|

| 23-task coding | 22 / 21 / 22 of 23 | 22/23 |

| R5 long-horizon | 5/6, 6/6, 5/6 — 0 loops ALL runs | 6/6, 0 loops |

| vision | 21/21 x3 | 21/21 |

| KLayout unaided | 2/8, 1/8, 0/8 | 2/8 |

| KLayout + API ref | 7/8 x3 (zero variance) | 6/8 |

| KLayout-render vision | 5/6 x3 | 6/6 |

| closed loop unaided | 0/4, 3/4, 2/4 | 4/4 |

| closed loop + ref | 4/4 x3 | 4/4 |

| office unaided | 6/9, 9/9, 6/9 | 6/9 |

| office + API ref | 6/9, 6/9, 9/9 | 6/9 |

| real-case GATE | PASS, FAIL 6/7, FAIL 0/7 | FAIL 6/7 |

What is STABLE (repeated every run): vision 21/21 (84/84 lifetime, identical

breakdown), KLayout+ref 7/8, closed-loop+ref 4/4, rounds 2/3/4 perfect, and

0 loops across 24 long-horizon tasks — the axis that retired four models here.

Tool calls parse structured and correct; tool_restraint never fires spuriously.

23-task spread is 1 (21.7 mean), R4 efficiency flat at 169-178 tok/step.

What is NOT stable — and where I got it wrong from n=1. The first battery led

me to state three things that the repeats refuted. Recording them because the

error is more instructive than the scores:

• "office has a REPRODUCIBLE value= codegen defect" — it appeared in BOTH arms

of run 1, which looked conclusive. But those two arms differ only by the API ref

and are NOT independent samples. rep2 unaided scored 9/9 clean.

• "the unaided closed loop is blocked by a layer_index misconception" — that was

0/4 once; it is 0/4, 3/4, 2/4 across three runs.

• "REAL-CASE GATE: PASS 7/7" — reported as a headline off run 1. It passes **1 in

4**. This was the worst of the three: a pass/fail gate quoted from a single sample.

The office defect, characterized properly. It is not a misunderstanding of

openpyxl — the model writes ws.cell(row=i, column=4, value=f"=B{i}*C{i}")

correctly every time in loops. It fails ONLY on value="= (keyword =, quote,

then another =, with no f intervening), always on the grand-total line:

ws.cell(row=6, column=4, value"=SUM(D2:D5)"). 5 of 8 office arms, under both

samplers, with and without the ref. A token-level generation slip, and the single

most reproducible defect found. Office also failed once on a hallucinated

ColumnChart (correct: BarChart) — THAT one the API ref did fix. Net: office

averages 7/9 with the ref and 7/9 without, because the ref cures recall errors and

is powerless against the token slip, and the two alternate.

Reasoning strength: high is NOT a simple more-effort dial and does not match

Meta's "use high for coding" advice on this box:

• it made the model more concise — 103,477 total tokens vs 113,981-126,825 at

default, the LEANEST battery, and expr_eval used 5058 tokens vs 8140-10055.

• it HELPED where self-checking pays: unaided closed loop 0-3/4 -> 4/4, and

render-vision 5/6 x3 -> 6/6 (first ever clearing of nested_rings).

• it did NOTHING for the 23-task score (22/23, same cap) and nothing for the

office token slip (6/9 both arms, same SyntaxError).

• it was slightly WORSE on KLayout+ref: 6/8 against a 7/8 that had zero variance

over three runs. n=1, so suggestive rather than settled.

expr_eval is the one hard coding limit: failed 4/4 runs, every time on the

same assertion (expected ValueError for '1++2'), under both samplers, never a

cap-hit at a 16000 budget. articulation_points is the resampling-sensitive one

(passed 3 of 4).

REAL-CASE IS AN ACTIONABLE FIX, NOT JUST A SCORE. 2 of its 3 failures are the

SAME line — len(layout.cells()), where Layout.cells() returns an int, not a

collection — and cells() is NOT in the gate's API_REF (bench/realcase_grating.py,

1498 chars). Adding it there and to the klayout-classes skill should lift the

pass rate materially. The third failure is worse and is NOT a reference gap: the

model wrote db.CellInst while CellInstArray was present in its own prompt.

So on a long task (spec + Excel parse + geometry) it drifts from a reference it

was given — plausibly dilution, unproven. Practical rule: the klayout-classes

skill is NECESSARY but demonstrably NOT SUFFICIENT for this model on long tasks.

See [[klayout-api-recall-vs-composition]].

Artifacts were verified, not trusted ([[eval-false-pass-adjacent-data]]): the

run-1 realcase GDS holds 54 cells at dbu 0.001 with 36 non-degenerate shapes on

203/7, 204/3, 203/1; rep2's passing office workbook carries real per-row =B2*C2

formulas and =SUM(D2:D5) in D6.

GRILL RUNNER GOTCHA that cost an arm: grill_klayout_vision.py runs

mode=ground-truth by DEFAULT; the closed loop needs the **--closed-loop CLI

flag**, not an env var. GRILL_KLAYOUT_APIHELP only affects the loop's CODE stage,

so without the flag the two apihelp arms are IDENTICAL no-ops — the first battery

ran 5/6 twice and I nearly reported it as "closes the loop unaided". Both correct

arms live in bench/run-closed-loop-muse-glimmer.sh.

It forced the first llama.cpp rebuild since Jul 26. Arch support landed in

PR #26841 / commit 62bf73d on 2026-08-10; the box was on build 10133

(ff067f76d, Jul 26) and is now 10369 (6e62ba538). The existing build cache

already carried CMAKE_CUDA_ARCHITECTURES=89;120, so it was a plain pull +

cmake --build. The relink gives a fresh inode, so the model resident at the time

(fable-fusion) kept running on the old binary — a rebuild does NOT disturb a live

model, it takes effect on the next swap.

DFlash spec-decode is worth ~2.8x and the acceptance rate is a red herring.

Measured on one prompt: **42.8 / 49.6 tok/s with the drafter vs 16.7 / 16.7

without.** Draft acceptance sits at only 22-25%, which looks like a failing

drafter and is not. Do not remove it on that number. -md is REQUIRED with local

-m paths: the sidecar auto-resolution at common/arg.cpp:545 lives inside the

-hf download planner, so it never fires for local files.

Context hard-caps at 131072 and overshooting costs VRAM silently. -c 262144

does not error — it logs the slot context (262144) exceeds the training context

of the model (131072) - capping, serves at 131072 anyway, and still allocates the

oversized KV: 28188 MiB at -c 262144 vs 24806 at -c 131072, ~3.3 GiB burned for

context the slot can never reach. Unsloth's "up to 262144" means explicit YaRN rope

scaling, which is NOT configured here. q8_0 K and V are both accepted.

--tensor-split 48,52, measured not guessed. At 50,50 CUDA0 ran 916 MiB

heavier; 48,52 lands 12283 vs 12523 MiB. Remember CUDA0 = the 4060 Ti =

nvidia-smi index 1 ([[gpu-device-ordering]]). ~7.7 GiB of the 31.9 GiB pool is

still free at 131072 with the drafter loaded.

Reasoning strength is a system-prompt string, not a flag or template variable:

the literal Reasoning strength: low|medium|high|xhigh. Verified — it cut reasoning

from 1984 to 720 chars. There is no reasoning_effort variable in the embedded

template. Meta recommends high/xhigh for coding and agentic work. CoT goes to

reasoning_content, the answer to content; **at max_tokens=64 it hit the cap

mid-think and returned EMPTY content with no error**, the same trap already

recorded for [[pocket-35b]]. --jinja is mandatory and the template is embedded —

unlike the Qwen3.5/3.6 entries, do NOT add --chat-template-file.

vLLM support now EXISTS — in nightlies, not stable (CORRECTED AGAIN 2026-08-20).

The earlier "CORRECTED 2026-08-12" note in this file was ITSELF wrong — it claimed

PR #51655 was "the ROCm PR, not a Muse Glimmer PR." That is false. PR #51655 "Add

Muse Glimmer model support" MERGED 2026-08-14T04:28:56Z (GitHub API confirmed). On

main now: vllm/model_executor/models/muse_glimmer.py exists and the registry

maps MuseGlimmerForCausalLM, MuseGlimmerForConditionalGeneration, plus the DFlash

draft head (MuseGlimmerAssistantModel / DFlashMuseGlimmerAssistantModel,

reusing the generic qwen3_dflash impl). So the --model-impl transformers

fallback is OBSOLETE — native support keeps --tool-call-parser muse_glimmer /

--reasoning-parser muse_glimmer, so a vLLM grill IS comparable to the GGUF grill.

But NOT in any stable release. 0.27.1 (Aug 11) predates the merge by 3 days;

verified on the on-disk vllm-env-027 / vllm-env.0.27.1 envs: 367 archs, no

MuseGlimmer. The installed serving env (vllm-env, 0.26.0) has 362, none. Muse

Glimmer is in nightly 0.26.1rc1.dev977+gc20572610 (commit c2057261, built

2026-08-19, 5 days post-merge) at wheels.vllm.ai/nightly/cu130/, cp38-abi3

(installs on py3.12). Installed into a fresh ~/vllm-env-nightly 2026-08-20 to

trial the AWQ below — the 0.26.0 serving env is left untouched.

Known PR bugs to watch for (some may be fixed by dev977, some not): DFlash

needs --max-num-batched-tokens 4096 (the auto-cap of 2048 hard-crashes); the ATEM

tool parser had a string-arg JSON-decode bug and sometimes swallowed opening

<atem:invoke> tags. The day-0 vllm/vllm-openai:muse-glimmer docker image is an

alternative, but this box runs vLLM from a venv, not docker.

A W4A16 AWQ build EXISTS and is Ada-compatible — cyankiwi/Muse-Glimmer-30B-AWQ-INT4,

uploaded 2026-08-11, 22.37 GiB, downloaded and cached here (on NVMe, REAL not a

symlink to ssk500). compressed-tensors pack-quantized, group_0 = 4-bit int,

group_size 32, input_activations: None = weight-only W4A16, so it runs on

the Ada 4060 Ti, unlike the NVFP4 builds (W4A4, Blackwell-only kernels). The

vision tower, vision_adapter, lm_head AND language layers 47 and 51 are

left unquantized — that last exclusion is the signature of the quantizer carving

out layers that misbehaved, so treat quality as UNPROVEN (also 0 downloads,

unknown quantizer). 22.37 GiB fits the 31.9 GiB TP=2 pool; FP8 (32.78 GB) and BF16

(59.58 GB) do not. **Both blockers (quant + engine) are now clear in nightly; the

AWQ is being load-tested + grilled next.**

Two load warnings are benign and verified so: dflash requires ctx_other to be set

(the log itself says this is normal during memory fitting) and special_eot_id is

not in special_eog_ids — generations still finish with stop. Stop tokens are

<|end_of_text|> (200001) and <|eot|> (200008); never stop on <|eom|>, which

marks message-end, not turn-end. The server suggests --reasoning-preserve for

multi-turn; not enabled.

AWQ TRIED + REMOVED — 2026-08-20 (1-pass grill, no role, unwired same day)

The cyankiwi/Muse-Glimmer-30B-AWQ-INT4 W4A16 build was wired in as a selectable

served model muse-glimmer-awq (port 9142), grilled one pass, and **removed the

same day** — it wins nothing the roster doesn't already beat and rides a fragile

nightly stack. The wiring was reverted from llama-swap.yaml + models.json +

sync-models.sh + the 6 agent CLIs; the entry was HUP-evicted (VRAM back to ~18

MiB/card, no orphan squat); the grill script + results dir were deleted.

1-PASS GRILL (budget 32000, temp 0.2, 77 min — fast because only expr_eval

ran away, vs qwen38-awq's several; n=1, so treat the exact scores as a read not

a verdict):

| suite | muse-glimmer-awq | GGUF sibling | qwen38-awq |

|---|---|---|---|

| coding 23-task | 22/23 (expr_eval runaway) | 21.7 mean | — |

| R5 long-horizon | 5/6, 0 loops, 6.8% redund | 5–6/6, 0 loops | — |

| KLayout unaided | 1/8 | 0–2/8 | — |

| KLayout +ref | 5/8 | 7/8 (0 var) | 7/8 |

| office unaided | 0/9 | 6–9/9 | — |

| office +ref | 9/9 (vision sub-tasks pass) | ~7/9 | 9/9 |

| real-case gate | 0/7 FAIL | 1 of 4 (0/7–7/7) | 2/3 |

| decode | ~27.5 tok/s | ~45–50 (DFlash) | ~28 |

Why removed: it is a PEER of the GGUF, not an upgrade. Coding 22/23 matches

the GGUF and fable-fusion/gemma-awq; R5's 0 loops matches the GGUF (the axis that

retires models, clean here too). But KLayout+ref 5/8 is 2 below the GGUF's

7/8 and qwen38-awq's 7/8 — the AWQ quant/engine costs API recall. It's slower

than the GGUF (no DFlash fits 2x16GB) and ~3x slower than gemma-awq (93 tok/s,

office 18/18). And it fails the real-case gate with the SAME db.CellInst

(instead of CellInstArray) defect the GGUF hit on its worst run — that defect

repeating across both weights AND both engines says it's a **Muse Glimmer

lineage property** (drifts from a reference it was given on long tasks), not a

quant artifact. The gate is the actual mask work; failing it is the disqualifier

that demoted the GGUF too.

The n=1 caveat does not save it. The real-case gate is high-variance (the

GGUF passed 1-in-4, ranging 0/7 to 7/7), so a single 0/7 does NOT settle the

gate — this AWQ could pass on a repeat. But its *best* plausible outcome

(matches the GGUF, fails the gate 1-in-4, slower, fragile nightly) is still a

demoted model that loses to the roster on everything that matters, so 2 more

passes were not worth the ~2.5 h. Removed.

Retained learnings for any future MuseGlimmer-vLLM attempt (the wiring is

gone but the engineering was real):

• Runs ONLY on the nightly vLLM ~/vllm-env-nightly (dev977, commit c2057261,

the one build with MuseGlimmerForConditionalGeneration); ${vllm_bin} (0.26.0)

lacks the arch. A vllm_nightly_bin macro + a cmd: PATH putting the nightly

bin first was the pattern (mirrors prism_llama_bin).

• --attention-backend TRITON_ATTN is mandatory (CLI flag, NOT an env var —

VLLM_ATTENTION_BACKEND is silently ignored in this nightly). The nightly's

flashinfer 0.6.17 cu130 wheel has sm89 XQA cubins but not sm120 (5060 Ti), and

no nvcc/flashinfer_cubin to JIT → flashinfer auto-select crashes at CUDA-graph

capture. TRITON_ATTN (pure-Triton, JIT, sm120-native) is the fix.

• The muse_glimmer reasoning parser splits the think block into the reasoning

field (NOT reasoning_content, per [[vllm-reasoning-key-not-reasoning-content]]);

reasoning_tokens reports 0 even when reasoning is present (counting quirk).

CoT goes to reasoning, the answer to content; at small max_tokens it hits

the cap mid-think and returns EMPTY content (the [[pocket-35b]] trap).

• DFlash drafter does NOT fit 2x16GB (OOM'd twice) — serve plain.
• Decode ~27.5 tok/s dense 30B (memory-bandwidth-bound), same ceiling as qwen38-awq.

Disk cleanup 2026-08-20: the cached AWQ weights + two orphan HF cache entries

AND the nightly env are ALL DELETED — Muse-Glimmer-30B-AWQ-INT4 (23 GiB),

Muse-Glimmer-30B-assistant (4.8 GiB, the vLLM DFlash drafter that OOM'd — the

served GGUF uses the ssk500 .gguf drafter via -md, NOT this),

Muse-Glimmer-30B-GGUF (12 KiB stub; the real GGUF lives on ssk500), and

~/vllm-env-nightly (7.9 GiB, the dev977 build — the only one with the

MuseGlimmer arch). ~35 GiB freed total (HF cache 95 -> 68 GiB). The served GGUF

on ssk500 is untouched. The nightly env is re-creatable in ~10 min from the

cu130 nightly wheel (vllm/wheels index, commit c2057261) IF a genuine

nightly-only-arch need ever returns — none exists today (NVFP4 is

hardware-blocked on this mixed sm89/sm120 box; Muse Glimmer-AWQ is removed).

The 0.26.0 serving env (~/vllm-env) is untouched.

See also [[llama-swap-setup]] for the HUP-reload-without-sudo trick used throughout,

and [[pgrep-f-self-match-deadlock]] — a pkill -f "port 9141" killed its own shell

mid-task here, the same self-match failure in a new disguise.

HEAD-TO-HEAD vs fable-fusion, SAME HARNESS (2026-08-12)

fable-fusion was re-grilled 3x on the current harness precisely because the

comparison in this file originally leaned on its pre-2026-08-10 numbers. Result:

| | muse-glimmer | fable-fusion |

|---|---|---|

| real-case GATE | 1 of 4 | 3 of 3 |

| office | ~7/9 mean (6 arms) | 5 of 6 arms 9/9 |

| 23-task mean | 21.7 | 22.3 |

| KLayout +ref | 7.0/8 | 7.7/8 |

| loop unaided | 1.7/4 | 2.7/4 |

| context | 131072 HARD CAP | 262144 |

| decode | ~50 tok/s | 30.7 tok/s |

| vision (identical 21/21) | ~135 s / ~3.5k tok | ~320 s / ~8.4k tok |

| cap-hits / runaways | 0 in 4 batteries | 2 in 3 |

SPEED FAVOURS MUSE-GLIMMER AND IT STILL LOSES. That is the correction to make

to any "it is just slower" reading: it decodes ~60% faster, finishes the agentic

round ~30% quicker, and does vision in under half the time on a third of the tokens.

It loses on CORRECTNESS, and specifically on the real-case gate — the actual mask

work — 1/4 vs 3/3.

Two demotion arguments I made originally were WRONG and are corrected by this run:

• "fable-fusion closes the KLayout loop unaided, muse-glimmer manages 0-3/4" — the

measured means are 2.7/4 vs 1.7/4. An edge, not a categorical difference.

• "it fills gemma's KLayout gap / 7-8 is decisive" — 7.7 vs 7.0 is small.

What actually justifies the demotion is the real-case gate (1/4), plus office

and the hard 131072 context. What genuinely argues FOR keeping it is stronger than

I credited: zero runaways in 4 batteries where fable-fusion had 2 in 3, and a

vision capability that is 2.4x cheaper in wall clock for an identical score.