con-0007

Nathanw1014/strix-halo-llamacpp (the Strix Halo Vulkan fork tracked in con-0002) shipped v0.6.8 and v0.6.9, two stable releases that carry a deliberate MTP rollback EXACTNESS tradeoff on hybrid GDN targets. v0.6.8 (2026-08-22T02:40:00Z) added DFlash2 speculative decoding support for mmproj/vision (community-reported vision-prompt HTTP 500 fixed by injecting draft rows at dense per-token positions and triming the draft cache in token space) and introduced a one-line change, "common: use full checkpoints for MTP rollback", that forced MTP rollback through full sequence-state checkpoints. v0.6.9 (2026-08-22T04:09:43Z) REVERTS that one line (revert commit a17e843, payload Nathanw1014/llama.cpp@a17e8432b, branch strix-halo-vulkan): on Vulkan with a hybrid GDN target (qwen35moe, e.g. Qwen3.6-35B-A3B) the full-checkpoint save/restore path deadlocked a few hundred tokens into a long response - every server thread parked in futex_do_wait with the GPU idle and GTT flat, reproduced deterministically and bisected on hardware. v0.6.7, CPU, and DFlash2 (incl. the vision path) were unaffected. The vendor states the tradeoff plainly: with the revert, MTP rollback returns to v0.6.4-v0.6.7 behaviour - fast snapshot-plane restore that CAN DIVERGE SLIGHTLY from a no-draft run after a rejected draft (called "a subtle distribution drift after rejected drafts, not garbled output"). Re-land of the full-checkpoint restore is deferred until the state-save path is fixed on Vulkan. Speed figures in the notes are single runs, explicitly NOT the BENCHMARKS.md protocol. Treat as an upstream/report record only: single-payload fork-vendor verification on gfx1151 Vulkan, not a HaloBench benchmark result, and not inherited into any HaloBench number. SUPERSEDED as an operative statement by fork v0.6.10 (see con-0009/clm-0107, 2026-08-22T12:03:16Z), which restored token-exact MTP rollback (root cause: the server re-verifying replayed draft tokens after a checkpoint restore) — this record stands as the historical v0.6.8/v0.6.9 report.