当我们发布自动嵌入功能时——该功能能够自动将任何文本列转化为向量，而无须单独的模型服务——最常见的反馈是关于速度的。之前的路径通过SentenceTransformers在Candle之上完成，Hugging Face的纯Rust ML推理运行时，留下了很多CPU闲置：大多数工作负载在文档/秒的低双位数徘徊，不论我们如何处理它们，并且并发调用在单个模型会话上串行化。因此，我们花了几周时间重建Manticore运行ONNX模型的方式。新的ONNX运行时后端在Manticore Search 27.1.5中发布。ONNX（开放神经网络交换）是大多数流行的开源嵌入模型——MiniLM、BGE、E5等——已经发布的便携式模型格式。结果是一个后端，在相同硬件（平均便宜的16核/ 32线程服务器）上，平均速度比先前的SentenceTransformers/Candle路径快约14倍，使用相同的模型和权重，并且在全线程×批处理工作负载网格中进行了平均评估——这种优势无论你运行1个客户端线程还是32个线程都能保持。旧的路径在整个网格中的文档/秒范围在5–11之间；新的路径则在70–230文档/秒区间内。本文是工程日志：我们尝试了什么，什么让我们惊讶，丢弃了什么，最终的设计看起来是什么样的。TL;DR 在相同设备（16核/32线程）、相同模型、相同权重下，平均速度比之前的SentenceTransformers/Candle路径快约14倍，横跨全线程×批处理工作负载网格（1 / 2 / 4 / 8 / 16 / 32线程×批处理大小1…128）。在Manticore Search 27.1.5中发布的新ONNX路径现在是任何提供.onnx文件的HuggingFace模型的默认快速路径。在所有的MiniLM-L12-v2配置中，旧的Candle路径在我们尝试的每个配置中都保持在5–11文档/秒。新的ONNX路径则在70–230文档/秒之间——无论你运行1个客户端线程还是32个，差距约为14倍。我们测试机器上的单次插入延迟为：单个客户端时约14毫秒，8线程并发负载下约56毫秒——两者都远低于Candle的200+毫秒。想要最大限度提升批量导入吞吐量？在单个客户端线程上使用高批量大小（32–128）。新的后端在调用内部进行并行化，因此客户端的扩展只会增加协调的开销——在我们的机器上，1个线程+批次=64时的峰值为233文档/秒。最重要的两个变化是：关闭intra_op_spinning，并放弃在工作者内部批处理文档。没有用户面向的API变化。一个已经指向ONNX可用的MODEL_NAME的表会自动采用新路径。将现有表切换到不同模型并不是一行代码的事——Manticore不允许在浮点向量字段中就地更改MODEL_NAME——但你不需要重新创建整个表：可以添加一个新列与新模型并存，重建它的嵌入，然后删除旧列。为什么这很重要 使用自动嵌入，数据库本身在每次插入时运行模型。这意味着嵌入速度就是插入速度——你的导入吞吐量就是嵌入步骤能维持的速度。旧的SentenceTransformers/Candle路径留下了性能空间。并发导致锁竞争，批处理调用由于填充开销而停滞，而在调用之间，运行时以某种方式停放线程，阻止了下一次调用继续之前的调用。显著症状非常简单：无论你对其施加什么，顶部都会显示机器在满载下良好工作。整组测试——单行插入，128行批量插入，一个客户端线程，三十二个客户端线程——都在5–11文档/秒之间徘徊，因为你无法通过供给的方式获得更多CPU。新的ONNX路径提升了基本性能一个数量级，并为用户提供了有意义的性能调优选项。单线程、单行插入现在能达到72文档/秒——已经是旧的Candle的7倍多。增加并发或批处理大小，能提升到130–230文档/秒范围，在单个客户端线程的--batch-size=64时，顶峰为233文档/秒。在整个线程×批处理矩阵上的平均效果，新路径是旧路径的约14倍。为什么选择ONNX，而不是Candle Manticore的嵌入库支持了几种后端已有一段时间。Candle路径在正确性方面表现良好且易于发布。但是，对于MiniLM和BGE系列等小型编码模型的生产推理来说，ONNX运行时是难以超越的：ONNX运行时（或ORT——微软的官方手工调整的C++推理引擎）进行图融合、常量折叠、内核自调优。在HuggingFace上，大多数流行的嵌入模型已经在其onnx/目录中发布了预融合模型.onnx。磁盘上的文件已经是ORT所需的形状。在相同的all-MiniLM-L12-v2权重下，在CPU上，ONNX路径明显优于Candle路径。相同的质量，每个文档的工作量大大减少。ORT会话使用一小部分意见创建：让sess