如何衡量 LLM 伺服器的真實吞吐量
如果你在現代伺服器租用基礎設施上執行推論工作負載，那麼LLM伺服器吞吐量這個詞就不該只是供應商投影片上的說法，或實驗室展示中的數字。真實容量取決於排隊行為、token 串流、請求類型組合，以及系統在負載下的實際表現。對於在美國伺服器環境中建構系統的技術團隊來說，目標其實很直接：衡量這套技術堆疊在並發使用者、長提示詞和持續流量同時出現時，究竟能真正交付什麼。
很多關於吞吐量的討論之所以失真，是因為它們把語言模型服務當成一般 Web 流量來看待。這種簡化很快就會失效。生成式工作負載至少包含兩個不同階段：提示詞處理和 token 生成。官方基準測試資料通常將其稱為 prefill 和 decode，而它們對延遲的影響方式完全不同。首 token 時間不僅包含排隊、提示詞處理，也包括網路開銷；而輸出 token 吞吐量則反映串流輸出開始後系統持續生成的效率。與單純的請求數相比，這些指標重要得多。
為什麼「真實吞吐量」不同於理論吞吐量
理論效能總是很整齊，真實效能卻往往充滿雜訊。某台伺服器在紙面規格上可能相當漂亮，但當提示詞長度增加、記憶體壓力升高，或多個工作階段同時進入 prefill 階段時，它的表現可能會完全不同。官方基準測試指南指出，更長的輸入序列會提高 prefill 成本，並可能拉長首 token 時間；而更長的輸出則會對 decode 和 token 間延遲帶來更大壓力。換句話說，一個基準數字根本無法概括整個 LLM 服務。
因此，工程師不該再問「吞吐量是多少」，而應該提出更有價值的問題：
- 在低、中、高並發下，token 速率分別是多少？
- 在排隊壓力下，首 token 時間的穩定性如何？
- 延遲從哪個點開始上升得比吞吐量更快？
- 提示詞長度會如何改變整體曲線形態？
- 系統在持續負載下是否能夠平順退化，而不是突然失穩？
這些問題揭示的是實際運作狀態，而不是宣傳資料中的理想化算術。
你真正應該追蹤的核心指標
在撰寫任何基準測試腳本之前，先把指標定義清楚。如果衡量吞吐量的語言本身是模糊的，那麼最終結果也一定是模糊的。
- 首 token 時間（TTFT, Time to First Token）：從送出請求到收到第一個生成 token 之間的延遲。這是互動式場景中最直觀的回應指標。官方文件將其視為面向使用者的回應性指標，並指出其中包含網路延遲、排隊和提示詞處理。
- token 間延遲（Inter-Token Latency）：串流輸出開始後，相鄰生成 token 之間的時間間隔。這個指標能夠揭示 decode 階段的表現，並幫助判斷輸出是順暢還是卡頓。
- 輸出 token 吞吐量（Output Token Throughput）：整個系統每秒生成的 token 數量。這是衡量生成式服務吞吐能力最直接的指標。
- 請求吞吐量（Request Throughput）：每秒完成的請求數。它當然有用，但只有在輸入和輸出長度被嚴格控制時才真正有參考價值。
- 尾端延遲（Tail Latency）：p95 或 p99 往往比一個好看的平均值更重要，因為生產環境中的真實問題通常都出現在尾端。
- 失敗率（Failure Rate）：逾時、空回應、重試以及與記憶體相關的崩潰，都應該納入最終報告。
對技術讀者來說，最關鍵的原則是：不要在沒有延遲資料的情況下談吞吐量，也不要在不說明負載型態的前提下談延遲。
在開始測試之前，先理解 prefill 和 decode
大多數基準測試錯誤，根源都在於忽視了階段行為。Prefill 是模型處理輸入上下文的階段，decode 則是模型逐步輸出 token 的階段。多份官方資料都強調，這兩個階段對系統造成的壓力來源並不相同，而且 prefill 階段的並發情況會顯著影響排隊深度與首 token 延遲。
這之所以重要，是因為「短提示詞 + 長輸出」和「長提示詞 + 短輸出」可能呈現完全不同的系統瓶頸。如果你的工作負載涉及檢索、程式碼上下文或多輪記憶，那麼 prefill 很可能主導使用者體驗；如果你的工作負載需要持續生成長文本，那麼 decode 效率就可能成為真正的上限。
一個實用的思考模型可以這樣理解：
- Prefill 主導型負載：對提示詞長度、排隊與準入控制更敏感
- Decode 主導型負載：對 token 排程、記憶體頻寬和批次效率更敏感
- 混合型負載：兩者都敏感，而這其實才是很多生產系統的真實狀態
如何設計一個貼近生產環境的基準測試
只有當基準測試接近你計畫執行的真實服務時，它才有價值。這並不意味著要複製每一個邊緣情境，而是要控制那些真正影響系統行為的關鍵變數。
- 固定模型與執行路徑。除非某項變更本身就是實驗目標，否則不要在量化方式、排程參數或平行配置變化後橫向比較結果。
- 固定提示詞與輸出範圍。沒有 token 數量限制的吞吐量資料，幾乎沒有解釋價值。
- 先完成預熱。首次執行的額外開銷可能來自惰性初始化、圖形擷取或快取填充，這會污染結果。
- 將單使用者測試和並發測試分開。前者用於觀察基礎回應，後者用於評估服務容量。
- 測試時間要足夠長。過短的突發測試會掩蓋溫度、排隊或記憶體層面的問題。
- 蒐集系統遙測資料。GPU 使用率、記憶體占用、CPU 壓力和網路表現不是可有可無的附註，它們是解釋結果的關鍵層。
官方的生成式系統基準測試工具通常支援合成輸入或資料集驅動輸入、基於並發的壓力測試、基於請求速率的壓力測試，以及匯出日誌供後續分析。這使工程團隊可以建立可重複的測試流程，而不是只截幾張終端機畫面了事。
一套適合極客維運視角的實用測試矩陣
如果你的網站面向美國基礎設施採購者，那麼讀者多半是在做架構選型，而不是閱讀純理論。因此，提供一套能直接跑起來的測試矩陣，遠比抽象解釋更有價值。
- 情境 A：短提示詞、短輸出、低並發
- 情境 B：短提示詞、長輸出、中等並發
- 情境 C：長提示詞、短輸出、中等並發
- 情境 D：長提示詞、長輸出、逐級提升並發
- 情境 E：混合提示詞長度，並疊加持續背景流量
然後以階梯方式逐步提高並發，而不是一開始就把並發值拉到極限。這樣做可以找出曲線的拐點，也就是輸出 token 吞吐量不再足以抵消延遲代價的那個位置。官方的生成式服務基準測試建議也強調，應仔細掃描並發程度以及輸入輸出長度，因為這些參數會直接決定測試結果是否具有實際意義。
對很多團隊而言，最有價值的圖表並不是「最高吞吐量」，而是「服務從回應流暢變得遲滯的轉折點」。
測試過程中應該記錄什麼
單純的基準測試輸出永遠不夠。你需要把請求端視角和系統端視角配對起來看。
- 請求開始時間和完成時間
- 首 token 時間戳記
- 輸入 token 數和輸出 token 數
- 每個請求的狀態，包括失敗條件
- 正在處理中的並發請求數
- GPU 使用率和顯示記憶體占用
- 主機上的 CPU 與 RAM 壓力
- 如果用戶端位於遠端，還要記錄網路延遲
當數字看起來不對勁時，這些日誌能幫助你判斷問題究竟來自排隊堆積、提示詞膨脹、decode 變慢，還是主機層面的瓶頸。沒有這些資訊，工程師往往會把問題歸因到錯誤的層級。
那些會讓結果失去意義的常見測試陷阱
在 LLM 吞吐量測試中，有一些錯誤幾乎反覆出現。
- 只測一個並發值。這樣根本看不到系統曲線的形狀。
- 忽視提示詞長度。極小的合成提示詞幾乎無法代表檢索型流量。
- 只看平均延遲。使用者真正會抱怨的是尾端延遲。
- 把冷啟動和熱啟動混在一起。初始化開銷會污染樣本。
- 在不同 token 預算下比較請求吞吐量。這根本不是同一維度的比較。
- 報告 tokens per second 時，不說明是系統總吞吐還是單一使用者吞吐。官方資料之所以區分這兩種視角，是有充分理由的。
- 讓用戶端先成為瓶頸。效能不足的壓測端會偽造伺服器上限。
還有一個容易被忽略的陷阱尤其值得單獨提出：協調遺漏。關於 prefill 並發的官方文件提到，如果基準測試工具在等待空閒槽位時自動放慢節奏，那麼整個測試可能會無意中把自身節流到與伺服器容量一致。這會讓延遲表現看起來比真實開放流量情境下更好。
如何像維運工程師一樣解讀結果
當測試結束後，不要急著把最大的數字當成贏家。真正有價值的解讀，永遠是在分析權衡關係。
- 如果 TTFT 一直很低，但 token 串流變得斷斷續續，那麼限制因素很可能出在 decode 階段。
- 如果長提示詞讓 TTFT 急劇上升，那麼問題可能來自 prefill 或排隊準入。
- 如果吞吐量上升了，但 p99 延遲也暴漲，那麼你很可能已經超出可用運作區間。
- 如果結果很差時 GPU 使用率卻不高，那麼瓶頸可能在排程、CPU 處理流程或用戶端路徑上。
- 如果失敗只在持續負載下出現，那麼你的技術堆疊更可能是穩定性出了問題，而不是算力本身不夠。
優秀的維運人員關注的不是「最大數字」，而是「高效區間」。所謂高效區間，就是吞吐量夠強、延遲仍可預測、尾端表現也仍符合應用要求的那一段工作區間。
為什麼這對美國伺服器租用和伺服器託管規劃很重要
對正在評估伺服器租用還是伺服器託管的團隊來說，吞吐量測試絕不只是實驗室裡的練習。它會直接影響容量規劃、資源密度設計和服務型態選擇。一份紮實的基準報告能告訴你，當前系統更適合圍繞回應速度最佳化、圍繞批次效率最佳化，還是圍繞記憶體餘裕最佳化。它也能幫助你估算，在服務品質開始惡化之前，一套部署究竟能支撐多少工作階段。
這在美國伺服器部署中尤其重要，因為這裡對延遲的期望通常比較嚴格，而生產流量又可能隨著地區、工作負載模式和業務時段發生變化。做聊天式互動的團隊，也許更看重首 token 速度；執行後台批量生成的團隊，則可能更關注總體輸出 token 吞吐量。基準測試應該反映這種營運現實，而不是強行追求某個放諸四海皆準的單一目標。
一套可以反覆重用的簡單測試流程
- 記錄硬體和軟體環境。
- 用一組固定的小請求對服務進行預熱。
- 先跑基線單請求測試。
- 逐步掃描並發程度。
- 用更長的提示詞重複掃描。
- 再用更長的輸出重複一次。
- 執行持續性測試，觀察漂移和失敗情況。
- 將 TTFT、token 間延遲、尾端延遲和總體 token 吞吐量結合起來分析。
- 標記出最符合目標應用的運作區間。
這套流程夠簡單，便於重複執行；同時也夠嚴謹，能夠產出真正有工程價值的證據。
最後的思考
LLM 伺服器吞吐量並不是一個行銷數字，而是在明確工作負載下，prefill、decode、排隊、並發和系統邊界共同作用後的結果。只要你認真衡量這些動態因素，就能在架構、容量和美國伺服器租用策略上做出更明智的決策。如果跳過這一步，基準測試就只剩下表演意義。對技術團隊來說，真正的目標不是追逐最響亮的數字，而是找到一個穩定運作點：在那裡，延遲仍然合理，token 串流保持順暢，基礎設施效率也足夠高。
