晶圓級芯片算力再好看最終都是被I/O拖死的。這句話不是夸張。最近幾年只要提到超大AI加速芯片繞不開“晶圓級”這個詞——把一整片晶圓做成一個計算芯片而不是切成幾十個小die。聽起來很美幾十萬個AI核巨大緩存超大片上SRAM。但真到了實際部署你會發(fā)現(xiàn)一個非常現(xiàn)實的矛盾計算可以鋪滿一整片硅片數(shù)據(jù)卻只能從芯片邊緣進出。I/O帶寬成了那種平時不顯眼、一旦跑真實負載就立刻卡死你的因素。我去年參與評估過類似架構(gòu)的加速器第一輪跑出來峰值算力確實漂亮但一換到真實模型吞吐率掉得厲害。后來定位了很久問題不在矩陣計算也不在內(nèi)核調(diào)度而在I/O——數(shù)據(jù)喂不進去計算陣列只能空轉(zhuǎn)。這個經(jīng)歷讓我意識到晶圓級芯片真正的評價錨點不是算力而是它怎么組織數(shù)據(jù)進出。下面把這個問題拆開聊。1. 晶圓級芯片為什么會在I/O這里被卡住1.1 算力越堆越高數(shù)據(jù)卻進不去先看一個常識單個芯片的計算密度可以隨著制造工藝和集成方式暴漲但數(shù)據(jù)進出芯片的端口密度受封裝、面板、基板、pin腳間距限制。晶圓級芯片是把幾百個die拼一起計算核心數(shù)動輒幾十萬但外部連接只有芯片邊緣的那一圈pad加上封裝基板的布線層。無論內(nèi)部多強外部數(shù)據(jù)吞吐的天花板遠低于內(nèi)部計算需求。舉個例子用最簡單的比例理解假設(shè)一片晶圓級芯片內(nèi)部有10萬個計算單元每個單元每個時鐘周期需要從片上存儲器讀取幾百字節(jié)數(shù)據(jù)內(nèi)部設(shè)計可以做到很高帶寬。但如果這些數(shù)據(jù)都需要從芯片外部進入外部I/O總帶寬可能只有片上帶寬的百分之一甚至千分之一。這意味著絕大多數(shù)計算單元必須依賴片上緩存反復(fù)復(fù)用數(shù)據(jù)一旦緩存局部性不好就會暴露外部帶寬缺口。所以晶圓級芯片的I/O瓶頸本質(zhì)上是一個“面積與周長”的矛盾。算力與存儲可以平均分布在整個二維平面但外部通信只能從邊界進出。面積增長是平方關(guān)系周長只是線性關(guān)系。即使整片晶圓的面積比普通芯片大幾十倍也只是把可用的I/O總帶寬增加了幾倍遠達不到算力增長的幅度。1.2 帶寬瓶頸不是簡單多放幾個引腳就能解決有人會說那我把芯片周圍的pad做密一點不就有更多I/O了嗎沒那么簡單。芯片I/O帶寬受幾個環(huán)節(jié)同時制約。首先是封裝基板芯片pad信號要通過基板走線扇出到球柵陣列走線層數(shù)和線寬決定了信號密度。晶圓級芯片尺寸巨大基板相應(yīng)也要大翹曲、熱膨脹、信號完整性都會變差。其次高速串行接口需要大量電源引腳和地引腳配對單純增加信號引腳會引入串?dāng)_和電源噪聲。第三更實際的問題在功耗每一路高速SerDes串行器/解串器都要消耗幾瓦甚至幾十瓦晶圓級芯片本身功耗已經(jīng)非常高再堆大量高速I/O熱密度會先擊穿系統(tǒng)。因此I/O瓶頸不是“硬件設(shè)計時少加了幾根線”的問題而是從物理、封裝到功耗都受到約束的系統(tǒng)性問題。這也是為什么晶圓級芯片常采用特殊設(shè)計來回避I/O壓力而不是硬懟引腳數(shù)量。2. 拆開看看I/O帶寬瓶頸到底卡在哪幾層2.1 封裝物理極限引腳數(shù)量、扇出和信號完整性普通工藝下芯片pad pitch在4080微米量級晶圓級芯片如果要兼容標準封裝pad數(shù)要控制在合理范圍。假設(shè)一片芯片的邊長大約220毫米300mm晶圓直徑四邊利用率假設(shè)只有70%即使按50微米pitch算可用pad數(shù)量也只是十萬到二十萬量級。每個pad如果跑2Gbps甚至5Gbps理論上I/O可以到數(shù)百Gbps到數(shù)Tbps。但別忘記這需要大量的差分對、電源、地、冗余實際可用差分信號對數(shù)會少一個數(shù)量級。更重要的是信號完整性。晶圓級芯片封裝基板的尺寸大走線長阻抗控制難引腳之間的串?dāng)_和損耗更明顯。如果盲目增加I/O數(shù)量信號質(zhì)量下降誤碼率上升最終有效帶寬可能不升反降。所以設(shè)計上通常要留出足夠的信噪比預(yù)算有些方案寧可降低接口速率也不犧牲誤碼率。從工程經(jīng)驗看封裝層面的I/O優(yōu)化空間是有限的除非走向更先進的封裝技術(shù)例如co-packaged optics共封裝光學(xué)或硅光互連。但這些技術(shù)目前成本高良率挑戰(zhàn)大距離大規(guī)模商用還有距離。2.2 功耗墻SerDes功耗與帶寬不成線性I/O鏈路每提升一個檔次的速率在相同調(diào)制技術(shù)下功耗/bit并不會等比例下降。到56Gbps PAM4或112Gbps PAM4時代單通道功耗可以達到500mW1.5W這還只是PHY功耗不含編碼和協(xié)議處理。晶圓級芯片如果要追求50Tbps甚至100Tbps的外部I/O帶寬光是PHY功耗就可能占滿整個芯片功耗預(yù)算的相當(dāng)大比例。計算芯片的功耗早就被熱管理制約晶圓級芯片更是如此。之前不少AI加速器為了達到較高帶寬采用HBM堆疊但HBM每個堆棧的IO功耗也在幾十瓦量級。如果用戶需要更多HBM堆棧功耗自然上漲而高帶寬存儲堆棧本身就制造了新的熱源還會加重封裝散熱負擔(dān)。因此晶圓級芯片設(shè)計不得不在I/O帶寬、存儲帶寬和功耗之間做取舍。很多廠商給出的峰值I/O帶寬往往是理論最大值真實部署時受功耗限制后能用的要打折扣。2.3 外部存儲帶寬HBM 數(shù)量、堆疊層數(shù)和熱密度晶圓級芯片計算速度很快存儲系統(tǒng)如果跟不上就會出現(xiàn)“數(shù)據(jù)饑渴”。目前主流高帶寬存儲是HBM2e、HBM3甚至HBM3e。單顆HBM3e的帶寬可以達到1.2TB/s以上但這只是存儲堆棧本身的接口帶寬連接HBM與計算芯片的Interposer/Silicon Bridge以及基板通道也是瓶頸。多個HBM堆棧并排放在晶圓級芯片周圍還會占據(jù)大量封裝面積和布線資源。我們經(jīng)?？吹揭恍┬麄魑陌笇憽癏BM總帶寬達到xx TB/s”但實際使用時還要看存儲控制器的調(diào)度能力、讀寫混比、訪問模式和數(shù)據(jù)分布。HBM本質(zhì)上是一個共享資源如果不同計算核同時訪問不同堆棧地址映射和路由可能造成沖突實際帶寬遠低于理論值。晶圓級芯片為了減少對外部存儲的依賴通常會把大量SRAM直接集成在die內(nèi)形成巨大的片上緩存。這確實是一個聰明的方向與其把大量數(shù)據(jù)放在外部存儲不如抬高數(shù)據(jù)局部性減少跨芯片和跨存儲層的數(shù)據(jù)搬移。但代價是片上SRAM容量和面積受限應(yīng)用程序如果無法復(fù)用數(shù)據(jù)還是有大量數(shù)據(jù)需要通過外部存儲接口而外部存儲帶寬又受HBM堆棧數(shù)量、封裝布線和功耗的聯(lián)合約束。2.4 片內(nèi)互連晶圓級片上網(wǎng)絡(luò)也有帶寬和延遲約束晶圓級芯片不是幾十個核的小系統(tǒng)而是幾十萬個核的超級網(wǎng)格。片內(nèi)互連網(wǎng)絡(luò)片上網(wǎng)絡(luò)的帶寬、跳數(shù)、路由策略一樣影響數(shù)據(jù)供給。如果片內(nèi)數(shù)據(jù)網(wǎng)絡(luò)沒有足夠的臂展帶寬即使數(shù)據(jù)已經(jīng)到了芯片邊緣也無法快速送到目標計算單元。片內(nèi)互連的瓶頸更多體現(xiàn)在扇出和功耗上每條長距離連線都需要中繼器(buffer)會消耗功耗和面積。把幾百個die連接起來的跨die總線需要穿過硅中介層或通過微橋連接跨die通信的延遲和功耗遠高于die內(nèi)部。如果路由算法沒有把數(shù)據(jù)盡量控制在同一個die或鄰近die那么大量跨die流量會造成片上網(wǎng)絡(luò)擁塞拖累整體吞吐。這也是為什么說I/O瓶頸不僅指芯片外部接口還包括芯片內(nèi)部的數(shù)據(jù)分發(fā)路徑。3. 繞開瓶頸的工程思路從硬件到軟件協(xié)同3.1 存儲近計算把數(shù)據(jù)放在計算單元邊上晶圓級芯片最大的結(jié)構(gòu)優(yōu)勢其實是巨大的片上SRAM。設(shè)計上應(yīng)該盡量讓數(shù)據(jù)在片上多復(fù)用把外部存儲和外部I/O當(dāng)作最后的數(shù)據(jù)源而不是每次計算都去搬數(shù)據(jù)。具體做法包括使用較大的一級/二級緩存并在運行時做顯式的數(shù)據(jù)分塊tiling讓每次從外部HBM讀入的數(shù)據(jù)塊能在片上停留足夠長時間完成多輪計算后再寫回。這有點像CPU的寄存器分塊和緩存優(yōu)化但在晶圓級芯片上緩存容量可以非常大優(yōu)化的空間也大。如果你的應(yīng)用屬于卷積、Transformer推理或矩陣乘法這類經(jīng)典算子可以通過分塊策略做到高數(shù)據(jù)復(fù)用減少到外部存儲的數(shù)據(jù)流量。但如果你的應(yīng)用是圖神經(jīng)網(wǎng)絡(luò)、稀疏推理、隨機訪問較多的業(yè)務(wù)局部性很差片上緩存的命中率會低I/O瓶頸就會暴露得更明顯。3.2 片內(nèi)互連的層級設(shè)計減少跨片流量晶圓級芯片如果由多個die拼接而成那么die之間的互聯(lián)帶寬就成了隱藏瓶頸。工程上有一個樸素的設(shè)計原則數(shù)據(jù)盡量在核組compute cluster內(nèi)部流動避免跨die長距離路由。具體可以這樣做在體系結(jié)構(gòu)層面把計算核按物理位置分區(qū)任務(wù)與數(shù)據(jù)映射盡量采用分區(qū)分片的策略。在通信庫和編譯器層面盡可能把對相同數(shù)據(jù)的訪問調(diào)度到同一個die上的核減少跨die同步。如果不得不跨die通信優(yōu)先使用靠近數(shù)據(jù)源的局部網(wǎng)絡(luò)而不是全芯片統(tǒng)一路由。這類方法不一定寫入芯片說明書但在實際程序調(diào)優(yōu)時非常有效。我見過很多晶圓級加速器的性能問題最后都歸結(jié)為“通信局部性差”數(shù)據(jù)在片上網(wǎng)絡(luò)繞了很長的路把有效帶寬消耗在路由擁塞上。3.3 數(shù)據(jù)壓縮與稀疏化讓有效帶寬翻倍I/O帶寬緊張除了想方設(shè)法增加物理帶寬還可以減少傳輸?shù)臄?shù)據(jù)量。這一點在深度學(xué)習(xí)場景里尤其有效。對權(quán)重、激活值做量化從FP32降到INT8甚至INT4數(shù)據(jù)量直接除以4或8。對梯度做稀疏化只傳輸非零梯度或top-k梯度大幅度降低通信量。對中間特征做無損或有損壓縮很多AI框架里的通信庫已經(jīng)支持梯度壓縮晶圓級芯片的SDK也往往提供類似能力。壓縮不是免費的解壓和壓縮需要額外計算資源還會引入延遲。通常在芯片端到端總帶寬已接近極限時壓縮的收益會大于消耗。實際工程里可以先做profiling看看當(dāng)前任務(wù)的片上總流量和有效利用率再決定是否引入壓縮或稀疏化。3.4 運行時調(diào)度和流水線重疊把等待時間變成計算時間很多I/O瓶頸不是硬件接口不夠快而是任務(wù)調(diào)度沒有把數(shù)據(jù)加載和計算重疊起來。思路很簡單如果計算需要的數(shù)據(jù)還在路上就讓計算單元先處理已經(jīng)在緩存里的下一批數(shù)據(jù)形成“數(shù)據(jù)加載-計算-寫回”流水線。這套做法在傳統(tǒng)HPC里叫overlap communication and computation在晶圓級芯片上同樣適用。硬件上需要異步數(shù)據(jù)搬運引擎DMA、copy engine軟件上需要任務(wù)切分和預(yù)取機制。如果你使用的SDK支持異步數(shù)據(jù)流建議用它替代同步接口。否則計算單元會在緩存未命中時空轉(zhuǎn)表現(xiàn)出的有效帶寬遠低于硬件能力。流水線重疊還會改變排障思路很多“帶寬不夠”的問題其實是同步等待過多而非接口物理帶寬真的耗盡。先用profiler看時間線如果發(fā)現(xiàn)計算和拷貝沒有重疊那優(yōu)先去優(yōu)化調(diào)度而不是買更貴的硬件。4. 如果要在真實項目中評估和驗證I/O帶寬4.1 一個可參考的評估流程評估晶圓級芯片的I/O能力不要只看宣傳PPT建議按下面四步走確定負載特征。先明確跑什么類型的算子/模型訪存密集還是計算密集數(shù)據(jù)復(fù)用度如何。計算密集、復(fù)用度高的模型I/O壓力相對小訪存密集、隨機訪問多的模型I/O壓力大。用同一套真實負載構(gòu)建基準。選取至少兩個模型一個高數(shù)據(jù)復(fù)用一個低數(shù)據(jù)復(fù)用。分別記錄單batch和連續(xù)batch的吞吐。分析瓶頸位置。用profiler查看計算單元利用率、緩存命中率、I/O隊列深度、PCIe/HBM鏈路利用率。如果計算單元利用率低但I/O鏈路已經(jīng)拉滿那就是I/O瓶頸。做壓力測試。逐步增加并發(fā)和batch size觀察有效帶寬是否先于計算能力飽和。畫一條帶寬利用率-計算量曲線能直觀看出系統(tǒng)在什么位置進入拐點。這套流程能幫助你區(qū)分“計算瓶頸”“存儲瓶頸”和“I/O瓶頸”避免把問題簡單歸結(jié)為“帶寬不夠”。4.2 常見誤區(qū)單看峰值帶寬不看實際可達帶寬很多人比較不同加速器時直接看“I/O帶寬”數(shù)字比如“芯片到外部接口帶寬為20TB/s”或“HBM帶寬為4TB/s”。但這些數(shù)字和真實可達帶寬差距很大。實際可達帶寬需要扣除編碼開銷、協(xié)議開銷、讀寫切換開銷、訪問沖突和刷新開銷。以PCIe為例說128GT/s的PCIe有效數(shù)據(jù)帶寬通常只有八成左右HBM也有類似情況如果全部讀或全部寫也許能接近峰值但讀混寫時會掉很多。所以在評估時要問清楚官方數(shù)字是單向峰值還是雙向總和是物理層速率還是有效數(shù)據(jù)速率是否包含糾錯碼ECC開銷這些細節(jié)直接決定了你對I/O能力的判斷是否準確。4.3 排查鏈路從鏈路、協(xié)議、驅(qū)動、拓撲到負載如果實際I/O帶寬明顯低于預(yù)期建議按下面的順序排查先看物理鏈路。接口是否工作在預(yù)期速率信號完整性是否達標誤碼率是否正常。鏈路可能因為布線長度、連接器質(zhì)量、供電噪聲降速。再看協(xié)議層。檢查是否有握手超時、重傳、流控反壓。統(tǒng)計協(xié)議層面的事件比如NAK、重傳次數(shù)這是排查隱藏性能損失的好入口。再看驅(qū)動和系統(tǒng)層。DMA緩沖是不是分配在不可訪問區(qū)域中斷處理是否頻繁頁大小和內(nèi)存鎖頁是否影響內(nèi)核和用戶態(tài)之間的數(shù)據(jù)拷貝這些問題經(jīng)常被忽略。再看拓撲和路由。數(shù)據(jù)訪問路徑上是否有擁塞節(jié)點比如多個核爭搶同一個I/O通道或同一個HBM堆棧。有些問題在你驗證初期不會出現(xiàn)擴容后才暴露。最后才回到負載本身。訪問模式是否隨機、是否存在大量小指令寫、是否頻繁切換讀/寫方向。不要直接懷疑硬件標注錯了。絕大多數(shù)“帶寬不達標”的現(xiàn)象最終都能在協(xié)議層、驅(qū)動映射或者負載特征中找到原因。4.4 這類方案適合誰不適合誰晶圓級芯片在I/O上天然有挑戰(zhàn)但它依然適合特定場景需要超大片上緩存、超強算力且數(shù)據(jù)復(fù)用度極高的蜜罐型負載比如大規(guī)模稀疏模型訓(xùn)練、Transformer推理、科學(xué)計算中的某些結(jié)構(gòu)化網(wǎng)格計算。這類負載的核心收益來自“大量計算在片上完成減少外部I/O流量”。不適合的場景包括訪問模式高度隨機、數(shù)據(jù)量遠超片上容量、無法做數(shù)據(jù)分塊的負載。比如某些圖計算或數(shù)據(jù)庫查詢大量數(shù)據(jù)需要從外部存儲隨機讀取片上放不下外部I/O一旦成為瓶頸晶圓級芯片可能反而不如多個小芯片并聯(lián)靈活。因此選擇這類方案前先算一算“擬算法的算術(shù)強度”和“數(shù)據(jù)復(fù)用度”。如果算術(shù)強度很低數(shù)據(jù)復(fù)用度不高I/O壓力必然很大晶圓級芯片的優(yōu)勢會大打折扣。這也是為什么有些通用加速器團隊評估完晶圓級芯片后選擇放棄不是因為芯片不好而是因為負載不匹配。另一個需要關(guān)注的邊界是軟件生態(tài)。晶圓級芯片的編程模型通常與傳統(tǒng)GPU或CPU有很大差異很多算子的實現(xiàn)需要重新編寫。如果團隊沒有足夠精力做深度移植和優(yōu)化那么再大的內(nèi)部算力也體現(xiàn)不出來。這個問題比I/O硬件瓶頸更隱性也更容易導(dǎo)致項目延期。說到底晶圓級芯片的I/O帶寬問題不是一道簡單的“增加I/O接口”題而是封裝、功耗、存儲、互連和軟件調(diào)度共同作用的系統(tǒng)設(shè)計課題。評估任何這類加速器時我都建議把“峰值算力”放在一邊先去問一個問題這套系統(tǒng)能夠穩(wěn)定維持的、真實負載下的有效I/O帶寬是多少只有把這個數(shù)字摸清楚你才算真正看懂了一臺晶圓級芯片。如果你正在考慮采購或使用這類方案我的建議是別急著跑大模型先拿一個訪存密集、數(shù)據(jù)復(fù)用低的小測試程序探底。這個小程序跑出來的實際帶寬往往比幾百頁的架構(gòu)白皮書更能說明問題。晶圓級芯片的潛力是真實的但它的I/O邊界也是真實的。那些在邊界之內(nèi)妥善設(shè)計的人和團隊才有機會獲得真正的收益。