问题：检索有两类不同的资源成本
私有 RAG 系统需要为文档编码、向量存储和搜索结果排序投入资源。实用的运行配置取决于可接受的质量变化和处理能力受限的位置。ProsGrow 使用 Qwen 支持的表示方式及 vLLM 的精度执行路径，系统地评估了这些决策。
我们选择了原始向量字节数减少 75% 的 1,024 维向量；在另一项独立实验中，选择动态 FP8，获得了 69.10% 的嵌入吞吐量提升。两者各有自己的质量权衡。
决策一：保留值得占用存储空间的维度
我们从 Qwen3-Embedding-8B 原生的 4,096 维输出开始。在完整 SciFact 测试集上，这一 FP16 基线的 nDCG@10 得分为 0.79279；该相关性指标会奖励排在搜索结果前列的有用文档。将输出降至 1,024 维后，得分为 0.78944，即基线 nDCG@10 的 99.58%。
相同存储精度下的原始向量大小
更激进的压缩带来了更大的排序质量损失。我们为该语料库选择 1,024 维，Recall@100 从 0.98000 降至 0.97333。99.58% 的保留比例特指这项 FP16 维度实验中的 nDCG@10。
更小的向量在哪些方面有帮助，又有哪些局限
Qwen3-Embedding-8B 提供 Matryoshka 表示，并得到 vLLM 嵌入运行时支持。这项上游能力支持更短且仍然有效的向量。ProsGrow 的贡献是针对工作负载评估由此带来的存储与质量权衡。
对于 1 亿个 float32 向量，计算得到的原始存储量从 1.64 TB 降至 0.41 TB。数据库总占用和搜索延迟仍需使用实际索引测量。
编码器仍然按原生隐藏维度进行计算，在受测维度之间，吞吐量变化最多为 1.2%。下文的 69.10% 吞吐量提升来自独立的精度实验。
决策二：使用 FP8 获得实测编码能力提升
保持输出维度和短输入工作负载不变时，动态 FP8 在八个副本上达到 319,951 输入 token/秒，高于 FP16 的 189,213。两次 FP8 节点运行中的较低结果对应 69.10% 的提升。
相同八张 GPU 上的嵌入吞吐量
更快的执行路径来自 vLLM 的动态 FP8 支持。ProsGrow 验证了预期的 FP8 算子内核在每张 GPU 上执行，并综合评估精度、并发和副本部署。将并发提高到选定配置之上，处理能力增加很少，平均延迟却约翻倍。
最终对比始终关闭前缀缓存，避免重复的基准输入通过复用缓存替代 Transformer 计算。
这一优化节点每处理一百万输入 token 的 GPU 板卡能耗也降低了 44.19%：从 7.025 Wh 降至 3.921 Wh。这是实测 GPU 能耗改善，指标不包含主机和设施用电。
FP8 的质量代价需要单独决策
我们通过一个匹配的 FP16 对照和两次 FP8 启动，重复了完整 SciFact 质量评估。在 1,024 维下，较保守的 FP8 结果为 0.786211 nDCG@10，匹配的 FP16 对照为 0.789717，即降低 0.003506。Recall@100 保持在 0.97333。
另一次 FP8 启动的 nDCG@10 为 0.790021。我们报告较低得分，以使验收决策保持保守。前述 99.58% 保留比例仅属于原始维度实验，并非降维与 FP8 组合后的质量保证。
重排序：将算力用于能影响答案的候选文档
对于 Qwen3-Reranker-8B，我们为每个查询选择 20 篇完整文档。策略研究同时改变了候选数量和文档截断方式，因此不能将效果仅归因于候选数量。选定策略的 nDCG@10 为 0.80482；较小的候选集在节省算力与检索召回率之间做出权衡。
在固定的 20 文档规格下，动态 FP8 将独立运行吞吐量从每秒 2.7444 次搜索提升至 4.6958 次，增幅为 71.10%。较保守的八副本结果从每秒 21.6248 次搜索提升至 44.4738 次，即每小时 77,849 次提升至 160,106 次 top-20 搜索，增幅为 105.66%。nDCG@10 从 0.804821 变为 0.803368，Recall@20 保持在 0.94000。
两次启动中，节点结果均超过独立 FP8 速率的八倍；经审查，原因仍未确定。这一处理能力仅适用于该特定配置。独立运行的 71.10% 对比更适合用来判断精度变化带来的单 GPU 收益。
这对客户意味着什么
对于通过 1,024 维质量验收的语料库，向量载荷可缩小四分之三。对于同时通过 FP8 验收的短输入索引任务，实测吞吐量折算为每十亿输入 token 约需 52 分钟，而 FP16 基线为 88 分钟。这些是按基准速率计算的处理时间估算值。
这为更频繁的索引刷新提供了空间。在线搜索需要联合规划处理能力：整节点的嵌入和重排序速率是分别测量的。
ProsGrow 的贡献是根据工作负载要求选择并验证运行配置。客户试点需要自身的相关性标注和完整检索链路，涵盖答案质量与 p95 延迟。基准测试明确了组件层面的权衡；生产服务需要联合验证。
两个独立组件的成本模型
在全部处理能力均用于付费任务时，9 月的基础设施模型估算：节点采购成本为 $100,000–$150,000，嵌入成本为每百万输入 token $0.00453–$0.00646，top-20 重排序成本为每 1,000 次搜索 $0.03258–$0.04644。计算分别采用各组件自己的实测整节点速率：319,951 输入 token/s 或 44.4738 次搜索/s。
这些情景假设三年摊销、每年 5% 维护成本、每月 720 小时、电价 $0.10/kWh、1.30 的用电乘数，以及运行中的服务器功率为 6 kW。由此得到每个活跃节点小时 $5.22–$7.44 的基础设施成本模型值。6 kW 是面向整体方案的假设，与上文实测的 GPU 板卡能耗改善相互独立。需求降低时，固定成本将由更少的售出单位分摊。
两个组件在独立测试中分别使用全部八张 GPU，因此不能将各自峰值合并为同时服务能力。成本不包括存储、应用运维、人工、网络、服务预留容量及答案生成。每个合格答案的成本需要端到端验证。
方法与局限
- 硬件与模型：八张 RTX PRO 6000 Blackwell Server Edition GPU，每张标称显存 96 GB，每张部署一个副本。嵌入使用
Qwen/Qwen3-Embedding-8B，修订版本1d8ad4ca9b3dd8059ad90a75d4983776a23d44af；重排序使用Qwen/Qwen3-Reranker-8B，修订版本77d193c791ed757ca307ee72715aa132723da912。 - 运行时：vLLM 0.25.1；精度对比采用 float16 激活值和动态 FP8 权重，并验证了 FP8 算子内核执行路径。最终对比关闭了前缀缓存。
- 嵌入处理能力：采用合成短输入，每个请求包含 64 条输入，每条平均为 56 个模型 token，返回 1,024 维向量。每次节点运行处理 65,536 条输入。选定的 FP8 共同计时窗口为 11.467 秒；两次运行相差 0.47%，没有失败请求。真实文档质量另行评估。
- 检索质量：使用完整的 BEIR SciFact 测试集：5,183 篇由标题和摘要组成的文档、300 个查询及官方相关性标注，采用发布方的查询指令和穷举余弦搜索进行评估。SciFact 是一个科学领域基准；其他语料库和近似索引可能有不同表现。
- 重排序测量边界：每次节点运行处理 2,400 次搜索，每次包含 20 篇完整文档。候选文档固定来自 FP16 1,024 维稠密检索基线，因此该测试不衡量 FP8 嵌入与重排序组合的流水线。我们报告观察到的较低吞吐量与质量。
- 计时与部署：预热后的 API 计时窗口从最早副本开始到最后完成为止，不包含启动和载荷构建。连接器、分块、向量数据库操作、生成和生产排队都需要端到端试点。每小时及十亿 token 的数值是算术换算，并非持续稳定性测试。
- 存储与能耗：75% 的降幅适用于相同存储精度下的原始向量；元数据、索引结构、副本和备份会增加开销。能耗数字仅涵盖 GPU 板卡。结果是特定配置的本地对比，不声称与等效模型的托管 API 具有某种成本关系。
私有 RAG 检索与语义搜索
对于规划私有检索增强生成（RAG）的团队，本研究区分了嵌入向量存储、文档索引处理能力和重排序质量。这些测量可以为语义搜索基础设施的选择提供依据，但向量更小本身并不能证明数据库查询更快。部署时应在完整检索链路中验证相关性、响应时间和答案质量。