簡介《基于存算一體集成芯片的大模型專用硬件架構》是一份面向大模型硬件架構研究者、芯片設計工程師與高校相關專業(yè)師生的學術論文PDF聚焦大模型部署中的數據傳輸帶寬瓶頸與數據中心能耗壓力。文件共1個PDF約3.49MB完整收錄何斯琪、穆琛、陳遲曉發(fā)表于《中興通訊技術》2024年第30卷第2期的文章便于檢索、引用與精讀。內容圍繞存算一體集成芯片與集成芯粒方案展開分析傳統計算與存儲分離架構的局限并討論輕量化—存內壓縮協同設計、稀疏網絡在存算一體硬件上的稠密映射等實現思路對理解大模型推理能效優(yōu)化和專用硬件設計具有參考價值。已有140人學習適合作為架構調研、論文寫作或技術方案論證的參考資料。1. 為什么大模型推理通常會卡在“搬數據”上一筆帶寬賬決定的架構選型給一個 70 億參數的大模型做推理硬件方案最先被推翻的往往不是算力預算而是帶寬預算。按每秒一萬個令牌的實時速率計算僅僅把權重從存儲搬到計算單元就需要每秒幾十太字節(jié)的搬運能力而當前主流的高帶寬存儲封裝單棧只有每秒零點幾太字節(jié)的量級多棧堆疊也補不上這個缺口。這個缺口不是靠堆容量能抹平的它直接決定方案走向計算和存儲到底要不要貼在一起?；诖嫠阋惑w集成芯片的大模型專用硬件架構解決的就是這筆搬運賬把權重固定在存儲陣列里讓乘加在數據所在的位置發(fā)生再用芯粒集成繞開單芯片的面積與良率天花板。這套思路適合兩類人要做一份完整硬件架構畢設或課設的學生以及要給推理加速卡做選型論證的工程師。2. 帶寬瓶頸如何計算從參數規(guī)模到芯粒接口速率架構方案里最容易空泛、也最容易被導師或評審追問的地方就是“帶寬不夠”這四個字。不夠多少、缺在哪個環(huán)節(jié)、換成什么結構能補上多少必須能算。這一章把這筆賬拆成三層模型側的增長曲線、系統側的搬運量、器件側的算力存儲比。三層算完架構選型就不是拍腦袋而是被數字推出來的。2.1 參數規(guī)模、算力需求與單芯片面積的三條天花板先看模型側。以注意力機制為基礎的大模型在近幾年呈現出一種近乎失控的增長參數規(guī)模大約每兩年增長 240 倍對應的算力需求增長接近 750 倍。而通用硬件每兩年大約只有 3.1 倍的提升并且已經逼近物理極限。三條曲線放在一張圖上缺口就是逐年拉大的剪刀差這個剪刀差最終會以“推理成本”的形式落到數據中心賬單上。再看制造側。傳統超大規(guī)模、超大面積的單芯片 SoC 方案在面積繼續(xù)放大時會同時遇到四個問題晶圓利用率下降、良率隨面積指數衰減、驗證復雜度失控、設計成本激增。更硬的一條約束是光刻12 英寸晶圓在光刻機的要求下單顆芯片的最大設計面積被限制在 858 mm2 左右掩膜版尺寸本身就是一堵墻。也就是說即使不計成本和良率單芯片路線在面積上也無法再大幅擴展。第三條天花板來自封裝與接口。大模型推理的瓶頸并不在乘加單元本身而在于權重需要從片外存儲反復搬到計算單元。這條通路的帶寬由封裝、接口速率和引腳數共同決定屬于典型的“物理上無法在短期內倍增”的環(huán)節(jié)。三條天花板疊加結論就比較清楚了繼續(xù)沿著單芯片 SoC 增加算力很難可以轉向“把大芯片拆成小芯片再集成”的路線。集成芯粒的思路是先把多個小顆粒芯片獨立設計、獨立實現再通過先進封裝重新組裝成系統。這樣做的好處很直接單顆芯粒面積小、良率高、可復用設計周期短壞處是片間互聯和封裝成為新的約束項必須在架構階段就一并設計不能等到后端再補。2.2 用令牌速率反推帶寬需求一份可以自行復算的推導模型側的賬用一份可執(zhí)行腳本算最清楚。下面這段腳本把“參數量 → 每令牌搬運字節(jié)數 → 帶寬需求”串起來并且把幾種典型架構的接口速率放在一起對比。# 大模型推理帶寬/算力/存儲預算復算腳本 # 所有參數均可替換用于方案階段快速做架構對比 def inference_budget(params_billion, token_rate, weight_bits8, hidden4096, ffn11008, layers32, target_topsNone): params_billion: 模型參數量十億 token_rate: 目標令牌速率令牌/秒 weight_bits: 權重位寬INT8 取 8 hidden/ffn/layers: 全連接層維度用于核算力與存儲 # 1) 每個令牌需要搬運的權重字節(jié)數解碼階段每令牌過一遍全部權重 bytes_per_token params_billion * 1e9 * weight_bits / 8 # 2) 帶寬需求 單令牌搬運量 × 令牌速率 bw_Bps bytes_per_token * token_rate bw_TBps bw_Bps / 1e12 # 3) 三層連續(xù)全連接層FC0/FC1/FC2的算力與存儲 macs_per_layer (hidden * ffn ffn * hidden hidden * hidden) total_macs macs_per_layer * layers tops total_macs * token_rate * 2 / 1e12 # 1 MAC 2 ops capacity_GB total_macs * weight_bits / 8 / 1e9 # 4) 算力存儲比單位 ops/byte數值上等于令牌速率 ratio tops * 1e12 / (capacity_GB * 1e9) return { 帶寬需求(TB/s): round(bw_TBps, 3), 算力需求(TOPS): round(tops, 2), 容量需求(GB): round(capacity_GB, 3), 算力存儲比(ops/byte): round(ratio, 1), } # 70 億參數模型1 萬令牌/秒的實時推理目標 print(inference_budget(7, 10_000)) # 輸出約帶寬 64 TB/s 量級算力 68 TOPS容量 3.4 GB腳本里最關鍵的一行是bytes_per_token。解碼階段每個令牌都要把全部權重過一遍所以帶寬需求等于“參數量 × 位寬 ÷ 8 × 令牌速率”與批大小、序列長度都無關只和模型尺寸與目標速率掛鉤。這解釋了一個常被誤判的現象把令牌速率從每秒 1 個提到每秒 1 萬個算力需求只漲到 68 TOPS對一顆芯片來說并不夸張但帶寬需求漲到了 64 TB/s對任何現有封裝來說都不現實。參數說明與調參建議weight_bits從 8 降到 4帶寬直接減半這也是權重量化在推理側收益立竿見影的原因token_rate是業(yè)務指標做方案論證時應先固定它再倒推硬件而不是先有硬件再編速率。算力存儲比那一項的輸出值在數值上恰好等于令牌速率這個巧合背后是“每字節(jié)權重只參與一次乘加”的解碼特性后面第 3 章會用它來反推存邊架構的并行度設計。對比之下采用分離式計算架構時GPU 與高帶寬存儲之間的數據搬運量就是上面算出來的量級而在存算一體架構里權重常駐陣列接口上只需要搬運輸入激活和輸出結果同樣令牌速率下帶寬需求能壓到每秒幾十吉比特的量級差距超過三個數量級。這不是靠“帶寬優(yōu)化技巧”省出來的而是數據通路結構變了。2.3 算力存儲比大模型和卷積網絡比較數值時需要注意第二個容易被誤用的指標是算力存儲比。拿前面算出的 68 TOPS 與 3.4 GB 相除得到約 20 ops/byte。而經典卷積網絡在圖像任務上的算力存儲比要高出一到兩個數量級通常在每千字節(jié)上百 GOPS 的量級。兩者不是一個量級的負載卷積網絡是計算密集大模型解碼是訪存密集。這個差別直接決定了存儲介質和陣列結構的選法。經典交叉陣列做存內計算時算力存儲比約等于“時鐘頻率 × 2”因為一次陣列級乘加在一個時鐘周期內完成而陣列深度決定了它能裝多少權重。當負載的算力存儲比遠低于這個值時交叉陣列會長時間處于“等數據”的狀態(tài)并行度上不去。針對這一點存邊計算的做法是把乘加邏輯分布在片上權重緩沖 SRAM 的邊緣讓算力存儲比變成“時鐘頻率 × 2 ÷ 存儲深度”。存儲深度可以按宏單元的容量來配等于把算力存儲比做成了一個可調參數而不是被陣列結構鎖死。這個調整聽起來只是公式變化落到實現上意味著權重可以按輸入通道方向切塊、展平后存進不同列輸出通道方向的并行度靠增加宏單元數量來堆近存計算里成熟的數據流映射方法可以直接搬過來用。提示做方案對比時務必把“算力存儲比”和“峰值算力”分開列。只報峰值算力的方案在解碼類負載上通常兌現不了。3. 總體架構設計CPU 與存算一體芯粒的分工與數據流算完賬架構的骨架其實已經被約束住了主機側負責調度、采樣、非矩陣類算子加速側負責全連接層和注意力的矩陣運算兩者之間只走輸入輸出不走權重。這一章把這個骨架展開成可實現的模塊劃分、數據流映射和多芯粒擴展方案。3.1 存算分離與存算一體的數據通路對比分離式架構的數據通路是主機 CPU 通過高速串行總線把請求發(fā)給加速卡加速卡上的計算芯片從外部高帶寬存儲里反復讀取權重算完把結果寫回再經總線返回。這條通路上真正昂貴的不是計算而是“權重讀一遍、用一次、丟掉、下個令牌再讀一遍”。存算一體架構把這條通路改成主機 CPU 通過同一套總線把輸入激活送到存算加速卡權重常駐在加速卡的存算陣列里不動乘加在陣列內部完成只把輸出激活送回主機。外部存儲的角色從“權重的家”降級為“激活的暫存”容量需求和帶寬需求同時下降一個數量級。這里有一個容易在設計文檔里寫漏的點主機側的矢量計算單元和小算力 NPU 并不是冗余的。注意力模塊里的 softmax、層歸一化、掩碼、采樣這些操作計算量不大但訪存模式零碎放在存算陣列里做反而低效。合理的分工是主機側處理這些“非規(guī)則但輕量”的算子存算側只處理“規(guī)則且重”的矩陣乘。方案里如果只畫一顆存算芯片評閱時基本會被問“softmax 在哪算”。從帶寬對比看同為每秒一萬令牌的目標速率分離式架構需要幾十太字節(jié)每秒的片外帶寬存算一體架構只需要每芯粒每秒幾十吉比特量級的接口速率節(jié)省幅度超過三個數量級。這個數字也解釋了為什么單芯粒接口速度可以做得比較保守從而繞開一部分高速接口的工藝與管制約束。3.2 存邊計算架構把乘加邏輯挪到 SRAM 的邊緣存邊計算的物理形態(tài)是一片 SRAM 陣列邊緣掛一排乘加單元和歸約樹權重按行或按列靜態(tài)存放輸入激活從一側流入部分和從另一側匯出。它的好處是既能用上 SRAM 的高能效又不像交叉陣列那樣被陣列深度綁死并行度。數據流映射的具體做法是權重在計算開始前預先加載進宏單元沿輸入通道方向切塊后展平存入宏單元的不同列輸出通道方向的并行度靠堆多個宏單元實現形成空間并行。下面這段配置腳本描述了一次映射的參數組織方式實際綜合時可以把它轉成宏單元的配置寄存器表。# 存邊宏單元的權重組裝與映射配置 # 目標把一層全連接權重切成列塊鋪到 N 個 COMB 宏上 def build_mapping(in_ch, out_ch, macro_cols64, macro_rows256, macros4): in_ch / out_ch: 該層輸入、輸出通道數 macro_cols: 單個宏單元一行能放多少個權重列方向 macro_rows: 單個宏單元能放多少行深度 macros: 并行使用的宏單元顆數 # 每個輸出通道的權重沿輸入通道切塊每塊長度 macro_cols blocks_per_out (in_ch macro_cols - 1) // macro_cols # 輸出通道按宏數量均分實現輸出方向的空間并行 outs_per_macro (out_ch macros - 1) // macros mapping [] for m in range(macros): for b in range(blocks_per_out): mapping.append({ macro: m, block: b, in_start: b * macro_cols, in_end: min((b 1) * macro_cols, in_ch), out_start: m * outs_per_macro, out_end: min((m 1) * outs_per_macro, out_ch), depth_needed: outs_per_macro, # 占用宏單元行數 }) # 校驗占用行數不能超過宏深度否則需要增加宏或二次切分 assert all(x[depth_needed] macro_rows for x in mapping), 宏深度不足 return mapping for item in build_mapping(4096, 11008)[:3]: print(item)macro_cols決定了單次陣列操作的向量寬度macro_rows決定了能同時駐留多少個輸出通道的權重macros決定了輸出方向的空間并行度。三者共同決定算力存儲比。實踐中的調參順序是先按片上 SRAM 總面積和工藝節(jié)點定macro_rows再按目標算力定macros最后用macro_cols對齊位寬和累加器位寬。斷言那一行不是裝飾depth_needed超過宏深度時如果只增加宏數量而不調整切分策略會得到一堆溢出越界的地址仿真階段表現為隨機錯值非常難查。3.3 多芯粒集成的劃分與擴展性單顆芯粒的容量是有上限的。以 12/14 nm 工藝估算一顆 10 TOPS、200 MB 存儲的芯粒計算電路面積約 8 mm2存儲面積約 300 mm2折算下來算力密度只有 0.0325 TOPS/mm2。這個數字說明兩件事一是存儲面積占絕對主導想提高容量只能堆芯粒二是算力密度低不是設計失誤而是這類架構的固有特征方案文檔里必須主動解釋否則會被當成缺陷。四顆 65 nm 的 SRAM 存邊計算芯粒通過扇出型 2.5D 封裝集成在一起是這套方案里比較典型的一個規(guī)模點算力和容量都能獲得接近線性的提升封裝工藝也相對成熟。超過四顆之后映射方法需要重新設計否則算力不會隨芯粒數量線性增長原因在于芯粒間的激活廣播和部分和歸約開始成為瓶頸互聯拓撲和切分粒度都要跟著改。芯粒劃分的一般原則可以歸納成三條把同一層的權重盡量聚在同一顆芯粒上減少跨芯粒的權重訪問把需要頻繁交換部分和的通道切在同一封裝內避免走封裝外總線給每顆芯粒留出獨立的激活緩沖避免共享緩沖成為串行點。3.4 單芯粒預算表方案文檔里必須有的那張表評審看方案第一眼找的就是這張表。缺了它后面的模塊設計再細也會被質疑“沒有量化依據”。項目取值說明工藝節(jié)點12/14 nm 估算決定面積與能效基線單芯粒算力10 TOPSINT8 等效單芯粒容量200 MB片上 SRAM 權重區(qū)計算電路面積約 8 mm2乘加陣列與歸約樹存儲面積約 300 mm2占主導決定了芯粒尺寸算力密度0.0325 TOPS/mm2該類架構的常態(tài)值集成方式扇出型 2.5D 封裝四芯粒為一個規(guī)模點片間接口每芯粒 3264 Gbit/s遠低于分離式架構要求表格里最后一行是這套方案最容易被忽略的價值點因為權重不出片片間接口只需要承載激活和部分和速率要求被壓到很低封裝難度和功耗隨之下降。做方案論證時應該把這一行單獨強調它比“峰值算力多少 TOPS”更能說明架構的合理性。4. 輕量化與存內壓縮的協同設計稀疏網絡在存算陣列上如何稠密映射前面三章解決的是“權重怎么不搬家”這一章解決“權重怎么少占地方”。稀疏化本身并不新鮮難點在于把非結構化剪枝后的稀疏矩陣直接塞進規(guī)則陣列零值仍然要占存儲單元壓縮等于白做。這一章給出的是軟硬件協同的一條路徑剪枝策略、位掩碼編碼、路由網絡三件事必須一起設計。4.1 剪枝子組大小與稀疏率的確定方法稀疏化的兩個關鍵參數是子組大小和稀疏率。子組太大壓縮粒度粗精度掉得快子組太小解碼邏輯復雜位掩碼本身的開銷就吃掉收益。取值不能靠猜要在目標任務上做一輪掃描。掃描的做法是固定子組大小逐步提高稀疏率觀察驗證集指標找到指標開始下降的拐點再把拐點往回退一檔作為工作點。在一組字符級語言建模任務的實驗中子組大小取 32、修剪掉四分之三的權重時網絡性能基本保持不變于是工作點被定為“子組 32、稀疏率 75%”。這個結果不是普適常數換模型、換任務都要重掃但它給出了一個合理的出發(fā)區(qū)間。注意精度拐點必須用最終任務的指標來判定不能用訓練損失代替。訓練損失平穩(wěn)而下游指標下降的情況在這類壓縮里非常常見。4.2 位掩碼編碼與稠密權重的存內組織確定了工作點編碼方式就固定下來了權重向量按子組劃分每組按預定義稀疏度修剪剪枝后的非零權重壓成一個稠密向量同時生成一個等長的比特掩碼用來指示稠密權重在原始向量里的位置。陣列里只存稠密向量掩碼存在旁邊的掩碼存儲里兩者一一對應。下面這段腳本實現了完整的編碼與解碼校驗可以直接拿來驗證編碼邏輯有沒有寫錯。import random def prune_group(weights, sparsity0.75): 按絕對值保留最大的 (1-sparsity) 比例權重返回稠密向量與位掩碼 n len(weights) keep max(1, int(round(n * (1 - sparsity)))) idx sorted(range(n), keylambda i: -abs(weights[i]))[:keep] keep_set set(idx) mask [1 if i in keep_set else 0 for i in range(n)] # 1 表示保留 dense [weights[i] for i in range(n) if mask[i] 1] return dense, mask def prefix_popcount(mask): 前綴 popcount輸出每個位置之前含自身位置前1 的個數 用于把掩碼位置翻譯成稠密向量的下標 out, cnt [], 0 for b in mask: out.append(cnt) cnt b return out # 校驗稠密向量第 k 個元素應該落在掩碼第 prefix_popcount[mask[i]] 位 weights [round(random.uniform(-1, 1), 3) for _ in range(32)] dense, mask prune_group(weights, 0.75) pp prefix_popcount(mask) for i, b in enumerate(mask): if b 1: assert dense[pp[i]] weights[i], 編碼/解碼不一致 print(保留權重數:, len(dense), 掩碼長度:, len(mask))這段代碼的核心是prefix_popcount。它把“原向量第 i 位”翻譯成“稠密向量的第幾個元素”硬件里的實現就是一條掃描鏈加一個計數器。校驗斷言那一行是必須的編碼端和解碼端只要對“前綴是否含自身”的理解差一位整個陣列的輸出就會整體偏移一個位置現象是結果“看起來差不多但精度掉一截”屬于最費時間的 bug 之一。4.3 蝶形路由網絡前綴 popcount 與左旋轉補碼稠密權重準備好了輸入激活還得跟著一起“擠”。原始輸入特征里被剪掉權重對應的那些輸入不需要參與計算必須從輸入向量里挑出來、按順序排好送進陣列。這個重排用蝶形網絡實現多級 2 選 1 的數據分發(fā)單元控制信號由解碼器實時產生。解碼器接收位掩碼生成每一級蝶形的控制比特涉及兩個操作。第一個是前綴 popcount掃描掩碼序列輸出當前位置之前 1 的總數用來確定某個數據該被送到第幾個輸出口。第二個是左旋轉補碼LRCW本質是一次循環(huán)左移唯一區(qū)別是移位量在運算過程中以補碼形式表示用來在每一級修正路由偏移。def lrcw_shift(src_bits, shift, width): 左旋轉補碼循環(huán)左移移位量按補碼解釋負值等價于反向旋轉 shift % width # 補碼語義下先歸一化到位寬范圍 return ((src_bits shift) | (src_bits (width - shift))) ((1 width) - 1) def butterfly_route(inputs, mask, stages): 按位掩碼把輸入特征路由到稠密位置stages 為蝶形級數 width len(inputs) assert width (1 stages), 輸入長度需為 2 的整數次冪 idx [i for i, b in enumerate(mask) if b 1] routed [inputs[i] for i in idx] # 硬件中每級只做一次局部交換這里用軟件等價描述便于驗證 ctrl lrcw_shift(0b0011, 1, 4) assert ctrl in range(1 4) return routed print(butterfly_route(list(range(8)), [0,1,1,0,1,0,0,1], 3)) # 期望輸出[1, 2, 4, 7]軟件描述里看不出并行性硬件上則是每一級只做一次相鄰或跨組的 2 選 1 交換級數等于輸入長度的以 2 為底對數延遲對輸入長度是對數關系。設計時的關鍵約束是路由網絡的控制信號必須在同一拍內產生不能跨拍否則數據流水的節(jié)拍會被解碼器拖住。這也是為什么解碼器要用純組合邏輯加前綴樹而不是塞進一條通用流水線。4.4 28 nm 驗證芯片的指標拆解這套協同設計在一顆 28 nm 工藝的驗證芯片上做過實現指標可以按維度拆開看。指標數值讀法工藝 / 精度28 nm / INT8定制 SRAM 位單元陣列規(guī)模96 kB宏單元 80 kB 量級、系統緩沖 64 kB 量級工作頻率320 MHz電壓 0.641.03 V總功耗250.65 mW含控制器與全局聚合峰值性能3.3 TOPS已計入 75% 稀疏率芯片面積3.93 mm2含 8 個功能單元與特征存儲面積效率0.85 TOPS/mm2峰值性能 ÷ 面積系統能效11.83 / 25.22 TOPS/W生成 QKV / 整體注意力能效拆成兩個值來報是有意為之。生成查詢、鍵、值矩陣這一步是全連接層的稠密計算能效體現的是陣列本身的水平整體注意力包含了路由與聚合的開銷能效體現的是協同設計的水平。兩個數一起看才能判斷存內壓縮到底有沒有帶來凈收益。如果只報前一個數評審很容易問“壓縮開銷算了嗎”答不上來就會顯得方案不完整。5. 常見問題與排查從建模到流片最容易出問題的五個點方案寫到這一章之前都是“應該怎樣”這一章說“實際會怎樣”。下面五條都是在同類項目里反復出現的問題按“現象 → 原因 → 解決”組織做成檢查清單比任何設計原則都省時間。5.1 稀疏率按經驗設定精度下降后才發(fā)現子組大小取錯現象編碼和陣列仿真都通過功能正確但任務指標比基線低了兩三個點重訓也拉不回來。原因子組大小是按“常見值”設定的沒有在目標任務上掃過拐點。子組過大時一個子組里被剪掉的權重分布與權重的重要性分布不匹配等價于做了一次粗粒度的結構破壞子組過小時位掩碼的相對開銷變高壓縮收益被吃掉而精度又沒變好。解決把子組大小和稀疏率做成二維掃描表每一格記錄指標取“指標不下降前提下壓縮比最高”的那一格。掃描成本遠低于后期返工。經驗上字符級建模任務在子組 32、稀疏率 75% 附近比較穩(wěn)但換任務必須重掃。5.2 交叉陣列里零權重未清干凈稠密映射實際未生效現象陣列規(guī)?？雌饋頉]變功耗反而略微上升性能提升遠小于預期。原因非結構化剪枝后的矩陣在映射到規(guī)則陣列時被剪掉的位置如果沒有做顯式清零或旁路存儲單元里殘留的是舊值或隨機初值。計算仍然執(zhí)行但貢獻了錯誤的項為了修正它又加了額外的門控邏輯功耗就上去了。解決在映射流程里加一道強制檢查遍歷所有被剪枝的位置確認寫入的是零或已被旁路使能覆蓋。上面 4.2 節(jié)的編碼校驗腳本可以直接擴展成這一檢查把斷言從“保留位一致”擴到“裁剪位為零”。5.3 芯粒數量一增加算力不線性增長現象從四顆芯粒擴到八顆仿真出來的算力只有預期的六成左右增加芯粒帶來的收益遞減明顯。原因跨芯粒的部分和歸約和激活廣播開始成為瓶頸原來的切分策略是按四顆設計的切分粒度太粗導致每一層都要跨封裝交換中間結果?；ヂ撏負錄]有跟著調串行點就出現了。解決先做一次互聯流量統計找出跨芯粒流量最大的那幾層把切分粒度沿輸出通道方向細化同時給每顆芯粒配獨立激活緩沖把共享緩沖改成點對點。芯粒規(guī)模繼續(xù)往上時映射方法本身要重做不能沿用四芯粒的配置。5.4 只按峰值算力做功耗預算忽略封裝與散熱現象架構仿真完美熱仿真一跑結溫超標標稱頻率降不下來實測性能只有設計值的七成。原因存算一體架構的算力密度低但存儲面積大熱量分布很不均勻乘加陣列集中在邊緣SRAM 陣列鋪滿大部分面積峰值算力對應的功耗峰值集中在少數熱點上。按平均功耗做散熱設計熱點必然超標。解決把功耗預算按區(qū)域拆分別給計算邊緣區(qū)和存儲區(qū)設定功耗密度上限熱仿真按區(qū)域熱點而不是平均功耗跑。封裝選型時把熱阻作為與帶寬同級的指標來評估。5.5 仿真用理想 SRAM 模型流片后時序不達標現象RTL 仿真和門級仿真都過流片回來頻率上不到目標值或者良率異常低。原因存內計算對 SRAM 位單元的讀寫裕度極其敏感行為級模型里讀操作是零延遲、無窮驅動實際位單元在低壓下讀出擺幅很小加上陣列規(guī)模大、走線長時序和噪聲裕度都不夠。定制位單元的晶體管數量、驅動能力、讀出放大器閾值這些參數在前期模型里常被簡化。解決從設計第一天起就用帶時序與噪聲的存儲器模型關鍵路徑上跑蒙特卡洛對低壓工作點單獨做讀寫裕度分析把最低工作電壓留出足夠余量。這條問題的成本很高屬于前期少做一步、后期多花幾個月的那類問題。6. 驗收與答辯用一組可復算的指標證明架構成立方案交上去評審通常只做三件事看你的賬算不算得清、看你的結構能不能對得上賬、看你有沒有驗證過。所以答辯材料不要從“技術趨勢”講起從一張指標表講起讓每一個數字都能被現場的追問追到底。第一層是帶寬賬。開口就給出目標令牌速率下的帶寬需求以及存算一體架構下的接口速率兩者放在同一張表里標注清楚算法和公式。這一層的作用是確立問題真實存在并且你的架構確實把它解決了。評審如果追問“為什么是這個速率”現場用 2.2 節(jié)的腳本心算一遍比任何解釋都有說服力。第二層是容量與并行度。給出單芯粒容量、宏單元深度、輸出通道并行度三者的關系式說明在給定面積下為什么選這個組合。這一層最容易被問的是“為什么不多堆幾顆芯?！贝鸢敢?5.3 節(jié)的擴展性分析來接承認非線性并給出拐點位置比硬說線性更可信。第三層是稀疏協同的凈收益。把壓縮前后的存儲占用、能效、精度三項并列明確說明壓縮開銷已經計入。用 4.4 節(jié)那張表的形式把生成 QKV 的能效和整體注意力的能效分開報。第四層是覆蓋面。至少在三個維度上有驗證數據功能層編碼解碼一致性、架構層映射后的算力與容量、實現層時序、面積、功耗。只有功能仿真而沒有實現層數據是這類方案最常見的失分點。驗收維度交付物通過判據帶寬論證公式 復算腳本 對比表目標速率下接口需求低于封裝能力容量規(guī)劃芯粒預算表 映射配置權重全部駐留無跨芯粒權重訪問稀疏協同編碼校驗輸出 精度對照指標不降壓縮比達標擴展性四芯粒與八芯粒對照明確拐點與瓶頸位置實現層時序、面積、功耗匯總低壓工作點有裕度余量答辯現場還有一個很實際的小技巧把最容易出錯的兩條5.2 的零權重未清、5.5 的存儲器模型過理想主動寫進“已識別風險”那一頁附上你的應對措施。評審看到你自己先把問題擺出來追問的火力會明顯下降剩下的時間就能用來講你的架構亮點。反過來被現場問出一個你完全沒想過的坑前面所有數字的可信度都會打折。從那以后我每次帶這類硬件架構方案都強制走一遍“算賬 → 畫表 → 復算腳本 → 風險頁”這四步哪怕時間再緊也不跳。翻車的方案幾乎都不是因為想法不對而是因為某筆賬只在腦子里算過、沒落到紙上、也沒被第二個人復算過。希望這套結構能幫到你把手上那份方案從“看起來有道理”變成“經得起追問”。本文還有配套的精品資源點擊獲取 大模型推理帶寬瓶頸下存算一體芯粒架構設計與驗收
簡介《基于存算一體集成芯片的大模型專用硬件架構》是一份面向大模型硬件架構研究者、芯片設計工程師與高校相關專業(yè)師生的學術論文PDF聚焦大模型部署中的數據傳輸帶寬瓶頸與數據中心能耗壓力。文件共1個PDF約3.49MB完整收錄何斯琪、穆琛、陳遲曉發(fā)表于《中興通訊技術》2024年第30卷第2期的文章便于檢索、引用與精讀。內容圍繞存算一體集成芯片與集成芯粒方案展開分析傳統計算與存儲分離架構的局限并討論輕量化—存內壓縮協同設計、稀疏網絡在存算一體硬件上的稠密映射等實現思路對理解大模型推理能效優(yōu)化和專用硬件設計具有參考價值。已有140人學習適合作為架構調研、論文寫作或技術方案論證的參考資料。1. 為什么大模型推理通常會卡在“搬數據”上一筆帶寬賬決定的架構選型給一個 70 億參數的大模型做推理硬件方案最先被推翻的往往不是算力預算而是帶寬預算。按每秒一萬個令牌的實時速率計算僅僅把權重從存儲搬到計算單元就需要每秒幾十太字節(jié)的搬運能力而當前主流的高帶寬存儲封裝單棧只有每秒零點幾太字節(jié)的量級多棧堆疊也補不上這個缺口。這個缺口不是靠堆容量能抹平的它直接決定方案走向計算和存儲到底要不要貼在一起?；诖嫠阋惑w集成芯片的大模型專用硬件架構解決的就是這筆搬運賬把權重固定在存儲陣列里讓乘加在數據所在的位置發(fā)生再用芯粒集成繞開單芯片的面積與良率天花板。這套思路適合兩類人要做一份完整硬件架構畢設或課設的學生以及要給推理加速卡做選型論證的工程師。2. 帶寬瓶頸如何計算從參數規(guī)模到芯粒接口速率架構方案里最容易空泛、也最容易被導師或評審追問的地方就是“帶寬不夠”這四個字。不夠多少、缺在哪個環(huán)節(jié)、換成什么結構能補上多少必須能算。這一章把這筆賬拆成三層模型側的增長曲線、系統側的搬運量、器件側的算力存儲比。三層算完架構選型就不是拍腦袋而是被數字推出來的。2.1 參數規(guī)模、算力需求與單芯片面積的三條天花板先看模型側。以注意力機制為基礎的大模型在近幾年呈現出一種近乎失控的增長參數規(guī)模大約每兩年增長 240 倍對應的算力需求增長接近 750 倍。而通用硬件每兩年大約只有 3.1 倍的提升并且已經逼近物理極限。三條曲線放在一張圖上缺口就是逐年拉大的剪刀差這個剪刀差最終會以“推理成本”的形式落到數據中心賬單上。再看制造側。傳統超大規(guī)模、超大面積的單芯片 SoC 方案在面積繼續(xù)放大時會同時遇到四個問題晶圓利用率下降、良率隨面積指數衰減、驗證復雜度失控、設計成本激增。更硬的一條約束是光刻12 英寸晶圓在光刻機的要求下單顆芯片的最大設計面積被限制在 858 mm2 左右掩膜版尺寸本身就是一堵墻。也就是說即使不計成本和良率單芯片路線在面積上也無法再大幅擴展。第三條天花板來自封裝與接口。大模型推理的瓶頸并不在乘加單元本身而在于權重需要從片外存儲反復搬到計算單元。這條通路的帶寬由封裝、接口速率和引腳數共同決定屬于典型的“物理上無法在短期內倍增”的環(huán)節(jié)。三條天花板疊加結論就比較清楚了繼續(xù)沿著單芯片 SoC 增加算力很難可以轉向“把大芯片拆成小芯片再集成”的路線。集成芯粒的思路是先把多個小顆粒芯片獨立設計、獨立實現再通過先進封裝重新組裝成系統。這樣做的好處很直接單顆芯粒面積小、良率高、可復用設計周期短壞處是片間互聯和封裝成為新的約束項必須在架構階段就一并設計不能等到后端再補。2.2 用令牌速率反推帶寬需求一份可以自行復算的推導模型側的賬用一份可執(zhí)行腳本算最清楚。下面這段腳本把“參數量 → 每令牌搬運字節(jié)數 → 帶寬需求”串起來并且把幾種典型架構的接口速率放在一起對比。# 大模型推理帶寬/算力/存儲預算復算腳本 # 所有參數均可替換用于方案階段快速做架構對比 def inference_budget(params_billion, token_rate, weight_bits8, hidden4096, ffn11008, layers32, target_topsNone): params_billion: 模型參數量十億 token_rate: 目標令牌速率令牌/秒 weight_bits: 權重位寬INT8 取 8 hidden/ffn/layers: 全連接層維度用于核算力與存儲 # 1) 每個令牌需要搬運的權重字節(jié)數解碼階段每令牌過一遍全部權重 bytes_per_token params_billion * 1e9 * weight_bits / 8 # 2) 帶寬需求 單令牌搬運量 × 令牌速率 bw_Bps bytes_per_token * token_rate bw_TBps bw_Bps / 1e12 # 3) 三層連續(xù)全連接層FC0/FC1/FC2的算力與存儲 macs_per_layer (hidden * ffn ffn * hidden hidden * hidden) total_macs macs_per_layer * layers tops total_macs * token_rate * 2 / 1e12 # 1 MAC 2 ops capacity_GB total_macs * weight_bits / 8 / 1e9 # 4) 算力存儲比單位 ops/byte數值上等于令牌速率 ratio tops * 1e12 / (capacity_GB * 1e9) return { 帶寬需求(TB/s): round(bw_TBps, 3), 算力需求(TOPS): round(tops, 2), 容量需求(GB): round(capacity_GB, 3), 算力存儲比(ops/byte): round(ratio, 1), } # 70 億參數模型1 萬令牌/秒的實時推理目標 print(inference_budget(7, 10_000)) # 輸出約帶寬 64 TB/s 量級算力 68 TOPS容量 3.4 GB腳本里最關鍵的一行是bytes_per_token。解碼階段每個令牌都要把全部權重過一遍所以帶寬需求等于“參數量 × 位寬 ÷ 8 × 令牌速率”與批大小、序列長度都無關只和模型尺寸與目標速率掛鉤。這解釋了一個常被誤判的現象把令牌速率從每秒 1 個提到每秒 1 萬個算力需求只漲到 68 TOPS對一顆芯片來說并不夸張但帶寬需求漲到了 64 TB/s對任何現有封裝來說都不現實。參數說明與調參建議weight_bits從 8 降到 4帶寬直接減半這也是權重量化在推理側收益立竿見影的原因token_rate是業(yè)務指標做方案論證時應先固定它再倒推硬件而不是先有硬件再編速率。算力存儲比那一項的輸出值在數值上恰好等于令牌速率這個巧合背后是“每字節(jié)權重只參與一次乘加”的解碼特性后面第 3 章會用它來反推存邊架構的并行度設計。對比之下采用分離式計算架構時GPU 與高帶寬存儲之間的數據搬運量就是上面算出來的量級而在存算一體架構里權重常駐陣列接口上只需要搬運輸入激活和輸出結果同樣令牌速率下帶寬需求能壓到每秒幾十吉比特的量級差距超過三個數量級。這不是靠“帶寬優(yōu)化技巧”省出來的而是數據通路結構變了。2.3 算力存儲比大模型和卷積網絡比較數值時需要注意第二個容易被誤用的指標是算力存儲比。拿前面算出的 68 TOPS 與 3.4 GB 相除得到約 20 ops/byte。而經典卷積網絡在圖像任務上的算力存儲比要高出一到兩個數量級通常在每千字節(jié)上百 GOPS 的量級。兩者不是一個量級的負載卷積網絡是計算密集大模型解碼是訪存密集。這個差別直接決定了存儲介質和陣列結構的選法。經典交叉陣列做存內計算時算力存儲比約等于“時鐘頻率 × 2”因為一次陣列級乘加在一個時鐘周期內完成而陣列深度決定了它能裝多少權重。當負載的算力存儲比遠低于這個值時交叉陣列會長時間處于“等數據”的狀態(tài)并行度上不去。針對這一點存邊計算的做法是把乘加邏輯分布在片上權重緩沖 SRAM 的邊緣讓算力存儲比變成“時鐘頻率 × 2 ÷ 存儲深度”。存儲深度可以按宏單元的容量來配等于把算力存儲比做成了一個可調參數而不是被陣列結構鎖死。這個調整聽起來只是公式變化落到實現上意味著權重可以按輸入通道方向切塊、展平后存進不同列輸出通道方向的并行度靠增加宏單元數量來堆近存計算里成熟的數據流映射方法可以直接搬過來用。提示做方案對比時務必把“算力存儲比”和“峰值算力”分開列。只報峰值算力的方案在解碼類負載上通常兌現不了。3. 總體架構設計CPU 與存算一體芯粒的分工與數據流算完賬架構的骨架其實已經被約束住了主機側負責調度、采樣、非矩陣類算子加速側負責全連接層和注意力的矩陣運算兩者之間只走輸入輸出不走權重。這一章把這個骨架展開成可實現的模塊劃分、數據流映射和多芯粒擴展方案。3.1 存算分離與存算一體的數據通路對比分離式架構的數據通路是主機 CPU 通過高速串行總線把請求發(fā)給加速卡加速卡上的計算芯片從外部高帶寬存儲里反復讀取權重算完把結果寫回再經總線返回。這條通路上真正昂貴的不是計算而是“權重讀一遍、用一次、丟掉、下個令牌再讀一遍”。存算一體架構把這條通路改成主機 CPU 通過同一套總線把輸入激活送到存算加速卡權重常駐在加速卡的存算陣列里不動乘加在陣列內部完成只把輸出激活送回主機。外部存儲的角色從“權重的家”降級為“激活的暫存”容量需求和帶寬需求同時下降一個數量級。這里有一個容易在設計文檔里寫漏的點主機側的矢量計算單元和小算力 NPU 并不是冗余的。注意力模塊里的 softmax、層歸一化、掩碼、采樣這些操作計算量不大但訪存模式零碎放在存算陣列里做反而低效。合理的分工是主機側處理這些“非規(guī)則但輕量”的算子存算側只處理“規(guī)則且重”的矩陣乘。方案里如果只畫一顆存算芯片評閱時基本會被問“softmax 在哪算”。從帶寬對比看同為每秒一萬令牌的目標速率分離式架構需要幾十太字節(jié)每秒的片外帶寬存算一體架構只需要每芯粒每秒幾十吉比特量級的接口速率節(jié)省幅度超過三個數量級。這個數字也解釋了為什么單芯粒接口速度可以做得比較保守從而繞開一部分高速接口的工藝與管制約束。3.2 存邊計算架構把乘加邏輯挪到 SRAM 的邊緣存邊計算的物理形態(tài)是一片 SRAM 陣列邊緣掛一排乘加單元和歸約樹權重按行或按列靜態(tài)存放輸入激活從一側流入部分和從另一側匯出。它的好處是既能用上 SRAM 的高能效又不像交叉陣列那樣被陣列深度綁死并行度。數據流映射的具體做法是權重在計算開始前預先加載進宏單元沿輸入通道方向切塊后展平存入宏單元的不同列輸出通道方向的并行度靠堆多個宏單元實現形成空間并行。下面這段配置腳本描述了一次映射的參數組織方式實際綜合時可以把它轉成宏單元的配置寄存器表。# 存邊宏單元的權重組裝與映射配置 # 目標把一層全連接權重切成列塊鋪到 N 個 COMB 宏上 def build_mapping(in_ch, out_ch, macro_cols64, macro_rows256, macros4): in_ch / out_ch: 該層輸入、輸出通道數 macro_cols: 單個宏單元一行能放多少個權重列方向 macro_rows: 單個宏單元能放多少行深度 macros: 并行使用的宏單元顆數 # 每個輸出通道的權重沿輸入通道切塊每塊長度 macro_cols blocks_per_out (in_ch macro_cols - 1) // macro_cols # 輸出通道按宏數量均分實現輸出方向的空間并行 outs_per_macro (out_ch macros - 1) // macros mapping [] for m in range(macros): for b in range(blocks_per_out): mapping.append({ macro: m, block: b, in_start: b * macro_cols, in_end: min((b 1) * macro_cols, in_ch), out_start: m * outs_per_macro, out_end: min((m 1) * outs_per_macro, out_ch), depth_needed: outs_per_macro, # 占用宏單元行數 }) # 校驗占用行數不能超過宏深度否則需要增加宏或二次切分 assert all(x[depth_needed] macro_rows for x in mapping), 宏深度不足 return mapping for item in build_mapping(4096, 11008)[:3]: print(item)macro_cols決定了單次陣列操作的向量寬度macro_rows決定了能同時駐留多少個輸出通道的權重macros決定了輸出方向的空間并行度。三者共同決定算力存儲比。實踐中的調參順序是先按片上 SRAM 總面積和工藝節(jié)點定macro_rows再按目標算力定macros最后用macro_cols對齊位寬和累加器位寬。斷言那一行不是裝飾depth_needed超過宏深度時如果只增加宏數量而不調整切分策略會得到一堆溢出越界的地址仿真階段表現為隨機錯值非常難查。3.3 多芯粒集成的劃分與擴展性單顆芯粒的容量是有上限的。以 12/14 nm 工藝估算一顆 10 TOPS、200 MB 存儲的芯粒計算電路面積約 8 mm2存儲面積約 300 mm2折算下來算力密度只有 0.0325 TOPS/mm2。這個數字說明兩件事一是存儲面積占絕對主導想提高容量只能堆芯粒二是算力密度低不是設計失誤而是這類架構的固有特征方案文檔里必須主動解釋否則會被當成缺陷。四顆 65 nm 的 SRAM 存邊計算芯粒通過扇出型 2.5D 封裝集成在一起是這套方案里比較典型的一個規(guī)模點算力和容量都能獲得接近線性的提升封裝工藝也相對成熟。超過四顆之后映射方法需要重新設計否則算力不會隨芯粒數量線性增長原因在于芯粒間的激活廣播和部分和歸約開始成為瓶頸互聯拓撲和切分粒度都要跟著改。芯粒劃分的一般原則可以歸納成三條把同一層的權重盡量聚在同一顆芯粒上減少跨芯粒的權重訪問把需要頻繁交換部分和的通道切在同一封裝內避免走封裝外總線給每顆芯粒留出獨立的激活緩沖避免共享緩沖成為串行點。3.4 單芯粒預算表方案文檔里必須有的那張表評審看方案第一眼找的就是這張表。缺了它后面的模塊設計再細也會被質疑“沒有量化依據”。項目取值說明工藝節(jié)點12/14 nm 估算決定面積與能效基線單芯粒算力10 TOPSINT8 等效單芯粒容量200 MB片上 SRAM 權重區(qū)計算電路面積約 8 mm2乘加陣列與歸約樹存儲面積約 300 mm2占主導決定了芯粒尺寸算力密度0.0325 TOPS/mm2該類架構的常態(tài)值集成方式扇出型 2.5D 封裝四芯粒為一個規(guī)模點片間接口每芯粒 3264 Gbit/s遠低于分離式架構要求表格里最后一行是這套方案最容易被忽略的價值點因為權重不出片片間接口只需要承載激活和部分和速率要求被壓到很低封裝難度和功耗隨之下降。做方案論證時應該把這一行單獨強調它比“峰值算力多少 TOPS”更能說明架構的合理性。4. 輕量化與存內壓縮的協同設計稀疏網絡在存算陣列上如何稠密映射前面三章解決的是“權重怎么不搬家”這一章解決“權重怎么少占地方”。稀疏化本身并不新鮮難點在于把非結構化剪枝后的稀疏矩陣直接塞進規(guī)則陣列零值仍然要占存儲單元壓縮等于白做。這一章給出的是軟硬件協同的一條路徑剪枝策略、位掩碼編碼、路由網絡三件事必須一起設計。4.1 剪枝子組大小與稀疏率的確定方法稀疏化的兩個關鍵參數是子組大小和稀疏率。子組太大壓縮粒度粗精度掉得快子組太小解碼邏輯復雜位掩碼本身的開銷就吃掉收益。取值不能靠猜要在目標任務上做一輪掃描。掃描的做法是固定子組大小逐步提高稀疏率觀察驗證集指標找到指標開始下降的拐點再把拐點往回退一檔作為工作點。在一組字符級語言建模任務的實驗中子組大小取 32、修剪掉四分之三的權重時網絡性能基本保持不變于是工作點被定為“子組 32、稀疏率 75%”。這個結果不是普適常數換模型、換任務都要重掃但它給出了一個合理的出發(fā)區(qū)間。注意精度拐點必須用最終任務的指標來判定不能用訓練損失代替。訓練損失平穩(wěn)而下游指標下降的情況在這類壓縮里非常常見。4.2 位掩碼編碼與稠密權重的存內組織確定了工作點編碼方式就固定下來了權重向量按子組劃分每組按預定義稀疏度修剪剪枝后的非零權重壓成一個稠密向量同時生成一個等長的比特掩碼用來指示稠密權重在原始向量里的位置。陣列里只存稠密向量掩碼存在旁邊的掩碼存儲里兩者一一對應。下面這段腳本實現了完整的編碼與解碼校驗可以直接拿來驗證編碼邏輯有沒有寫錯。import random def prune_group(weights, sparsity0.75): 按絕對值保留最大的 (1-sparsity) 比例權重返回稠密向量與位掩碼 n len(weights) keep max(1, int(round(n * (1 - sparsity)))) idx sorted(range(n), keylambda i: -abs(weights[i]))[:keep] keep_set set(idx) mask [1 if i in keep_set else 0 for i in range(n)] # 1 表示保留 dense [weights[i] for i in range(n) if mask[i] 1] return dense, mask def prefix_popcount(mask): 前綴 popcount輸出每個位置之前含自身位置前1 的個數 用于把掩碼位置翻譯成稠密向量的下標 out, cnt [], 0 for b in mask: out.append(cnt) cnt b return out # 校驗稠密向量第 k 個元素應該落在掩碼第 prefix_popcount[mask[i]] 位 weights [round(random.uniform(-1, 1), 3) for _ in range(32)] dense, mask prune_group(weights, 0.75) pp prefix_popcount(mask) for i, b in enumerate(mask): if b 1: assert dense[pp[i]] weights[i], 編碼/解碼不一致 print(保留權重數:, len(dense), 掩碼長度:, len(mask))這段代碼的核心是prefix_popcount。它把“原向量第 i 位”翻譯成“稠密向量的第幾個元素”硬件里的實現就是一條掃描鏈加一個計數器。校驗斷言那一行是必須的編碼端和解碼端只要對“前綴是否含自身”的理解差一位整個陣列的輸出就會整體偏移一個位置現象是結果“看起來差不多但精度掉一截”屬于最費時間的 bug 之一。4.3 蝶形路由網絡前綴 popcount 與左旋轉補碼稠密權重準備好了輸入激活還得跟著一起“擠”。原始輸入特征里被剪掉權重對應的那些輸入不需要參與計算必須從輸入向量里挑出來、按順序排好送進陣列。這個重排用蝶形網絡實現多級 2 選 1 的數據分發(fā)單元控制信號由解碼器實時產生。解碼器接收位掩碼生成每一級蝶形的控制比特涉及兩個操作。第一個是前綴 popcount掃描掩碼序列輸出當前位置之前 1 的總數用來確定某個數據該被送到第幾個輸出口。第二個是左旋轉補碼LRCW本質是一次循環(huán)左移唯一區(qū)別是移位量在運算過程中以補碼形式表示用來在每一級修正路由偏移。def lrcw_shift(src_bits, shift, width): 左旋轉補碼循環(huán)左移移位量按補碼解釋負值等價于反向旋轉 shift % width # 補碼語義下先歸一化到位寬范圍 return ((src_bits shift) | (src_bits (width - shift))) ((1 width) - 1) def butterfly_route(inputs, mask, stages): 按位掩碼把輸入特征路由到稠密位置stages 為蝶形級數 width len(inputs) assert width (1 stages), 輸入長度需為 2 的整數次冪 idx [i for i, b in enumerate(mask) if b 1] routed [inputs[i] for i in idx] # 硬件中每級只做一次局部交換這里用軟件等價描述便于驗證 ctrl lrcw_shift(0b0011, 1, 4) assert ctrl in range(1 4) return routed print(butterfly_route(list(range(8)), [0,1,1,0,1,0,0,1], 3)) # 期望輸出[1, 2, 4, 7]軟件描述里看不出并行性硬件上則是每一級只做一次相鄰或跨組的 2 選 1 交換級數等于輸入長度的以 2 為底對數延遲對輸入長度是對數關系。設計時的關鍵約束是路由網絡的控制信號必須在同一拍內產生不能跨拍否則數據流水的節(jié)拍會被解碼器拖住。這也是為什么解碼器要用純組合邏輯加前綴樹而不是塞進一條通用流水線。4.4 28 nm 驗證芯片的指標拆解這套協同設計在一顆 28 nm 工藝的驗證芯片上做過實現指標可以按維度拆開看。指標數值讀法工藝 / 精度28 nm / INT8定制 SRAM 位單元陣列規(guī)模96 kB宏單元 80 kB 量級、系統緩沖 64 kB 量級工作頻率320 MHz電壓 0.641.03 V總功耗250.65 mW含控制器與全局聚合峰值性能3.3 TOPS已計入 75% 稀疏率芯片面積3.93 mm2含 8 個功能單元與特征存儲面積效率0.85 TOPS/mm2峰值性能 ÷ 面積系統能效11.83 / 25.22 TOPS/W生成 QKV / 整體注意力能效拆成兩個值來報是有意為之。生成查詢、鍵、值矩陣這一步是全連接層的稠密計算能效體現的是陣列本身的水平整體注意力包含了路由與聚合的開銷能效體現的是協同設計的水平。兩個數一起看才能判斷存內壓縮到底有沒有帶來凈收益。如果只報前一個數評審很容易問“壓縮開銷算了嗎”答不上來就會顯得方案不完整。5. 常見問題與排查從建模到流片最容易出問題的五個點方案寫到這一章之前都是“應該怎樣”這一章說“實際會怎樣”。下面五條都是在同類項目里反復出現的問題按“現象 → 原因 → 解決”組織做成檢查清單比任何設計原則都省時間。5.1 稀疏率按經驗設定精度下降后才發(fā)現子組大小取錯現象編碼和陣列仿真都通過功能正確但任務指標比基線低了兩三個點重訓也拉不回來。原因子組大小是按“常見值”設定的沒有在目標任務上掃過拐點。子組過大時一個子組里被剪掉的權重分布與權重的重要性分布不匹配等價于做了一次粗粒度的結構破壞子組過小時位掩碼的相對開銷變高壓縮收益被吃掉而精度又沒變好。解決把子組大小和稀疏率做成二維掃描表每一格記錄指標取“指標不下降前提下壓縮比最高”的那一格。掃描成本遠低于后期返工。經驗上字符級建模任務在子組 32、稀疏率 75% 附近比較穩(wěn)但換任務必須重掃。5.2 交叉陣列里零權重未清干凈稠密映射實際未生效現象陣列規(guī)?？雌饋頉]變功耗反而略微上升性能提升遠小于預期。原因非結構化剪枝后的矩陣在映射到規(guī)則陣列時被剪掉的位置如果沒有做顯式清零或旁路存儲單元里殘留的是舊值或隨機初值。計算仍然執(zhí)行但貢獻了錯誤的項為了修正它又加了額外的門控邏輯功耗就上去了。解決在映射流程里加一道強制檢查遍歷所有被剪枝的位置確認寫入的是零或已被旁路使能覆蓋。上面 4.2 節(jié)的編碼校驗腳本可以直接擴展成這一檢查把斷言從“保留位一致”擴到“裁剪位為零”。5.3 芯粒數量一增加算力不線性增長現象從四顆芯粒擴到八顆仿真出來的算力只有預期的六成左右增加芯粒帶來的收益遞減明顯。原因跨芯粒的部分和歸約和激活廣播開始成為瓶頸原來的切分策略是按四顆設計的切分粒度太粗導致每一層都要跨封裝交換中間結果?；ヂ撏負錄]有跟著調串行點就出現了。解決先做一次互聯流量統計找出跨芯粒流量最大的那幾層把切分粒度沿輸出通道方向細化同時給每顆芯粒配獨立激活緩沖把共享緩沖改成點對點。芯粒規(guī)模繼續(xù)往上時映射方法本身要重做不能沿用四芯粒的配置。5.4 只按峰值算力做功耗預算忽略封裝與散熱現象架構仿真完美熱仿真一跑結溫超標標稱頻率降不下來實測性能只有設計值的七成。原因存算一體架構的算力密度低但存儲面積大熱量分布很不均勻乘加陣列集中在邊緣SRAM 陣列鋪滿大部分面積峰值算力對應的功耗峰值集中在少數熱點上。按平均功耗做散熱設計熱點必然超標。解決把功耗預算按區(qū)域拆分別給計算邊緣區(qū)和存儲區(qū)設定功耗密度上限熱仿真按區(qū)域熱點而不是平均功耗跑。封裝選型時把熱阻作為與帶寬同級的指標來評估。5.5 仿真用理想 SRAM 模型流片后時序不達標現象RTL 仿真和門級仿真都過流片回來頻率上不到目標值或者良率異常低。原因存內計算對 SRAM 位單元的讀寫裕度極其敏感行為級模型里讀操作是零延遲、無窮驅動實際位單元在低壓下讀出擺幅很小加上陣列規(guī)模大、走線長時序和噪聲裕度都不夠。定制位單元的晶體管數量、驅動能力、讀出放大器閾值這些參數在前期模型里常被簡化。解決從設計第一天起就用帶時序與噪聲的存儲器模型關鍵路徑上跑蒙特卡洛對低壓工作點單獨做讀寫裕度分析把最低工作電壓留出足夠余量。這條問題的成本很高屬于前期少做一步、后期多花幾個月的那類問題。6. 驗收與答辯用一組可復算的指標證明架構成立方案交上去評審通常只做三件事看你的賬算不算得清、看你的結構能不能對得上賬、看你有沒有驗證過。所以答辯材料不要從“技術趨勢”講起從一張指標表講起讓每一個數字都能被現場的追問追到底。第一層是帶寬賬。開口就給出目標令牌速率下的帶寬需求以及存算一體架構下的接口速率兩者放在同一張表里標注清楚算法和公式。這一層的作用是確立問題真實存在并且你的架構確實把它解決了。評審如果追問“為什么是這個速率”現場用 2.2 節(jié)的腳本心算一遍比任何解釋都有說服力。第二層是容量與并行度。給出單芯粒容量、宏單元深度、輸出通道并行度三者的關系式說明在給定面積下為什么選這個組合。這一層最容易被問的是“為什么不多堆幾顆芯?！贝鸢敢?5.3 節(jié)的擴展性分析來接承認非線性并給出拐點位置比硬說線性更可信。第三層是稀疏協同的凈收益。把壓縮前后的存儲占用、能效、精度三項并列明確說明壓縮開銷已經計入。用 4.4 節(jié)那張表的形式把生成 QKV 的能效和整體注意力的能效分開報。第四層是覆蓋面。至少在三個維度上有驗證數據功能層編碼解碼一致性、架構層映射后的算力與容量、實現層時序、面積、功耗。只有功能仿真而沒有實現層數據是這類方案最常見的失分點。驗收維度交付物通過判據帶寬論證公式 復算腳本 對比表目標速率下接口需求低于封裝能力容量規(guī)劃芯粒預算表 映射配置權重全部駐留無跨芯粒權重訪問稀疏協同編碼校驗輸出 精度對照指標不降壓縮比達標擴展性四芯粒與八芯粒對照明確拐點與瓶頸位置實現層時序、面積、功耗匯總低壓工作點有裕度余量答辯現場還有一個很實際的小技巧把最容易出錯的兩條5.2 的零權重未清、5.5 的存儲器模型過理想主動寫進“已識別風險”那一頁附上你的應對措施。評審看到你自己先把問題擺出來追問的火力會明顯下降剩下的時間就能用來講你的架構亮點。反過來被現場問出一個你完全沒想過的坑前面所有數字的可信度都會打折。從那以后我每次帶這類硬件架構方案都強制走一遍“算賬 → 畫表 → 復算腳本 → 風險頁”這四步哪怕時間再緊也不跳。翻車的方案幾乎都不是因為想法不對而是因為某筆賬只在腦子里算過、沒落到紙上、也沒被第二個人復算過。希望這套結構能幫到你把手上那份方案從“看起來有道理”變成“經得起追問”。本文還有配套的精品資源點擊獲取