第 15 章 — 無伺服器 API 對比專屬基礎設施

《LLM Primer VI:擴展 AI 系統》章節走讀的第十五篇。這一章把損益兩平的算術擺上桌,接著替那個對大多數團隊而言決定答案的平台工程項目命名。

這一章為什麼存在

第 14 章讓團隊拿到一張乾淨的圖 — API 帳單是由什麼組成 — 也留下一絲懷疑:它應該可以更便宜。自然的下一個問題是團隊到底該不該按 token 付錢。替代方案是把推論搬回自家、用前面章節描述的堆疊跑一顆開源權重模型、改用 GPU 小時計費。這項取捨有一個乾淨的損益兩平點。不乾淨、且大多數團隊低估的,是自架這一側帳目上不出現在 GPU 帳單上的每一項 — 平台工程、資安修補、模型升級編舞、節點掉出機群時凌晨三點的電話。第 15 章認真看待兩側,並推導出自架什麼時候是對的答案。

15.1 損益兩平公式很乾淨,大部分是誘餌

GPU 每小時產出 throughput × utilization × 3,600 個輸出 token。它每一百萬 token 的成本是 (gpu_hourly / tokens_per_hour) × 1,000,000。相對於 API 的損益兩平點就是那個數字等於 API 每百萬定價的時候。一顆 H100 上 FP8 的 70B 模型,以每小時 3 美元、每秒 800 個 token 聚合、60% 利用率跑,大約落在每一百萬輸出 token 一美元。最前沿 API 收 15 美元。表面上看是 14 倍的節省 — 一個財務會愛、卻漏了第二條更大的項目的自架論點。損益兩平也取決於利用率;低於 20 到 30% 利用率時,自架的每百萬成本會爬過 API 費率,GPU 反而比原本要取代的方案還貴。利用率本身又是流量形狀、自動擴縮品質、以及團隊能不能把多個工作量塞到同一機群上的函式。

15.2 平台工程是決定這樁生意的項目

GPU 帳單是比較小的那一半。更大的那一半是把機群保持運行的團隊:引擎、驅動程式、編排、自動擴縮、可觀測性、資安。API 團隊隱含地透過每 token 定價付這筆成本;自架團隊則以人頭付。有一個實用的經驗法則:單一服務 GPU 機群 — 一到兩個模型變體、自動擴縮、可觀測性、值班、每季升級 — 大約需要一位全職平台工程師,加上一小部分 SRE。更多元的機群 — 好幾個引擎、好幾個模型、多租戶排程 — 則需要二到四位。以每人全負擔 30 萬美元計,年度平台帳單是 30 萬到 120 萬美元。自架回本的每月流量門檻,大約落在 2 億到 10 億個輸出 token 之間。低於那個,工程開銷會壓過 token 節省,團隊該留在 API。高於那個,節省勝出。平台工程也是階梯函式、不是平滑曲線:第一位聘用把機群拉起來、第二位是因為第一位撐不了週末值班、第三位是機群長成多區域時。

15.3 現實的姿態是混合的,而路由器是關鍵

最乾淨的決定 — 全 API 或全自架 — 對一個進生產一年以上的團隊而言鮮少是對的。穩態可預測工作量(隔夜批次、排程報表、分類佇列)剛好塞進規劃好的專屬容量。爆量工作量(病毒式尖峰、工單洪流、新一批使用者上線)需要 API 的彈性。嚴延遲工作量(互動式補全、語音)受益於一個同區部署的專屬部署。無延遲工作量(隔夜擴充、重新索引)受益於半價的批次 API。撐得起混合的架構是應用邊界上的一個路由器,它按延遲預算、複雜度、以及當前後端利用率分類每一個請求,然後派到最便宜、又能滿足 SLA 的後端。更精緻的路由器還會做 API 內的模型路由(簡單查詢用便宜模型、複雜的用最前沿、需要推理的用推理層)。第二階效益是選擇權:工作量可以靠改路由器策略跨過邊界,不用改應用程式碼。而且專屬那一側常常只有在第二個工作量 — 原本會走 API 的那個 — 搭便車到已經付過錢的 GPU 上時,才會回本。以單一工作量評估專屬的團隊通常永遠不會搬;以工作量組合思考的團隊會搬,而且省下錢。

第 15 章鋪陳出來的東西

第 15 章替代理引入的一類工作量命名,它既不符合「API 呼叫」、也不符合「模型服務」:LLM 生成程式碼的執行環境,依代理需要的隔離與套件彈性,落在無伺服器函式、microVM(Firecracker、gVisor)、或 WASM 沙箱上。第 16 章替這一卷收尾,列出兩側姿態都適用的降本動作目錄:智慧型模型路由、應用層的上下文壓縮、批次 API、語意快取 — 那些能複利成上個月帳單三分之一到一半的動作。

下一篇 — 第 16 章:生產環境的降本策略。把上個月帳單變成下個月節省的複利動作。