dflash: enable Qwen3.6-27B, Qwen3.6-35B-A3B, Qwen3.5-122B-A10B, Qwen3-Coder-Next, Gemma 4 31B on Vulkan

[gboddaer]

PR #79 — Executive Summary

What this PR is

dflash: enable Qwen3.6-27B, Qwen3.6-35B-A3B, Qwen3.5-122B-A10B, Qwen3-Coder-Next, Gemma 4 31B on Vulkan

This PR makes Vulkan DFlash functional across multiple model architectures and fixes the Vulkan DFlash paths so they can run without crashes, decode failures, or 256K-context OOM failures on the tested Strix Halo setup.

---

Development history

The PR started as:

dflash: enable Qwen3-Coder-Next on Vulkan

It then evolved through several phases.

Phase 1: original Coder-Next enablement

• Coder-Next on Vulkan initially produced 0% draft acceptance.
• Fixed the Vulkan-specific path where the drafter reads target context.
• Added Qwen3Next-specific tape capture and full-block drafting.

Phase 2: sync from vulkan-dflash-cross-ring

• Pulled in 11 DFlash code files from the vulkan-dflash-cross-ring branch.
• Fixed Qwen3.6 divergence and the Coder-Next crash.
• Introduced a Qwen3.5-122B-A10B ring=1 regression: rep=12.

Phase 3: bug fixes

Three major fixes were needed:

1. ab2be17fd — 122B fix
   Removed the n_rs_seq=0 clamp for QWEN35MOE, which forced checkpoint/restore for draft rejection and caused DeltaNet recurrent-state desync → repetition.

2. efb07137c — 35B-A3B fix
   Rotated DeltaNet RS snapshots for n_seq_tokens < K. Under stochastic sampling, every step became a 1-token decode, clobbering snapshot history → multilingual gibberish with 0% acceptance.

3. ecc90d226 / later 5b0e7533c — DFlash slide/decode failure fixes
   Added crash guards and fixed the drafter KV slide path. This addressed decode failures such as drafter decode failed with 1, caused by drafter KV fill-up after failed sliding on hybrid memory.

Phase 4: testing and verification

• Added 5 new unit tests to tests/test-dflash-plumbing.cpp.
• Ran 256K context stress tests across all 5 target models.
• All 20 stress runs passed.
• Verified greedy and stochastic sampling across ring=0 and ring=1.
• Re-benchmarked after each fix to confirm no regressions.

Phase 5: documentation

• Renamed documentation from enable-dflash-qwen3-coder-next-on-vulkan.md to enable-and-fix-dflash-on-vulkan-various-models.md.
• Added root-cause evidence for the production fixes, including gdb traces.
• Documented the Gemma 4 Vulkan DFlash Flash Attention corruption issue.
• Gemma 4 workaround: use --flash-attn off.

---

Final verified status

Validated on:

• Commit: 5b0e7533c
• Branch: pr-79-sync
• Platform: AMD Strix Halo, Ryzen AI MAX+ 395 / Radeon 8060S
• Driver stack: RADV GFX1151, Mesa 25.0.7, Vulkan 1.4.309
• Memory: 96GB UMA + ~31GB system RAM overflow
• Context: -c 262144 / 256K
• Prompt: hard prompt, ~665 tokens
• Generation: 512 tokens

Result: all 20 runs passed.

• No crashes
• No OOM
• No server exits
• No drafter decode failed with 1
• No failed to slide warnings
• Greedy and stochastic runs completed

---

Final performance results

Model	Baseline gen	DFlash ring=0	DFlash ring=1	ring=1 stochastic	Result
Qwen3.6-27B	12.36 tok/s	21.72 tok/s acc .746	21.42 tok/s acc .743	14.55 tok/s acc .434	✅ Best DFlash win, 1.73× with r1
Qwen3.6-35B-A3B	42.80 tok/s	54.39 tok/s acc .705	54.97 tok/s acc .710	38.52 tok/s acc .444	✅ Strong DFlash win, 1.28× with r1
Qwen3-Coder-Next	53.22 tok/s	30.25 tok/s acc .328	46.68 tok/s acc .478	45.29 tok/s acc .284	✅ Stable, slower than baseline
Gemma 4 31B	11.33 tok/s	10.49 tok/s acc .215	10.83 tok/s acc .185	12.37 tok/s acc .564	✅ Stable; stochastic above baseline
Qwen3.5-122B-A10B	19.04 tok/s	9.67 tok/s acc .144	13.22 tok/s acc .146	16.23 tok/s acc .164	✅ Stable, slower than baseline

---

Key findings

• Qwen3.6-27B is the strongest dense-model DFlash win: 21.42 / 12.36 = 1.73×.
• Qwen3.6-35B-A3B is also a real DFlash win in the final 256K run: 54.97 / 42.80 = 1.28×.
• Qwen3-Coder-Next is stable and crash-free, but DFlash remains slower than baseline: 46.68 / 53.22 = 0.88×.
• Gemma 4 31B is stable. Greedy DFlash is near baseline, while stochastic ring=1 is slightly above baseline: 12.37 / 11.33 = 1.09×.
• Qwen3.5-122B-A10B is stable, but DFlash is slower than baseline: 13.22 / 19.04 = 0.69×.
• All tested models complete at 256K context with no crash, no OOM, and no decode failure.

---

Recommended usage

Environment	Model type	Recommendation
Vulkan-only / Strix Halo	Qwen3.6-27B	Use Vulkan + DFlash. ring=0 and ring=1 are both good.
Vulkan-only / Strix Halo	Qwen3.6-35B-A3B	Use Vulkan + DFlash for greedy 256K runs; ring=1 was best in final testing.
Vulkan-only / Strix Halo	Qwen3-Coder-Next	Use baseline for speed. DFlash is stable but slower.
Vulkan-only / Strix Halo	Qwen3.5-122B-A10B	Use baseline for speed. DFlash is stable but slower.
Vulkan + Gemma 4	Gemma 4 31B	DFlash is stable. Use --flash-attn off to avoid the Vulkan FA / Gemma 4 own repetition issue.

---

Current status

The PR includes:

• original Qwen3-Coder-Next Vulkan DFlash enablement
• vulkan-dflash-cross-ring sync
• 122B recurrent-state desync fix
• 35B-A3B stochastic DeltaNet snapshot fix
• DFlash decode-failure / slide-failure fix
• Vulkan DFlash crash guards
• unit tests in tests/test-dflash-plumbing.cpp
• 256K stress-test verification
• documentation with root-cause evidence

All 5 target models are now functional on Vulkan with DFlash.

---

Personal note

I have been dog-fooding this heavily on my own Strix Halo machine, including 256K-context runs across all 5 target models. The current PR is crash-safe and usable in real testing, not just in narrow benchmark cases. Performance benefit is model-dependent, but the Vulkan DFlash path itself is now functional.

---

Bottom line

This PR turns Vulkan DFlash from a fragile / diagnostic path into a crash-safe and usable feature on Strix Halo.

It gives clear speedups for Qwen3.6-27B and Qwen3.6-35B-A3B, while providing stability and correctness value for Qwen3-Coder-Next, Qwen3.5-122B-A10B, and Gemma 4.

[gboddaer]

Detail 1: CUDA results

If CUDA is available, the recommendation is simple:

Use CUDA, not Vulkan.

On RTX 3090, CUDA remains faster than Vulkan for Qwen3.6:

Backend | No drafter | DFlash ring=0 | DFlash ring=1 -- | -- | -- | -- CUDA | 40.56 tok/s | 54.36 tok/s | 34.46 tok/s Vulkan | 32.13 tok/s | 28.24 tok/s | 28.14 tok/s

Implications:

• CUDA baseline already beats Vulkan baseline.

• CUDA + DFlash with ring=0 gives a clear win for dense Qwen3.6:

  • 54.36 tok/s vs 40.56 tok/s

  • approximately 1.34× faster

• CUDA ring=1 should not be used currently:

  • acceptance collapsed to 2/22 = 9.1%

  • speed fell below the CUDA baseline

Recommended CUDA dense config:

GGML_DFLASH_GPU_RING=0
--spec-type dflash

So for CUDA systems: use CUDA. For dense Qwen3.6, use DFlash with the GPU ring disabled / CPU hidden capture. Do not use the DFlash GPU ring yet.

[gboddaer]

Detail 2: Vulkan-only results

For Vulkan-only systems, this PR is valuable, especially for dense Qwen3.6 on AMD UMA systems.

On Strix Halo / RADV GFX1151:

Model | No drafter | DFlash ring=0 | DFlash ring=1 -- | -- | -- | -- Qwen3.6-27B dense | 12.45 | 28.26 / 2.27× | 29.43 / 2.36× Qwen3-Coder-Next MoE | 52.86 | 34.32 / 0.65× | 47.30 / 0.89× Qwen3.5-122B-A10B MoE | 21.96 | 16.18 / 0.74× | 18.78 / 0.85×, broken repetition

Implications:

• Dense Qwen3.6 benefits strongly from DFlash on Vulkan:

  • ring=0 already more than doubles speed

  • ring=1 is slightly better than ring=0 on Strix Halo

• MoE models do not benefit from DFlash on Vulkan in these tests:

  • Qwen3-Coder-Next remains slower than no drafter, though ring=1 avoids the crash and narrows the gap

  • Qwen3.5-122B-A10B remains slower, and ring=1 has correctness issues at rep=4

Recommended Vulkan dense config:

GGML_DFLASH_GPU_RING=1
--spec-type dflash

Recommended Vulkan MoE config:

--spec-type none

unless doing experiments.

[gboddaer]

Detail 3: Policy recommendation and PR implication

CUDA available

Model type | Recommendation -- | -- Dense Qwen3.6 | CUDA + DFlash, GGML_DFLASH_GPU_RING=0 MoE | CUDA baseline unless separately proven Vulkan | Avoid if CUDA is available

Overall, this PR turns Vulkan DFlash from a mostly diagnostic / fragile path into a usable path for the main dense Qwen3.6 DFlash target, especially on AMD UMA hardware.

The Vulkan GPU ring is not universally faster, but on Strix Halo it provides the best dense-model result and avoids the CPU hidden-capture penalty.

This PR does not make DFlash universally beneficial for MoE models. For MoE, the drafter overhead and/or acceptance behavior still loses to the no-drafter baseline, and the 122B ring=1 path still has a correctness concern.

[gboddaer]

Vulkan DFlash comparison: main vs PR fixed

Strix Halo / Vulkan results. Gemma 4 31B was tested with chat template, --reasoning on, temp=1.0, top-k=64, top-p=0.95, seed=42, 1024 tokens.

Model	Case	main 85e22ea0b	PR fixed ab2be17fd	Δ / note
Qwen3.6-27B dense, n_embd=5120	baseline	12.45 ✅	12.47 ✅	≈
	DFlash ring=0	21.02 ✅	19.55 ✅	≈
	DFlash ring=1	21.07 ✅	24.03 ✅	PR GPU ring wins: 24.0 > r0 19.6; main r1≈r0, no GPU ring
Qwen3-Coder-Next MoE, n_embd=2048	baseline	53.25 ✅	53.32 ✅	≈
	DFlash ring=0	💥 CRASH	30.99 ✅	PR fixes crash
	DFlash ring=1	💥 CRASH	47.04 ✅	PR fixes crash; GPU ring beats r0: 47.0 > 31.0
Qwen3.5-122B-A10B MoE, n_embd=3072	baseline	18.63 ✅	21.80 ✅	PR baseline +17% from synced llama-model / qwen35 changes
	DFlash ring=0	18.46 ✅	15.92 ✅	PR a bit slower
	DFlash ring=1	18.39 ✅	16.47 ✅	PR fixes corruption: was rep=12 on PR pre-fix, now rep=0; GPU ring 16.5 > r0 15.9
Gemma 4 31B dense, chat template, reasoning on	baseline	11.48 ✅ rep=0, vis=368	11.47 ✅ rep=0, vis=368	≈; PR output identical to main baseline
	DFlash ring=0	💥 CRASH std::out_of_range vocab index	17.88 ✅ rep=0, vis=252, 1.56×	PR fixes crash and gives clear DFlash speedup
	DFlash ring=1	💥 CRASH std::out_of_range vocab index	16.18 ✅ rep=0, vis=189, 1.41×	PR fixes crash; coherent output, but ring=0 is faster for this Gemma run

[gboddaer]

Can someone verify and run on more hardware?

[gboddaer]

Qwen3.6-35B-A3B DFlash is broken on Vulkan on BOTH branches (main and PR)

now fixed on PR

[gboddaer]

Post-fix performance

PR fixed efb07137c, Vulkan, greedy 256 tokens.
All cases are coherent, rep=0.

Model	Arch / n_rs_seq	Baseline tok/s	DFlash ring=0 CPU capture	DFlash ring=1 GPU ring
Qwen3.6-35B-A3B	qwen35moe / 4	52.04	75.60 acc 0.827	76.88 acc 0.828
Qwen3.6-27B	qwen35 dense / 8	12.47	29.80 acc 0.835	29.94 acc 0.816
Qwen3-Coder-Next	qwen3next / 0	53.26	34.07 acc 0.754	50.09 acc 0.621
Qwen3.5-122B-A10B	qwen35moe / 4	13.92	8.20 acc 0.189	14.92 acc 0.256

Interpretation

• All 12 cases are coherent, rep=0, with no correctness regressions.

• The fix rotates DeltaNet RS snapshots for n_seq_tokens < K, which makes the affected models correct under both greedy and stochastic sampling.

• Qwen3.6-35B-A3B is the headline win: DFlash is now correct and about 1.45–1.48× faster than baseline, improving from 52.04 tok/s to 76.88 tok/s, with high acceptance around 0.83.

• Before the fix, Qwen3.6-35B-A3B produced gibberish under quickstart stochastic sampling. After the fix, both ring=0 and ring=1 are coherent and fast.

• Qwen3.6-27B dense remains the strongest DFlash win: about 2.4× faster, from 12.47 tok/s to about 30 tok/s, with acceptance around 0.82–0.84.

• MoE targets remain mixed on Vulkan:

  • Qwen3-Coder-Next is still slower with DFlash, although ring=1 is close to baseline: 50.09 vs 53.26 tok/s.
  • Qwen3.5-122B-A10B is slightly faster with ring=1: 14.92 vs 13.92 tok/s, but ring=0 is slower.

• Gemma-4 31B is unaffected by this fix because it is GEMMA4, with no DeltaNet recurrent state. Prior PR data still stands: ring=0 ~26.5 tok/s, ring=1 ~21.4 tok/s, both coherent with --reasoning on, temp=1.0.

Bottom line

This fix turns Qwen3.6-35B-A3B DFlash from broken under stochastic sampling into a correct 1.48× speedup with about 0.83 acceptance.

It also preserves correctness and speed across Qwen3.6-27B, Qwen3.5-122B-A10B, and Qwen3-Coder-Next, while making the 122B stochastic path coherent as a bonus.

Tested on Strix Halo (amd ryzen 395+) platform.****

[gboddaer]

RTX 3090 PR performance: main vs PR fixed

Benchmarked latest main 85e22ea0b vs PR / vulkan_fixes 5c4be2ba0 on RTX 3090.

Metric format: prompt tok/s / decode tok/s
Modes: ND = no drafter, R0 = DFlash ring=0, R1 = DFlash ring=1

---

Summary table

Model	Backend	Mode	main 85e22ea0b	PR 5c4be2ba0	Acceptance	Conclusion
Qwen3.6 27B	CUDA	ND	119.80 / 40.15	326.94 / 40.23	—	Baseline unchanged for decode
		R0	309.14 / 41.20	291.14 / 49.70	63/100 → 76/92	✅ PR benefits CUDA R0
		R1	304.10 / 59.20	311.63 / 37.16	75/94 → 2/22	❌ PR regresses CUDA R1
	Vulkan	ND	100.13 / 32.47	100.18 / 32.68	—	≈ unchanged
		R0	78.08 / 28.03	93.09 / 26.86	20/21 → 20/21	❌ DFlash slower than Vulkan baseline
		R1	92.45 / 28.93	93.10 / 26.87	38/43 → 20/21	❌ DFlash slower than Vulkan baseline
Qwen3.6 35B-A3B	CUDA	ND	170.92 / 141.64	420.09 / 143.31	—	Baseline decode ≈ unchanged
		R0	400.83 / 102.86	380.88 / 105.85	0/22 → 60/66	✅ Correctness improves, but still slower than baseline
		R1	284.35 / 136.76	371.31 / 110.12	60/66 → 1/22	❌ PR regresses CUDA R1 acceptance
	Vulkan	ND	190.65 / 101.90	26.74 / 104.72	—	Baseline decode ≈ unchanged
		R0	83.34 / 56.32	101.55 / 57.74	0/22 → 18/21	✅ Correctness improves, but slower than baseline
		R1	188.42 / 59.62	190.68 / 60.15	0/22 → 18/21	✅ Correctness improves, but slower than baseline
Gemma 4 31B	CUDA	ND	398.26 / 37.05	186.20 / 33.16	—	Baseline decode slightly lower on PR
		R0	533.68 / 50.47	490.47 / 46.30	73/90 → 74/97	✅ Still benefits from DFlash R0
		R1	334.64 / 55.49	349.83 / 17.17	75/95 → 1/22	❌ PR regresses CUDA R1 badly
	Vulkan	ND	83.19 / 27.83	29.89 / 27.99	—	Baseline decode ≈ unchanged
		R0	79.01 / 33.91	80.73 / 27.69	76/91 → 66/83	❌ PR loses prior Vulkan DFlash speedup
		R1	81.09 / 33.88	81.68 / 27.42	76/91 → 74/97	❌ PR loses prior Vulkan DFlash speedup

---

Per-model conclusions

Qwen3.6 27B

Benefits: CUDA ring=0.

On CUDA, PR ring=0 improves decode from 41.20 to 49.70 tok/s, with acceptance improving from 63/100 to 76/92.

However, CUDA ring=1 regresses badly: decode falls from 59.20 to 37.16 tok/s, and acceptance collapses from 75/94 to 2/22.

On Vulkan, DFlash does not benefit this model on RTX 3090. PR Vulkan baseline is 32.68 tok/s, while both DFlash modes are around 26.9 tok/s.

Recommendation: use CUDA ring=0 for DFlash. Do not use CUDA ring=1. Do not use Vulkan DFlash for this model on RTX 3090.

---

Qwen3.6 35B-A3B

Benefits: correctness improves, but performance does not beat baseline.

The PR fixes acceptance/correctness for DFlash paths:

• CUDA ring=0: 0/22 → 60/66
• Vulkan ring=0: 0/22 → 18/21
• Vulkan ring=1: 0/22 → 18/21

But DFlash is still slower than the no-drafter baseline:

• CUDA baseline: 143.31 tok/s
• CUDA ring=0: 105.85 tok/s
• Vulkan baseline: 104.72 tok/s
• Vulkan ring=1: 60.15 tok/s

CUDA ring=1 should not be used: acceptance collapses to 1/22.

Recommendation: PR is valuable for correctness, but DFlash is not a performance win for this model on RTX 3090. Use baseline unless specifically testing DFlash correctness.

---

Gemma 4 31B

Benefits: CUDA ring=0 still helps, but PR regresses several paths.

CUDA ring=0 remains beneficial versus PR baseline:

• PR CUDA baseline: 33.16 tok/s
• PR CUDA ring=0: 46.30 tok/s
• speedup: about 1.40×

CUDA ring=1 regresses badly:

• main CUDA ring=1: 55.49 tok/s
• PR CUDA ring=1: 17.17 tok/s
• acceptance: 75/95 → 1/22

On Vulkan, main had a DFlash speedup around 33.9 tok/s, but PR Vulkan DFlash falls back to baseline-like performance:

• PR Vulkan baseline: 27.99 tok/s
• PR Vulkan ring=0: 27.69 tok/s
• PR Vulkan ring=1: 27.42 tok/s

Recommendation: use CUDA ring=0 if using DFlash. Avoid CUDA ring=1. Vulkan DFlash no longer shows a benefit for Gemma 4 31B on this PR / RTX 3090 data.

---

Overall conclusion

On RTX 3090, the PR is not a universal performance win.

Clear benefits:

• Qwen3.6 27B: CUDA ring=0 improves decode.
• Qwen3.6 35B-A3B: DFlash correctness / acceptance improves substantially.
• Gemma 4 31B: CUDA ring=0 still gives a useful speedup.

Clear non-benefits / regressions:

• CUDA ring=1 is problematic across all tested models on this PR.
• Vulkan DFlash does not beat Vulkan baseline on RTX 3090 for these models.
• Gemma 4 31B loses the prior Vulkan DFlash speedup on the PR.

Policy for RTX 3090 from this data:

Model	Best tested choice	What to avoid
Qwen3.6 27B	CUDA + DFlash ring=0	CUDA ring=1; Vulkan DFlash
Qwen3.6 35B-A3B	Baseline for speed; DFlash only for correctness testing	CUDA ring=1
Gemma 4 31B	CUDA + DFlash ring=0	CUDA ring=1; Vulkan DFlash on this PR

[gboddaer]

Main vs PR #79 ecc90d226: Vulkan on Strix Halo

Setup: AMD Ryzen AI MAX+ 395 / Radeon 8060S, RADV GFX1151, Mesa 25.0.7, 96GB UMA, Vulkan 1.4.309.
main = 85e22ea0b, pr = ecc90d226. Greedy sampling, temp=0, top_k=1, 256 generated tokens.

Metric: prompt tok/s | gen tok/s | DFlash acceptance

Model	Case	Main	PR #79	PR DFlash vs PR baseline	Conclusion
Qwen3.6-27B qwen35 dense	base	124.5 | 12.45 | —	124.2 | 12.42 | —	—	Baseline parity
	DFlash r0	117.2 | 20.84 | 0.667	117.3 | 23.26 | 0.798	1.87×	✅ Strong PR win
	DFlash r1	117.6 | 21.02 | 0.667	118.5 | 23.34 | 0.798	1.88×	✅ Strong PR win; r0≈r1
Qwen3.6-35B-A3B qwen35moe	base	227.7 | 52.03 | —	219.7 | 51.65 | —	—	Baseline parity
	DFlash r0	208.5 | 39.68 | 0.036	207.9 | 46.25 | 0.656	0.90×	✅ Fixed correctness, ❌ not faster
	DFlash r1	213.8 | 40.04 | 0.036	214.5 | 46.33 | 0.658	0.90×	✅ Fixed correctness, ❌ not faster
Qwen3-Coder-Next qwen3next MoE	base	160.7 | 53.36 | —	162.0 | 53.13 | —	—	Baseline parity
	DFlash r0	CRASH	150.4 | 31.97 | 0.614	0.60×	✅ Crash fixed, ❌ slower
	DFlash r1	CRASH	151.4 | 35.69 | 0.614	0.67×	✅ Crash fixed, ❌ slower
Qwen3.5-122B-A10B qwen35moe	base	75.0 | 13.11 | —	74.9 | 22.05 | —	—	⚠️ PR baseline is much faster: 1.68×
	DFlash r0	72.8 | 16.94 | 0.018	72.5 | 17.66 | 0.055	0.80×	❌ Slower than PR baseline
	DFlash r1	72.1 | 18.54 | 0.018	71.7 | 18.39 | 0.055	0.83×	❌ Slower than PR baseline
Gemma 4 31B ⚠️ gemma4	base	118.2 | 11.76 | —	117.3 | 11.73 | —	—	Baseline parity
	DFlash r0	115.5 | 10.97 | 0.087	114.8 | 27.31 | 0.716	2.33×	✅ Major PR win under greedy
	DFlash r1	115.4 | 10.92 | 0.081	115.6 | 27.40 | 0.716	2.33×	✅ Major PR win under greedy; r0≈r1

⚠️ Gemma 4 under greedy sampling emits "own own own" repetition, identical on main baseline. This inflates DFlash acceptance. Throughput is still a valid greedy-generation measurement; for coherent Gemma 4 output, use stochastic + --reasoning on.

Findings

• No crashes on PR dflash: enable Qwen3.6-27B, Qwen3.6-35B-A3B, Qwen3.5-122B-A10B, Qwen3-Coder-Next, Gemma 4 31B on Vulkan #79. Coder-Next DFlash crash is fixed.
• Qwen3.6-27B: clear DFlash win on PR, about 1.88× over PR baseline.
• Gemma 4 31B: transformed under greedy, from broken/slow DFlash on main to 2.33× over PR baseline.
• Qwen3.6-35B-A3B: acceptance fixed, but DFlash remains slower than baseline: about 0.90×.
• Qwen3-Coder-Next: crash fixed, but DFlash is slower than baseline: 0.60–0.67×.
• Qwen3.5-122B-A10B: PR baseline itself improves strongly, 22.05 vs 13.11 tok/s; DFlash is slower than that new baseline.
• ring=0 ≈ ring=1 across the PR results; the restructure appears to narrow the ring-mode difference.

Bottom line

PR #79 fixes the broken Vulkan DFlash paths and gives strong wins for Qwen3.6-27B and Gemma 4 31B on Strix Halo.

For the larger / cheap-active MoE models, DFlash is now mostly correct but not a speed win; baseline remains better for Qwen3.6-35B-A3B, Qwen3-Coder-Next, and Qwen3.5-122B-A10B.

[gboddaer]

256K context stress test on Strix Halo

Run complete: all 20 runs passed, with no crash and no OOM.

The crash guard holds at -c 262144 under stress, including all 5 stochastic ring=1 runs.

Setup:

• PR branch: da8806748
• Context: -c 262144 / 256K
• Prompt: hard prompt, ~665 tokens
• Generation: 512 tokens
• Platform: Strix Halo, 96GB UMA
• All 5 models fit at 256K, with ~31GB system RAM overflow alongside UMA

Model	Baseline gen	DFlash ring=0	DFlash ring=1	ring=1 stochastic	Result
Qwen3.6-27B	12.33	18.20 acc .821	21.46 acc .741	14.43 acc .435	✅ Best DFlash win
35B-A3B	51.14	43.44 acc .721	36.63 acc .543	43.66 acc .534	✅ Stable, but slower than baseline
Coder-Next	52.91	34.00 acc .328	37.87 acc .478	45.59 acc .284	✅ Stable, but slower than baseline
Gemma 4	11.34	10.39 acc .231	10.95 acc .185	11.76 acc .462	✅ Stable; stochastic slightly above baseline
122B-A10B	21.65	9.78 acc .185	16.12 acc .138	16.13 acc .164	✅ Stable, but slower than baseline

Conclusions

• Correctness / stability: pass. All 20 runs completed without crash or OOM at 256K context.
• Crash guard: holds under stress, including stochastic runs.
• Memory behavior: all 5 models fit at 256K on Strix Halo, using 96GB UMA plus ~31GB system RAM overflow.
• Best performance win: Qwen3.6-27B, where DFlash ring=1 improves generation from 12.33 to 21.46 tok/s.
• MoE models: stable now, but DFlash is generally slower than baseline at 256K.
• Gemma 4: stable; greedy DFlash is roughly baseline/slightly slower, while stochastic ring=1 is slightly faster than baseline.

Bottom line: this is a strong stability result. The 256K stress path survives all tested models and stochastic cases. Performance benefit is model-dependent: clear win for Qwen3.6-27B, mostly stability/correctness value for the larger MoE cases.

[gboddaer]

256K Regression Report — DFlash Slide Fix Verification

Commit: 5b0e7533c — dflash: slide drafter KV without the GPU cross-ring (fix CPU-path decode fails)
Branch: pr-79-sync / boditec
Platform: AMD Strix Halo, Ryzen AI MAX+ 395 / Radeon 8060S, RADV GFX1151, Mesa 25.0.7, Vulkan 1.4.309, 96GB UMA + ~31GB system RAM overflow
Date: 2026-06-22

Test configuration

• Context: -c 262144 / 256K
• Prompt: hard prompt, ~665 tokens, concurrent skip-list map specification
• Generation: 512 tokens
• Result: all 20 runs passed
• No crash, no OOM, no server exit
• All 5 models fit at 256K

---

Results

Model	Baseline gen	DFlash ring=0	DFlash ring=1	ring=1 stochastic	Result
Qwen3.6-27B	12.36 tok/s	21.72 tok/s acc .746	21.42 tok/s acc .743	14.55 tok/s acc .434	✅ Best DFlash win, 1.73× r1
35B-A3B	42.80 tok/s	54.39 tok/s acc .705	54.97 tok/s acc .710	38.52 tok/s acc .444	✅ Strong DFlash win, 1.28× r1
Coder-Next	53.22 tok/s	30.25 tok/s acc .328	46.68 tok/s acc .478	45.29 tok/s acc .284	✅ Stable, slower than baseline
Gemma 4 31B	11.33 tok/s	10.49 tok/s acc .215	10.83 tok/s acc .185	12.37 tok/s acc .564	✅ Stable; stochastic above baseline
122B-A10B	19.04 tok/s	9.67 tok/s acc .144	13.22 tok/s acc .146	16.23 tok/s acc .164	✅ Stable, slower than baseline

---

Correctness

Model	Baseline	DFlash ring=1	Result
Qwen3.6-27B	208/235 unique, 89%	206/234 unique, 88%	✅ Identical quality
35B-A3B	204/233 unique, 88%	202/235 unique, 86%	✅ Identical quality
Coder-Next	182/368 unique, 49%	169/389 unique, 43%	✅ Identical quality
Gemma 4 31B	131/200 unique, 66%	6/506 unique, 1%	⚠️ Greedy own own own; known temp=0 Gemma 4 behavior
122B-A10B	157/231 unique, 68%	158/221 unique, 71%	✅ Identical quality

Gemma 4 note: the own own own repetition at temp=0 is a Gemma 4 greedy-decoding behavior seen in previous runs, not introduced by this fix. Stochastic temp=1.0 shows the same model-specific pattern with this prompt.

---

Fix verification

No drafter decode failed with 1 errors

All 20 runs had zero decode failures.

This verifies the CUDA 3090 root cause is fixed: llama_decode previously returned 1 / LLAMA_MEMORY_STATUS_FAILED_PREPARE when the drafter KV filled up. The drafter KV is now trimmed via common_dflash_align_drafter_seq_or_clear; the clearing stale drafter KV for seq=0 messages confirm the fix is active.

No failed to slide warnings

The original failure path was:

llama_memory_seq_rm(0, trim_before) returns false on hybrid memory
→ slide fails
→ drafter KV fills up
→ decode fails

This is bypassed now. The fix slides the drafter KV directly in the draft path instead of relying on the GPU cross-ring-only update_drafter_kv_cache -> trim_drafter_prefix_window chain.

No crashes

All 20 runs completed without crash, OOM, or server exit.

Correctness maintained

All models produce coherent text matching baseline quality, except for the known Gemma 4 greedy repetition behavior. No new output-coherence regression was observed.

---

Performance comparison

Model	Baseline	DFlash ring=1	Ratio	Verdict
Qwen3.6-27B	12.36	21.42	1.73×	Strong win
35B-A3B	42.80	54.97	1.28×	Solid win
Coder-Next	53.22	46.68	0.88×	Expected; cheap active decode
Gemma 4 31B	11.33	10.83	0.96×	Near baseline
122B-A10B	19.04	13.22	0.69×	Expected; weak drafter

DFlash wins on dense Qwen3.6 and small-active MoE 35B-A3B. It is slower on cheap-active MoE models such as Coder-Next and 122B-A10B, where drafter overhead exceeds the speedup from low acceptance.

---

Expected warnings

These warnings are expected and are not test failures:

1. DFlash reduced verify failed (no argmax output, top_k=N)
   Vulkan lacks GGML_OP_TOPK for k > 1, so it falls back to full-logits rejection sampling.

2. discarding 2 draft tokens and recovering
   Reduced-verify fallback recovery. Happens once per session.

3. clearing stale drafter KV for seq=0
   This is the fix in action: sliding-window trim of drafter KV.

4. target/draft SWA window mismatch
   Gemma 4 target SWA window is 1024 while drafter SWA window is 2048. Warning only.

---

Commands to reproduce

All commands run from:

/crypt/tmp/worktrees/pr-79-sync

Baseline, no DFlash

./build-vulkan/bin/llama-server -m <MODEL> \
  -np 1 -ngl all -c 262144 -b 1024 -ub 512 \
  --flash-attn on --reasoning off \
  --cache-type-k q4_0 --cache-type-v q4_1 \
  --no-cache-idle-slots --no-cache-prompt \
  --device Vulkan0 --port 18080

DFlash ring=0, CPU capture

GGML_DFLASH_GPU_RING=0 ./build-vulkan/bin/llama-server -m <MODEL> \
  -np 1 -ngl all -c 262144 -b 1024 -ub 512 \
  --flash-attn on --reasoning off \
  --cache-type-k q4_0 --cache-type-v q4_1 \
  --no-cache-idle-slots --no-cache-prompt \
  --device Vulkan0 \
  --spec-type dflash --spec-draft-model <DRAFT> \
  --spec-draft-n-max 4 --spec-dflash-cross-ctx 1024 --spec-branch-budget 0 \
  --spec-draft-ngl all --spec-draft-type-k q4_0 --spec-draft-type-v q4_1 \
  --spec-draft-device Vulkan0 \
  --port 18080

DFlash ring=1, GPU ring

./build-vulkan/bin/llama-server -m <MODEL> \
  -np 1 -ngl all -c 262144 -b 1024 -ub 512 \
  --flash-attn on --reasoning off \
  --cache-type-k q4_0 --cache-type-v q4_1 \
  --no-cache-idle-slots --no-cache-prompt \
  --device Vulkan0 \
  --spec-type dflash --spec-draft-model <DRAFT> \
  --spec-draft-n-max 4 --spec-dflash-cross-ctx 1024 --spec-branch-budget 0 \
  --spec-draft-ngl all --spec-draft-type-k q4_0 --spec-draft-type-v q4_1 \
  --spec-draft-device Vulkan0 \
  --port 18080

Stochastic variant

Append this to the ring=1 command:

--temp 1.0 --top-k 64 --top-p 0.95 --min-p 0.0 --seed 42

Request

curl -s http://localhost:18080/completion \
  -H "Content-Type: application/json" \
  -d @/tmp/test_payload.json

Greedy payload:

{
  "prompt": "<hard_prompt.txt content>",
  "n_predict": 512,
  "temperature": 0,
  "repeat_penalty": 1.0
}

Stochastic payload:

{
  "prompt": "<hard_prompt.txt content>",
  "n_predict": 512,
  "temperature": 1.0,
  "top_k": 64,
  "top_p": 0.95,
  "min_p": 0.0,
  "seed": 42,
  "repeat_penalty": 1.0
}

---

Model paths

• Qwen3.6-27B
  Target: /crypt/models/Qwen3.6-27B-Q4_K_M.gguf
  Draft: /crypt/models/Qwen3.6-27B-DFlash-Q4_K_M.gguf

• Qwen3-Coder-Next
  Target: /crypt/models/Qwen3-Coder-Next-Q4_K_M.gguf
  Draft: /crypt/models/qwen3-coder-next-dflash-q4_k_m.gguf

• Qwen3.5-122B-A10B
  Target: /crypt/models/Qwen3.5-122B-A10B-UD-Q4_K_XL-00001-of-00003.gguf
  Draft: /crypt/models/qwen35-122b-a10b-dflash-Q4_K_M.gguf

• Qwen3.6-35B-A3B
  Target: /crypt/models/Qwen3.6-35B-A3B-UD-Q6_K_XL.gguf
  Draft: /crypt/models/qwen36-35b-a3b-dflash-Q5_K_M.gguf

• Gemma 4 31B
  Target: /crypt/models/gemma-4-31B-it-Q4_K_S.gguf
  Draft: /crypt/models/gemma4-31b-it-dflash-Q5_K_M.gguf

---

Bottom line

This fix verifies the 256K DFlash slide path under stress.

All 20 runs pass with no crash, no OOM, no decode failure, and no failed slide warnings. The CPU-path drafter KV trimming issue is fixed.

Performance is model-dependent:

• Strong win: Qwen3.6-27B
• Solid win: 35B-A3B
• Near baseline: Gemma 4 31B
• Slower but stable: Coder-Next and 122B-A10B

Note on test prompt used

  You are a senior C++ library engineer. Implement a production-quality, header-only, generic C++17 component and a thorough self-contained test harness, then critically review your own work. Follow every constraint exactly.                                                                                             
                                                                                                                                                                                                                                                                                                                             
  ## Component: `concurrent_skip_list_map<K,V,Compare=std::less<K>>`                                                                                                                                                                                                                                                         
                                                                                                                                                                                                                                                                                                                             
  A thread-safe, ordered associative container backed by a probabilistic skip list with the following requirements:                                                                                                                                                                                                          
                                                                                                                                                                                                                                                                                                                             
  1. **Concurrency**: multiple concurrent readers and a single exclusive writer at a time (reader-writer semantics). Writers must not starve readers. Use only the standard library (no external deps). Provide `try_*` non-blocking variants for every mutating operation.                                                  
  2. **Operations**: `insert(k,v)` returning whether a new node was added; `erase(k)`; `find(k)`; `contains(k)`; `operator[](k)` (inserts default-constructed V if absent); `lower_bound`/`upper_bound`; `clear`; `size`; `empty`.                                                                                           
  3. **Iteration**: forward and reverse bidirectional iterators (`begin/end/rbegin/rend`), `const_iterator`, and a `snapshot()` returning a `std::vector<std::pair<K,V>>` that is a consistent point-in-time copy taken under a read lock. Iterators must remain valid across concurrent mutation of *other* keys (document  
the exact invalidation rules).                                                                                                                                                                                                                                                                                               
  4. **Range queries**: `range(low, high)` returning a lazy view over `[low, high)`; `count(low, high)`.                                                                                                                                                                                                                     
  5. **Memory**: node-level fine-grained locking per level with hand-over-hand (crabbing) locking; nodes are reference-counted so that iterators holding a node prevent its reclamation. No use-after-free under concurrent erase+iteration.                                                                                 
  6. **Metrics**: atomic counters for inserts, erases, finds (hits/misses), range scans, and max level reached. Provide `metrics()` returning a struct snapshot.                                                                                                                                                             
  7. **Configurability**: max level, probability (default 0.5), allocator via an `Allocator` template parameter defaulting to `std::allocator`.                                                                                                                                                                              
  8. **Correctness edge cases**: empty container, single-element, duplicate keys (overwrite semantics for `insert`), `operator[]` default construction cost, TTL-less (no expiration), comparator consistency, move semantics, swap.                                                                                         
                                                                                                                                                                                                                                                                                                                             
  ## Deliverables                                                                                                                                                                                                                                                                                                            
  A) The complete header-only implementation with Doxygen-style comments on every public symbol, exception-safety guarantees (basic or strong) stated per operation, and `noexcept` annotations.                                                                                                                             
  B) A `main()` test harness exercising: concurrency (spawn N reader threads + M writer threads on K distinct keys, join, assert no data races via a logical invariant checker), iterator-stability under erase, range correctness, metrics sanity, and a randomized differential test against `std::map` over 100k          
operations with seed=42.                                                                                                                                                                                                                                                                                                     
  C) A critical review: identify at least four concrete weaknesses (correctness, performance, memory, API ergonomics), explain the failure scenario for each, and propose a specific fix with a code sketch.                                                                                                                 
                                                                                                                                                                                                                                                                                                                             
  Be rigorous. Do not hand-wave. Show real code, not pseudocode, for parts A and B.                                                                                                                                                                                                                                          

[gboddaer]

Gemma 4 own own own bug — root cause found

Root cause: the Vulkan Flash Attention kernel produces corrupted attention weights during DFlash draft verification for Gemma 4’s ISWA / Interleaved Sliding Window Attention layers.

Evidence

Hard prompt, 512 generated tokens, greedy --temp 0.

Configuration	Result	Vocabulary diversity
Gemma 4 baseline + FA on	✅ Coherent C++ code	66% unique words
Gemma 4 + DFlash + FA off	✅ Coherent C++ code	64% unique words
Gemma 4 + DFlash + FA on	❌ own own own repetition	3% unique words

Why this happens

1. Gemma 4 has ISWA layers: mixed SWA and FULL attention, swa=4, full=2.
2. During normal decoding, the Vulkan FA kernel produces correct results.
3. During DFlash draft verification, the FA kernel computes wrong attention weights for the ISWA layers.
4. The corrupted attention weights cause the target model to accept bad draft tokens.
5. Under greedy sampling, the model converges to own repetition because the top-1 token becomes own.

Workaround

For Gemma 4 + DFlash on Vulkan, use:

--flash-attn off

With FA disabled, Gemma 4 DFlash is coherent and still faster than baseline:

Gemma 4 baseline:        ~11–12 tok/s
Gemma 4 DFlash FA off:   ~17–19 tok/s

Commit

• d6531e021b628e58c3d39c7256a964b0dd1f1bd9

[gboddaer]

Cross-backend comparison: Strix Halo iGPU vs W7800 eGPU

Platform / context

• OS: Debian 13 / Linux

• Kernel: 7.0.10+deb13-amd64

• UMA split: 64GB VRAM / 64GB CPU

• iGPU: Strix Halo / Radeon 8060S / GFX1151

  • Vulkan: Vulkan1
  • ROCm: ROCm0

• eGPU: AMD W7800 / NAVI31 / gfx1100 / 46GB

  • Vulkan: Vulkan0
  • ROCm: ROCm1

• Build dirs:

  • Vulkan: build-vulkan/bin/llama-server
  • ROCm: build-rocm/bin/llama-server

• Prompt: same short PI coding prompt

• Generation: n_predict=1024, temp=0.6, top_k=20

Decode = generated tokens/sec.
Prompt = prompt-processing tokens/sec.

---

Qwen3.6-27B

GPU	Backend	Config	Prompt tok/s	Decode tok/s	Draft acc	Read
iGPU	Vulkan	baseline	73.71	12.29	—	baseline
iGPU	Vulkan	ring0	59.53	18.41	46.7%	✅ helps
iGPU	Vulkan	ring1	53.46	18.77	56.5%	✅ helps
iGPU	Vulkan	ring1 stochastic	59.58	30.29	82.0%	✅ best result
iGPU	ROCm	baseline	83.94	11.76	—	baseline
iGPU	ROCm	ring0	73.32	15.76	42.5%	✅ helps
iGPU	ROCm	ring1	72.64	8.82	4.7%	❌ bad
iGPU	ROCm	ring1 stochastic	72.83	10.19	57.0%	❌ slower than baseline
W7800	Vulkan	baseline	88.50	27.23	—	best W7800 Vulkan path
W7800	Vulkan	ring0	82.53	18.90	44.9%	❌ slower
W7800	Vulkan	ring1	70.52	19.75	54.0%	❌ slower
W7800	Vulkan	ring1 stochastic	70.89	24.03*	76.0%	near baseline, but incomplete run
W7800	ROCm	baseline	78.19	18.51	—	baseline
W7800	ROCm	ring0	71.65	26.00	65.7%	✅ helps strongly
W7800	ROCm	ring1	83.06	16.61	1.2%	❌ bad
W7800	ROCm	ring1 stochastic	82.61	18.96	56.7%	≈ baseline

• W7800 Vulkan ring1 stochastic stopped at 959 generated tokens, not the full 1024, but timing was valid.

Conclusion for Qwen3.6-27B:
Best overall result is iGPU Vulkan ring1 stochastic: 30.29 tok/s. On W7800, the best practical path is Vulkan baseline at 27.23 tok/s or ROCm ring0 at 26.00 tok/s.

---

Qwen3.6-35B-A3B

GPU	Backend	Config	Prompt tok/s	Decode tok/s	Draft acc	Read
iGPU	Vulkan	baseline	135.77	52.86	—	best iGPU path
iGPU	Vulkan	ring0	130.17	42.03	58.7%	❌ slower
iGPU	Vulkan	ring1	127.90	46.79	46.6%	❌ slower
iGPU	Vulkan	ring1 stochastic	129.29	46.84	61.7%	❌ slower
iGPU	ROCm	baseline	172.67	46.12	—	baseline
iGPU	ROCm	ring0	174.03	46.64	51.7%	≈ baseline
iGPU	ROCm	ring1	175.65	43.48	0.0%	❌ bad
iGPU	ROCm	ring1 stochastic	173.95	46.33	56.0%	≈ baseline
W7800	Vulkan	baseline	156.79	73.03	—	best overall
W7800	Vulkan	ring0	140.24	47.20	47.9%	❌ slower
W7800	Vulkan	ring1	139.34	61.50	84.0%	❌ slower than baseline
W7800	Vulkan	ring1 stochastic	137.00	62.36	63.5%	❌ slower than baseline
W7800	ROCm	baseline	111.97	66.39	—	best ROCm path
W7800	ROCm	ring0	124.46	56.12	46.9%	❌ slower
W7800	ROCm	ring1	126.17	61.66	0.0%	❌ slower / bad acc
W7800	ROCm	ring1 stochastic	125.80	61.88	3.0%	❌ slower / low acc

Conclusion for Qwen3.6-35B-A3B:
Best overall result is W7800 Vulkan baseline: 73.03 tok/s. DFlash is not beneficial for this model in this matrix; baseline wins on both iGPU and W7800.

---

Qwen3-Coder-Next Q4_K_M

GPU	Backend	Config	Prompt tok/s	Decode tok/s	Draft acc	Read
iGPU	Vulkan	baseline	115.13	53.36	—	best measured path
iGPU	Vulkan	ring0	108.65	37.68	42.5%	❌ slower
iGPU	Vulkan	ring1	107.57	47.10	40.6%	❌ slower
iGPU	Vulkan	ring1 stochastic	107.70	47.42	62.4%	❌ slower
iGPU	ROCm	baseline	146.80	44.67	—	best ROCm path
iGPU	ROCm	ring0	153.21	39.34	41.9%	❌ slower
iGPU	ROCm	ring1	158.38	41.80	2.4%	❌ slower / bad acc
iGPU	ROCm	ring1 stochastic	153.88	42.43	56.6%	❌ slower
W7800	Vulkan	baseline	—	—	load OK, full run crashed	not usable yet
W7800	ROCm	—	—	—	not run; likely too tight for 46GB	not tested

Conclusion for Qwen3-Coder-Next:
Best measured result is iGPU Vulkan baseline: 53.36 tok/s. DFlash is consistently slower. W7800 Vulkan loaded but crashed during full run; W7800 ROCm was not tested and is probably too tight for 46GB.

---

Gemma-4-31B

GPU	Backend	Config	Prompt tok/s	Decode tok/s	Draft acc	Read
iGPU	Vulkan	baseline	67.97	11.41	—	best iGPU Vulkan path
iGPU	Vulkan	ring0	66.81	10.71	18.3%	❌ slower
iGPU	Vulkan	ring1	66.52	11.09	16.1%	≈ baseline
iGPU	Vulkan	ring1 stochastic	65.64	11.06	51.5%	≈ baseline
iGPU	ROCm	baseline	101.14	10.26	—	baseline
iGPU	ROCm	ring0	102.82	9.63	20.8%	❌ slower
iGPU	ROCm	ring1	100.99	8.26	10.6%	❌ slower
iGPU	ROCm	ring1 stochastic	101.86	12.31	48.2%	✅ helps
W7800	Vulkan	baseline	96.46	25.34	—	best overall
W7800	Vulkan	ring0	91.96	22.52	30.4%	❌ slower
W7800	Vulkan	ring1	92.77	21.94	31.6%	❌ slower
W7800	Vulkan	ring1 stochastic	92.65	21.97	32.9%	❌ slower
W7800	ROCm	baseline	175.45	18.41	—	baseline
W7800	ROCm	ring0	183.58	17.09	14.0%	❌ slower
W7800	ROCm	ring1	176.75	24.24	57.2%	✅ strong DFlash win
W7800	ROCm	ring1 stochastic	176.19	21.90	48.3%	✅ helps, but less than greedy ring1

Conclusion for Gemma-4-31B:
Best overall result is W7800 Vulkan baseline: 25.34 tok/s, narrowly ahead of W7800 ROCm ring1: 24.24 tok/s. DFlash only clearly helps on ROCm, especially W7800 ROCm ring1. Vulkan DFlash is slower than Vulkan baseline.

---

Best result per model

Model	Best measured config	Decode tok/s	Conclusion
Qwen3.6-27B	iGPU Vulkan ring1 stochastic	30.29	DFlash can beat all baselines, especially on iGPU Vulkan
Qwen3.6-35B-A3B	W7800 Vulkan baseline	73.03	Baseline wins; DFlash not beneficial
Qwen3-Coder-Next Q4_K_M	iGPU Vulkan baseline	53.36	Baseline wins; DFlash slower
Gemma-4-31B	W7800 Vulkan baseline	25.34	Baseline narrowly wins overall; W7800 ROCm ring1 is close

---

Backend/device conclusions

iGPU Vulkan

Best overall for Qwen3.6-27B with DFlash:

• Qwen3.6-27B: 30.29 tok/s with ring1 stochastic
• Qwen3.6-35B-A3B: baseline still better
• Coder-Next: baseline better
• Gemma-4-31B: baseline roughly equal/better

iGPU ROCm

Generally not as strong as iGPU Vulkan for decode speed:

• Qwen3.6-27B: ring0 helps
• Gemma-4-31B: stochastic helps
• 35B-A3B mostly neutral
• Coder-Next slower with DFlash

W7800 Vulkan

Strongest baseline backend for the larger models:

• Qwen3.6-35B-A3B: best overall at 73.03 tok/s
• Gemma-4-31B: best overall at 25.34 tok/s
• Qwen3.6-27B: strong baseline at 27.23 tok/s, but beaten by iGPU Vulkan DFlash
• Coder-Next: loads but full run crashed

W7800 ROCm

Mixed:

• Qwen3.6-27B benefits from ring0: 18.51 → 26.00 tok/s
• Gemma-4-31B benefits from ring1: 18.41 → 24.24 tok/s
• 35B-A3B baseline remains better
• Coder-Next not tested / likely too tight for 46GB

---

Overall conclusion

DFlash benefit is highly model-, backend-, and device-dependent.

The clearest DFlash win is Qwen3.6-27B on iGPU Vulkan, especially ring1 stochastic, reaching 30.29 tok/s versus 12.29 tok/s baseline.

For the larger or cheap-active MoE models, DFlash usually does not beat baseline. In particular:

• Qwen3.6-35B-A3B: W7800 Vulkan baseline is best.
• Qwen3-Coder-Next: iGPU Vulkan baseline is best.
• Gemma-4-31B: W7800 Vulkan baseline is best, but W7800 ROCm ring1 is close and shows a real DFlash gain over ROCm baseline.

Practical recommendation from this matrix:

Model	Recommended config
Qwen3.6-27B	iGPU Vulkan DFlash ring1 stochastic, or W7800 Vulkan baseline if avoiding DFlash
Qwen3.6-35B-A3B	W7800 Vulkan baseline
Qwen3-Coder-Next Q4_K_M	iGPU Vulkan baseline
Gemma-4-31B	W7800 Vulkan baseline; W7800 ROCm ring1 is the best DFlash path