第 8 章 — 效能、服務、成本的最佳化

發佈於: 2026-04-21 最後更新於: 2026-07-05 版本: 1
第 8 章 — 效能、服務、成本的最佳化

第 8 章 — 效能、服務、成本的最佳化

LLM Primer V: Building Real-World LLM Applications 章節走讀的最後一篇。這一章把生產 LLM 經濟學當分層紀律處理 — 最便宜的呼叫是那個從沒發生的,下面每一層是讓下一次呼叫變便宜的那一層。


這一章為什麼存在

每一種值得擁有的生產性質都用 token、延遲或算力付它自己的帳。冗餘要花第二次供應商呼叫。驗證要花一次分類器 pass。護欄在每個 prompt 上多花 token。追蹤要花儲存跟匯出頻寬。人工審查要花小時。這些都不免費,而系統一到生產環境,壓力就不是加能力、是把已經有的能力用「企業願意繼續付得起」的成本維持下去。第 8 章走過那些成本住的層,以及在不回歸品質的前提下把成本降下來的技術。框話是刻意的:一個「削掉幾個百分點成本、加了幾個百分點錯誤率」的技術不算贏,而紀律是刻意地把錢花在「移動使用者可見的品質與可靠性」上、拒絕花在其他地方。

一句話總結:最便宜的呼叫是那個從沒發生的(語意快取)、下一個是對著「夠用的最小模型」發的那個(router),而底線是在推論伺服器裡由 KV cache、連續批次、投機解碼設定的。

8.1 語意快取 — 那個從沒發生的呼叫

語意快取把一個重複的問題轉成一個已儲存的答案,即使措辭改了。機制是把進來的請求嵌入、在按 tenant 跟角色劃範圍的 bucket 裡查近鄰,如果某個近鄰在相似度門檻內、也在新鮮度窗口內,就把已儲存的答案送出去。做對了它會把一次模型呼叫從請求路徑上整個移除。做錯了它會把別的 tenant 的答案送給當前使用者、或送出昨晚剛改的政策下的舊答案。正確性依靠複合鍵 — tenant 加角色加模型加 prompt 版本,不只是查詢嵌入 — 也依靠週期性 refresh sweep 抓漂移。單看命中率是錯的目標;「經驗證正確的成本加權命中率」才是對的,因為在便宜請求上高命中率、在昂貴請求上低命中率,加的價值比反過來少。

8.2 速率限制與動態模型路由

每請求限制對 LLM 流量來說是錯的形狀,因為請求成本在艦隊裡橫跨兩個數量級。Token bucket 跟兩階段預留-結算的美元預算取代「每請求計數」;分層預算 — 使用者、tenant、應用、全域 — 在每一層都封住爆炸半徑。路由接著挑「對每個請求都夠用的最小模型」。一個分類器 — 簡單案例用啟發式、比較難的用便宜的 LLM 呼叫 — 給請求貼標籤,並派給成本分層艦隊,配一條有驗證的 fallback 鏈:先 SLM、驗證失敗或信心不足升中階、再往前沿升、最下面墊確定性預設值。Router 本身帶著信任意涵 — 它是攻擊者會嘗試操縱的一個決策面 — 而它屬於前面章節建的「被追蹤、被評估、被守護」的封套裡。

8.3 推論伺服器裡面

在應用下方,推論伺服器是最後一個數量級的成本節省住的地方。PagedAttention 把 KV cache 當虛擬記憶體對待,好讓長短請求混合的批次不會為了最長的那一個浪費連續記憶體。連續批次靠「把新請求接進正在跑的批次、不等所有請求都跑完」讓 GPU 在異質請求長度下都保持忙。投機解碼用一個小的 draft 模型猜 token,由目標模型平行驗證,乘上 draft 猜對的那些 token 的有效吞吐。前綴快取存共享靜態 prompt 的 KV 狀態、跨使用者共用,system prompt 付一次錢、被重用。量化在多數任務上不影響品質的前提下把權重精度降下來。LoRA 服務讓一個基底模型服務多個微調變體,幾乎跟只服務基底模型一個價錢。蒸餾把模型本身縮小。這些最佳化互相疊,而它們的累積效果就是讓「主權自架部署」在 2026 年變得財務上可行的東西。

值得記住:能力不變、LLM 定價卻下降一個數量級,這不是魔法。它是供應商端這些最佳化的累積效果,而應用端的快取跟路由做對後,還能再讓節省疊上兩三倍。

第 8 章收在哪裡、接下來會怎麼走

第 8 章收尾第五卷。這本書建的單一應用工程 — 確定性包裝、模型呼叫、檢索管線、代理迴圈、評估套件、追蹤層、安全姿態、服務經濟 — 是後續組合的基本單位。第六卷《擴展 AI 系統》(Scaling AI Systems)把那個單位當成給定的、問下一組問題:當單一組織在共享的推論叢集上跑一百個這種系統時會發生什麼、全艦隊的策略引擎怎麼跨它們授權、當工作負載陣發、底層硬體稀缺時,容量規劃會怎麼改,以及這一章只勾勒的推論伺服器最佳化,一旦成為承載面就會變成的深工程。第六卷走機制;第五卷立起機制會用的詞彙。


第五卷在這裡結束。系列的下一卷,LLM Primer VI — 擴展 AI 系統(Scaling AI Systems),接手第 8 章只勾勒的推論與基礎設施工程,並把這一卷建起的「應用形狀單位」當成 fleet 規模組合的基本粒子。


下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。