企业建设AI搜索和知识库时，常用“每分钟请求数”判断需要多少算力，但同样一次请求，可能只包含几个词，也可能包含上百篇长文档。Cohere最新分析指出，请求形态比调用次数更重要，共享推理与专用推理的选择必须回到真实工作负载。

10月9日，Cohere发布Embed与Rerank部署分析，比较按使用量计费的共享推理和预先配置容量的专用推理。文章给出的核心框架是：先理解请求内容，再看流量模式和设备利用率，最后决定部署方式，而不是只比较每Token价格或峰值请求量。

同一个嵌入模型面对两种完全不同的任务

向量嵌入会把文本转换为可比较的数字表示，是语义搜索和RAG的重要基础。电商平台首次建立商品索引时，可能把约100条商品描述组成一个批次，每条约200个Token。用户搜索“防水越野跑鞋”时，则只提交一个很短的查询。

两种任务使用相同模型，但目标不同。批量索引更关心吞吐量和单位成本，短查询更关心即时响应。针对大批次调优的基础设施，不一定能在大量小请求中保持低延迟；反过来，为交互查询预留的容量，也可能在低流量时长期闲置。

重排序成本随候选集合快速增长

Rerank会把用户问题与候选文档逐一比较，再把更相关的结果排到前面。Cohere举例称，一个约20个Token的查询，加上50篇各约200个Token的候选内容，一次重排序需要处理约1.1万个Token。候选数量从20增加到100时，处理量可从约4400个Token上升到约2.2万个Token。

对用户来说仍然是一次搜索，后台计算量却可能增加数倍。因此，检索深度不仅影响结果质量，也是基础设施和成本决策。企业如果只统计查询次数，很容易低估扩大候选集合后的算力需求。

稳定流量更适合专用容量，突发流量偏向共享

持续、可预测的全球搜索服务通常更容易让专用实例保持高利用率；月末报表、批处理或活动高峰等突发型任务，则可能更适合按量使用共享服务。真正需要计算的不是最高峰有多高，而是容量能在一天中保持多长时间的有效使用。

Cohere基于代表性价格和单个NVIDIA A10 GPU专用实例给出了若干示例临界点：短查询嵌入可能需要每分钟数万次请求才接近专用容量的经济区间，包含100段长文本的批量嵌入则可能只需每分钟约4次。官方强调，这些数字取决于实例、价格、请求结构和全天利用率，不是通用采购标准。

吞吐量不能脱离延迟目标

最大吞吐量并不等于生产环境可用容量。批量索引可以接近设备峰值运行，交互搜索却必须在目标延迟内留出余量。重排序加入更多候选文档，可能提升单位时间处理的文档数，却降低可同时服务的搜索次数。

编辑观察：先记录真实请求，再决定买多少算力

企业在上线前应从日志中抽取典型请求，分别统计文本长度、批次大小、候选文档数量、峰谷流量、允许延迟和失败重试。随后用同一批业务数据压测共享与专用方案，比较满足延迟目标时的可持续吞吐量和完整成本。

很多系统最终可能采用混合方式：稳定的大批量索引使用专用容量，波动明显的在线查询使用共享推理。Cohere这次分析提醒企业，AI基础设施没有一个只靠调用次数就能套用的答案。理解每次请求携带多少计算工作，才是控制成本和体验的起点。

配图为AIcent原创AI生成实景风格示意图，非官方新闻现场照片，不使用第三方新闻图片。

参考来源：Cohere官方博客（2026年10月9日）。正文为基于官方消息的中文整理，编辑观察与事实披露分开呈现。