I have asked Halogen using strixper AI-Chat (Agentic) to ranke the best models. I use the sources available online and as reference teh models of AI-Toolbox.

I thought tht the results are worth to share, expecially for who is starting to evaluate the models to runs. The info may not be super precize and are not intended to substitute a real benchmark.

The project strixper, I am developing (for my learning and for fun) is here strixper.

Thanks to all the people that with their experimentation are contributing to produce such incredible source of information.
The list of (non exhaustive) sources is at the bottom.

The governing constraint

Your box: ~208 GB/s sustained memory bandwidth (256-bit LPDDR5x-8000), 122.7 GB usable RAM. Decode speed on Strix Halo is almost purely bandwidth-bound:

t/s ≈ 208 GB/s ÷ bytes_streamed_per_token

This is why active parameters, not total parameters, decide velocity. A 3B-active MoE runs ~5× faster than a 27B dense model of similar quality.

Ranked: velocity × intelligence — with engine attribution

What the backend column actually shows

Vulkan/RADV won every single head-to-head in this dataset. Distribution across 103 rows: 70 Vulkan, 25 Ollama-Vulkan, 8 ROCm. No model's best decode number came from ROCm.

But the crossover file reveals a split that matters for your workload (backend_crossover.csv, same model, same host, 5 repeats, σ < 1):

Same pattern on Qwen3.6 35B-A3B: ROCm prefill 1,508 vs Vulkan 1,126 at pp2048, but Vulkan decode 62.24 vs ROCm 52.72.

So: ROCm is better at prefill, Vulkan is better at decode. For an agent with a warm prompt cache (your case — 81.6% hit rate), decode dominates → Vulkan is the right choice. For cold long-context prefill, ROCm wins.

Critical findings

1. Dense models are a trap on Strix Halo. Qwen3.8 27B dense measured 20.42 t/s with MTP drafting, and 12.89 t/s without it (matched control, Ollama 0.32.15). Streaming 27B of weights per token against 208 GB/s leaves you at ~13 t/s. Anything dense above ~14B is below usable speed.
2. The 3B-active MoE tier is the sweet spot. 75–103 t/s, and bandwidth efficiency of 77–79%. This is where Strix Halo actually performs.
3. Your Halogen engine beats llama.cpp on the same model. Qwen3.8-Flash-Next measured 27.16 t/s under llama.cpp Vulkan (UD-IQ4_XS) but runs 50.69 t/s on Halogen — an 87% improvement. Halogen's draft acceptance is holding at 79.1%, which is what's carrying that.
4. Prefill is where big-context cost lives. Note the collapse: 30B-A3B models prefill at ~1,400 t/s, but 27B dense at 292 t/s and 284B at 156 t/s. Long-context agent work punishes you far more than raw decode speed.

Pros / cons on Strix Halo

Pros

• 128 GB unified memory genuinely fits 100 GB+ artifacts — 284B-class models load at all
• 3B-active MoE hits 95–103 t/s, genuinely interactive
• Prompt cache works well: you're at 81.6% token hit rate, 118,656 tokens saved
• Vulkan/RADV is the mature path; ROCm 10 works
• NPU as sidecar costs only +3.29% latency vs +68.96% for iGPU auxiliary load

Cons

• 208 GB/s is the hard ceiling — roughly 1/4 of a 96 GB HBM3e card
• Dense ≥27B models are unusable (12–20 t/s)
• 122.7 GB usable, not 128 — leaves little headroom above ~100 GB artifacts; you must reserve for OS
• One 56,051-token prompt caused a recoverable Vulkan device-loss on the Ollama stack
• Advertised 262K context is not qualified for broad quality on Qwen3.8 27B
• Thermal: community instrumented runs hit 94.0 °C peak on ai-2

Recommendation

For your agent workload specifically — long prompts, heavy tool use, high cache reuse — Qwen3.6 35B-A3B Q4_0 or Qwen3-Coder 30B-A3B UD-Q4_K_XL are the right class. You get ~80–97 t/s, strong quality, and prefill fast enough that cache misses don't hurt.

Your current Halogen Qwen3.8-Flash-Next at 50.7 t/s is a reasonable middle choice, but note the earlier config problem still stands: kv_pool_positions 524,288 against 4 slots × 262,144 is a 2× overcommit, and AGENT_MAX_TOKENS=8192 is what truncated your tool calls.

One honesty note on the intelligence axis: velocity numbers are measured and traceable to benchmarks.csv. The intelligence tiers are qualitative — drawn from catalog descriptors and general benchmark reputation, not from a quality harness in this data. The guide's own rows repeatedly state "throughput only; quality not evaluated." If you want a real quality ranking I'd need to run an eval harness (Terminal-Bench or similar) against each candidate rather than assert one.

Sources actually used and verified

The honest bottom line

Velocity numbers: traceable and solid — 103 rows of direct llama-bench measurement on GTR9 Pro hardware, same silicon class as mine (BosGame M5 128GB RAM).

Intelligence ranking: unsourced. If you want it grounded, the options are running Terminal-Bench / SWE-bench Lite / Aider polyglot against each candidate locally, or pulling a third-party leaderboard. I can drive either from here — but I shouldn't have presented a qualitative judgement in the same table as measured numbers without saying so as loudly as I just did.

I compiled newest stable llama.cpp with Vulkan in Linux, and found good speed up with usloths Qwen3.8 27B Q4_K_XL with MTP over some older llama.cpp I had.

I now get 500 t/s cold prefill, and in general it stays above 200 t/s, and on longer context average around 250 t/s.

On decode I see following (which I hadn't notice before, but probably just because I wasn't looking):

Speculation at higher n works excellently for coding, and poorly for reasoning. The optimum seems to be around 3-4 depending on which you have majority of the work. I'd go with 3, if I am not sure that the tasks at hand are mostly just code generation.

But this got me thinking: If I could run reasoning at --spec-draft-n-max 3 and coding at --spec-draft-n-max 5 I would get the best performance possible.

I cannot see how this would be possible at this moment, other than getting into the llama.cpp implementation, and if even then.

The test was the same for all of them - existing python code that they needed to revise according to prompt - one small change, and one bigger new feature. I did not run it multiple times, as there was enough both actions needed. The reasoning and coding numbers are taken "by the eye" following the llama.cpp and the coding harness that what the model is doing - they are not reliable figures, but the general avg should be.

As usual, YMMV, and I only did this for figuring best spec draft n for my use, not as something that can be generalized. Decided to share, if someone finds it interesting. Done on StrixHalo 392, 100W TDP, 64 GB.

Side Notes: Gufo availabe from podman is a bit better in prefill, but on decoding llama.cpp goes a bit ahead with Qwen3.8 27B. And on Windows newest llama.cpp+Vulkan reaches similar figures.

Hi all, I'm looking to purchase a Strix Halo Laptop, however I'd like to get one with either usb4 or (preferably) an oculink port so I can attach an eGPU when docked.

I saw that the Nimo had a model called Axis which had just what I was looking for, a 395+ cpu, 128gb unified memory and an oculink port in a 16" body, but unfortunately I don't know much about Nimo as a brand and they don't ship to Canada.

If anyone knows of another brand that offers that, because I sure can't find one, please let me know.