Qwen3 RAG 成本计算：向量化与重排候选数量预算

对于检索客服知识库的 RAG 系统，重排费用可能更多地取决于候选段落数量，而不是向量索引的大小。下文的预算示例中，把每次重排的候选数从 20 增至 100，会让重排输入量增加到五倍。只要求返回五条结果，并不代表服务只评估了五个段落。

本指南结合 qwen3-embedding-8b 和 qwen3-reranker-8b 当前的 Orux 价格，提供可离线运行的 Python 计算器，帮助你设定初始候选预算，明确后续需要测量什么。我们实际运行了本地计算，但没有为本文发起新的模型请求，也没有进行检索基准测试。全部工作量都是明确列出的假设，不是对你应用的实测。

分开计算建库、查询向量化与重排

向量模型把文本转换为可比较的向量；重排模型根据查询与候选文档计算相关性。两者承担不同工作：未变更的文档通常在建库时向量化一次，而重排在收到查询、选出候选后进行。原生模型说明见 Qwen 向量模型卡和 Qwen 重排模型卡。

预算中应分别记录三个计数：建库或更新时向量化的文档 token、搜索时向量化的查询 token，以及重排评估的查询与文档 token。除非实现确实每次发送全库，否则不要将整个语料库乘以月查询量。反过来，按查询与文档对估算重排时，也不能只计算一次查询：同一查询会与每个候选文档配对。

最终撰写答案的语言模型是第四项成本。向量存储、检索基础设施、网络流量和适用税费也不在计算器内。分开这些项目后，账单意外增高时就能定位原因，而不是把所有支出都归到答案模型上。

当前价格快照：统一比较单位

下表为 2026 年 10 月 30 日核对的 Orux 公开输入价格。这是本服务售价，不是厂商官方托管 API 报价，也不是模型质量排名。1 积分（Credit）约合 $0.005。显示为零只说明当前配置价格为零，不承诺永久免费、无限容量或后续请求一定成功。

左右滑动查看完整表格。

备选模型页面是 bge-m3 和 bge-reranker-v2-m3。零价快照值得了解，但不能证明它们满足你的相关性、延迟或语言要求。依赖某项服务前，应核对访问条件、限制及当前报价。

延伸阅读中，LLM 请求费用对比讨论的是答案生成阶段；DeepSeek API 价格指南也针对文本生成，而非向量检索。这两篇不能替代重排价格表。

客服检索预算示例

假设知识库有 10,000 个段落，每段 400 token。第一个统计周期收到 10,000 次搜索，查询平均 40 token。分别估算每次重排 20、50、100 个候选。这里的长度是规划参数；语言、分词器、格式和文档组成都会改变实际用量。

初始建库需要 10,000 × 400 = 4,000,000 token，按 Qwen 向量模型价格计算为 46.6668 积分。查询向量化需要 10,000 × 40 = 400,000 token，即 4.66668 积分。两个向量化阶段合计 51.33348 积分。本例建库是一次性支出，未变化的语料库不应重复计算建库费。

重排估算公式为：搜索次数 × 候选数 ×（文档 token + 查询 token）。20 个候选时，输入量为 10,000 × 20 × 440 = 88,000,000 token；88 × 11.6667 = 1,026.6696 积分。这只是容量估算，不能替代服务实测用量或结算记录，且没有计入模型特有的格式开销。

左右滑动查看完整表格。

总额包含初始建库、查询向量化和重排，不包含答案生成。下一周期若索引未变化，可减去 46.6668 积分；若只更新部分文档，应按实际重新向量化的 token 替换该项。不能把此表描述成延迟或准确率实测结果。

在这些假设下，从 20 增至 50 个候选，重排费用为原来的 2.5 倍；增至 100 个则为五倍。这是工作量公式的比例，不代表模型效果提升 2.5 倍或五倍。图表属于编辑计算示意，不是模型生成结果。

无需 API Key 即可运行计算器

将以下代码保存为 budget.py，运行 python3 budget.py。代码只使用 Python 标准库，不发送网络请求。Decimal 运算保留公开费率精度，避免金额经过二进制浮点转换。用于其他日期或应用前，请修改费率和工作量参数。

"""Scenario calculator, not a tokenizer or a measured API bill. No network calls."""
from decimal import Decimal
RATE = Decimal('11.6667')  # Credits per 1M input tokens, checked 2026-10-30
USD_PER_CREDIT = Decimal('0.005')
QUERIES, CHUNKS, DOCUMENT_TOKENS, QUERY_TOKENS = 10000, 10000, 400, 40

def credits(tokens):
    return Decimal(tokens) * RATE / Decimal(1000000)

def scenario(candidates):
    index_tokens = CHUNKS * DOCUMENT_TOKENS
    query_tokens = QUERIES * QUERY_TOKENS
    pair_tokens = QUERIES * candidates * (DOCUMENT_TOKENS + QUERY_TOKENS)
    rerank = credits(pair_tokens)
    total = credits(index_tokens + query_tokens) + rerank
    return pair_tokens, rerank, total, total * USD_PER_CREDIT

if __name__ == '__main__':
    assert credits(4000000) == Decimal('46.6668')
    assert scenario(20)[1] == Decimal('1026.6696')
    assert scenario(50)[1] / scenario(20)[1] == Decimal('2.5')
    assert scenario(100)[1] / scenario(20)[1] == Decimal('5')
    print('k | rerank tokens | rerank Credits | first-period Credits | USD equivalent')
    for k in (20, 50, 100):
        print(k, *scenario(k), sep=' | ')

断言检查了建库算术和两个候选数比例，打印结果复现上表。这验证的是计算器，不是模型质量，也不是托管请求最终上报的精确 token 数。接入后的下一步，是将第一条真实用量记录与估算比较，替换假设的平均文档和查询长度。

候选数量不等于返回结果数量

当前 Orux 重排表单提供 query、documents 和可选 top_n。文档数组决定提交哪些段落参与评估。应把 top_n 理解为希望返回的结果数量，不能用它代替缩短输入数组来控制成本。比较 20 与 100 个候选时，应实际准备两组不同数量的候选。

向量请求使用 input 和当前公开的 encoding_format: "float"。原生模型能力和托管表单是不同的接口约定：不要推断模型卡中的所有功能都已成为 Orux 参数。接入前，请使用模型页的准确别名并查看当前输入表单。

例如查询“怎样修改发票邮箱？”，应先从自己获准使用的文档中检索候选，再只把这些段落送去重排。文本旁保留文档 ID，方便将返回的索引或结果映射到来源。相关性分数并不能确认段落仍然有效、当前用户有权查看，或它足以回答问题。

选择仍能保留有效证据的最小候选池

没有进入候选集合的相关段落，重排模型无法找回。因此减少候选并非无条件优化。先建立有标注的代表性客服问题集，涵盖准确产品名、歧义表达、近期政策变更，以及没有有效答案的问题。比较配置前，记录正确答案需要哪些来源段落。

对每种候选预算，分别测量必要段落在重排前是否被检索到、重排后的位置，以及答案阶段是否获得足够证据。延迟和计费用量分开记录。如果相关段落在重排前就缺失，应检查检索和文档准备；更大或更贵的重排模型也无法给未收到的文档打分。

比较 20、50、100 个候选时，固定评测集与文档快照，否则语料更新可能被误认为模型进步。本文没有通用的最佳候选数。只有在证据覆盖率和用户体验仍可接受时，才保留更便宜的配置。文档长度、流量组成或价格明显变化后，应重新检查。

常见问题

Q.首周期总额是保证的 API 账单吗？

不是。这是根据明确工作量假设和价格快照得到的估算，未包含格式开销、实际分词差异、答案生成及基础设施。可用它统一比较候选预算，但在作为预测前，需先对照真实请求的用量和计费记录。

Q.把 top_n 设为五，就只付五个候选的费用吗？

不能这样假设：请求仍然包含你提交用于评分的全部文档。应区分输入候选数与返回结果数。若要验证减少候选带来的预算变化，请缩短 documents 数组，并检查重要证据是否仍然保留。

Q.未变更的文档需要每次查询都向量化吗？

本文描述的索引式流程不需要。文档向量会保存并复用，直到内容或向量配置发生变化；查询向量化是独立步骤。应计算新增、编辑和主动重建索引，而不是将整个文档库乘以每次搜索。

Q.BGE 零价能证明它是最佳选择吗？

不能。当前零输入价只是核对日期的价格事实，不能说明你的检索质量、访问条件、延迟或未来价格。将其作为生产依赖前，应使用代表性问题评估，并核对实时模型页。

Q.这个计算器会调用模型或消耗积分吗？

不会。Python 示例用标准库在本地做算术，不需要 API Key 或网络请求。它说明预算关系，不生成向量或相关性分数。之后调用托管模型的集成测试是独立操作，需要遵循当时的价格和限制。

价格核对日期：2026-10-30。来源：Orux Qwen 向量模型、Orux Qwen 重排模型、Orux BGE 向量模型、Orux BGE 重排模型，以及上文两份 Qwen 模型卡。