這項由兩位研究者Satyam Kumar與Saurabh Jha獨立完成的研究，以arXiv預印本形式於2026年4月14日發布，論文編號為arXiv:2604.16498v1，歸類於電腦體系結構領域（cs.AR）。感興趣的讀者可通過該編號在arXiv平台查閱完整論文。
手機里的AI助手在幫你寫郵件、翻譯語言、識別照片的時候，背後其實有一套複雜的"翻譯系統"在悄悄工作。它的任務是把你安裝的AI程序翻譯成手機晶片能聽懂的語言，就像一位專業口譯員，坐在AI程序和晶片硬體之間，實時傳達雙方的意圖。這個"翻譯官"有個專業名字，叫做編譯器。
問題在於，現在主流的"翻譯官"——比如英特爾的OpenVINO和微軟的ONNX Runtime——工作方式相當笨重。它們在翻譯之前需要把AI程序先改寫成一種老舊的中間格式，就像要把普通話先翻譯成文言文，再從文言文翻譯成方言，繞了一大圈，不僅慢，還經常翻譯出錯。現代AI程序里有很多新式表達方式，文言文根本沒有對應詞彙，翻譯就卡住了。
這篇論文介紹的FORGE-UGC（全稱FX Optimization & Register-Graph Engine — Universal Graph Compiler，可以理解為"通用圖編譯引擎"）正是為了解決這個問題而生。兩位研究者從2025年12月開始，用不到半年時間，從零構建了一套全新的編譯系統。這套系統跳過了那道多餘的文言文翻譯環節，直接在原始AI程序和晶片之間建立了清晰、透明的溝通管道。在英特爾AI Boost神經處理單元（NPU，一種專門處理AI任務的晶片）上驗證的結果顯示，編譯速度比現有方案快了6.9到9.2倍，AI程序運行延遲降低了18.2%到35.7%，每次推理消耗的電量減少了30.2%到40.9%。
---
一、為什麼手機里需要專門的AI晶片，而不是直接用CPU？
要理解這個問題，可以把不同類型的晶片想像成不同專業的廚師。CPU（中央處理器）是全能廚師，炒菜、烘焙、擺盤什麼都會，但樣樣都只是中等水準，速度也不算快。GPU（圖形處理器）更像是專門做批量料理的流水線廚師，同時炒一百鍋的效率極高，特別適合需要大量重複計算的任務。而NPU（神經處理單元）則是專門為AI任務量身打造的廚師，處理那些密集的矩陣運算時，每一瓦電力產生的計算量遠超前兩者。
英特爾把這種NPU集成進了Meteor Lake和Arrow Lake系列處理器，品牌名叫AI Boost，能提供每秒11萬億次整數運算（11 TOPS INT8），功耗卻不超過10瓦——這相當於在一根燈泡的耗電量下，完成獨立顯卡十幾倍的AI效率。對於手機或筆記本電腦這種靠電池供電的設備來說，這種效率差距直接決定了AI助手能不能在本地流暢運行而不把電池榨乾。
然而，有了這麼好的硬體廚師，還需要一個能跟他溝通的助理。AI程序是用PyTorch這類工具寫的，語言是Python；而NPU晶片只懂自己的底層指令集。編譯器就是那個懂雙語的助理，負責把Python寫的菜譜翻譯成晶片能執行的烹飪動作。翻譯得好，晶片就能高效工作；翻譯得差，晶片就在不停地等待、重複勞動、浪費電力。
---
二、現有的"翻譯官"到底哪裡出了問題？
現有的兩套主流編譯工具——OpenVINO和ONNX Runtime——在設計上都有一個共同缺陷，就是它們無法直接讀懂現代PyTorch寫出的AI程序。
以OpenVINO為例，它的工作流程是這樣的：先把PyTorch程序轉換成ONNX格式（一種通用的AI模型描述語言），再把ONNX轉換成OpenVINO自己的專有格式，最後才送進NPU執行。這個過程就像把一本現代漢語小說先翻譯成英文，再翻譯成拉丁文，再交給羅馬工匠去製作雕塑。每次轉換都有資訊損失，而且現代AI程序里有很多新式結構——比如Llama-3、Mistral這類大語言模型用到的旋轉位置編碼（RoPE）、分組查詢注意力（GQA）、SwiGLU激活函數——這些東西在ONNX這種"舊語言"里根本沒有對應詞彙，翻譯就直接失敗了，開發者不得不手動把這些新結構拆解成更基礎的操作，費時費力且容易出錯。
除此之外，這兩套工具還有一個讓開發者頭疼的特點：整個翻譯過程是個黑箱。你把AI程序扔進去，等十幾分鐘，出來一個編譯好的版本，但你完全不知道編譯器在裡面做了什麼，哪些優化生效了，哪些沒有，也無法調試為什麼某個模型跑得特別慢。這就好比你把食材交給餐廳廚師，一小時後端出一道菜，但廚師絕不讓你進廚房，你永遠不知道他到底怎麼做的，食材有沒有被處理好，火候有沒有控制準確。
在內存管理上，這兩套工具同樣沒有提供有效的機制。AI程序在運行時會產生大量中間計算結果，它們就像廚房裡臨時擺放的半成品，需要合理安排放置位置，用完了就清掉，以免把工作檯堆滿。現有工具沒有暴露給開發者任何關於這些中間結果生命周期的資訊，導致晶片在CPU和NPU之間來回搬運數據，每次搬運都要花時間和電力。
編譯速度也是一個實際問題。對於80億參數規模的模型（比如Llama-3.1-8B），OpenVINO需要58秒，ONNX Runtime需要62秒才能完成編譯。在研究和開發階段，工程師每次調整模型後都要等這麼久才能看到結果，嚴重拖慢了疊代速度。
---
三、FORGE-UGC是怎麼繞過這些麻煩的？
FORGE-UGC的核心思路是：既然問題出在那道多餘的翻譯環節，那就乾脆不翻譯，直接在原始語言上工作。
PyTorch 2.x版本提供了一個叫做`torch.export`的功能，它能把AI程序的計算過程完整地捕獲成一張"計算圖"——可以把這張圖想像成一張精確的烹飪流程圖，上面標註了每道菜需要哪些食材、按什麼順序操作、中間產物傳遞給哪個步驟。這張圖使用的是PyTorch底層的ATen算子語言，涵蓋了包括RoPE、GQA、SwiGLU在內的所有現代操作，不需要經過任何中間格式轉換。
FORGE-UGC直接接收這張計算圖，然後分四個階段處理：
第一階段是圖的捕獲，也就是用`torch.export`把AI程序變成那張烹飪流程圖。這個階段還有一個細節處理：有些AI程序里有"共享參數"，比如GPT-2的詞嵌入層和語言模型頭部共用同一塊權重數據，就像兩道菜共用同一鍋高湯。FORGE-UGC會自動識別這種情況，確保兩個地方都指向同一份數據，而不是複製兩份，既節省內存又保證計算正確。
第二階段是圖的優化，這是整個系統最精華的部分，下一節會詳細展開。
第三階段是把優化後的計算圖轉換成一種叫做NPUIR的中間表示，給每個計算步驟打上標籤，註明它應該在NPU上運行還是在CPU上運行，以及輸入輸出用哪個"虛擬寄存器"（可以理解為臨時儲存格子的編號）。
第四階段是內存分配和指令調度，確定虛擬寄存器映射到實際物理內存的哪個位置，並調整執行順序，讓NPU任務儘可能連續執行，減少CPU和NPU之間來回切換的次數。
這四個階段共同產出一個叫做`CompiledNPUExecutor`的執行器，它是一個扁平化的指令列表，運行時不需要再做任何動態決策或內存分配，像一台按劇本表演的機器人，每步都提前安排好了。
---
四、那六道"優化工序"各自做了什麼？
第二階段的六個優化步驟是FORGE-UGC的核心技術所在，它們按照固定順序依次處理計算圖，每一步都有明確的任務，可以獨立測量效果，也可以單獨禁用某一步來測試其貢獻。
第一步叫死代碼消除。計算圖在捕獲時會包含一些實際執行時根本用不到的節點，比如調試用的中間輸出、梯度計算相關的分支等。這一步從輸出結果往回追溯，標記出所有真正需要的計算節點，剩下的一律刪掉，相當於在烹飪流程圖里劃掉那些"最終菜品不需要"的預備工序。
第二步叫公共子表達式消除。如果計算圖里有兩個地方做了完全相同的運算（相同的操作、相同的輸入），就只保留第一個，第二個直接復用第一個的結果。這就像發現流程圖里有兩處"切洋蔥"步驟，只需要切一次，把切好的洋蔥分給兩道菜用就行了。
第三步叫常量摺疊。如果某個計算的所有輸入在編譯時就已經是固定數值，那就直接提前算好結果，把那個計算節點替換成一個數字常量。比如AI程序里有`x + 0`或者`x × 1`這種毫無意義的運算，直接替換成`x`本身，節省運行時計算。
第四步叫注意力融合，這是六步中效果最顯著的一步。現代大語言模型的"注意力機制"（Attention）是讓模型理解上下文的核心計算，但在原始計算圖裡，它被分解成了一串獨立的操作：先做Q乘K的轉置，再除以縮放係數，再加掩碼，再經過softmax，再乘以V矩陣。每個箭頭都是一次獨立的晶片調度請求，中間結果都需要寫入內存再讀出來。FORGE-UGC會識別這個特定的操作模式，把整條鏈合併成一個單一的"融合注意力"調用，一次性完成所有計算，中間結果都在晶片內部流轉，不需要來回寫內存。這一步平均減少了14.6%的計算圖節點，對32層深的模型，延遲降低可達29.6%。
第五步叫算子融合。類似於注意力融合，這一步針對的是"線性層+激活函數"這種常見組合，比如Linear層後面跟著ReLU、GELU或者SiLU。原本需要兩次調度的操作合併成一次，由NNFactory（英特爾NPU的編程接口）編譯成一個統一的NPU指令。
第六步叫布局優化。NPU處理數據時，數據在內存里的排列方式（布局）對效率有很大影響。經過矩陣轉置或維度重排操作後，數據在內存里可能變得不連續，NPU讀取時需要額外複製一份連續的版本。這一步在進入NPU處理之前，提前把數據排列成NPU最喜歡的格式，省掉運行時的隱式複製開銷。
六步優化合在一起，在GPT-2（125M參數）上把計算圖節點數從403個減少到333個，降幅17.4%；在LFM2-2.6B上降幅達到21.9%。所有六步總耗時僅208毫秒，只占整個編譯時間的21.1%。
---
五、內存管理和指令調度的技術細節
第四階段的工作可以用一個倉庫管理的比喻來理解。計算圖里有大量中間計算結果需要臨時存放，就像倉庫里有很多貨物，每件貨物都有它的"入庫時間"（什麼時候被生產出來）和"出庫時間"（什麼時候被最後一次使用）。入庫到出庫之間叫做這件貨物的"存活區間"。
FORGE-UGC先做一次活性分析（Liveness Analysis），精確計算每個虛擬寄存器的存活區間。然後用一個叫做"線性掃描寄存器分配"的經典算法（這個算法複雜度是O(N log N)，比OpenVINO內部使用的圖著色方法的O(N?)複雜度低得多），貪心地把已經過了出庫時間的貨物儲存格子分配給新進來的貨物。這就像倉庫里一個貨架位被騰空後，立刻分配給下一批需要存放的貨物，而不是專門給每種貨物留一個固定的格子。
通過這種重用機制，物理緩衝區的數量比虛擬寄存器數量減少了30%到48%。具體來說，GPT-2的333個虛擬寄存器只需要218個物理緩衝區，Llama-3.1-8B的896個虛擬寄存器只需要468個物理緩衝區。
指令調度的任務則是調整執行順序。CPU和NPU是兩個獨立的處理單元，每次從一個切換到另一個都需要通過PCIe/MMIO接口搬運數據，每次切換大約耗時0.3到0.8毫秒。FORGE-UGC的調度器在滿足數據依賴關係的前提下，優先安排與當前設備相同的任務，讓NPU上的任務儘可能聚集在一起，CPU上的任務也聚集在一起，減少設備切換次數。
在Llama-3.1-8B上，調度前有264次CPUNPU切換，調度後減少到93次，降幅64.8%，消除了每次推理中大約50到130毫秒的切換開銷，占總延遲改善的11.2%。
---
六、研究結果：數字背後的真實含義
研究團隊在一台配備英特爾Core Ultra 9 285HX處理器和英特爾AI Boost NPU的工作站上，針對六個規模從1.25億到80億參數不等的語言模型進行了測試，數據集採用WikiText-103（語言建模標準測試集）和GLUE（多任務自然語言理解測試集）。
編譯速度的差距非常顯著。以最小的GPT-2（125M參數）為例，FORGE-UGC編譯需要1000毫秒，OpenVINO需要6930毫秒，ONNX Runtime需要7271毫秒，分別快了6.9倍和7.3倍。對最大的Llama-3.1-8B，FORGE-UGC需要6.7秒，而兩個基準框架分別需要58.4秒和62.2秒，差距進一步擴大到8.7倍和9.2倍。更值得注意的是，FORGE-UGC的編譯時間與模型層數基本成線性比例（大約每層210毫秒），而兩個基準框架的編譯時間隨層數增長呈超線性增長（大約按層數的1.4次方增長），這意味著模型越大，FORGE-UGC的優勢越明顯。
進一步分析編譯時間的構成，會發現一個有趣的事實：FORGE-UGC78%的編譯時間花在了`torch.export`圖捕獲這一步，而這是PyTorch本身的基礎功能，任何使用FX計算圖的工具都必須走這一步。FORGE-UGC自己的優化和後端處理只花了約216毫秒。換句話說，FORGE-UGC之所以比基準框架快，一部分是因為它省掉了對方需要額外做的ONNX/TorchScript轉換步驟，另一部分是因為它自己的優化算法更高效。
推理延遲的改善在不同模型規模上都很穩定。在WikiText-103上，GPT-2的平均延遲從8.45毫秒（OpenVINO）或9.13毫秒（ONNX Runtime）降到6.82毫秒，降幅19.3%；Llama-3.1-8B從91.37毫秒或97.82毫秒降到62.48毫秒，降幅分別為31.6%和36.1%。在GLUE數據集上，結果與WikiText-103高度一致，標準差不超過1.2%，說明這些改善來自圖結構優化，而不是針對特定數據集的僥倖表現。
延遲分布的穩定性同樣值得關注。FORGE-UGC的P99延遲（最差情況下99%的請求能在這個時間內完成）與P50延遲（中位數延遲）的比值穩定在1.20，而兩個基準框架的這個比值是1.27到1.28。這6到8個百分點的差距意味著，在對響應時間要求嚴格的邊緣部署場景中，FORGE-UGC能更可靠地滿足服務質量要求。
能耗數據可能是最令人印象深刻的部分。研究團隊使用英特爾的RAPL接口測量了推理過程中CPU和NPU的系統級功耗，GPT-2每次推理消耗69.6毫焦，而OpenVINO消耗99.7毫焦，ONNX Runtime消耗110.5毫焦，降幅分別是30.2%和37.0%。Llama-3.1-8B每次推理消耗637.3毫焦，而兩個基準框架分別消耗1078.2毫焦和1183.6毫焦，降幅達到40.9%和46.2%。能耗的改善幅度系統性地超過了延遲的改善幅度，原因在於FORGE-UGC不僅縮短了推理時間（時間短就少耗電），還降低了推理過程中的平均功耗（設備切換減少了調度開銷，預分配內存減少了動態內存分配帶來的DRAM功耗峰值）。
在數值精度方面，研究團隊對1000個隨機採樣的文本序列分別運行編譯前和編譯後的模型，比較輸出概率的差異。對於使用fp16精度的模型（1.25億到26億參數），最大絕對差異不超過1.2×10??，KL散度（衡量兩個概率分布差異的指標，越接近0表示越相似）低於6.3×10???，可以認為是數值誤差範圍內的完全一致。對於80億參數的Llama-3.1-8B，因為NNFactory在第四階段執行時應用了INT8權重量化（把模型從16位浮點精度壓縮到8位整數精度），最大絕對差異是2.1×10??，KL散度是8.4×10??，仍然處於實踐中可忽略不計的範圍內，困惑度（衡量語言模型質量的指標）在兩位小數精度下完全一致。
---
七、三個新指標：把編譯器的價值量化出來
研究團隊還提出了三個評估指標，幫助工程師更科學地比較不同編譯器。
第一個指標是每個優化步驟的執行時間。通過分別測量每個優化步驟的耗時，工程師可以清楚地知道哪個步驟最耗時、哪個步驟收益最大。在GPT-2上，算子融合耗時72毫秒，是最耗時的步驟，但注意力融合只需38毫秒，卻消除了59個節點，每毫秒消除1.55個節點，效率是算子融合（每毫秒消除0.17個節點）的9.1倍。
第二個指標叫融合增益比（FGR），它衡量的是禁用所有融合優化時的代價模型得分與完全開啟融合時的得分之比。這裡需要特別說明的是，FGR是一個基於啟發式代價模型的診斷工具，而不是實際延遲的直接比值。在Llama-3.1-8B上，FGR值是67.9，意思是融合把代價模型評估的估算成本壓縮到了原來的1/67.9，但對應的實際牆鍾時間延遲降低是29.6%，兩者之間不是線性關係。FGR的價值在於提供一個不依賴硬體執行就能比較不同編譯配置、不同模型融合效果的標準化指標。
第三個指標叫編譯效率指數（CEI），計算方式是推理延遲加速比除以編譯時間（以秒為單位）。CEI越高，說明每花一秒編譯時間能換來更多的推理速度提升。對於GPT-2，相對ONNX Runtime的CEI是1.339，意思是每秒編譯時間換來了1.339倍的推理速度提升。對於Llama-3.1-8B，CEI是0.233，隨模型變大而降低，因為編譯時間增長比推理加速更快。研究者特別指出，CEI主要適用於頻繁重新編譯的疊代開發場景，在"編譯一次、運行百萬次"的生產部署場景中，即使是6.7秒的編譯時間也完全可以忽略不計，絕對延遲改善才是關鍵指標。
---
八、消融實驗：拆開來看，哪步最關鍵？
研究團隊逐一禁用某個優化步驟來測量它的貢獻。結果明確指出，注意力融合是最關鍵的單一優化。禁用注意力融合後，代價模型得分從8.64急劇上升到238.34，增幅2658%；而禁用其他任何單一步驟，代價模型得分的變化都不超過3%。
從實際延遲的角度驗證這一結論，在12層的GPT-2上，啟用注意力融合比不啟用延遲降低16.6%；在32層的Llama-3.1-8B上，降低幅度達到29.6%。層數越多，效果越顯著，因為每個注意力模組都會被融合處理一次，層數越多，融合的節點越多。
融合激進程度（參數α，從0到1）的敏感性測試顯示，對NPU目標來說，α越高越好。這與GPU上的情況不同——GPU上過度融合會導致寄存器壓力增大，反而影響性能。NPU通過NNFactory把整個融合子圖作為一個單元調度，消除了所有中間調度開銷，因此融合得越徹底，節省越多。
自動調優（AutoTuning）模組在45種配置組合中選出最優配置，在200毫秒內完成，不需要實際運行硬體。自動調優比默認配置進一步改善了4.2%到8.7%的代價模型得分，且改善幅度隨模型規模增大而增大，因為更大的模型有更多樣化的子圖結構，更能受益於針對性配置。
---
九、這套系統和其他同類工具相比，到底獨特在哪裡？
同類工具中有幾個值得橫向比較。TVM是學術界影響力最大的深度學習編譯器，支持自動調優，但需要把模型導出到ONNX格式，引入了FORGE-UGC極力避免的導出環節，且不支持英特爾NPU目標。
XLA是谷歌為TPU和GPU開發的編譯器，支持整程序優化，但只能用於谷歌自家硬體生態。
IREE是最接近FORGE-UGC理念的開源框架，基於MLIR（多層中間表示）構建，支持可組合的優化步驟、多後端代碼生成和顯式內存管理。但IREE需要通過torch-mlir或StableHLO轉換才能接入PyTorch模型，再次引入了導出環節；更關鍵的是，IREE沒有英特爾NPU後端，也不支持NNFactory調度。研究者最初曾嘗試用IREE-Turbine（IREE的PyTorch前端）來構建這套系統，但遭遇了兩個難以繞過的障礙：MLIR的優化步驟必須用C++實現，Python調試周期很長；而且IREE完全沒有針對英特爾AI Boost NPU的後端，從頭實現需要巨大工程量。這段嘗試經歷最終促使研究者選擇了PyTorch FX計算圖作為基礎。
torch.compile（Inductor後端）是PyTorch官方的編譯工具，也直接操作FX計算圖，與FORGE-UGC在架構上最相似。但Inductor只針對CPU（C++代碼生成）和GPU（Triton核心）後端，沒有英特爾NPU調度，沒有NNFactory集成，也沒有基於存活區間的NPU緩衝區分配。研究者評估過把FORGE-UGC實現為torch.compile的自定義後端，但發現三個問題難以解決：torch.compile的後端API不支持在圖捕獲和代碼生成之間注入自定義步驟；NNFactory需要的是"編譯一次、作為整體調度"的執行模型，而torch.compile假設核心是可直接調用的Python函數；Inductor的內存規劃器是面向GPU設計的，不開放為可插拔組件。
Hexagon-MLIR是與FORGE-UGC同期出現的一個針對高通驍龍NPU的編譯棧，採用MLIR為基礎，支持Triton核心編譯，實現了Hexagon向量擴展（HVX）的向量化和NPU緊耦合內存（TCM）感知的分塊優化。兩者的目標硬體和IR基礎完全不同，但設計理念高度相似：可組合步驟、顯式內存管理、硬體感知調度。FORGE-UGC的作者認為，未來在高通Hexagon後端模組裡，可以借鑑Hexagon-MLIR在TCM感知分塊和雙緩衝方面的經驗，同時復用FORGE-UGC的整個前端和中間優化流程。
---
說到底，這項研究做的事情其實可以用一句話概括：把一套原本像黑箱一樣、讓開發者束手無策的晶片"翻譯官"，替換成了一套透明、可調試、可拆卸的工具鏈，同時還順帶把速度提高了將近10倍，把電量消耗降低了三分之一到四成。
對於普通用戶來說，這意味著你手機上的AI助手有一天可以跑得更快、更省電，不用每次思考半天才給你回答，同時也不會把電池消耗殆盡。對於開發者來說，這意味著他們可以看清楚自己的AI程序在晶片上到底經歷了什麼，在哪裡卡殼，為什麼這個步驟比那個步驟慢。對於整個行業來說，這套系統的架構設計——把硬體無關的優化層和硬體相關的後端層徹底分離——意味著當高通、AMD、蘋果或者三星的新一代NPU出現時，只需要新寫一個後端模組，前面那六道優化工序可以完全照搬。
這個研究還帶出了一個更深層的思考：在晶片硬體越來越強大的今天，軟體與硬體之間的"溝通層"是否已經成為新的瓶頸？好的硬體如果沒有好的編譯器來驅動，就像一輛賽車配了一個不會換擋的司機。FORGE-UGC給出的答案是，透明、可組合、硬體感知的編譯基礎設施，才是讓AI真正跑起來的關鍵。感興趣的讀者可以通過arXiv:2604.16498v1獲取完整論文，深入了解每個技術細節。
---
Q&A
Q1：FORGE-UGC編譯器和OpenVINO有什麼本質區別？
A：OpenVINO需要把PyTorch模型先轉成ONNX格式，再轉成自己的專有格式，才能送進NPU執行，這個過程不僅慢，還會因為格式差異導致現代大語言模型里的新式操作（如RoPE、GQA）轉換失敗。FORGE-UGC直接操作PyTorch原生的計算圖，跳過了所有中間格式轉換，編譯速度快了6.9到8.7倍，同時還暴露了每個優化步驟的詳細資訊，讓開發者可以清楚看到每一步做了什麼。
Q2：NPU和GPU處理AI任務有什麼不同？
A：GPU像是能同時做一百道菜的流水線廚師，並行計算能力極強但功耗較高，適合靈活多變的大規模任務。NPU是專門為密集矩陣運算優化的AI專用晶片，每瓦電力產生的AI計算量遠超GPU，特別適合手機、筆記本這類依賴電池的設備。英特爾AI Boost NPU在10瓦功耗下提供每秒11萬億次運算，比獨立顯卡的AI能效高出一個數量級，但需要配合高質量的編譯器才能發揮全部效能。
Q3：FORGE-UGC的注意力融合優化具體是怎麼工作的？
A：大語言模型的注意力機制在原始計算圖中被拆分成多個獨立步驟：Q乘K的轉置、縮放、掩碼、softmax、再乘V矩陣，每個步驟都是一次單獨的NPU調度請求，中間結果需要寫入內存再讀出。注意力融合識別出這個固定的操作鏈，把它合併成一個單一的"縮放點積注意力"調用，整個計算在晶片內部一次完成，中間結果不需要經過內存讀寫。這一步平均減少了14.6%的圖節點數，在32層深的模型上能讓推理延遲降低接近30%。
