Rerank API 中转看起来只是“把请求转发到上游”，但重排序处在搜索链路的关键位置：它慢一百毫秒，用户就能感知；它的计费单位不透明，月底对账就会出问题；它的模型版本悄悄变化，排序质量也会跟着漂移。

本文讨论中转与代理的常见形态、延迟影响、计费核对和迁移步骤，帮助团队在“快上线”和“可长期维护”之间做取舍。具体模型与价格以各服务商文档及站内模型价格为准。

说明：Cohere、Jina AI 等名称是其权利人的商标，本文与相关厂商无隶属关系。中转市场变化较快，本文描述的是 2026 年常见形态，不构成对任何服务方的背书。

一、Rerank 中转和聊天中转不是一回事

聊天 API 中转的主要问题是流式输出、上下文长度和并发；Rerank 中转的主要问题是同步延迟、文档数量和计费口径。重排序请求通常很短，却对 P95 极其敏感；一次请求可能携带几十篇文档，成本随“篇数 × 长度”增长；返回结果只有索引和分数，出问题时很难从响应本身判断上游是谁。

还有一个容易忽略的点：Rerank 没有统一的 OpenAI 兼容标准。Cohere 的路径是 /v2/rerank，Jina 是 /v1/rerank，字段名和分数范围也可能不同。中转如果做了协议转换，必须确认转换后的行为与上游一致，尤其是截断策略和 top_n 的语义。

二、四种常见中转形态

形态 控制力 延迟来源 计费透明度 Key 归属 适用场景
商业中转站 低，依赖服务商 中转路由 + 跨境链路 看是否提供调用明细 服务商持有上游 Key 快速验证、小流量
自建反向代理 高，自己运维 服务器区域 + 上游链路 上游账单直接可见 自己持有 有运维能力的团队
云区域网关 中，受云产品约束 同区域调用通常较短 云账单可拆分 自己或云账号 已在同一云上部署
统一 AI 网关 中高，可配多上游 网关区域 + 上游路由 统一账单，需核对倍率 网关方或自持 多模型、多项目

自建代理并不等于没有风险：服务器、证书、重试、限流都要自己处理，上游账号的合规责任也在自己身上。商业中转省掉的是运维，不省掉的是选型责任。

三、延迟会怎样影响搜索

先画一条端到端预算：召回、重排、生成、网络叠加。重排序的增量应控制在数百毫秒内，否则用户会感觉搜索“卡了一下”。Jina 的文档给出的参考是，100 篇约 256 Token 的文档、64 Token 查询约 150 毫秒；单篇 4096 Token 时会升到数秒。Cohere 建议单次不要超过 1000 篇文档。中转多一跳，增加的是 RTT、排队和可能的协议转换开销。

降低延迟的手段按性价比排序：减少候选文档数、缩短单篇长度、把 top_n 设小、让中转节点靠近业务区域、复用连接。若中转节点与上游跨区域，跨境 RTT 可能比模型推理本身还大。对搜索即输即显的场景，可以把重排放到第二段请求，或只对前 20–50 条候选重排。

测量时要区分“中转响应时间”和“端到端搜索时间”。前者好看不代表后者好看，因为重试、DNS、TLS 握手和排队都可能被平均值掩盖。

四、计费透明度：三种口径要对上

Rerank 常见计费口径有三种：按请求次数、按文档数或 search unit、按输入 Token。不同口径下，同样的业务量账单可能差很多。需要确认的细节包括：top_n 是否影响计费、被截断的文档如何计费、失败请求是否计费、缓存命中是否减免、是否有最低消费、倍率是否含在单价里。

最有效的办法是做一次对账实验：准备一批固定请求，分别走直连和中转，记录调用次数、文档数、Token 数和实际扣费。若中转只给一个总余额，不给每次调用的明细，后续很难排查“为什么这个月涨了”。企业采购还应确认发票主体、开票时点和退款规则，避免预充值余额变成沉没成本。

五、Key 与数据风险

商业中转常用共享上游 Key。好处是开通快，代价是你无法控制上游账号的限流、模型版本和封禁风险；一旦上游调整策略，所有租户一起受影响。自建代理则要自己承担 Key 泄露、滥用和账单失控的风险。

重排序请求会携带查询和文档片段，可能包含客户资料、合同条款或内部知识库内容。签约前要问清：请求是否落日志、日志保留多久、是否用于训练、数据存放在哪个区域、删除机制是什么。对敏感业务，宁可选择可签数据处理条款的服务方，或把重排模型部署在自己的环境里。

另外要警惕“与厂商合作”之类的模糊表述。是否获得授权、是否为企业客户，应以合同和可核验的资质为准，不能只看宣传页。

六、迁移清单

  1. 盘点现有调用：接口路径、模型、候选数量、超时和重试设置。
  2. 保存基线：用一批真实查询记录排序结果、P95 延迟和错误率。
  3. 抽离客户端：把 URL、Key、模型名放进配置，避免散落在业务代码里。
  4. 双跑对比：同一批请求分别走原服务和新中转，比较排序和质量指标。
  5. 校准分数：不同模型的分数分布不同，不要直接沿用旧阈值。
  6. 灰度切流：先 5%–10% 流量，观察搜索指标和账单。
  7. 验证降级：确认超时、429、5xx 时能回退到原服务或原始排序。
  8. 保留回滚窗口：至少保留一个完整计费周期的旧配置和 Key。

迁移中最容易出错的是第 5 步。重排序分数只表示同一批候选内的相对顺序，跨模型不可直接比较；模型版本、截断长度、是否传入结构化文档，都会改变结果。

七、怎么验证一个中转

先做静态核对：接口路径、鉴权方式、模型名是否可固定、响应里是否包含 index 和 relevance_score、分数范围是否与文档一致。再做动态测试：用相同 payload 对比直连与中转的排序差异，记录 P50/P95、错误率和 429 触发情况。最后做账单核对，确认调用明细能对上。

下面是一段最小延迟测试脚本，重点是使用真实长度的文档，而不是等长占位文本：

import statistics, time, requests

URL = "https://<relay-host>/v1/rerank"
HEADERS = {"Authorization": "Bearer <key>"}
PAYLOAD = {
    "model": "<model>",
    "query": "退款政策是什么",
    "documents": ["这里放真实长度的文档片段 " + str(i) for i in range(50)],
    "top_n": 5,
}

latencies = []
for _ in range(30):
    start = time.perf_counter()
    resp = requests.post(URL, json=PAYLOAD, headers=HEADERS, timeout=3)
    resp.raise_for_status()
    latencies.append((time.perf_counter() - start) * 1000)

latencies.sort()
print("p50", statistics.median(latencies))
print("p95", latencies[int(len(latencies) * 0.95) - 1])

如果中转方无法提供稳定的模型版本号或调用日志，建议只把它用于非关键业务。生产环境应保留可切换的备用路径，并定期复测。准备统一接入多家的团队，可以先从注册入口了解当前接口清单，再按模型价格估算预算。

八、常见问题

中转会比直连慢多少？

取决于节点位置和路由。同区域中转可能只增加几毫秒，跨境多一跳可能增加几十到数百毫秒。必须用真实请求测 P95，不能只看服务商给的均值。

为什么中转账单和上游账单对不上？

常见原因是计费口径不同：按请求、按文档、按 Token，或包含倍率、最低消费和失败请求。签约前要让对方给出计费公式和调用明细样例。

换中转后排序结果变了正常吗？

正常。模型版本、截断长度、结构化文档处理和分数归一化都可能不同。要用同一批查询做对比，并重新校准业务阈值。

中转服务停服怎么办？

提前做两件事：把客户端抽象成可切换配置，保留直连或其他服务商的备用路径；不要把所有预算一次性充进单一中转。

自建反向代理算中转吗？

算技术意义上的中转。它让你掌握 Key 和日志，但服务器、证书、限流、合规和上游账号责任都要自己承担。

相关阅读