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

围绕 SGLang 智能体的开发，针对 LLM 和扩散模型工作已经涌现出一套技能：

• SGLang .claude/skills 维护在 SGLang 代码仓库内部，涵盖了仓库级别的开发工作流，例如 CUDA 崩溃调试、内核集成、测试、CI、性能分析、生产事故分类以及源码树约定。
• SGLang diffusion .claude/skills 专注于扩散模型特定的工作流，包括添加新的扩散模型、对去噪路径进行基准测试和性能分析、调优性能选项以及验证量化后的流水线。
• BBuf/AI-Infra-Auto-Driven-SKILLS 涵盖了跨框架的服务基准测试、容量规划、性能分析与流水线分析、模型计算模拟、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 则能以更低的协调开销运行相同的循环。
• 审查变得愈发重要。智能体可以运行更多实验，但它们也会生成更多看似合理、仍需仔细审查的变更。开发者越来越多地负责定义问题、选择证据、设计工作流，并判断结果是否已准备好进入生产路径。

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

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

• 大语言模型路径很复杂。单个性能问题可能跨越 Python 运行时、调度器、CUDA 图、Triton/CUDA 内核、FlashInfer/FlashAttention、分布式集合通信以及模型特定的封装器。
• 扩散模型路径也很复杂。一次较慢的去噪过程可能涉及流水线/阶段划分、DiT 块、注意力后端、torch.compile 图断点、CFG/SP 并行、VAE 或自定义融合内核。
• 验证成本高昂。许多变更必须在 H100、H200、B200 或 RTX 5090 等真实模型和真实工作负载上进行测试。仅靠本地单元测试是不够的。
• 性能分析文件难以手动复用。单个跟踪记录可能包含数百次内核启动。手动阅读 Perfetto 可能会遗漏内核到 Python 源码的映射关系，并且很容易混淆预填充和解码阶段。开发人员在阅读性能分析器输出时会积累经验知识，例如哪些内核名称对应哪些模型逻辑、哪些启动模式暗示了图断裂、以及哪些 NCCL/注意力/MLP 布局是正常的。如果这些知识只停留在一个人的脑子里，下一个任务就无法复用。
• 性能结论高度依赖于上下文。GPU 类型、形状、批处理大小、并行度、精度、后端和编译状态都可能改变结果。孤立的微基准测试通常无法证明真实的模型级收益，因此需要一个端到端的长时间运行测试流程，在固定工作负载下反复验证吞吐量、延迟、内存、准确性和稳定性。这个过程既耗费人力又耗费时间。

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

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

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

在 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 图开销、请求容量和 OOM 压力
追踪分类	llm-torch-profiler-analysis	生成固定的内核、重叠机会和融合模式表格，并将内核映射回 Python 源码；同一统一工作流也存在于 AI-Infra 中，供跨框架使用
流水线/层分析	llm-pipeline-analysis	将 torch profiler 追踪切片为前向传播、层和内核流，以定位稳态传播、瓶颈层类型以及 Perfetto 时间范围
模型计算模拟	model-compute-simulation	为 LLM 构建算子级别的计算模板，并估算张量形状、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 与请求的开源推理框架进行公平比较，然后将差距决策、性能分析、打补丁和重新验证放入 Humanize/RLCR 循环中。

这些条目将容易遗漏的步骤转化为可执行的协议，以便工作流能够运行、恢复和接受审查。

3.2 近期优化与工作流示例

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

案例	结果	关键点
路由器长上下文 token 化去重，SGLang PR #28744	在 DeepSeek-V4-Flash 部署上，60k/125k token 提示的空闲 TTFT 下降了约 29% / 41%；在 60k token 负载下，TTFT 下降了 34%–49%。	该智能体同时处理了缓存感知路由、聊天编码器一致性、引擎端 input_ids 回退和代理主体构建，避免了路由器和引擎中的重复 token 化。
Qwen3-Next FlashInfer allreduce 融合，SGLang PR #22664	在 H100 TP=4 上，请求吞吐量从 5.49 req/s 提升至 9.41 req/s，约提升 +71.4%；平均 TTFT 从 456.24 毫秒降至 167.54 毫秒。	这是一种基于性能画像的大语言模型集体优化：未融合的跨设备规约主导了预填充阶段，而融合的全规约路径已通过 MMLU/GSM8K 精度验证。
Cohere2Moe NVFP4 融合 MoE 路径，SGLang PR #27401	对于在 1x B300 上运行的 CohereLabs/command-a-plus-05-2026-w4a4，请求吞吐量相比之前的 SGLang 默认配置在聊天场景提升了 +26%，在摘要场景提升了 +21%，并在该配置下击败了另一个开源推理框架，领先幅度分别为 +4.1% 和 +6.8%。	该变更完善了路由语义，使得现有的 flashinfer_trtllm NVFP4 融合 MoE 内核能够在真实模型路径中正确使用，并经过了 GSM8K/MMLU 验证。
针对 SM100 的 Kimi Delta Attention CuteDSL 预填充内核，SGLang PR #27488	对于 moonshotai/Kimi-Linear-48B-A3B-Instruct，在 B200 上使用 Delta Attention 进行预填充比 Triton 快 1.08 倍至 1.52 倍；GSM8K 得分从 0.915 提升至 0.920，并新增了针对实际门控幅度的回归测试。	此内核任务在优化准备合并之前，必须覆盖模型的门控分布、数值溢出、主机开销、真实模型精度以及单元测试。
频谱渐进式扩散，SGLang PR #27524	在报告的 RTX A6000 配置下，FLUX.1、FLUX.2、Z-Image、Wan 和 Qwen-Image 的去噪速度分别达到了 1.63 倍、1.77 倍、2.07 倍、2.32 倍和 1.6 倍。	这是一项扩散侧的系统优化：早期去噪在较低的潜在空间分辨率下运行，然后通过 GPU DCT 上采样恢复全分辨率，此时高频细节开始变得重要。
LTX-2 VAE 解码 channels-last-3d，SGLang PR #27431	LTX-2 解码阶段从 5.41 秒提升至 3.84 秒，约提升 1.41 倍；峰值保留内存从 71.81 GiB 降至 62.12 GiB，节省约 9.7 GiB。	性能分析指向了 Conv3d 和布局转换，因此修复方案在因果填充中保留了内存格式，并将加载器策略关联到单 GPU 的 LTX-2。

在这些示例中，智能体主要通过执行工作流来做出贡献：运行基准测试、读取性能分析数据、定位 Python 源代码、修改代码、添加测试、重新验证以及准备 PR 描述。如果没有技能，许多步骤依赖于手动提醒。一旦编码为技能，工作流就变得更容易重复。

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

在 SGLang 性能优化工作中，一个常见错误是只关注总运行时间，或者打开 Perfetto 看几分钟，就凭直觉断定某个操作“应该被融合”。对于智能体场景来说，这种做法风险更大，因为很容易把一个视觉上很热的内核误认为是真正的瓶颈。

在实践中，通常会将两种性能分析技能结合使用。`llm-torch-profiler-analysis` 负责处理第一层的 trace 分类，将全局性能分析结果转化为三个固定的表格：

• 内核表：按阶段汇总 GPU 时间占比、启动次数和内核类别，并尽可能将内核映射回 Python 源代码和 CPU 操作。
• 重叠机会表：利用独占/隐藏时间占比、依赖风险和内核类别，来识别剩余的重叠或优化空间。
• 融合模式表：将 trace 与一个基于源码的模式目录进行对比，该目录包含了 SGLang、其他开源推理框架以及内核库中的融合/重叠路径。

这些表格回答了第一组问题：哪个阶段和哪个内核占用了多少 GPU 时间，它们对应哪一行 Python 代码，以及是否存在可借鉴的现有融合/重叠路径。如果 SGLang 落后于其他推理框架，那么在开始任何代码改动之前，性能分析表就应该能解释其中的差距。

下一步是 `llm-pipeline-analysis`。在了解了全局热点之后，我们还需要知道它们属于哪个前向传播、哪种层类型以及哪个内核流程。该技能会读取 Chrome trace JSON 和模型 config.json，利用层边界锚点内核将 trace 分割成前向传播和各个层，然后生成多个表格用于更深入的分析：

• 前向传播摘要：将冷启动阶段与稳态阶段分开，避免将预热过程误设为优化目标。
• 逐层时间线：报告每层的挂钟时间、总耗时，以及 MLA、MoE、GEMM、NCCL、MHC 和 Hadamard 等类别的占比。
• 层聚类统计：对于具有交替层结构的模型尤其有用，例如带有 compress_ratios 的 NSA/混合注意力模型，其中 C4_LIGHT、C128_HEAVY、HASH 或其他层类型可能主导延迟。
• 计算流表：将代表性层展开为具体的核函数流，包含热度、相对时间戳和输入维度，便于跳回 Perfetto 进行分析。

因此，性能分析成为一个两步过程。首先，llm-torch-profiler-analysis 识别完整追踪中的主要冲突。然后，llm-pipeline-analysis 将问题定位到稳态前向传播、代表性层和具体的核函数流中。第一步避免了凭直觉选择方向。第二步避免了只盯着一个全局热点核函数而忽略模型结构中不同层类型的差异。

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

Humanize 处理长时间运行任务中的状态与审查问题。一项高风险的 SGLang 性能任务通常无法在一次实现中完成。它可能需要经过多轮基准测试、性能分析、补丁修复、回滚、方向调整和重新验证。Humanize 将此过程分为两个阶段：

1. 首先运行 gen-plan。humanize-gen-plan 将草稿需求转化为结构化的 plan.md 文件，包含目标描述、验收标准、正/负测试用例、路径边界、里程碑和实现说明。
2. 接下来运行 RLCR 循环。humanize-rlcr 从 plan.md 开始启动循环。在每一轮中，Claude Code 读取 .humanize/rlcr/<timestamp>/round-<N>-prompt.md，进行实现、提交并编写摘要。然后 Codex Review 检查状态文件、摘要、git 整洁度、审查结果、未解决问题、最大迭代条件以及其他关卡。仅凭一句声称"任务完成"的陈述不足以退出循环。

该机制为 SGLang SOTA 性能循环提供了执行和审查基础。Claude Code 运行基准测试、读取性能分析结果、修改 SGLang 代码并重新验证。Codex Review 在每轮结束时检查证据、状态和风险。它非常适合那些将成为 PR、影响服务正确性或需要多天、多轮实验的任务。

在实践中，命令顺序应明确指定，以免智能体直接跳入实现阶段：

1. Write a task draft under artifact_root/draft.md.
2. Run humanize-gen-plan to generate artifact_root/plan.md.
3. Start humanize-rlcr from artifact_root/plan.md.
4. Keep all decisions, summaries, and review state in the local Humanize workspace.

4.2 SGLang SOTA 性能循环（循环工程）

单个技能可以稳定一项任务。然而，经过十几轮实验后，另一个问题出现了：哪个候选方案最佳，哪些方向已经失败，之前的 NCU 报告显示了什么，基准测试是否仍与基线匹配，以及何时停止。这种状态不能仅存在于聊天上下文中。

SGLang SOTA 性能循环是一种基于 Humanize/RLCR 构建的循环工程工作流。此处，SOTA 指在固定实验条件下可重现的最佳结果：相同的模型、硬件、GPU 数量、精度、工作负载、SLA、框架提交版本和服务参数。问题在于 SGLang 是否能在这些条件下达到当前可重现的最佳结果。

图 1：SGLang SOTA 性能循环。首先，一个固定的公平基准测试建立可重现的基线。后续的差距判定、性能分析、流水线分析、补丁修复和重新验证均由 Humanize/RLCR 循环驱动。

一个完整的 SGLang SOTA 性能循环包含以下阶段：

1. 定义目标边界。例如，Qwen/Qwen3-Next-80B-A3B-Instruct-FP8，单节点 2x B200，FP8，SGLang TP=2，并与在相同 2-GPU 预算下所要求的开源推理框架进行对比。
2. 首先运行公平搜索。在对 SGLang 打补丁之前，在相同的工作负载和资源预算下，为 SGLang 以及每个所要求的开源推理框架搜索最佳的可重现命令。
3. 判定差距。如果 SGLang 已经持平或领先，则记录完成证据。如果其持续落后超过阈值，则进入性能分析阶段。
4. 使用性能分析结果来解释差距。不要急于修改代码。首先在需要时生成内核表、流水线表、重叠/融合表以及 NCU 报告。
5. 仅对证据支持的路径打补丁，例如混合注意力、Mamba/GDN、基数缓存、目标验证、CUDA 图、MoE/EP、量化内核或模型封装器。
6. 在相同的工作负载上重新验证。每一轮都记录基准测试结果、性能分析数据、准确率、失败的尝试、环境信息和清理操作。

对于像 Qwen/Qwen3-Next-80B-A3B-Instruct-FP8 在 2x B200 上运行这样的目标，循环之所以重要，是因为基准测试结果、性能分析追踪、失败的补丁以及中间结论都需要始终与同一个模型、硬件、工作负载和框架版本绑定。如果这类任务被拆分成许多独立的提示词，很容易丢失哪个命令产生了哪个结果，或者后续的性能分析是否仍与原始基线匹配。一个带有证据和审查的循环能够确保各轮次之间的条件保持一致。

4.3 Codex Goal：一种成本更低的循环实现方案

上述 SGLang SOTA 性能循环采用双角色设置：Claude Code 负责执行基准测试、性能分析、打补丁和重新验证，而 Codex Review 则在每轮结束时进行检查。这种设置适用于严肃的 PR 工作，但每一轮都会消耗一个执行模型和一个审查模型，从而增加了成本和等待时间。

Codex Goal 提供了另一种实现方案。一旦将“公平基准测试 -> 差距决策 -> 性能分析 -> 打补丁 -> 重新验证 -> 产物台账”写入一个持久的 Goal 中，单个 Codex Goal 就可以承担执行、自我检查和重新验证的工作，无需采用双角色的执行/审查设置。SGLang SOTA 性能循环的核心约束保持不变：固定的工作负载、基于证据的补丁、相同实验条件下的重新验证，以及每轮之后更新产物清单。

这两种方法的区别如下：

维度	Humanize/RLCR SOTA 循环	Codex Goal
执行	Claude Code 负责实现和实验；Codex Review 审查每一轮	一个 Codex Goal 持续执行、自我检查并重新验证
状态位置	计划、提示词、摘要和审查结果位于 .humanize/rlcr/... 下	当前 Goal 线程以及产物根目录下的清单/证据
审查方法	停止钩子、Codex Review 以及 git/状态/模式检查	Goal 级别的自我检查、产物合约以及人工抽查
成本	两个模型角色参与，因此每轮成本更高	一个 Goal 同时承担执行和检查，降低了成本
主要风险	循环设置更复杂，每轮等待时间更长	除非硬停止条件明确，否则可能出现 Goal 偏离或过早完成

以下是来自 AI-Infra-Auto-Driven-SKILLS/prompts 的一个 2x B200 模型优化提示词示例。

拟人化/RLCR 版本：

Use the sglang-sota-humanize-loop workflow.

Task:
Optimize SGLang serving performance for Qwen/Qwen3-Next-80B-A3B-Instruct-FP8
on a single node with 2 NVIDIA B200 GPUs, FP8 precision, and initial SGLang
TP=2. SGLang should match or exceed the best reproducible result from the
requested open-source inference frameworks under the same 2-GPU budget, workload, SLA,
model, precision, and environment constraints.

Required workflow:
1. Create a draft task document under artifact_root.
2. Run humanize-gen-plan to turn the draft into a structured plan.md.
3. Start humanize-rlcr from that plan.md in the Claude Code session.
4. Keep benchmark, profile, patch, and revalidation decisions inside the same
   Humanize workspace.

Evidence and safety requirements:
- Before patching, run a fair bounded search for SGLang and the requested open-source inference framework set.
- Check relevant open PRs in sgl-project/sglang and BBuf/sglang before choosing
  the SGLang baseline.
- If SGLang is behind by more than 1%, profile before patching.
- Prioritize evidence around hybrid attention, Mamba/GDN, radix cache, target
  verify, and CUDA graph.
- Record benchmark commands, profile artifacts, failed attempts, and cleanup
  evidence for every round.
- Patch only evidence-supported SGLang code paths.
- If a PR is needed, push/open it only against BBuf/sglang and include benchmark,
  GSM8K, and full MMLU accuracy tables.

artifact_root:
/workspace/sglang-agent-artifacts/b200_qwen3_next_80b_a3b_instruct_fp8_sota_humanize

Codex Goal 版本：

/goal Keep optimizing SGLang serving for
`Qwen/Qwen3-Next-80B-A3B-Instruct-FP8` on a single node with 2 NVIDIA B200
GPUs until SGLang matches or exceeds the best reproducible result from the
requested open-source inference frameworks under the same 2-GPU budget, FP8 precision,
workload, SLA, model, and environment constraints. The current Codex Goal is the loop: fixed fair
benchmarking, gap decision, profiling, pipeline analysis, evidence-backed
patching, revalidation, final report, and optional PR preparation all happen
inside this Goal. Completion requires benchmark evidence, profile evidence when
SGLang was behind, correctness/accuracy evidence, a final artifact manifest,
and no regression in environment safety constraints.

model_id: Qwen/Qwen3-Next-80B-A3B-Instruct-FP8
root_dir: /workspace
target_hardware: single-node 2x NVIDIA B200
minimum_gpu_count: 2
precision_quantization: FP8
initial_deployment: SGLang TP=2
artifact_root:
/workspace/sglang-agent-artifacts/b200_qwen3_next_80b_a3b_instruct_fp8_sota_goal

Requirements:
- Use the current Codex Goal as the only persistent loop.
- Before patching, run a fair bounded search for SGLang and the requested
  open-source inference frameworks under the same 2-GPU budget.
- If SGLang is behind by more than 1%, profile in the same Goal, then use
  llm-torch-profiler-analysis, llm-pipeline-analysis, and ncu-report-skill when
  needed before patching.
- Focus on hybrid attention, Mamba/GDN, radix cache, target verify, and CUDA graph.
- Update the artifact manifest, benchmark evidence, profile evidence, failed
  attempts, and next-step decision after every round.
- Stop and report a blocker if resources are unavailable, evidence is
  untrustworthy, the budget is exhausted, or no defensible next patch exists.

Goal 版本保留了相同的基准测试、配置文件、精度和工件要求。区别在于，执行和审查被合并为一个持续的目标。在明确的硬停止条件下，它可以用更少的编排工作来承载相同的 SGLang SOTA 性能循环。

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

除了大语言模型和扩散模型的模型级优化之外，内核优化面临着更严峻的扩展问题。不存在独立于硬件和工作负载的最佳内核。同一个算子可能在 H100、H200、B200 或 B300 上偏好不同的实现；不同的模型架构会暴露不同的张量形状和布局约束；而服务工作负载会改变批次大小、序列长度、精度格式、封装开销、同步行为和回退路径。在实践中，搜索空间是硬件、模型和工作负载定义的笛卡尔积。

这带来了组合优化的负担。对于每个候选内核，开发者需要提取具有代表性的生产行，构建相同 ABI 的测试框架，运行 A/B 测量，检查各形状桶的正确性，读取 NCU 指标，决定某个桶是否值得专门优化，然后在真实的 SGLang 路径中重新验证。对每个硬件/模型/工作负载组合都手动执行此操作成本高昂。而这正是智能体所擅长的重复性、证据密集型工作流——只要人类定义好不变性并审查最终路径。

然而，直接让智能体编写 CUDA 很容易导致基准测试奖励黑客行为：更改基准测试、使用更轻量的封装、启用基线未使用的快速数学运算、仅优化单一形状、破坏数值语义，或在真实 SGLang 路径中毫无收益。

KDA-Pilot 将内核优化分解为独立的任务，这样智能体就不会随意修改整个 SGLang 代码库：

• 工作负载来自真实的 SGLang 扩散模型。该过程首先运行 20 个扩散模型，并汇总实际的内核元数据。
• 基线从上游 SGLang 主分支复制而来，并记录了来源追溯信息。
• 基线和候选方案必须使用相同的本地 ABI 以及相同的构建/导出路径。
• 基准测试使用固定的生产数据行、A/B 交错测试，以及 CUDA 事件计时或挂钟计时。
• 正确性检查涵盖生产数据行、标准回归测试网格、NaN/Inf 检查、毒化输出检查以及回退契约。
• 每次迭代都会刷新任务提示词、基准测试证据、KernelWiki 和 ncu-report-skill。
• 允许形状特化的分发，但每个桶必须记录其条件、路径、延迟和回退方案。

具体的快照能让规模更直观。公开的 KDA-Pilot B200 扩散摘要目前列出了 10 个被追踪的 SGLang 内核任务。大多数数据行在 KDA-Pilot 账本中都有稳定的 B200 数值证据，在提取的生产数据行上，挂钟几何平均加速比范围从 1.1341x 到 2.7499x。residual_gate_add 行显示为 1.11x，与已合并的上游 LTX-2.3 B200 结果一致。

截至 2026 年 6 月 27 日，已有三个源自 KDA-Pilot 的优化合并到了上游 SGLang 中。第一个是 SGLang PR #27392，为 Qwen-Image-2512 提供了一个 B200 原生扩散归一化-缩放-移位 CUDA 快速路径。另外两个在同一周晚些时候合并：用于 Cosmos3 VAE 因果 Conv3D cat/pad 复制路径的 SGLang PR #29281，以及用于 LTX-2.3 residual-gate 更新路径的 SGLang PR #29361。

上游 PR	目标路径	内核级证据	模型路径级证据
#27392	Qwen-Image 归一化-缩放-移位	目标内核组在分析器归因中提升了 1.279x	在一张 B200 上，每侧五次交错运行显示完整请求加速比为 1.125x，去噪挂钟加速比为 1.130x
#29281	Cosmos3 因果 Conv3D cat/pad	在追踪的 VAE 解码调用中，B200 加权内核组从 10.621 毫秒提升至 5.240 毫秒，即 2.03x	在 Cosmos3-Nano T2V 上启用 torch.compile 后，中位端到端时间从 181.521 毫秒提升至 177.687 毫秒，即 1.021x
#29361	LTX-2.3 residual-gate 更新	大型 B200 LTX-2.3 数据行相较于现有 Triton 路径提升了 1.108x 到 1.130x，相邻扩散数据行最高提升至 2.587x	在 LTX-2.3 HQ T2V 上，端到端时间从 46644.08 毫秒提升至 45198.37 毫秒，即 1.032x

关键结论并非每个独立的 kernel 任务胜利都能转化为端到端的重大胜利。关键在于，同样的 KDA-Pilot 证据包——固定的生产数据行、正确性门控、相同 ABI 比较、性能分析器归因以及真实模型检查——能够将一项 kernel 任务从孤立的基准测试，推进到可审查的 SGLang 服务路径中。

图 2：针对 KDA-Pilot 优化的 10 个受追踪的 SGLang 扩散模型 kernel 任务的 B200 证据。大多数行报告的是 KDA-Pilot 在提取的生产数据行上的几何平均加速比；墙钟时间包括 Python 调度、封装器开销、kernel 启动以及通过 cuda.synchronize() 可见的同步开销，这比纯 kernel 设备时间更接近真实的调用路径。

Kernel 任务	B200 证据	主要优化方向
qknorm_rope	1.1341x	共享 RoPE 暂存、Q/K 复用、大行快速路径
norm_infer	1.3523x	Warp 行 RMS、分块持久化 RMS、8B/16B 向量路径
rotary_embedding	1.4912x	128 位向量 I/O、cos/sin 提升、LTX2 块匹配
cutedsl_norm_tanh_mul_add	1.4953x	行不变数学运算提升、启动边界调优、精确 tanh
cutedsl_norm_scale_shift	1.3201x	操作数类调度、16B/32B 向量、两遍方差计算
fuse_scale_shift	2.7499x	rowgrid/flatvec/exact-C 路径、缓存提示、单遍归约
group_norm_silu	2.3118x	分组统计、通道最后直接路径、超大行回退方案
attention_concat_copy	1.30x	单次启动区域拷贝、交错 16B 块收集、严格布局/设备拒绝
causal_conv3d_cat_pad	2.06x	扁平分块、16B 向量化存储、步幅感知回退方案、按位精确门控
residual_gate_add	1.11x	单遍 CUDA 融合、固定 GPU 正确性、SGLang PR #29361 B200 Triton 行重新基准测试

该图表和任务表应结合实验背景来解读：它们报告的是在提取的生产数据行上的 kernel 任务加速比，而非完整模型的端到端收益。但它们仍然有用。一旦基线、工作负载、正确性、性能分析和审查被固定下来，智能体就能在真实的框架 kernel 上产生可审查的增量改进。

从 KDA-Pilot 实验中可以提炼出两条值得遵循的规则：

• 不要为基准测试的奖励黑客行为留下空间。当基线模型和候选模型使用不同的 ABI、不同的快速数学设置或不同的封装路径时，结果会变得不可靠。另一个常见问题是在看到结果后更改基准测试的形状集，例如移除候选模型运行较慢的形状。此类结果不应被使用。
• 接近 Roofline 模型的桶应允许“不执行”或“回退”决策。一个好的内核优化任务不应强制智能体在每个形状上都获胜。对于已经接近带宽限制的巨大连续桶或路径，记录一次回退可能比增加更多复杂性更好。

6. 实践规则

1. 在启动智能体之前定义任务边界。“优化 SGLang”过于宽泛。“在 2x B200 上，针对 Qwen/Qwen3-Next-80B-A3B-Instruct-FP8，在固定的 1000->1000 和 8000->1000 工作负载下，匹配另一个开源推理框架”是一个可执行的目标。

2. 在读取性能分析结果之前，先固定基准测试。如果工作负载在结果已知后可以更改，智能体可能会意外地优化一个更简单的问题。SOTA loop 和 KDA-Pilot 都在打补丁之前使用了固定的工作负载。

3. 根据内核的计算特性解读 NCU 结果。对于内存密集型内核，关注 DRAM/L2 吞吐量、加载/存储效率和内存管线利用率。对于计算密集型的 GEMM/注意力内核，关注 Tensor Core 利用率、SM 繁忙度、符合条件的 warp 以及主要的停顿原因。对于延迟敏感的小型内核，检查启动次数、每个内核的持续时间、同步点以及可能的融合机会。单张跟踪截图是不够的；下一次代码更改应有具体指标作为支撑。

4. 在信任性能分析结果之前，检查后端和回退门控。如果大语言模型运行静默切换了注意力后端、禁用了 CUDA graph，或者走了一条与被基准测试路径不同的封装路径，那么该跟踪就不再描述目标服务路径。同样的规则也适用于扩散模型：如果日志显示回退到了 diffusers 后端，则该跟踪不能用作原生 SGLang 扩散模型的证据。这些硬性停止条件应存在于技能中。

5. 内核优化必须使用相同的 ABI、封装器和编译标志。特别是，候选方案不应静默地选择更轻量的路径，并且 `--use_fast_math` 不应仅在一侧启用。

6. 代码审查比以往更加重要。智能体可以创建更多的 PR，但它们也可能制造更多看似合理的错误。对于像 SGLang 这样的高性能系统，审查需要检查形状、数据类型、分布式执行、CUDA 图行为、回退行为、准确性、服务 API、指标和基准测试设置。

智能体时代的 SGLang 开发不会将开发者排除在系统之外。更现实的变化是将开发者体验写入工作流，将重复性执行交给智能体，而将判断、设计和审查留给人类。节省下来的时间可以投入到更困难的性能问题、模型路径和生产稳定性上，或者反过来用于改进智能体工作流本身。对于一个开源推理框架来说，这种基础设施值得持续投入。

7. 致谢

我们感谢 SGLang 团队中帮助构建 SGLang 智能体技能的成员和贡献者：Xiaoyu Zhang (BBuf)、Lianmin Zheng、Liangsheng Yin、Ke Bao、fzyzcjy、Kangyan Zhou、DarkSharpness、Mick、Alison Shao、Baizhou Zhang、Bingxu Chen、Cheng Wan、Ratish P、shuwenn、ykcai-daniel、Yuhao Yang 和 Artem Savkin。

我们感谢 KDA 团队：Dongyun Zou、Ligeng Zhu、Sihao Liu、Junxian Guo、Yixin Dong、Zijian Zhang、Hao Kang 和 Song Bian。

我们感谢 Humanize 团队和贡献者：Sihao Liu、Ligeng Zhu、Zijian Zhang、Zenus Zhang、shinan6、DYZhang、Chao Liu、Zhou Yaoyang、gyy0592、AcrossForest、Emin、Qiming Chu、jiaxiaoyu、tastynoob 和 zhenwei。

8. 参考文献

• SGLang GitHub 仓库
• SGLang .claude/skills
• SGLang 扩散模型 .claude/skills
• AI-Infra-Auto-Driven-SKILLS
• AI-Infra-Auto-Driven-SKILLS 提示词
• 内核设计智能体（KDA）
• KernelWiki 技能
• ncu-report-skill
• KDA-Pilot
• SGLang 扩散模型高级优化，LMSYS 博客
• OpenAI Codex 提示词：目标模式
• Humanize