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 分離部署均可使用。兩種部署形態的視圖布局不同，見不同部署形態的視圖布局。
開啟引擎並發分析
登入CloudMonitor 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 與指標列表。