AI热榜 编者按： 大模型推理的性能瓶颈往往隐藏在 Prefill 与 Decode 的交错调度、多卡间的数据同步、以及 Continuous Batch 的动态编排之中——而要真正“看见”这些问题，离不开请求级别的可观测能力。
在沐“蜥”芯生，开源共创—— SGLang 技术交流 MeetUp 上，龙蜥社区 SGLang 开发者苏峰和龙蜥社区智算联盟委员常怀鑫分享了《从全链路可观测到智能分析：AI 性能分析范式的演进与实践》的主题演讲。
两位嘉宾在演讲中回顾了其在龙蜥社区孵化并向上游贡献的 SGLang Tracing 可观测性建设历程，并结合具体案例探讨如何利用 AI Agent 实现 SGLang 框架的性能优化。
以下为本次演讲全文： SGLang Tracing 请求级可观测能力 当前推理引擎在部署时会面临很多性能问题——不管是线上服务还是部署新模型、研发新实例，我们经常遇到这样的情况：测试指标偏高、请求中止或超时；又或者 CPU 和 GPU 资源没有打满，但吞吐再也提升不上去。
这些都是典型的性能问题。
要分析上述问题，完善的可观测性是基石。
在此之前，SGLang 有三类观测手段： 第一种是日志。
一般我们用日志来看整体的健康度，但它的输出比较碎片化，而且不是所有信息都会输出，所以用日志来分析问题通常需要做大量的后处理。
第二种是 Metrics。
一般用于线上健康度观测，呈现形式类似于折线图或直方图，是聚合的统计数字。
它偏向宏观观测，会丢失请求的个体信息，也没有办法把请求的执行过程关联起来。
第三种是 Torch Profiler。
这应该是我们离线分析性能问题最常用的手段，非常好用。
但最大的问题是它非常重——采集几十秒就会产生 GB 级的数据，没办法长时间采集。
对于偶发性问题，采集到它的概率其实不大。
另外一个缺点是它不区分请求，以函数调用栈的方式呈现，不管 batch 里有多少请求，我们看到的其实就是一次 batch 里一个 forward 的结果。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接