AMD、Embedded LLM · vLLM Blog · 阅读原文
原始来源：AMD、Embedded LLM · vLLM Blog
发现渠道：AIHOT · 聚合线索
多轮编程 Agent 会重复发送很长的历史，服务端能否复用这些计算，往往比纸面矩阵算力更影响吞吐。Kimi K3 同时有保存压缩历史的 MLA 注意力，以及携带固定大小递归状态的 KDA 层；恢复请求时，两种状态必须停在兼容的位置。文章举例：MLA 已缓存到3072个 token，KDA 检查点却只到2048，仍要从2048继续重算，而非直接接上最后一段。
团队在 vLLM 推理服务框架的 AMD 路径上分散跨卡历史缓存，复用已有通信来去掉重复专家计算，融合内核并删除没有消费者的拷贝。它还把较短的投机验证任务切成更多小工作组，让 GPU 能同时执行足够多的工作。投机解码是先草拟若干 token 再由主模型检查；草稿更长只有在整个循环的时间增幅较小时才划算。
博客采用10月9日的 AgentX 快照：两套八卡完整服务栈在90分位 token 间延迟折算为每用户50 token/s的条件下，MI355X 每卡总吞吐约7567，B300约6083，高24.4%。总 token 包含复用输入，速度口径不含首 token 等待；每美元优势另依赖所有权成本模型。这不是所有真实任务的输出速度或费用比例。
可信度 65 · 重要性 80 · 新颖度 75
技术与主题
Agent 系统 · 系统与效率 · Prefix Caching · Hybrid Attention · GPU Kernel Fusion · Speculative Decoding
edwingao28
2026年7月、旧vLLM镜像的MI355X/DSpark故障报告；不是对10月文章版本的重测。
忠实转述（非原句）：他先确认推荐配置能完成启动和预热，随后补报长上下文分析阶段仍崩溃：两台机器分别在约337K和339K已计算token附近出现硬件异常，缓存占用约16%。他据此认为短请求或预热成功不能说明长轨迹可用，并请求进一步调试建议。
编辑评读
“缓存命中”看起来只是是否有旧数据，但混合架构增加了一个恢复一致性的条件：所有相关层都要能从同一位置继续。这个例子比再报一次压缩比例更有工程含义，因为存下来的字节若不能直接复用，仍要花计算恢复。它也解释了为什么应测整次请求，而不能把多个独立内核实验的百分比相加。
外部检查需要保留时间和版本。InferenceX 当前页已经显示10月14至15日的更新运行，50 token/s目标下数字也不同；那不是博客10月9日比较的第二次独立确认。另读到的7月问题 #50347，先以为启动成功就修好，随后约337K上下文又在两台设备复现失败。这个旧案例支持“长轨迹要单测”，却不证明10月栈仍有同样错误。下一步应在固定镜像、相同会话和完成比例下比较冷缓存、暖缓存、首 token 等待与实际输出质量，尤其不要把合成接受率当成模型对真实文本的表现。
需要留意
- 完整服务栈和合成轨迹比较；快照、并发与缓存配置不同；成本不等于公开API账单。