Qwen3.6-35B-A3B emits garbage tokens and gpt-oss-20b crashes on Gorgon Point (Ryzen AI 9 HX 470); HRX source build crashes in qwen3_npu.dll

Qwen3.6-35B-A3B emits garbage tokens and gpt-oss-20b crashes on Gorgon Point (Ryzen AI 9 HX 470); HRX source build crashes in qwen3_npu.dll

Summary

On a Ryzen AI 9 HX 470 (Gorgon Point, XDNA2) all dense models run correctly
through FLM, but:

1. qwen3.6-moe:35b-a3b produces garbage tokens while telemetry stays healthy.
2. gpt-oss:20b crashes the server process during prefill.
3. A source build of current main with FLM_USE_HRX=ON crashes in
   qwen3_npu.dll (0xC0000005) while loading any model, including
   qwen3:0.6b, which works fine on the released 1.0.1 binary.

Both failing models are the two MoE models in the catalog. Dense models of
0.6B, 8B and 9B are fine on the same machine, same runtime, same session.

Environment

item	value
CPU / NPU	AMD Ryzen AI 9 HX 470 w/ Radeon 890M — Gorgon Point, XDNA2, 55 INT8 TOPS
NPU driver	first 32.0.203.314, later updated to 32.0.20101.3760 (NPU_RAI_376_WHQL, dated 2026-04-04)
RAM	64 GB (61.6 GB visible)
OS	Windows 11 Pro, build 26200
FLM (release)	v1.0.1, installed from flm-setup.msi, SHA-256 verified against the GitHub asset digest
FLM (source)	main, built locally as v1.0.2, MSVC 19.51 (VS 2026 Build Tools), CMake 4.3.1, Ninja 1.13.2, Rust 1.97.1
flm validate	NPU: XDNA2, driver reported correctly in both driver versions

What works

model	result
qwen3:0.6b	coherent output, ~0.8 s for a short answer
qwen3:8b	coherent; on a 12-item classification test: 10/12 correct, 2.7 s per item
qwen3.5:9b	coherent; 10/12, 2.4 s per item, ~6.5 tok/s decode
Qwen3-8B-Hybrid (Lemonade / OGA hybrid)	coherent; 9/12, 1.8 s per item

So the NPU, the driver and the dense paths are all healthy on this machine.

Failure 1 — qwen3.6-moe:35b-a3b: garbage tokens, healthy telemetry

Prompt: Яка столиця України? Відповідай одним словом. (Ukrainian, "What is the
capital of Ukraine? Answer in one word.")

Output, verbatim:

)$"!56789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop3)$"!56789:...

Second run, --ctx-len 1024 --prefill-chunk-len 256, 46.8 GB RAM free:

////////////////////////////////////////////////////////////

Reported usage for that call:

{"prompt_tokens": 20, "completion_tokens": 200,
 "prefill_speed_tps": 10.46, "decoding_speed_tps": 13.84,
 "finish_reason": "stop"}

The pipeline therefore runs at the expected speed and emits invalid tokens.
That reads as a numerical/kernel problem rather than a resource problem.

flm pull qwen3.6-moe:35b-a3b --force re-downloaded the model
(All files verified successfully); output unchanged.

Failure 2 — gpt-oss:20b: process dies during prefill

Last lines before the process disappears (client then gets connection reset,
then refused):

[🟢 ]  NPU Locked!
[FLM]  Start prefill...
[FLM]  Prefill chunk 1/1 with 73 tokens

Reproduced with defaults and with --ctx-len 1024 --prefill-chunk-len 256 --pmode balanced.

Failure 3 — source build with FLM_USE_HRX=ON crashes in qwen3_npu.dll

Motivation: trying the HRX backend as a workaround for failures 1–2.

Build steps (all succeeded):

git clone --depth 1 https://github.com/ROCm/FastFlowLM.git
git submodule update --init --recursive --depth 1
hrx-integration/fetch-hrx-release.ps1          # SHA-256 verified
vcpkg install boost-program-options boost-beast boost-asio curl ffmpeg fftw3 --triplet x64-windows
cmake --preset windows-vs18 -DFLM_USE_HRX=ON ^
      -DCMAKE_PREFIX_PATH=<hrx package prefix> ^
      -DCMAKE_TOOLCHAIN_FILE=<vcpkg>/scripts/buildsystems/vcpkg.cmake ^
      -DCMAKE_CONFIGURATION_TYPES=Release
cmake --build build --config Release --parallel

flm.exe (v1.0.2) links and runs: flm version and flm validate both work
and report NPU: XDNA2.

But flm serve <any model> dies while loading. Windows Application log:

Faulting application name: flm.exe
Faulting module name: qwen3_npu.dll
Exception code: 0xc0000005

This happens with qwen3:0.6b as well — a model the released 1.0.1 binary
runs correctly on the same machine seconds earlier.

Tried, no change:

• copying the HRX kernels from src/lib/hrx and hrx.dll next to the binary;
• using the repository's own src/xclbins (219 files) instead of the
  installed 1.0.1 set (209 files);
• rebuilding with -DNPU_VERSION=32.0.203.376 instead of the 32.0.203.304
  pinned in CMakePresets.json, to match the installed driver.

Ruled out for failures 1–2

hypothesis	how it was tested	result
low memory	rerun with 46.8 GB free	identical garbage
context length	1024 / 2048 / 4096	identical
power mode	performance and balanced	identical
corrupt download	flm pull --force	identical
stale runtime	0.9.25 (via Lemonade) → 1.0.1	identical
stale NPU driver	.314 → 32.0.20101.3760 (WHQL, 2026-04-04) + reboot	identical
transient load state	three clean restarts in a row	identical each time

The message Still some invalid buffer, last try! reported in a similar issue
never appeared in any of our logs.

Questions

1. Is the MoE path validated on Gorgon Point, or only on Strix / Strix Halo
   / Kraken? Both MoE models fail here while every dense model works.
2. For a control build with FLM_USE_HRX=OFF, the configure step requires XRT
   headers (xrt/xrt_bo.h). Which XRT package/version is expected on Windows?
   Without it we cannot tell whether failure 3 is HRX-specific or a mistake in
   our build.
3. Which NPU_VERSION should be passed when the installed driver is
   32.0.20101.3760? The preset pins 32.0.203.304.

Happy to run any diagnostic build or collect further logs — the machine is
available and the failures are 100% reproducible.

Start by reproducing the failures with flm validate and flm serve, comparing dense and MoE models on the reported Gorgon Point setup. Inspect CMakePresets.json, src/lib/hrx, src/xclbins, and the HRX build path around the qwen3_npu.dll crash. Done means determining whether the MoE failures and HRX crash share a cause and documenting or fixing the confirmed failure path.