今日份 Ferris

今天是這階段的最後一篇文章啦，開心開心

Python 與 Rust 在 MLOps 最終比較

產品優先思維

實時機器學習平台 Claypot AI 的共同創辦人 Chip Huyen 在其著作 Designing Machine Learning Systems 中討論了關於機器學習落地的各個面向，並試圖說服我們將機器學習產品化不僅是機器學習的問題，更是 infrastructure 的問題。
要做 MLOps 不只需要 ML 方面的專業，在部署、容器化、作業排程與工作流程管理等環節上更需要 Ops (operational) 的專業，而這就代表我們在執行 MLOps 時必須具有 production-first mindset。
若以產品的角度來看 MLOps，它就像系統程式一樣，必須具有很高的效率 (正如同對 Linux 來說，電源管理與執行效率至關重要)，就拿訓練模型來說好了，如何處理巨量資料並妥善運用珍貴的運算資源，就是這個產品成敗的關鍵，而這也是為什麼 Rust、Mojo 等現代語言躍上舞台的原因。

創新的兩難

在比較 Rust 與 Python 之前，我們先來談談所謂的創新的兩難 (Innovator's Dilemma)，這是著名的商業顧問 Clayton Christensen 在 1997 年的著作，其中提出的 破壞性創新 理論被稱為 21 世紀初最具影響力的商業理念。
書中談到了許多產業龍頭雖然時刻保持警覺、立即回應顧客需求，卻也因此忽略具有破壞性科技的新興企業，反而喪失了領導地位。
正如同在 Python 與 Rust 的抉擇中，一個關於從 Python 轉換到 Rust 的常見誤解是，嘿，Python 已經能勝任工作了，我不想改變現狀，讓我繼續使用我熟悉且高效的語言。
確實，沒人能否定 Python 成功的地位，但與此同時我們也可以看到像 Rust 一樣破壞性的技術出現。
而在這裡也不是要討論誰贏誰輸，只是根據手邊的問題選擇適當的解法。
例如 Python 在 API 文件方面表現得相當出色，就可讀性而言也是無與倫比。
在執行一些不需要太多運算資源的操作，比如從文件中讀取內容、修改文本並重新寫入文件時，Python 確實是一個理想的解決方案。
但當談到 MLOps 時，性能問題就至關重要，例如我們可能需要將 Hugging Face 的預訓練模型封裝成一個命令列工具，然後構建一個能夠遍歷數百萬個文件並以最低成本將這些文件總結的高性能二進制檔案，使用 Python 或許就不是最佳解決方案。

Python v.s. Rust 最終比較

換句話說，當處理特定問題時，要關注哪些因素是非常重要的，以下就從 MLOps 與產品化的角度來進行比較：

• 二進制部署：
  Python 並不支持二進制部署的概念，這不是它的設計目標。
  而 Rust 則預設支援二進制部署。
• Packaging：
  Python 的標準函式庫提供了許多內建模組，但其中並不包含內建的 Packaging 工具，在 Python 生態系統中有許多競爭性的解決方案，如虛擬環境、PIP、conda、poetry 等。
  而 Rust 提供了一個統一的解決方案 cargo。
• 計算速度：
  Python在計算速度方面是最慢的語言之一，在 Rui Pereira 等人的研究 Energy Efficiency across Programming Languages 中，它比 Rust 慢多達 70 倍，而且在多數情況下它的記憶體效率也比 Python 高兩倍。
  而 Rust 在性能方面則是最高效的語言。
  
• 生產力工具：
  正如前幾天的討論，Python 並不包含內建的 Formater, Linter, 文檔生成工具等增加軟體開發生產力工具。
  但使用 rustup 安裝 Rust 時就已經有這些工具了。
• 多執行緒：
  Python 在過去或許因為編譯器技術不如今天成熟而進行了妥協，但也因此無法充分利用多核處理器。
  然而現在我們有超過 100 核心的機器，使得這個問題越顯嚴重。
  而 Rust 則更容易處理多執行緒，事實上，它的編譯器就能幫助我們創建安全的多執行緒程式碼。
  因此，如果需要高性能的多執行緒編程，Rust 才是應該使用的解決方案。
• 語言安全性：
  Python 的型別安全性是一個附加功能，並非所有情況下都具備，我們需要安裝某些額外的套件或模組，語言本身並非為強大的型別安全性而設計，這有好有壞。
  而 Rust 的設計原則之一就是安全性，它擁有優秀的型別系統和防止記憶體流失 (memory leak) 的機制，這是該語言的核心設計理念。

總而言之，選擇使用 Python 還是 Rust 取決於我們的具體需求。
如果需要高性能、多執行緒、低能源消耗和更優秀的內建工具，那麼 Rust 可能是更好的選擇。
如果你只是需要快速進行一些較簡單的操作，Python 則會是一個更容易入門的選擇。

WASM

一般來說，當我們使用 TensorFlow 或 PyTorch 等框架建立了模型，必須仰賴該框架支援才能在特定的硬體後端上運行，而框架要支援某特定後端則需要了解硬體設計，且不同硬體又有不同的記憶體排列與計算方言：

＊Different compute primitives and memory layouts for CPU, GPU, and TPU. Chen et al. - TVM: An Automated End-to-End Optimizing Compiler for Deep Learning

因此框架要支援硬體後端是耗時且需要高度技術的工作，舉例來說，儘管 TPU 在 2018 年就上市，但 PyTorch 要等到 2020 才支援 TPU，在這之前你毫無選擇只能使用 TensorFlow 等支援 TPU 的框架。
然而，如果能在瀏覽器中運行模型的話，那麼我們就能擁有支援任何硬體後端的模型，不管是 MacBook、Chromebook、iPhone、Android 手機，只要該裝置支援瀏覽器，模型就能部署上去。
我們不需要再擔心這些裝置用了什麼晶片，也就不會再重現 Apple 從 Intel 換成 ARM 後一堆不支援跟不知道怎麼安裝的慘劇了。

而談到瀏覽器，大部分的人都會想到 JavaScript，像是 TensorFlow.js 等工具就是為了幫助我們把模型編譯成 JavaScript。
但問題是 JavaScript 很慢，並不適合作為需要從資料中提取特徵等複雜邏輯等任務的程式語言。

所以現在更有前景的方法是 WebAssembly (WASM)。
WASM 是一個開放的標準，允許在瀏覽器中運行可執行程式，所以我們可以在 scikit-learn、PyTorch、TensorFlow 或其他框架建立模型之後，將其編譯為 WASM (而不是編譯模型以運行在特定硬體上)。
WASN 的性能卓越，易於使用，並且擁有一個快速增長的生態系，截至目前為止，它已經受到全球 94% 的設備支援：

＊https://caniuse.com/wasm

而這裡提到它的原因就是，Rust 原生支援編譯成 WASM，讓我們在部署上可以更加輕鬆，這一點也為選擇它執行 MLOps 小小的錦上添花。
延伸閱讀：Is WebAssembly & WebGPU the new lazy deployment pipeline?

環境永續

最後一個 Python 與 Rust 的比較則與現在熱門的永續性有關。
身為一個愛護地球的好孩子，當我們需要進行繁重的計算時，例如 Web 微服務需要反覆進行 JSON 序列化與反序列化，或許該好好想想程式碼的碳足跡，不然就會被真人版地球超人攔下來。

在 AWS 的文章 Sustainability with Rust 便從這個觀點闡述了為何該選擇 Rust。
其中提到 C 和 Rust 就能源效率和計算性能而言，它們基本上是等效的：

由上圖可以看到 Rust 的能源消耗至少比 Java 少 50%，甚至比 Python 少了 98%。
另外，在 CPU 與記憶體使用時間上也可以大幅減少：


由上圖可以看到相較於 Python、Ruby 和 Javascript 等語言：

• Rust 可以將 CPU 時間減少高達 75%。
• Rust 可以將記憶體使用減少高達 95%。

總之，如果你愛地球、關心能源效益，關心計算時間，Python是效能最差的語言之一。
而從永續性的角度來看，Rust 是一個好選擇。

好啦，關於 Python 與 Rust 的比較告一段落了，明天要開始做專案啦！

參考資料

• Chip Huyen - Designing Machine Learning Systems
• Chen et al. - TVM: An Automated End-to-End Optimizing Compiler for Deep Learning