北京
一個反直覺的判斷正在被技術驗證：當生成式AI模型需要真正落地到數十億設備時，那個“不夠酷”的CPU可能是最優解，而不是那些噱頭十足的專用加速器。
過去五年，行業默認的敘事是CPU推理只是個兜底選項。要跑大模型，要跑圖像和音頻生成，你得靠GPU、NPU或者各種定制化AI芯片。這種慣性思維背后有一個真實的工程取舍：CPU的延遲太高了，尤其是在處理Transformer里密集的矩陣運算時，等待時間根本滿足不了生成式AI的交互要求。但問題在于，把賭注全壓在專用加速器上會立刻撞上另一堵墻——碎片化。不同芯片的驅動、算子庫、內存帶寬特性天差地別。為一個NPU高度優化的模型，換到另一家手機芯片上性能可能崩塌。
Arm的方案直接針對這個取舍本身。Scalable Matrix Extension 2（SME2）的做法不是在CPU旁邊掛一個協處理器，而是把一個專用的矩陣計算單元直接集成進了CPU集群內部。這意味著，CPU核心自己就能在需要時變身為一個高性能的矩陣乘法加速器。原文給出的數據是，針對生成式AI中矩陣運算密集的工作負載，推理速度直接提升到原來的5倍。“要么選高延遲CPU，要么選碎片化的專用加速器”這個二元困局，在架構層面被SME2打掉了。CPU不再是一個妥協選項，而成了一個正經的、統一可編程的、能跑滿生成式模型算力需求的計算平臺。
硬件只是故事的一半。如果開發者需要手動去調SME2的指令集，那這條技術路線出不了實驗室。Google AI Edge作為集成軟件棧補上了關鍵一塊。LiteRT在執行推理時，會在運行時自動通過XNNPACK和集成了KleidiAI的算子庫去調用SME2。整個過程對開發者來說是透明的。LiteRT會識別出iGeMM和GeMM這類數學密集的內核，然后把它們派發給SME2去加速。開發者不需要關心底層指令，也不需要寫任何針對Arm的定制代碼。軟件棧自動完成從模型到硬件的映射、自動選擇精度最高的執行路徑。
部署環節同樣被工具鏈打包處理。模型量化是離線和在線部署里最容易踩坑的環節。AI Edge Quantizer負責處理復雜的模型壓縮，Model Explorer則提供了一個可視化的性能熱力圖，能直接定位模型中的瓶頸層。用Stability AI的開源音頻模型stable-audio-open-small做實際驗證，本來是浮點PyTorch的版本，經過這個“轉換-量化優化-部署”的管線后，被打包成一個混合精度（FP16/Int8）的格式，在Arm的CPU上實現了端側生成高質量音頻。
這里有兩個維度值得拆開看。第一個維度是生成質量。像stable-audio-open-small這種擴散模型，參數量在十億左右，用一句話生成11秒的立體聲音頻片段。如果開發者隨隨便便對整個模型權重做暴力量化，音頻質量會直接崩掉。找出那個最優的量化配置本身就是一個高復雜度的搜索問題，AI Edge Quantizer解決的正是這一點，讓模型體積降下來但質量還能維持可用狀態。第二個維度是設備覆蓋。原文特意強調，能在CPU上高效跑音頻生成不只是一個技術里程碑，更意味著有機會將這類應用直接鋪開到全球數十億臺手機設備上，因為這些設備都是CPU驅動的。這不再是某個高端旗艦芯片的獨占功能。
從技術棧的角度，KleidiAI優化被直接嵌入XNNPACK這個設定，意味著開發者不需要額外引入任何庫或SDK。只要用LiteRT跑推理，Arm CPU上的SME2加速就會自動生效。這個“自動獲益”的設計很關鍵。它把一條原本高度依賴手工優化、需要同時懂模型壓縮和底層指令集的窄路，拓寬成了一個普通應用開發者也能使用的通用路徑。擴散模型不是另類，而是被選來演示這條端到端路徑的典型案例。轉換、優化、部署，三步走完，一個原本只能在云端或高端GPU上跑的PyTorch模型，最終變成能在移動端CPU上實時推理的混合精度模型。這種“端到端工作流可復現”的體感，才是工具鏈成熟度的標志。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
