Oxidizing Cross-Encoders
Qdrant 将 cross-encoder 推理用 Rust 重写为 cross-encode-rs，并与 Python 的 fastembed、sentence-transformers 做基准对比。由于三者最终都调用同一个 C++ 引擎 onnxruntime，小型 reranking 模型上 Rust 版本中位数仅快 1.1 倍；在更大模型上约快 1.4 倍；模型加载时间上并未占优。
发展脉络
- 首次出现Oxidizing Cross-EncodersQdrant Blog
- 当前判断这为「用 Rust 重写推理栈」的叙事提供了一个边界案例：在共享同一 C++ 执行引擎的前提下，语言迁移带来的中位数提升有限，性能差异更多取决于模型规模与运行时集成方式。对推理工具链厂商而言，竞争点可能从语言选择转向运行时、批处理与加载路径的工程优化。Agent Pulse · 分析
Qdrant 博客记录了把 cross-encoder 推理「氧化」（oxidizing）为 Rust 库 cross-encode-rs 的过程与基准结果。关键发现是：与 fastembed、sentence-transformers 对比时，小型 reranking 模型上 Rust 实现中位数只快 1.1 倍，原因不是 Rust 实现慢，而是 Python 库与 Rust 库都把计算交给同一个 C++ 引擎 onnxruntime，三者绝大部分时间消耗在同一份编译代码里。在更大模型上 Rust 版本约快 1.4 倍，但在模型加载时间上没有优势。
该基准说明语言层重写对端到端推理延迟的收益受限于底层运行时：当 fastembed、sentence-transformers 与 cross-encode-rs 都落到 onnxruntime 时，Rust 的收益主要来自调用与数据搬运开销，而非算子本身。可验证的下一信号是 Qdrant 是否公布按阶段拆分的耗时（预处理、tokenization、onnxruntime 调用、后处理），以及更大模型上 1.4 倍差距是否来自批处理或内存布局。
这为「用 Rust 重写推理栈」的叙事提供了一个边界案例：在共享同一 C++ 执行引擎的前提下，语言迁移带来的中位数提升有限，性能差异更多取决于模型规模与运行时集成方式。对推理工具链厂商而言，竞争点可能从语言选择转向运行时、批处理与加载路径的工程优化。
对评估推理栈迁移的团队，这条证据提示应先测量端到端阶段耗时再决定是否重写：当底层引擎相同时，语言迁移的收益可能只有个位数到四成，而模型加载等非计算路径可能成为更实际的优化目标。
若后续基准显示更大模型上差距扩大，或模型加载时间被单独优化，Rust 推理库的定位会更清晰；反之，若差距稳定在 1.1 至 1.4 倍，则说明收益主要来自边缘开销而非核心计算。可观察的下一信号是 cross-encode-rs 是否发布与 onnxruntime 解耦的执行后端或加载优化。