大模型推論降本：不是裁員，是排隊

不少人降本第一反應是裁員，模型團隊的第一反應是砍算力帳單。這兩件事裡有 80% 重疊。今天說下推論側最實用的三個開關，都是我們這類小團隊真正用過、能寫進月度報表的。

開關一：KV Cache，把重複計算變成查表

生成下一個 token 時，模型要看前面所有 token 的 Key 和 Value。樸素實現是每步重算，成本隨序列長度平方漲。KV Cache 把這些算好的結果存下來，後續步驟直接查表，單步開銷從 O(n²) 降到 O(n)。

實操上要注意兩點。第一，顯存不是加多少就行，70B 模型開 8K 上下文，單卡 80G 可能裝不下 KV Cache，這時優先砍併發而不是砍上下文。第二，多輪對話的 cache 命中率取決於會話管理策略，把會話 key 設成 session_id 比設成 request_id，命中率能從 30% 提到 80% 以上，帳單直接砍掉一截。

開關二：量化，精度換位元組的明碼標價

INT8 比 FP16 省一半顯存和頻寬，INT4 再省一半。聽起來簡單，實際部署有個坑：量化損失不均勻。權重層影響小，注意力裡的 softmax 附近影響大，低比特下長尾任務（數學、程式碼）掉點比平均指標兇。

我們的做法是分層決策：主幹權重 INT4，輸出層和注意力投影保留 INT8。70B 模型全 INT4 能跑在 48G 卡上，這套混合方案掉點在 0.5 個百分點內，業務方無感。省下的不是幾張卡，是能多塞 2 倍併發。

開關三：批次處理，把碎請求拼成整塊

推論 GPU 利用率低，十有八九是請求太碎。單條請求佔 GPU 時間片短，啟動和切換開銷佔比高。連續批次處理（continuous batching）讓新請求隨時插入正在跑的批次，把 GPU 佔滿。

判斷值不值有個簡單標準：你的請求 P95 延遲要求。如果業務能接受 2 秒內返回，批次處理是純賺；如果要求 200 毫秒內，批次處理可能把 P95 推上去，這時不如加卡。我們客服場景 P95 要求 1.5 秒，開批次處理後 GPU 利用率從 34% 拉到 71%，單 token 成本降了 40%。

怎麼組合這三個開關

順序很重要：先開 KV Cache（零損失、純賺），再上量化（有損失、需要評測），最後調批次處理（有延遲代價、看業務容忍度）。三個都做完，小團隊的推論帳單通常能砍到原來的三成。剩下的錢別急著投硬體，先看看有沒有請求可以用小模型或規則兜底，那才是更大的頭。