這一篇將介紹LLM服務有關推理計算的評估指標 (Computation evaluation metrics)。
這個分類是參考論文Beyond Efficiency: A Systematic Survey of Resource-Efficient Large Language Models第九章中的評估分類方式,此研究中其他還有整理一些Energy, Financial cost, Network communication等評估指標,可以供讀者去參考。
現在LLM應用滿地都是,雖然很多服務都是誰先出來誰先贏、使用上體感速度似乎不錯,不過要怎麼客觀的跟別人比較說你的系統比較好、比較快?在數字會說話的情境下,認識這些推理計算的評估指標就很重要了!
另外,在推理加速技術和框架越來越多的情況下,在選擇框架的時候這些評估指標就是關鍵了。假設現在已經選好不錯的模型,硬體負載量也OK,那除了看模型準確度,更需要注意生成時間。
(圖源: 網路)
在LLM推理時基本上就是兩種模式:
User輸入query後到產生第一個token的時間,對應的就是上一章說到的prefill階段時間。在streaming模式下送出後等待第一次回應的時間。
影響的因素包含:服務的網路速度、輸入序列的長度、模型大小
在streaming模式下後面每個token出現的時間,只要模型產生的速度大於人類閱讀的速度,就是一個非常好的體驗。100 ms/token的TPOT就是每秒可以收到10個token。
這兩個比起來,目前在工作上遇到的是RAG系統客戶比較在乎的會是TTFT,如果是stream回應的話,送出問題之後假設5秒內只要有打字效果,user勉強算是可以接受了。
不過RAG系統除了生成的速度之外,還有包含前面的文件搜尋或排序,這些都會有額外的等待時間出現,需要被考慮進去。
User收到完整回應的總時間。影響的因素包含:輸出長度、prefill time、硬體排隊時間(因為缺乏GPU或記憶體,導致有些request在排隊中)
Latency = TTFT + TPOT * (tokens數量 - 1)
另外也要考慮LLM的冷啟動時間。當LLM在先前處於非活動狀態後被呼叫時,它會導致冷啟動 (Cold Start),需要重新啟動、分配計算資源、模型載入,所以需要額外的時間準備處理request。
另外如果有做Scaling to Zero,當服務一定的時間內沒有收到請求的話,伺服器也會自動將分配給他的資源釋放掉。
分成推理服務在某個時間跨度內,可以處理多少User請求,或是可以產生的輸出token數。
雖然知道要測試什麼內容,但是實際上有很多衡量上條件不太統一的問題,因此很難進行模型之間的比較。
這章稍微提到了一些常用在LLM推理計算上的評估指標,像是TTFT, TPOT, Latency和Throughput,目標就是最小化延遲的時間與最大化吞吐量。
因為這邊只有純推理計算上的指標,如果是有做其他LLM應用的服務,通常會針對那個服務有更多推理上的評估指標,像是RAG的生成就會需要知道生成答案的相關性 (Relevance),這部分又是一個很大的坑了。
後來發現打錯TPOT的縮寫非常抱歉!!
A Guide to LLM Inference Performance Monitoring
https://symbl.ai/developers/blog/a-guide-to-llm-inference-performance-monitoring/
LLM 推理性能优化最佳实践
https://mp.weixin.qq.com/s?__biz=Mzk0ODU3MjcxNA==&mid=2247484362&idx=1&sn=a7a9cc60f95b78083bc12348b168d2cc&chksm=c364c48ff4134d9954f929a4de363bbee2f8a0590008d1ea2099635f503b1a970fa853639e0e&scene=21#wechat_redirect