rerank 模型 费用

做完 RAG 之后，很多人卡在同一个地方：向量召回已经调通了，但答案还是不准，于是加一层 rerank。加完之后账单里多出一笔说不清的开销——它不像生成模型那样一眼能看出按什么收。这篇把重排序的计费方式、成本落在链路的哪一段、以及怎么按自己的检索量粗算一遍讲清楚，顺带说说什么场景下加它并不划算。

做完 RAG 之后，很多人卡在同一个地方：向量召回已经调通了，但答案还是不准，于是加一层重排序。加完之后账单里多出一笔说不清的开销——它不像生成模型那样一眼能看出按什么收。这篇把重排序的计费方式、成本落在链路的哪一段、以及怎么按自己的检索量粗算一遍讲清楚，顺带说说什么场景下加它并不划算。

先给一个总的判断：重排序的成本结构跟生成模型很不一样，它的钱几乎全部花在「输入」上，而不是「输出」上。你只需要记住这一条，后面所有估算都能顺下来。至于具体单价，站内不写死，一律到官方 API 价格页和模型资料库按当时的数字核对。

先搞清 rerank 按什么单位收钱

重排序吃的是「查询 + 候选文档」拼起来的输入量，输出通常只是一个分数，所以计费看的是输入侧，不是输出侧。理解这一点，后面所有估算都能顺下来。同一个查询，召回十条还是召回一百条，输入规模差了十倍，费用自然跟着差。

常见口径有三种：按输入 token 计、按「一次查询 × 候选条数」计、按请求次数计。同一家平台上不同模型的口径可能不一样，别拿 A 的单价去套 B。候选条数是最容易被忽略的乘数：召回条数翻倍，即使查询完全一样，花掉的钱也跟着翻。

按输入 token 计

把查询和每一条候选拼成输入，按总 token 数结算，候选越长越贵

按查询 × 候选条数计

一次请求固定按召回条数算，跟文本长短关系不大，估算最好算

按请求次数计

每次调用收一次，跟候选条数无关，适合候选集固定的场景

输出侧

通常只有一个相关性分数，几乎不产生额外计费

这笔钱落在 RAG 链路的哪一段

一条完整链路是：切分 → 嵌入 → 向量召回 → 重排序 → 生成。重排序夹在召回和生成中间，前一段按文档量收，后一段按最终上下文收，它自己按候选量收。很多人把它算进「生成成本」里，结果发现生成那段的账对不上，拆账时应该单独给它一行。

和嵌入模型的区别要分清：嵌入是一次性建库、按文档量算，重排序是每次请求都跑、按查询次数算。前者是一次性投入，后者随流量线性涨。流量翻倍，嵌入那部分基本不动，重排序那部分跟着翻倍。

想把各段的账分开记，可以直接参照站内把嵌入、召回、生成拆开算的思路，把重排序单独列一行，后面调参时才好对比。

按自己的检索量粗算一遍

估算不需要很精确，但顺序要对。先量三个数，再换算成钱，最后留一条可调的对照线。下面这套顺序照着走一遍，十分钟内能得出一个量级。

1. 量出三个基数记下日请求数、平均召回条数、平均每条候选的长度（字符数）。这三个数乘起来就是每天的输入规模量级，注意是量级不是精确值。
2. 换算成 token 与金额中文大致一字一 token，英文按词数估。拿总量去站内的换算工具按当时的单价算出金额，别凭印象拍一个数。
3. 留一条对照线把召回条数从高位砍到低位，钱会按比例掉，但召回质量可能受损。在评测集上验一遍再决定砍多少，不要只看账单。
4. 跟同类量级对一下用自己的历史用量跟站内用量榜上同类项目的量级比一比，如果差出一个数量级，先回头检查基数是不是量错了。

• 日均请求数 × 平均候选条数 = 每天的候选处理总量
• 候选总量 × 平均候选 token 数 = 每天输入 token 量级
• 输入 token 量级 × 当时单价 = 日成本量级
• 把上面三步乘 30 得到月量级，再跟预算比

什么情况下别急着上重排序

重排序不是默认应该加的组件，它带来的收益要能撑起它引入的调用次数和延迟。下面几种情况，先别上，或者先做小范围验证。

• 召回本身就准：先用一小批标注过的查询测一下，加了重排序后排序顺序没什么变化，就先别上
• 候选集很小（个位数）：提升往往撑不起额外的延迟和调用次数，不如先把切分和召回策略调好
• 延迟敏感又要同步返回：重排序是链路上额外的一跳，先把延迟预算算进来再决定
• 预算极紧的早期项目：可以先用召回后按规则截断这类零成本做法顶着，等流量起来再换

反过来说，如果召回明显不准、候选集又大、对延迟还有余量，那重排序通常是性价比不错的一跳。判断依据是评测集上的排序变化，不是感觉。