成本與延遲的現實
兩個數字決定一個大型語言模型功能能否在真實使用中存活下來:每次呼叫花多少錢、以及要花多久。成本隨token而增長——包含你送出的 token 與生成的 token——所以一段囉嗦的提示或一塊巨大的檢索內容,可能悄悄讓你的帳單翻倍。延遲則由首字延遲(time to first token)主導,接著是生成速度。成本與延遲最佳化就是在不削減(可量測的)品質下,把這兩者都砍下來的手藝。
总成本等于输入词元数乘以输入单价,加上输出词元数乘以输出单价——而输出词元通常更贵。
最佳化技巧
- 依任務為模型選對尺寸:把簡單請求送給小而快的模型,把又大又貴的留給真正困難的請求(就是第二篇講的路由器)。
- 精簡提示:更短的系統提示、更少的 few-shot 示範,以及更精簡的檢索內容,都會在每一次呼叫上削減輸入 token。
- 限制並串流輸出:設定合理的最大 token 上限,並使用串流,這樣即使總時間沒變,感受到的延遲也會下降。
- 把彼此獨立的呼叫批次化、平行化,而不是一個接一個地等。
自回归循环示意图:每次生成一个词元并将其作为输入反馈。
快取:不要付兩次錢
快取大型語言模型回應是槓桿最高的最佳化,因為最便宜的呼叫就是你從來不必發出的那一次。完全相符快取為一個完全相同的請求儲存答案——對重複查詢非常理想;語意快取依意義來比對,當新問題和先前的某個問題夠接近時,就回傳已儲存的答案;而提示快取(一種供應商功能,相關於 提示快取(prompt caching))則讓一段又長又穩定的前綴——例如一大段系統提示或共用內容——的成本在許多次呼叫之間被重複利用。每一種都有新鮮度的取捨:絕不要快取任何必須反映即時資料的東西。
選對尺寸:小型語言模型
更大不一定更好。一個小型語言模型(small language model)——幾十億而非幾千億參數——一旦你用自己的資料微調,就能在狹窄任務上追上巨型模型,而每次呼叫只花零頭、跑得快得多。有兩種技巧能帶你到那裡:蒸餾(distillation),讓大模型的輸出去訓練一個小模型來模仿它;以及量化(quantization),把權重縮到較低精度,讓模型能裝進更便宜的硬體而幾乎不損失品質。紀律就是選對尺寸:使用仍能通過你評測的最小模型。
对数-对数图:损失随模型规模增大而下降,收益递减。
裝置端與開源生態
夠小的模型可以直接在裝置本身上執行——一支手機或一台筆電——這意味著每次呼叫零成本、即時回應,而且資料永遠不離開使用者。代價是能力上限,以及把模型送上各式各樣硬體的負擔。在這一切背後的是開源大型語言模型生態:你可以下載、微調,並用服務框架(serving frameworks)自行架設的開放權重模型。自行架設買到的是控制權、隱私,以及大規模時可預測的成本——交換的是你得自己扛起維運、GPU 與正常運行時間。