[firetussin]

Adds official tools/strata_bench.py results from an RX 6700 XT 12 GB, Ryzen 5 3600 and 32 GB RAM: six model/quant combinations at 32K and 64K, a Qwen UD-Q4_K_M speed control, and the separately labeled initial 32K Qwen run. Includes all 15 upstream suite reports, per-request JSON, client timing output, launch settings, model hashes, native gfx1031 HIP build metadata and reproduction notes.

Measured source: 26e4cb5, engine 0.1.45. The main profiles explicitly reserve 1024 MiB VRAM. The initial 64K readiness failure is disclosed without presenting it as an official benchmark run. The benchmark's AMD hardware detector left GPU fields empty and generated cpu-labeled directories; the original outputs are retained and the externally verified hardware and cgroup limits are documented separately. Missing static expert-profile hashes are marked unavailable.

Validation: 60 copied upstream artifacts checked byte-for-byte against the collected evidence; all 15 completed stages have exactly one report; reproduction metadata and relative links checked; staged files restricted to the report directory and its community-guide link. No engine or benchmark-tool code changes.

This submission contains only the official upstream speed suite and necessary reproducibility metadata. Custom practical/coding evaluations, dossier tests, calibrated-context follow-ups, private reports, charts and the private evidence archive are excluded. It makes no general accuracy claim or isolated engine-kernel comparison.

[VecSzn]

Thanks, merged (01789a6). It's the first full suite on an RDNA2 card for these models, and it's kept carefully.

The "cpu" directory names: strata_bench.py looked for an AMD card only through rocm-smi, which ROCm from AMD's wheels doesn't have. 6798e59 reads the card from the amdgpu driver's sysfs files instead, as the server does, so a run from main names the RX 6700 XT.

The memory-access fault at the 64K start without an explicit reserve: could you post the engine log of that start (the lines of strata-<model>.log from the start to the error) and the config? A user with an 8 GB laptop saw a similar fault past 4,096 prompt tokens with --kv q8_0 on Windows, and I couldn't reproduce either on Linux with an NVIDIA card, so the AMD log would help.

[firetussin]

Thanks for merging and for the AMD hardware-detection fix. Here is the archived 64K failure you asked for.

One clarification to our earlier shorthand "64K readiness failure": the server loaded successfully and the first tiny smoke request succeeded (26 input tokens, 3 output tokens, response 12). The engine then faulted during the two-request readiness smoke test; the second request returned HTTP 503. This happened before the official suite, with a 65,536-token configured window, not a 64K prompt. Both requests used max_tokens=128, temperature=0, seed=12345, and reasoning_effort="none".

Environment: RX 6700 XT 12 GB, Ryzen 5 3600, 32 GB installed RAM; unprivileged Debian 13 LXC with Docker. Source 26e4cb5df7996edfb5ff549a63b82d8581e1e658, engine 0.1.45, locally built native HIP gfx1031. Model: Qwen3.6-35B-A3B UD-Q3_K_M. No explicit VRAM-reserve flag and no --kv q8_0 override were passed; the full arguments are below, including --kv-whole and --tail-skip 6.

Only the experiment-directory prefix and internal container hostname have been replaced with placeholders. GPU addresses, kernel name, launch arguments, timestamps and all error lines are unchanged. These excerpts were checked against the frozen evidence checksums; no new reproduction was run.

Complete engine log, start through error

[strata] 2026-10-19 06:39:43 engine started: <experiment>/upstream/engine-poly/strata-poly --serve --model <experiment>/data/models/qwen36-UD-Q3_K_M/Qwen3.6-35B-A3B-UD-Q3_K_M.gguf --max-context 65536 --expert-profile <experiment>/results/qwen36-ud-q3_k_m-ctx65536/out/expert-profile.txt --conversation-cache-mib 0 --tail-skip 6 --kv-whole --threads 8
strata-poly: loaded in 2.7 s; 5238 of 10496 routed experts in VRAM (6.8 GiB), 8 CPU threads
strata-poly: tail skip 6: an expert outside VRAM that every token of a window ranks at place 7 or later among its experts is left out; STRATA_ROUTE_TAIL_SKIP=0 turns it off
VGPU=0x594c722b8e80 SWq=0x7e4c8c6f6000, HWq=0x7e4255a00000, id=2
	Dispatch Header =0xb02 (type=2, barrier=1, acquire=1, release=1), setup=1
	grid=[5120, 1, 1], workgroup=[256, 1, 1]
	private_seg_size=0, group_seg_size=0
	kernel_obj=0x7e4c8c71e180, kernarg_address=0x0x7e446cc00300
	completion_signal=0x0, correlation_id=0
	rptr=1860, wptr=1866
:0:rocdevice.cpp            :3576: 175814621252 us:  Memory Fault Error [host: <container-id>, GPU index: 0, faulting addr: 0x7e40aea0c000, kernel: __amd_rocclr_fillBufferAligned]
Memory access fault by GPU node-1 (Agent handle: 0x594c721727d0) on address 0x7e40aea0c000. Reason: Page not present or supervisor privilege.
GPU coredump: Directory . not writable or does not exist
GPU core dump failed

Complete server config (paths normalized)

{
  "exe": "<experiment>/upstream/engine-poly/strata-poly",
  "args": [
    "--model",
    "<experiment>/data/models/qwen36-UD-Q3_K_M/Qwen3.6-35B-A3B-UD-Q3_K_M.gguf",
    "--max-context",
    "65536",
    "--expert-profile",
    "<experiment>/results/qwen36-ud-q3_k_m-ctx65536/out/expert-profile.txt",
    "--conversation-cache-mib",
    "0",
    "--tail-skip",
    "6",
    "--kv-whole",
    "--threads",
    "8"
  ],
  "cwd": "<experiment>/upstream",
  "tokenizer": "<experiment>/data/packs/qwen36-ud-q3_k_m/tokenizer",
  "model_name": "qwen3.6-35b-a3b-ud-q3_k_m",
  "display_name": "Qwen3.6-35B-A3B UD-Q3_K_M",
  "log": "<experiment>/results/qwen36-ud-q3_k_m-ctx65536/out/engine.log",
  "lib_dirs": [
    "<experiment>/upstream/.venv/lib/python3.13/site-packages/_rocm_sdk_devel/lib",
    "<experiment>/upstream/.venv/lib/python3.13/site-packages/_rocm_sdk_libraries_gfx103X_all/lib"
  ],
  "port": 8080,
  "gpu": 0,
  "gpus_asked": true,
  "host": "127.0.0.1",
  "open_browser": false,
  "reasoning_budget_tokens": 512,
  "benchmark_mtp": 0
}

benchmark_mtp: 0 is an adapter sentinel, not a claim that speculation was disabled; the successful first response recorded draft_n: 2, draft_n_accepted: 1.

Server output for the same start

loading the model (the first start takes a minute or two) ...
[strata] starting the engine: reading the model's weights ...
[strata] thinking budget: 512 tokens (reasoning_budget_tokens; a request can set its own)
ready: http://127.0.0.1:8080/v1  (OpenAI: /v1/chat/completions, Anthropic: /v1/messages, context 65536 tokens)
       open http://127.0.0.1:8080/ in a browser to chat; close this window to stop the model
[strata] done: 3 tokens in 1 s (47.4 tok/s) (stop, cancel=False), expert cache 55.5% hit
[strata] the engine stopped unexpectedly (exit code -6). The engine was ended by SIGABRT: a crash, or a signal from another program. Its last log line: GPU core dump failed - please report it at github.com/VecSzn/PolyStrata/issues with the log. The next request starts the engine again. Its log: <experiment>/results/qwen36-ud-q3_k_m-ctx65536/out/engine.log
[strata] done: 0 tokens in 0 s (0.0 tok/s) (error, cancel=False)

Sandbox details relevant to the failed core dump: inference ran as UID/GID 65534 with a read-only root, source and model mounts, a writable output directory and /tmp tmpfs, no external network, capabilities dropped, no-new-privileges, /dev/kfd and /dev/dri/renderD128 access, unlimited memlock, a 26 GiB memory limit with no swap, and a 9-CPU quota; engine threads were 8. The working directory containing the source was read-only, consistent with the logged core-dump write failure. Docker's recorded environment contained only PYTHONDONTWRITEBYTECODE=1, HOME=/tmp, and the standard PATH; no HSA/ROCm override was recorded there.

Subsequent explicit --vram-reserve-mib 1024 runs had no recorded GPU memory-access faults, including the completed official 64K suite. That is an observed workaround in this setup, not proof of the root cause or that this is the same bug as the Windows Q8_0 case.

[VecSzn]

Thanks, the log points at one place. The faulting kernel is ROCm's buffer fill (__amd_rocclr_fillBufferAligned), i.e. a memset, and it ran on the second request. That matches the expert cache growing back into free VRAM: Engine::mind_card_vram() does nothing before the first request has run, and from the next one on, when the card has more free than it keeps, grow_cache() maps more VRAM and zeroes the new part with zero_vram(). Without an explicit reserve it keeps only max(reserve / 2, 128) MiB free, so it grows nearly to the end of the card; with --vram-reserve-mib 1024 it keeps 1 GiB, which fits your runs with that flag never faulting. With --kv-whole the attention cache doesn't grow, so it isn't that path.

So it looks like ROCm handing out VRAM that isn't really there when the mapping gets close to the card's end, on this RDNA2 card at least. @donschen, you wrote the growing cache (#28) and carry a local ROCm VMM patch that adds a pinned-host allocation and free after VRAM mappings. Is that for this kind of fault? If it is, I'd like it on main.

Until then --vram-reserve-mib 1024 is the workaround on AMD, as you found. It's a different path from the Windows q8_0 report, which was on NVIDIA.