开源搜索引擎 Manticore Search 在 27.1.5 版本中重写了向量嵌入的后端实现，基于 ONNX Runtime 替代原有的 Candle 运行时，在相同硬件条件下实现约 14 倍的平均性能提升。
为什么重写
Manticore Search 的「自动嵌入」功能允许在数据库内部直接运行嵌入模型，生成文本向量。但旧路径依赖 SentenceTransformers 与 Hugging Face 的纯 Rust 运行时 Candle，存在三个性能瓶颈：并发调用在单个模型会话上排队等待；批处理因填充开销而遭遇瓶颈；运行时在调用间隙将线程置于停放状态，导致下次调用无法快速接续。结果是无论单行插入还是 128 行批量插入，无论 1 个还是 32 个客户端线程，吞吐始终停留在 5–11 docs/sec。
ONNX Runtime 为什么更快
ONNX Runtime（ORT）是微软维护的 C++ 推理引擎，对 ONNX 格式模型执行图融合、常量折叠和内核自动调优。目前主流开源嵌入模型——MiniLM、BGE、E5 等——均已在 HuggingFace 提供预融合的 .onnx 文件，磁盘上的权重文件直接符合 ORT 要求的格式，无需额外转换。
Manticore 的实现中，大部分配置属于常规优化：启用最高图优化等级（Level3）、让 ORT 自动选择核心数、开启清零非规格化数和近似 GELU 激活函数。真正关键的是一个反直觉的设置：intra_op_spinning(false)——关闭操作间的线程自旋等待。
这个参数的字面意思是禁止 CPU 在等待期间空转，改为直接让线程休眠。对大多数场景这会略微增加延迟，但对高并发工作负载，关闭自旋让 ORT 在每次调用结束后真正释放资源，而非保持「热备」状态等待下一个请求。对这个数据库嵌入场景，这一改动是整个分支中收益最大的单项优化。
并发模型的选择
Manticore 工程师尝试了常见的两种并发方案并最终放弃：一是单 Session 加 Mutex 锁保护，实现简单但所有线程排队；二是每个线程独占 Session，消除锁竞争但浪费显存。最终采用的方案是为每个工作线程维护一个 ORT Session 实例，在会话粒度消除竞争，同时避免显存碎片。
另一个重要发现是放弃在 worker 内部批处理文档。开发者曾尝试在服务端累积文档再统一推理，但跨请求协调的开销得不偿失。将批处理控制权交给客户端（通过 --batch-size 参数）后，单客户端单线程加 batch=64 即可达到峰值 233 docs/sec——多客户端的额外协调反而成为瓶颈。
实际效果
在新路径下，all-MiniLM-L12-v2 模型在 16 核/32 线程服务器上，单客户端单行插入即可达到 72 docs/sec，已经超过旧路径最高值；8 并发下延迟约 56 毫秒，32 并发下吞吐量攀升至 130–230 docs/sec。API 保持不变，已有表配置指向 ONNX 模型会自动切换；更换模型需添加新列而非原地修改。
编注：信源为 Manticore Search 官方技术博客，材料为工程日志，包含完整性能测试数据与代码配置。原文详细描述了并发模型的取舍过程，本文侧重结论与机制。