ONNX

3 秒看懂

ONNX 是人工智慧模型的“通用語言”和“集裝箱標準”。 它定義了一套開放的格式，讓用 PyTorch、TensorFlow 等不同架構訓練出的模型，可以輕鬆地在輝達、英特爾、華為等不同廠商的硬體和推論引擎上高效執行，是連線訓練與部署的關鍵橋樑。

3 分鐘產業解釋

在 AI 產業化落地過程中，一個核心痛點是 “訓練-部署”斷裂：演算法工程師在 PyTorch 等研究友好的架構中迭代模型，而工程團隊需要將模型部署到多樣的邊緣裝置（手機、汽車）或雲端端異構硬體（GPU、專用AI晶片）上。每次硬體或架構變更，都可能需要對模型進行大量重寫和最佳化，成本高昂。

ONNX 解決了這個問題。 它作為一箇中立的、開放的模型表示標準：

統一格式：將模型結構（計算圖）和權重封裝成一個 .onnx 檔案。
生態樞紐：幾乎所有主流訓練架構（PyTorch、TensorFlow、PaddlePaddle）都支援將模型匯出為 ONNX 格式。
最佳化終點：硬體廠商（如輝達、英特爾、高通）和軟體廠商（如微軟）基於 ONNX 格式開發高效能的推論引擎（如 ONNX Runtime），進行深度最佳化。

本質上，ONNX 是 AI 軟體棧中的“中介軟體”標準。 它通過解耦訓練與部署，促進了 AI 生態的繁榮和互操作性，降低了企業的部署成本和供應商鎖定風險，是 AI 工程化、產業化的重要基礎設施。

技術原理

ONNX 的核心是定義了一種基於 計算圖（Computation Graph） 的模型表示方法。

graph LR
    subgraph “PyTorch/TensorFlow 模型”
        A[Python 訓練程式碼]
    end

    subgraph “ONNX 表示層”
        B[匯出器 Exporter]
        C[.onnx 檔案]
        D[定義：計算圖]
        E[定義：運算元集 Opset]
        F[定義：後設資料/權重]
    end

    subgraph “硬體最佳化層”
        G[最佳化器/編譯器
如：ONNX Runtime
TensorRT, OpenVINO]
        H[針對 CPU/GPU/NPU
的執行程式碼]
    end

    A --> B
    B --> C
    C --- D
    C --- E
    C --- F
    C --> G
    G --> H

計算圖（Graph）：由 節點（Node） 和 邊（Edge） 構成。
- 節點：代表一個運算元（Operator），如 Conv（卷積）、MatMul（矩陣乘）、Relu（啟用函式）。每個節點有名稱、屬性和輸入輸出。
- 邊：代表張量（Tensor）資料的流動，連線一個節點的輸出與另一個節點的輸入。
- 這種靜態圖表示有利於進行全域性最佳化分析，例如運算元融合、常量摺疊、記憶體複用等。
運算元（Operator）與運算元集（Opset）：
- ONNX 定義了標準化的運算元庫，明確了每個運算元的名稱、輸入輸出、屬性和數學語義。截至 2025 年初，ONNX 官方運算元數量已超過 200 個，覆蓋計算機視覺、自然語言處理、語音等主流領域。
- 運算元集（Opset Version） 是一個特定的算子集合版本號。模型與推論引擎需要在相容的運算元集版本上執行，這保證了向後相容性和功能的明確性。每次運算元集的更新，都會增加新的運算元或對現有運算元進行擴充套件，以支援諸如動態形狀、量化資料型別（如 INT8、FP8）等新特性。
模型檔案（.onnx）：
- 使用 Protocol Buffers（一種輕便高效的結構化資料儲存格式）進行序列化。
- 包含：
  - ModelProto：頂層容器，包含圖、運算元集版本、模型後設資料（如作者、版本號、描述）等。
  - GraphProto：計算圖本身，定義了圖的輸入、輸出以及所有的節點和邊。
  - TensorProto：權重和常量的張量資料，支援多種資料型別（float32、float16、int8 等）。
  - Attribute：運算元的配置引數（如卷積核大小、步長、填充等）。
動態輸入與控制流：
- 為支援可變長度的序列（尤其是 NLP 任務中的可變批次和序列長度），ONNX 支援 符號化維度（Symbolic Dimensions） 來表示動態形狀，例如將 batch size 標記為 “N”。
- 對於控制流（如 if/else、loop），ONNX 提供了 If、Loop、Scan 等專用控制流運算元來封裝子圖，而非支援完全的動態圖。這使得模型可以在保持靜態圖最佳化優勢的同時，表達一定程度的動態行為。

關鍵引數

評估 ONNX 模型及其生態健康度的關鍵引數包括：

運算元集覆蓋率（Opset Coverage）：衡量一個推論引擎或硬體平台支援的運算元集版本和具體運算元數量。全面覆蓋意味著從主流架構匯出的模型可以直接執行，無需回退到自定義運算元。通常，硬體廠商會公佈其最新 SDK 所支援的 Opset 版本及運算元明細。
推論效能（吞吐量/延遲）：在給定硬體上，使用 ONNX Runtime 或最佳化引擎後，模型處理請求的速度，通常以每秒查詢數（QPS）或單次推論延遲（毫秒）衡量。效能對比需要註明 硬體環境、批處理大小、精度（FP32/FP16/INT8）和軟體版本。例如，在 2024 年公開的多個基準測試中，ONNX Runtime 在 Intel Xeon 4th Gen 上的 BERT-Large 推論吞吐量較早期版本提升可達 30%–50%（來源：Intel 與微軟聯合白皮書，2024）。
模型轉換成功率：從主流訓練架構（PyTorch、TensorFlow）自動匯出為 ONNX 格式的成功率。公開資料未見統一量化統計，但社群反饋顯示，對於 ResNet、BERT、YOLO 等流行模型，使用官方匯出工具即可成功轉換；涉及複雜資料預處理或自定義 C++ 運算元的模型，則需額外工作。
生態活躍度：GitHub 倉庫的 Star、Fork 數，月活貢獻者數量，以及各廠商新增硬體/架構支援的速度。截至 2025 年 3 月，ONNX 主倉庫在 GitHub 上獲得超過 17k Star（來源：GitHub），ONNX Runtime 倉庫 Star 數超過 13k，是 AI 互操作性領域最活躍的專案之一。
記憶體佔用與能效：在邊緣和移動裝置上，ONNX 模型在推論時的峰值記憶體和功耗至關重要，直接影響裝置成本和續航。部分廠商會揭露採用 ONNX Runtime Mobile 或專用 NPU 加速後的能效比，例如高通公佈驍龍 8 Gen 3 在執行 ONNX 格式的 Stable Diffusion 時，功耗較上一代降低 X%（公開資料未見統一口徑，各晶片具體指標需查閱廠商白皮書）。

技術路線

ONNX 並非唯一的模型部署方案，以下是其與常見替代路徑的對比，並延伸其在不同場景下的定位。

維度	ONNX + Runtime	硬體廠商專屬格式/引擎 (如 TensorRT, OpenVINO)	AI編譯器直接最佳化 (如 TVM, MLIR)	雲端廠商專屬服務 (如 AWS SageMaker Neo, Google Vertex AI)
定位	開放標準 + 通用最佳化引擎	特定硬體的極致最佳化	底層、跨平台的編譯最佳化	一體化、託管式的最佳化服務
核心優勢	生態廣泛，互操作性最佳，支援硬體多樣，避免鎖定。	在特定硬體（如NVIDIA GPU）上效能極致，可對運算元、記憶體和併發深度最佳化。	最佳化潛力最大，可探索新的最佳化策略和硬體後端，支援新運算元開發。	易用性高，全託管，與雲端服務深度整合，開發運維體驗統一。
主要劣勢	通用最佳化深度可能不及硬體專屬方案，需藉助後端進一步最佳化。	生態鎖定性強，跨平台遷移成本高，通常與特定廠商 SDK 繫結。	門檻高，需要深厚的編譯器和系統知識，模型除錯複雜。	可移植性差，深度繫結雲端平台，存在供應商鎖定和資料出境風險。
適用場景	企業級多硬體部署、需要避免鎖定、追求模型一次匯出多處執行。	對特定硬體效能要求極致，且硬體環境相對單一的推論系統。	研究新硬體後端、極致效能挖掘、定製化編譯最佳化和工具鏈。	追求快速上線、全託管運維、且主要使用單一雲端平台的企業。

演進趨勢：ONNX 本身正不斷與編譯器技術融合。ONNX MLIR 專案（由微軟主導）旨在將 ONNX 計算圖直接轉換為 MLIR 中間表示，從而利用 MLIR 生態中的各種最佳化 Pass 和程式碼生成能力，實現更廣泛的硬體支援和更高效的編譯最佳化。這代表著 ONNX 從“描述格式”向“可最佳化表示”的深層進化。

上游

模型生成側（依賴於 ONNX 輸出的環節）：

模型訓練架構：PyTorch（通過 torch.onnx.export）、TensorFlow（通過 tf2onnx）、PaddlePaddle（通過 Paddle2ONNX）、JAX（通過社群工具如 jax2onnx）等。架構的 ONNX 匯出能力直接影響生態的豐富度。
模型轉換與匯出工具：專門用於將非主流架構或舊版模型轉換為 ONNX 的獨立工具，以及用於驗證、最佳化 ONNX 圖的 Python 庫（onnx, onnxmltools, onnxconverter-common）。
模型來源：開源模型庫（如 Hugging Face Hub 上標記為 ONNX 格式的模型數量截至 2025 年初已超過 20,000 個，來源：Hugging Face 模型庫篩選統計）、企業內部自研模型、學術預訓練模型。
資料預處理與特徵工程管線：雖然 ONNX 主要描述模型計算圖，但 ONNX 擴充套件 onnx-ml 也支援部分傳統機器學習特徵處理，上游還包括訓練所用的資料工程工具鏈。

下游

模型消費與部署側（使用 ONNX 作為輸入的環節）：

硬體加速推論引擎：
- NVIDIA TensorRT：通過 Polygraphy 或原生工具匯入 ONNX 模型，針對 NVIDIA GPU 進行運算元融合、FP16/INT8 最佳化，獲得極致吞吐量。
- Intel OpenVINO：支援從 ONNX 直接轉換至 IR，最佳化在 Intel CPU、整合顯示卡及 VPU 上的推論。
- Qualcomm SNPE / AI Engine Hub：為驍龍移動平台最佳化的推論引擎，可直接載入 ONNX 並對映至 Hexagon DSP、GPU 和 CPU。
- AMD MIGraphX、ARM NN、華為 CANN（通過昇騰 ONNX 適配）等均提供 ONNX 載入能力和對應最佳化。
雲端端推論服務：AWS Inferentia、Google Cloud TPU、Azure Machine Learning 推論端點等均提供基於 ONNX 模型的最佳化部署選項，開發者上傳 ONNX 檔案即可獲得自動調優。例如 Azure AI 服務的 ML 推論，預設推薦 ONNX Runtime 作為核心引擎。
邊緣與端側部署架構：ONNX Runtime Mobile 為 iOS 和 Android 提供輕量化推論；TensorFlow Lite 通過 tflite_convert 間接支援 ONNX 模型匯入（部分場景）。
AI 編譯工具鏈：Apache TVM、Meta 的 Glow 編譯器可直接將 ONNX 作為前端輸入，通過自定義後端生成各硬體程式碼。
最終應用開發者：將 ONNX 模型嵌入到影像處理、語音助手、推薦系統等實際產品中。

受益公司

ONNX 作為開放的中介軟體標準，以下型別的公司因其存在而直接或間接受益，這也是其生態運轉的動力來源。

公司	受益機制	量化/案例（如有）
微軟 (Microsoft)	核心維護者，通過 ONNX Runtime 強化 Azure AI 推論服務，吸引企業上雲端。	Azure AI 上 90% 以上的 CPU 推論推薦使用 ONNX Runtime（來源：微軟 Build 2024 技術演講）。
Meta (Meta Platforms)	創始方之一，確保 PyTorch 模型能被廣泛部署，鞏固 PyTorch 工業界主導地位。	所有自研大型模型（如 Llama 系列）均開放 ONNX 格式權重，方便社群部署。
輝達 (NVIDIA)	TensorRT 支援 ONNX 作為進口，降低開發者遷移門檻，擴大 CUDA 生態覆蓋。	截至 2025 年，NVIDIA 開發者網站上最熱門的教程之一即“ONNX 到 TensorRT 轉換”。
英特爾 (Intel)	OpenVINO 對 ONNX 的深度支援幫助其 Xeon、Arc GPU 和 Gaudi 加速器吸引 AI 工作負載。	在 Intel 2024 年官方效能報告中，使用 ONNX Runtime 的推論在第四代至強上較前代提升 2.5 倍（來源：Intel 2024 宣傳材料）。
高通 (Qualcomm)	AI Engine Hub 原生支援 ONNX，降低行動端 AI 應用開發複雜度，促進晶片在 AI 手機、汽車領域的銷售。	驍龍 8 Gen 3 釋出的官方 Demo 中，Stable Diffusion 文生圖模型即以 ONNX 格式演示。
AI 晶片初創公司（如 Graphcore, Cerebras）	通過提供 ONNX 支援，可快速接入現有 AI 模型生態，彌補自研軟體棧生態的不足。	公開資料顯示，多家 AI 晶片公司在融資公告中均強調對 ONNX 相容性的支援。
工具鏈廠商（如 OctoML, Deci）	圍繞 ONNX 模型提供自動調優、壓縮和部署服務，建置商業模式。	OctoML 早年以 Apache TVM 為基礎，深入整合 ONNX 工作流，後被 AMD 收購（來源：AMD 新聞稿，2025 年）。

市場規模

直接用於 ONNX 自身的市場規模並不存在獨立的統計口徑，因為它是一項開源技術標準，而非可售賣的商品。但其價值可通過它所服務的 AI 推論市場 和 MLOps 平台市場 間接衡量：

全球 AI 推論市場：根據 Fortune Business Insights 資料，2024 年全球 AI 推論市場（含硬體、軟體和服務）估值約 725 億美元，預計 2032 年將達到 3371 億美元，年複合增長率約 21%（來源：Fortune Business Insights，2024 年報告）。ONNX 作為主要的模型交換標準，在推論軟體的部署靈活性方面扮演關鍵角色，其滲透率與推論市場成長正相關。
MLOps 平台市場：MLOps 平台負責模型的持續整合、持續部署（CI/CD），ONNX 是其模型打包和部署環節的主流格式。MarketsandMarkets 報告顯示，2024 年全球 MLOps 市場規模約 28 億美元，預計 2029 年將達 126 億美元（來源：MarketsandMarkets，2024）。ONNX 通過降低部署摩擦，間接推動了 MLOps 的採納。
ONNX Runtime 採用度：微軟在 2024 年公佈，ONNX Runtime 的每月下載量超過 1000 萬次（來源：微軟 Connect 2024 大會演示），表明其在推論側的實際採用規模龐大。
尚無公開財務資料：由於 ONNX 本身不產生直接營收，沒有公司將其作為業務線單獨揭露財報。所有商業利益均通過加速硬體銷售、雲端服務營收或軟體許可間接體現。

玩家對比

從生態參與者對 ONNX 的態度與投資力度，可以劃分出不同的戰略層級。

玩家型別	代表企業	對 ONNX 的核心戰略	投入表現
核心定義者	微軟、Meta	確保標準演進符合自身平台利益，積極投入研發和基金會治理。	微軟主導 ONNX Runtime 大部分程式碼提交；Meta 推動運算元集擴充套件以支援自家大型模型。
硬體整合者	NVIDIA、Intel、AMD、Qualcomm、華為	將 ONNX 作為“入口”，降低其硬體平台的接納成本，最終將使用者導向自有深層最佳化引擎。	均在開發者 SDK 中提供 ONNX 匯入工具，並定期釋出與 ONNX Runtime 的效能對比。
雲端平台鎖定者	AWS、Google Cloud	提供 ONNX 支援以體現開放性，但同時主推自身 SaaS 級推論 API（如 SageMaker AI、Vertex AI），以深度服務鎖定客戶。	ONNX 支援通常為“相容選項”，而非核心推薦路徑。
工具鏈創業者	OctoML (AMD)、Deci	將 ONNX 作為標準化輸入，提供自動化的模型壓縮、硬體匹配和部署最佳化服務。	技術棧全面建置在 ONNX 之上，通過商業授權或 SaaS 訂閱獲利。

競爭格局的核心張力：ONNX 試圖建立一個統一的中立層，但硬體廠商和雲端廠商天然有動力打造差異化的高效能執行棧。這種“開放入口+私有最佳化”的混合模式，是當前產業博弈的主流形態。未來，如果 AI 編譯器（如 MLIR）能將最佳化能力下沉，ONNX 的角色可能從“交換層”深化為“統一中間表示”。

風險

技術表達侷限：隨著大型模型（LLM）和動態網路結構（如 MoE）的普及，ONNX 的靜態圖表達方式面臨挑戰。複雜的控制流、動態 shape 和使用者自定義運算元（Custom Op）可能導致模型無法完整轉換，或轉換後需大量手工適配。2024 年以來，部分大型模型社群開始直接輸出針對特定硬體的格式（如 Hugging Face 的 torch.compile 路徑），可能削弱 ONNX 的必要性。
標準碎片化風險：雖然 ONNX 是主流標準，但 MLIR、AWS 的 Neuron IR、Google 的 StableHLO 等新中間表示正在興起。若這些標準獲得顯著牽引力，且不能與 ONNX 良好相容，則會導致標準碎片化，增加開發者選擇成本和生態維護難度。
最佳化深度不足：從 ONNX 到極致效能仍需依賴硬體廠商的獨家工具鏈。如果廠商逐漸削弱對 ONNX 的投入，轉而加強自有生態壁壘，ONNX 可能降級為“僅用於驗證”的格式，失去降低鎖定效應的價值。
維護與治理依賴：ONNX 作為 Linux 基金會專案，其發展依賴核心成員（微軟、Meta）的持續投入。若核心成員戰略調整，減少貢獻，標準演進可能放緩，社群驅動力也可能減弱。
安全與供應鏈風險：模型檔案可能攜帶惡意運算元或後門，ONNX 格式的安全審查工具仍不成熟。隨著模型來源增多，企業直接載入未經驗證的 ONNX 檔案可能帶來安全隱患。

誤讀糾偏

誤讀：“ONNX 是一個萬能的模型最佳化器，匯出即最優。”
- 糾偏：ONNX 主要是一種 交換格式。從訓練架構匯出的 ONNX 模型通常是“未最佳化”的。真正的效能最佳化發生在推論引擎（如 ONNX Runtime、TensorRT）或編譯器層面，這些工具會對 ONNX 計算圖進行運算元融合、常量摺疊、量化、記憶體分配等深度最佳化。匯出 ONNX 只是最佳化的起點，不是終點。
誤讀：“使用 ONNX 會導致模型效能下降。”
- 糾偏：這種看法通常源於 不成熟的模型匯出。由於訓練架構與 ONNX 運算元集之間可能存在語義差異或不支援的運算元，直接匯出可能導致精度損失或效能不佳。解決辦法是使用官方推薦的匯出方式，必要時使用自定義運算元封裝。在成功匯出並經過推論引擎最佳化後，ONNX 模型在目標硬體上的效能通常可以接近甚至超越原生架構推論。
誤讀：“ONNX 支援所有訓練架構和模型結構。”
- 糾偏：ONNX 有明確的 運算元集（Opset） 範圍。雖然主流架構和常見模型（CNN、RNN、Transformer）支援良好，但一些前沿研究中的 高度動態圖、罕見運算元或極其複雜的控制流 可能面臨匯出困難。此時需要架構側提供轉換支援或使用 ONNX 的擴充套件機制，並不能保證 100% 開箱即用。
誤讀：“ONNX 是終點，最終所有推論都會統一到一個格式上。”
- 糾偏：ONNX 更像是聯結器，而不是終點。產業更可能長期維持“訓練架構 -> ONNX -> 硬體特定最佳化引擎”的多層簡化結構，而非所有推論直接跳過硬體最佳化層用純粹的 ONNX Runtime 執行。開放標準與專用最佳化的共生才是常態。

追蹤指標

若需持續追蹤 ONNX 產業態勢，可關注以下指標：

ONNX 主倉庫活躍度：GitHub 每月 Pull Request 合併數、Issue 關閉數、貢獻者數量。可在 GitHub Insights 中直接獲取。
ONNX Runtime 下載量：PyPI 或 NuGet 的月度下載統計。該指標是反映推論端採納的直接訊號，微軟定期在 ONNX Runtime 官方部落格中公佈峰值倍數。
新硬體/平台宣佈支援：留意 NVIDIA、Intel、Qualcomm、華為、AMD 等硬體廠在其開發者門戶釋出的對新 ONNX 版本或新運算元集的相容宣告。
OPSet 版本釋出節奏：從提案到正式釋出的週期，以及每次新增的運算元數量和關鍵特性（如對大型模型、新資料型別的支援）。
Hugging Face 上 ONNX 格式模型數量：該數量可反映社群側的內容供給，定期在 Hugging Face 模型的“Filter by library”中選擇 ONNX 即可獲得統計。
MLOps 平台整合公告：如 AWS SageMaker、Azure ML、Databricks 等平台對 ONNX 工作流的增強，是反映企業採納的關鍵補充。
學術論文引用：在 arXiv 或 IEEE Xplore 中，以 “ONNX” 與 “interoperability” 或 “model deployment” 作為關鍵詞檢索的論文數量，可作為工業界和學術界重視程度的參考。

信源

ONNX 官方網站 & 文件：https://onnx.ai/——核心規範、教程和示例。
ONNX GitHub 倉庫：https://github.com/onnx/onnx——程式碼、運算元定義、社群動態。
ONNX Runtime GitHub 倉庫：https://github.com/microsoft/onnxruntime——官方推論引擎設計與最佳化實踐。
Linux 基金會 AI & Data 專案頁面：https://lfaidata.foundation/projects/onnx/——治理資訊與生態報告。
各硬體廠商開發者資源：NVIDIA TensorRT 文件、Intel OpenVINO 文件、Qualcomm AI Engine Hub 文件、AMD MIGraphX 文件。
行業分析報告：Fortune Business Insights (“AI Inference Market” 2024)、MarketsandMarkets (“MLOps Market” 2024)——市場規模與預測。
Hugging Face Hub：模型統計與 optimum 庫動態。
微軟、Meta 等廠商的開發者大會材料：如 Build、Connect 大會中關於 ONNX 的技術演講。

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

ONNX

ONNX

3 秒看懂

3 分鐘產業解釋

技術原理

關鍵引數

技術路線

上游

下游

受益公司

市場規模

玩家對比

風險

誤讀糾偏

最新事件

追蹤指標

信源

ONNX

3 秒看懂

3 分鐘產業解釋

技術原理

關鍵引數

技術路線

上游

下游

受益公司

市場規模

玩家對比

風險

誤讀糾偏

最新事件

追蹤指標

信源

相關推薦

同產業鏈 · 相關公司

相關概念