開放模型 Token 並非全都一樣 | YC Paper Club

先撇開 François Chollet 的框架不談，本集節目的核心論點來自 Together AI 的 Dan Fu：在模型有效壽命內，推論所消耗的算力約為訓練的 12 倍，這使推論最佳化成為 AI 成本結構中最關鍵的槓桿。這場 110 分鐘的 YC Paper Club 課程，大部分時間其實是技術導覽，說明一個 Token 究竟如何被服務——預填與解碼分離（prefill/decode disaggregation）、KV-cache 路由、量化、GPU kernel 與編譯器——「12 倍」這個標題只佔開場幾分鐘。

四位實務工作者從不同角度拆解這套堆疊：Fu（Together AI 研究主管）談服務機制與量化；Jeffrey Morgan（Ollama 執行長）談為何名稱相同的開源模型在不同供應商手上表現不一；Joe Fiotti（Luminal 執行長）談等式飽和（equality saturation）編譯器；Liang Cheng（SGLang 核心開發者）談 RadixAttention 與混合式架構的統一記憶體池。讀者讀完應該能帶走：DeepSeek 服務經濟效益的具體數字、一套稽核推論供應商品質的框架，以及一個關於剩餘效能空間在哪裡的心智模型。

推論算力已是訓練的約 12 倍，DeepSeek 的毛利率就是證明

Fu 的開場論點是：業界的 benchmark 文化把重點放錯了。多數 NeurIPS 論文最佳化的是「等訓練 FLOPs」，但真正花掉的算力發生在推論端。DeepSeek 是唯一同時公佈兩邊帳目的實驗室，而依其數字——Fu 稱之為「舊資料」——訓練 DeepSeek-V3 約需 280 萬 H800 小時，服務則每天燒掉約 4.3 萬 H800 小時。換算下來，單一權重檔案每年花在推論的 FLOPs 約是訓練的 6 倍；若假設模型有效壽命兩年，則接近 12 倍。

經濟後果就是 Fu 說在演講前一天曝光時讓大家震驚的數字：DeepSeek 的隱含毛利率約 80%，靠的是推論端的創新，而非模型品質本身。他把這歸功於一整疊技術，並分成三層。

Fu 關鍵的診斷詞彙：預填是算力受限，模型 FLOPs 利用率約 50%；解碼則是記憶體受限，MFU「大概只有 5%」。每一個解碼步驟都必須把整個模型的權重從 GPU 記憶體載入到運算單元，才能產出一個 Token。這個不對稱正是解碼（而非預填）成為瓶頸、也是晶片創新集中之處的原因。

DeepSeek 公佈的服務指標，Fu 引用時稱之為「前一天才出爐」的 benchmark：

預填 150 萬對比解碼 1.4 萬的吞吐量差距，就是解碼主導成本的全部原因。96% 的快取命中率，則是將 KV cache 保留 72 小時換來的成果——Fu 也提醒這取決於工作負載：代理式程式開發的流量快取效果好，但「我媽三不五時就開一個全新的 ChatGPT 對話」完全產生不了可重用的快取，只能反覆預填。

「如果 Jensen Huang 保證給你 2 兆 FP8 FLOPs，你拿不到那個數字。差得遠了——大概只有一半。到了解碼階段更慘，可能只有 5%。」

一個 Token 的旅程：路由、分詞、排程、預填、解碼

Fu 把請求的生命週期從頭走到尾。請求先經過 Cloudflare 與 DNS，進到有數千顆 GPU 的資料中心，第一個決策是請求層級的路由——交給哪一個 GPU 副本。有別於傳統的輪詢負載平衡，這裡的路由必須考量 KV-cache 的所在位置：同一個請求送到同一顆 GPU 就能重用先前的計算，因此路由器解的是一個負載平衡與快取區域性性（cache locality）的聯合問題。

分詞比表面看起來複雜，因為牽涉工具呼叫。模型本身「沒有能力上網搜尋」——是外層排程層把可用工具清單傳進去，模型發出呼叫，而這一來一回是否正確，正是各家供應商表現分歧的主要來源（Morgan 稍後會接續這個主題）。接著是排程器迴圈，批次大小的選擇在此拿吞吐量換延遲。Fu 以 Google Gemini 的搜尋結果為例，說明它很可能採用了雙軌排程：第一個回應極快，後續對話較慢，暗示後端區分了不同的請求類別，甚至用了不同的模型。

預填與解碼之後通常會被拆到不同的 GPU 上，使用不同的 kernel 與平行化策略。Fu 列出六個加速槓桿——kernel、分離、平行化、路由、投機解碼、量化——並把細節集中在其中三項。

Kernel 最佳化正從人工調校轉向代理驅動的搜尋迴圈

過去，kernel 最佳化意味著「一群非常聰明的人死命地做」——手工調校每一個 layer norm、RMS norm 與 softmax，因為它們的運算強度低，會拖垮端到端的利用率。Together 的內部專案目前叫 Together Compiler（Fu 坦承它「其實不是編譯器」，之後會改名），改採代理迴圈，針對真實的生產流量來最佳化 kernel。Fu 說這個迴圈必須由實際工作負載驅動，因為程式開發與聊天流量啟動的 kernel 不一樣；他形容這「幾乎是推論領域 RSI 迴圈——遞迴自我改進——的雛形」。

平行化方面，Fu 強調的轉變是輝達從 8 顆 GPU 擴大到 72 顆 GPU 的 scale-up 網域（GB 機櫃世代）。以往模型只要切分超過八份，就會落到頻寬慢得多的路徑上。如今 72 顆 GPU 以高頻寬互連，MoE 的專家可以一顆 GPU 放一個，既拉高服務量，也把運算強度救回來——一個專家服務大量 Token，看起來又像是一個大型矩陣乘法。代價是可靠性：72 顆 GPU 的副本只要壞一顆，若沒有妥善的補救機制，可能一次損失 72 顆 GPU 的算力，Fu 說讓這件事具備韌性是一筆重大投資。

量化先是品質管控問題，才是演算法問題

模型以 BF16 訓練，每個引數兩個位元組；一個 3 兆引數的模型就是 6 TB，而頂規 B300 只有 280 GB。量化到 8 位元或 4 位元在演算法上早已成熟——「幾百、幾千篇論文」——但 Together 把它當成使用者體驗風險來處理，因為客戶是拿這些模型來創業的。他們的流程是：任何版本發布前先在內部 dogfooding、由每一次歷史故障案例累積出的數百個代理式測試案例、標準 benchmark（Fu 指出 MMLU 這類已經飽和在 90% 以上，所以掉一分就代表真的出事了）、針對 activation 的逐層 KL 散度，以及一個「flappy bird 迴圈」——讓模型反覆寫同一款遊戲，如果量化弄壞了什麼，「突然間 flappy bird 就不會拍翅膀了」。

Fu 明確表示 Together 避開需要後訓練微調的量化配方，因為沒有原始訓練資料，模型「會忘掉東西」。他們的做法是免訓練，把校準資料與一套已發表的方法 Scale Search 結合。

案例研究：MiniMax 用自家配方把 M3 模型量化到 NVFP4 時卡關，品質相較 FP8 原版有可量測的落差。Together 的配方達到了與原版模型相當的表現，讓 MiniMax 能服務更多 Token，「把從訓練模型到有利潤地服務模型這一圈補了起來」。

同一批開源模型，不同供應商表現不同——有時差距比開源對閉源還大

Morgan 的核心論點：服務「同一份」開源權重時，最好與最差供應商之間的差距，比開源模型與閉源模型之間的差距還大。他引用 2024 年一篇測試 31 個 Llama 端點的論文，發現有些端點的表現更接近 GPT-3.5，而不是其他號稱權重相同的 Llama 部署。對開發者而言，這意味著「開源模型的 Token 並不是每個都一樣」，而這個問題在代理式工作負載下會複合放大：每次呼叫 10% 的偏差，在一個 15 步的程式開發任務上，可能導致高達 79% 的錯誤結果。

Ollama 在 2023 年起步，原本是讓能跑在筆電或單張 H100 上的模型在本機執行的工具，後來隨著 Kimi、GLM、MiniMax 推出 5,000 億到 1 兆引數的模型，也推出了雲端服務。Morgan 說它已成為美國與歐洲最大的開源模型獨立雲端之一，且財星 500 大企業中有很大比例部署了 Ollama。它的雲端會路由到多家供應商，這正是品質稽核之所以重要的原因。

他列出偵測工具組，也誠實說明各自的取捨：

Morgan 點出一個結構性解方：實驗室應該把自己實際用來服務的那套堆疊一起釋出，而不是隻給權重加上由另一個應用團隊寫的範例程式碼。他舉 DeepSeek 前一天發布的 DeepInfer 為範例——拿權重跑在一致的堆疊上，最好還能達到每 GPU 小時 38 美元那個數字。他也提到，實驗室越來越常自行發布量化版本，這與過去由第三方在模型發布後自行量化、以便塞進 MacBook 的時代正好相反。他的前瞻押注是：路由的區分會變成「本機對雲端」，而不只是「供應商對供應商」，因為像 Recursive 的 Flint 這類能力夠強的本機模型，已經能在 M5 MacBook 上執行。

「一顆爛蘋果可以壞了整籃……你的客戶體驗可能就落在最低共同標準上。」

用搜尋取代手寫規則的編譯器

Fiotti 的 Luminal 從工具鏈端切入同一個成本問題。他的論點是：輝達四兆美元的市值，很大一部分建立在 CUDA 是一個支援完善的軟體生態繫上，而把模型對應到複雜硬體這件事，至今仍大致未解。傳統 MLIR 風格的編譯器，人力需求會隨模型、後端與資料型別的數量呈指數成長——「一個 500 人或 1,000 人的編譯器團隊。而且就算這樣，編譯器還是很不完美。」

Luminal 的做法是透過 egglog 引擎進行等式飽和，Fiotti 稱這是該技術至今最大的工業應用。模型被拆解成大約 14 到 15 個原始運算（加、乘、求和）——完全沒有矩陣乘法這個運算；一個矩陣乘法會變成廣播式乘法加上求和縮減。Fiotti 形容這個 IR「在 PyTorch 層面完備，但不是圖靈完備」：任何能用 PyTorch 表達的模型都能被吃進來，但受限的運算集合避開了萊斯定理（Rice's theorem），因此能對記憶體搬移做解析式推理，並以 roofline 模型進行剪枝。

機制是這樣：非破壞性的重寫規則（用 Lisp 寫，因為引擎作者喜歡 Lisp）會不斷擴張 e-graph 直到飽和，然後抽出具體程式、編譯，並在真實硬體上計時。Fiotti 抱持「苦澀教訓」的立場：最好的成本模型就是不要成本模型——對現代 GPU 而言，實測剖析勝過解析建模。他說一次完整前向傳遞的剖析迭代不到 10 毫秒，所以一秒內能跑約 1,000 次，而搜尋只探索整個空間的「百分之一的百分之一」，目標是找到一個表現達全域最佳 99% 的區域性最佳解。編譯時間是刻意的取捨：推論客戶不在乎編譯要花一天，只要能換來在數百萬 GPU 小時上 1% 到 10% 的執行期改善。

這個多層級 IR 明確地為執行緒、warp、執行緒區塊、GPU 與節點等層級建模，讓編譯器能在同一次前向傳遞中混用 cuBLAS 的主機層級呼叫、CUTLASS／ThunderKittens 的執行緒區塊運算，以及融合式巨型 kernel。Fiotti 也指出，巨型 kernel 對大型模型未必總是最佳解。Luminal 每月在輝達、AMD、TPU、Trainium 與其他 ASIC 上執行約 80 到 90 兆個 Token，全公司只有八名員工，並宣稱已「解決編譯器公司的變現難題」——考量到編譯器新創的墳場，這相當罕見。

RadixAttention 與混合式架構的統一記憶體池

Cheng 的演講從 2023 年底的一個洞察談起 SGLang 的起點：代理式工作負載會共用很長的字首（系統提示、分岔出的子代理），並穿插簡短的工呼叫提示，而當時沒有任何引擎能有效率地重用字首。RadixAttention 把代理的上下文以 radix tree 的形式管理在引擎記憶體中，共用字首，並在記憶體吃緊時逐出未使用的葉節點，同時進行快取感知的請求重排，讓穿插的請求不會互相逐出。

2024 年的 v0.2 版本把這套機制推廣成完整引擎，支援從 Llama 8B 到 405B。Cheng 特別強調重疊排程（overlap scheduling）：當 GPU 相對於 CPU 越來越快，裝置與主機之間的同步就變成明顯的空氣泡，因此 SGLang 把同步延後一輪，並預先準備下一個批次。他說這在 Hopper 上只比原生排程快約 1.1 到 1.5 倍，但在 Blackwell／GB 系統上可達約 2 倍，而 DeepSeek 的 DeepInfer 也採用了同樣做法。

快取階層橫跨 GPU 記憶體（L1）、主機記憶體（L2）與儲存（L3），Cheng 說在他們的實驗中，這讓每個輸出 Token 的耗時降低了 56%。更難的問題是混合式架構——滑動視窗注意力加上 KDA 這類遞迴狀態。要在位置 10 命中快取，必須同時具備到位置 10 為止的完整注意力 KV、以及回溯到位置 7 的滑動視窗 Token、以及恰好停在位置 10 的遞迴狀態；若分開管理這些池子，共用就會破功。Cheng 用算術說明這件事為何重要：快取命中率從 95% 提升到 99%，運算成本是降為五分之一，而不是降 5%。

SGLang 的答案是：以語意 Token ID 為鍵的統一 radix tree，協調各元件的比對與逐出規則；再加上統一的實體記憶體池，從同一個位元組粒度的池子裡配置完整 Token、視窗與遞迴狀態所需的記憶體，而不是預先按固定比例切分——這是必要的，因為不同使用者的上下文長度相差好幾個數量級。碎片化則靠壓縮（compaction）處理：低延遲的記憶體複製 kernel 重新打包實體記憶體、重對映虛擬頁面 ID，而不去動到未被搬移的頁面。Cheng 也提到 Miles，這是 Redux Arc 與 SGLang 的聯合專案，把推論放進 RL 訓練迴圈中做 rollout。

四路人馬從不同方向收斂到同一批瓶頸

把四場演講合起來讀，它們描述的是同一個系統在解碼步驟上承受壓力。Fu 把它量化出來（MFU 5%、每 GPU 每秒 1.4 萬 Token），Fiotti 在編譯器層出手，Cheng 在記憶體管理層出手，Morgan 則在量測層出手——因為如果供應商悄悄讓量化或工具呼叫變差，省下來的成本會在品質上蒸發。尚未解決的張力在於驗證：Morgan 最便宜的偵測方法（log probe、請求形態觀察）能抓到漂移，卻抓不到絕對品質；而能抓到糟糕量化的方法（完整評測）又太貴，無法持續執行。Fu 的答案是供應商自己做 dogfooding；Morgan 的答案是客戶專屬的私有評測，讓供應商無法針對它爬山最佳化。兩者都無法擴充套件到一個有數百家推論供應商的市場。兩個值得追蹤的發展：實驗室是否會跟隨 DeepSeek DeepInfer 的先例，把服務堆疊與權重一起釋出；以及 72 顆 GPU 的 scale-up 網域，是否會成為 MoE 服務的預設單位——儘管它有單點失效的經濟代價。