【Arm的AI世界】以ExecuTorch和KleidiAI執行LLM推論　充分釋放行動端AI潛力！

Posted By Arm作者群 on 5 月 2, 2025 in Arm, Arm的AI世界, Edge AI開發地圖, LLM, 技術導讀, 技術新訊, 物聯網, 量化技術 | 0 comments

全球有2,000多萬開發人員基於Arm架構進行開發，而Arm也持續致力於協助全球開發人員先進的人工智慧(AI)運算能力。而要實現這一目標，就需要在龐大的軟硬體合作夥伴生態系中開展關鍵的軟體協作。

去年，Arm推出了包含一系列開發人員支援技術和資源的Arm Kleidi，以推動整個機器學習軟體堆疊的技術協作和創新。其中包括提供最佳化軟體例程的 Arm KleidiAI 軟體函式庫，當將 KleidiAI 整合到如 XNNPACK 等關鍵框架中時，能夠幫助基於Arm Cortex-A CPU的開發人員自動實現 AI 加速。而透過XNNPACK將KleidiAI整合到ExecuTorch中，可提升Arm CPU在行動裝置端的AI工作負載效能。

受惠於Arm和Meta工程團隊的協作，AI開發人員可在具有i8mm ISA擴展的基於Armv9架構之Arm Cortex-A CPU上部署Llama量化模型，運作速度最高可提升20%。同時，ExecuTorch團隊也已正式上線了測試(Beta)版本。

這顯示雙方合作中的一個重要里程碑。在本文中，我們將分享更多細節，包括ExecuTorch功能、Meta Llama 3.2模型、4位元整數分區塊量化(per-block quantization)，以及在Arm CPU上展現的出色效能。我們在三星S24+裝置上執行Llama 3.2 1B量化模型，在預填充階段實現了每秒超過350個詞元(token)的速度，如以下圖所示。

接下來，一起深入瞭解實現上圖展示中所需的關鍵元件。

Meta Llama 3.2

Meta 發佈的首款輕量級Llama量化模型能夠在主流的行動裝置上執行。Meta對Llama 3.2 1B和3B模型採用了兩種量化技術：帶有LoRA配接器(adaptor)的量化感知訓練(QAT) QLoRA和先進的訓練後量化方法SpinQuant。這些量化模型在使用PyTorch的ExecuTorch框架做為推論引擎，並使用Arm CPU做為後端的情況下進行評估。這些經過指令調整的模型保留了原始1B和3B模型的品質和安全性，同時與原始BF16格式相比，實現了二至四倍的加速，模型大小平均減少了56%，記憶體佔用平均減少了41%。

ExecuTorch

ExecuTorch是一種用於在裝置端側部署AI模型的PyTorch原生框架，以增強隱私性並減少延遲。它支援部署前端的開源AI模型，包括Llama模型系列及視覺和語音模型(如Segment Anything和 Seamless）。

這為廣泛的邊緣端裝置開闢了新的可能性，例如手機、智慧眼鏡、VR 頭盔和智慧家庭攝影機等。傳統上，在資源有限的邊緣端裝置上部署 PyTorch 訓練的 AI 模型是一項具有挑戰性且耗時的工作，通常需要轉換為其他格式，過程中可能會出現錯誤和效能不理想的情況。此外，硬體和邊緣端生態系中的不同工具鏈也會影響開發人員體驗，使開發通用解決方案變得不切實際。

為解決這些問題，ExecuTorch提供了多個可組合的元件，包括核心runtime、運算子函式庫(operator library)，和支援可攜性和可擴展性的代理 (delegation) 介面。模型可以使用torch.export()匯出，生成與ExecuTorch runtime原生相容的圖表，能夠在大多數搭載CPU的邊緣端裝置上運作，並可擴展到GPU和NPU等專用硬體以增強效能。

透過與Arm合作，ExecuTorch現可利用KleidiAI函式庫中經過最佳化的低位元矩陣乘法核心，透過XNNPACK提高裝置端大語言模型(LLM)的推論效能。

為AI工作負載提升架構

自深度學習浪潮興起以來，Arm一直致力於投資開源項目並推進新的處理器技術，專注於提高 AI 工作負載的效能和能源效率。

例如，Arm從Armv8.2-A架構開始導入SDOT指令，以加速8位元整數向量之間的點積運算。目前行動裝置上已廣泛具備此特性，顯著加快了8位元量化模型的運算速度。繼SDOT指令之後，Arm導入了BF16資料類型和MMLA指令，進一步提升CPU的浮點和整數矩陣乘法效能，後來又宣佈推出了可擴展矩陣延伸指令集(SME)，展現機器學習能力的重大飛躍。

下圖展示了過去十年中Arm CPU在AI領域持續創新的部分：

有鑑於Arm CPU的廣泛應用，AI框架需要在關鍵運算元中充分利用這些技術，以大幅提高效能。認識到這一點後，我們需要一個開源函式庫來共用這些經過最佳化的軟體例程。然而，我們也注意到將新函式庫整合到AI框架中仍存在挑戰，例如對函式庫的大小、依賴項目和文件檔案的擔憂，而且需要避免給開發人員增加額外的負擔。因此，我們努力收集合作夥伴的回饋意見，並確保整合過程順利進行，並且不需要AI開發人員使用額外的依賴項目。這項工作促成了KleidiAI的誕生，這是一個開源函式庫，為針對Arm CPU量身訂做的AI工作負載，提供了經過最佳化的效能關鍵例程。

Arm與Meta的ExecuTorch團隊合作，為創新的4位元分區塊量化方案提供了軟體最佳化，用於加速Llama 3.2量化模型的Transformer層的torch.nn.linear運算元中的矩陣乘法核心。ExecuTorch 靈活的4位量化方案在針對裝置端LLM的模型準確性和低位元矩陣乘法效能之間取得了平衡。

4 位元整數分區塊量化

在KleidiAI中，我們導入了針對這種新的4位元整數量化方案進行最佳化的微核心(micro-kernels)

(matmul_clamp_f32_qai8dxp_qsi4c32p

如下圖所示，對權重參數(RHS矩陣)採用這種4位元分塊量化策略，並對啟動參數(LHS矩陣)採用8位元分行量化(8-bit per-row quantization)：

如上圖所示，權重矩陣中的每個輸出特徵圖 (OFM) 被劃分為大小相等的區塊(群組大小)，每個區塊都有一個以BF16格式儲存的比例因數(scale factor)。BF16 的優勢在於它以一半的位元數維持了32位元浮點(FP32)格式的動態範圍，並且可以使用簡單的移位運算輕鬆地與FP32進行轉換。因而，BF16非常適合用於節省模型空間、保持準確性，以及確保向後相容缺少BF16硬體加速的裝置。

為保證完整性，這個4位元量化方案和我們在KleidiAI中的實現允許使用者配置線性權重(RHS 的群組大小；如果模型由使用者進行量化，則允許使用者在模型大小、模型準確性和模型效能之間進行權衡。

至此，我們已準備好來展示使用ExecuTorch在Arm CPU上執行Llama 3.2 1B和Llama 3.2 3B。以下，先介紹用於評估LLM推論效能的幾個指標。

LLM 推論指標

通常，用於評估 LLM 推論效能的指標包括：

第一個詞元延遲 (Time To First Token，TTFT)：該指標測量的是使用者提供提示詞後生成第一個輸出詞元所花費的時間。這方面的延遲或回應時間對於良好的使用者體驗至關重要，尤其是在手機上。TTFT 也是提示詞或提示詞詞元長度的函數。為了使該指標不受提示詞長度的影響，我們在此使用「每秒預填充詞元數」做為替代指標。它們之間呈現反向關係：TTFT 越低，每秒預填充詞元數就越高。
解碼效能：該指標是指每秒生成的平均輸出詞元數，因此以「詞元/秒」為單位進行報告。它與生成的詞元總數無關。對於裝置端推論，重要的是使該指標高於使用者的平均閱讀速度。
峰值Runtime記憶體：該指標反映了運行模型時要達到預期效能(使用上述指標來衡量)所需的 RAM 大小。這是裝置端 LLM 部署的關鍵指標之一，決定了可在裝置上部署的模型類型。

結果

Llama 3.2 1B 量化模型(SpinQuant 和 QLoRA)專為在各種 RAM 有限的手機上高效率運作而設計。我們展示的測量資料是以運作原生態Android系統的三星 S24+ 手機為基礎，使用Llama 3.2 1B參數模型進行實驗。雖然我們的示範僅使用了1B模型，但預計3B參數模型也會有類似的效能提升。實驗設置包括進行一次預熱執行，序列長度為128，提示詞長度為64，使用8個可用 CPU 中的6個，並透過adb測量結果。

我們使用來自GitHub的ExecuTorch主分支(branch)，首先用已發佈的檢查點為每個模型生成ExecuTorch PTE二進位檔案。然後，我們使用相同的程式碼倉庫，為 Armv8 生成了 ExecuTorch runtime二進位檔案。我們將使用 KleidiAI 構建的二進位檔案，比較不同的 1B 量化模型與 BF16 模型的效能。我們還將比較帶有 KleidiAI 的二進位檔案和不帶有 KleidiAI 的二進位檔案運行量化模型的效能提升幅度，以分析 KleidiAI 產生的影響。

我們的示範結果顯示，Llama 3.2 1B量化模型在預填充階段每秒可生成超過350個詞元，在解碼階段每秒可生成超過40個詞元。這種級別的效能足以僅使用Arm CPU，就可在裝置端實現文字摘要功能，並提供良好的使用者體驗。為便於理解，可以參考的是，平均50條未讀消息包含約600個詞元。憑藉這樣的效能，回應時間(即生成的第一個單詞出現在螢幕上所需的時間)約為兩秒。

量化模型效能

與基準線BF16模型相比，Llama 3.2量化模型SpinQuant和QLoRA在提示詞預填充和文字生成(解碼)方面的效能顯著提升。我們觀察到，解碼效能提高了兩倍以上，預填充效能提高了五倍以上。

此外，量化模型的大小(以位元組為單位的PTE檔大小)不到BF16模型的一半，前者為1.1 GiB，後者為2.3 GiB。雖然INT4的大小是BF16的四分之一，但是模型中的某些層是用INT8量化的，使得PTE文件大小比例變大。我們觀察到，在最大序列長度為2,048時，在常駐記憶體集合大小(RSS)中測量，與BF16模型的3.1 GiB相比，SpinQuant 模型的運行時峰值記憶體佔用減少近40%，為1.9 GiB。

透過全方位的提升，Llama 3.2量化模型非常適合在Arm CPU上進行裝置端部署。

KleidiAI的影響

ExecuTorch 借助 KleidiAI 函式庫，為具有先進 Armv8/Armv9 ISA 特性的新Arm CPU提供低位元高效能矩陣乘法核心。這些核心用於ExecuTorch中的裝置端 Llama 3.2 量化模型推論。

為了評估 Kleidi 產生的影響，我們生成了兩個針對 Cortex-A CPU 的 ExecuTorch runtime二進位檔案，並比較了它們的效能。第一個ExecuTorch runtime二進位檔案透過XNNPACK函式庫使用KleidiAI函式庫建構。第二個二進位檔案是在不使用KleidiAI函式庫的情況下建構的，使用的是XNNPACK函式庫中的原生核心。

如下圖所示，與非KleidiAI核心相比，ExecuTorch在 S24+上使用KleidiAI 後，預填充效能平均提升了20%以上，同時保持相同的準確度。這種效能優勢並不侷限於特定的模型或裝置，預計所有在Arm CPU 上使用低位元量化矩陣乘法的 ExecuTorch 模型都將從中獲益。

快來動手嘗試吧！

準備好親身體驗效能的改進了嗎？現在就可在你的專案中試用 ExecuTorch 和 KleidiAI 所提供的最佳化！歡迎瀏覽 Arm Learning Paths，了解如何透過 ExecuTorch 和 KleidiAI 開發使用 LLM 的應用。

（參考原文：Unleashing the Power of AI on Mobile: LLM Inference for Llama 3.2 Quantized Models with ExecuTorch and KleidiAI；本文共同作者為Arm 工程部首席軟體工程師 Gian Marco Iodice 及 Meta 公司 Digant Desai。本文中文版校閱者為 Arm 主任應用工程師林宜均）

About
Latest Posts

Arm作者群

來自各方的Arm開發者社群專家。