覆盖 2026-08-23 07:00 至 2026-08-24 07:00（Asia/Shanghai），run 20260824T100354+0800。 自动抓取 118 条、实际命中 6 个源，人工检查 25 个 adapter-required 源；reddit-machine-learning 返回 429。Hugging Face 组织聚合器因历史上容易串行卡住而跳过，随后并发直查 source.yaml 配置的 20 个官方组织端点，均成功返回，窗口内没有同时满足创建时间与 3 likes 阈值的新仓库。xAI、Ai2、Z.ai 等重点源仍有 403、404、超时或无带日期列表的缺口，均按“未能核实”处理。

今天的共同主线是：投机解码已经从“开或不开”的功能项，变成要按模型、draft 方法、任务分布、proposal length 与硬件共同扫参的运行策略。 vLLM 的 AMD 实验把 native MTP、Gemma 4 MTP、EAGLE-3、DFlash 与 DSpark 放进同一张地图：同一方法可以在一组任务里超过 2 倍，也可以在另一组配置里低于 autoregressive baseline。更长的草稿不是免费午餐，接受率也不是最终目标；部署者真正要优化的是端到端 throughput、延迟与稳定性。

今日重点关注

  • vLLM 把五种 speculative drafting 路径放进同一套 AMD 实验。 高位结果包括 Gemma 4 26B-A4B 的 DFlash 2.87 倍、Gemma 4 MTP 2.83 倍，以及 Kimi-K2.5 的 DFlash 2.68 倍；但 Qwen3-8B 的 EAGLE-3 在 MATH500 上仍低于无投机 baseline。（vLLM）
  • 最佳 num_speculative_tokens 随模型和 workload 改变。 native MTP 的高点在 N=3–7 之间移动，DFlash 常在 N=7 附近较好；把 block 支持到 15 个候选，不等于 15 就是最高吞吐。（vLLM tuning）
  • 本地推理也在暴露同一个边界。 一名 RTX 3090 用户称 Qwen3.8-27B 在 90K context 下从约 50 tok/s baseline 调到 70+ tok/s，但 N 从 2 加到 3 反而因拒绝增加而变慢；这是带完整 flags 的个人实测，尚未独立复现。（原帖）
  • llama.cpp 同一天补了三类“能不能正确跑”的边界。 GLM-4.5-Air 获得 MTP 支持；DeepSeekV4 修复 multi-sequence rollback；默认日志不再只为被丢弃的设备信息创建 CUDA context、占用约 550MB VRAM。（b10603、b10593、b10594）

三、AI Infra

本节以 vLLM/AMD 的完整实验与配置为事实底座。所有加速比都绑定原文披露的模型、draft checkpoint、benchmark、proposal length、硬件与软件版本；不把厂商测得的 output-token throughput 外推成任意线上请求的端到端延迟。

五种 draft 路径不是五个名字，而是三种依赖结构

按 vLLM 的方法分解，Speculative decoding 的共同合同没有变化：draft 先提出未来 token，target model 一次核验多个位置，只提交从左到右通过验证的前缀；遇到第一个拒绝后，后续候选全部丢弃。加速来自减少串行 target decode step，而不是让 draft 替代 target。差异在 draft 如何借用 target 的状态，以及生成候选时还保留多少串行依赖。

  • Native MTP 是目标模型自带的辅助预测路径。它把 target hidden representation 与当前 token 信息结合，逐步生成候选；不加载单独 checkpoint，但每多猜一个 token 仍多一段顺序 drafting 工作。
  • Gemma 4 MTP 使用与特定 target 配对的独立 assistant checkpoint，同时复用 target activation 与 KV cache。它在部署上是独立权重，在数据依赖上仍紧贴 target，也仍逐 token 起草。
  • EAGLE-3 从 target 前、中、后层抽取三段 hidden state，拼接投影后交给独立 draft decoder；后续候选依赖前一个 draft 输出，因此也是 autoregressive drafting。
  • DFlash 把 target 的多层 hidden state 融成每个 draft layer 都能访问的额外 K/V，再在一次 forward 中并行预测整块 masked positions。它拿掉了候选之间的完整自回归反馈，换来更短的 draft critical path。
  • DSpark 在 DFlash 式并行 backbone 后加轻量 Markov head，按前一个已选 draft token 修正下一位置 logits；另有 confidence head 决定应送多少前缀去验证。不过这次 vLLM 实验没有启用 confidence-based prefix selection，因此结果只代表并行 backbone 加 Markov correction，不能与此前的 adaptive verification 数字直接合并。

这张结构图解释了为什么“哪一种最好”没有固定答案。顺序 draft 的接受率可能更高，但草稿本身更贵；并行 draft 更便宜，却可能在较后位置失去一致性。target 越大、target step 越贵，省下一次验证越值钱；draft 越大、并发越高或接受率越低，起草与验证的额外工作越容易反噬。

最高 2.87 倍和低于 baseline 同时成立

实验覆盖包括 Gemma 4、Qwen3/3.5/3.6、Kimi-K2.5 与 MiniMax-M3 的不同 target-method 组合，任务使用 GSM8K、MATH500、HumanEval、MBPP 等 task-grounded benchmark。主平台是 8× AMD Instinct MI300X；MiniMax-M3-MXFP8 另用 8× MI355X。软件为 Ubuntu 22.04.5、ROCm/HIP 7.2.53211、vLLM 0.23.1 的开发快照、PyTorch 2.11.0 与 Transformers 5.13.1。

结果不支持把单一方法写成赢家。Gemma 4 26B-A4B 上，Gemma 4 MTP 在 GSM8K/MBPP 的 sweep 高点为 2.74/2.62 倍，DFlash 在 MATH500/HumanEval 为 2.87/2.79 倍，EAGLE-3 四项为 2.11–2.27 倍。Qwen3-8B 上，DSpark 为 1.15–1.63 倍、DFlash 为 1.08–1.27 倍；EAGLE-3 在三项高于 baseline，MATH500 的最高值仍低于 baseline。

同系列模型也会反转。Qwen3.6-27B 的 native MTP sweep 高点高于 DFlash；到了 Qwen3.6-35B-A3B，DFlash 四项达到 1.77–2.06 倍，而 native MTP 只有 1.28–1.49 倍。Kimi-K2.5 的 EAGLE-3 最高 2.33 倍、DFlash 最高 2.68 倍；MiniMax-M3-MXFP8 的 EAGLE-3 在 HumanEval、N=4 时为 2.09 倍。这些数字证明的是“在披露配置里可达”，不是跨硬件、并发和请求分布的固定倍率。

N 是运行参数，不是模型常数

vLLM 的 tuning 说明把 num_speculative_tokens 视为需要 sweep 的运行参数：N 增大时，一轮验证有机会提交更多 token，但后部位置的接受概率通常下降。被拒绝的候选仍消耗 draft 与 verification 计算，所以曲线可能先升、再平台、再回落。vLLM 建议 native MTP 从 N=1 开始，再扫 2–7；DFlash 的 block size 16 虽允许最多 15 个候选，实际应比较 N=3、7、11、15。

原文的 sweep 说明最佳 N 会跟任务走：Qwen3.5-27B 的 GSM8K/MATH500 高点在 N=5，HumanEval/MBPP 在 N=4，MT-Bench 在 N=3；Qwen3.5-122B-A10B 的四个推理/代码任务高点在 N=7。DFlash 常在 N=7 较高，部分 workload 到 N=11，继续加长却不稳定增益。

因此部署时至少同时记录 throughput、mean accepted length、overall acceptance rate 与 per-position acceptance rate。高接受率不必然高吞吐——draft 太贵时仍会输；低一些的接受率也不必然失败——并行 draft 足够便宜时仍可能赢。选择 N 应绑定真实 prompt、sampling、batch/concurrency 与 SLO，而不是抄模型卡的一条示例命令。

llama.cpp 的三个小修复，补的是可用性而不是排行榜

b10603加入 GLM-4.5-Air 的 MTP 支持，把模型原生的多 token 预测头接进本地 speculative path；release 本身没有给吞吐数字，所以这里只能确认“支持已落地”，不能宣称具体加速。

b10593修复 DeepSeekV4 的 multi-sequence rollback：包括模型加载、pending rollback 只使用一次、full load 时只清理对应 seq_id 的 cache，并把 graph topology 固定下来。它提醒服务端并发下的 speculative correctness 不只是 token 接受算法，还包括每条 sequence 的回滚与 cache 生命周期。

b10594处理的是更隐蔽的资源副作用：旧逻辑即使默认日志不会打印设备信息，也会遍历设备、查询显存并创建 CUDA context，约占 550MB VRAM；新逻辑先检查是否为 trace verbosity，若结果最终会被日志函数丢弃，就不触碰 GPU。对紧贴显存边界的本地部署，这类启动路径可能比一项 microbenchmark 更直接地决定模型能否装下。

四、Agent 系统与 Harness

本节只把带原始配置与明确限制的社区报告作为个人实测，不视为独立 benchmark。一个 600K-token C 项目移植实验尤其说明：模型、上下文窗口与 GPU 都够大，并不保证 harness 会把墙钟时间转成有效工作。

原帖要求把一份 2.1MB、约 600K token、39K 行的单文件 C 游戏移植成 single-file HTML/three.js。输入超过 262,144 context 两倍，agent 必须自己遍历源码、判断哪些部分值得保留。Qwen3.8-27B 以 FP8 跑在 vLLM、FP8 KV cache 与 RTX PRO 6000 96GB 上；作者各跑一次：Hermes 用 4 小时 18 分输出 949 行，Codehamr 用 1 小时 40 分输出 1,056 行，两者都被作者评为 bad；Claude Code + Opus 5 的云端参考用 21 分钟输出 1,759 行，被评为 okay。

这不是模型排行榜：每个组合只有一次运行，“bad/okay”是作者对 playable quality 的主观判断，模型、harness 与云端后端也没有受控隔离。它有价值的地方是把失败预算写全了。更重的 harness 并没有自动弥补一条 thin one-shot prompt；在输入远大于 context 时，文件遍历、摘要、编辑与验证策略决定 GPU 运行数小时后是否仍在有效收敛。对长程 agent，token/s 只是局部速度，最终还要看 work/s、重试次数、有效 diff 与墙钟时间。

社区实测：配置比“开了 MTP”更能解释结果

以下数字均来自当日原帖，未独立复现；它们不承担模型发布或通用性能事实，只用来展示参数敏感性。（RTX 3090 MTP 原帖；RTX PRO 6000 量化原帖）

  • 同一张 RTX 3090 上，MTP 可以加速，也可以倒退。 Qwen3.8-27B Q4-UD_K_XL、90K context 的作者先看到约 50 tok/s baseline，错误配置时降到约 35 tok/s；最后以 temp 0、--spec-draft-n-max 2、CUDA Graph optimization、Q8 KV cache 与 batch/ubatch 2048 报到 70+ tok/s。N=3 因更多候选被拒而慢于 N=2，高 temperature 也降低 draft acceptance。完整 flags 让它可复查，但单用户、单任务与未披露测量时段限制了外推。
  • 量化的速度、分布接近度与视觉样例不是同一指标。 Atomic 团队在 RTX PRO 6000 上报告 Qwen3.8-27B 的 AD-Q4_K_M 为 17.1GB、95.6% top-1 agreement、mean KLD 0.0113、67 tok/s；AD-Q6_K 为 25.0GB、98.7%、0.0011、49 tok/s；Q8_0 为 28.9GB、98.9%、0.0006、50 tok/s。作者只用一个 voxel-island 生成任务作展示，评论也指出采样随机性可能大过量化差异；表格能说明压缩—分布—速度取舍，不能证明 Q4 在一般任务上与 BF16 等质。
  • 超长代码任务里，更多 agent machinery 也可能只延长失败。 上述 600K-token 单次移植中，两个本地 harness 都没有产出可用结果，耗时却相差 2.6 倍；作者自己把结论降级为 prompt/harness 配置问题，而不是 Qwen 与 Opus 的通用能力差距。（原帖）

三条实测与 vLLM 的正式 sweep 指向同一件事：优化必须保留完整条件。 模型版本、量化、context、KV dtype、sampling、draft N、CUDA Graph、batch、harness 与任务共同定义结果；只抄一个 tok/s 或“2×”会把可复现性丢掉。

深度阅读

  • **Exploring Speculative Decoding in vLLM on AMD GPUs**｜约 35 分钟 适合 inference、serving、runtime 与本地模型工程师。建议先读五种方法的数据依赖图，再看 model-method coverage、proposal-length sweep 与 per-position acceptance appendix；和本期“没有通用最优 N”直接对应。建议 digest：yes。
  • **Speculative Decoding**｜约 12 分钟 适合先补算法合同再读工程 sweep 的读者。重点区分 draft proposal、target verification、最长接受前缀与 lossless 的适用条件，并与 MTP 的训练目标分开。窗口外延伸一篇；本节的当日实验入口仍以 vLLM 原文为准。

来源与口径

  • 证据窗口为 2026-08-23 07:00 至 2026-08-24 07:00（Asia/Shanghai），immutable run 为 20260824T100354+0800。自动抓取 118 条、命中 6 个源；25 个 adapter-required 源均已记录 no_update、blocked 或 unreachable。正文一手主线来自 vLLM/AMD与 llama.cpp releases。
  • 自动源唯一错误是 reddit-machine-learning HTTP 429。HF 聚合器本轮显式跳过后，补查 20 个配置内官方组织 API；全部可达，窗口内没有满足创建时间与 3 likes 阈值的新仓库。原始响应已保存到本 run 的 raw/hf-org-audit/。
  • 重点手工源中，xAI 与 Ai2 为 403，Z.ai 为 404，Mistral 超时；Anthropic Engineering、Qwen、DeepSeek、MiniMax、StepFun、LongCat、混元、MiMo、Artificial Analysis 与 LMArena 缺少可按时间审计的列表或日期。不能访问或不能证明时间，都没有被改写成“没有更新”。
  • Import AI 没有窗口内新一期；本期也没有 longform: true 新文，因此未触发 longform-scout。无需论证图，未使用 PicGo。
  • smol.ai 最新完整一期仍是 08-21，明确覆盖 08-20–08-21，早于本期窗口；Twitter/Reddit 两节已完整审阅但只作 coverage_only，没有挪用旧 recap，也没有生成固定 Twitter/Reddit 栏目。正文中的 Reddit 数字均回到本期原帖，标为个人实测并保留硬件、版本、配置、样本和未复现限制。
  • discovery-only 来源只承担发现与覆盖审计；正文中的发布事实、实现变化与正式 benchmark 均回到一手页面。社区样本不升级成厂商能力结论，厂商 throughput 也不跨硬件、并发或 workload 外推。