Mojo 與 Python 的效能之爭：快速人工智慧之戰

資訊科技數位 » recursos » Mojo 與 Python 的效能之爭：快速人工智慧之戰

Mojo 與 Python 的效能之爭愈演愈烈，因為它觸及了現代人工智慧的核心：真正的速度、易用性和硬體支援。近年來，一些加速資料浮出水面，乍看之下似乎天方夜譚，但實際上，這些進步得益於編譯器以及程式碼在 CPU、GPU 和 AI 加速器上的執行方式的深刻變革。

本文全面匯總了來自各種管道關於Python 的已發佈內容，包括其性能局限性以及 Mojo 的設計理念。 Mojo是一種基於模組化架構的語言，由 Chris Lattner（LLVM、Clang、Swift 的開發者）主導開發。此外，我們還解釋了 MLIR、GIL 瓶頸背後的原因、CUDA 和 MPS 的差異、與 Python 生態系統的兼容性以及未來仍面臨的推廣挑戰。

Python 在人工智慧領域佔據主導地位，但其架構不利於效能提升。

Python 成為人工智慧領域的通用語言並不令人意外：語法簡潔，擁有數千個函式庫、海量教學以及龐大的社群。然而，這種流行也帶來了一個令人不安的現實：Python 是解釋型語言，動態類型，並且受全域解釋器鎖定 (GIL) 的限制，這使得純 Python 程式碼的並發執行只能在單一執行緒中進行。

這種設計雖然能加快開發速度，但與 C/C++、Swift 或 Rust 等編譯型語言相比，速度和記憶體效率降低。在機器學習/深度學習工作負載中，每一毫秒都至關重要，而且硬體速度極快，因此這種效能損失非常明顯。

為了彌補這些不足，生態系統不得不採取一些變通方案：例如 NumPy（部分程式碼使用 C 和 Fortran 編寫）、委託給本機程式碼的函式庫，以及用於關鍵操作的 C/C++ 擴充。這些方案確實有效，但卻引入了層級、依賴關係，以及版本、框架和後端交織而成的複雜系統，使得在生產環境中維護起來非常棘手。

此外，Python 中的平行處理通常依賴多進程或函式庫在原生程式碼段中釋放 GIL。因此，除非工作負載能夠很好地委託給 C/C++ 或 GPU，否則 Python 的原始效能就會成為瓶頸。

NumPy 和其他「補丁」：必不可少，但也有局限性

NumPy 就是一個典型的例子：它的許多關鍵操作都是用C 或 Fortran寫的，這比純 Python 快得多。然而，在精細並行處理、擴展到多核心處理器或與新型加速器整合時，Python 的限制就再次顯現，尤其是在控制流程頻繁返回解釋器的情況下。

這種分層方法（Python → C/C++ 擴展 → 驅動程式/硬體）雖然有效，但調試和部署起來卻很複雜。在規模化人工智慧應用中，由於涉及訓練、推理和後處理等流程，這種運作複雜性幾乎與可用的浮點運算能力 (FLOPS) 一樣重要。

CUDA、MPS 和可移植性問題

CUDA加速（NVIDIA）固然是救星，但也如同金絲籠：某些模型和最佳化完全依賴 NVIDIA 協定堆疊。如果您嘗試在搭載 Metal Performance Shaders (MPS) 的Apple Silicon或 AMD GPU 上執行相同的程式碼，則可能會遇到不支援的指令或不完整的運算路徑。

最常見的比喻很明確：使用CUDA 就像駕駛一輛“法拉利”，而 MPS 在某些工作負載下可能會顯得功能有限。即便如此，業界仍在努力推進標準化和可移植性，因為除非絕對必要，否則沒有人願意將自己的業務綁定到單一硬體供應商。

MLIR：連結計算新時代的橋樑

要理解 Mojo 的方案，我們需要了解MLIR（多層中間表示），這是一個誕生於 LLVM 生態系統的項目，它添加了一種專為高性能和機器學習設計的中間表示。與傳統的 LLVM 管線不同，MLIR 可以處理資料圖、向量化、細分、DMA 插入和明確快取管理。

通俗地說：MLIR 可以將高階程式碼轉換為非常接近目標硬體（CPU、GPU、TPU、NPU、FPGA 等）的實現，提取並行性並應用經典編譯器在這些領域未能很好地涵蓋的HPC 最佳化。

Mojo究竟是什麼？

Mojo 是一種自詡為Python 超集的語言：它保持了熟悉的語法，可以利用相同的函式庫，並整合了由 MLIR 支援的現代編譯模型。它於 2023 年發布，最初是一個按需存取的Web Playground ，後來支援在GNU/Linux和 macOS 上本地執行。 2025 年 2 月，其標準函式庫開源，但編譯器至今仍是閉源的。

目標雄心勃勃：既要擁有 Python 的簡潔性，又要具備 C/C++ 的高效能，還要擁有 Rust 或 Swift 等語言的安全性和使用者友善性。換句話說，就是用高階語言編寫程式碼，並產生體積小、速度快、易於部署的二進位。

設計重點：類型、記憶體、結構體和函數

其中最引人注目的特點是強類型（以及在需要時使用靜態類型）、使用let/var聲明不可變和可變元素，以及支援具有編譯定義設計的結構體，這有助於產生最佳機器碼。

除了`def`之外， Mojo 還允許你使用`fn`聲明函數；一般來說，`fn`往往意味著更多的限制，因此編譯器擁有更好的最佳化潛力。它還具有“零成本抽象”和自適應調優功能，編譯器會根據目標平台選擇高效的參數。

無需 GIL 且真正實現並行化

與 Python 不同，Mojo 不依賴GIL。其運行時和編譯器旨在充分利用執行緒、向量和加速器，而無需開發者處理解釋器的基本並發問題。實際上，這意味著在 Python 中會遇到 GIL 問題的任務，在 Mojo 中可以真正並行運行。

這一點在密集型運算中至關重要：如果你能將一個問題分解成子任務，並以原生方式並發運行它們，那麼效能的提升就不是漸進式的，而是質的飛躍。

效能：從曼德布羅集到向量化版本

為了衡量改進效果，我們經常使用曼德勃羅集進行測試。曼德勃羅集是一種計算密集的分形產生器，非常適合併行化。據報道，純 Python 實作耗時超過1000 秒，而經過多次最佳化後，Mojo 實現的耗時已降至0,03 秒左右。

我們記錄了以下類型的改進過程：從最初的 Python 版本到 NumPy 版本，再到最初的 Mojo 版本，最後到使用 SIMD 指令集的向量化 Mojo 版本。透過這種改進流程，我們觀察到了巨大的速度提升，在特定情況下，速度提升幅度從 35.000 倍到 68.000 倍不等。這些數字非常驚人，但正如以往一樣，實際效果取決於演算法、硬體以及優化工作的細緻程度。

簡單的編譯和部署

Mojo 遵循「建置到二進位」的理念：建置完成後，即可取得可執行檔並進行分發。如果您之前使用過 Python，這種方式可以避免虛擬環境、wheel 套件以及各種函式庫版本相容性差等諸多問題。

舉個例子，可以用一個簡單的mojo 檔案 hello.mojo編譯並執行「Hello World」程式。此外，這些檔案都帶有.mojo副檔名（火焰表情符號也逐漸被用作眨眼表情），這使得它們在混合項目中更容易識別。

Python 相容性和生態系統

Mojo 的魅力之一在於它不會強迫你放棄你已經擁有的東西：它與 Python 生態系統的兼容性意味著你可以繼續使用 NumPy、Pandas 或 Matplotlib 等函式庫，同時在需要時採用更有效率的結構和類型。

實際上，這種「Python++」策略可以平滑採用曲線：您可以維護自己的程式碼庫，將熱門部分遷移到 Mojo，並利用編譯器和 MLIR 來提高效能，而無需放棄您熟悉的語法。

模組化：一個統一 PyTorch 和 TensorFlow 的執行環境

除了程式語言之外，Modular 還引入了一個通用框架/執行時間環境，無需分別安裝PyTorch 和 TensorFlow即可運行這兩個技術堆疊。根據相關資料顯示，其架構可將 TensorFlow 的執行速度提升至3 倍，將 PyTorch 的執行速度提升至2,5 倍，同時也整合了量化工具，有助於提升 AI 的可擴充性。

我們的願景是避免「三層」地獄（Python → C/C++ → 特定硬體），採用單一編程層和後端，可以與任何硬體通信，並充分利用每個平台，而無需每隔一天就重寫模型。

量化：在不犧牲精度的前提下縮小尺寸

模型量化就像神經網路的MP3：降低某些權重/層的準確率，作為交換，可以減少模型規模並加快推理速度。準確率的損失通常很小（例如，分類器從94%降至91%），而部署和速度的提升足以彌補這一損失。

這種方法是實現將模型部署到本地設備並同時保障隱私的關鍵。事實上，像Core ML這樣的技術堆疊以及像蘋果的NPU（透過 MPS/Accelerate）這樣的加速器，都在致力於開發壓縮模型，使其能夠適配並流暢地在 iPhone 或 Mac 上運行，而無需將資料傳送到雲端。

從 Swift for TensorFlow 到 Mojo：Lattner 的歷程

走到今天這一步並非偶然。克里斯·拉特納 (Chris Lattner)曾在蘋果公司 (LLVM、Clang、 Swift ) 工作，之後又先後就職於特斯拉和谷歌大腦，並在谷歌大腦主導了Swift 與 TensorFlow 的結合。儘管這項將現代語言與機器學習結合的嘗試最終被擱置，但它所累積的經驗如今已在 MLIR 和 Mojo 的設計中得以體現。

在 Modular 之前，Lattner 也涉足了RISC-V領域（SciFive），這與人工智慧的未來涉及多種硬體的想法相符，我們需要能夠快速適應所有這些硬體的編譯器和運行時。

專案狀態、支援和採納

Mojo 於 2023 年發布，雖然這門語言發展迅速，但仍處於成熟階段。其標準庫於 2025 年 2 月開放，但編譯器仍閉源。就流行度（TIOBE 指數）而言，Mojo 的排名低於前 50，這對於一門僅有兩年歷史的語言來說也在意料之中。

在「支持者」部分，提到了亞馬遜、AMD、NVIDIA 和 Inworld的支援。即便如此，要想與 Python 競爭，它仍然需要一個社群、完善的文件、豐富的軟體包以及能夠作為其他語言標竿的成功案例。

挑戰：社群、反思與動態特徵

除了表演之外，Python 在社區、資源和生態系統方面也更勝一籌。 Mojo 需要彌補 Python 在某些優勢領域的不足，例如某些反射機製或廣泛使用的動態模式。此外，它還需要不斷提升使用者友善性，以實現從 Python 到 Mojo 的無縫過渡。

從技術角度來看，「為所有平台編譯」的承諾聽起來很棒，但每個後端（CUDA、ROCm、MPS、TPU、FPGA…）都有其自身的細微差別。在運行時保持所有後端功能和性能的一致性是一項馬拉松，而不是短跑。

Mojo 與 GPU：超越 NVIDIA

Mojo 和 MLIR 的優勢之一在於它們能夠同時支援 NVIDIA 和 AMD 的 GPU，而不僅僅是 CUDA 生態系統。如果這種支援能夠保持最新且具競爭力，許多公司將會意識到不被單一供應商鎖定所帶來的策略優勢。

同時，蘋果世界（包括MPS）和其他專用加速器（NPU、FPGA）也需要合適的編譯路徑和函式庫。 「一次編寫，到處快速運行」的承諾雄心勃勃，如果能夠真正實現，將徹底改變遊戲規則。

爭論：是開發新語言，還是開發「Python++」？

在技​​術論壇上，人們爭論Mojo 究竟是「Python 的另一個變體」，還是僅僅共享語法的新語言。對於日常使用而言，關鍵在於你可以重複使用程式碼和函式庫，同時還能編寫具有更豐富類型和結構的高效能元件。

這種二元性，再加上現代 MLIR 編譯器，使得「hello world」既用戶友好，又能夠讓你的計算內核在向量化場景中達到甚至超越 C/C++ 的效能。

資源、社區與學習

如果你剛開始接觸人工智慧，開放學習社群將非常寶貴。這些面向學生和教師的平台提供了提問、分享資源以及從基礎到高級技術循序漸進學習的機會。它們是練習、比較不同方法並獲得實際應用答案的絕佳場所。

推廣生態系統也發揮著重要作用：從Jeremy Howard 等專家撰寫的Mojo 發布概要，到影片平台上提供的免費 Python 課程，讓你無需任何費用即可開始編寫程式碼。圍繞 Mojo 的社群越強大，企業和開發者就越容易採用它。

實用筆記和有趣細節

一些看似不起眼的小細節也能帶來顯著的提升：例如.mojo檔案、對fn / def函數的支援、使用mojo指令直接執行，以及明確提供易於分發的二進位檔案。這些看似平凡的細節，在專案規模擴大時卻能發揮至關重要的作用。

同時， Rust 和 Swift對型別設計、記憶體安全和零成本抽象的影響也不容忽視。這並非巧合：Lattner 曾參與 Swift 的創建和 LLVM/Clang 的開發；這種傳承在編譯器的設計中顯而易見。

從實驗室到生產：您可以期待什麼

如果你今天打算嘗試 Mojo，那麼最好將其用於高影響力模組（例如計算核心、密集型轉換或緊密循環）。保持你的編排和工具使用 Python，並將高需求元件遷移到 Mojo，以便從指標中衡量其帶來的實際收益。

根據分析的報告，Mandelbrot 類型的任務或 SIMD 核心實現了巨大的速度提升。在實際的管線中，考慮到 I/O、預處理和第三方函式庫，雖然速度提升幅度較小，且取決於主要瓶頸，但仍能獲得顯著的效能提升。

統一層：告別“弗蘭肯斯坦式堆疊”

模組化技術堆疊的一項關鍵優勢在於各層的統一：它摒棄了以往分散的 Python + C/C++ + 特定後端架構，而是為所有三層提供單一語言，並配備一個能夠與硬體互動的執行環境。這樣一來，程式碼「黏合劑」更少，不相容性更低，防禦性維護工作也更少。

如果這個願景得以實現，訓練和推理過程就可以在NVIDIA、AMD、Apple Silicon、TPU或NPU之間自由切換，而無需對專案進行徹底的重新編程。這不僅僅是一個技術細節，更是一種商業策略：可以根據成本、可用性或能源效率自由選擇硬體。

關於語音模型和轉錄的明確

在實際應用中，當把像Whisper（轉錄）這樣的模型從 Python 移植到原生路由或其他 API（MPS/Accelerate）時，會遇到相容性問題：某些指令存在於 CUDA 中，但不存在於 MPS 中，反之亦然。這時，統一的後端和支援 MLIR 的編譯器就能幫你省去很多麻煩。

如果沒有這種通用的黏合劑，最終會導致程式碼分支過多和手動移植，從而減緩專案的演進速度。有了它，就有望實現一次編寫，即可在所有支援的平台上獲得高效的路由。

「元」背景：對外宣傳、贊助以及科技社區

這場辯論的部分素材來自播客和技術博客，它們將教育內容與贊助和社區（甚至週邊產品）相結合。除了這些軼事（課程、應用程式、Twitch、背景音樂、播客網路支援…）之外，有趣的是，這場技術辯論已經超越了其小眾群體，引起了廣泛受眾的共鳴。

這種討論是好事：它能帶來棘手的問題、真實的應用案例以及各種硬體的使用經驗。擴大關於 MLIR 和 Mojo 的討論範圍，有助於加速缺陷檢測、遷移指南的編寫，以及創建我們都能重複使用的方案。

整體趨勢很明確：Python 仍將是通往人工智慧的門戶，但當性能至關重要時，一個務實的替代方案已經存在。 Mojo 的目標並非取代 Python，而是透過現代編譯器、真正的平行化以及能夠同時理解當前和未來加速器的運行時層來提升其效能。如果您從事機器學習/深度學習工作，並且對每次推理或訓練週期的時間/成本非常敏感，那麼不妨使用您自己的資料和硬體進行嘗試。