VibeSys 用多智能体在 4 块 MI300A 上构建 Qwen3.5-397B 服务引擎，吞吐达调优后 SGLang 的 2.33 倍

Vic Shihang Li, Keisuke Kamahori, Simon Peter, Baris Kasikci

2026年10月8日

TL;DR：我们使用 VibeSys——我们用于设计系统的多智能体系统——在四块 AMD MI300A 上为 Qwen3.5-397B-A17B（一种混合专家模型）构建了一个服务引擎。没有任何人类编写引擎代码。在 105 小时内，智能体将基线 PyTorch 引擎在多轮聊天工作负载上的有效吞吐量（满足延迟 SLO 的响应吞吐量）从 12.8 tok/s 提升到 2,242 tok/s，是同一硬件上 SGLang 的 2.33 倍。原版 SGLang 无法在 MI300A 上运行该模型，因此我们首先使用 VibeSys 对其进行了移植和调优。

Goodput of the agent-built engine across rounds.

图 1. 在 4× MI300A 上各优化轮次迄今的最佳有效吞吐量（蓝色）。灰点为单次测量运行，包括回退和被拒绝的候选方案。虚线为调优后的 SGLang（961 tok/s）。

VibeServe 论文认为，编码智能体使服务引擎的按部署特化变得可负担，主要是在单块 GPU 上使用小模型。本次部署在规模化条件下检验了这一主张。在 105 小时内，我们的智能体迭代构建了感知模型、硬件和工作负载的优化，最终得到一个定制服务引擎，其有效吞吐量达到 SGLang 的 2.33 倍。

目标

模型。Qwen3.5-397B-A17B 每个 token 激活其 397B 参数中的约 17B，分布在 512 个路由专家上，权重为 MXFP4。在其 60 层中，15 层使用带 KV 缓存的全注意力，45 层为 Gated DeltaNet 层，这是一种线性注意力形式，具有固定大小的循环状态并原地更新。

硬件。每块 MI300A 将 24 个 CPU 核心和 GPU 计算放在同一封装上，共享 128 GB 的 HBM3 内存池，因此权重、GPU 缓存、操作系统页缓存和主机进程都在竞争同一块内存。四块这样的芯片为节点提供 512 GB。

工作负载。一个确定性的多轮聊天基准从 1 个并发会话逐步增加到 192 个。每个会话有 3–6 轮，每轮生成 80–300 个 token，思考时间为 1–8 秒，且每轮都会重新发送完整对话。如果任何响应被丢弃、为空或被截断，则该次运行失败。SLO 为 p95 每输出 token 时间（TPOT）≤ 250 ms，p95 首 token 时间（TTFT）≤ 10 s。我们报告每个系统在爬坡过程中的峰值有效吞吐量。

VibeSys 如何运行

我们使用 VibeSys 驱动优化，这是一个由 VibeServe 原型创建的多智能体系统构建框架。

智能体收到了模型权重、Hugging Face Transformers 参考实现、基准测试，以及硬件和交付物（一个 HTTP 服务器）的自然语言描述。实现智能体被允许使用 PyTorch、Triton 以及 AMD AITER 库中的单个内核，但不得使用 SGLang、vLLM 或 TensorRT-LLM 中的任何服务代码。一个审查智能体根据此规则检查每项更改。因此，智能体自行编写了调度器、缓存、并行、图捕获以及若干内核。

一个编排智能体提出优化假设，并将每个假设分派给一个实现智能体，后者调用基准测试和分析智能体。VibeSys 将每个结果与一个提交绑定，因此编排智能体可以看到跨假设的轨迹。每一轮整合被接受的假设。独立的假设并行运行：105 小时的运行使用了 392.8 小时的智能体时间。每个智能体都是使用 Opus 5 的 Claude Code。

如果一个假设能在 20% 的留出集上提升有效吞吐量并通过正确性检查，则被接受：在 1,088 个教师强制 top-1 token 中至少有 1,074 个必须与参考匹配，并且 5 个贪心参考补全必须全部复现。节点间波动约为 ±10%，超过大多数单一优化，因此接受还要求至少两个同节点配对，将对照和候选在同一节点上背靠背运行。

基线：使用 VibeSys 移植和调优 SGLang

SGLang v0.5.18 无法在 MI300A 上服务此模型，原因有三：

没有 MoE 内核。 SGLang 所固定的 AITER 版本中，每个 MXFP4 内核都仅限于 gfx950（MI350 级），因此在 MI300A 的 gfx942 上，服务器在预热期间中止。通用 Triton 回退方案没有针对此 GPU 上 512 个专家调优的配置，只能达到 HBM 带宽的 1–3%。
内存大小设定。 SGLang 根据加载权重后观察到的空闲内存来确定其 KV 和循环状态池的大小。在共享内存上，通过页缓存加载会使四个 rank 的空闲内存不均衡，因此启动会因内存不足错误、负状态预算或节点停滞而失败。
启动时间。 加载权重约需 60 分钟。随后 AITER 在首次请求时编译注意力内核（约 105 秒），而 SGLang 的 20 秒健康检查会在编译期间杀死服务器。

VibeSys 支持优化像 SGLang 和 vLLM 这样已经高度优化的服务引擎，也支持从 Hugging Face 实现开始。为了让此模型在 MI300A 上运行，我们首先使用 VibeSys 移植 SGLang。智能体编写了一个融合 HIP MoE 内核，在寄存器中反量化 MXFP4 权重，固定 KV 池大小，将内存映射加载替换为对预分片的每 rank 权重进行有界读取（加载时间降至约 1 分钟），并提供了预构建的 AITER 内核缓存。

随后 VibeSys 智能体对运行中的服务器进行调优。在 48 个并发会话下，最大的收益来自使用模型内置多 token 预测（MTP）头的推测解码和 4 个草稿 token（TPOT 中位数 70.9 → 38.3 毫秒）以及针对每个捕获的解码形状的 GEMM 调优表（38.1 → 22.9 毫秒）。较小的收益来自三项 MoE 内核改进、填充并调优的预填充 GEMM，以及禁用重叠调度。调优将有效吞吐量提高了 42%，在 48 个会话下达到 961 tok/s。总体而言，智能体向 SGLang 添加了约 3,500 行代码，其中约 1,900 行用于 MoE 内核、一个小批量 GEMM 内核及其封装。

结果

智能体构建的引擎在 96 个并发会话下达到 2,242 tok/s。这是由 VibeSys 移植和调优的 SGLang 基线峰值吞吐量的 2.33 倍。两个引擎都使用 MTP。调优后的 SGLang 在 48 个会话时达到峰值。在 96 个会话的同节点运行中，其 p95 TTFT 达到 15.5 秒。

智能体构建的引擎约有 19,400 行代码（不包括注释和测试），其中包括 520 行 HIP。与 SGLang 的改动不同，它包含自己的调度器、缓存、并行和 MTP。

智能体优化的是峰值有效吞吐量，这奖励高负载下的吞吐量，而未优化低负载延迟。在低并发下，调优后的 SGLang 仍然更快，并且在 16 个会话时，MTP 使引擎后续轮次的 p95 TTFT 增加了 11–15%。一个包含低负载延迟的目标，例如第 2 轮及以后的 TTFT，将引导优化转向那里。

加速来自何处

图 1 中的轨迹有四个阶段。最后阶段的收益是相对于同一节点上的前一个构建来衡量的。

前缀缓存（12.8 → 55.6 tok/s）

第一个引擎在每一轮都预填充完整对话，而串行预填充使解码资源匮乏。DeltaNet 层只能从保存的循环状态快照恢复，因此智能体构建了一个前缀缓存，同时保存注意力 KV 和 DeltaNet 快照。这带来了 4.3 倍提升。

内核与图捕获（55.6 → 659 tok/s）

每个解码步骤都会启动许多小内核，GPU 等待 CPU。智能体将解码、预填充以及混合解码加预填充步骤捕获为 HIP 图，每步一次启动。他们还编写了融合的 MXFP4 MoE 内核、分块的 DeltaNet 预填充和 split-K 解码注意力，并添加了一个重叠调度器，在 GPU 运行当前步骤时于 CPU 上规划下一步。这一阶段带来了最大的提升，11.9 倍。

通信与并发（659 → 1,055 tok/s）

将模型拆分到四个 rank 上，每层需要两次集合通信，每个解码步骤约 120 次。智能体将原有的 all-reduce 替换为与残差加法和 RMSNorm 融合的一次性版本。更大的解码图，最高支持 batch 128，使引擎能够运行 96 个并发会话，在此情况下它超过了 SGLang 的 961 tok/s。

预填充、缓存与推测（1,055 → 2,242 tok/s）

快照驱逐（+27%）。 每个 DeltaNet 快照约占用 47 MiB，因此前缀缓存能容纳的对话数量远少于纯注意力模型。该缓存是一棵过去对话的树，并在每个分支点存储快照。一旦后续轮次将对话扩展到分支点之后，就不会有请求从该快照恢复。这些过时快照填满了共享内存预算，因此缓存驱逐了活跃对话，其后续轮次随后重新计算完整历史。优先驱逐过时的内部快照，同时保留每个活跃对话末尾的快照，将预填充 token 减少了约 40%。

MTP 推测解码（+16–20%）。 主模型在一次前向中验证 MTP 头草拟的 token。使用 DeltaNet 层时，验证必须对草稿运行循环和因果卷积，并在拒绝时回滚循环状态，所有这些都在图捕获下进行。智能体最初将 MTP 判定为无竞争力，因为捕获版本在首次重放时触发了非法内存访问。后来的一轮找到了原因：图引用了仅由 Python 闭包持有的张量，这些张量在捕获后被释放。使用 2 个草稿 token 时，每个序列在每个验证步骤中生成 2.68 个 token，84% 的草稿被接受。

更便宜的预填充与集合通信。 将等待中的预填充累积成最多 1,536 个 token 的块带来了 +9.3%，无填充地打包预填充序列 +5.6%，MoE 内核中使用 32 行 tile +4.8%。将 all-reduce 重构为 reduce-scatter、RMSNorm 和 all-gather 带来了 +8–9%。

没有帮助的部分

频繁使用专家的 BF16 缓存覆盖了 80–86% 的专家分配，但比 MXFP4 内核慢 5–7 倍，且每个 rank 最多使用 20 GiB。用自定义稠密 GEMM 替代调优的 hipBLASLt、持久化 MoE 内核以及并行路由准备，要么没有效果，要么更慢。智能体丢弃了全部四项。

VibeSys 可在 github.com/uw-syfi/vibesys 获取，论文描述了完整设计。智能体构建的引擎和调优后的 SGLang均已公开。