Commit fc42f1f, which reflects the 0.2.5.1 public documentation into tsaipifong/whirl-llm, landed on 2026-11-05 (UTC). WHIRL is a native C++/HIP-based LLM inference engine for Windows that runs on AMD GPUs. The commit message states that it covers documentation only, with no changes to source code, tools, or the build. The README and the Traditional Chinese README, the CHANGELOG, and the quickstart, usage, and server documents were modified, and 10 benchmark chart images were newly added. The entry in the CHANGELOG defines 0.2.5.1 as a Radeon 8060S (AMD Ryzen AI Max+ 395) speed update dated 2026-11-06.
Looking at the figures in the document, five new kernel paths were added for the 8060S, so prefill gets +2%~+10% faster across all three modes and both models, and Swift-1.5 27B decode rises by +5.8%~+12.1% in balance and +3.7%~+8.1% in fast. The outputs are bit-identical to 0.2.5 in every mode on the 8060S. The README states that, compared with the official llama.cpp b11960 (v0.8.0, 2026-10-28) ROCm and Vulkan builds, the 8060S leads in every measured cell in balance mode. Swift-1.5 27B is +28%~+59% against ROCm and +30%~+106% against Vulkan, and Ornith-1.5-35B-A3B is +51%~+65% and +46%~+127% respectively. The document states that the measurements were taken at a maximum power of 80W on an ASUS ROG Flow Z13 with a 64GB UMA frame buffer, taking the best of 3 runs per cell.
The fixes that the CHANGELOG summarizes for 0.2.5.1 also come to light. If the installation folder path exceeds 150 bytes on a UTF-8 basis, it refuses to start before the GPU runtime is loaded, and the SSD cache folder is rejected if it exceeds 217 characters. The part of the 0.2.5 entry that said long installation paths and a 260-character cache folder were allowed is corrected as of 0.2.5.1, while the 0.2.5 entry itself is left as it was written. The tuning cache file names were shortened to a tune5- prefix, and whirl-server was changed to clear the pinned-memory note when it terminates.
The limits of the evidence are also clear. The GPU code for the R9700 is identical to 0.2.5 and only the internal build ID differs, so the R9700 numbers in the README are not newly measured values but the values from 0.2.5. The Ornith decode cells fluctuate between -6.3%~+6.4% across versions, which is attributed to the number of approved MTP drafts differing from run to run (the explanation notes that in 64k balance it decreased from 0.71 to 0.60), appearing together with each step becoming 0.5% faster. Swift's precise decode does not use the new path and is nearly unchanged. For 8060S users this reads as a performance improvement with stated measurement conditions, but for R9700 users 0.2.5.1 brings no substantive performance change.