P40 与 L20 上的 Embedding 和 Reranker 服务性能对比

知识库应用的检索链路中，Embedding 和 Reranker 服务的响应速度会影响调用体验。硬件升级与服务部署方式都可能改变性能，测试时需要分别观察它们。

这份报告整理了 P40 + Xinference、L20 + Xinference、L20 + vLLM 三组部署的测试结果。在这批样本中，L20 + vLLM 的 Embedding 在并发 30 时达到 1197.76 QPS，Reranker 在并发 20 时达到 310.71 QPS。

这两个数是测试范围内观察到的峰值。各组仅运行一轮、每档 100 次请求，部分 vLLM 测试持续时间不足 0.5 秒，因此更适合用来寻找复测方向，不能直接当作长期服务容量。

测试矩阵与指标口径

原报告日期为 2026 年 9 月 21 日。三组部署使用相同的模型名称、并发档位和请求数量。

QPS 表示报告中的每秒请求吞吐；P50 和 P95 分别描述延迟分布的中位数与高分位。QPS 的比较单位是请求，不能换算成 token 吞吐或重排文档对吞吐，因为输入长度和每次请求的文档数量没有完整记录。

L20 上两组部署使用同一台硬件，更适合观察部署方式的差异。不过，报告没有记录 Xinference 的实际推理后端、精度、worker 数量与版本，不能把全部差异归因到框架本身。P40 与 L20 的网络路径也不同，其对比反映的是完整服务栈表现。

结果表按同一并发档位横向比较：绿色高亮为最高 QPS，或同一延迟指标的最低值。P50 与 P95 分别比较，比值列不参与最佳值判定。

Embedding 吞吐随并发增加

横轴按实际并发数间隔绘制，纵轴从零开始。标记对应各档观测值，连线用于辨认变化方向；每档仅 100 次请求、单轮测试。点击图表可放大查看。

表中的同档比值使用 L20 vLLM QPS / L20 Xinference QPS 计算。五档结果在 3.86 至 4.66 倍之间。

L20 + vLLM 的吞吐在测试范围内持续增加：并发从 20 增至 30，QPS 增加约 19.7%。由于没有测量更高并发，只能说当前范围内尚未观察到吞吐回落，不能确定真正的容量上限。

P40 + Xinference 则在并发 20 达到本轮峰值 57.39 QPS，升至 30 后降为 48.72 QPS。这个转折值得复测，但单轮数据不足以确定它来自硬件、排队、请求波动还是其他部署条件。

L20 上的 Embedding 延迟

延迟独立绘图，避免与 QPS 共用坐标轴。这里重点展示 P95；P50 的精确值保留在下表。P40 的延迟档位不完整，因此不绘制其延迟曲线。

在这批结果中，L20 + vLLM 在五档并发下同时获得更高 QPS 和更低 P50、P95。并发 30 的 P95 为 23.55 ms，反而低于并发 20 的 26.63 ms。这样的非单调变化需要更长测试来判断，不能据此认为继续提高并发会降低尾延迟。

Reranker 在并发 20 附近出现吞吐平台

并发 20 与 30 的 vLLM 观测点接近水平，能直观看到本轮吞吐平台；单轮连线不代表这些档位之间已经经过连续测试。

Reranker 的曲线与 Embedding 不同。L20 + vLLM 在并发 20 时达到 310.71 QPS，并发 30 时为 308.64 QPS，相差约 0.7%。这两个档位的吞吐已经很接近。

L20 上的 Reranker 延迟

与吞吐图一起看，并发 20 升至 30 时，vLLM 吞吐几乎不变，P95 仍继续上升。Xinference 在并发 20 的 500.70 ms 高值也按原数据保留，是否稳定出现需要复测。

并发从 20 增至 30 时，L20 + vLLM 的吞吐几乎没有增长，P95 却从 78.61 ms 增至 128.65 ms，增加约 63.7%。在这一轮样本中，继续增加并发的代价主要体现在延迟上。

因此，并发 20 可以作为 Reranker 下一轮复测的重点，而不是已经验证的生产最优值。如果业务有更严格的延迟要求，还需要同时观察较低并发档位。

同档比较与峰值比较需要区分

Reranker 的 3.46 倍，来自并发 20 时的同档比较：310.71 / 89.84。如果比较两组部署各自在测试范围内的最高 QPS，则为 310.71 / 135.96，约 2.29 倍。两个数字回答的是不同问题。

Embedding 的测试内峰值比为 1197.76 / 257.23，约 4.66 倍，恰好两组峰值都出现在并发 30。不能因为 Embedding 的两个口径重合，就在 Reranker 中也混用同档与峰值比值。

比较峰值能够描述各组在本次档位范围内的最高观测吞吐；选择服务参数还要一起看延迟、错误率和业务负载。

部署参数与复测范围

报告提供了 vLLM 的启动参数。两种模型都使用 float16、GPU 0、最大序列数 128，以及最大批 token 数 8192。Embedding 使用 pooling embed、最大序列长度 8192、显存利用比例 0.60；Reranker 使用 pooling classify、最大序列长度 512、显存利用比例 0.30。

两条原始命令复用了同一 GPU 和服务端口，报告要求分别启动。这里的结果不代表 Embedding 与 Reranker 同时运行时的共享资源表现。batch-size=0 是压测脚本传入的参数，也不代表已知服务端的实际动态批大小。

原报告建议每档至少 1000 次请求，预热后重复 3 至 5 轮。这可以作为复测的起点；若要验证持续容量，还需要让测试持续足够长，并覆盖真实输入长度与持续负载。

下一轮应补齐服务版本、推理后端、精度、模型版本、网络路径和预热记录，并同步观察 GPU 利用率、显存、队列与实际批大小。Embedding 可以继续测试并发 40、50、64，寻找吞吐平台；Reranker 则重点复测 10、20、30，确认延迟上升与吞吐平台是否稳定存在。

这次结果最有价值的地方，是把复测方向变得具体：Embedding 继续寻找吞吐边界，Reranker 优先验证并发与尾延迟的权衡。 它还不是采购结论，也没有比较模型效果；生产选择仍需要真实负载下更完整的证据。

数据下载与来源

• 下载 30 组测试汇总 CSV
• 报告来源与指标核对记录
• SSD 迁移性能报告

CSV 为原报告中的测试组汇总值，不是逐请求日志。部署地址已省略。