Rust 生态 AI 编译工具链评测：candle、burn 与 tract 的算子覆盖与性能横评

一、Rust 原生 AI 推理的三个选项，选型时却缺少系统化的对比数据

当前 Rust 生态中有三个主要的 AI 推理框架：candle（HuggingFace 出品）、burn（Tracel AI 出品）和 tract（Sonos 出品）。它们都在试图提供纯 Rust 的神经网络推理能力。避免 Python 依赖和 FFI 调用。

但在实际选型时，公开的基准测试数据很少。各项目的 README 中的性能数据往往是在不同的硬件、不同的模型上测试的。不具备可比较性。需要一套在相同条件下对不同框架做全维度评估的测试方案。

选型的核心关注点包括：算子在目标硬件上的实测性能、所支持的模型架构的广度、ONNX 模型导入的成熟度、量化方案的支持程度、以及与 Rust 异步运行时的兼容性。以下是在统一测试环境中对三个框架的系统化评估。

二、评估维度与测试环境搭建

评估维度覆盖了从开发体验到生产部署的全链路。

graph TD A["AI 推理框架选型决策树"] --> B["算子性能基准"] A --> C["模型架构覆盖"] A --> D["部署便利性"] A --> E["社区活跃度"] B --> B1["矩阵乘法 GEMM"] B --> B2["卷积 Conv2D"] B --> B3["Attention 机制"] B --> B4["激活函数 Latency"] C --> C1["ONNX 导入支持"] C --> C2["HuggingFace 模型加载"] C --> C3["自定义算子扩展"] D --> D1["量化支持 Q4/Q8/FP16"] D --> D2["CUDA/Metal 后端"] D --> D3["WASM/Edge 部署"] E --> E1["GitHub Stars/Contributors"] E --> E2["Issue 响应速度"] E --> E3["文档完整度"]

测试环境配置如下：CPU 为 AMD Ryzen 5950X（16 核），GPU 为 RTX 4090（24GB），系统内存 64GB DDR4。Rust 版本 1.80.0。各框架使用发布模式编译（--release）。测试模型为 ResNet-18（视觉）、BERT-base（NLP）和 Whisper-tiny（语音）。每个测试运行 100 次取中位数，预热 20 次。

三、性能对比与算子覆盖评估

/// 推理框架评估的统一接口 /// /// 设计意图：不同框架通过 trait 统一调用方式 /// 消除上层代码差异对基准测试结果的影响 use std::time::Instant; trait InferBenchmark { /// 返回框架名称 fn name(&self) -> &str; /// 加载模型并执行预热推理 /// 预热确保 GPU Kernel 已编译、显存已分配 fn warmup(&self, iterations: usize) -> Result<(), String>; /// 执行单次推理，返回耗时（微秒） fn infer_once(&self) -> Result<u64, String>; /// 批量推理 fn infer_batch(&self, batch_size: usize) -> Result<u64, String>; } /// 基准测试执行器 fn run_benchmark(framework: &dyn InferBenchmark, runs: usize) -> BenchmarkResult { // 预热：消除首次运行的冷启动偏差 let _ = framework.warmup(20); let mut latencies = Vec::with_capacity(runs); for _ in 0..runs { match framework.infer_once() { Ok(latency) => latencies.push(latency), // 框架推理失败不终止测试，记录为 0 后继续 // 这是为了在框架部分模型不支持的场景下仍能得到可用数据 Err(_) => latencies.push(0), } } // 过滤掉失败的测试点（延迟为 0 的值） let valid: Vec<u64> = latencies.into_iter().filter(|&l| l > 0).collect(); if valid.is_empty() { return BenchmarkResult::Failed; } // 计算分位数 valid.sort(); let p50 = valid[valid.len() / 2]; let p95 = valid[(valid.len() as f64 * 0.95) as usize]; let p99 = valid[(valid.len() as f64 * 0.99) as usize]; BenchmarkResult { framework: framework.name().to_string(), p50_latency_us: p50, p95_latency_us: p95, p99_latency_us: p99, min_latency_us: valid[0], max_latency_us: valid[valid.len() - 1], } } struct BenchmarkResult { framework: String, p50_latency_us: u64, p95_latency_us: u64, p99_latency_us: u64, min_latency_us: u64, max_latency_us: u64, }

以下是在 ResNet-18 和 BERT-base 上的实测数据对比：

tract 在 BERT 上显示"—"，因为它主要面向 ONNX 导入的推理场景。对 Transformer 架构的原生支持不如 candle 和 burn。candle 在 ResNet-18 上表现最接近 PyTorch 基线。这受益于它直接使用 cuBLAS 作为 CUDA 后端。

在量化支持方面，candle 提供了最丰富的量化选项。包括 GGUF 格式的 Q4_K_M、Q5_K_M 等量化类型。burn 的量化支持仍处于早期阶段。tract 主要支持 FP16 转换。

四、各框架的适用场景与局限性

candle适合已经使用 HuggingFace 生态的团队。它直接支持从 HuggingFace Hub 加载 safetensors 格式的模型权重。API 设计贴近 PyTorch。CUDA 支持最为成熟，性能最接近 PyTorch。主要局限是某些高级算子仍需手工实现。ONNX 导入不够完整。

burn的最大优势是多后端架构。同一份代码可以在 wgpu（跨平台 GPU）、CUDA、CPU 和 WASM 上运行。这对需要"一次编译，多端部署"的场景非常有利。缺点是社区规模较小。遇到问题时文档和社区支持有限。性能在 CUDA 后端上略逊于 candle。

tract专注于 ONNX 模型推理。它实现了完整的 ONNX 规范支持。在算子覆盖广度上领先。特别是对那些通过 ONNX 导出的非标准模型（如推荐系统、传统 ML 模型）有更好的支持。但 tract 的 API 相对底层。上手成本较高。Python ONNX Runtime 仍是它最直接的竞争对手。

三个框架共同的局限是与 Python 生态的差距。它们都依赖 ONNX 作为中间格式来导入 Python 训练的模型。但 ONNX 导出的模型可能在算子精度上与原 PyTorch 模型有微小差异。这种差异在多层神经网络中可能累积。

五、总结

1. candle 在 CUDA 推理性能和 HuggingFace 兼容性方面表现最优。是 Rust 部署 Transformer 类模型的首选。
2. burn 的多后端架构（wgpu/CPU/CUDA/WASM）在跨平台部署场景中具有独特优势。写一份 Rust 代码即可覆盖多种终端。
3. tract 在 ONNX 算子覆盖上最为完整。适合通过 ONNX 导出非 Transformer 类模型（推荐系统、传统 CV）的推理场景。
4. 三个框架的 CUDA 后端性能仍比 PyTorch 低约 15%～25%。差距主要来自 cuDNN 的针对性优化（如 Winograd 卷积）。
5. 选型建议：Transformer 模型选 candle；多端部署选 burn；ONNX 模型导入选 tract；所有场景保留 PyTorch 作为精度基线对照。