你做了一个 RAG（检索增强生成）应用。给老板汇报预算时，你大概是这样算的：
用户提问 → 调一次 embedding 模型把问题转成向量（几分钱）→ 调一次大模型生成答案（几毛钱）。所以每问一次，成本不到一块钱。
这套账在原型阶段确实成立。但 2026 年一线工程团队的真实数据是：上线后，真实账单往往是原型的 3 倍，有时是 10 倍。问题不在于模型涨价，而在于——你只算了 2 笔账，生产环境实际有 6 笔。
RAG 的真实账单：6 笔，不是 2 笔
2026 年多份生产 RAG 成本审计（aicredits、Multigrid、ergini、ravoid 等）给出的成本模型高度一致，一条生产级 RAG 查询最多会碰 7 个计费项，落地后通常收敛为 6 笔：
| 序号 | 账单项 | 计费方式 | 常被忽略程度 | |---|---|---|---| | 1 | 建库 embedding（一次性 + 变更重算） | 按 token，随变更复利 | 高（以为只发生一次） | | 2 | 向量库存储 + 查询（QPS/读取单元） | 按月 + 按查询 | 中 | | 3 | 查询 embedding | 每次查询按 token | 低（便宜到被忽视） | | 4 | 检索编排（混合检索/改写/过滤，常自带一次 LLM 调用） | 按查询 | 高 | | 5 | reranker 重排（cross-encoder，按 search 计费而非 token） | 按查询次数 | 高（最被低估的一笔） | | 6 | 生成输入 + 输出 token | 按 token，输出通常是输入 3–5 倍 | 低（但占比最大） |
还有两笔「隐形摊销」几乎从不被写进预算：reindex 摊销（换 embedding 模型要全量重算重建索引）、可观测/评估（追踪、faithfulness 校验、定期 re-embedding）。
一个反直觉的事实：大家最担心、最想优化的建库 embedding，其实是最便宜的那笔；真正吞钱的是生成 + reranker。ergini 的审计结论很直接——团队平均把每问 RAG 成本少算了 3 倍，有时 10 倍，根因是结构性的：RAG 被宣传成「embedding + 生成」两笔成本，生产里却是六笔，而被遗忘的四笔（reranker、多跳、可观测、reindex 摊销）加起来通常是 embedding 账单的十倍。
四笔「看不见的账」是怎么爆的
① reranker 是按「次」收钱，不是按 token。 它每次把 top-k 候选重排成 top-5，单价约 $0.001–0.002/次。问题在于：它不随你的上下文变短而变便宜。用一个廉价小模型前面挂一个 reranker，reranker 反而可能比模型本身还贵。质量值得，但必须进预算。
② 建库 embedding 不是一次性，是「复利债」。ravoid 的拆解最扎心：向量库存储随数据量线性增长（可预测），但 embedding 生成成本随数据波动率增长。一个每周更新 10% 内容的知识库，每周都在重新产生 10% 的 embedding 成本——无限循环。12 个月累计的 embedding 生成成本，可能达到首次入库成本的 5–8 倍**。
③ chunk 策略是隐藏的成本乘数。 过碎的、命题式的 chunking 会比递归切分多出 3–5 倍向量，意味着更多 embedding 调用、更多存储、更多检索计算。chunking 不只是检索效果决策，更是经济决策。
**④ 查询侧的「乘法效应」。简单 top-K 检索每问 1 次向量操作；但生产 RAG 普遍用查询扩展（HyDE/多查询）+ 混合检索 + rerank。一个月 100 万次查询、3 步检索管道的系統，实际是 300 万次向量操作 + 100 万次 rerank 推理 + 100 万次查询 embedding——你以为的「一次调用」实际被乘了三倍。
为什么这恰好是中转站该给你的「逐笔明细」
绝大多数团队直到账单爆了才发现：他们根本看不清哪一笔在烧钱。ergini 给的诊断模板要求按 租户（多租户）/ 用户 / 功能场景 / 查询类型 分别归因——这才能定位「某个租户贵了 10 倍」这类异常。
而这正是中转站层能、也应该为你做的事：
- 逐笔明细可归因到租户/功能/会话：每一笔 RAG 查询里的 embedding 次、rerank 次、生成 token，都能按 request_id 拆出来，归到你自己的业务维度，而不是混在一张总账里。
- 按密钥额度上限 + 环境隔离：dev/prod 不混账，单租户失控有硬顶，避免「一个租户的 reranker 把整月预算烧穿」。
- 固定 1.27× 透明倍率：上游峰谷差价我们承担，你每一笔的成本可预期，不会被静默调价偷走预算。
- 上游方舟官方授权 + 数据不留存不训练：RAG 知识库常含内部文档，链路境内、不留存，把你的数据风险敞口压到最低。
竞品（TeamoRouter/硅基流动/OpenRouter）只跟你比「多少折、多少模型、多好接」，从不讲「RAG 这六笔账怎么归因、怎么按 key 拆、怎么硬上限拦截」。把「算得清」做成默认能力，是我们在钱袋子这件事上和它们最根本的分野。
给开发者的四步自查
- 把你现在的 RAG 成本表从 2 行扩到 6 行：embedding（建库+查询）、向量库、reranker、生成输入/输出、reindex 摊销、可观测。少一行就是一笔漏掉的债。
- 按租户/功能/会话归因：用中转站逐笔明细，找出「贵 10 倍」的那一类查询，而不是只看总金额。
- 给 reranker 和单租户设硬上限：无条件全量 rerank 是财务和延迟双重错误；用中转站按 key 额度上限兜住突发。
- 把倍率写进合同前先问清：上游是否随峰谷/版本静默调价？固定倍率 + 调价提前公告，才让你预算可预期。
RAG 不是「一次 embedding + 一次生成」那么便宜。把六笔账算清、把每一笔归到具体的业务维度，你才算真正控住了这条链上的钱袋子。
本站 Yady API 默认提供 request_id 级逐笔明细（可归因到租户/功能/会话）、按密钥额度上限 + 环境隔离、固定 1.27× 透明倍率、上游方舟官方授权链路境内不留存不训练。方舟当前仅激活 1 个模型（广度短板，不掩饰）；不承诺全网最低价；上游调价提前公告不静默变更。详见 -> https://yczc.top/blog/rag-hidden-cost-2026.html
