AI News HubLIVE
站內改寫4 分鐘閱讀

超越每秒Token數:如何平衡LLM推理的速度、成本和質量

大多數團隊仍以每秒Token數和每百萬Token成本評估LLM,但這些指標無法預測生產行為。本文揭示了速度、成本和質量之間的真實權衡,介紹了帕累託前沿作為評估框架,並強調了TTFT、p99延遲等關鍵生產指標。

大多數團隊仍然使用供應商主頁上最顯眼的兩個指標來評估大語言模型(LLM):每秒Token數和每百萬Token成本。這些數字簡單、方便、易於比較,但它們很少能預測生產環境中的實際行為。一個在嚴格控制基準測試中看似快速的模型,在中等併發下可能會停滯不前;一個看起來成本高效的模型,當流量增長時可能會導致2-3倍的預算超支;而強大的合成性能在真實世界的提示、真實延遲和真實的多步驟流水線中可能會急劇下降。

如今,大語言模型驅動着企業級人工智能系統:多模態流程、檢索增強生成(RAG)流水線、編排代理、多模型集成以及支持數千併發用户的交互式應用程序。這些環境會放大微小的性能問題,將低效轉化為用户可見的故障或失控的基礎設施成本。

為了成功實現大規模運行,團隊需要理解大語言模型推理的更深層機制:精度如何影響推理能力,併發性如何塑造延遲分佈,並行性如何改變吞吐量,以及調度規則如何與流量模式交互。本文旨在指導企業團隊識別大語言模型部署中的隱藏權衡,並通過實際工作負載的視角(而非簡化指標)來評估性能。

為什麼傳統基準測試會誤導團隊(以及供應商如何操控它們)

基準測試結果通常看起來具有決定性:一個單一的吞吐量數字、一個每百萬Token成本估算,或者一個顯示某個模型優於另一個的圖表。但這些數字背後的現實很少能代表大語言模型在生產中的實際行為。供應商通常設計基準測試來突出理想條件下的優勢,而不是企業級工作負載中存在的可變性、不可預測性和多維權衡。

表面之下,這製造了一種性能幻覺,可能嚴重扭曲基礎設施規劃、產品決策和成本預測。

Token吞吐量和單位成本的侷限性:Token吞吐量是批量優化的,通過大型同質批次、一致的序列長度和預熱GPU來測量。在這些條件下,即使中等硬件也能顯示令人印象深刻的數字。但企業流量並非同質:用户發送變長提示,請求以不可預測的間隔到達,應用程序通常混合了交互式和批處理工作負載。Token/秒未能捕捉:交互行為(聊天機器人中的TTFT而非吞吐量驅動感知速度)、調度約束(併發決定Token的生成和排隊方式)、混合長度低效(長提示造成批處理停滯,短提示無法充分利用GPU)以及冷啓動懲罰(新會話、容器啓動和緩存未命中會扭曲性能)。

每百萬Token成本同樣不完整。它排除了實際驅動基礎設施支出的因素,包括延遲開銷、量化導致的質量下降以及為在真實流量下維持SLA所需的額外GPU小時。團隊最終支付的費用往往是預測的兩到三倍,因為供應商指標沒有考慮併發性、尾部延遲或質量影響。

供應商如何操控基準條件:為了最大化頭版性能,供應商通常會調整其推理棧以優化條件而非現實條件。這包括:激進的量化(int8/int4)降低VRAM需求並提高吞吐量,但會嚴重損害推理準確性、長上下文一致性和細微任務的表現;確定性解碼(温度=0)穩定了基準測試,但隱藏了真實對話代理中出現的方差和非確定性;預熱緩存基準測試預加載KV緩存、嵌入或模型權重,使基準測試永遠不會遇到真正的冷啓動行為;合成提示生成使用固定長度的均勻提示,創建完美高效的批次,而真實工作負載的序列長度變化極大;鎖定內存和定製硬件導致誤導性的速度或成本推斷;禁用安全或路由層去掉了生產系統必須運行的安全分類器、審核層或系統提示引入的延遲。

這些優化本身都沒有錯,但它們常常產生的指標並不能準確反映真實企業環境中的端到端行為。

理解大語言模型部署中的真實權衡(以及為什麼帕累託前沿很重要)

在評估大語言模型性能時,目標不是找到最快或最便宜的模型,而是理解哪些權衡對你的工作負載重要,併為這些特定約束選擇一種平衡速度、成本和質量的最佳配置。大語言模型推理是一個多目標優化問題,每個軸上的改進都會影響其他軸。

速度、成本和質量不能獨立優化:每種推理配置都受到三種對立力量的影響。速度受批處理策略、調度激進程度、精度水平和並行性選擇的影響。追求更高速度通常會引入權衡,例如在流量不規則或突發時增加p99延遲或降低輸出質量。成本由模型大小、精度和併發限制驅動。降低成本通常涉及約束其中一個或多個維度,這可能會減少推理深度、準確性或在需求高峯時的響應能力。質量通過更高精度、更大上下文窗口、更保守的調度和減少批處理來提升,但這些選擇會增加計算負載、減慢推理並提高GPU支出。

這些力量相互牽制。一個主要針對成本調整的配置通常會犧牲TTFT或推理質量;一個針對速度調整的配置可能在高等併發下掙扎;一個針對質量調整的配置可能需要顯著更多的計算資源。沒有通用的最佳配置,只有針對特定工作負載的適當平衡。

這就是為什麼依賴每秒Token數或任何單一指標不可避免地導致決策失誤。帕累託前沿框架能夠展示所有配置中,改善一個指標需要犧牲另一個指標的那些配置。它提供了一種結構化的方式來理解權衡,而不是盲目優化。在實踐中,帕累托最優配置揭示了團隊如何必須在以下方面做出平衡:更低的TTFT與更低的吞吐量、更好的質量與更高的成本、更高的併發與更多的內存使用、更緊的p99延遲與降低的批處理效率。這種方法將評估與實際業務需求對齊,使團隊能夠為其約束條件選擇最佳配置,而非擁有最令人印象深刻的基準數字的配置。

標準基準測試中缺失的生產關鍵指標

大多數公開基準測試關注吞吐量,但僅靠吞吐量無法預測大語言模型在實際工作負載下的行為。企業流量暴露了簡單基準數字隱藏的性能維度:響應性、併發限制、調度行為和內存模式。這些指標直接影響用户體驗、SLA穩定性和基礎設施成本。

TTFT(首次Token生成時間)主導聊天、代理和副駕駛的用户體驗。交互式應用生存在TTFT和p99延遲之上,因為用户感知到每一毫秒。TTFT對批處理累積、緩存未命中和調度選擇敏感,決定了界面的響應感。高TTFT使助手在回覆前猶豫,降低信任和參與度,即使吞吐量很強。Token間延遲(ITL)決定了流式平滑度和SLA穩定性。變異性來自解碼階段的內存壓力和調度開銷。當ITL不一致時,對話代理感覺斷斷續續或“結巴”,增加用户流失。p99延遲揭示了在真實併發下的真實性能。平均延遲隱藏了尾部行為。p99顯示系統在併發激增或輸入長度變化時的反應。高p99值會破壞SLA、觸發超時,並迫使團隊過度配置GPU以補償不可預測的邊緣情況。

這些指標共同構成了評估大語言模型推理性能的更完整畫面。團隊應超越基準指標,構建考慮其特定工作負載的評估框架。