vLLM、SGLang 等推理引擎默认使用 Continuous Batching 调度，一条请求变慢往往不是请求本身的问题，而是同一批次中其余请求带来的副作用；只看单条调用链无法判断耗时被谁拖长。引擎并发分析将一段时间内推理引擎中所有请求的执行情况呈现在同一视图中，支持按时刻横向对比全部并发请求。本文介绍如何打开引擎并发分析视图、读懂视图中的方块与阶段耗时，并诊断以下两类典型问题：
Decode 阶段耗时抬升、TPOT（单个输出 token 的耗时）上升：诊断 Decode 被大 Prefill 阻塞导致的 TPOT 上升
请求链路中 Wait 阶段耗时过长、新增请求排队：诊断突发并发导致的请求排队
为什么需要并发视角
大模型推理的瓶颈通常不在算力，而在显存带宽：每生成一个 token，都要把模型权重从显存搬进计算单元一次，而单条请求的一次矩阵乘只用到其中极小一部分算力，GPU 大部分时间在等数据。攒批让多条请求共享同一次权重读取，把访存开销摊薄，可以显著提升单卡吞吐。传统静态批处理以整批为调度单位：短请求算完也要空转等待最长请求结束，新请求必须排队等待整批放行，首 token 延迟（TTFT）被拉长。Continuous Batching 则把调度粒度从“一整批”降到“一次迭代”——每完成一步解码就检查一遍队列，结束的请求立刻退出并释放 KV Cache，等待中的请求马上补进空出的槽位，批次始终保持饱和，吞吐和尾延迟同时得到改善。这也是 vLLM、SGLang 等现代推理引擎默认采用 Continuous Batching 调度的原因。
代价是排查一条慢请求时，不能只看它自身的阶段耗时，还要看同一时刻与它共处一个批次的其他请求：Prompt 有多长、是否正在 Prefill、是否已把并发请求数顶到上限。这正是引擎并发分析要解决的问题——使请求所处的批次环境成为可以直接观察的对象。
前提条件
已按对vLLM/SGLang推理引擎进行可观测完成 ARMS Python 探针接入，推理引擎已通过探针启动并上报链路数据。
使用限制
本文的诊断方法依赖请求的 Wait、Prefill、Decode 阶段耗时。各开关的默认值与生效条件见vLLM/SGLang 采集配置说明。
PD 分离（Prefill 与 Decode 阶段由不同 worker 承担的部署形态）与非 PD 分离部署均可使用。两种部署形态的视图布局不同，见不同部署形态的视图布局。
打开引擎并发分析
登录云监控 2.0 控制台，选择目标工作空间。
在左侧导航栏选择所有功能 > 推理服务可观测，进入推理服务应用列表。
单击目标推理服务应用。进入应用后，顶部导航栏展示引擎并发分析。
在顶部导航栏单击引擎并发分析。
在页面右上角的时间选择框设置需要查询的时间段。
完成后，视图按该时间段展示引擎内所有请求的执行快照：出现时间轴与代表推理请求的方块。如果视图中没有出现请求方块，或看不到 Wait、Prefill、Decode 阶段耗时，按以下方向排查：
选择的应用与查询时间段是否正确。
是否已完成 ARMS Python 探针接入，且推理引擎已通过探针启动并上报链路数据。
采集粒度是否设为
0——此时只有请求级llm_requestSpan，没有wait、prefill、decode阶段子 Span。
读懂引擎并发分析视图
视图元素与坐标
引擎并发分析视图是一段时间内推理引擎中所有请求的执行快照：横轴是时间轴，每个方块代表一个推理请求在引擎内的执行区间，并发执行的请求在视图中各占一行。
交互与判读
将鼠标悬停在请求方块上，可以看到该请求 Wait、Prefill、Decode 各阶段的耗时。判读某一时刻的并发情况时，可在该时刻作一条竖线：竖线穿过的所有方块，即为这一时刻正在执行的全部推理请求；要判断某个时刻引擎是否已经跑满，可以直接数该时刻竖线穿过的方块数量。视图中的并发行数受引擎的最大并发请求数限制。例如把引擎的最大并发请求数设置为 8 时，同一时间最多只有 8 个并发请求，竖线最多穿过 8 个方块。
不同部署形态的视图布局
非 PD 分离部署下，所有请求显示在同一面板的时间轴上；PD 分离部署下，Prefill worker 和 Decode worker 分别显示在独立的面板中，同一请求的两个阶段通过一条虚线关联。沿虚线可以从 Decode 侧定位对应的 Prefill 请求，并分别判断两侧的排队和执行耗时。
诊断 Decode 被大 Prefill 阻塞导致的 TPOT 上升
大 Prefill 请求（Prompt Token 数明显高于其他请求）会阻塞同一批次的 Decode 请求，使该批次的 Decode 阶段耗时明显高于大 Prefill 请求出现之前的水平，在指标上表现为 TPOT 上升。在引擎并发分析视图中按以下方式定位阻塞来源：
找到 Decode 阶段耗时抬升的时间窗口，将耗时升高的 Decode 阶段与同一时间窗口内的其余请求对齐。
对比这些请求的 Prompt Token 数。如果某个 Prefill 请求的 Prompt Token 数明显高于其他请求，可判定该大 Prefill 请求是主要阻塞来源。
以非 PD 分离部署、引擎最大并发请求数为 8 的场景为例：按上述判据找到大 Prefill 请求后，可以看到与它在时间上重叠的 Decode 阶段耗时同步抬升，且抬升的起点与该 Prefill 请求进入批次的时间一致。如需进一步核对 TPOT 指标的定义与计算方式，可查阅vLLM/SGLang 采集的 Span 与指标列表。
诊断突发并发导致的请求排队
如果在请求链路中看到 Wait 阶段的耗时特别长，可以查看对应时间的引擎并发分析视图。在对应时间窗口中，如果并发请求数相较此前突然升高，并同时出现较长的 Wait 阶段，说明突发流量超过了推理引擎当时的处理能力，新增请求因此进入队列等待。结合最大并发请求数上限可以进一步区分原因：如果并发请求数长期贴在上限，说明引擎容量本身不足；如果只在某一时间窗口内突然抬升，则是突发流量所致。如需核对 Wait 阶段子 Span 的属性口径或 TTFT 指标的定义与计算方式，可查阅vLLM/SGLang 采集的 Span 与指标列表。