手工要二三十分钟：四个案例看智能体怎么压推理

手工要二三十分钟：四个案例看智能体怎么压推理

OpenAnolis 的 Feng Su、Huaixin Chang 在 2026-09-08 的阿里云社区文章里，讲 SGLang Tracing 怎样补上请求级观测，以及智能体怎样拿这些数据做性能分析和算子优化。SGLang 是大模型推理引擎。文章来自 SGLang 技术交流会上的演讲，主题是从端到端观测走到智能分析。下面四个案例里，三个是分析，一个是优化。

推理变慢时，常见现象是测试指标异常高、请求中断或超时、GPU 和 CPU 没用满但吞吐到顶。作者认为要先看见单次请求，而不是只看汇总。

日志、指标和 profiler 各缺一块

原先有三种看法。日志能看整体健康，但输出碎，而且不是每件事都有日志。指标适合线上健康度，是折线或直方图上的汇总，单次请求的过程丢了。torch profiler 适合线下分析，但几十秒的采样就能到数 GB，不能一直开，偶发问题靠运气；它也不区分请求，一批里多少请求都只显示这一次 forward 的调用栈。想知道的是哪一条请求在哪一段变慢。

做成请求级追踪有三件难事。请求是打成 batch 一起跑的，不能靠协程切换自动带上追踪上下文。Continuous Batching 里，同一轮可能有新请求加入、旧请求结束，埋点散在代码各处。并行还有张量并行、数据并行、流水线并行和 Prefill-Decode 分离，既要看请求本身，也要看它怎么并行。

SGLang Tracing 用官方 OpenTelemetry API，外面包一层上下文管理，可以送到 Collector，再用 Jaeger 或 Zipkin 看。也可以导出文件，离线转成 Perfetto，在一张时间线上看所有请求。核心收进 TimeStats：一个阶段结束时，用前一个时间戳生成 Span，并把上下文从 tokenizer 交到 scheduler。宏阶段和时间戳类型不变时，内核怎么改都不用改追踪模块。功能关掉时，对主推理路径的开销是零。

Span 分三层。第一层是请求，一条请求一个总 Span。第二层是线程，从请求进入某条线程到离开，用来看不同并行方式下怎么执行。第三层挂在线程 Span 下，可以细到每个 token，粒度用 trace level 调。上游应用的 Span 也能接进来，例如 Dynamo 调用 SGLang。

演示用的是非 PD 分离、TP 部署：一个 tokenizer 进程加两个 TP rank，两条请求同时跑。每条线程下有两行，同一条时间线上能看见 Prefill 的 forward 分开处理、Decode 的 forward 合在一起。

案例一：把找 SLA 配置从手工改成编排

日常任务是：在给定配置下，找到满足 SLA 的最优 QPS 和对应参数。例子是把 DeepSeek V4 部署在 H20 上。全靠人做要反复起停服务、手调 QPS、凭经验猜。单次测试常常要 20 到 30 分钟，而且人得一直盯着。

把测试方法固化之后，智能体对一套配置可以在十多分钟里找到最优 SLA 方案。文中的例子是 DeepSeek V4、TP8、H20，智能体自动给出了最优测试结果。文章没有写出那个 QPS 或参数值。

只靠 Skill 或智能体仍会偏。对 max_running_requests 和 QPS，智能体一开始的理解和工程师意图可能不一致。作者认为目前更有效的是人机协作：先对齐几轮，把确定的逻辑收成脚本，再让 Skill 编排剩下的流程。人保留判断，智能体负责执行。

案例二：三个 Skill 读 profiler

测试时要找瓶颈，还要看不同算子的 MFU 和资源利用率有没有到合适水平。MFU 是模型算力利用率。以前要在大量数据里按模型结构做分析，经验难复用。三个 Skill 串起来：

模型结构 Skill 展示具体模型的结构，数据来自上游开源项目。流水线分析 Skill 从 torch profiler 里选 batch 和层，再看这一层里的算子。计算仿真 Skill 看一层里的数据流，结合基础知识估算每个算子的实际输出张量类型和 MFU。

合在一起的输出包括模型结构、profiler 里的 batch 和层，以及算子信息。融合 MoE 算子的案例里，能看见关键算子的 MFU 执行情况，模型还会给出自己的判断。文章没有给出这个案例的 MFU 数字。

案例三：上新模型前先估并发

问题是新模型能不能在 H20 这类卡上跑，显存够不够。Prefill 阶段的显存通常不是重点。Decode 要较高 batch 才能把核心算子的 MFU 拉起来，这时显存可能到顶。要回答的是：给定输出形态，并发能到多高，MFU 满不满意。

容量估算 Skill 用静态和动态数据，加上抽出来的边界。显存拆成模型权重、KV Cache，以及框架运行时的主要动态显存。再结合每个 token 或每个请求的显存，估算特定配置下的并发。经验是：在 H20 或同类 GPU 上，并发到 200 及以上，利用率通常很好。这是经验判断，不是某一次跑分的结果。

案例四：三轮迭代把融合 MoE 提高约 20%

优化用的是开源项目 Kernel-Pilot，结构分成三块。Humanizer 是智能体流程：长任务或复杂任务里，单次流程很少能到最好，所以用循环或多智能体让任务多跑一阵。三个角色是模型优化（Claude）、代码审查和状态评估（后两个用 Codex）。Kernel knowledge 放的是从历史资料里抽出的内核优化经验。NCU Skill 用 NVIDIA Nsight Compute 做深入分析。

优化前必须先定义 workload set。融合 MoE 内核按不同输入序列长度做了调优。大约三轮之后给出最终结果。如果是单次流程，第一轮就可能停。代码审查和其他 Codex 智能体又往下钻了两轮，用 NCU 数据找到新的优化点。最后改 MoE 相关配置，各 workload 上平均提高约 20%。文章没有按序列长度拆开这 20%。

还没做完的部分

TP、DP、PP 和 PD 分离的基础追踪已经合入。最近补了 SD/EPD 分离的架构支持，以及 PD 分离场景里 Mooncake 后端的追踪。还在做的是 KV Cache 在 L1 到 L3 的数据传输追踪、eagle V2 的评审，以及大批量下异步 OpenTelemetry 导出带来的开销，避免挤占主路径的时间窗。后面要补不完整的组件覆盖、过粗的 Span 属性、随意的 trace level，并做成直接导出 Perfetto，替换现在的离线脚本。

四个案例里，案例一没有最优 QPS，案例二没有 MFU 数值，案例三的 200 并发是经验而不是实测表，案例四的 20% 是各 workload 的平均。关掉追踪时开销为零，打开后在大批量下的导出开销仍在优化，没有给出开销百分比。页面没有禁止复制的声明。

阿里云，Feng Su、Huaixin Chang（OpenAnolis），From Incubation in OpenAnolis to Upstream Contribution: SGLang Tracing and AI Agent Tuning Practices，2026-09-08，https://www.alibabacloud.com/blog/from-incubation-in-openanolis-to-upstream-contribution-sglang-tracing-and-ai-agent-tuning-practices_603537