Engine/model benchmark 2026-10-24: strix-llama -ub 512 wins, now prod
Last updated 05/11/2026 · llm, metis, benchmark, llama-cpp
Outcome of the 2026-10-24 engine/model A/B (guide: /data/docker/llama/EXPERIMENTAL_IMAGE_BENCH_GUIDE.md). Winner: strix-llama engine with **-ub 512**, now the standard **/data/docker/llama/compose.yml**. Rollback: variants/vulkan-radv.yml (the previous prod).
Final comparison (quiet box, same model/flags: GSQ-RCO Q2_0 + MTP + mmproj, -c 131072, KV q8_0, cache-ram 8192)
| vulkan-radv (old prod, b11853) | strix-llama -ub 512 (new prod, build 12169) |
strix-llama -ub 1024 |
|
|---|---|---|---|
| prefill 8k/32k/64k/100k t/s | 295/287/247/204 | 582/500/409/345 | 696/583/456/371 |
| decode 8k/32k/64k/100k t/s | 52/48/47/43 | 61/53/45/39 | 61/53/46/39 |
| GTT idle/peak GiB | 44.2/44.2 | 44.0/44.0 | 48.3/48.9 |
| min avail RAM | 5.3 GiB | 5.0 GiB | 129 MiB (unsafe) |
| swap max | 644 MiB | 461 MiB | 1.6 GiB |
| eval (9 tasks) / tools / vision / think | 8/9, 4/4, 3/3, ok | 8/9, 4/4, 3/3, ok; 100k probe 5/5 | 8/9, all ok |
Why -ub 512: the extra ~4.7 GiB GTT of strix-llama was the compute buffer (about 5.4 GiB at -ub 1024; -ub 4096 = 21.6 GiB). Halving -ub gave the memory back and cost only ~16% prefill vs -ub 1024. Decode is faster up to 32k but ~4% / 9% slower at 64k / 100k. -ub 256 was never run (not needed).
Rejected / not viable (do not re-test without a new reason)
- REAP-288 (pruned 288 experts): prefill +55% but decode -41%, eval 6/9.
- TheRock nightly: fast prefill, decode collapses at >=64k. hrx-staging: no gain.
- Swift-1.5 GSQ-RCO: roughly tied with prod, no reason to switch.
- Gyro-S TQ1_0: TQ quant unsupported on vulkan-radv; on strix-llama it loads but crashes at prefill (
GGML_ASSERT(nb10 % sizeof(src1_t) == 0)in binbcast.cu). - Flint UD-Q6_K_XL (40B-A2.5B, text-only, no MTP): fast on vulkan (56 t/s decode, 1430 t/s prefill, 36 GiB GTT) but no vision, thinking control fails, eval 6/9; does not load on strix-llama. Fine as a text-only coding model if ever wanted.
- ignite-llama + DFlash2: hangs on both REAP and prod model (DFlash2 hyper-connection stream mean not implemented in llama.cpp, issue #30887). engramhalo: decode 35/27 t/s, worse.
- Ornith-122B: ~10B active, no MTP, so no speed gain; quality is not the problem. Download dropped.
- Not llama.cpp-compatible or too big for 56 GiB GTT: Gufo, PaoAI engine, halogen, ds4-server, SGLang+DFlash2.
- Lowering
**--cache-ram**to save RAM was ruled out by Niklas (loses long-session cache hits, ~49% on OpenClaw).
Method + gotchas
- Suite
/data/docker/llama/bench/:run_suite.sh,stages/NN_name.conf, summary in/data/sources/llm-bench/logs/imgbench/run_*/summary.md, live logstatus.log. Env:STAGES="name ...",RESTORE_PROD=0|1,SWAP_MAX_MIB,BASELINE_DIR. Watchdog aborts at GTT 52 GiB / swap limit.FULL=auto|always|neveris set inside the stage conf and overrides the env var (stage 23 hadFULL=never; edited toauto). - Measure on a quiet box: background downloads inflate anon RAM and make paging/refault numbers misleading (first strix-llama runs showed 129 MiB free RAM partly because of this; the quiet re-run still showed 129 MiB at
-ub 1024, so the compute buffer was real). - Prod compose had
-lm mmap --lazy-mode on; strix-llama uses-lm mmap --lazy-mode on-directwith-fit off -dev ROCm0. - Compose project name: files in
variants/default to projectvariants; both files now setname: llama, soup -dof either file replaces the other. If allama-flashnextcontainer from another project exists,downit first (name conflict). - Prod MTP head (Q8_0) only works with the matching Flash-Next base; other models need their own draft.
- Dead configs left in
/data/docker/llama/variants/:ornith.yml,qwen27b.yml,test-8130.ymlpoint at model paths that no longer exist on disk, so they cannot run; onlyvulkan-radv.ymlis a usable rollback. Not deleted (tiny) - delete if a future cleanup touches configs.
Open items
- Verify in a long live Zed/OpenClaw session (58k-83k tokens) that decode and cache behave; if decode at depth disappoints,
variants/vulkan-radv.ymlis one command away. - DONE 2026-10-25 (Niklas approved): losing model dirs deleted. Removed
models/swift-1.5-q2_0(63G),reap-288(59G),gyro-s-tq1_0(58G incl. mmproj + draft),flint(34G),dflash2(341M)./data/docker/llama/modelsis now 71 GB: onlyqwen3.8-flashnext(prod base + MTP + mmproj) andmtp-hc(3.9G, unused by prod, kept for the engram-hc idea). Alsodocker rmi’d the bench engine tags (hrx-staging,rocm-10.0-engramhalo,therock-nightly,vulkan-radv-b11631-20261016,vulkan-radv-new,vulkan-radv-performance,local/ignite-llama:rocm10, ~13.9 GB) anddocker builder prune(6.9 GB); prodrocm-10.0-strix-llama+ rollbackvulkan-radvkept./dataused 525 GB -> 297 GB;/v1/healthok after. Re-testing a rejected candidate means re-downloading its GGUF. The bench stage confs (stages/*.conf) still reference the deleted paths and will fail if re-run - that is intentional, they document the rejected candidates. - Headroom compression was live under LiteLLM (archived
ai-gateway-omniroute) and confirmed on the qwen route (23 events / 24 h, avg 33 % token reduction, cache reuse still good). Since 2026-10-31 the gateway is OmniRoute with Headroom chained — current state inai-gateway-omniroute. - strix-llama is
0.6.0-devand auto-rebuilt upstream (unpinned tag): re-checkllama-server --version,/healthand a short bench after image pulls.
Source: Wiki.js