各位開發者，Mojo 1.0 Beta 的到來，象徵著 Python 效能瓶頸的劃時代變革，尤其是在人工智慧與高效能運算這類高要求的領域。這不僅僅是另一種號稱速度更快的語言；它是一次精心設計的重新構想，旨在充分利用你我熟悉的 Python 語法，同時釋放各種硬體的強大運算力。
幾十年來，Python 開發者一直飽受效能瓶頸的困擾與折磨。當速度開始變得至關重要時，我們只能選擇用 C++ 或 Rust 重寫程式碼——這意味著要切換語言、維護兩套程式碼庫，並且不得不接受這種無可避免的摩擦。
而 Modular 於 2026 年 5 月 9 日正式發布了 Mojo 1.0 beta 版 (v1.0.0b1)，它號稱能夠消除這種取捨：它擁有 Python 的語法，亦能達到 C/Rust 的效能，並且從底層構建，專為 AI 基礎設施和 GPU 程式設計打造。
如果 Mojo 果真能夠實現這一目標，那麼雙語言的問題或許將成為過去式。
重大變更訊號：API 穩定化
Mojo 1.0 測試版引入了三項重大變更，讓開發者能夠立刻採取行動。這些變更並非隨意為之——它們標誌著該語言正朝著 2026 年稍晚發布的 1.0 正式版穩步邁進。
首先，fn → def 合併。關鍵字 fn 已被棄用。所有函式宣告現在都使用 def。目前，使用 fn 會觸發編譯器警告；下一個版本將把它改為硬性錯誤。遷移過程很簡單——只需尋找並取代——但此舉藉由降低認知負荷來簡化語言，往後所有函式都使用同一個關鍵字。
其次，預設情況下指標不可為空。UnsafePointer 現在被重新設計為不可為空。如果需要可為空的指標，請使用 Optional[UnsafePointer[...]] 做顯式宣告。這是從 Rust 引進到 Python 語法中的記憶體安全機制。它的優勢在於：零開銷的外部函式介面安全性。可空性被明確化，意味著更少的執行時期崩潰和更多的編譯時期攔截。
第三，移除負索引。類似 x[-1] 這樣的表達式現在會產生編譯時期錯誤。您必須使用基於長度的顯式索引方式：x[len(x) - 1]。這確實比較冗長，但對於系統程式設計來說，顯式索引優於隱式索引。當清晰度和便利性發生衝突時，Mojo 會優先考慮清晰度。
這些變化為何如此重要？beta 版本中的重大變更表明 Modular 正在鎖定 API，重大語法變更的窗口期正在關閉。如果你正在考慮使用 Mojo，現在正是進行實驗的最佳時機，因為 1.0 正式版將最終確定設計藍圖。此外，Modular 正從 Python 2 到 3 的升級中吸取教訓。Mojo 2.0 計劃提供漸進式遷移路徑、實驗性標誌以及對混合生態系的編譯器支援。他們在穩定當前的同時，也在為未來進行規劃。
GPU 效能於各大廠商間實現飛躍
Mojo 1.0 beta 版大幅擴展了其 GPU 的支援，旨在實現連 CUDA 都無法比擬的跨廠商相容性。該版本新增了對 Apple Metal M5 MMA 硬體矩陣乘加運算的支援、對 AMD MI250X GPU 和 NVIDIA B300 (sm_103a) 加速器的支援。
此外，Apple Metal 還新增了 print() 偵錯支援和動態執行緒群組記憶體——這些看似微小的改進在偵錯 GPU 程式碼時卻是至關重要的救命丹。
Mojo 的戰略佈局顯而易見：只需編寫一次程式碼，即可在 NVIDIA、AMD 或 Apple 的硬體上執行。沒有廠商鎖定，也無需獨立的 CUDA 程式碼。這就是統一異構運算的優勢所在，而 Mojo 認為 AI 基礎設施的蓬勃發展將使其成為必然之選。
一些真正的人工智慧技術公司已經在生產環境中部署了這項技術。例如，Inworld 使用 Mojo 構建了直接在 GPU 上執行的自定義靜音偵測核心。Qwerky 也使用 Mojo 來實現記憶體高效的 Mamba 協定，編譯自定義 GPU 核心，從而加速 Mamba 處理對話歷史記錄的線性時間複雜度。這些並非玩具範例——它們是選擇 Mojo 而非 CUDA 的生產系統。
現在，效能提升已經可以被量化。Modular 於 2026 年 3 月發布的 26.2 版本，在 FLUX.2 圖像生成模型上實現了 4 倍的速度提升。在 NVIDIA B200 硬體上，Gemma 4 的吞吐量比 vLLM 高出 15%。此外，這是在硬體支援初期就達到的最先進效能，表明編譯器最佳化工作正按預期進行。
效能宣傳：炒作與現實
Modular 聲稱 Mojo 的速度「比 Python 快 68,000 倍」。這個數字顯然有些誇大其詞。更實際的說法是：對於典型的 AI/ML 工作負載，速度提升 1,000 倍以上，而單執行緒程式碼的效能與 C++ 和 Rust 相當（相差不超過 2 倍）。
這 68,000 倍的提升幅度來自於 Python 效能最差的緊密迴圈情境——直譯執行的開銷、全域直譯器鎖定 和動態型別共同作用，嚴重影響了效能。Mojo 的 SIMD 向量加速和 MLIR 編譯器最佳化在這些場景中表現突出。然而，對於均衡的工作負載，可預期的效能提升幅度約為 Python 的 1,000 倍，而非 68,000 倍。
總結來說，Mojo 的優勢體現在 AI/ML 基礎設施、GPU 加速的資料處理、自定義訓練核心和推論引擎等方面。在任何 Python 效能瓶頸迫使你重寫為 C++ 的情況下，Mojo 都能提供語法熟悉的折衷方案。
Mojo 也並非全能，它在什麼地方會落敗？網頁開發並非 Mojo 的強項。使用成熟函式庫進行快速原型開發仍然更仰賴 Python 生態系。如果你的專案依賴於沒有 Mojo 綁定的 Python 套件，你就束手無策了。Python 生態系尚不成熟——這片領域目前還處於早期採用者的階段。
一個決策框架：何時採用 Mojo？
那麼，現在應該採用 Mojo 1.0 beta 版，還是等待 1.0 正式版，抑或是完全不理睬它？
如果符合以下條件，不用猶豫可立即使用：
- 你正在從零開始構建 AI/ML 基礎設施。
- GPU 程式設計是一項核心要求。
- 你需要 Python 語法，但又無法容忍 Python 的效能問題。
- 你願意承受測試版的不穩定性，並為生態系的發展做出貢獻。
如果符合以下條件，請等待 1.0 正式版（預計 2026 年底發布）：
- 生產環境的穩定性是不容妥協的。
- 你擁有一個龐大的現有 Python 程式碼庫。
- 你的團隊缺乏系統程式設計經驗。
- 你需要成熟的第三方函式庫。
如果出現以下情況，切勿使用：
- 你的專案重度依賴 Python 生態系的函式庫。
- 你專注於網站開發。
- 你的團隊不願投入時間學習新的語法。
而當今，市場時機對 Mojo 非常有利。AI 基礎設施投資正在爆炸性成長——KKR 斥資 100 億美元投資 Helix，Anthropic 承諾向 Google Cloud 投資 2000 億美元——而 GPU 運算效率是重中之重。Python 的效能危機已是公認的事實。如果說 Python 語法的系統語言有突破的良機，那就是現在了。
雙語問題或可解決
多年來，AI 開發者一直在 Python（用於研究）和 C++（用於生產環境）之間切換。用 PyTorch 編寫的原型，會被重寫成 C++ 用於推論。這種做法帶來的摩擦巨大：不同的語法、不同的團隊、雙重維護。
Mojo 承諾為高層邏輯和底層執行提供一個統一的環境，無需獨立的 CUDA 程式碼，也無需從原型過渡到生產環境時切換語言。Inworld 和 Qwerky 等專案已證明其在全新專案中行之有效。然而，遷移現有的 Python 程式碼庫相當複雜，且生態系尚不成熟，限制了可用函式庫的數量。
Mojo 的技術令人印象深刻，而且執行得非常出色。問題在於其生態系能否快速成熟，從而克服 Python 的網路效應。它的早期生產部署令人鼓舞，但 beta 版的不穩定性以及有限的函式庫仍然是個障礙。
此次 Mojo 1.0 beta 版標誌著一個重要的里程碑。此次重大變更預示著 API 的穩定性。GPU 功能的加入滿足了市場的實際需求。雖然效能的宣傳可能略顯誇張，但它確實在關鍵領域帶來了顯著的提升。
如果你已經達到了 Python 的效能瓶頸，或者需要使用 GPU 程式設計但又不想面對 CUDA 的複雜性，那麼現在就應該評估一下 Mojo。Mojo 1.0 正式版發布前的試用窗口，即將關閉。
作者：洛逸
相關閱讀：