SGLang 团队把工程经验写进 Agent，结果有点猛

SGLang 团队干了件事：把自家工程经验（benchmarking、profiling、CUDA kernel 调优、生产问题排查）编码成可执行的 agent skills。

结果呢？3 个 KDA-Pilot kernel PR 已经合并上游，B200 上 kernel 加速最高 2.75x，Qwen3-Next 吞吐量提升 71.4%，TTFT 从 456ms 降到 168ms。

为什么 SGLang 适合 agent 辅助开发？

SGLang 是个高性能 serving 框架，LLM 和 multimodal 模型都跑。随着模型和硬件路径膨胀，开发中反复出现几个问题：

• LLM 路径复杂。一个性能问题可能跨 Python runtime、scheduler、CUDA graph、Triton/CUDA kernel、FlashInfer、分布式通信、模型特定 wrapper。
• Diffusion 路径也复杂。慢的 denoise pass 可能涉及 pipeline/stage 划分、DiT blocks、attention 后端、torch.compile graph break、CFG/SP 并行、VAE、自定义 fused kernel。
• 验证成本高。很多改动必须在真实模型和真实 workload 上测试，H100、H200、B200、RTX 5090 都得跑。本地单元测试不够。
• Profile 难以手动复用。一个 trace 可能包含几百个 kernel launch。手动读 Perfetto 容易漏掉 kernel 到 Python 源码的映射，容易混淆 prefill 和 decode。开发者积累的 know-how（哪个 kernel 对应哪个模型逻辑、哪些 launch pattern 暗示 graph break）如果只留在一个人脑子里，下一个任务没法复用。
• 性能结论严重依赖上下文。GPU 类型、shape、batch size、并行度、精度、后端、编译状态都会改变结果。孤立 microbenchmark 往往不能证明真实模型收益，需要端到端长时间测试反复验证。

这些问题天然适合 agent。启动 server、固定 workload、收集 trace、分析 profile 行、加测试、记录实验结果——都有明确的输入输出，适合脚本化和重复执行。开发者需要定义边界：同样的 benchmark 设置、同样的 profile 解释规则、同样的精度门限、以及 agent 何时应该停止改代码。

从 prompt 工程到 SKILL

SGLang 团队把常用工作流编码成技能文件（.claude/skills），每个技能都回答了：什么时候用、怎么启动、怎么验证、怎么决策、怎么交付。目前覆盖的层次：

最近合并的几个案例

Router 长上下文 tokenization 去重（PR #28744）：DeepSeek-V4-Flash 上，60k/125k token 提示的 idle TTFT 降低约 29%/41%，负载下 TTFT 降低 34%–49%。Agent 同时处理了 cache-aware routing、chat-encoder 对齐、engine 侧 input_ids fallback 和 proxy body 构造，避免了 router 和 engine 重复 tokenization。

Qwen3-Next FlashInfer allreduce fusion（PR #22664）：H100 TP=4 上，请求吞吐从 5.49 req/s 提升到 9.41 req/s（+71.4%），平均 TTFT 从 456ms 降到 168ms。这是 profile 驱动的 LLM collective 优化：未融合的跨设备 reduce 主导了 prefill，融合后的 allreduce 路径通过了 MMLU/GSM8K 精度验证。

Cohere2Moe NVFP4 fused-MoE（PR #27401）：1x B300 上，CohereLabs/command-a-plus-05-2026-w4a4 的请求吞吐比 SGLang 此前默认路径提升 26%（chat）和 21%（summarization），比另一个开源框架高 4.1%/6.8%。改动补全了 routing 语义，让已有的 flashinfer_trtllm NVFP4 fused-MoE kernel 能正确用在真实模型路径中。

Kimi Delta Attention CuteDSL prefill kernel（PR #27488）：B200 上，moonshotai/Kimi-Linear-48B-A3B-Instruct 的 Delta Attention prefill 比 Triton 快 1.08x–1.52x。这个 kernel 任务需要覆盖模型的 gate 分布、数值溢出、host 开销、真实模型精度和单元测试才能合并。

Spectral Progressive Diffusion（PR #27524）：FLUX.1、FLUX.2、Z-Image、Wan、Qwen-Image 的 denoising 加速 1.6x–2.32x。思路是早期 denoising 在较低 latent 分辨率下跑，GPU DCT 上采样在高频细节开始重要时恢复全分辨率。

LTX-2 VAE decode channels-last-3d（PR #27431）：LTX-2 decode 阶段从 5.41s 降到 3.84s（1.41x），峰值预留内存从 71.81 GiB 降到 62.12 GiB，省了约 9.7 GiB。Profile 指向 Conv3d 和 layout conversion，修复方案在 causal padding 中保持了 memory format，并把 loader policy 连接到单 GPU LTX-2。

这些案例中，agent 主要贡献是执行工作流：跑 benchmark、读 profile、定位 Python 源码、改代码、加测试、重新验证、准备 PR 描述。没有技能，很多步骤靠人工记忆；编码成技能后，工作流变得容易重复。

Profile 分析的两步法

SGLang 性能工作中一个常见错误是只看总耗时，或者打开 Perfetto 看几分钟就凭直觉判断"这个应该融合"。对 agent 来说这更危险——它们很容易把视觉上"热"的 kernel 误认为真正的瓶颈。

实践中通常两个 profiler 技能配合使用：

第一步，llm-torch-profiler-analysis 把全局 profile 转成三张固定表格：Kernel Table（按阶段汇总 GPU 时间占比、launch 次数、kernel 类别，并映射回 Python 源码）、Overlap Opportunity Table（用 exclusive/hidden time 占比识别剩余 overlap 空间）、Fuse Pattern Table（对比 SGLang、其他框架和 kernel 库中已有的融合/overlap 路径）。

第二步，llm-pipeline-analysis 把热点定位到具体的 forward pass、层类型和 kernel 流。它读取 Chrome trace JSON 和模型 config.json，用层边界 anchor kernel 切分 trace，产出 forward pass 摘要、逐层时间线、层聚类统计和计算流表。这对 NSA/hybrid-attention 这类交替层结构的模型尤其有用——C4_LIGHT、C128_HEAVY、HASH 等不同层类型可能各自主导延迟。

Loop Engineering：把"追 SOTA"变成可重复流程

单次优化可以用一个 skill 搞定。但十几轮实验之后，问题变了：哪个 candidate 最好、哪些方向已经失败、上次 NCU 报告说了什么、benchmark 是否还和 baseline 对齐、什么时候该停。这些状态不能只活在 chat context 里。

SGLang SOTA Performance Loop 是一个构建在 Humanize/RLCR 之上的 Loop Engineering 工作流。SOTA 在这里指的是固定实验条件下的最佳可复现结果：同样的模型、硬件、GPU 数量、精度、workload、SLA、框架 commit 和 serving 参数。

完整流程分六步：定义目标边界 → 先跑公平搜索 → 判断差距 → 用 profile 解释差距 → 只在有证据支持的路径上 patch → 在相同 workload 上重新验证。每一轮都记录 benchmark、profile、精度、失败尝试、环境信息和清理动作。

Humanize/RLCR 把这个流程拆成两个阶段：先用 humanize-gen-plan 把需求草案转成结构化的 plan.md（包含目标描述、验收标准、正负测试、路径边界、里程碑），再用 humanize-rlcr 启动循环——Claude Code 执行实现和实验，Codex Review 在每轮结束时检查状态、证据和风险。

对于不想搞双角色（执行+审查）这种较重设置的场景，Codex Goal 提供了更轻量的替代方案。把"公平 benchmark → 差距判断 → profile → patch → 重新验证 → 产物清单"写进一个持久化 Goal，单个 Codex Goal 就能持续执行、自检和重验，省掉双模型角色的成本和等待时间。

KDA-Pilot：CUDA kernel 优化的工业化

模型级优化之外，kernel 优化有更残酷的 scaling 问题。没有独立于硬件和 workload 的最佳 kernel。同一个算子，H100、H200、B200、B300 上偏好不同实现；不同模型架构暴露不同 tensor shape 和布局约束；serving workload 会改变 batch size、sequence length、精度格式、wrapper 开销、同步行为、fallback 路径。搜索空间是硬件 × 模型 × workload 的笛卡尔积。

KDA-Pilot 把 kernel 优化拆成隔离任务，让 agent 不能随意修改整个 SGLang 仓库：

• workload 来自真实 SGLang diffusion 模型。先跑 20 个 diffusion 模型，汇总实际 kernel 元数据。
• baseline 从上游 SGLang main 复制，记录来源。
• baseline 和 candidate 必须使用相同本地 ABI 和相同 build/export 路径。
• benchmark 使用固定生产行、A/B 交错、CUDA event 或 wall timing。
• 正确性覆盖生产行、规范回归网格、NaN/Inf 检查、poison 输出检查、fallback 契约。
• 每轮迭代刷新 task prompt、benchmark 证据、KernelWiki、ncu-report-skill。
• 允许 shape 特化分发，但每个 bucket 必须记录条件、路径、延迟、fallback。

截至 2026 年 6 月 27 日，三个 KDA-Pilot 衍生的优化已合并上游：

下面这张图展示了 10 个跟踪的 SGLang diffusion kernel 任务的 B200 加速比：

需要说明的是，这些是提取的生产行上的 kernel 任务加速比，不是完整模型端到端收益。但一旦 baseline、workload、正确性、profiling 和 review 都固定下来，agent 就能产出可审查的增量改进。

几条实践规则

1. 在启动 agent 之前定义任务边界。"优化 SGLang"太宽泛。"在 2x B200 上，固定 workload 下让 SGLang 匹配另一框架"才是可执行目标。
2. 在读 profile 之前固定 benchmark。如果 workload 可以在看到结果后改变，agent 可能意外优化了一个更简单的问题。
3. 根据 kernel 的计算特性解释 NCU 结果。内存受限 kernel 关注 DRAM/L2 吞吐、load/store 效率；计算受限 GEMM/attention 关注 Tensor Core 利用率、SM busy、eligible warps；延迟受限 kernel 关注 launch 次数、每 kernel 时长、同步点。
4. 在信任 profile 之前检查后端和 fallback 门限。如果 LLM 运行静默切换 attention 后端、禁用 CUDA graph、或走了不同的 wrapper 路径，trace 就不再描述目标 serving 路径。Diffusion 同理：如果日志显示 fallback 到了 diffusers 后端，那个 trace 不能作为 native SGLang diffusion 的证据。
5. Kernel 优化必须使用相同 ABI、wrapper 和编译标志。candidate 不能静默走更轻的路径，--use_fast_math 不能只开一边。
6. Review 比以前更重要。Agent 可以创建更多 PR，也能制造更多看似合理的错误。高性能系统的 review 需要检查 shape、dtype、分布式执行、CUDA graph 行为、fallback、精度、serving API、metrics、benchmark 设置。

Agent 时代的 SGLang 开发不会把开发者从系统中移除。更现实的变化是：把开发经验写进工作流，把重复执行交给 agent，把判断、设计、review 留给人类。省下的时间可以投入到更难的性能问题、模型路径和生产稳定性上，或者反过来改进 agent 工作流本身。对于一个开源 serving 框架，这种基础设施值得持续投入。