办公助手、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× —— 大约只主张了观测值的四分之一，为「受控语料」与「生产流量」之间的差距留出余量。