Qwen3.6-35B-A3B on Strix Halo: one flag buys 22% prefill, and my own GPU power advice was wrong

Qwen3.6-35B-A3B is this box's production workhorse: Q8_0, served at --parallel 6 with 256K context split across agents, because the primary workload here is four-plus parallel coding agents, not single-user chat. A tuning session on it produced one clean performance win and one uncomfortable reliability finding. The second corrects advice this blog published.

The method behind both was the same: one variable at a time, real before/after measurement on this exact model at this exact concurrency, and no community number (or previously written-down claim) trusted over an actual measurement. The benchmarks wrapped llama.cpp's own tools, with provenance (kernel, container digest, exact command) captured per run.

Finding 1: -ub 1024

Correction, same day: the first version of this post claimed +25-30%, comparing runs taken on opposite sides of the GPU power-state change described in Finding 2. That state change is itself worth 2.4-4.9% on this machine, so the comparison was confounded and the number inflated. The table below is the clean same-state comparison (both runs at the same governor setting, three minutes apart). The append-only findings log that caught this is the subject of the next post.

Production had never set the ubatch size, so it ran llama.cpp's default of 512. Raising it to 1024, measured across the real concurrency curve with q8_0 KV cache, aggregate prefill:

The gain is remarkably uniform, +21.5% to +22.3% across every row with a same-state baseline (the baseline run died 6 rows in when the machine crashed, so pp8192 at c=4/c=6 lack a clean before). Decode stayed flat within the noise band, exactly as expected: ubatch governs prefill compute-buffer sizing and does not touch the decode path. For this workload, prefill is the number one axis; coding agents re-send long, growing contexts every turn. One flag, ~22%, no downside. Applied to the production conf, validated with a live completion and a tool-call test through the real llama-swap serving stack, shipped.

Finding 2: the forced-high GPU governor, retracted

Mid-session, the machine hard power-cut, the second such crash in days and the seventh since April, with the cadence accelerating: two in two months, then four or five in three weeks. The signature is identical every time. The kernel log goes silent, the journal keeps ticking routine heartbeats, then simply stops: no panic, no shutdown sequence, which is the classic shape of a firmware-level critical cut before the OS can log anything. The two most recent crashes both carried an "internal CPU thermal limit was tripped" flag in the AMD platform reset-reason register, with the caveat that this register is sticky and cumulative, so it is supporting evidence, not proof.

The root-cause candidate surfaced during the investigation: gpu-power-high.service, which locks power_dpm_force_performance_level to high at boot. Checking the actual clock tables showed what that really does on this machine: GPU clock pinned at a fixed 2900 MHz around the clock, at idle, not just under compute.

That service exists because this blog put it there. The gotchas post and the setup guide both recommend forcing high persistently, on the claim that the auto governor costs up to 50% throughput. Here is the uncomfortable part: that number came from community documentation, and going back through my own notes, I never measured it. No before/after exists. The tuning skill's own reference material flags forcing high as a diagnostic, not a tune, and my config had it locked anyway, on an unverified claim.

Switching to auto and disabling the service had an immediate, measured effect: idle package power dropped from 27-29W to 11W, roughly 60% less standing power and heat, on a machine that idles most of every day. Whether auto costs any throughput under real load is now an open measurement (DPM should boost clocks under sustained compute on its own), and it is next on the list, but the direction of the error is already clear: I was paying a continuous thermal and power tax for a benefit I had never verified, on a machine with an accelerating hard-crash habit whose evidence points thermal. Both published pages now carry a retraction note.

Benchmarking resumed only after the machine was inspected, with live kernel-fault monitoring and continuous sensor logging running throughout; temperatures stayed nowhere near limits for the rest of the session.

The takeaway

Same discipline, two payoffs in one session: a 22% prefill win from measuring a default nobody had questioned, and a reliability fix from finally measuring a "fact" this blog itself had published. Measurements beat documentation, and that includes your own documentation. The unverified claim you wrote down a few months ago is exactly as suspect as the unverified claim you found on a forum, and considerably more dangerous, because you trust it more.

Reproducibility: AMD Ryzen AI MAX+ 395 (Radeon 8060S, gfx1151), 128 GB unified memory, ROCm 7.2.4 container, Qwen3.6-35B-A3B Q8_0, -fa 1 --no-mmap -ngl 999 -ctk q8_0 -ctv q8_0, llama-batched-bench sweeps at pp 2048/8192, tg 128, concurrency 1/2/4/6. The change shipped to production: -ub 1024. Governor: auto (default), gpu-power-high.service disabled.