AI處理器設計,從未如此複雜

藍鯨財經
昨天

文|半導體產業縱橫

在開發處理器時,理解應用的真實性質及其將運行的工作負載至關重要。

越來越多的人工智能(AI)處理器正圍繞特定工作負載而非標準化基準進行設計,旨在優化性能和功率效率,同時通常保留足夠的靈活性以適應未來的變化。

雖然矩陣乘法和軟件優化的基礎仍然適用,但僅靠這些已不再足夠。設計需要解決特定的數據類型、數據可能在何時何地被處理、將面臨何種約束,以及在設計進入製造和封裝階段時工作負載是否可能發生轉變等問題。這在AI領域尤爲重要,因爲算法的不斷變化會急劇縮短那些圍繞當前工作負載設計得過於緊湊的芯片的生命週期。

“在開發處理器時,理解應用的真實性質及其將運行的工作負載至關重要,”Arm公司CPU技術副總裁兼院士Frederic Piry說。“雖然基準測試對於展示性能目標很有價值,並且可以從中學到很多,但真實世界的工作負載引入了基準測試本身無法捕捉的變量。處理器開發者需要知道應用程序將如何執行。工作負載的執行頻率、競爭進程的存在以及內存等共享資源的負載都會影響性能。這些條件會改變內存延遲的暴露方式、預取器的調優方式以及緩存拓撲的設計方式。”

基準測試通常強調“完成時間”,但特定的工作負載可能有不同的衡量指標需要考慮。

“從系統層面思考工作負載很重要,”Piry說。“在移動設備中,後臺運行的應用程序可能會影響進程的運行方式,要求設計者考慮分支預測和預取學習率。在雲環境中,核心可能共享代碼和內存映射,從而影響緩存替換策略。甚至軟件棧也對結構大小和性能一致性有影響。處理器開發者還需要思考特性在真實工作負載中是如何被使用的。不同的應用程序可能會以不同的方式使用安全特性,這取決於它們如何與其他應用程序交互、編碼的安全性以及所需的整體安全級別。所有這些不同的選擇都揭示了不同的性能權衡,必須針對這些權衡進行設計和測試。”

以移動設備與數據中心的工作負載爲例。“用於手機的移動處理器運行的工作負載與針對特定市場且高度優化的AI處理器截然不同,”Rambus的傑出發明家兼院士Steve Woo說。“架構師需要理解市場需求的差異,以及如何對不同特性進行優先級排序以滿足市場需求。例如,移動處理器要求低功耗和功耗模式之間的快速切換,而用於最大型AI模型的數據中心AI處理器則需要最高的性能、最高的內存帶寬和快速的連接性,以便將大型問題分解到多個處理器上。處理器架構師還必須理解目標工作負載的計算特性。是否存在帶寬密集型、延遲敏感型或計算密集型階段?它們之間如何相互作用?對於AI工作負載,這意味着要對大型語言模型(LLM)等AI模型進行性能分析,以理解計算、通信和內存訪問模式、可用的並行性以及數據在系統中的移動方式。算法分析、代碼重構以及模擬器、性能計數器和工作負載追蹤等工具有助於量化這些行爲,然後用於指導架構和系統設計,並且在AI這樣快速演進的領域中,對於平衡靈活性、功耗和吞吐量尤其有幫助,因爲這些領域的工作負載變化迅速。”

對工作負載有深入理解的公司可以優化自己的設計,因爲他們清楚設備將如何被使用。這比通用解決方案提供了更顯著的好處。

“整個設計過程都致力於滿足那些更狹義和深入理解的需求,而不必爲任何可能的輸入都能工作,這本身就帶來了優勢,”現隸屬於Synopsys的Ansys產品營銷經理Marc Swinnen說。

然而,這說起來容易做起來難。“神經網絡開發涉及的認知負荷相當高,特別是當你考慮爲某個設備優化這些東西時,”Arm負責AI和開發者平臺的院士Geraint North說。“開發者腦子裏需要同時處理兩件事。一件是他們模型的架構,他們關心的是模型的準確度、大小等方面。如今的機器學習開發者對此已經很瞭解。挑戰在於當你開始轉向設備端時,因爲你還必須開始擔心NPU(神經處理單元)是否真的能夠運行我優化後的模型。這就是爲什麼我們如此專注於提升CPU的性能。CPU的優勢在於它是通用計算單元。你幾乎可以保證它能處理你扔給它的任何算子、任何數據類型。我們與Stability AI合作時看到一個有趣的現象:他們真正優化的網絡部分,SME 2使其速度快了很多;而他們沒有花時間優化的部分,SME 2使其速度更快。因此,即使是機器學習工程師沒有花時間優化的部分——他們不優化是有充分理由的——也不是工作負載的重大部分,SME 2將這些部分加速了大約八到九倍。所以我們專注於CPU的原因是,它能讓機器學習工程師繼續專注於他們今天已經在擔心的事情,而不必再爲硬件加速器的細微差別而煩惱。”

理解數據類型

AI處理器開發者需要知道將要處理哪些數據類型,以及將要執行的算法的大致領域。

“要開發一個好的音頻處理器,處理器中的數據路徑需要能夠原生處理預期的音頻數據採樣位精度,”Quadric首席營銷官Steve Roddy說。“音頻數據是8位(低保真度)還是12位採樣?或者是非常高精度的,比如完整的Float32?所有的寄存器文件和硬件單元(如乘加單元)都需要理解這些數據類型,尤其是累加寄存器。該音頻處理器需要有能夠高效運行典型音頻濾波和音頻處理算法的原生指令。但該音頻DSP的開發者不需要在杜比或DTS工作,也無需接觸3D定位音頻技術棧中數百萬行的代碼。”

對於SoC(系統級芯片)開發者來說也是如此。“我們的NPU很容易集成,”Cadence公司AI IP產品營銷總監Jason Lawley說。“我們有一個AXI接口,它會處理已優化的架構規範。與之配套的軟件負責將那些來自框架的工作負載映射進來。很多時候,客戶在PyTorch或TensorFlow中進行開發。然後我們將該網絡映射到NPU中,這樣他們在開發SoC時就知道設計中有一個通用的CPU部分,還有一個加速器,即NPU。當他們得到通常是音頻或視頻幀的工作負載時,他們所要做的就是編譯那個特定的工作負載。當進入加速部分時,他們調用一個簡單的API代碼,然後系統會說,‘哦,這是那一幀,讓我把內置的指令發下去。’它進行加速,然後他們得到結果。很多走IP路徑的客戶都是這樣做的。如果你不走IP路徑,你仍然需要做所有這些事,但你可能不會那麼關注引擎的可配置性,或者試圖確保你已完全優化並以最佳方式點亮所有硬件。這也行,取決於他們的工作負載是否能被滿足。”

同樣,對於AI,需要考慮的關鍵因素是數據類型和通用用例。“一個僅限視覺的NPU,如果主要是一臺INT8機器(8 x 8 MAC),可能會表現得相當不錯,”Quadric的Roddy說。“想轉而運行LLM?那可能需要4位權重來壓縮巨大的模型,但需要16位激活值(甚至可能是float16)來保持準確性,因此4 x 16 MAC是基本構建模塊。你想運行多少種類型的網絡,其廣度將決定一個僅支持30或40個圖算子的固定功能NPU加速器是否足夠,還是你需要一個能運行當今PyTorch中2300多個算子的處理器。所有這些最終都歸結爲數據類型和算子,但這並不要求在設計LLM時具備任何數據科學專業知識,也不要求任何終端市場專業知識來構建一個能在例如汽車IVI和ADAS系統中取得成功的NPU處理器。簡而言之,你需要知道AI工作負載裏有什麼,而不是如何創建它們。”

不同類型的處理器之間,設計者需要了解的知識也存在差異。

“用於手機的電池供電移動處理器的設計者專注於功耗和快速的功耗狀態轉換,處理器在支持小內存容量的小尺寸環境中獨立工作,”Rambus的Woo說。“相比之下,用於最大型工作負載訓練和推理的數據中心AI處理器專注於性能和吞吐量,擁有更大的功率預算和先進的散熱解決方案,並能訪問更高的內存容量和帶寬。專注於AI訓練的GPU設計者會優先考慮這些數據密集型任務的並行性和內存帶寬。同時,爲推理優化的處理器通常資源要求較低,因爲模型被量化以減少內存容量和帶寬需求。定向處理流水線提高了在數據中心外使用的設備的效率。每種處理器類型都要求對工作負載結構、性能瓶頸和部署環境(無論是雲規模、移動還是嵌入式)有量身定製的理解。”

表示工作負載

向NPU設計者表示工作負載的最佳方式是什麼?Roddy說最簡單的解決方案是提供一組代表性的基準模型。

“假設你想構建一臺真正高效的LLM推理‘機器’來運行Llama和DeepSeek的模型,”Roddy解釋道。“從已發佈的公開模型開始。模型的結構——即圖算子及其互連——都是公開的。專有的、通常保密的是訓練好的模型權重——那數十億的參數。分析參考模型,你很快就能看到:a) 數據類型(精度);b) 所需的計算——MAC、高斯方程、二次方程、簡單平均,或控制流操作——以及,c) 這些操作中每一種的頻率或強度,即哪些操作被執行數十億次,而哪些只執行兩次。唯一棘手的部分是準確描述你希望機器能夠應對的未來變化。數據類型會變嗎?常用的算子會變嗎?請注意,PyTorch有超過2300個算子,其中大部分今天很少使用,但可能在未來的AI創新中突然變得至關重要。今天的已知工作負載,加上你需要的未來靈活性的範圍,將完全描述需要解決的問題。”

與此同時,終端應用可能會提供明確的限制,或至少是邊界條件,供處理器設計時考慮。“例如,在安全關鍵型應用中就是如此,其中需要部署看門狗或鎖步等安全機制,以防止處理器陷入任何類型的死鎖,”弗勞恩霍夫集成電路研究所(Fraunhofer IIS)自適應系統工程部設計方法主管Roland Jancke指出。“對於這種情況,有相應的標準和測試程序,以便設計可以根據這些標準進行認證。”

來自應用的其他要求,如能耗,則不那麼容易量化。“對於手頭的任務,一個全功能的水冷AI加速器可能是理想的,但對於輕量級無人機應用來說就太重了,”Jancke說。“總的來說,自主系統會爲處理器設計提供功耗和重量的邊界條件。另一方面,我們與業界交流的經驗是,問題常常反過來問。‘特定算法的開發者需要多大程度上了解執行處理器的確切結構和屬性?’當然,瞭解可用處理單元的細節可能會提高算法實現的效率。然而,這些架構細節在開發週期中可能會改變。考慮到這一點,我們看到一種日益增長的抽象化趨勢。建立一個定義良好的接口,如API,爲硬件和軟件的相對獨立開發提供了可能性。軟件基於該API開發,而硬件則專注於儘可能高效地實現API的指令。即使不瞭解也未考慮確切的應用,這也可能對開發過程有利。”

所有這些技術考慮,正是爲什麼AI IP對一些AI處理器開發者來說是有意義的。“SoC開發者必須理解客戶想要什麼,”Cadence的Lawley說。“但很多人忽略的另一個關鍵部分是編譯將在其SoC上運行的AI模型的軟件。他們將不得不在解決方案的整個生命週期內開發和維護它,而隨着AI變化如此之快,組建一個軟件團隊並找到合適的人才是昂貴的。你必須找到不僅是AI開發者的編譯器專家。他們必須獲取那個模型,編譯它,然後優化它以在他們創建的特定硬件上運行。很多時候這對他們來說是困難的,除非他們有非常特定的、定製的工作負載,並且總是在上面運行相同的模型。例如,在嵌入式領域,設計用於特定機器人之類的SoC的團隊可以說,‘我們知道我們將會有某種AI模型。’如果你回顧最初的NPU設計,很多更像是美其名曰的矩陣乘法引擎。關於NPU將要做什麼的炒作很多。它們將解決世界飢餓問題並加速AI。所以我們已經進入了NPU的‘祛魅’階段,但這是暫時的。我們正在進入第二代和第三代NPU。我們正處於第二代,並且我們已經學到了很多關於NPU架構需要是什麼樣子,才能使其對通用AI加速更有用。”

處理器專業化與支持不斷演變的工作負載的現實之間的這種相互作用,對設計者來說是一個巨大的挑戰。準確預測活動既是必要的,又是難以捉摸的。

“這說起來容易做起來難,”Ansys的Swinnen說,“在運行一個程序時,你如何捕捉例如蘋果的Safari瀏覽器?這種活動與Firefox或Chrome有何不同?如果蘋果想讓其芯片對Safari更高效,你如何捕捉這一點?那是數百萬行的軟件代碼。你無法輕易地將在芯片設計中使用的東西捕捉下來。”

這就是仿真(emulation)發揮作用的地方。“對於那些負責猜測或預測工作負載樣子的驗證工程師和RTL設計師來說,他們已經做得很好,但當仿真平臺被創造出來時,它是革命性的,因爲它消除了系統中的猜測,”現隸屬於Synopsys的Ansys的Suhail Saif觀察到。“你可以將你的系統以FPGA格式或類似形式,放到仿真器上,並在製造前運行真實的工作負載。而當涉及到真實的工作負載時,無論是在iPhone上運行Safari瀏覽器,還是在手機上播放YouTube視頻、打電話,或在iPad上玩遊戲等,這些都是芯片、系統或設備設計者希望其最終用戶做的非常真實的工作負載場景。從仿真中得到的活動文件是無可否認的,因爲它代表了100%真實的工作負載場景。如果你在通過該工作負載向量模擬你的設計時發現問題,那麼你就可以毫無疑問地確定,這是你在進入製造前必須修復的問題,因爲它暴露了來自真實工作負載的真實問題。在功耗估算、電壓降分析和爲信號網絡設計供電網絡時,我們一直依賴這些來自仿真的真實工作負載,它們具有最大的權重。”

結論

AI處理器需要在性能、功耗和足夠的面積之間取得平衡,以幫助使設計面向未來。“沒有人會因爲在他們的SoC中增加一點AI而被解僱,”Lawley說。“無論你是從IP提供商那裏獲得一些東西,還是在你的SoC中增加一些矩陣乘法能力,現在都是時候這麼做了,因爲每個人將來都會回頭看然後說,‘我真希望我的硬件裏有更多的AI能力,’因爲那纔是難的部分。對於SoC來說,構建一個SoC需要兩到五年的週期。我們兩年前在哪裏,從現在起兩到三年後這些設備發佈時我們又會在哪裏?在AI能力和靈活的AI能力上投入面積將是重要的,即使是對於它所進入的機器人,即使你正在做這些非常特定的功能。模型變化很快。對於現在的一個模型,誰知道將來會不會有一個經過充分優化且更好的新模型。所以要確保你的SoC中有AI能力,然後儘量確保它儘可能靈活,並且它連接到可以以多種方式使用的系統中。” 

免責聲明:投資有風險,本文並非投資建議,以上內容不應被視為任何金融產品的購買或出售要約、建議或邀請,作者或其他用戶的任何相關討論、評論或帖子也不應被視為此類內容。本文僅供一般參考,不考慮您的個人投資目標、財務狀況或需求。TTM對信息的準確性和完整性不承擔任何責任或保證,投資者應自行研究並在投資前尋求專業建議。

熱議股票

  1. 1
     
     
     
     
  2. 2
     
     
     
     
  3. 3
     
     
     
     
  4. 4
     
     
     
     
  5. 5
     
     
     
     
  6. 6
     
     
     
     
  7. 7
     
     
     
     
  8. 8
     
     
     
     
  9. 9
     
     
     
     
  10. 10