SGLang推理优化：Harness、Loop与图工程实践

1.1 实现状态与可用性

2. 推理即部署空间

推理栈仓库

4.2.2 起始上下文

4.3.3 执行路由

6. 一位工程师，多条循环

6.1 从执行到判断

6.2 飞行中的观测任务

6.3 项目级协调

8.2 证据驱动的任务图

8.3 证据完整性

推理优化在代码中看似局部，但其有效性是全局的。一个 kernel、通信路径或调度变更只在由模型、工作负载、SLO、服务拓扑、运行时版本和加速器平台所定义的特定部署点上才有意义。同一个补丁可能改善一个点而劣化另一个点。AI 智能体辅助探索可以产生更多的环境、实验、测量和被拒绝的路径，所有这些都必须保持可复现性。

因此，首要要求是可靠的执行。要复现一个部署点，模型能力是不够的：工具、环境、上下文、记忆、验证和安全边界必须保持稳定。Harness 工程将这些周边条件转化为一个可复现且可检查的执行系统——这是抽象 Agent = Model + Harness 的基础。

可靠的执行必须随时间保持一致。推理工程任务通常跨越多轮调查、实现、部署、评估、失败和恢复。Loop 工程将连续的执行连接起来，使一个任务能够保持其任务契约、纳入新证据，并通过产生经验证的交付物或可靠的后续交接来满足其退出标准。

项目级工作超越了一个任务的边界。多个任务必须并行推进、交换交付物、共享状态、在证据积累时触发返工和改变方向。Graph 工程将独立收敛的任务循环组织成一个不断演化的任务图。该图将已发布和已拒绝的路径与其依赖、约束和证据保持连接，使项目决策保持可解释性。

Infer-forge 将这一方法论应用于围绕 SGLang 的推理工程。其范围遵循一个工程变更穿过推理栈的路径：从 kernel 和通信库，经过引擎集成与部署，再到评估和在线诊断。一个共享工作区和三个不断积累的执行结构保持这条端到端路径的一致性：

• MonoRepo 为跨仓库工程建立可复现的工作区。
• Harness 提供可复用的执行能力、记忆、验证和安全边界。
• Task Loop 保持一个长期运行的任务向前推进，直至达到其退出标准。
• Task Graph 将独立收敛的任务连接成更大的目标，包括项目交付和能力演进。

1.1 实现状态与可用性

Infer-forge 是一个围绕 SGLang 独立开发的内部工程系统；它不是 SGLang 或 LMSYS 的官方组件。

Infer-forge 目前未开源，因为其核心组件与内部仓库、基础设施、工作流和安全控制深度耦合。因此，当前代码库在我们环境之外的可移植性有限。

取而代之，本文公开了构建方法论。我们的目标是让团队和个人将其交给 AI 编码工具，添加自己系统的上下文，并快速构建适合其环境的 infer-forge 实现。

Infer-forge 已从工作流设计转入持续工程使用。在一位工程师 4 月至 7 月的记录中，观测到的飞行中任务峰值从 2 个增长到 9 个。在一个 DeepSeek-V4-Pro 服务项目中，38 个独立可验证的任务节点跨七个任务类型被协调为任务图。综合来看，这些记录展示了 infer-forge 在四个月工程记录和项目级任务图中持续使用的情况。

一个有能力的 AI 智能体可以让一次执行成功；一个工程系统旨在让成功的工作可复现。Infer-forge 不承诺每个任务都会更快完成。它提供了保持每个部署点来源的结构、在长期任务中维持可验证工作、以及跨任务边界协调证据的结构。

2. 推理即部署空间

图 1 将上面介绍的部署点转化为一条具体的约束链。模型决定了支持的模态和模型特定的执行路径。服务场景将模态和流量形态转化为 SLO。该 SLO 约束服务拓扑，其中部署架构与并行策略相结合。然后，拓扑通过版本化运行时配置文件实现，该文件锁定特定服务修订版本的引擎配置和容器镜像。最后，完整的运行时必须在加速器平台上构建和验证。部署点是通过这条链的完整路径——而不是孤立的任意一层。

没有脱离上下文的推理优化。不同的服务目标和 SLO 可能需要根本不同的部署路径，包括 Colocated PD、PD 分离和 EPD 分离。每种架构都改变了阶段边界、通信路径、资源平衡和可行的并行策略集合。这些决策传播到必须验证的运行时配置文件和加速器特定实现中。一个 kernel 改进只有在完整部署点复现了它并通过了吞吐量、延迟、正确性和稳定性门控时，才能成为服务结果。没有其部署点，性能声明无法被复现、比较或延续。

Infer-forge 不消除这个组合空间；它使每次穿越它都变得明确且可验证。我们不是让 AI 智能体"优化 DeepSeek-V4-Pro"，而是定义一个记录当前部署点、约束其可变更的维度子集、在执行开始前锁定验证门控的任务。一个任务可能在保持服务场景、拓扑和加速器不变的情况下替换 MoE 后端，然后产生接受的改进或记录在案的拒绝。两种结果都为下一个任务减少了不确定性。然而，在任何任务可以复现之前，部署点背后的精确跨仓库代码状态必须被固定。这就是 MonoRepo 的角色。

推理优化跨越仓库边界，但必须作为一个连贯系统交付。一个变更可能始于一个 kernel 库，依赖一个通信后端，通过引擎集成进入 SGLang，最终需要一个匹配的部署配置。当这些仓库位于独立的工作区时，它们之间的关系成为 Transient Knowledge，工程师和 AI 智能体必须反复重建。一个缺失的分支或不兼容的修订版本就足以使结果失效。

Infer-forge 将该依赖图转换为共享工作区。Git 子模块将相关仓库放置在一个根目录下，同时保留它们独立的历史、分支策略、访问控制和发布流程。该根为工程师和 AI 智能体提供了推理栈的稳定映射和跨仓库工作可以开发和验证的单一入口点。

该结构在三个方面改变了跨仓库工作：

整个栈保持在视野中。 仓库边界保持明确，但它们的工程关系从一个工作区可见。

上下文保持有界。 AI 智能体可以导航完整的仓库映射，同时仅加载当前任务所需的仓库。

集成就地开始。 相关分支可以开发、组合和验证，而无需反复定位仓库或从记忆中重建它们的关系。

工作区协调变更；任务记录使其持久。每个任务捕获用于工作的分支、提交和执行状态，日志在完成后归档。仓库可以继续演进而不擦除已经验证和交付的工作的来源。

一个工作区不意味着一个未分化的代码库。Infer-forge 按工程角色分离仓库：内置工作区协调跨仓库工作，推理栈仓库包含正在被变更的服务系统，Harness 仓库将这些变更从执行带到经验证的证据。

内置工作区是 infer-forge 的协调层，而不是另一个实现仓库。代码保留在其所属的仓库中。根目录仅包含需要在仓库边界上操作的机制：

Task System 将一个 Task 所需要的工作空间具体化：相关的仓库、环境入口点、记录位置，以及当需要隔离时——一个专属的 worktree 和 AI 智能体会话。

Cross-lib Management 使仓库图可操作。它维护仓库位置、默认分支，以及用于同步和集成变更的操作。实际用于某项工作的分支和提交属于 Task 记录，并归档到 Journal 中。

Skills 在其所属的范围内暴露能力。根级提供 Task 生命周期和跨仓库协调的 Skills；每个仓库保留其特定领域的 Skills。

Inference Stack Repos 是服务行为和性能实际发生变更的地方。SGLang 是栈的中心，Dynamo 将 SGLang 实例组织成分布式服务。DeepGEMM、FlashMLA、FlashInfer 和 Humming 提供专用计算内核。DeepEP 和 Mooncake 提供专家并行通信和跨节点 KV 传输。这些仓库独立演进，但一个服务结果可能同时依赖于其中几个的变更。

代码不会仅仅因为 AI 智能体能编辑它就成为工程成果。Harness Repos 提供了将变更贯穿到其生命周期其余部分的能力：寻找计算资源、准备环境、部署服务、运行性能和正确性评估、诊断失败和在线行为、保存长期记录，以及强制执行安全边界。它们将原本孤立的操作步骤转变为从代码变更到可验证交付物的可重复路径。

三个组共同形成一条工程路径：Built-in Workspace 准备和协调工作，Inference Stack Repos 提供处于变更中的系统，Harness Repos 将该变更带到验证阶段。Infer-forge 将它们纳入同一工作空间，而不强迫它们合并到同一个仓库历史、所有权模型或发布流程中。

MonoRepo 提供工作空间；Task Loop 结构化工作如何随时间推进。推理工程通常需要多轮研究、实现、部署、评估和恢复。Task Loop 保持这些执行与一个 Goal 和 Task Contract 对齐，直到它们通过可验证的交付物或可靠的 Follow-up Handoff 满足其退出标准。

"一切皆可为 Task" 适用于可独立验证的工作单元，而非每个动作。Task 需要自己的 Goal、Scope、Acceptance、验证路径和退出标准。命令和中间实验作为 Loop Block 实例或工具调用保留在其中。一旦一个工作单元可以独立完成或交接，它就可以成为更大 Task Graph 中的一个 Task 节点。

Task Loop 保持其边界稳定，同时允许执行路径适应。Task Definition 建立 Task Type、Starting Context、Task Contract 和 Exit Criteria。主循环通过一系列 Loop Block 实例推进工作，并使用 Task Goal Met? 来决定是退出还是继续。Task Memory 保存当前状态、下一个 Sub-target、执行记录，以及迭代之间的交接。

Harness 环绕在循环周围，而不是作为其中的另一个阶段。它在执行期间提供资源、方法、记忆系统、验证入口点和安全边界。不同的 Task 可以按不同顺序使用这些能力，而不需要被迫遵循一个固定流程。

Task Loop 从一个可测试的承诺开始，而非从活动开始。在 AI 智能体搜索代码库、启动部署或消耗评估容量之前，Task 必须说明它试图完成什么以及结果如何被评判。Task Definition 建立四个锚点：

Task Type 选择默认的 Playbook。

Starting Context 记录执行开始时的状态。

Task Contract 确定 Goal、Scope、Acceptance 和 Verification。

Exit Criteria 定义执行必须产生的持久交付物或 Follow-up Handoff。

Playbook 将既往实践转化为一个良好的起点。对于每种 Task Type，它提供一个轻量、可适应的模板：哪些仓库可能相关，哪些 Skills、Tools & CLI 和验证入口点适用，以及哪些安全边界适用。这减少了 AI 智能体在开始有用工作之前必须搜索的空间。

Playbook 标准化了起始方法，而非完整的执行路径。AI 智能体可以根据 Task Contract 和新证据需要更改方法、引入新的 Loop Block 实例，或使用模板之外的能力。它减少了重复发现，而不是取代工程判断。

每种 Task Type 捕捉推理工程中一个可验证工作的不同单元：

Plan 定义目标、约束和分解，然后为下游 Task 交付可执行计划。

Research 调查一个有限的不确定性，评估现有证据，并交付带有明确局限性的结论。

Code 实现任何有范围的代码变更，并交付变更及其验证证据。

Integration 汇编来自多个上游 Task 的变更，包括跨仓库或跨组件的变更，并验证组合后的系统。

Evaluation 运行功能、性能、准确性、压力和稳定性评估，并交付针对 Acceptance 的证据。

Release 将经过验证的候选版本推进通过审批、金丝雀部署、扩展或回滚，并记录结果。

Online Diagnosis 在只读边界内调查生产问题，并将所需变更交接给下游 Task。

Capability 通过添加、更新、合并、退役或无变更来维护版本化的 Skills & Tools 集合。

Custom 处理没有可复用 Playbook 的可验证工作，同时保留相同的 Task Definition。

该分类法是通过反复实践获得的。一个活动只有在它的起始约定、Acceptance 边界和交付物足够稳定以指导未来工作时，才能成为内置 Task Type。标准化跟随经过验证的实践；它不会试图提前预测每条路径。

Starting Context 划定了已知状态和假设之间的界限。Task 可能从空白状态、准备好的环境或上游结果开始。重要的是该状态的来源和验证状态保持明确。

Custom Setup 记录为当前 Task 准备的条件，例如模型、容器镜像、部署配置文件、仓库版本、数据集或实验入口点。

Imported Context 携带上游环境、中间结果或 Follow-up Handoff 及其沿袭和验证状态。

Task Contract 在执行适应时保持目标稳定。Goal 陈述预期结果，Scope 限定工作范围，Acceptance 陈述成功可观察的条件，Verification 定义评判它们所需的证据。没有这个边界，AI 智能体可以在看到结果后简单地更改问题而看起来成功了。

对于推理优化 Task，合同可能固定模型和权重格式、硬件放置、服务拓扑、运行时版本、工作负载网格和基准线。Acceptance 然后可以要求更好的吞吐量、TTFT 或 TPOT，而不违反准确性或稳定性。在观察到结果后更改拓扑、GPU 类别或工作负载是合同变更——而非优化结果。

证据可以重定向主循环，但不能 silent 移动终点线。不实质改变 Goal、Scope 或 Acceptance 的澄清必须明确且被记录；对其中任何一项的实质性更改都会启动一个新的 Task。

Task 不会因为活动停止而结束。它在状态可以被验证或可以安全地继续时结束。

Deliverable 将完成的结果打包，并附带足够的证据来验证 Task Contract。

Follow-up Handoff 保存已完成的工作、当前状态、未解决的问题，以及当另一个 Task 必须继续工作时的下一个入口点。

Exit Criteria 将执行转化为持久的工程状态：可验证的结果，或下一个 Task 的可靠起点。

Task 的大小由其工程目标决定，而非运行时会话的持续时间。Task Contract 定义完整目标；主循环通过一个或多个 Loop Block 实例实现它，随证据出现。在定义 Task 时，用户不需要预测它是否能在一次持续的运行时循环内完成。

Task 是连续性的单元；Loop Block 是执行的单元。每个 Loop Block 拥有自己的 Sub-target、Exit Condition、路由决策和一组执行记录。Claude Code /loop 和 Codex /goal 是当前的执行入口，但两者都不决定 Task 的范围。

The Main Loop 将开放式 Task 转化为一系列产生证据的 Loop Block：

Define Loop Block 选择当前的 Sub-target 和 Exit Condition。

Execution Routing 为该 Sub-target 选择 Model Tier 和 Agent Topology。

Execute Loop Block 通过可用的持续执行入口点运行该块。

Task Goal Met? 将累积状态与 Task Contract 进行比较，决定是退出还是定义另一个块。

完成一个 Loop Block 不等于完成整个 Task。一个块可能确认一个假设、拒绝一种方法，或暴露新的约束条件。其 Exit Condition 关闭该局部工作单元；Task Goal Met? 则决定累积的证据是否满足整个 Task Contract。Yes 分支进入 Exit Criteria，而 No 分支则根据已产生的证据定义下一个 Loop Block。

Task Memory 使 Loop Block 序列具有持久性和可追溯性。它保存已完成的 Loop Block 和活跃的 Current Loop Block，包括其 Sub-target 和 Exit Condition。只有在当前块结束且 Task Goal Met? 确定 Task 必须继续之后，Next Loop Block 才会被记录。

Execution Records 捕获智能体在每一步做了什么、产生了什么结果。它们使执行可审计、可追溯、可复现。

Loop Block Handoff 在一个 Task 内部转移状态；图级别的 Handoff 边连接独立的 Task 节点实例。

Execution Routing 为当前 Loop Block 做两个正交选择：

Model Tier 遵循推理难度。不确定性、推理深度和所需专业知识决定该块使用 Lower-tier、Mid-tier 还是 Strongest Available。

Agent Topology 遵循内容量和预期上下文长度。能在单一上下文内可靠容纳的工作使用 Single Agent；必须跨上下文划分的工作使用 Multi-Agent14。

一个困难但紧凑的问题可能使用 Strongest Available 配合 Single Agent。一个大型但常规的评估矩阵可能使用 Lower-tier 或 Mid-tier 配合 Multi-Agent。Model Tier 提供推理能力；Agent Topology 管理上下文负载。

图 5 展示了一种可能的 Multi-Agent 拓扑：Coordinator 与 Infra、Code 和 Eval 协作，而 Reviewer 在主执行链之外检查结果7。角色是说明性的；实际分解遵循当前 Loop Block 的内容和上下文要求。

如果模型层选择或子智能体不可用，Loop Block 继续使用运行时提供的 capabilities 执行，并在其 Execution Records 中保留 fallback 记录。

Task Loop 只有在 Harness 能够维持执行的情况下才能保持进展。没有稳定的 Harness，每个 Loop Block 都必须重新发现机器、重建环境、定位命令、恢复证据和重新协商安全边界。Infer-forge 转而提供一个由 Node Registry、Skills & Tools、Journal 和 Safety Guard 构建的统一执行底层。

价值在于组合，而非任何单一能力。在 Task Definition 之后，智能体可以检查资源状态、准备环境、部署工作负载、修改和评估系统，并在必要时在另一个 Node 上恢复。整个过程中，Node 状态、操作方法、执行历史和安全约束保持连接，因此人类无需在步骤之间重建路径。

资源自治必须从可证明的所有权开始，而非猜测。Node Registry 是一个 Git 支持的账本，记录每个 Task 到 Node 的声明。Collectors 定期将运行时进程和 GPU 活动观察写入 Registry，创建连续可审计的历史。GPU 遥测是一种信号；没有单个样本能够确定 Task 已完成。

Cleanup 失败 closed。只有当新鲜、无间隙的观察显示运行时和 GPU 活动在可配置的策略窗口内持续空闲时，声明才变得有资格被清理。缺失、过时、有间隙或冲突的证据会阻止清理；运行时活跃/GPU 空闲的 Node 需要审查。

资格不等于执行，清理不等于复用。清理必须被显式触发，且仅移除 Registry 声明。它不停止工作负载或确定 Task 完成。在 Node 被复用之前，其当前机器状态必须再次验证。

Node Registry 不是调度器，也不启动工作负载。它的角色更窄——但却是基础性的：维护可审计的资源状态，cleanup、allocation 和 deployment 决策都依赖于此。

一个能干的智能体不应该在每个 Task 中重新发现如何执行相同的工程工作。Skills 在 SGLang Upstream、Cross-lib、Task 和 Ops 之间保留可复用的方法。Tools & CLI 为部署、构建、权重和代码同步、Evaluation、性能分析、在线诊断和监控暴露稳定、可记录的接口。

Playbook 为当前 Task Type 选择相关子集。Skills 缩小决策空间；Tools & CLI 将选定的决策转化为行动，其输入和输出可以进入 Execution Records。智能体从累积的实践中开始，而不被强制通过固定路径。

Skills & Tools 是版本化的能力基线，而非不断增长的指令堆。普通 Task 使用当前基线。Capability Task 使用 Journal 证据和运行时变更后的重新验证来决定应该添加、更新、合并、停用或保持不变的内容。

证据只有在下一个 Task 能够找到并复用它时才会累积。Task Memory 保存一个 Task 的执行状态；Journal 跨 Task 携带证据。LLM-wiki 将 Task 记录连接成知识网络，而 Multi-dim Index 按 model、Task Type 和 GPU 等维度组织它们。它们共同支持 Retrieve、Compare 和 Filter，而无需强制每个 Task 重新发现相同的事实。

在 SGLang 早期版本的 OpenAI 兼容聊天基准处理器中，streamed delta.reasoning_content 未被包含在 TTFT 和输出统计中（在 sgl-project/sglang#23954 中修复）；非流式处理在 #25298 中单独处理。Journal 在后续 Task 中呈现了这条历史记录，防止将测量错误误认为其他问题。