[chizamd]

Moves the core backend to ryzenai-corelib 0.53.0, adds Qwen3.8-27B, takes Qwen3.6-35B-A3B to its Q4_G32 file, and runs every core model on paged attention up to the most corelib runs it at, AMD's 4-bit GGUFs by default. Thirteen commits, and main merged in at f37cdd29.

Model repositories: preferred_source pins amd/Qwen3.8-27B-Q4_G128-GGUF at deab6eaf and amd/Qwen3.6-35B-A3B-Q4_G32-GGUF at 53a2155b (private, like the other amd/*-Q4_*-GGUF); every file there matches model_info.json's size and sha256.

Commits

1. feat(core): run Llama 3.2 1B/3B and 3.1 8B on corelib's llama model (Anjul Gurmukhani) — the Llama core tags, not yet on main; the commits below build on it.
2. test(core): build the corelib frontend harnesses against upstream's chat library and prefix cache, 3. test(core): stub the sampler seed/window setters and the engine state tables, 8. test(gemma4): stub gemma4e_npu_state_api — the core frontend test harnesses link again against main's prefix slots and sampler.
3. feat(core): move to ryzenai-corelib 0.53.0. corelib splits a model from its sessions (0.48.0): create_model_from_path and model_create_session replace model_weights_create_path and model_create, and forward, reset, model_get_info and the state calls take the session; a larger context opens a new session of the same model rather than re-reading the weights. get_hardware_context is gone (0.53.0): each stream opens its own context on a device corelib keeps, so flm opens its own device for the other families and corelib_device.hpp goes; the core backend comes up only where ryzenai_corelib_npu_usable() says so, since corelib now runs a session on the GPU or the host on a refused NPU stack. flat_mha_bf16 and paged_mha_bf16_enum_kernels leave the function table (0.37.0).
4. feat(core): Qwen3.8-27B, Qwen3.6 at Q4_G32, each model to its paged maximum.
   • qwen3.8-core:27b runs on corelib's qwen38 under the qwen3.8-mtp family's Qwen3_8MTP frontend, which reached restore()/checkpoint() through a cast to the FastFlowLM engine (null for a core engine) and now goes through the causal_lm. It prefers the Q4_G128 corelib runs on the NPU, converted from amd/Qwen3.8-27B_gpuep_1.0_gpu_128 at 9b37cf56 (sha256 as corelib's qwen38.md records), falling back to unsloth's public Q4_0, which corelib runs on the GPU.
   • qwen3.6-moe-core:35b-a3b prefers its Q4_G32, from amd/Qwen3.6-35B-A3B_gpuep_1.0_gpu_128 at c2fdd896, over the public Q8_0.
   • Limits and defaults below; Llama, Qwen3, Phi-4-mini and Gemma 4 continue a later turn from the page it starts in instead of from 0, Qwen3.5 restores a snapshot instead of replaying.
5. fix(core): retry a failed corelib pass from the start; warn past Qwen3.6's 32768. corelib fails only the call that failed, and a 4096-row paged prefill can intermittently not complete (corelib's PAGED_PREFILL_PREEMPTION_TIMEOUT); the engine was poisoned on the first failure. It now resets the session and runs everything again from position 0, once. A Qwen3.6 context past 32768 loads with a warning.
6. docs(core) — qwen.md lists every -core tag's file, fallback, limit, default and known limits; phi.md drops the 4096 ceiling.

	limit	default
Qwen3	32768	32768
Llama 3.x, Phi-4-mini	131072	131072
Gemma 4	131072	65536 (PAGED_ATTENTION_POSITION_WRAP past 65535)
Qwen3.5, Qwen3.6, Qwen3.8	262144	32768 (PAGED_DECODE_PAGE_DRIFT)

With an HF token that reads AMD's repositories every tag but Qwen3-0.6B and the Llama tags pulls a 4-bit GGUF; those have only a Q8_0 (corelib's llama reads Q8_0 only), refit to 4-bit groups on load.

9. chore(core): pin Qwen3.8 and Qwen3.6's AMD Q4 GGUFs to their published commits.
10. feat(platform): ask corelib which NPU generation this machine has. flm list offered whatever default_npu_platform() was compiled to: dev04 in every corelib build, aie2p in every other. A corelib build now asks corelib once per process: its AIEM is dev04, and AIE2P, none, or a corelib that cannot be loaded is aie2p; a build without corelib answers aie2p, as every dev04 model is a corelib one. corelib reads the device itself, so FastFlowLM holds no table of devices, IDs or geometry. The question goes through ryzenai_corelib_testing_npu_arch (included after the version pin) until corelib's public header names the architecture. On aie2p, flm no longer reports corelib unavailable on every run.
11. test(phi4): count the prefill's sample toward the budget — #870's _shared_generate counts the token the prefill samples toward generated_tokens and the length limit, so two phi4_core expectations move by one (main fails the same two).
12. fix(validate): check the NPU stack on aie2p in a corelib build too. flm validate in a corelib build answered checks_skipped and ready on any NPU, the skip decided at compile time; Lemonade gates FastFlowLM on validate, so on XDNA2 it no longer checked the driver, the firmware or memlock. aie2p now runs the same checks as a build without corelib, before the device is opened, as there.
13. fix(validate): ask corelib whether a dev04 NPU can run, rather than skip. The stock checks hold an XDNA2 device ID, driver line, firmware and column count against FastFlowLM's own kernels, so they do not apply to dev04; corelib's own gate does. validate brings corelib up as the core backend does: XRT loads, and the NPU stack is one corelib supports (on Windows, XRT and the NPU driver at corelib's minimums), opening no context. ready is that, and memlock on Linux; the JSON reports corelib_npu_ok, and corelib_error when false, in place of checks_skipped.

The merges of main keep #863's prefix slots in Qwen3_8MTP::insert and calls restore()/checkpoint() there through the causal_lm, as commit 5 does; model_info.json takes main's and adds this branch's six keys; automodel.cpp takes #870's _shared_generate, whose single pop_back on every stop but EOT replaces the two this branch had.

Testing

On this branch after the merge: core_model 4/4, phi4_core 5/5, model_backend 1/1, gemma4_core 3/3, llama_core 1/1, model_list_platform 1/1, chat_continue 1/1, against the 0.53.0 headers; flm.exe builds with -DFLM_ENABLE_CORE=ON. Platform detection: on an AIE2P (Strix) machine a corelib build lists the 51 FastFlowLM models and no -core one; on an AIE4 machine it lists the 14 -core models only. flm validate --json on that AIE2P machine, whose NPU driver 32.0.203.281 is below the 32.0.203.304 minimum, now reports npu_driver_ok: false, ready: false instead of skipping; on the AIE4 machine it reports npu_platform: dev04, corelib_npu_ok: true, ready: true.

On an AIE4 (Medusa) test machine (XRT 2.27.0, NPU driver 10.1.0.3575), the same commits on an internal branch, with another user's processes on the NPU for most runs: test_real_corelib passes; every -core tag at its default context answers three greedy prompts correctly (Qwen3.8 at 5.5 tok/s decode, Qwen3.6 at 32.8); two-turn passkey recall across pages is right for Qwen3-4B, Qwen3.5-9B, Qwen3.6, Gemma 4 E2B, Llama 3.2 3B and Phi-4-mini; Phi-4-mini recalls a passkey after ~96k tokens.

Known limits, each reproduced through corelib's own runner too, so corelib's: Qwen3.6 past 32768 and Qwen3.8 on long prompts can return ! repeated (Qwen3.8 intermittently, from about 10k tokens), and so did Llama 3.2 3B on a ~96k-token prompt of one repeated sentence. qwen.md lists them.