北京
周五下午三點，你的LLM應用突然開始排隊。用戶截屏發到群里：“卡了五分鐘還沒出結果，這AI是不是在構思小說？”你打開監控面板，GPU利用率穩在90%，推理請求卻在隊列里越堆越長。直覺告訴你加卡、切模型、上vLLM。但真正吞掉延遲的往往不是你想象的那個瓶頸——而是每個請求里默認塞進去的大量無用工作。
原型階段一切都很美好。寥寥幾個用戶，一條prompt調一次模型，響應快到你根本不會多看。可一到生產環境，流量一沖，會話變長，RAG往prompt里猛灌上下文，Agent開始連環調用工具，你隨手設的那個寬松輸出限制，悄悄把延遲和成本吹成了氣球。多數情況，補GPU不是解藥；先砍掉那些你原本無需執行的工作——多算的token、多余的調用、該小的模型沒變小、該重用的緩存晾在那里——效果才扎得深。
1. 先把該量的延遲指標量清楚
不先拆出時間花在哪，優化就是在盲調。端到端延遲好看，但根本解釋不清慢在哪。生產環境至少得盯住：請求排隊等了多久（queue time）、用戶看到第一個token要多久（TTFT）、生成每個token的間隔（inter?token latency）、輸入和輸出的token數，以及緩存命中率（prompt、檢索、響應緩存有沒有避開重復做功）、工具和檢索自身的耗時。別只看平均，P95、P99這種長尾延遲才最要命。高TTFT往往指向長prompt、慢檢索或排隊擁擠；生成token間隔慢則是模型過大、GPU過載、批處理配置不好或顯存吃緊的信號。不看這些，優化方向幾乎一定會跑偏。
2. 對著輸出token下狠手
生成token是延遲和成本里最容易捅掉的一刀。模型得逐個token順序生成，響應長度翻倍，時間就幾乎翻倍，賬單也毫不客氣地跟漲。從這幾件事做起：給max_tokens或最大生成長度綁上現實的上限；用戶不需要長文解釋就要求模型給簡潔回答；活用stop序列讓模型該停就停；別讓模型把用戶問題再復述一遍；用緊湊的JSON結構和更短的字段名；把多余的總結、免責聲明、重復上下文統統從輸出里剃掉；在產品UI里拆開“簡短答”和“詳細解釋”兩種模式，把選擇權交給用戶，而不是讓模型替所有人啰嗦。
這兩刀砍下去，常常比換一個所謂更快的新模型來得更實在。說到底，LLM推理優化不是比誰GPU多，而是比誰浪費的token少、誰排的隊短、誰讓緩存真正把重復勞動省下來。先量清楚、再砍干凈，你的GPU可能根本不用加。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
