辦公助手、Skill 執行器、知識庫問答 —— 每一次呼叫都付兩份錢：一份是帳單，一份是訊噪比。兩者都由你送出去多少決定。本文把檢索、去噪與壓縮前移到本地模型之後會發生什麼，連同算式一起寫清楚；每一個假設都標註來源。
Bestom 工程筆記 —— 由我們自己的平台與系統工程師基於端側推理主機的內部工作整理。所有數字都帶來源標籤：[實測] 本次真跑，[公開] 官方價目或廠商公開實測值，[假設] 可掃描參數，可替換成你自己的值，[推導] 由前三者算術得出。本文採用的規模是 30 人 × 22 個工作日 × 每人每天 30 次互動 = 每月 19,800 次請求。
沒有一件是讓模型變聰明。三件都是關於「讓模型讀什麼」。
一次回答不過幾百 token，而偷懶拼出來的提示詞是幾萬。按 pro 檔價目，輸入側未命中 4.50 元/百萬 token、命中 0.15 元，輸出 13.50 元；而命中快取比未命中便宜 30×。真正的槓桿從來不是回答。
如果任務真正需要的是 2,000 個 token，而這次呼叫帶了 70,400 個，那麼模型讀到的東西只有 6.2% 是相關的。其餘部分不只是花錢 —— 它還給模型提供了抓錯段落的機會。成本與準確率在這裡同向，這種情況不多見，值得利用。
檢索、去重、摘要、前綴穩定化，都不需要旗艦模型。一台解碼速度 102.01 tok/s 的裝置（3B 模型在端側 AI 加速卡上的公開實測值）能在數秒內產出幾百 token 的精煉上下文。本地這一趟你付出的是時延，不是錢。
圖 1 —— 每一步發生在哪裡。跨出網路邊界的，只有精煉後的上下文。
同一個知識庫、同一批問題、同一個團隊，只有編排方式不同。雲端費用按 pro 檔計價；端雲協同方案還要算上自己的硬體。
| 方案 | 每輪上下文 | 輪次 | 單次輸入 | 月輸入量 | 雲 + 本地 / 月 |
|---|---|---|---|---|---|
| B1 —— 無編排 | 32,000 tok | 2.2 | 70,400 tok | 1,393.9 M tok | 6,078 元 |
| B2 —— 雲端側 RAG | 8,000 tok | 1.8 | 14,400 tok | 285.1 M tok | 1,372 元 |
| P —— 端雲協同 | 4,000 tok | 1.4 | 5,600 tok | 83.2 M tok | 503 元 |
B2 才是誠實的比較對象。拿一個好設計去比「完全沒有設計」，得到的數字好看但不能說明任何問題。所以下面的結論性數字，一律是對雲端側 RAG（也就是多數團隊已經在跑的做法）而言。
圖 2 —— 每月總成本（雲端 + 本地硬體）。端雲協同排在最下面，因為它是最低的那一條。
四個機制互相耦合，貢獻度不能簡單相加。有意義的是「其餘三個不變、單獨關掉某一個」時多花多少錢。
| 機制 | 關掉後成本 | 佔總貢獻 |
|---|---|---|
| 穩定前綴 —— 快取命中率 10% → 65% | +163 元/月 | 32% |
| 上下文壓縮 —— 8,000 → 4,000 tok | +139 元/月 | 27% |
| 本地分流 —— 25% 請求本地閉環 | +112 元/月 | 22% |
| 輪次收斂 —— 1.8 → 1.4 輪 | +96 元/月 | 19% |
結論是反直覺的。最大單項貢獻不是上下文壓縮，而是快取命中率：32% 對壓縮的 27%。因為命中快取的輸入比未命中便宜 30×，讓提示詞前綴位元組穩定，比讓它變短更划算。只盯 token 數量的團隊，把更大的那一半留在了桌上。
壓縮比是最容易在你的環境裡失真的假設，所以這裡掃描而不是斷言。注意收益不成正比：第一次減半買到的東西，遠多於最後一次。
| 每輪上下文 | 相對 B2 壓縮比 | 相關度 | 成本 / 月 | 相對 B2 節省 |
|---|---|---|---|---|
| 2,000 tok | 4.0× | 100.0% | 433 元 | 68.4% |
| 3,000 tok | 2.7× | 66.7% | 468 元 | 65.9% |
| 4,000 tok —— 建模取值 | 2.0× | 50.0% | 503 元 | 63.3% |
| 6,000 tok | 1.3× | 33.3% | 572 元 | 58.3% |
| 8,000 tok —— 不壓縮 | 1.0× | 25.0% | 642 元 | 53.2% |
| 16,000 tok | 0.5× | 12.5% | 920 元 | 32.9% |
即便把本地壓縮這一步完全關掉、上下文退回 B2 自己的規模，本地分流與輪次收斂仍然撐起大約一半的節省。這個方案不是把寶押在激進壓縮上。
端側編排做的是 token 級的文字工作：檢索、排序、摘要。這是 NPU 能做的最便宜的一類事。
| 端側模型 | 解碼速度 | 是否勝任編排 |
|---|---|---|
| 215.86 tok/s | 0.5B —— 意圖路由、打標 | 勝任，且仍有餘量 |
| 102.01 tok/s | 3B —— 檢索 + 摘要（本文建模配置） | 勝任 —— 即建模所用配置 |
| 90 tok/s | 4B —— 更長摘要、更好的指令遵循 | 勝任，但餘量更小 |
| 61.11 tok/s | 8B —— 窄任務上接近雲端品質 | 僅在時延預算允許時 |
它確實不免費。本地這一趟有自己的成本：150 元/月的硬體折舊與 17 元/月的電費，已經算在上面 503 元裡了。而且第一次把大知識庫跑一遍是 prefill 密集型任務，必須攤進索引，不能每次查詢重做。如果一套系統每次請求都重新嵌入整個知識庫，它在時延上虧掉的會比在 token 上省下的更多。
| # | 步驟 | 進入下一步前的門禁 |
|---|---|---|
| 1 | 按請求記錄 token 用量，拆成輸入 / 命中快取 / 輸出 | 能把花費歸因到具體功能，而不是歸到一個帳號 |
| 2 | 給每個請求分類：這件事到底需不需要雲端 | 得到一個實測的本地方案閉環比例 —— 本文建模取 25% |
| 3 | 在抽樣 200 次請求上測真實訊噪比 | 人工評分；這是多數團隊從來沒測過的那個數 |
| 4 | 在本地模型上實作檢索 + 壓縮鏈路 | 壓縮後的上下文仍能正確回答那批抽樣問題 |
| 5 | 凍結提示詞前綴，讓它位元組穩定 | 快取命中率是測出來的，不是盼出來的 |
| 6 | 用你自己的數字把成本模型重跑一遍 | 上面每一個假設都被一個實測值替換 |
第 5 步收益最大，但看上去像雜務。快取價目對「永不變更的提示詞前綴」的獎勵倍數高達 30×，因此前綴整潔度應當被當作設計需求，而不是收尾整理。
[實測] 位元組到 token 的換算率由本次研究用 20 萬詞表分詞器在自有語料上實測：中文為主文本 3.0 位元組/token，含標記的英文頁 3.2，英文純文字 3.7。我們內部的記憶系統全量 284,222 位元組 = 95,303 tokens；一次工作階段實際注入 8,766 位元組 = 3,004 tokens，實測壓縮 31.7×。[公開] 價格取廠商官方 pro 檔空閒時段價目（人民幣/百萬 token）：輸入未命中 4.50、命中 0.15、輸出 13.50。0.5B / 3B / 4B / 8B 的解碼速度 215.86 / 102.01 / 90 / 61.11 tok/s 為廠商公開的端側實測值。[假設] 團隊規模、輪次、快取命中率、輸出長度、電價與硬體折舊均為可掃描參數。[推導] 成本、節省、訊噪比與時延由上述資料算術得出。模型刻意只對 B2 取 2.0× 的壓縮比，而自有實測已達 31.7× —— 大約只主張了觀測值的四分之一，為「受控語料」與「生產流量」之間的差距留出餘量。