NVIDIA 于 2026 年 9 月 23 日公开 SWE-Serve：同一批 627 个补丁加真实服务路径检查后通过率从 69.4% 降到 45.9%。 ## 这条复盘的是评测口径，不是模型能力 前置部署 Forward Deployed Engineer（FDE）在客户机房最常做的一件事，是给推理服务改源码：客户要支持一个新模型、一个新量化格式，或者要在隔离网络里换掉某个组件，FDE 直接改 SGLang 与 vLLM 这类推理引擎的代码再上线。这条内容的落点就是这类改动的验收问题——编码智能体给出的补丁，能不能在真正起了服务之后跑通。 前置部署 Forward Deployed Engineer（FDE）能从这条里直接拿走三个数字：627 个补丁在完整验证器下通过率 45.9%、去掉真实服务路径检查后升到 69.4%、以及跨运行时域的任务通过率比单域任务低 21.3 个百分点。这三个数字合起来回答一个问题——只看单元测试，你的评测会乐观多少。 本条属于评测方法与验收口径的建设复盘，不是工具版本快讯，也不含可直接复制的命令行配置。前置部署 Forward Deployed Engineer（FDE）要先划清一条边界：所有数字都来自 NVIDIA 的单方面发布与配套论文，没有第三方独立复现，也没有客户侧的交叉验证。 ## 一、原来的做法：补丁过了测试就算解出来了 编码智能体的评测长期以仓库级测试通过率为准：补丁能让测试转绿，就记为解出。SWE-Serve 这篇复盘给出的反例是，推理服务软件的改动，失败经常只在真正起服务之后才出现。 NVIDIA 在原文里的表述是：一个编码智能体的补丁可以通过测试，却在服务器装载真实模型并处理请求时失败。所以评测推理服务软件的改动，必须检查完整的服务路径，包括系统是否通过公开接口返回正确结果。 前置部署 Forward Deployed Engineer（FDE）在客户现场遇到的正是这一类改动：补丁在本地仓库里测试全绿，装到客户机器上起服务后请求报错、返回空响应，或者批处理顺序错了而单元测试看不出来。本条把这种乐观偏差从经验判断变成了可测量的数字。 这条也是本次评测建设的动机：不是模型不行，而是评测方式没有覆盖最容易出事的那一段路径。 ## 二、新做法：把 83 个已合并的 PR 拆成 53 个可执行任务 SWE-Serve 把 83 个已经合并的 SGLang 拉取请求转成 53 个可执行任务，分布在六个推理工程族上：推测与高级解码 14 个、模型与后端启用 12 个、内核与量化与性能 8 个、服务 API 与运行时正确性 8 个、缓存与运行时状态 7 个、分布式执行与调度 4 个。 任务按硬件分组：12 个任务跑在 CPU 上，41 个任务使用单张 NVIDIA H100。原文明确写出首个版本不评估其他推理引擎，也不覆盖多 GPU 执行与多节点服务。 任务的来源也有口径：37 个任务来自单个上游拉取请求，另外 16 个任务把二至六个相关改动合并成一道题，合计取材于 83 个已合并的 SGLang 拉取请求。SGLang 团队是发布伙伴，负责提供难题线索、推荐特别苛刻的拉取请求，并参与设计正确性验证思路。 每道任务给智能体一份指令，加一份改动之前的容器化 SGLang 代码检出。补丁是否通过，只取决于它是否在声明的硬件上满足该任务隐藏的验证器；补丁从不与参考实现做比对。 这些改动的体量不小：参考解的中位数是修改 553 行、涉及 7 个文件；一个典型验证器包含 7 个新行为测试与 10 个回归测试；19 个任务会启动真实服务器，其中 3 个还会在 H100 上强制一道经过标定的性能门。 举个例子：一道任务要求为稠密版与专家混合版 Qwen3.5 增加服务支持，智能体必须在单张 H100 上让 0.8B 稠密模型与 35B-A3B 专家混合模型都能通过常规 SGLang 接口加载并服务。它的验证器会检查模型注册、配置与权重加载、图像与视频输入、OpenAI 兼容请求、原生批处理生成、对数概率，以及是否真正走通了专家混合模型的路由专家。 ## 三、前后对比：627 个补丁，45.9% 对 69.4% 这是本条最硬的一组对照数字。在 19 个会启动真实服务器的任务上，同一批 627 个补丁在完整验证器下的通过率是 45.9%；当真实服务路径测试被排除后，通过率升到 69.4%。换算成绝对数，有 147 个补丁在去掉真实服务测试时由失败变成通过。 原文的另一种表述是：大约每三个通过了其他检查的补丁，就有一个在真实服务测试上失败。 这 19 个任务一共包含 276 条真实服务测试。其中 242 条取自或改编自 SGLang 上游，剩下 34 条是为本次改动新引入的行为补写的，因为上游找不到合适的既有测试。 有一个任务的数字特别具体：在 Gemma 4 专家混合模型那道任务上，33 个补丁里有 16 个通过了所有其他检查，却至少失败一条真实服务测试。这些测试覆盖模型加载、专家路由、文本与图像服务，以及带正确顺序与对数概率的批处理生成。 前置部署 Forward Deployed Engineer（FDE）在验收补丁时要用的对照口径就是这条：同一个补丁集合，加不加起服务这一步，通过率差 23.5 个百分点（本文按原文两个百分比相减得出）。README 与单元测试给的是 69.4% 那个数，客户机房验收面对的是 45.9% 那个数。 ## 四、跨运行时域的任务通过率低 21.3 个百分点 NVIDIA 把从请求到输出的路径拆成四个运行时域：请求处理与输入输出、调度与请求生命周期、模型执行、键值缓存与运行时资源管理。 按每个模型的最佳配置统计，26 个只落在单一运行时域的任务通过率是 69.0%，27 个跨多个运行时域的任务通过率是 47.7%，两者相差 21.3 个百分点。原文强调每一组模型配置都呈现同一方向的差异。 这条对排期有直接影响：跨调度、模型执行与键值缓存三层的改动，通过率大致只有单域改动的一半到三分之二。给客户报工时时把跨域改动按单域口径估，返工概率会明显上升。 原文没有给出跨域任务在时间与成本上的额外开销，只给了通过率差。前置部署 Forward Deployed Engineer（FDE）若要用这条做估算依据，需要自己在项目上补一组实测，不要直接把 21.3 个百分点换算成工期。 ## 五、11 个模型 31 组配置：最高 75.5%，最低 34.6% 评测用 mini-swe-agent 这个只使用 Bash 的最小软件工程智能体，在闭卷条件下跑 11 个模型、31 组模型与推理强度配置。其中两个 Claude 模型与三个 GPT-5.6 模型各测了 5 档推理强度，另外 6 个模型各测 1 组配置。 每组配置把完整的 53 个任务跑三遍；每个智能体会话上限是 210 分钟与 350 步；只有补丁在声明的硬件上通过完整验证器，该任务才算解出。原文报告的是每个模型得分最高的那档配置，均值通过率区间是 34.6% 到 75.5%。 领头两个模型的数字是：Claude Opus 5 在最高推理档 75% 加减 3%、单任务平均成本 17.40 美元、平均耗时 57.5 分钟；GPT-5.6 Sol 在最高档 75% 加减 6%、单任务平均成本 12.26 美元、平均耗时 29.5 分钟。中间档里 Claude Sonnet 5 的 xhigh 档是 64% 加减 3%、6.61 美元、40.6 分钟；Kimi K3 最高档 64% 加减 5%、7.24 美元、99.9 分钟。 成本与得分并不对齐：四组并列 64% 的配置里，单任务平均成本从 0.95 美元到 7.24 美元，平均耗时从 25.5 分钟到 99.9 分钟。原文还有一句反直觉的结论——原生工具链没有帮到两个领头模型：GPT-5.6 Sol 在 Codex 里得分 73.6%，Claude Opus 5 在 Claude Code 里得分 69.8%，两者都低于各自用 mini-swe-agent 时的 75.5%。 前置部署 Forward Deployed Engineer（FDE）在读这张表时要避开的结论是：不要按单一总分选模型。原文明确写出没有任何模型在六个工程族上全部领先，总分相同的配置强项可以不同。 ## 六、这套基准自己是怎么被验证的 任务筛选是三段收口：筛过 786 份候选来源，构建出 156 个可执行候选，最终收录 53 个。 每个收录的任务都要在声明的硬件上实测：未修改的仓库必须在新行为测试上失败、同时在回归测试上继续通过；参考补丁必须通过完整验证器。NVIDIA 还用智能体生成的补丁去挑战验证器本身，发现具体问题时就修复、收窄或剔除任务。 评测在闭卷条件下进行：屏蔽公网与上游源码仓库，只允许访问 Hugging Face 取模型权重。原因是开放网络的一次预实验里，模型会去检索该任务对应的上游代码。NVIDIA 审计了排行榜背后的全部 1749 次试验，拦截了 196 次违规检索尝试，没有一次成功。 这一段对自建评测的团队比模型排行榜更有参考价值：先证明题目本身可信，再去比较模型。 ## 七、谁该行动，以及具体怎么做 第一类该行动的是把编码智能体用于推理引擎或服务端改造的团队。前置部署 Forward Deployed Engineer（FDE）的具体动作分四步，每步都可以直接搬。 第一步，在评测里加一层真实服务检查。最小覆盖是：模型注册、配置与权重加载、通过 OpenAI 兼容接口取结果、批处理生成的顺序与对数概率。只要你的改动碰推理引擎，就至少要有这三类断言——服务能起来、公开接口能答、批处理顺序不错。 第二步，把任务按运行时域拆开统计，单域与跨域分开报，不要只报一个平均分。跨域任务通过率会低约 21.3 个百分点，混在一起会把风险藏起来。 第三步，用同一批历史补丁跑两遍评测，一遍带真实服务检查、一遍不带，量出自己评测的乐观偏差。本条给出的参照偏差是 23.5 个百分点；如果你的偏差远低于这个数，说明你的单测已经覆盖了服务路径，可以少投这一层。 第四步，把成本与耗时一起进表。四组同样 64% 的配置单任务成本差 7 倍以上，只看通过率会选到贵而慢的配置；同时把会话上限设死，本条用的是 210 分钟与 350 步。 适用条件有三条：仓库必须能在声明的硬件上从源码构建并起服务；评测要绑定固定硬件（本条 41 个任务绑定单张 H100），换卡后数字不可比；必须有一个隐藏或等价的独立判定器，不能拿模型自己的解释当通过标准。 退出与回滚方式：把真实服务检查做成可独立开关的一层，先用它对历史补丁做一次回溯统计；若偏差低于团队可接受阈值，只保留回归集即可。不要一开始就把它设成 CI 必过门禁——起服务的用例耗时长、依赖 GPU，容易把流水线拖死。回滚后保留原来的单元测试口径，评测结果仍可比。 ## 八、原文自述的局限与本条未覆盖的场景 局限一，首个版本不评估其他推理引擎，也不覆盖多 GPU 执行与多节点服务；结论只在单卡场景成立。 局限二，通过率只代表满足基准验证器。原文写明这不等于补丁可部署、可合并，也不代表获得 SGLang 维护者的背书。 局限三，样本量对单个模型之间的细小差异未必显著：龙头配置的标准差达到加减 6%，也就是说 75% 与 73% 之间的差别不能当结论用。 局限四，成本口径分两类：可调用 API 的模型按记录的 token 用量与冻结价格计算，可下载模型按托管费率估算，都不含基础设施、人力与失败重试之外的开销。 局限五，闭卷条件下 1749 次试验拦截 196 次违规检索、0 次成功，只说明本次封锁有效，不能推断其他团队的自建评测环境同样安全。 局限六，原文没有公布真实客户流量下的长尾请求表现，也没有多租户共享集群上的资源争用数据，因此通过率不能直接外推为生产可用率。 本条未覆盖的场景包括：非 SGLang 引擎的等价评测怎么搭、跨域任务的工期与成本换算、以及把这一层检查接入客户 CI 后的流水线耗时增量。前置部署 Forward Deployed Engineer（FDE）需要提前接受的限制是，本条不含可复制的命令与配置，仓库与论文才是入口。 ## 九、与本站既有条目的差异说明 检索本站已发布列表的标题，含 SWE-Serve 的条目为 0 条；含 SGLang 的条目为 1 条，是 v0.5.20 的版本发布，落点是 CUDA 12 通道退役与推理服务升级；含 NVIDIA 的条目为 1 条，是容器工具包 v1.20.1 的版本发布。 本条与那两条的落点不同：它们讲的是版本里改了什么，本条讲的是评测补丁时用什么口径判定通过，属于评测方法论。 本站已有的评估类条目分别落在商业智能助手的段落评估、云监控的内置评估器与检索器的步数上限上。前置部署 Forward Deployed Engineer（FDE）在本条里换到的是编码智能体在推理服务仓库上的基准建设复盘，与上述条目的技术面不重叠。 ## 原始来源 原始来源： https://developer.nvidia.com/blog/how-swe-serve-exposes-the-gap-between-local-tests-and-live-serving/ https://arxiv.org/abs/2609.26777 https://github.com/NVIDIA/swe-serve https://research.nvidia.com/benchmarks/swe-serve