一個 token 的成本

🚧受記憶體限制的解碼#

等待的不是運算，而是頻寬

模型每產生一個 token，都要從記憶體重新讀取幾乎全部權重。一個 70B 模型以 16 位元載入，光是權重就約 140GB，因此逐一處理請求時，記憶體頻寬會比運算核心更早碰到上限。所以降低推論成本的方法，大多歸結為每讀一次拿到更多 token，或減少需要讀取的位元組數。

預填充與解碼#

兩個階段的瓶頸不同

讀取提示詞的預填充階段一次處理全部輸入 token，因此瓶頸在運算量。寫出回答的解碼階段逐一產生 token，每次都要讀取權重與 KV 快取，因此瓶頸在記憶體。第一個 token 出現前的時間主要由預填充決定，之後 token 之間的間隔則由解碼決定。這正是 DistServe、Splitwise 等研究提出把兩個階段放到不同 GPU 上執行的原因。

🛠️服務技術#

繞過同一個瓶頸的三條路

不改模型、在服務端降低每個 token 成本的方法主要有三種。批次處理用一次讀取的權重同時替多個請求產生 token，量化直接減少要讀取的位元組數，推測解碼則透過一次驗證確定多個 token。批次處理與推測解碼不會改變模型的輸出分布；量化則以些許品質換取記憶體空間。

連續批次處理與 KV 快取#

讀一次，分給多個請求

連續批次處理不等某個請求結束，而是在每個解碼步驟把新請求補進空位，用一次權重讀取同時替多人產生 token。這時限制批次大小的，是每個請求不斷累積的 KV 快取。2023 年的 vLLM 論文指出，現有系統浪費了 KV 快取記憶體的 60%~80%，並透過以分頁管理快取，在相同延遲下把吞吐量提高到 2~4 倍。

量化#

降到 8 位元，要讀的位元組減半

把權重從 16 位元降到 8 位元，每個 token 要從記憶體讀取的量就減半，降到 4 位元則只剩四分之一。GPTQ、AWQ 這類只壓縮權重的方法，對以記憶體為瓶頸的解碼立即見效；連激活值也降到 8 位元的 W8A8，還能加快以運算為瓶頸的預填充。位元數越少，品質可能越差，因此位元數要用實際服務的任務重新評估後再決定。

推測解碼#

小模型起草，大模型一次驗證

小型草稿模型先提出幾個 token，主模型再用一次前向傳播把它們一起驗證。由於只保留被接受的 token，輸出分布與主模型單獨產生時相同。2023 年 Google 研究人員指出，在 T5-XXL 上不改變輸出即可加速 2~3 倍；實際效益取決於草稿 token 被接受的比例。

💸計算 token 成本#

吞吐量翻倍，成本減半

如果自行部署服務，一個 token 的成本等於 GPU 每小時的費用除以這一小時內產生的 token 數。服務技術與模型架構降低成本的方式，是提高吞吐量，而不是改變 GPU 的價格。不過，即使 token 單價下降，像 AI 代理那樣一次任務要多次呼叫模型的產品，呼叫次數可能成長得更快，總帳單仍可能變大。

Token 稅#

推論成本計入營業成本

傳統 SaaS 多服務一位使用者的成本很低，而 LLM 產品每個請求都要耗用 GPU 時間。因此推論成本會計入營業成本；在固定費率方案下，用得最多的使用者就是成本最高的使用者。唯有清楚單一請求的輸入 token、輸出 token 與快取命中率，才能算出方案是否賺錢。

快取命中折扣#

不必重讀的提示詞比較便宜

如果每個請求開頭都帶著同樣的系統提示詞或長文件，重複使用這部分的 KV 快取，就能省下相應的預填充。主流模型 API 對命中快取的輸入 token 收費低於一般輸入，原因就在這裡。快取只會命中從開頭起完全一致的部分，所以只要把固定內容放在前面、變動內容放在後面，命中率就會不同。

📐模型架構#

在設計階段減少讀取量

如果說服務技術是讓既有模型跑得更便宜的方法，模型架構就是從一開始減少每個 token 需要讀取與運算的量。混合專家（MoE）減少每個 token 使用的參數，MLA 減少每個請求累積的 KV 快取。DeepSeek-V3 同時採用兩者，以 FP8 混合精度訓練，並以 FP8 格式公開權重。

混合專家（MoE）#

671B 中每個 token 只用 37B

DeepSeek-V3 共有 671B 參數，處理每個 token 時只啟用其中 37B。每個 token 的運算量與需讀取的權重縮減到啟用參數的規模，但由於無法事先知道會呼叫哪些專家，全部 671B 仍須載入記憶體。MoE 以更多記憶體容量換取運算上的節省，隨之而來的是把專家分散到多張 GPU 上的設計。

MLA#

壓縮 KV 快取，擴大批次

多頭潛在注意力（MLA）不直接儲存鍵與值，而是把它們壓縮成較小的潛在向量再放進快取。DeepSeek-V2 技術報告寫道，採用 MLA 的這個模型，KV 快取比 DeepSeek 67B 小 93.3%。單一請求占用的記憶體變少，同一張 GPU 就能容納更多請求與更長的上下文。

🧑‍💻服務工程師#

負責壓低 token 成本的職缺

隨著推論成本直接左右產品毛利，在打造模型之外，讓模型跑得又便宜又快的工作變得重要。挑選並調校 vLLM、SGLang、TensorRT-LLM 等服務引擎，讓同一張 GPU 產出更多 token，就是這個職缺的成果。本圖的多數分支，正是這個職缺每天調整的設定值。

服務工程師的工作#

從測量負載到解碼設定

第一步是測量工作負載，判斷瓶頸在預填充還是解碼，要守住的延遲指標是第一個 token 的時間還是 token 之間的間隔。接著調整批次大小、KV 快取的記憶體配置、量化位元數以及是否啟用推測解碼，並確認品質沒有下降。每改動一項設定，都要把吞吐量、延遲與品質一起重新測量。