作者：Arm 高級首席工程師 Jason Zhu 等人

交互式圖像分割已成為全球主流應用中極具代表性的移動端體驗。簡單來說，用戶只需在圖片上輕點一下（或粗略勾畫），應用就能立刻生成像素蒙版，把目標對象“摳”出來。這項技術支撐了許多常見功能，比如制作個性化貼紙、分離主體以替換背景，或是對圖像局部進行選擇性增強。這些效果背后，是輕量級分割模型在運行，這些模型通過 ExecuTorch（PyTorch 的開源端側推理運行時）以及第二代 Arm 可伸縮矩陣擴展技術 (Arm SME2) 運行。

本文將探討這些軟硬件技術升級如何讓摳圖功能背后的端側交互式分割模型 SqueezeSAM 在圖像分割任務中實現最高可達 3.9 倍的加速，并闡述這一突破對移動端應用開發者的廣泛影響。SqueezeSAM 已部署在 Meta 旗下應用中。

移動設備上端側 AI 的興起

隨著端側人工智能 (AI) 不斷發展，一個核心問題擺在眼前：當更強大的模型在嚴格的移動端功耗與時延限制下能夠運行得更快時，會出現哪些新的可能性？實際上，許多交互式移動端 AI 功能和工作負載已在 CPU 上運行，因為 CPU 始終可用、與應用無縫集成，且在各類場景中具備高靈活性、低時延與出色性能。對于這類部署方案，性能優劣往往取決于 CPU 執行矩陣密集型內核的效率，以及當算力不再是瓶頸后還存在哪些限制因素。

SME2 是 Armv9 架構中的一組高級 CPU 指令，專為在端側直接加速面向矩陣的計算工作負載而設計。我們量化了在 ExecuTorch 與 XNNPACK 部署方案中，SME2 對端到端推理的加速效果，并通過算子級性能分析展示具體哪些方面得到了改進。啟用 SME2 的全新 Arm CPU已集成在Arm Lumex 計算子系統 (CSS)中，用于旗艦智能手機與下一代 PC 設備。

案例研究：利用 SME2 加速交互式圖像分割

我們評測了在以 ExecuTorch 和 XNNPACK 為后端運行時，SME2 對 SqueezeSAM 推理時延的影響。該方案利用 Arm KleidiAI 優化的內核，以發揮 SME2 的加速能力。

啟用 SME2 后，8 位整型 (INT8) 和 16 位浮點型 (FP16) 推理均獲得顯著性能提升（圖 1）。在采用默認功耗配置的單個 CPU 核心上，INT8 時延優化 1.83 倍（從 556 毫秒降至 304 毫秒），FP16 時延優化 3.9 倍（從 1163 毫秒降至 298 毫秒）。若無 SME2，時延會過高，無法滿足交互式場景的流暢使用需求；啟用 SME2 后，單核端到端推理時延可達到 300 毫秒左右，使端側部署切實可行，同時也為應用的其他部分留出了性能余量。

上述結果表明，SME2 可在 CPU 上顯著加速量化后的 INT8 模型。同時，在本案例中，SME2 讓 FP16 時延接近 INT8 水平，這一成果意義重大，因為它并非替代 INT8，而是擴展了實際可部署的方案范圍。這讓開發者擁有更高的靈活性，可選擇最符合精度與工作流需求的數據格式，尤其適用于對精度敏感的工作負載，如圖像超分辨率、圖像摳圖、暗光去噪與高動態范圍 (HDR) 增強。倘若沒有如此級別的 FP16 加速，移動端部署通常只能選用 INT8 以滿足時延目標，而這意味著需要引入量化工作流并承擔精度下降的風險。

除基準測試數據外，這些性能提升可直接轉化為可用的 CPU 算力余量。這些余量可用于打造更豐富的體驗，例如在保持相機預覽與 UI 流暢的同時，并行運行分割與增強任務（如去噪或 HDR 處理）；或者把原本只能處理單張圖片的摳圖，擴展成帶跨幀目標跟蹤的實時視頻摳圖，亦可用于降低功耗。

圖 1：普通模式下（默認移動端功耗設置），一個 CPU 核心在啟用與禁用 SME2 時 SqueezeSAM 的端到端時延。INT8 從 556 毫秒優化至 304 毫秒（提升 1.83 倍）。FP16 從 1163 毫秒優化至 298 毫秒（提升 3.90 倍），在本案例中 FP16 時延已接近 INT8 水平。

本文所有結果均為在搭載啟用 SME2 的 Arm CPU 的旗艦安卓智能手機上進行受控測試所得。性能會因模型、硬件及具體設備設置而異。

技術棧：PyTorch、ExecuTorch、XNNPACK、KleidiAI 和 SME2

框架間的連接關系

上圖總結了本案例研究中使用的 CPU 執行技術棧。模型在 PyTorch 中定義，由 ExecuTorch 導出并運行，CPU 計算則委派給作為后端的 XNNPACK 執行。XNNPACK 使用 Arm KleidiAI，這是面向 Arm CPU、為加速機器學習工作負載而優化的輕量級 CPU 內核庫。這些內核可在受支持的設備上自動利用 SME2 加速，同時也能為不支持 SME2 的系統提供針對其他的 CPU 特性的優化實現。

當 ExecuTorch 在啟用 XNNPACK 委派的情況下運行模型時，XNNPACK 會在運行時根據底層硬件能力選擇合適的內核實現。在啟用 SME2 的設備上，這些運算中的矩陣乘法計算可直接受益于 SME2 加速，無需對模型結構或應用代碼進行任何修改。在這類運算得到加速后，推理管線中的其他環節（如數據移動、布局轉換、未委派的算子等）往往會成為新的性能瓶頸。這也是算子級性能分析對于理解端到端性能至關重要的原因。

案例研究模型

在本次評估中，我們使用了 SqueezeSAM 模型，該模型采用輕量級、以 conv2d 為主的 UNet 架構，是典型的移動端視覺模型。

模型結構可被映射為兩大類工作，這兩類工作對端到端推理時間有著顯著影響：

計算密集型運算：卷積層（iGEMM，隱式通用矩陣乘法）和注意力/MLP 層（GEMM，通用矩陣乘法）。

數據移動類運算：轉置、維度重塑和布局轉換。

平臺說明：在許多基于 Armv9 架構的設備上，SME2 作為 CPU 核心間的共享執行資源實現，其伸縮特性會隨系統級芯片 (SoC) 與 CPU 微架構不同而存在差異。我們在評估中已明確考慮這一點，并在解讀單核與多核結果時討論其產生的影響。

結果：INT8 和 FP16

（1 個 CPU 核心對比 4 個 CPU 核心）

我們在啟用與禁用 SME2 的條件下，對同一模型的兩種精度（INT8 和 FP16）進行基準測試。我們重點關注單核執行場景（SME2 在此場景下相對收益最大），同時也給出四核結果，以說明當 SME2 作為共享硬件資源時的絕對時延與伸縮表現。所有測試均僅統計模型本身的推理時延。

模型通過 ExecuTorch 在安卓智能手機上運行，在相同軟件與系統環境下分別測試啟用與禁用 SME2 的情況。除非另有說明，所有結果均為在無溫控降頻情況下的穩態性能。

所有結果均以“普通模式 | 無限制模式（毫秒）”的形式給出。普通模式對應默認的移動設備電源設置，即系統電源策略啟用狀態，反映典型用戶使用場景。無限制模式對應持續供電、保持喚醒狀態的配置，CPU 頻率限制有效解除；單核測試中，無限制模式結果固定在最高性能（Ultra/Prime，本例中為 4.2 GHz）CPU 核心上運行。

在兩種模式下，SME2 均呈現一致的相對加速趨勢，表明盡管絕對時延存在差異，但其加速效果受系統功耗策略影響較小。除非另有明確說明，本文后續均以普通模式結果為主，因其更能反映典型手機使用環境下的用戶感知時延。無限制模式結果用于展示性能余量與硬件上限，應視為最佳表現，而非日常用戶體驗。

表 1：在安卓手機上啟用與禁用 SME2 時，SqueezeSAM 的端到端時延結果，分別在一個 CPU 核心與四個 CPU 核心上測試（僅模型時延）。數值以“普通模式 | 無限制模式（毫秒）”的形式給出。

關于四核擴展說明：四核的加速比例較小（例如，普通模式下 INT8 為 1.08 倍，而單核為 1.83 倍），這與 SME2 作為共享資源的特性一致，同時也受內存帶寬、緩存行為等其他系統共享因素影響。伸縮特性會因 SoC 與 CPU 實現方式不同而存在差異。在生產部署中，若能滿足時延目標，優先使用一到兩個核心可獲得更好的能效；當需要更低的絕對時延且功耗預算允許時，可使用更多核心。

算子級性能分析的重要性

端到端時延只能告訴我們性能提升了多少，無法說明原因及后續的優化對象。為了理解 SME2 的性能收益來源及下一階段的性能瓶頸，我們使用算子級性能分析。

我們通過 ExecuTorch 開發工具中的性能分析工具 ETDump 采集每個算子的耗時信息，該工具會記錄推理過程中各個算子的執行時間。這使我們能夠將端到端加速效果歸因到模型的具體部分，如圖 2 和表 2 所示。

為了讓分析更具實踐指導意義，我們將算子歸納為少數幾個與常見模型結構精準對應的類別：

卷積：Conv2d 層（通常基于 iGEMM 實現）；

GEMM：矩陣乘法和線性層（注意力和 MLP 投影）；

逐元素：ReLU、GELU、Add、Mul 及其他逐點運算；

數據移動：轉置、拷貝、格式轉換、維度重塑和填充；

其他：未委派的算子和框架開銷。

通過上述分類拆解，我們可以明確 SME2 在哪些方面作用最為顯著，以及在矩陣計算被加速后依然存在的性能瓶頸。

圖 2：在安卓智能手機上（一個 Arm CPU 核心，默認移動設備功耗設置），啟用與禁用 SME2 時，FP16 與 INT8 的算子類別耗時明細（絕對時間）。SME2 大幅降低卷積與 GEMM 耗時，數據移動在運行時間中的占比顯著提升。

表 2：在安卓智能手機上（一個 Arm CPU 核心，默認移動設備功耗設置），禁用與啟用 SME2 情況下 INT8 與 FP16 的算子級耗時明細對比。非矩陣乘法算子主要受運行時波動的影響。

從端到端與算子級結果得出的三大洞察

洞察 1：SME2 能夠加速矩陣計算，將瓶頸轉移至數據移動

SME2 顯著降低 INT8 與 FP16 精度下的端到端時延。在單個 Arm CPU 核心上，INT8 性能優化 1.83 倍（從 556 毫秒降至 304 毫秒），FP16 優化 3.90 倍（從 1163 毫秒降至 298 毫秒）。即使在四核場景下，SME2 仍可大幅降低 FP16 時延（從 374 毫秒降至 193 毫秒）。這些優化效果使單核執行時延進入約 300 毫秒區間，在為應用其他部分保留 CPU 余量的同時，讓端側實時交互成為可能。

算子級性能分析表明，SME2 能夠大幅加速矩陣密集型算子。禁用 SME2 時，卷積與 GEMM 占據推理的主要耗時，分別占 INT8 運行時間的 55.7%、FP16 的 75.8%。啟用 SME2 后，GEMM 算子加速約 3 至 4 倍，卷積/iGEMM 加速約 4 至 9 倍，這是端到端性能提升的主要驅動因素。

矩陣計算加速后，數據移動與框架開銷的相對占比上升，后續優化重心也隨之轉移。

洞察 2：由轉置驅動的數據移動約占總運行時的 40%

在 SME2 加速后，數據移動成為主要運行耗時因素之一。在啟用 SME2 的 INT8 運行中，數據移動占總運行時的 41.4%（FP16 為 39.9%）。ETDump 追蹤結果顯示，約 85% 的數據移動時間來自轉置算子，僅兩類轉置節點就占用了該類別超過 80% 的耗時。

這類開銷源于模型不同部分與運行時之間的數據布局不匹配，而非計算強度問題。實際場景中，當具有不同布局偏好的算子按序組合時，會觸發頻繁的 NCHW NHWC 格式轉換。在本模型中可以看到：歸一化算子作為可移植的 NCHW 算子執行，且無法與相鄰卷積融合（例如當非線性激活函數位于 Conv2d 與 BatchNorm 之間時），而 XNNPACK 卷積內核更偏好 NHWC 布局。這會在 UNet 編碼器–解碼器模塊中引發重復的布局轉換：

BatchNorm/GroupNorm (NCHW) →

轉置 (NCHW→NHWC) → 卷積 (NHWC) →

轉置 (NHWC→NCHW) →

BatchNorm/GroupNorm (NCHW)

由于這類開銷由模型與運行時的布局選擇決定，而非計算強度，因此必須通過性能分析才能將其暴露出來，從而將其轉化為可執行的優化目標。

重要的是，這一性能分析洞察已被證實具備實際優化價值。作為初步舉措，Meta ExecuTorch 團隊在框架中實現了針對性的圖級優化，以減少歸一化層周圍不必要的數據布局轉換。在我們的實驗中，除 SME2 帶來的加速收益外，還可使 INT8 時延額外減少約 70 毫秒 (23%)，FP16 時延額外減少約 30 毫秒 (10%)。

由上述結果可以確認，高轉置的數據移動是極具價值的優化方向。隨著我們持續分析整張計算圖的布局行為，仍有進一步優化的潛力。

洞察 3：在本案例研究中，啟用 SME2 后 FP16 時延接近 INT8 水平

盡管 INT8 每個張量元素僅占用一半的內存帶寬，但這并不直接帶來成比例的端到端加速。啟用 SME2 后，本案例中 FP16 時延已接近 INT8（單個核心上分別為 298 毫秒與 304 毫秒）。

算子耗時明細揭示了背后原因。FP16 的卷積加速效果尤為顯著（加速 9.0 倍，INT8 為 4.4 倍），彌補了 INT8 在內存上的效率優勢。同時，INT8 矩陣計算路徑會帶來額外開銷，包括量化、伸縮及更復雜的內核調度邏輯，削弱了 INT8 的有效帶寬優勢。

最終效果是，SME2 拓寬了可選用的精度范圍。INT8 依然是高效方案，而對于不希望承擔量化復雜度或精度損耗的精度敏感型工作負載，FP16 也變得更加實用。盡管本案例中 FP16 性能已接近 INT8，但該效果與任務負載強相關，會隨算子組合、張量形狀與內存壓力發生變化。

實操示例：重現工作流

如想自行嘗試上述工作流，我們提供了基于開源 SAM 模型的實操教程，內容涵蓋模型導出、使用 SME2 執行推理、通過 ETDump 進行算子級性能分析等。完整的設置說明與代碼示例可在代碼倉庫及 Learning Paths 中獲取。

代碼倉庫: https://github.com/ArmDeveloperEcosystem/sme-executorch-profiling

Learning Paths: https://learn.arm.com/learning-paths/cross-platform/sme-executorch-profiling/

你將能學到什么：

如何將分割模型導出至 ExecuTorch，并啟用 XNNPACK 委派

如何在已啟用 SME2 的安卓、iOS 和 macOS 設備上構建與部署模型

如何運行 ETDump 性能分析，采集各算子的耗時信息

如何在自有模型中識別并量化數據移動及其他非計算類性能瓶頸

結論：SME2 帶來的實際改變

在本 SqueezeSAM 案例研究中，SME2 為 INT8 與 FP16 提供了顯著的端側 CPU 加速效果，從本質上提升了交互式移動端工作負載的可行性。

這對開發者和產品團隊意味著什么：

端側機器學習在 CPU 上更具可行性：SME2 可實現最高 3.9 倍的端到端推理加速。在安卓默認功耗設置下，真實交互式移動端模型的單核時延可從 1 秒以上降至約 300 毫秒。對于交互式工作負載，這使得基于 CPU 的端側機器學習從勉強可用變為穩定實用，同時為應用其他功能保留性能空間。

FP16 在部分場景中成為更可行的部署選擇：SME2 大幅加速 FP16 計算，并縮小其與 INT8 之間的時延差距，讓開發者能更靈活地選擇最符合精度、工作流與時延要求的數值精度，尤其適用于對精度敏感的工作負載。

節省的算力余量可帶來更豐富的使用體驗：釋放的 CPU 預算可用于增強端側功能，例如在圖像分割的同時運行畫質增強（如去噪、HDR），或將圖像摳圖從單張圖片擴展至支持跨幀目標跟蹤的實時視頻。

性能分析給出下一階段優化目標：當 SME2 加速了矩陣密集型算子（卷積/iGEMM、GEMM）后，性能瓶頸通常會轉向數據移動與未委派算子。基于 ETDump 的算子級性能分析可清晰展示這類開銷，并提供可落地的優化方向。

根據起點不同，有兩點明確的啟示：

若你目前尚未部署端側機器學習，那么基于 SME2 的 CPU 加速可以讓移動端 CPU 成為部署這類“重算子”模型的可行起點，而性能分析能夠為驗證表現和持續迭代提供清晰路徑。

若你已部署端側模型，SME2 可釋放算力余量，用于拓展功能、提升用戶體驗；同時性能分析可指出收益最高的后續優化方向（在 SqueezeSAM 中，由轉置驅動的布局轉換約占總運行時間的 40%）。

綜上，SME2 加速與算子級性能分析相結合，可形成一套實用工作流：既能快速獲得立竿見影的性能提升，亦可精準定位端側 AI 后續的重點優化方向。