MoEspresso coder trades at 2.455:1 NLL

The artifact’s NLL figures encode a 2.455:1 specialization exchange rate: each unit of coding-quality gain costs 2.455 units of general-language degradation against the stated baseline. Expert pruning simultaneously raised the activated-parameter fraction from roughly 4.58% to 6.37%, which bounds how much of the removed 80B was actually idle on coding inputs.

What the artifact claims

The steadfastgaze coder package derives from DeepSeek-V4-Flash-0731 via MoEspresso expert pruning and mixed-precision quantization. Every figure below is attributed to the artifact; the studio has not verified these measurements.

Attribute	Figure	Conditions per artifact
Reference package safetensors	84.355 GB	MoEspresso V2, 2.37 bpw, unpruned
Coder package safetensors	56.831 GB	MoEspresso V2, expert-pruned, mixed quant
Safetensors reduction	32.63%	Model safetensors only; total package is 56.869 GB
Parameters removed	~80B	Approximate; “about” per artifact
Parameters retained	~204B	Approximate; “about” per artifact
Active parameters per token	~13B	Approximate; coder package only
Experts per learned-router layer, original	256	40 learned-router layers
Experts retained per learned-router layer	176	Same 40 layers; 3 hash-routed layers keep all 256
Experts selected per token	6	Router policy unchanged
WikiText NLL delta	+0.25170	vs unpruned all-IQ1 no-REAP baseline
Code NLL delta	−0.10250	Same baseline; not vs the 2.37 bpw package
Routed projection quantization	32 IQ1_S_R4, 64 IQ2_KS, 33 IQ2_K	129 routed projection cells total
Denser model weights	q6_K	Non-routed layers
Serving engine required	MoEspresso 2.1+	llama.cpp, transformers, and mlx-lm explicitly excluded

Analysis

Active-parameter fraction

All three parameter counts carry approximate language in the artifact. Treating them as exact for bounding: 13B active from a retained pool of 204B, 80B pruned from an implied original of 284B.

$$f_{\text{active}} = \frac{N_{\text{active}}}{N_{\text{retained}}} = \frac{13\,\text{B}}{204\,\text{B}} \approx 6.37\%$$

The pre-pruning fraction against the implied 284B total:

$$f_{\text{active,pre}} = \frac{13\,\text{B}}{284\,\text{B}} \approx 4.58\%$$

At $6.37 / 4.58 \approx 1.39\times$, the pruned model exercises a 39% larger fraction of its loaded parameter budget per token. What that means depends entirely on what the removed experts were doing. If the 80B pruned experts were genuinely near-zero-activated on coding inputs — the premise the −0.10250 code NLL figure partially supports — then $N_{\text{active}}$ is unchanged and the denominator shrinks cleanly. If they contributed even occasionally, the active count has silently shrunk and the fraction rise is partly an artefact of miscounting. The two cases are not distinguishable from the published figures.

A second utilization figure appears at the per-layer level. Each learned-router layer draws 6 experts from 176 rather than 256:

$$\frac{6}{176} = 3.41\% \quad \text{vs} \quad \frac{6}{256} = 2.34\%$$

The ratio is $256/176 = 1.45\overline{45}$, so each retained expert slot is 45.5% more likely to be activated per token. That load concentration is how sparse pruning tightens the routing distribution without expanding the active-parameter count — the same six selections now draw from a smaller pool, so each retained expert sees a higher activation rate during both training and inference.

NLL specialization ratio

Two NLL deltas, both against an unpruned all-IQ1 no-REAP baseline. The exchange rate follows directly:

$$\rho_{\text{spec}} = \frac{\Delta\text{NLL}_{\text{wiki}}}{\left|\Delta\text{NLL}_{\text{code}}\right|} = \frac{0.25170}{0.10250} \approx 2.455$$

This ratio is derived here from the two published figures; the artifact does not state it. A value above 1.0 means the specialization is asymmetric: coding quality improves less than general-language quality degrades. Whether 2.455 is acceptable depends on token-frequency weighting in the target workload. In a coding-agent loop where tokens are predominantly code, comments, and stack traces, the weighted average NLL impact lies much closer to −0.10250 than to +0.25170. The artifact’s warning — “not a smaller general-purpose replacement” — maps directly onto this asymmetry.

Size reduction decomposition

The 32.63% safetensors reduction has two components the artifact does not separate. Parameter count reduction alone contributes $80 / 284 \approx 28.2\%$. The residual $32.63 - 28.17 \approx 4.5$ percentage points come from the quantization mix shifting toward lower bit-widths on retained cells relative to the 2.37 bpw baseline. This is a fixed-rate scheme (IQ1_S_R4 through IQ2_K on routed cells, q6_K elsewhere); for context on variable bit-rate quantization at comparable depths, see our buun-llama-cpp VBR field note.

What cannot be concluded

Both NLL deltas are against an “unpruned all-IQ1 no-REAP baseline,” not the 2.37 bpw package used as the size reference. No placement of the 2.37 bpw package on that same NLL scale appears in the artifact, so the coder package cannot be ranked against it on quality from the published numbers. If the 2.37 bpw package already carries a WikiText NLL deficit relative to fp16 weights, the +0.25170 here may compound with that existing gap — or partially cancel if REAP compensation shifts the distribution favorably. Neither direction can be resolved without a shared reference point, and the studio has not run comparative evaluations.

What this means for the studio’s shipped work

Itria uses llama.cpp with a Metal backend. The artifact is unambiguous: MoEspresso 2.1+ is the sole serving engine, and llama.cpp will not load these files. Whether 56.831 GB fits in a Mac’s unified memory pool is a separate question and currently moot — engine compatibility has to resolve first. The M4 Max bandwidth measurements from our hardware decode field note confirm 400 GB/s is available on that platform, but bandwidth is not the binding constraint here — engine compatibility is.

The figure that carries forward is the ~13B active-parameter count. Our Qwen3.6-35B analysis found ≈11.2B active parameters per pass on that architecture; the coder package’s ≈13B is in the same band. Any itria-compatible model at this active-parameter scale would face a comparable per-token compute floor. The per-layer utilization analysis also implies that a 176-expert pool with 6 active selections behaves closer to a 13B dense model at throughput time than to a 204B one — the per-token weight reads are bounded by the active count, not the retained total.

For the 2.455:1 exchange rate: if a similar pruning-plus-specialization step were applied to a model in the itria catalogue, a 0.1-unit code NLL improvement would cost approximately 0.25 units on general tasks. Whether that trade is acceptable depends on the app’s token mix between code and prose, a parameter the studio controls at the product level.

---

Method: this note was drafted by us.anthropic.claude-sonnet-4-6 from two sources — the published README of steadfastgaze/DeepSeek-V4-Flash-0731-Coder-56.8GB-MoEspressoV2 and this studio’s own published measurements, linked above. Before publication an automated gate re-checked every extracted claim against the source document (11 claim(s) and 0 quantity(ies) verified) and every claim-shaped number in the draft against that evidence (18 derived from it, 24 row(s) supplied from our own tables). The studio has not re-run steadfastgaze/DeepSeek-V4-Flash-0731-Coder-56.8GB-MoEspressoV2’s benchmarks; figures attributed to it are its own.

FAQ

Can this model run on a Mac with 64 GB of unified memory?

The safetensors are 56.831 GB, which fits within 64 GB. The artifact states MoEspresso 2.1+ is the only engine that can serve these files and explicitly excludes llama.cpp, transformers, and mlx-lm. Whether MoEspresso supports Apple Silicon or the Metal backend is not stated in the artifact, and the studio has not verified this.

Is the 32.63% size saving mostly from parameter pruning or quantization?

Parameter count reduction accounts for roughly 28.2% (80B removed from an implied 284B), leaving approximately 4.5 percentage points attributable to the quantization mix shifting toward IQ1/IQ2 tiers on retained cells. The artifact does not decompose the two contributions, so neither component can be credited with the full reduction from the published numbers alone.

Does the −0.10250 code NLL improvement mean the coder package beats the 2.37 bpw package on code?

Not from the published figures. Both NLL deltas are against an "unpruned all-IQ1 no-REAP baseline," not the 2.37 bpw package used as the size reference. Where the 2.37 bpw package sits on that same scale is not reported, so no direct comparison between the two packages can be made from the available numbers.

Why is the ~13B active count so much lower than the ~204B retained count?

At each token, the router activates only 6 of the 176 retained experts per learned-router layer; most of the 204B parameters sit idle in any given forward pass. The selection count of 6 is unchanged from the unpruned model — only the pool from which they are drawn has shrunk from 256 to 176. Active-parameter count is governed by the selection policy, not the retention policy.