AREX Feed Article
AMD 宣布 EAGLE-4 首日即运行于 Instinct MI355X：Qwen3.8-27B 单请求约 300 tokens/s，SGLang 与 ATOM 引擎均可用
AMD 于 10 月 20 日（UTC）发布，宣布 EAGLE 团队最新的投机解码（speculative decoding）草稿器 EAGLE-4 自发布首日（day 0）起即运行于 AMD Instinct MI355X GPU，在 SGLang 与 ATOM 两种推理引擎中开箱即用，checkpoint（模型权重文件）与服务启动参数都与其他硬件相同。按 AMD 自测，在 BF16 精度的 Qwen3.8-27B 上，单张 MI355X 服务单请求约 300 tokens/s，为纯解码的 3.5 倍、模型内置多 token 预测（Multi-Token Prediction，MTP）的 1.6 倍；增益在 1～32 路并发会话下保持，扩展到四卡张量并行后，单请求可达 463～489 tokens/s。
EAGLE-4 的官方推理代码同日公开于 GitHub 仓库 ：核心是可 pip 安装的 eagle-harness v0.1.0，通过引擎插件驱动 SGLang、vLLM 与 TokenSpeed，随附 。该仓库的引擎支持表里，MI355X 对应的 SGLang ROCm wheel（预编译包）索引已就位，容器镜像则标注「尚未发布（需自行构建）」。AMD 这次补上的是厂商一侧的内容：覆盖单卡到四卡的 MI355X 自测成绩、一套针对这块 GPU 的适配工作，以及此前不在该引擎名单中的 ATOM。
为 MI355X 完成的首日工程：实测成本表、Gated DeltaNet 树验证与无损校验
按 AMD 文章的概括，投机解码让小草稿器一次猜出多个 token，大模型一步并行验证；EAGLE-4 一次只草拟一个 token，因此每一步都能停下、加深或加宽猜测树。要让它在 MI355X 上首日就跑出成绩，AMD 列出了三项工作。
第一，在这块 GPU 上实测 EAGLE-Harness 的成本表。EAGLE-Harness 在启动时测量草稿与验证在这台硬件上的真实开销，服务时据此挑出单位成本下接受 token 最多的树——单用户用宽而深的树，高负载退回短链。AMD 称已在 MI355X 上完成测量，使树尺寸适配这块 GPU；文中的复现命令显示，每块 GPU、每种张量并行（tensor parallelism，TP）尺寸要跑一次 engine_cost.py，约 10～20 分钟。
第二，为 Qwen3.8 的线性注意力层（Gated DeltaNet）新增树验证：一整棵猜测树一次通过检查，只保留被接受分支的状态。在 SGLang 路径里，这一能力由三个 SGLANG_GDN_TREE_* 环境变量开启，底层是 FlyDSL 的树验证。
第三，AMD 称做过无损性检查：每个输出 token 与纯解码结果一致，仅在取值接近打平处允许 BF16 舍入带来的差异。
单卡实测：四种配置在四档并发下的吞吐
AMD 给出的单卡（TP1）矩阵如下，测试对象为 BF16 权重的 Qwen3.8-27B，基准为 SPEED-Bench，单位 tokens/s：
| 并发会话数 | 1 | 4 | 16 | 32 |
|---|---|---|---|---|
| 纯解码（SGLang） | 82 | 292 | 872 | 1,285 |
| 内置 MTP（SGLang） | 178 | 617 | 1,743 | 2,551 |
| EAGLE-4（SGLang） | 289 | 941 | 2,167 | 2,784 |
| EAGLE-4（ATOM） | 309 | 976 | 2,309 | 3,243 |
单请求场景里，SGLang 跑出 289 tokens/s、ATOM 跑出 309 tokens/s，「约 300 tokens/s」即来自这两行，后者相当于纯解码的 3.8 倍。AMD 把相对内置 MTP 的 1.6 倍归因于验证通过率：单请求下 EAGLE-4 每步验证约接受 4.7 个 token，内置 MTP 约 2.9 个。负载上升时，EAGLE-4 随 GPU 占满而缩短猜测，AMD 称其在 32 路并发下仍领先内置 MTP：SGLang 2,784 对 2,551，ATOM 3,243。
基准口径也在文中写明：取 EAGLE-4 论文所用 SPEED-Bench 定性拆分（qualitative split）中每类每 10 段取 1 段、共 88 段对话逐轮重放（完整数据集为 880 段），开启 thinking（思考模式）、温度 0，tokens/s 按生成 token 数除以墙钟时间。
多卡扩展：从两卡到四卡张量并行
AMD 给出的多卡数据从两卡延伸到四卡：两张 MI355X 张量并行下单请求 403 tokens/s（ATOM）；四卡（TP4）时成绩如下表：
| 并发会话数 | 1 | 4 | 16 | 32 |
|---|---|---|---|---|
| 纯解码（SGLang） | 156 | 539 | 1,655 | 2,331 |
| 内置 MTP（SGLang） | 303 | 1,036 | 2,711 | 3,916 |
| EAGLE-4（SGLang） | 463 | 1,360 | 3,339 | 4,474 |
| EAGLE-4（ATOM） | 489 | 1,347 | 3,381 | 4,796 |
按 AMD 给出的倍率，SGLang 下四卡单请求为纯解码的 3.0 倍、内置 MTP 的 1.5 倍；到 32 路并发，两个倍率仍有 1.9 倍与 1.14 倍。
ATOM 加入 EAGLE-4 引擎名单，两条复现路径已公开
ATOM 是这次宣布里的新名字：EAGLE-4 仓库的引擎名单列的是 SGLang、vLLM 与 TokenSpeed，而 AMD 的测试把 EAGLE-4 跑在 SGLang 和 ATOM 上。AMD 文章的测试配置显示，其 ATOM 路径基于 ，运行在 nightly（每夜构建）容器 rocm/atom-dev:nightly_202610131505（ROCm 7.2.4，含 aiter 与 FlyDSL）中。ATOM 仓库自称「AiTer Optimized Model」，是一个基于 AITER 做集成与优化的轻量类 vLLM 实现；其新闻栏还显示，今年 7 月 AMD 关于 Kimi-K3 在 MI355X 上首日部署的技术文章同样以 ATOM 为载体。
两个引擎在测试中用树的方式不同：SGLang 在表内所有并发下都使用 EAGLE-Harness 的动态树，ATOM 在 16 路并发以内按批量大小用固定树、32 路并发用链。
复现方面，AMD 给出两条路径。ATOM 侧是一条命令的 build_and_repro.sh，README 列明 TP 尺寸、并发等选项；SGLang 侧使用 （EAGLE-4 发布所用的 SGLang 复刻仓库，默认分支 eagle/v0.1.0 即发布版），在 MI355X 的 ROCm SGLang 镜像中先测成本表、再按文中命令启动服务。两个引擎共用 EAGLE-4 仓库的 SPEED-Bench 客户端 client_speedbench.py 与数据集 question_multiturn.jsonl。
AMD 在文末称，下一步想把 EAGLE-4 带到更多模型，并把它与单请求 megakernel（把整段前向计算合入单个持久内核）方案结合以进一步降低延迟；AMD 同日发布的 称，megakernel 加投机解码等手段在单请求 GSM8K 测试中取得 1.9～3.3 倍解码提速。AMD 同时表示欢迎 EAGLE 团队、模型开发者与社区合作。
不过，文中全部性能数字与无损性结论均为 AMD 自述的自测结果，报道未能独立复核；分发形态也尚未完全落地——EAGLE-4 仓库引擎支持表中，MI355X 的 SGLang ROCm 容器镜像标注「尚未发布」，AMD 的 ATOM 路径依赖开发者分支与 nightly 容器，尚未进入正式版本。