AI芯片這行聊架構(gòu)的文章很多聊編譯器和指令集的文章也不少但能把“軟硬件設(shè)計(jì)”串成一條線講清楚的確實(shí)不多。這個(gè)系列我寫到了第6篇前幾篇我把脈動(dòng)陣列、片上網(wǎng)絡(luò)、存儲(chǔ)層次這些硬件架構(gòu)翻來覆去講過一遍。結(jié)果不少做軟件的朋友留言說你們硬件選型倒是講得熱鬧可這些東西到底怎么跟編譯器、算子庫配合為什么同一塊芯片有人能跑到理論峰值的80%有人拼了命只能用到三成這篇文章我就把軟硬件協(xié)同設(shè)計(jì)里最容易被忽略、但決定成敗的幾個(gè)環(huán)節(jié)——算子映射、指令集裁剪、編譯器適配、流片前聯(lián)合驗(yàn)證——挑出來逐個(gè)拆開。適合正在做AI芯片工具鏈、或者準(zhǔn)備從算法轉(zhuǎn)芯片方向的人讀如果你剛?cè)腴T也不用慌我會(huì)先講清楚“為什么必須要軟硬件協(xié)同”再把每一環(huán)背后的邏輯說透。1. 軟硬件劃分AI芯片設(shè)計(jì)的第一個(gè)岔路口1.1 為什么說架構(gòu)決定軟件的天花板很多人以為軟硬件協(xié)同是從寫代碼那一刻開始的其實(shí)不是真正的分岔路口在芯片定義階段就出現(xiàn)了。你要先想清楚哪些計(jì)算被固化到硬件里哪些留給軟件去靈活處理。這個(gè)劃分決定了后面的軟件團(tuán)隊(duì)在幾層樓里跳舞也決定了你的芯片兩年后是“一把梭”還是“生銹的老古董”。拿卷積舉例。卷積運(yùn)算在圖像和AI模型里占了九成以上的計(jì)算量錘死在硬件里很劃算。但你要是把所有的卷積細(xì)節(jié)、不同的padding方式、不同尺寸的kernel全部用純硬件邏輯實(shí)現(xiàn)那芯片面積會(huì)爆掉功耗也會(huì)失控。而且算法迭代特別快今天流行卷積明天可能流行注意力機(jī)制或者新的算子。硬件一旦固死了就只能看著新模型干瞪眼。所以業(yè)界的普遍做法是把最底層的乘累加陣列、激活函數(shù)、池化這類“原子操作”做成硬件單元而把“如何組合這些原子操作”留給了指令流。這就是軟硬件劃分的核心硬件負(fù)責(zé)確定性高、重復(fù)性高、能耗敏感的部分軟件負(fù)責(zé)策略性、組合性和未來可擴(kuò)展的部分。我參與過某AI推理加速芯片項(xiàng)目當(dāng)時(shí)團(tuán)隊(duì)就為“是否把softmax也做成硬件單元”吵了一星期。做硬件的人說softmax里那個(gè)exp和除法太費(fèi)電必須硬化做軟件的人說模型里經(jīng)常有自定義變體硬死了不好改。最后方案是把exp查表做成了硬件小單元但softmax的整體流程交給軟件算子庫去拼裝。這樣既保住了大部分功耗收益又留了靈活性。1.2 劃分時(shí)的取舍原則做軟硬件劃分時(shí)我建議死守三條原則。第一看“調(diào)用頻率”。頻率極高的算子例如矩陣乘、卷積、向量加法果斷傾向硬化一年用不上幾次的算子就算再復(fù)雜也別為它浪費(fèi)芯片面積。第二看“數(shù)據(jù)依賴復(fù)雜度”。像卷積這種數(shù)據(jù)復(fù)用規(guī)律非常清晰的計(jì)算硬化后可以用脈動(dòng)陣列把數(shù)據(jù)搬移成本壓到極低而像動(dòng)態(tài)維度、動(dòng)態(tài)shape這類運(yùn)行時(shí)才能確定的東西硬到硬件里只會(huì)讓你想砸鍵盤。第三看“生態(tài)兼容窗口”。你做的芯片總要跑主流框架吧哪怕今天某個(gè)算子不常用但如果它長(zhǎng)在主流模型的骨干路徑上那硬件還得多留一步軟實(shí)現(xiàn)的后路。這里有個(gè)容易踩的坑過度適配。我見過某芯片把三年前的某小眾模型算子固化得非常漂亮性能好看得很但過兩年那個(gè)模型已經(jīng)沒人用了芯片反而因?yàn)槟遣糠钟布加脹]法給新算子騰地方。軟硬件劃分的本質(zhì)是風(fēng)險(xiǎn)管理不是炫技。2. 算子映射與指令集設(shè)計(jì)讓硬件聽懂算法2.1 從Tensor到指令算子映射的路徑假設(shè)你已經(jīng)從算法里抽出來了一個(gè)矩陣乘算子下一步就是要把這個(gè)算子翻譯成芯片能執(zhí)行的指令序列。這段路大多數(shù)人叫“算子下發(fā)”但里面門道很深。首先你要把矩陣乘這個(gè)邏輯操作拆成循環(huán)嵌套遍歷輸出矩陣的行、列然后做內(nèi)積。針對(duì)每個(gè)芯片的計(jì)算陣列規(guī)模循環(huán)要切塊tiling。比如你的片上陣列是16x16的乘法單元但你算的矩陣是128x128那就得把大矩陣切成一堆16x16的小塊再一塊塊喂進(jìn)去。這個(gè)切塊的大小直接影響兩個(gè)東西一是數(shù)據(jù)復(fù)用小塊從片外搬上來越少越好二是流水線銜接上一塊還在算下一塊的數(shù)據(jù)最好已經(jīng)在片上等著了。很多芯片利用率低不是因?yàn)橛?jì)算陣列不行而是因?yàn)榍袎K策略一塌糊涂算一會(huì)兒等一會(huì)兒等于花錢養(yǎng)了一堆閑著的乘法器。我舉個(gè)例子某芯片的矩陣單元是32x32的MAC陣列理論算力挺高。結(jié)果跑一個(gè)維度為512的全連接層時(shí)軟件團(tuán)隊(duì)直接把整個(gè)矩陣按一個(gè)小塊硬拆片外拷了四次數(shù)據(jù)把時(shí)間全浪費(fèi)在DDR帶寬上了。后來改成混合分塊行方向按32拆列方向按64拆讓片上數(shù)據(jù)復(fù)用率達(dá)到70%以上實(shí)測(cè)端到端延遲直接降了三分之一。2.2 指令集擴(kuò)展的取舍把算子拆分好了還得靠指令把它表達(dá)出來。早期很多AI芯片直接沿用CPU的SIMD指令后來發(fā)現(xiàn)矩陣乘用SIMD指令得拆成無數(shù)條向量乘加指令流量太大跑到飛起性能也上不去。于是大家開始做指令集擴(kuò)展。一種是VLIW風(fēng)格一條超長(zhǎng)指令同時(shí)控制多個(gè)功能單元并行工作。好處是編譯器可以做大量調(diào)度壞處是解碼器復(fù)雜、指令字長(zhǎng)驚人很容易把指令存儲(chǔ)空間吃滿。一種是張量指令風(fēng)格就是你現(xiàn)在經(jīng)常聽到的“一條指令算一個(gè)矩陣乘”。這種方法指令密度高但對(duì)硬件的數(shù)據(jù)通路要求也高通常得配合專門的脈動(dòng)陣列或二維寄存器堆。我和不少同行聊過現(xiàn)在主流趨勢(shì)其實(shí)是混合模式控制密集、不規(guī)則的部分用通用指令計(jì)算密集、規(guī)則的部分用張量指令。關(guān)鍵是接口要干凈別讓軟件每次下發(fā)都要猜硬件狀態(tài)。我看過一些芯片手冊(cè)指令集設(shè)計(jì)得極其豐富但編譯器只用了其中三分之一剩下全是沒用的死功能。指令集不是越多越強(qiáng)而是找出現(xiàn)實(shí)模型里最常出現(xiàn)的計(jì)算模式把那些模式啃下來就夠了。這個(gè)取舍在AI芯片上比傳統(tǒng)處理器要激進(jìn)得多——因?yàn)锳I芯片的指令集是和一個(gè)相對(duì)封閉的模型生態(tài)打交道的少而精準(zhǔn)更香。3. 編譯器與運(yùn)行時(shí)把高層語言落到底層硬件3.1 編譯器的層次與分工指令集的另一端就是編譯器。AI芯片的編譯器和傳統(tǒng)編譯器長(zhǎng)得不太一樣它更像一個(gè)“調(diào)度器優(yōu)化器代碼生成器”的組合體。一般分三層干活前端負(fù)責(zé)把PyTorch、TensorFlow出來的計(jì)算圖接進(jìn)來做算子融合。比如把卷積后面的批量歸一化、ReLU融合進(jìn)同一個(gè)算子減少一次中間結(jié)果落回內(nèi)存。很多新手工改框架后端往往只盯著單個(gè)算子跑得快不快完全忘了算子之間的數(shù)據(jù)搬運(yùn)才是真正的消耗大戶。融合一次可能比單個(gè)算子優(yōu)化半天的收益還大。中端負(fù)責(zé)和硬件參數(shù)打交道做循環(huán)分塊、數(shù)據(jù)布局轉(zhuǎn)換、內(nèi)存分配。這一層是最容易翻車的。比如二維數(shù)據(jù)在內(nèi)存里是按行還是按列排直接決定搬運(yùn)效率和向量化效率。很多算法模型用NCHW格式但你的硬件如果對(duì)NHWC更友好編譯器就得自動(dòng)插入layout轉(zhuǎn)換這個(gè)轉(zhuǎn)換本身也有成本如何均衡是門手藝活。后端就是所謂的指令調(diào)度。把已經(jīng)標(biāo)好的操作排序、綁定到具體的執(zhí)行單元、處理好流水線停頓。如果前中端做得好后端壓力會(huì)小很多反之后端再精心打補(bǔ)丁也沒用。有個(gè)觀點(diǎn)我想多說一句AI芯片編譯器里永遠(yuǎn)不要指望“一招吃遍天”。不同模型、不同尺寸的算子最優(yōu)調(diào)度方案可能截然不同。與其在編譯器里堆一堆規(guī)則不如建立一個(gè)靜態(tài)性能模型讓編譯器基于成本模型做決策。我在某項(xiàng)目里就用了個(gè)非常簡(jiǎn)化的帶寬估算模型就把不少算子的調(diào)度決策從“拍腦袋”改成了“按數(shù)據(jù)計(jì)算”效果立竿見影。3.2 算子調(diào)度與內(nèi)存分配講到具體操作大部分性能問題都繞不開存儲(chǔ)層次。AI芯片基本都有寄存器堆、SRAM、DDR這幾級(jí)存儲(chǔ)。數(shù)據(jù)從DDR搬到SRAM要幾十上百個(gè)周期從SRAM搬到寄存器堆只要幾個(gè)周期差距懸殊。所以核心原則就一句話盡可能讓數(shù)據(jù)在離計(jì)算單元近的地方多被復(fù)用幾次。我做算子調(diào)優(yōu)時(shí)常用的手段是“雙重循環(huán)分塊”先按輸出通道分塊讓同一塊輸入數(shù)據(jù)對(duì)應(yīng)多個(gè)輸出通道的計(jì)算再按輸入通道分塊讓同一輸出區(qū)域復(fù)用多組輸入。這樣做能顯著增加SRAM里的數(shù)據(jù)命中次數(shù)而不是每算一個(gè)小塊跑去DDR搬數(shù)據(jù)。內(nèi)存分配呢最大的坑是“內(nèi)存碎片”。AI芯片的SRAM通常不大幾兆已經(jīng)算多的但模型一進(jìn)來各種張量同時(shí)并存如果你用簡(jiǎn)單的先到先得策略很容易把SRAM拆得七零八落最后大模型根本裝不下。我見過做得好的編譯器會(huì)先用一個(gè)“模擬退火貪心”的分配器搜索一遍把生命周期相近的張量安排到重疊區(qū)域然后把剩余空間整合給最大的中間結(jié)果。這一步做扎實(shí)了某些模型占用面積能減少四成。3.3 運(yùn)行時(shí)與驅(qū)動(dòng)的設(shè)計(jì)編譯出來的“可執(zhí)行文件”只是一堆指令和數(shù)據(jù)的集合真正讓它們?cè)谛酒限D(zhuǎn)起來的是運(yùn)行時(shí)和驅(qū)動(dòng)。運(yùn)行時(shí)干的事很雜內(nèi)存管理、任務(wù)隊(duì)列、同步、性能計(jì)數(shù)器的上報(bào)。我印象最深的是任務(wù)啟動(dòng)成本。很多芯片每次下發(fā)一個(gè)小算子驅(qū)動(dòng)就要做一堆寄存器配置、內(nèi)存映射、中斷處理。如果一個(gè)模型有幾百個(gè)小算子每秒跑幾百輪光啟動(dòng)開銷就把性能吃光了。這也解釋了為什么現(xiàn)在的落地產(chǎn)品格外強(qiáng)調(diào)“大算子fusion 一次下發(fā)”把幾百個(gè)小算子揉成幾個(gè)大任務(wù)啟動(dòng)開銷一下子降到可以忽略。另外別小看了性能計(jì)數(shù)器的設(shè)計(jì)。調(diào)優(yōu)的時(shí)候沒有精確的cycle數(shù)據(jù)你只能瞎猜瓶頸在哪。給運(yùn)行時(shí)加上指令計(jì)數(shù)、緩存miss計(jì)數(shù)、DRAM讀寫帶寬統(tǒng)計(jì)讓軟件團(tuán)隊(duì)能拿到多條硬件流水線的吞吐和占用率這是軟硬件協(xié)同能否持續(xù)優(yōu)化的關(guān)鍵。某芯片就是因?yàn)樵谟布锫窳艘唤M輕量級(jí)的性能監(jiān)控點(diǎn)之后編譯器團(tuán)隊(duì)才有了明確的優(yōu)化方向。4. 軟硬件協(xié)同驗(yàn)證流片前如何提前發(fā)現(xiàn)問題4.1 性能建模與仿真的位置軟硬件設(shè)計(jì)最大的痛點(diǎn)是軟件開發(fā)想提早進(jìn)行但芯片還沒流片。傳統(tǒng)的做法是各干各的——硬件做RTL仿真軟件做指令模擬器兩邊完全脫節(jié)到了板子上才發(fā)現(xiàn)軟硬件接口對(duì)不上一改就是幾個(gè)月周期根本等不起。我現(xiàn)在強(qiáng)烈建議在項(xiàng)目初期就建立一套“性能模型指令集模擬器”的組合。性能模型不需要拿到精確到信號(hào)級(jí)的延遲但要用會(huì)計(jì)量數(shù)據(jù)在每一級(jí)存儲(chǔ)上的駐留時(shí)間、算子執(zhí)行單元的占用情況。它能在一小時(shí)內(nèi)驗(yàn)證“某種切塊策略會(huì)不會(huì)導(dǎo)致長(zhǎng)時(shí)間等待”給指令集設(shè)計(jì)提需求。指令集模擬器則更精細(xì)一點(diǎn)執(zhí)行具體的指令流輸出計(jì)算和搬運(yùn)事件的時(shí)序。兩套工具并行相當(dāng)于在設(shè)計(jì)階段就跑通了軟硬件接口。好多人跟我抱怨說性能建模工作量太大做不完。我的體會(huì)是別沉浸在精確度里先做能算“相對(duì)瓶頸”的工具。你需要回答的其實(shí)只有三個(gè)問題數(shù)據(jù)搬運(yùn)需要多少個(gè)cycle計(jì)算單元有多少cycle是空閑的到底誰在拖誰的后腿有了這三個(gè)答案大部分架構(gòu)問題就現(xiàn)形了。4.2 虛擬原型與聯(lián)合調(diào)優(yōu)等指令集和編譯器初版都有了更完整的驗(yàn)收到虛擬原型Virtual Prototype階段。這一層可以用軟件模擬器把RTL的行為模型化讓完整應(yīng)用在上面跑甚至把調(diào)度器的策略放進(jìn)去觀察效果。我在某項(xiàng)目中做過一次實(shí)驗(yàn)同樣是卷積算子在虛擬原型上換了一種存儲(chǔ)排列順序利用率從56%升到78%而這次調(diào)整發(fā)生在流片前半年相當(dāng)于白賺了一輪性能優(yōu)化。不過虛擬原型也有自己的問題速度慢。給你一個(gè)調(diào)試用的慢版本可以但別指望它大規(guī)模跑訓(xùn)練或推演整套手機(jī)端性能。所以在實(shí)踐中我會(huì)把驗(yàn)證策略分成三檔單算子級(jí)別跑架構(gòu)級(jí)模擬器小網(wǎng)絡(luò)級(jí)別跑虛擬原型完整應(yīng)用則等在基于離線生成性能預(yù)測(cè)的階段再估算。這樣既不犧牲吞吐又能盡早暴露深層的不一致。說到聯(lián)合調(diào)優(yōu)還有個(gè)細(xì)節(jié)一定要讓軟件團(tuán)隊(duì)在早期就參與驅(qū)動(dòng)接口定義。很多芯片團(tuán)隊(duì)硬件做完才甩給軟件說“你們的編譯器適配吧”結(jié)果兩邊對(duì)寄存器接口的理解根本不在一頻道。我習(xí)慣做法是每個(gè)硬件模塊定義完之后立即讓軟件寫一個(gè)最小的煙霧測(cè)試smoke test在仿真環(huán)境里跑通基本算子有問題當(dāng)天反饋。這樣哪怕到流片時(shí)才暴露BUG也能迅速縮小到具體模塊而不是在全系統(tǒng)里盲人摸象。5. 從實(shí)測(cè)數(shù)據(jù)看軟硬件協(xié)同調(diào)優(yōu)的收益5.1 核心數(shù)據(jù)指標(biāo)怎么讀真正開始調(diào)優(yōu)了怎么看數(shù)據(jù)業(yè)內(nèi)有幾個(gè)關(guān)鍵指標(biāo)我每次都會(huì)讓團(tuán)隊(duì)把這幾項(xiàng)打印出來算子占用率、內(nèi)存帶寬利用率、片內(nèi)復(fù)用率、任務(wù)啟動(dòng)開銷占比。算子占用率計(jì)算單元真正在算的時(shí)間占比。長(zhǎng)期低于50%說明調(diào)度或切塊有問題。內(nèi)存帶寬利用率DDR或SRAM端口實(shí)際傳輸和理論峰值之比。高占用率但性能差可能是數(shù)據(jù)搬運(yùn)重復(fù)了而不是帶寬不夠。片內(nèi)復(fù)用率每次數(shù)據(jù)從內(nèi)存搬進(jìn)片上后被計(jì)算單元用了多少次。大于10基本健康小于3基本在發(fā)呆。任務(wù)啟動(dòng)開銷占比驅(qū)動(dòng)和運(yùn)行時(shí)消耗周期在所有計(jì)算周期中的比例。超過20%說明你得好好做算子融合了。以上這些指標(biāo)不要一次性全看那樣容易信息過載。我是習(xí)慣把一張熱力圖打出來橫軸是時(shí)間縱軸是不同硬件單元的活動(dòng)度。哪一個(gè)單元一直在跑、哪一個(gè)單元閑得像條咸魚一眼就看出來。比如計(jì)算單元燒滿但數(shù)據(jù)傳輸線沒幾個(gè)脈沖那就說明數(shù)據(jù)沒喂飽反過來搬運(yùn)一直堵計(jì)算一停一停的就說明調(diào)度沒鋪開或者切塊切小了。5.2 一個(gè)真實(shí)的調(diào)優(yōu)實(shí)例我挑一個(gè)自己印象最深刻的小案例講吧。某圖像處理Demo輸入是一張1080p圖片跑一個(gè)簡(jiǎn)單的超分模型總共就二十來個(gè)算子。上線后延遲慘不忍睹預(yù)估要50毫秒實(shí)際跑了200毫秒。最開始我們懷疑是卷積陣列太弱于是翻性能計(jì)數(shù)器結(jié)果發(fā)現(xiàn)卷積陣列占用率不到30%說明問題根本不在計(jì)算本身。進(jìn)一步看內(nèi)存事務(wù)的時(shí)間戳發(fā)現(xiàn)有很多頻繁的“小搬”操作每個(gè)算子都要讀一遍完整特征圖片內(nèi)復(fù)用率只有2。說白了數(shù)據(jù)根本沒有在片上停留下來每次計(jì)算都要從DDR把整個(gè)圖重新抬一遍。當(dāng)時(shí)我們的操作很簡(jiǎn)單先把所有算子的數(shù)據(jù)布局統(tǒng)一成硬件友好的格式避免layout轉(zhuǎn)換產(chǎn)生的零散搬運(yùn)再把相鄰的卷積與加融合成一個(gè)算子讓中間特征圖停留在SRAM而不是一算完就落回DDR。幾天改下來延遲降到70毫秒后來又做了一次循環(huán)分塊細(xì)分把部分重復(fù)讀取進(jìn)一步削掉干到了45毫秒。整個(gè)過程中芯片的算力一點(diǎn)沒變變的全是軟硬件怎么協(xié)作、數(shù)據(jù)怎么流動(dòng)。從那次之后我就很篤定一件事大多數(shù)AI芯片的性能事故不是算力不夠而是軟件沒有把數(shù)據(jù)喂好。硬件設(shè)計(jì)得再好數(shù)據(jù)流不轉(zhuǎn)就是空轉(zhuǎn)。6. 常見問題與排查技巧實(shí)錄6.1 排查思路先定位瓶頸在哪一級(jí)做軟硬件協(xié)同最怕的是拿到性能問題就到處懷疑。我習(xí)慣按一套固定排查流程走能省很多精神內(nèi)耗。先看計(jì)算單元占用率。如果占用率中等或偏上說明計(jì)算不是瓶頸趕緊去看存儲(chǔ)搬移和等待時(shí)間。如果占用率特別低先懷疑算子切塊是不是切得太大導(dǎo)致數(shù)據(jù)排不上再懷疑指令調(diào)度是不是串行依賴沒被打斷然后再懷疑數(shù)據(jù)布局是不是格式轉(zhuǎn)換把時(shí)間都燒走了。這套流程不算高深但真能攔住90%的初調(diào)問題。還有兩類坑很隱蔽。一類是同步陷阱多核芯片上如果各核心之間要頻繁同步任務(wù)等待時(shí)間會(huì)急劇膨脹。我見過一個(gè)模型算子都很輕但同步點(diǎn)特別密集導(dǎo)致多核利用率只有40%。后來把多個(gè)同步等待合并成一次握手一下子就提上來了。另一類是緩沖區(qū)分配錯(cuò)誤有的編譯器會(huì)給每個(gè)算子開一塊固定大小的SRAM結(jié)果明明很多算子的生命周期沒重疊資源也沒共享白白浪費(fèi)空間間接逼迫數(shù)據(jù)外溢到DDR。6.2 常見問題速查現(xiàn)象常見原因處理套路計(jì)算單元空閑內(nèi)存正常切塊尺寸不匹配片上數(shù)據(jù)復(fù)用低調(diào)整tile尺寸增大片內(nèi)駐留時(shí)間內(nèi)存帶寬打滿性能仍差數(shù)據(jù)被反復(fù)搬運(yùn)多次優(yōu)先做算子融合再統(tǒng)一layout單核快多核不提升同步點(diǎn)過密或任務(wù)分配不均合并同步、按數(shù)據(jù)并行重排任務(wù)小算子延遲極高驅(qū)動(dòng)任務(wù)啟動(dòng)開銷占比高算子融合或批量下發(fā)編譯器生成了冗余指令后端的模式匹配沒覆蓋硬件特性補(bǔ)上針對(duì)特定張量指令的匹配規(guī)則性能模型和實(shí)測(cè)偏離大模型里面存儲(chǔ)延遲估算不準(zhǔn)校準(zhǔn)各級(jí)存儲(chǔ)的實(shí)際cycle數(shù)6.3 兩個(gè)容易被忽略的細(xì)節(jié)最后說兩個(gè)我踩過坑的細(xì)節(jié)。第一個(gè)是“仿真器太快了”。我在早期調(diào)試時(shí)總覺得指令集模擬器跑得飛快程序一下子就出結(jié)果結(jié)果到了虛擬原型上一跑性能完全兩樣。原因是模擬器默認(rèn)所有訪存都命中而真實(shí)系統(tǒng)里緩存miss、SRAM bank沖突到處都是。所以建模擬器的時(shí)候一定要把存儲(chǔ)的bank沖突模擬進(jìn)來否則你辛辛苦苦調(diào)的指令序一到真硬件就垮。第二個(gè)細(xì)節(jié)是“性能數(shù)據(jù)要留到能溯源的程度”。很多芯片調(diào)試時(shí)計(jì)數(shù)器能告訴你總周期數(shù)但你看不出到底耗在哪個(gè)算子、哪條內(nèi)存邊上。所以我后來推行了一套規(guī)范每個(gè)算子執(zhí)行前記錄起始的流水線階段值執(zhí)行后讀一次算差值寫進(jìn)運(yùn)行日志。這樣做看似多余但真正排查問題時(shí)你才能在幾萬行日志里迅速定位到那一個(gè)操作出了毛病而不是拿著一個(gè)總時(shí)間反復(fù)猜。按照我個(gè)人的實(shí)踐體會(huì)AI芯片的軟硬件設(shè)計(jì)從來不是兩個(gè)聰明團(tuán)隊(duì)各寫各的再拼起來它是一場(chǎng)持續(xù)性的接口博弈。硬件留下多少余地軟件就能做出多少手腳軟件理解多少硬件硬件就能跑出多少性能。如果你正在做這顆芯片的工具鏈我建議從今天開始把每一個(gè)算子的性能計(jì)數(shù)器都打開把每一次數(shù)據(jù)搬移都畫出來。你很快會(huì)發(fā)現(xiàn)瓶頸永遠(yuǎn)比你想象得更靠前也永遠(yuǎn)更容易被一套嚴(yán)謹(jǐn)?shù)膮f(xié)同方法吃干榨凈。