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

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

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

移動設(shè)備上端側(cè) AI 的興起

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

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

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

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

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

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

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

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

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

技術(shù)棧：PyTorch、ExecuTorch、XNNPACK、KleidiAI 和 SME2

框架間的連接關(guān)系

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

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

案例研究模型

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

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

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

數(shù)據(jù)移動類運算：轉(zhuǎn)置、維度重塑和布局轉(zhuǎn)換。

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

結(jié)果：INT8 和 FP16

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

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

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

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

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

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

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

算子級性能分析的重要性

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

我們通過 ExecuTorch 開發(fā)工具中的性能分析工具 ETDump 采集每個算子的耗時信息，該工具會記錄推理過程中各個算子的執(zhí)行時間。這使我們能夠?qū)⒍说蕉思铀傩Ч麣w因到模型的具體部分，如圖 2 和表 2 所示。

為了讓分析更具實踐指導(dǎo)意義，我們將算子歸納為少數(shù)幾個與常見模型結(jié)構(gòu)精準對應(yīng)的類別：

卷積：Conv2d 層（通常基于 iGEMM 實現(xiàn)）；

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

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

數(shù)據(jù)移動：轉(zhuǎn)置、拷貝、格式轉(zhuǎn)換、維度重塑和填充；

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

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

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

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

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

洞察 1：SME2 能夠加速矩陣計算，將瓶頸轉(zhuǎn)移至數(shù)據(jù)移動

SME2 顯著降低 INT8 與 FP16 精度下的端到端時延。在單個 Arm CPU 核心上，INT8 性能優(yōu)化 1.83 倍（從 556 毫秒降至 304 毫秒），F(xiàn)P16 優(yōu)化 3.90 倍（從 1163 毫秒降至 298 毫秒）。即使在四核場景下，SME2 仍可大幅降低 FP16 時延（從 374 毫秒降至 193 毫秒）。這些優(yōu)化效果使單核執(zhí)行時延進入約 300 毫秒?yún)^(qū)間，在為應(yīng)用其他部分保留 CPU 余量的同時，讓端側(cè)實時交互成為可能。

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

矩陣計算加速后，數(shù)據(jù)移動與框架開銷的相對占比上升，后續(xù)優(yōu)化重心也隨之轉(zhuǎn)移。

洞察 2：由轉(zhuǎn)置驅(qū)動的數(shù)據(jù)移動約占總運行時的 40%

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

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

BatchNorm/GroupNorm (NCHW) →

轉(zhuǎn)置 (NCHW→NHWC) → 卷積 (NHWC) →

轉(zhuǎn)置 (NHWC→NCHW) →

BatchNorm/GroupNorm (NCHW)

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

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

由上述結(jié)果可以確認，高轉(zhuǎn)置的數(shù)據(jù)移動是極具價值的優(yōu)化方向。隨著我們持續(xù)分析整張計算圖的布局行為，仍有進一步優(yōu)化的潛力。

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

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

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

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

實操示例：重現(xiàn)工作流

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

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

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

你將能學(xué)到什么：

如何將分割模型導(dǎo)出至 ExecuTorch，并啟用 XNNPACK 委派

如何在已啟用 SME2 的安卓、iOS 和 macOS 設(shè)備上構(gòu)建與部署模型

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

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

結(jié)論：SME2 帶來的實際改變

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

這對開發(fā)者和產(chǎn)品團隊意味著什么：

端側(cè)機器學(xué)習(xí)在 CPU 上更具可行性：SME2 可實現(xiàn)最高 3.9 倍的端到端推理加速。在安卓默認功耗設(shè)置下，真實交互式移動端模型的單核時延可從 1 秒以上降至約 300 毫秒。對于交互式工作負載，這使得基于 CPU 的端側(cè)機器學(xué)習(xí)從勉強可用變?yōu)榉€(wěn)定實用，同時為應(yīng)用其他功能保留性能空間。

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

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

性能分析給出下一階段優(yōu)化目標：當(dāng) SME2 加速了矩陣密集型算子（卷積/iGEMM、GEMM）后，性能瓶頸通常會轉(zhuǎn)向數(shù)據(jù)移動與未委派算子?；?ETDump 的算子級性能分析可清晰展示這類開銷，并提供可落地的優(yōu)化方向。

根據(jù)起點不同，有兩點明確的啟示：

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

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

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