可交付方案
端侧 LLM 网关
在你现有云端大模型 API 前面，加一层本地检索与压缩
内网里放一台网关。它把内部语料索引一次，之后每次请求都在本地完成检索与压缩，转发出去的是 4,000 token 的精炼上下文，而不是 14,400 token 的一整堆。建模结果：每月成本比云端侧 RAG 低 63.3% —— 且这个数里已经含了网关自身的硬件。
网关并不让你的云端模型变聪明。它改变的是「让云端模型读什么」。
回答长度是几百 token，提示词长度是几万。按 pro 档价目，输入未命中 4.50 元/百万 token，输出 13.50 元，而命中缓存比未命中便宜 30×。把提示词砍短，是唯一有这个量级的杠杆。
如果任务真正需要 2,000 个 token，而调用带了 14,400 个，上下文里只有 25.0% 是切题的。网关把这个比例提到 50.0% —— 既少花钱，也降低模型抓错段落的机会。
检索、排序、摘要都在网关上跑。原始文档、邮件、代码库都不离开内网 —— 出去的只有精炼后的上下文。对不能把整份语料送到 API 的团队来说，这决定了「能不能用大模型」，而不只是「用得贵不贵」。
网关的部署位置。离开内网的只有精炼后的上下文，原始语料永远不出去。
同一个团队、同一个知识库、同一批问题。每月 19,800 次请求，按 pro 档计价；网关方案还要算上自己的硬件与电费。
| 方案 | 每轮上下文 | 轮次 | 单次输入 | 月输入量 | 合计 / 月 |
|---|---|---|---|---|---|
| 无编排 | 32,000 tok | 2.2 | 70,400 tok | 1,393.9 M tok | 6,078 元 |
| 云端侧 RAG | 8,000 tok | 1.8 | 14,400 tok | 285.1 M tok | 1,372 元 |
| 端侧网关方案 | 4,000 tok | 1.4 | 5,600 tok | 83.2 M tok | 503 元 |
我们拿云端侧 RAG 作比较基线，因为多数团队已经在这么做。拿一个好设计去比「完全没有设计」会得到一个更大、但更不诚实的数字。
每月总运行成本 —— 云端 + 网关设备。最右侧那条是端侧方案。
四个机制互相耦合，效果不能相加。有意义的数字是「其余三个照旧、单独拿掉某一个」时要多付多少。
| 机制 | 关掉后成本 | 占总贡献 |
|---|---|---|
| 稳定前缀 —— 缓存命中 10% → 65% | +163 元/月 | 32% |
| 上下文压缩 —— 8,000 → 4,000 tok | +139 元/月 | 27% |
| 本地分流 —— 25% 在网关上闭环 | +112 元/月 | 22% |
| 轮次收敛 —— 1.8 → 1.4 轮 | +96 元/月 | 19% |
最大的单项杠杆不是压缩，而是缓存命中率。32% 高于上下文压缩的 27%，因为命中缓存的输入比未命中便宜 30×。一个永不变化的前缀，比一个更短的前缀更值钱 —— 所以我们把「前缀稳定性」写成交付项，而不是留给实现细节。
压缩比是最容易在你环境里失真的假设，所以这里扫描而不是断言。
| 每轮上下文 | 相对云端侧 RAG | 相关度 | 合计 / 月 | 节省 |
|---|---|---|---|---|
| 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% |
即便把压缩完全关掉，本地分流与轮次收敛仍然撑起大约一半的节省。网关的价值不是只押在激进压缩上。
网关是我们 RK182X 端侧推理硬件的一个产品化配置，不是一块裸板。
按负载选型的 RK182X 级端侧推理主机，含 BSP、散热验证与外壳。速度参考：3B 模型解码 102.01 tok/s，仅做路由的 0.5B 可达 215.86 tok/s。
语料接入与增量索引构建、检索与重排、上下文压缩、前缀固化、按请求的 token 记账，以及纯本地的兜底通路。
在你们现有的云厂商前面提供一个 OpenAI 兼容端点。客户端代码接口不变，只改 base URL。
把上面这套成本模型换成你们自己的 token 日志重跑一遍，外加一份在你们真实请求抽样上测出的信噪比基线。
说实话：网关不是免费的。150 元/月的硬件折旧与 17 元/月的电费，已经含在 503 元里。而且第一次跑完大语料是 prefill 密集型工作，必须摊进索引 —— 每次请求都重新嵌入整个语料的配置，在时延上亏掉的会比在 token 上省下的更多。
| # | 步骤 | 产出 |
|---|---|---|
| 1 | 对现有环境做 token 记账 | 花费按功能归因，拆成输入 / 命中缓存 / 输出 |
| 2 | 语料勘查与索引设计 | 索引什么、刷新节奏、排除清单 |
| 3 | 整机交付与建立索引 | 网关在内网跑起来，首次全量索引完成 |
| 4 | 检索与压缩调优 | 压缩后的上下文仍能正确回答抽样问题 |
| 5 | 切换并实测 | 在你们真实流量上的前后成本与信噪比对照 |
第 1、2 步在你们侧完成，用我们的模型；第 3 到 5 步由我们做。第 1 步没做完之前我们不会报节省数字 —— 这个数取决于你们的 token 日志，不取决于我们的。
不会。它部署在你们已在用的云厂商前面，减少发过去的量。厂商关系、模型选择、账号都保持不变。
一台网关覆盖本文建模的团队规模（30 人）。低于大约十几人时，网关自身的折旧会超过省下的 token 费，这种情况我们会直说。
建模取 25% 的请求不经云端即可回答。这个比例是**测出来的**，不是承诺 —— 落地第 1 步就是为你们的流量测出它。
只有精炼后的上下文。文档、邮件、代码库都在网关上读取，原始语料从不外传；索引本身也留在网关。
类别与任务路由可用 215.86 tok/s 的 0.5B 模型；检索与摘要用 102.01 tok/s 的 3B 模型，这也是方案取值。更大参数量可用，但吞吐更低。
那结果就更差，上面那张敏感性表写明了差多少。即便上下文回到 8,000 token、完全不压缩，节省仍有 53.2%。
[实测] 字节到 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。[假设] 团队规模、轮次、缓存命中率、输出长度、电价与硬件折旧。[推导] 成本、节省、信噪比与时延。模型只主张 2.0× 的压缩比，而自有实测为 31.7×，约为观测值的四分之一。