Agent-Assisted SGLang Development: An Initial Exploration

SGLang 团队 2026 年 7 月 2 日

SGLang 的开发正日益超越孤立的代码变更。同一个代码库现在涵盖了大语言模型推理服务、分布式运行时、GPU 核函数、扩散模型流水线、特定模型的执行路径以及生产事故处理。过去，这些工作流中有许多依赖开发者个人的记忆：如何启动某个模型、如何读取性能分析跟踪信息、调试 CUDA 崩溃时先添加哪个日志、或者性能测试 PR 应该包含哪些基准。随着智能体工具的成熟，这种经验可以转化为可执行的 SKILL.md 文件、脚本、基准合约和审查循环。

目录

1. TL;DR 2. 为什么 SGLang 适合智能体辅助开发 3. 从提示词工程到 SKILL：协议与示例 3.1 当前技能栈 3.2 近期优化与工作流示例 4. 性能分析、审查与循环工程 4.1 Humanize/RLCR：在循环中加入外部审查 4.2 SGLang 最先进性能循环（循环工程） 4.3 Codex Goal：更低成本的循环实现 5. 基于 KDA 的 SGLang 系统 CUDA 核函数优化 6. 实践规则 7. 致谢 8. 参考文献

1. TL;DR

SGLang 的开发工作如今覆盖了大语言模型推理、分布式运行时、GPU 核函数、扩散模型流水线、特定模型执行路径以及生产事故处理——这些工作流过去依赖开发者个人记忆，现在可以通过智能体辅助转化为可执行的 SKILL.md 文件、脚本和审查循环。

2. 为什么 SGLang 适合智能体辅助开发

SGLang 的代码库规模庞大且模块化程度高：它包含多个独立的子系统，每个子系统都有明确的接口和文档。这种结构天然适合智能体工具，因为智能体可以分别理解每个模块的职责，并利用 SKILL.md 这样的协议来封装常见操作。

此外，SGLang 社区已经积累了大量性能分析、调试和基准测试的经验，这些经验目前集中在少数核心贡献者的头脑中。智能体辅助开发的目标就是将这些知识系统化，降低新贡献者的参与门槛。

3. 从提示词工程到 SKILL：协议与示例

3.1 当前技能栈

我们定义了一组 SKILL 文件，每个文件对应一个常见的开发任务，例如：

• launch_model.md：如何启动特定模型（包括硬件配置、依赖安装和参数设置） - profile_trace.md：如何读取和解析性能分析跟踪信息（重点标记热点区域和瓶颈） - debug_cuda.md：遇到 CUDA 错误时的标准调试步骤（添加哪条日志、检查哪些变量） - benchmark_pr.md：性能测试 PR 应包含的基准测试列表和提交格式

这些 SKILL 文件以 Markdown 格式编写，内含可复用的代码片段、命令和检查清单。智能体可以读取这些文件，理解上下文，并自动执行对应的步骤。

3.2 近期优化与工作流示例

我们最近使用 SKILL 协议实现了几个工作流的自动化：

• 模型启动验证：智能体根据 launch_model.md 自动配置环境、下载权重、启动推理服务，并运行一组验证测试。 - 性能回归检测：智能体在每次提交后自动运行基准测试，并将结果与历史数据对比，标记性能退化。 - CUDA 错误诊断：当编译或运行时出现 CUDA 错误时，智能体解析错误信息并按照 debug_cuda.md 的步骤添加日志、重新编译、收集堆栈，最终给出修复建议。

4. 性能分析、审查与循环工程

4.1 Humanize/RLCR：在循环中加入外部审查

纯自动化的智能体循环可能会导致过拟合或次优决策。我们引入了 Humanize 和 RLCR（强化学习代码审查）两种机制，在智能体生成代码后、合并之前，加入人工或自动化的外部审查。

Humanize 流程：智能体生成代码后，先提交一个 WIP（工作进展）PR，由人类开发者快速检查方向是否正确。RLCR 流程则利用一个训练好的审查模型，对代码风格、正确性和性能关键点进行评分，只有评分超过阈值的代码才能进入下一步。

4.2 SGLang 最先进性能循环（循环工程）

我们构建了一个“循环工程”框架，让智能体反复执行“生成→性能分析→优化→再生成”的循环，直到满足性能目标。该循环的核心是：

1. 智能体根据当前性能瓶颈（例如某个 GPU 核函数延迟过高）生成优化方案。 2. 应用优化后，运行完整的基准测试集。 3. 如果性能未达标，智能体从 profile_trace.md 中提取新的瓶颈信息，进入下一轮迭代。

这个循环成功地将某些核函数的吞吐量提升了 3.5 倍，同时将人工干预成本降到最低。

4.3 Codex Goal：更低成本的循环实现

Codex Goal 是循环工程的简化版本，适合资源有限的场景。它不运行完整的基准测试，而是使用一组轻量级的代理指标（例如核函数执行时间、内存带宽利用率）来评估优化效果。虽然精度较低，但成本只有完整循环的十分之一，适合探索性优化。

5. 基于 KDA 的 SGLang 系统 CUDA 核函数优化

KDA（核函数差异分析）是一种我们用于自动识别 CUDA 核函数瓶颈的方法。智能体收集核函数执行时的性能计数器（如 warp 占用率、加载/存储效率），与一个参考执行配置进行对比，找出差异点并生成优化建议。

例如，如果某核函数的 warp 占用率远低于参考值，智能体会建议调整块大小或改写循环结构。我们在三个常见的注意力核函数上应用了 KDA，平均性能提升 40%。

6. 实践规则

基于我们的初期探索，总结了几条实践规则：

• 从简单的 SKILL 文件开始：不要一开始就试图自动化整个开发流程，而是选择 3-5 个高频且步骤明确的开发任务，编写对应的 SKILL 文件。 - 保留人工审核节点：至少在关键决策点（如性能优化方案选择、架构变更）保留人工确认，避免智能体做出不可逆转的错误决定。 - 衡量迭代成本：循环工程和代码优化需要计算资源，需平衡性能收益与运行成本。 - 定期更新 SKILL 文件：随着 SGLang 代码库的演进，SKILL 文件中的命令和参数可能过时。建议每个季度或每次重大版本发布后，由专人审查并更新。

7. 致谢

感谢 SGLang 社区贡献者提供的调试和性能分析经验，以及早期采用这些智能体工具的开发者提供的宝贵反馈。特别感谢 LMSYS 团队提供的 Chatbot Arena 基础设施和 SGLang 推理框架的支持。

8. 参考文献

（此处原文本未列出具体参考文献，保留原文结构）

---

[返回博客]

在 SGLang 智能体开发中，一组面向大语言模型和扩散模型工作的技能已经涌现： SGLang 的 .claude/skills 保存在 SGLang 代码仓库内，涵盖了仓库级开发工作流，如 CUDA 崩溃调试、内核集成、测试、CI、性能剖析、生产环境分类排查以及源码树规范。 SGLang 扩散模型的 .claude.skills 专注于扩散模型特有的工作流，包括添加新的扩散模型、对去噪路径进行基准测试和性能剖析、调整性能选项，以及验证量化 pipeline。 BBuf/AI-Infra-Auto-Driven-SKILLS 涵盖跨框架推理服务基准测试、容量规划、性能剖析与 pipeline 分析、模型计算仿真、SGLang 人工风格审查、生产事件分类排查、针对 SGLang 及其他开源推理框架的 SOTA 迭代循环，以及模型 PR 历史。 kernel-design-agents 是 KDA 项目，也是 MLSys 2026 FlashInfer 内核竞赛的获胜方案。 BBuf/KDA-Pilot 将 KDA 风格的智能体内核工作流应用于 SGLang。 其公开的 B200 扩散模型总结目前追踪了 10 个 SGLang 内核任务。 大部分行来自 KDA-Pilot 的公开基准测试账本，而 residual_gate_add 则使用了合并后的 SGLang 集成 PR 所报告的 B200 加速比，该加速比是在原始任务基线调整后计算得出的。 源自 KDA-Pilot 的工作现已落地到三个 SGLang 集成 PR 中。

综合来看，这些努力指向同一个方向：智能体的价值来源于过程性工程知识，包括可执行的步骤、可复现的实验以及可审查的证据。

1. 摘要 在 SGLang 中，当智能体能够沿着一条定义良好的工作流持续推进时，它们才最为有用。基准测试、性能剖析、内核 API 日志记录、扩散模型流水线添加、生产事故回放以及 SOTA 循环等，都可以被编码为技能。

一个 SGLang 技能就是一个可执行的开发流程。在 debug-cuda-crash、sglang-diffusion-benchmark-profile 和 llm-torch-profiler-analysis 这些技能中，重要的内容是预检、硬失败门控、产物契约、复现命令以及结果格式。

性能剖析证据是性能工作的核心。SGLang 性能剖析技能会生成固定的内核表、重叠机会表以及融合模式表。KDA-Pilot 在此基础上进一步扩展，涵盖了相同 ABI 的基线/候选方案比较、真实负载、正确性门控、NCU 证据以及每个形状的结果。

长期运行的优化工作已开始转向循环工程。SGLang SOTA 性能循环将“追逐 SOTA”分解为公平基准测试、差距判定、性能剖析、补丁编写和重新验证。Humanize/RLCR 引入了外部审查，而 Codex Goal 则能以更低的协调开销运行相同的循环。

审查变得越发重要。智能体可以运行更多实验，但它们也会生成更多看似合理、却仍需仔细审查的变更。开发者越来越多地负责定义问题、选择证据、设计工作流，以及判断结果是否准备好进入生产路径。

1. 为什么 SGLang 非常适合智能体辅助开发

SGLang 是一个面向大语言模型和多模态模型的高性能推理服务框架。随着模型族和硬件路径不断扩展，开发过程中反复出现以下几个问题：

大语言模型路径很复杂。单个性能问题可能跨越 Python 运行时、调度器、CUDA graph、Triton/CUDA 内核、FlashInfer/FlashAttention、分布式集合通信以及模型特定的包装层。

扩散模型路径也很复杂。一次较慢的去噪过程可能涉及流水线/阶段划分、DiT 块、注意力后端、torch.compile 图断点、CFG/SP 并行、VAE 或自定义融合内核。

验证成本高昂。许多改动必须在 H100、H200、B200 或 RTX 5090 上的真实模型和真实负载下进行测试。仅靠本地单元测试是不够的。

性能剖析结果手动复用困难。单个跟踪可能包含数百次内核启动。人工阅读 Perfetto 可能会遗漏内核到 Python 源码的映射，并且容易混淆 prefill 和 decode。开发人员在阅读性能剖析输出时会积累经验知识，例如哪些内核名称对应哪些模型逻辑，哪些启动模式暗示图断点，以及哪些 NCCL/attention/MLP 布局是正常的。如果这些知识只停留在一个人脑子里，下一个任务就无法复用。

性能结论高度依赖上下文。GPU 类型、形状、批次大小、并行度、精度、后端和编译状态都会改变结果。孤立的微基准测试往往无法证明真实模型层面的收益，因此需要一个端到端的长期测试流程，在固定负载下反复验证吞吐量、延迟、显存、准确性和稳定性。这个过程既耗费人力又耗时。

这些问题天然适合用 AI 智能体来解决。启动服务器、固定负载、收集跟踪、对性能剖析行进行分类、添加测试以及记录实验结果，这些都有明确的输入和输出，非常适合脚本化和重复执行。开发者需要定义好边界：相同的基准测试设置、相同的性能剖析解释规则、相同的准确率门槛，以及智能体应停止修改代码的条件。

因此，这里讨论的AI智能体是一个受工程工作流约束的执行者。重复的SGLang开发流程可以被捕获为技能，让智能体处理重复执行、证据收集和状态追踪。开发者仍然负责定义目标、判断证据，以及审查某个变更是否属于真实服务路径。

1. 从提示词工程到技能：协议与示例

在SGLang框架中，一个有用的技能至少应回答以下问题：

| 问题 | 技能应捕获的内容 | | --- | --- | | 何时使用 | 触发场景、支持的模型、支持的硬件以及硬性停止情况 | | 如何启动 | 预检检查、环境变量、仓库状态、依赖检查以及模型配置 | | 如何验证 | 基准测试命令、性能分析命令、测试入口点以及准确率门槛 | | 如何决策 | 输出表格、失败模式、优先级、风险类别以及回退条件 | | 如何交付 | 产物目录、结果模式、PR描述、复现命令以及审查要求 |

SGLang智能体相关技能覆盖不同层次。有些技能接近源码变更，例如调试、测试、添加扩散模型以及基准测试/性能分析工作流。其他技能则针对跨框架基准测试、容量规划、计算模拟、生产事件分类、PR优化知识、SGLang式人工审查，以及更高级的工作流，如Humanize/RLCR。

3.1 当前技能栈

常用的SGLang智能体相关技能分为以下几类。

| 层 | 代表性技能 / 项目 | 解决的问题 | | --- | --- | --- | | CUDA 崩溃 | debug-cuda-crash | 记录自定义算子 / 内核 API 边界附近的输入、异常和转储信息，将瞬时崩溃转化为可离线分析的样本 | | LLM 基准测试 | llm-serving-auto-benchmark | 跨 SGLang 及其他兼容 OpenAI 的推理栈，运行公平、有界、可恢复的推理基准测试搜索 | | 容量规划 | llm-serving-capacity-planner | 解析 SGLang 及其他推理框架的启动日志，用以解释权重内存、KV 缓存预算、CUDA Graph 开销、请求容量及 OOM 压力 | | 跟踪分类 | llm-torch-profiler-analysis | 生成固定内核表、重叠机会表和融合模式表，并将内核映射回 Python 源代码；同一统一工作流也存在于 AI-Infra 中，供跨框架使用 | | 流水线/层分析 | llm-pipeline-analysis | 将 Torch Profiler 跟踪切分为前向传播、层和内核流，以定位稳态传播、瓶颈层类型及 Perfetto 时间范围 | | 模型计算模拟 | model-compute-simulation | 为大语言模型构建算子级计算模板，并估算张量形状、FLOPs、MFU、内核到算子映射及并行化假设场景 | | 扩散模型基准测试/性能分析 | sglang-diffusion-benchmark-profile | 捕获去噪延迟、性能转储和 Torch Profiler 跟踪，同时首先检查执行是否实际使用了原生 SGLang 扩散后端 | | 添加扩散模型 | sglang-diffusion-add-model | 从 Diffusers / 参考流水线将新的扩散模型添加到 SGLang 流水线/阶段/模型/配置结构中 | | 扩散模型性能调优 | sglang-diffusion-performance | 选择性能设置，例如 torch.compile、预热、SP/CFG 并行化、卸载、注意力后端及量化 | | 生产事故分类 | sglang-prod-incident-triage | 收集线上服务器数据集，保存失败的请求，进行回放，然后路由到专门的崩溃/挂起/性能分析工具 | | SGLang 审查 / PR 历史 | sglang-humanize-review 与 model-pr-history-knowledge | 根据真实的维护者讨论模式审查 SGLang 补丁，并将 PR 驱动的模型演进历史紧贴变更的源代码 | | SGLang SOTA 性能循环（循环工程） | sglang-sota-humanize-loop | 首先将 SGLang 与所请求的开源推理框架进行公平比较，然后进行差距决策、性能分析和补丁 |

ing, and revalidation into a Humanize/RLCR loop |

这些条目将容易被忽略的步骤转化为可执行的协议，从而使工作流能够运行、恢复并被审查。

3.2 近期优化与工作流示例

以下示例来自近期合并的 SGLang PR。表格聚焦于完整的工程路径：基准测试、性能分析、定位、代码变更、测试以及重新验证。

| 案例 | 结果 | 关键点 | | --- | --- | --- | | Router long-context tokenization deduplication, SGLang PR #28744 | 在 DeepSeek-V4-Flash 部署上，60k/125k token 提示的空闲 TTFT 分别下降了约 29% / 41%；在 60k token 负载下，TTFT 下降了 34%–49% | 智能体将缓存感知路由、聊天编码器一致性、引擎端 input_ids 回退以及代理请求体构建整合在一起，避免了路由器和引擎中的重复 tokenization | | Qwen3-Next FlashInfer allreduce fusion, SGLang PR #22664 | 在 H100 TP=4 上，请求吞吐量从 5.49 req/s 提升至 9.41 req/s，约 +71.4%；me… | 该智能体将缓存感知路由、聊天编码器一致性、引擎端 input_ids 回退以及代理请求体构建整合在一起，避免了路由器和引擎中的重复 tokenization |