<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AMDai lab log</title>
    <link>https://amdai.net/lab-log/</link>
    <description>Public AMDai results log of measured and cited findings, plus informative failures. Dual R9700 speed and the hourly Idea lab. No invented tok/s.</description>
    <language>en-US</language>
    <atom:link href="https://amdai.net/lab-log/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>CPU cooler for an R9700 build: Ryzen 9000X has none in the box, and a 360 AIO in the front or bottom of the case feeds warm air to the cards</title>
      <link>https://amdai.net/lab-log/#2026-10-28-cpu-cooler-for-dual-r9700</link>
      <guid isPermaLink="false">2026-10-28-cpu-cooler-for-dual-r9700</guid>
      <pubDate>Wed, 28 Oct 2026 12:00:00 GMT</pubDate>
      <description>AMD ships the Ryzen 5 9600X, Ryzen 9 9900X and Ryzen 9 9950X without a cooler; AMD recommends a premium air cooler for the 65 W 9600X and a liquid cooler for the 120 W 9900X and 170 W 9950X for best boost. for a local-AI box with blower R9700s, where the radiator goes matters: the cards pull their air from the case's front and bottom intake, so a 360 radiator should go on top as exhaust, and a case that only takes one in front or bottom is better paired with a large dual-tower air cooler.</description>
    </item>
    <item>
      <title>Case for two R9700s: a standard 7-slot ATX case is enough on 4-slot-spacing x8/x8 boards, and case fans should follow the GPUs, not the CPU</title>
      <link>https://amdai.net/lab-log/#2026-10-28-case-for-two-r9700s</link>
      <guid isPermaLink="false">2026-10-28-case-for-two-r9700s</guid>
      <pubDate>Wed, 28 Oct 2026 12:00:00 GMT</pubDate>
      <description>Every R9700 board-partner card is a 2-slot blower no longer than 271 mm. on the ASRock X870 Taichi Creator and Gigabyte B850 AI TOP, owners report 4-slot spacing between the two CPU x8/x8 slots, so the bottom card ends by expansion slot 7 and leaves a 2-slot gap above it. that means any 7-slot ATX case with at least 271 mm of card length fits two cards; no 8-slot case is needed unless you plan a third card or a riser. blowers push their heat out the back, so the case's job is fresh intake air for the card area.</description>
    </item>
    <item>
      <title>How much NVMe a Radeon local-AI box needs: 2 TB holds every Q4-Q6 quant of three model families, and Gen5 barely speeds up loading</title>
      <link>https://amdai.net/lab-log/#2026-10-28-nvme-for-local-models</link>
      <guid isPermaLink="false">2026-10-28-nvme-for-local-models</guid>
      <pubDate>Wed, 28 Oct 2026 12:00:00 GMT</pubDate>
      <description>Every Q4 to Q6 quant of Qwen3.6-35B-A3B (20.6 to 29.7 GiB), Qwen3.8-Flash-Next (103.7 to 157.6 GiB) and GLM-5.3-Flash (186.0 to 271.8 GiB) adds up to about 1,587 GiB once you keep one extra file of room for the next download and 150 GiB for the OS. That fits a 2 TB drive (1,863 GiB) with 10% left free; a fourth Flash-class family such as MiniMax-M3.1-Flash (UD-Q4 232 GiB) needs 4 TB. On llama.cpp's default memory-mapped loader, loading is usually limited by page faults and one CPU core rather than the drive, so a Gen5 SSD helps less than its doubled rating suggests.</description>
    </item>
    <item>
      <title>SGLang TP2 on 2x R9700 is slower than llama.cpp on one card for Qwen3.6-35B-A3B, and has no DDR5 path for Flash models</title>
      <link>https://amdai.net/lab-log/#2026-10-27-sglang-tp2-vs-llamacpp-r9700</link>
      <guid isPermaLink="false">2026-10-27-sglang-tp2-vs-llamacpp-r9700</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>The most complete public 2x R9700 SGLang rig (v0.5.15 plus RDNA4 patches, TP=2) measured Qwen3.6-35B-A3B AWQ int4 at 67.0 tok/s short and 22.0 tok/s at 197K input. llama.cpp on a single R9700 does 165.2 tok/s (Vulkan, Q4_K_M, tg128) and our own Q5 run does 100.8 short and about 50 at 256K. Upstream SGLang still blocks gfx1201 builds, and its only CPU-expert path (KTransformers) is built around Intel AMX, so Flash-class models stay on llama.cpp or Strata.</description>
    </item>
    <item>
      <title>rocm-smi is gone in ROCm 10.x: use amd-smi --rocm-smi, or the driver's own counters on Vulkan-only setups</title>
      <link>https://amdai.net/lab-log/#2026-10-27-rocm-smi-gone-in-rocm-10</link>
      <guid isPermaLink="false">2026-10-27-rocm-smi-gone-in-rocm-10</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>AMD's ROCm 10.1 transition guide lists ROCm SMI as removed from the Core SDK (replaced by AMD SMI, package amdrocm-amdsmi); it was dropped from TheRock builds in 10.0. On a fresh 10.x install, 'rocm-smi' prints command not found even though ROCm works. 'amd-smi --rocm-smi' prints the familiar concise table, and 'amd-smi monitor --gfx --vram-usage --watch 1' replaces 'watch -n1 rocm-smi'. Our own scan of amdai.net found 23 command lines across 15 pages still calling rocm-smi with no fallback, including the verify tutorial's pass/fail checklist; we are fixing those.</description>
    </item>
    <item>
      <title>Our KV-cache calculator vs llama.cpp's real allocator: GLM-5.3-Flash overstated 2.3x, Qwen3.8-Flash-Next 1.6 GiB short at 262K</title>
      <link>https://amdai.net/lab-log/#2026-10-27-kv-estimate-audit-llamacpp</link>
      <guid isPermaLink="false">2026-10-27-kv-estimate-audit-llamacpp</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>We checked the KV estimate for all 19 model presets in the amdai.net calculator against the model configs and llama.cpp master's memory code (Oct 27). 13 match within 10%. GLM-5.3-Flash was the big miss: only 11 of its 45 layers keep a growing cache (34 are linear-attention layers with a fixed state), so 262K context needs about 4.95 GiB at f16, not the 11.25 GiB we showed. Qwen3.8-Flash-Next needs about 7.6 GiB at 262K, not 6.0, because its sparse-attention indexer keys also live in the cache. Gemma 4's sliding-window layers were under-counted by 0.4-0.8 GiB.</description>
    </item>
    <item>
      <title>R9700 street price is now about $2,000: cheapest new card $1,949.99, 50% over MSRP and $250 up in a day</title>
      <link>https://amdai.net/lab-log/#2026-10-27-r9700-street-price-noon</link>
      <guid isPermaLink="false">2026-10-27-r9700-street-price-noon</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>As of Oct 27 at noon CT, every new in-stock Radeon AI PRO R9700 32 GB we found sold by Micro Center costs $1,949.99 to $1,999.99, and Newegg and B&amp;H list $1,999.99 (ASUS Turbo). That is up $250-300 from yesterday's $1,699.99-$1,799.99. The cheapest is the Gigabyte AI TOP at $1,949.99 (Micro Center, in-store pickup only), 50% above AMD's $1,299 MSRP. Two cards (64 GB VRAM) now cost $3,899.98 before tax.</description>
    </item>
    <item>
      <title>llama.cpp removed --no-mmap, --mlock and llama-bench -mmp: old commands now stop at startup, and LLAMA_ARG_NO_MMAP is silently ignored</title>
      <link>https://amdai.net/lab-log/#2026-10-27-llama-cpp-removed-load-flags</link>
      <guid isPermaLink="false">2026-10-27-llama-cpp-removed-load-flags</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>Since release b10875 (2026-09-09, PR #28334) llama-server and llama-cli exit with 'invalid argument' on --no-mmap, --mmap, --mlock and --direct-io, and llama-bench rejects -mmp and -dio. Use --load-mode none (old --no-mmap), mmap+mlock (old --mlock), mlock (old --no-mmap --mlock) or dio; in llama-bench, -lm none. The env vars LLAMA_ARG_NO_MMAP, LLAMA_ARG_MMAP and LLAMA_ARG_MLOCK are no longer read at all, so Docker or systemd setups that used them quietly fall back to the default load mode (auto, which memory-maps).</description>
    </item>
    <item>
      <title>vLLM 4-bit on the R9700: recent RDNA int4 speedups skip gfx1201, GPTQ crashes, and the default attention backend can return wrong output</title>
      <link>https://amdai.net/lab-log/#2026-10-27-vllm-int4-r9700-gating</link>
      <guid isPermaLink="false">2026-10-27-vllm-int4-r9700-gating</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>Reading vLLM main (e7fa26d5c8, 2026-10-27): the Oct 13 W4A16 decode tuning (+9-21% GEMM, up to -66% on speculative shapes) is gated to Strix Halo (gfx115x); the new int4 MoE decode kernel (+44% on a 35B-A3B, Strix Halo) and MXFP4 W4A8 GEMV are gfx11-only; upstream has no tuned int4 MoE configs for the R9700. On R9700, GPTQ checkpoints crash at startup unless you pass --linear-backend TRITON, and the default ROCM_ATTN backend gave wrong outputs or GPU faults outside head 128 / KV block 16, while TRITON_ATTN was clean.</description>
    </item>
    <item>
      <title>Monitoring local LLM speed: llama-server's tok/s gauges read 0 mid-generation; use the counters, and compare by context depth</title>
      <link>https://amdai.net/lab-log/#2026-10-27-llama-server-metrics-gauges</link>
      <guid isPermaLink="false">2026-10-27-llama-server-metrics-gauges</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>In current llama.cpp, the /metrics gauges predicted_tokens_seconds and prompt_tokens_seconds are reset by every scrape and only updated when a request finishes, so dashboards show 0 while a long generation runs and two scrapers steal each other's windows. Rates from the cumulative counters are reliable. Strata's /metrics already reports a live 2-second tok/s plus per-request speeds.</description>
    </item>
    <item>
      <title>VRAM per dollar: a new R9700 is now at parity with a used RTX 3090, and wins on watts and slots</title>
      <link>https://amdai.net/lab-log/#2026-10-27-vram-per-dollar</link>
      <guid isPermaLink="false">2026-10-27-vram-per-dollar</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>With the cheapest new R9700 at $1,949.99 (up $250 since yesterday) it costs $60.9 per GB of VRAM, against $58.9-63.7 per GB for a used RTX 3090 at eBay sold medians of $1,413-$1,528. Per watt it wins clearly (9.4 W/GB vs 14.6), and 64 GB takes two R9700s at 600 W instead of three 3090s at 1,050 W.</description>
    </item>
    <item>
      <title>R9700 upstream bug check: 15 RDNA4 fixes landed in 30 days, but the ROCm llama.cpp hang that needs a reboot still fails on the newest driver stack</title>
      <link>https://amdai.net/lab-log/#2026-10-27-gfx1201-upstream-bugs</link>
      <guid isPermaLink="false">2026-10-27-gfx1201-upstream-bugs</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>We searched 10 GitHub repos Radeon local-AI users rely on for issues naming gfx1201 or R9700. 15 RDNA4-titled issues were closed as fixed in the last 30 days, including two Tensile GEMM page faults and a ~12% Vulkan prefill regression in llama.cpp. Still open: a ROCm-only llama.cpp generation hang that resets the GPU (Vulkan passes), a cross-stream wait penalty whose size depends on MES firmware, a GFXOFF-related idle power cost, a vLLM TP=2 deadlock, and a vLLM 0.28 FP8 kernel choice that slows RDNA4 decode.</description>
    </item>
    <item>
      <title>Read the LICENSE, not the tag: 1 in 4 new open-weight models had no usable license label, and Qwen3.8-Flash-Next's terms are stricter than its 2.4T sibling's</title>
      <link>https://amdai.net/lab-log/#2026-10-27-new-model-licenses</link>
      <guid isPermaLink="false">2026-10-27-new-model-licenses</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>Of 88 open-weight models released in the last 90 days, 20 were tagged only 'other' or nothing on Hugging Face. After reading each LICENSE: 62 open, 7 open with conditions, 5 commercial only under a revenue cap, 9 non-commercial or research only, 1 not for EU use, 4 still unclear. Personal and home use is fine for every Flash-class model we run.</description>
    </item>
    <item>
      <title>Coding CLIs on a local llama-server: 0.7K to 19K tokens before your first word, and one background call that forces a full re-read</title>
      <link>https://amdai.net/lab-log/#2026-10-27-coding-cli-prompt-tax</link>
      <guid isPermaLink="false">2026-10-27-coding-cli-prompt-tax</guid>
      <pubDate>Tue, 27 Oct 2026 12:00:00 GMT</pubDate>
      <description>We captured what five coding CLIs send to a local endpoint. First-turn prompts: Claude Code 19,384 tokens, Qwen Code 15,091 (plus a 7,084-token memory call every turn), Codex CLI 8,343, OpenCode 7,158, Aider 749. Replayed on a real one-slot llama-server, Qwen Code's memory call evicted the session when the RAM prompt cache was off: turn 2 re-read 15,602 tokens instead of 21.</description>
    </item>
    <item>
      <title>llama.cpp on 2x R9700: build with RCCL off for batch-1 tensor split, and three build flags that no longer do anything</title>
      <link>https://amdai.net/lab-log/#2026-10-26-hip-build-flags-rccl</link>
      <guid isPermaLink="false">2026-10-26-hip-build-flags-rccl</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Since llama.cpp PR #27825 (merged 2026-09-15), a HIP build with GGML_HIP_RCCL=OFF (the default) uses a built-in two-GPU AllReduce for --split-mode tensor. On 2x R9700 it beat the old fallback by +17.5% prefill and +8.3% decode, and in published RCCL-on vs off tests decode was equal or slightly faster without RCCL while RCCL only helped long prefills.</description>
    </item>
    <item>
      <title>Hot DDR5 can quietly cost hybrid GPU+RAM decode up to ~10%, and non-ECC sticks never report errors</title>
      <link>https://amdai.net/lab-log/#2026-10-26-ddr5-dimm-heat-hybrid-decode</link>
      <guid isPermaLink="false">2026-10-26-ddr5-dimm-heat-hybrid-decode</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>When a big MoE model keeps its experts in DDR5 next to two R9700s, the DIMMs work hard for hours. DDR5 doubles its refresh rate above 85 C (JEDEC refresh interval 3.9 us drops to 1.95 us). For 64 GB sticks built from 32 Gb chips, that takes the time a rank spends refreshing from about 10.5% to about 21%, so bandwidth-bound work can slow by up to ~13%. For hybrid decode we estimate up to ~7-11% fewer tokens per second once sticks pass 85 C, depending on how much of each token's time is spent reading DDR5 (an upper-bound estimate). Linux can read each stick's temperature with the spd5118 driver, so this is easy to check.</description>
    </item>
    <item>
      <title>Power budget for four R9700s in two desktops: one 15 A circuit is not enough, even at the lowest power cap</title>
      <link>https://amdai.net/lab-log/#2026-10-26-four-r9700-two-desktops-power-budget</link>
      <guid isPermaLink="false">2026-10-26-four-r9700-two-desktops-power-budget</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Before buying a second desktop for two more R9700s, we built a power budget from published measurements. Under full compute an R9700 has been measured at about 390-400 W at the card (spec TBP 300 W), while decode-bound llama.cpp is much lower: about 340-353 W for two cards together in layer split. With all four cards at 300 W, the two desktops draw an estimated ~1,780 W at the wall; even at the lowest allowed cap (210 W) it is ~1,640 W. A 15 A, 120 V circuit may carry only 1,440 W continuously (the 80% rule for loads over 3 hours), so the two boxes need separate circuits, or one 20 A circuit with cards capped at 260 W or less.</description>
    </item>
    <item>
      <title>llama-bench A/A test: identical runs differed by up to 20%, and one run's mean +- stddev called identical runs 'different' 9 times in 15</title>
      <link>https://amdai.net/lab-log/#2026-10-26-llama-bench-noise-aa-test</link>
      <guid isPermaLink="false">2026-10-26-llama-bench-noise-aa-test</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Before trusting a 3-5% win between two configs, we ran the same llama-bench command 6 times in a row. Inside one run, repetitions varied about 5%, but the medians of whole runs varied 6-7%, and the first run after loading was 12-16% slower than the rest. Comparing any two of the identical runs, a 95% interval built from one run's repetitions wrongly flagged a difference in 9 of 15 pairs. llama-bench's own tools don't guard against this: the generation warmup is a single token, repetitions run back-to-back by default, and compare-llama-bench.py prints a plain ratio of averages with no spread.</description>
    </item>
    <item>
      <title>Open WebUI in front of llama-server: with --cache-ram 0, its background calls force a full re-prefill of the chat on every turn</title>
      <link>https://amdai.net/lab-log/#2026-10-26-openwebui-background-tasks-prompt-cache</link>
      <guid isPermaLink="false">2026-10-26-openwebui-background-tasks-prompt-cache</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Open WebUI 0.12.4 sends extra model calls per chat turn (follow-up suggestions every turn, plus title and tags on the first), each a fresh one-message prompt that shares no prefix with the conversation. On a one-slot llama-server they replace the slot's state. With the default host prompt cache (--cache-ram 8192 MiB) the conversation is saved and restored and each later turn re-processes only about 70 tokens; with --cache-ram 0, or a cache smaller than one conversation's saved state, every turn re-processed the whole 11K-token chat (about 40x the prefill time in this test).</description>
    </item>
    <item>
      <title>GLM-5.3-Flash GGUF chat template is two upstream fixes behind: up to 17 s of template rendering per request with many parallel tool results in llama.cpp</title>
      <link>https://amdai.net/lab-log/#2026-10-26-glm-flash-chat-template-render</link>
      <guid isPermaLink="false">2026-10-26-glm-flash-chat-template-render</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>The chat template embedded in the current Unsloth GLM-5.3-Flash GGUF matches the upstream 2026-08-27 version and misses the 2026-10-15 upstream rewrite of tool-result reordering. Rendered with llama.cpp's own Jinja engine, one block of 100 parallel tool results takes 1.14 s with the embedded template vs 31 ms with the new one (400 results: 17.0 s vs 0.19 s), with byte-identical output. Fix without re-downloading: pass the upstream template with --chat-template-file.</description>
    </item>
    <item>
      <title>R9700 street price today: $1,699.99, 31% over MSRP, and only in store</title>
      <link>https://amdai.net/lab-log/#2026-10-26-r9700-street-price</link>
      <guid isPermaLink="false">2026-10-26-r9700-street-price</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Across the six US R9700 32 GB models, the cheapest new card in stock is $1,699.99 (Gigabyte AI TOP and XFX at Micro Center, in-store pickup), 31% above AMD's $1,299 MSRP. The lowest price seen since Sep 29 is $1,599.99. Amazon's in-stock new offers run $2,399.99 to $2,680.81.</description>
    </item>
    <item>
      <title>Strata's MTP draft layer only loads Q2_0 experts, so a Q4+-only R9700 setup loses drafts and the RDNA4 pipeline-windows split gain</title>
      <link>https://amdai.net/lab-log/#2026-10-26-strata-mtp-q2-only-second-card</link>
      <guid isPermaLink="false">2026-10-26-strata-mtp-q2-only-second-card</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>In Strata main (2026-10-25), the runtime drafter sizes its 512 experts as kernels::cpu::BLOB, which is the Q2_0 layout (1,382,400 bytes per expert, 707,788,800 for the file). mtp_pack.py can write Q4_0 or Q8_0 draft experts, but nothing loads them (open issue #3728), and --mtp-q4 only requantizes the dense head, not the experts. Anyone who keeps every file at 4-bit or more therefore runs Strata with no draft layer. On a layer split that also turns off pipeline windows, the RDNA4 default that gave +21% code decode on 2x R9700 (103 to 125 tok/s) in the maintainer's table.</description>
    </item>
    <item>
      <title>vLLM TP2 on two R9700s: every all-reduce goes through RCCL, and batch-1 decode pays it ~80-96 times per token</title>
      <link>https://amdai.net/lab-log/#2026-10-26-vllm-tp2-allreduce-rccl-only</link>
      <guid isPermaLink="false">2026-10-26-vllm-tp2-allreduce-rccl-only</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>In current vLLM source, the custom all-reduce, QuickReduce and AITER all-reduce paths are enabled only on MI300-class GPUs; on gfx1201 vLLM forces disable_custom_all_reduce on, so every tensor-parallel all-reduce is an RCCL call (this is why --disable-custom-all-reduce 'has no effect' on R9700). With two all-reduces per layer, Qwen3.6-35B-A3B makes 80 per token (4 KiB each) and Qwen3.8-Flash-Next 96 (5 KiB). The only published R9700 rccl-tests table (4 cards, P2P off) is flat at 31-36 us up to 32 KiB, which is about 2.9 and 3.4 ms of communication per token, before any compute.</description>
    </item>
    <item>
      <title>Stale GGUFs after a re-upload: GLM-5.3-Flash needs one 9 MiB shard, not a 272 GiB re-download, and old Flash-Next MTP heads carry a wrong value</title>
      <link>https://amdai.net/lab-log/#2026-10-26-gguf-reupload-drift</link>
      <guid isPermaLink="false">2026-10-26-gguf-reupload-drift</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>On 2026-10-05 Unsloth re-uploaded files in its GLM-5.3-Flash and Qwen3.8-Flash-Next GGUF repos 'due to upstream changes'. We diffed the old and new files from the Hugging Face history. For GLM-5.3-Flash only shard 1 of each quant changed, and it holds metadata only (9.0 MiB, no tensors): the architecture name went from glm5next to glm5-next, the name mainline llama.cpp merged on 2026-09-30, and one key was added (attention.indexer.index_share_mtp = true). A copy downloaded before then can be fixed by replacing that one shard instead of re-downloading 186-272 GiB. For Qwen3.8-Flash-Next the UD-Q4/Q5/Q6 model shards did not change; the three non-shared MTP head files did, by one value: the MTP layer's attention compress ratio went from 0 to 4.</description>
    </item>
    <item>
      <title>Faster Qwen3.6-35B-A3B on one R9700: use the built-in MTP head, not a draft model, and watch the 262K fit</title>
      <link>https://amdai.net/lab-log/#2026-10-26-35b-a3b-mtp-vs-draft-r9700</link>
      <guid isPermaLink="false">2026-10-26-35b-a3b-mtp-vs-draft-r9700</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Published tests show a separate small draft model makes Qwen3.6-35B-A3B slower (one RTX 3090: 135.7 tok/s baseline vs 115.9-121.3 mean with drafts), while the model's own MTP head helps one user at a time: on an R9700 (Q4_K_M, Vulkan) one slot went from about 108 to about 133 tok/s, but MTP made a 3-slot job 1.58x slower. We read the headers of Unsloth's MTP GGUFs: the extra MTP block is Q8_0 attention with Q5_K/Q6_K experts in UD-Q5_K_XL, nothing below Q4.</description>
    </item>
    <item>
      <title>Two Radeon cards, wrong answers at full speed: which split setups corrupt text, what fixed it, and a correctness check</title>
      <link>https://amdai.net/lab-log/#2026-10-26-multi-gpu-silent-corruption</link>
      <guid isPermaLink="false">2026-10-26-multi-gpu-silent-corruption</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Several 2026 Radeon multi-GPU setups on ROCm/HIP produced fluent gibberish or blank output at normal speed with no error, and llama-bench still reported healthy numbers. The Windows layer-split case was fixed in ROCm's runtime (PR #10553, merged 2026-09-02); Windows -sm tensor on ROCm is still open; Linux cards with no peer-to-peer path need a no-peer-copy build. Always check text, not just tok/s, after a stack change.</description>
    </item>
    <item>
      <title>llama.cpp slot save/restore now works for hybrid Qwen models: resume a long agent context after a restart</title>
      <link>https://amdai.net/lab-log/#2026-10-26-slot-restore-hybrid-checkpoints</link>
      <guid isPermaLink="false">2026-10-26-slot-restore-hybrid-checkpoints</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Before llama.cpp b11507, restoring a saved slot on hybrid (Gated DeltaNet) models like Qwen3.5/3.6/3.8 reported success but re-processed the whole prompt, because context checkpoints were not saved. PR #26004 now appends them to the slot file. A published AMD Vulkan test (Radeon 8050S, Qwen3.5-35B-A3B UD-Q4_K_XL, 58K tokens) cut the first request after restore from 181.9 s to 4.7 s.</description>
    </item>
    <item>
      <title>Capping thinking on a slow Flash model: the stop message matters more than the token count</title>
      <link>https://amdai.net/lab-log/#2026-10-26-thinking-budget-latency</link>
      <guid isPermaLink="false">2026-10-26-thinking-budget-latency</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>At about 33 tok/s (a Flash-class MoE on 2x R9700 with experts in DDR5), every 1,000 thinking tokens is roughly 31 seconds before the first visible word. llama.cpp can cap this per request with thinking_budget_tokens plus reasoning_budget_message, and since June 2026 a client can end thinking mid-stream with POST /v1/chat/completions/control, which allows a wall-clock deadline instead of a token count. A bare cap without a stop message hurts: HumanEval on a Qwen3.5 9B fell to ~79% vs ~89% with a message (~93% uncapped), and on Qwen3.6-35B-A3B a bare 4,096-token cap ran 170 s as reasoning spilled into the answer, vs 78 s with Qwen's own stop sentence.</description>
    </item>
    <item>
      <title>R9700 GPU hangs come in three kinds, and only one is fixed by restarting the server</title>
      <link>https://amdai.net/lab-log/#2026-10-26-r9700-hang-recovery-classes</link>
      <guid isPermaLink="false">2026-10-26-r9700-hang-recovery-classes</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>Public Radeon AI PRO R9700 (gfx1201) fault reports split into three recovery classes. (1) The server process dies and the driver's reset succeeds: a systemd Restart=on-failure is enough. (2) A silent wedge: the server stays up at 100% GPU busy and 0% memory busy but produces no tokens, or blocks at idle power with no error, so nothing restarts it and a /health check still answers 200. (3) A dead GPU: the reset ends with 'PSP resume failed' / ret -62 or a reset storm with a CPU soft lockup, and only a reboot helps; repeated auto-retries in that state have hard-hung an R9700.</description>
    </item>
    <item>
      <title>Securing a local LLM server: what llama-server's API key covers, 2026 CVEs, and why ggml RPC must stay on a private link</title>
      <link>https://amdai.net/lab-log/#2026-10-26-endpoint-security</link>
      <guid isPermaLink="false">2026-10-26-endpoint-security</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>llama-server binds 127.0.0.1 by default, and --api-key protects every route except /health and the web-UI files. Without a key, /props, /slots and /v1/models are open, and the default CORS setting echoes any Origin. Builds from b8227 up to but not including b11393 have a 9.2-rated use-after-free on POST /completion (CVE-2026-107183), so update to b11393 or newer. The RPC backend used for multi-machine splits has no authentication and had a 9.8-rated remote code execution bug this year (fixed in b8492), so it belongs on a dedicated point-to-point link only.</description>
    </item>
    <item>
      <title>Text-to-speech next to a local LLM on R9700: llama-server now serves Qwen3-TTS, and a CPU voice would compete with offloaded experts for DDR5</title>
      <link>https://amdai.net/lab-log/#2026-10-26-r9700-tts-llama-server</link>
      <guid isPermaLink="false">2026-10-26-r9700-tts-llama-server</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>llama.cpp merged a native POST /tts endpoint for llama-server on 2026-10-20 (release b11781), with streaming, speaker-reference upload and router-mode autoload, so a TTS model can sit behind the same server as the LLM. Published R9700 results for Qwen3-TTS: the PyTorch reference runs at RTF 1.90 (slower than real time), while a custom HIP port reaches RTF 0.55 for the 1.7B model and 0.41-0.54 for the 0.6B. No llama.cpp R9700 TTS number has been published yet.</description>
    </item>
    <item>
      <title>Image and video generation on one R9700: step-distill LoRAs give ~6x, the hipBLASLt/MIOpen flags slow video 5-7%</title>
      <link>https://amdai.net/lab-log/#2026-10-26-r9700-image-video-gen</link>
      <guid isPermaLink="false">2026-10-26-r9700-image-video-gen</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>From published R9700 ComfyUI runs: SDXL 1024x1024 runs at 4.49-4.6 it/s. 4-step distillation LoRAs cut Qwen-Image-2512 from 85.9 s to 12.4 s and Wan 2.2 A14B 480p from 341.7 s to 56.6 s, far more than any runtime knob. In a same-box A/B, TORCH_BLAS_PREFER_HIPBLASLT=1 plus COMFYUI_ENABLE_MIOPEN=1 made all four video workflows 5.3-7.3% slower and left Qwen-Image within 2%.</description>
    </item>
    <item>
      <title>LoRA fine-tuning on the R9700: the hipBLASLt page-fault trap and what fixes it</title>
      <link>https://amdai.net/lab-log/#2026-10-26-r9700-lora-pagefault</link>
      <guid isPermaLink="false">2026-10-26-r9700-lora-pagefault</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>The R9700 (gfx1201) is officially supported for LoRA/QLoRA training (Unsloth lists RDNA4 as Full; TheRock lists gfx1201 Release Ready), but stock hipBLASLt GEMMs can fault in the LoRA backward pass at a fixed step. On ROCm 7.2.4 a reporter saw bf16 LoRA on Qwen3-8B fault at step 85 and QLoRA NF4 at step 799. The fix (rocm-libraries PR 8909, merged 2026-08-14) ran clean in independent validations at about 1.5% extra step time.</description>
    </item>
    <item>
      <title>Local RAG for an R9700 agent: Qwen3-Embedding-4B Q5_K_M is the value point, 0.6B pair fits in ~1.2 GiB</title>
      <link>https://amdai.net/lab-log/#2026-10-26-embed-rerank-pick</link>
      <guid isPermaLink="false">2026-10-26-embed-rerank-pick</guid>
      <pubDate>Mon, 26 Oct 2026 12:00:00 GMT</pubDate>
      <description>From official GGUF sizes and vendor scores: Qwen3-Embedding-4B Q5_K_M (2.69 GiB) scores 69.45 on MTEB multilingual, +5.1 over the 0.6B Q8_0 (0.60 GiB, 64.33), while the 8B Q5_K_M (5.05 GiB) adds only +1.1 more. Qwen3-Reranker-0.6B (0.60 GiB at Q8_0) lifts retrieval to 65.80 MTEB-R from 61.82, well ahead of bge-reranker-v2-m3 at 57.03.</description>
    </item>
    <item>
      <title>Strix Halo vs Radeon AI PRO R9700 on the same benchmark harness: ~2x decode, 3-4x prefill when the model fits</title>
      <link>https://amdai.net/lab-log/#2026-10-25-strix-halo-vs-r9700</link>
      <guid isPermaLink="false">2026-10-25-strix-halo-vs-r9700</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>Joining kyuz0's two public llama-bench grids (same scripts, best backend per row, 8 overlapping Q4+ models), one or two R9700s lead a 128 GB Ryzen AI Max+ 395 by a median ~2.0x on decode (tg128) and ~2.9x on prompt processing (pp512), widening to ~3.6-4.1x prefill at 32K-64K depth. Strix Halo's edge is capacity: it runs 80-90 GiB Q4/Q5 MoE models entirely in unified memory.</description>
    </item>
    <item>
      <title>Swapping big models on one box: llama.cpp router mode evicts by count, not VRAM; llama-swap can budget per card</title>
      <link>https://amdai.net/lab-log/#2026-10-25-model-swap-router</link>
      <guid isPermaLink="false">2026-10-25-model-swap-router</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>llama-server's router mode (start it with no model and a --models-preset INI) loads models on demand, but it decides what to unload only by counting: --models-max defaults to 4 and the scheduler never checks VRAM or RAM. On a dual-R9700 box where one Flash-class model fills both cards and DDR5, run it with --models-max 1, or a request naming a second big model will try to load it alongside the first. llama-swap's capacity router lets you declare per-card and RAM budgets instead, and can also host non-llama.cpp servers.</description>
    </item>
    <item>
      <title>Tool calls and JSON mode in llama.cpp: lazy grammars, rejection sampling, and why -bs switches off</title>
      <link>https://amdai.net/lab-log/#2026-10-25-llamacpp-grammar-sampling-cost</link>
      <guid isPermaLink="false">2026-10-25-llamacpp-grammar-sampling-cost</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>In current llama.cpp, a request with tools and tool_choice &quot;auto&quot; uses a lazy grammar that stays idle until the model starts a tool call, while tool_choice &quot;required&quot; or a response_format JSON schema constrains every token from the start. Sampling checks only the chosen token against the grammar and computes the full-vocabulary mask only when that token is rejected. Experimental backend (GPU) sampling, -bs, is turned off for any request that carries a grammar, lazy tool grammars included, so agent requests always sample on the CPU.</description>
    </item>
    <item>
      <title>Speech-to-text next to a local LLM on R9700s: use whisper.cpp, and mind the endpoint</title>
      <link>https://amdai.net/lab-log/#2026-10-25-whisper-stt-rdna4</link>
      <guid isPermaLink="false">2026-10-25-whisper-stt-rdna4</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>For voice input on RDNA4 cards, whisper.cpp (HIP or Vulkan) is the working path: a test on an R9700 ran the 11 s JFK sample with tiny.en in 206 ms, and an RX 9070 XT on Vulkan transcribed a 19.3-minute talk with large-v3-turbo in 48 s (about 24x real time, 1.5% WER). One RDNA4 tester reports the CTranslate2 ROCm forks behind faster-whisper produce wrong transcripts, so avoid that stack. The turbo model is 0.81 GiB at q8_0. whisper-server only serves /inference unless you pass --inference-path /v1/audio/transcriptions, which OpenAI-style agent clients expect.</description>
    </item>
    <item>
      <title>Vision on Qwen3.8-Flash-Next with R9700s: the encoder is cheap, the image tokens are not</title>
      <link>https://amdai.net/lab-log/#2026-10-25-flash-next-vision-cost</link>
      <guid isPermaLink="false">2026-10-25-flash-next-vision-cost</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>Flash-Next reads images through a separate 0.84 GiB projector (27-layer ViT, patch 16, merge 2, so one image token per 32x32 pixels). On an R9700 the GPU encoder takes 57 ms for a 260-token picture and 0.40 s for 972 tokens (3.13 s and 14.1 s on a CPU encoder). With llama.cpp's default cap of 4,096 tokens per image, a 1920x1080 screenshot becomes 2,040 tokens, so on a hybrid setup that prefills around 200 tok/s the image tokens, not the encoder, dominate time to first token. Capping images at 1,024 tokens halves that.</description>
    </item>
    <item>
      <title>R9700 reference band on llama.cpp's community scoreboards (Llama 2 7B Q4_0)</title>
      <link>https://amdai.net/lab-log/#2026-10-25-r9700-scoreboard-band</link>
      <guid isPermaLink="false">2026-10-25-r9700-scoreboard-band</guid>
      <pubDate>Sun, 25 Oct 2026 12:00:00 GMT</pubDate>
      <description>Published single-card R9700 results for the standard llama-bench test: Vulkan tg128 126-146 t/s (FA off) and 131-153 (FA on), pp512 5,000-5,900; ROCm/HIP 112.7 / 121.6 tg128 at build 8ea2902. A card well under this band points to a driver, power or PCIe problem, not the hardware. The ROCm scoreboard's R9700 row is stale (93.84 tg128 at bd4ef13); newer builds are about 20% faster.</description>
    </item>
  </channel>
</rss>
