3月28日下午，龙蜥社区SGLang开发者苏峰和智算联盟委员常怀鑫在沐“蜥”芯生MeetUp上，扔出了一个多数大模型部署团队早晚会撞上的问题：GPU明明显示已打满，CPU也没闲着，可推理吞吐就是卡在一个数上，再怎么加请求也上不去。

现场听完最直接的一个感受是，过去靠日志、Metrics和Torch Profiler三板斧排查这类“性能黑盒”，基本是在摸黑走路。

苏峰把旧手段的短板拆得很细。日志的输出碎片化，想拼出一个请求的完整执行路径，得靠人工做大量后处理；Metrics是聚合后的折线图或直方图，只适合宏观健康度监控，个体请求的延迟抖动直接被平滑掉了，而且无法把PreFill、Decode、调度打断这些阶段串联起来。Torch Profiler倒是能深入函数调用栈，但采集几十秒就是GB级数据，根本没法在线上长时间开着，偶发性的超时问题几乎抓不到。更致命的是，它不区分请求——不管一个Batch里塞了32条还是1条请求，我们看到的只是这次Forward计算的汇总结果，单条请求的卡顿彻底消失在了平均值里。

对比下来，SGLang这次在社区孵化并向上游贡献的请求级Tracing能力，相当于给推理引擎装上了一套“每请求独立GPS”。它的底层是基于OpenTelemetry API构建的，但实现难度远超常规互联网业务。苏峰提到三个关键挑战：首先，OpenTelemetry原生支持多协程自动管理上下文，可SGLang的多请求并发是以Batch形式一起执行的，必须手动为每一个请求维护Tracing上下文；其次，Continuous Batch机制让每一轮推理都可能动态加入新请求或终止已有请求，需要跟踪的点散落在整个代码仓库里；另外，TP、DP、PP、PD等并行模式的存在，要求Tracing不仅要看单请求细粒度执行，还要看清跨卡通信和并行协同的完整过程。

这套Tracing最直接的价值是，可以追着一条请求，看清楚它在PreFill阶段花了多少毫秒，在Decode阶段被调度挂起了几次，以及和其他请求的交互是如何导致排队积压的。而走到AI Agent介入这一步，则是常怀鑫在分享中释放的另一个信号：从“看见问题”到“自动分析优化”的链路正在被打通。利用Tracing输出的全链路数据，AI Agent已经开始尝试对SGLang框架的性能参数进行自动调优，不是简单地套用固定模板，而是根据实时负载模式来动态调整。

整个项目的路径是从龙蜥社区孵化，再向上游主仓库贡献代码。这意味着一套国产开源的可观测方案正在补上推理框架的监控短板。

如果你正在用SGLang跑生产级推理服务，是更相信手动调参的经验直觉，还是愿意把部分优化决策交给AI Agent？