圖:“Rust 的吉祥物 Ferris the Crab 從事人工智慧相關工作”,gemini-2.5-flash-preview,2025年09月21日。
AI 時代,這不用多說什麼了,而 Rust 又能夠扮演什麼角色呢?以 Python 這門語言來說,它的快速成長期剛好疊合在機器學習逐步爆發的年代,使得其能夠在這個領域獨領風騷,但實際上目前這領域並離不開 C/C++ 等的底層系統級語言。機器學習乃至目前人工智慧應用來說,底層邏輯依然是數值計算,C/C++ 早已有非常豐富,且無論是演算法優化、硬體加速等擁有龐大穩定的函數庫,所以實際上 Python 對相關應用的開發也是從巨人的肩膀上開始的。哪怕是因為 wrapper 的關係,或不同語言交互邏輯的情況以致效能不理想,但在那個快速實驗與驗證的時代,幾乎是唯一的選擇。
但至今顯然某些模型的應用,如:電腦視覺、聲音辨識、甚至大型語言模型等,都已經渡過心中想法理論需要快速得到實驗驗證的時代了,而落地應用在接下來必定是重中之重,而當中要優化和開發應付的面向固然是不一樣了。
Rust 生態系在這領域中,目前仍在發展當中,熱門常見的 crate
有:ort
、candle
、burn
、tch-rs
、tract
等。和昨日的 opencv
類似,以 C/C++ 實現底層數值計算的演算法的這一顆大樹早已非常穩健,一朝一夕想要完全由 Rust 從頭開始實現,顯然是不切實際的,而也待需要時間和應用場景進行驗證等。這篇文章會介紹以上常見的 crate
中具體是如何實現的。
Crate | 主要用途 | 核心機制 | 主要優勢 |
---|---|---|---|
ort | 推論 | FFI binding ONNX Runtime (C++) | 模型相容性強,效能取決 ONNX Runtime |
candle | 推論與訓練 | Rust 原生 Tensor 核心 + FFI 後端 | Hugging Face 生態、WASM 元件支持 |
burn | 推論與訓練 | 後端無關的抽象層 | 靈活性依據後端選擇所定 |
tch-rs | 推論與訓練 | FFI binding LibTorch (C++) | 與 PyTorch API 相似 |
tract | 推論 | 純 Rust 運算核心 | 輕量、零相依性、適合嵌入式或邊緣計算 |
ort 是 ONNX Runtime 的 Rust 綁定(binding)。ONNX (Open Neural Network Exchange) 是一個開放的模型格式標準,幾乎所有的主流訓練框架(PyTorch, TensorFlow, JAX)都能將模型匯出成 .onnx 格式。
ort 的核心是微軟開源的高效能推論引擎 ONNX Runtime。這個引擎本身是用 C++ 寫的,針對不同硬體(CPU, GPU, NPUs)進行了極致的最佳化。ort crate 的作用是提供一個安全、符合人體工學的 Rust 介面,讓我們可以透過這個介面去呼叫底層的 C++ 函式庫。
透過 FFI (Foreign Function Interface)。ort 本身是 Rust 程式碼,但它不執行任何運算。所有的神經網路計算都是透過 FFI 呼叫預先編譯好的 ONNX Runtime C++ 動態或靜態函式庫來完成的。你的 Rust 專案在編譯時需要連結到這個 C++ 函式庫。
candle 是由 Hugging Face 發起的專案,它是一個以 Rust 為中心、極簡且模組化的機器學習框架。它的設計深受 PyTorch 的啟發,但目標是更輕量、更適合伺服器端和 WebAssembly (WASM) 場景。
candle 的核心 (candle-core) 是一個 Tensor 函式庫,負責處理多維陣列的運算。它在設計上盡可能使用純 Rust 實現 CPU 上的運算。對於 GPU 加速,它會透過特定的後端(Backend)來達成。例如,candle-cuda 後端會呼叫 CUDA 函式庫來利用 NVIDIA GPU。它的架構非常模組化,讓使用者可以輕易地擴充或替換後端。
混合體,但核心為純 Rust。candle-core 的 CPU 運算部分是純 Rust 實現的。這使得它在沒有特殊硬體加速的環境下(例如 WASM 或輕量級伺服器)非常高效且易於部署。當你需要 GPU 加速時,它會透過 FFI 呼叫底層的硬體 API,例如 CUDA 或 Apple Metal。你可以將它理解為一個Rust 原生的核心,搭配可選的 FFI 加速後端。
burn 是另一個以 Rust 寫成的、注重靈活性與安全性的深度學習框架。它最大的特色是其後端無關 (Backend Agnostic) 的架構設計。
在 burn 中,你撰寫的神經網路邏輯與實際執行運算的後端是完全分離的。burn 提供了一個通用的 API 介面,開發者可以選擇在編譯時掛載不同的後端來執行。例如,它內建了:
取決於你選擇的後端。如果你使用 ndarray 後端,那麼整個計算過程就是純 Rust的。如果你使用 wgpu 後端,它本身是一個 Rust 函式庫,但它會與系統的圖形驅動(Vulkan, Metal, DirectX)互動,這層可以看作是低階的互動,但開發體驗上更接近純 Rust。如果你使用 tch 後端,那就是透過 FFI呼叫 C++ 函式庫。
機制與定位:這是 PyTorch 的 C++ 函式庫 (LibTorch) 的直接 Rust 綁定。如果你熟悉 PyTorch 的 API,你會發現 tch-rs 的 API 非常相似。它提供了非常全面的功能,幾乎涵蓋了 LibTorch 的所有能力。
純 Rust 還是 FFI?:純 FFI。與 ort 類似,tch-rs 本身是 Rust 的外殼,所有 Tensor 運算都轉交給底層的 LibTorch C++ 函式庫處理。
機制與定位:tract 是一個專為推論設計的嵌入式神經網路函式庫。它的主要目標是輕量、零相依性(或極少相依性)和可預測的效能。它支援 ONNX、NNEF 和 TensorFlow Lite 等多種模型格式。
純 Rust 還是 FFI?:核心為純 Rust。tract 的主要賣點之一就是它用純 Rust 實現了運算核心,這讓它在交叉編譯和部署到各種嵌入式平台(如 no_std 環境)時非常方便
不像 Python 生態系的 PyTorch
(或 TensorFlow
),這幾乎全都圍繞著其發展開來的狀況,目前 Rust 在人工智慧開發面來看,仍然還未達到一定的成熟度,甚至各有千秋,也說不上有一個共識的選擇。然而,這種大亂鬥的時代,我認為必定存在優勢,是一種值得探索冒險的優勢,強迫你去面對不穩定的現狀,當遇到後逐步去釐清背後的邏輯並實作解決,那種成長感很有價值!共勉之~