Broadcom Tomahawk 6 頻寬倍增，AI 網絡仍面臨擴展瓶頸
Broadcom Tomahawk 6 將單晶片 Ethernet 交換容量提升一倍至每秒 102.4 Tb，但這項進展不會自動令 AI 叢集的實際可用容量增加一倍。在營運商連接更多加速器前，更快的連線已可耗盡額外頻寬。隨之而來的壓力不止影響交換器，亦延伸至建築佈局、軟件及部署時間表。
Data Center Dynamics 於 10 月 30 日刊出的一篇評論文章，再次聚焦這種張力。文章作者、Eridu 聯合創辦人 Omar Hassen 認為，網絡必須從一開始便塑造 AI 設施。他的警告值得重視，同時亦應仔細審視其論述背後的時間線及假設。
Broadcom 與 Nvidia 已透過更快的交換技術及光學整合回應這一趨勢。Meta 的工程實務則帶來另一項考量：已安裝頻寬與可用頻寬並非同一回事。核心衝突在於不斷增長的通訊需求，以及網絡提供可預測應用程式效能的能力。
Broadcom Tomahawk 6 改變了數字，而非整道方程式
最新的頻寬提升確有其事，但不代表網絡限制已經消失。
Broadcom 在 2025 年 6 月 3 日宣布開始出貨 Tomahawk 6。其標示容量為每秒 102.4 Tb，用以衡量資料經交換器晶片傳輸的總量。該公司亦描述了為 AI 基礎設施而設的路由及連接功能。
在評估近期的網絡牆論點時，這項公告相當重要。Hassen 將不足的交換器頻寬及連接性視為高效 AI 基礎設施的限制因素。他主張提高連接度及採用更扁平的網絡，亦即減少交換層數的設計。
這篇文章屬於供應商高層的分析，而非整個市場的獨立量測。這項區別不會否定其論點，但意味讀者應把架構層面的主張，與有關業界進展的說法分開看待。
尤其需要謹慎看待時間線。Broadcom 的Tomahawk 5 發布可追溯至 2022 年 8 月 16 日，當時公司宣布具備 51.2 Tb 交換容量。下一次公告在 2025 年 6 月發布，相隔不足三年。
這些日期不支持將晶片發布間隔視為接近四年。它們亦無法說明完整系統何時廣泛供應或投入生產。晶片出貨、設備驗證及實際營運部署，分別代表不同里程碑。
這項區別改變了買家應提出的問題。問題不只是交換器製造商有否將容量提升一倍，而是可部署的系統能否以目標工作負載所需的速度，提供足夠的實用連接性。
更快的晶片可帶來設計選項。營運商可將其容量分配予更快的連線、更多連線，或兩者兼備。封裝、設備設計及支援的配置，決定哪些選項可成為實際產品。
因此，頻寬里程碑應是架構評估的起點，而非終點。買家需要將晶片規格與可採購的設備連繫起來，然後再將該設備與應用程式行為連繫起來。
同樣的審慎態度亦適用於「網絡已不可逆轉地落後於運算」的說法。不存在一個可描述每種模型、叢集或部署的通用比例。有些應用程式頻繁交換資料，另一些則可將更多工作留在本地完成。
較可辯護且更有用的結論是：交換容量一直進步，但單靠容量仍不足以完整描述 AI 基礎設施。當工作負載的通訊需求超出網絡實際可提供服務的能力時，壓力便會出現。
更快的連接埠可耗盡全部頻寬增幅
交換器可以變得更快，卻未必能以所需速度連接更多加速器。
關鍵分別在於總頻寬與 radix，即交換器在指定速度下支援的獨立連接數目。兩個數字都不能脫離對方而單獨理解。較低速度下的大量連接，並不等同於較高速度下相同數量的連接能力。
計算方式說明了為何交換器頻寬擴展可能令基礎設施規劃人員失望。若總容量增加一倍，而每條連線所需頻寬亦增加一倍，理論上的連接數目便維持不變。這是條件關係，並非對每款已出貨交換器的量測結論。
這種關係之所以重要，是因為 AI 設施必須同時容納通訊速度及叢集規模。滿足其中一項要求，可能消耗原本用於另一項的資源。營運商不能假定新一代交換器會同等擴展這兩個維度。
實體連接器亦帶來另一項複雜因素。它未必對應一條獨立的加速器連線。設備可把通道合併為更高速的連結，或透過 breakout 配置分拆所支援的連線。
因此，買家需要了解支援的配置，而不是只看宣傳上的連接器數目。他們亦需要知道多少連線服務加速器，以及多少連線用於連接交換器。分配在交換層之間的容量，不能同時服務端點。
Broadcom 的Tomahawk 6 規格說明了配置細節為何重要。該公司描述了一個兩層網絡，可支援超過 100,000 個加速器，每條連結速度為每秒 200 Gb。這是與既定連線速度掛鈎的供應商設計主張，而非適用於所有叢集的保證。
速度條件必須與規模數字一併理解。若移除這個條件，比較便會產生誤導。能以某一速度支援大量端點的設計，未必能在更高速度下自動支援相同數量的端點。
同樣的原則亦適用於交換層數。增加一層可延伸網絡，但也會引入更多設備及連線。這種取捨是否可以接受，取決於流經該層的流量。
更大的網絡不一定會在所有實用層面上更慢。若設計及軟件能有效使用額外路徑，便可提供容量及韌性。同樣地，較少層數亦不保證帶來更佳的應用程式效能。
實際限制在於網絡必須維持的通訊模式。某項設計可能能妥善處理本地化流量，卻在應用程式跨越遙遠群組通訊時遇到困難。總頻寬可以掩蓋這種差異。
這正是比較不同世代交換器時，不能只檢查容量有否倍增的原因。有意義的比較必須固定端點速度、工作負載、韌性要求及拓撲結構。拓撲結構是指裝置與連結的排列方式。
缺少這些條件時，交換器頻寬擴展看來或許令人印象深刻，但營運問題大致不變。有了這些條件，買家才能找出設計中真正受惠的部分。
壓力會先落在叢集擁有人身上，而非應用程式使用者
當已付費的運算容量必須等待通訊時，網絡限制便會成為營運問題。
以分散式訓練工作為例，多個加速器協作更新同一模型。每個加速器執行部分運算，並在指定時間點與其他參與者交換資訊，才可繼續進行。
集體操作會協調一組處理器之間的資料交換。例如，All-reduce 會合併各方貢獻，並分發合併後的結果。其完成時間取決於該群組所需的通訊。
重要後果是協調。一個加速器完成本地工作後，未必可以獨立繼續。通訊延遲可延長恢復有效運算前的等待時間。
這不代表每一個閒置的加速器都由網絡造成。資料準備、軟件行為、記憶體限制及排程，同樣可以限制效能。將所有使用不足歸咎於網絡，反而會掩蓋真正的診斷結果。
對叢集擁有人而言，相關問題是哪項限制因素決定工作完成時間。當另一項資源決定節奏時，更快的交換器價值有限。相反，若通訊仍在關鍵路徑上，更快的處理器所帶來的好處亦會減少。
這為基礎設施規劃帶來壓力。採購團隊可透過不同流程採購加速器及網絡設備，但應用程式會同時感受到兩者。設備決策已限制可用補救措施後，這種不匹配便會在工作負載執行期間顯現。
相同關係亦見於推論，即執行已訓練模型以產生輸出的過程。當模型跨越多個加速器時，通訊便成為處理請求的一部分。其重要性取決於應用程式如何劃分工作。
Mixture-of-experts 模型會針對不同輸入選取專門的模型組件。當這些組件位於不同裝置時，於它們之間路由工作便會增加通訊要求。部署安排決定多少流量跨越網絡。
另一種安排會將處理輸入提示的 prefill，與產生後續輸出的 decode 分開。將模型的中間注意力狀態在這些階段之間移動，會引入傳輸需求。這種取捨可能值得，但其價值部分取決於網絡行為。
這些例子說明，AI 網絡瓶頸應按工作負載評估。訓練結果不能自動預測推論效能。為某種通訊模式優化的配置，在另一種模式下可能表現不同。
應用程式使用者會間接遇到這些限制。他們感受到的是完成時間、服務一致性及可用容量，而非交換器規格。因此，企業買家需要反映其預期使用方式的服務證據。
叢集營運商面對更直接的責任：找出通訊在哪裏限制有效工作，然後決定硬件、軟件或配置調整能否解決問題。到處增加頻寬，是理解限制因素的昂貴替代方案。
由此產生的規劃轉變十分具體：網絡要求應在採購鎖定架構前，納入工作負載設計及設施決策之中。等待明顯的擁塞出現，會留下較少實際可行的選項。
更多交換容量無法修復每一種流量問題
網絡即使具備足夠的總容量，流量仍可能被導向錯誤路徑。
設想一個在通訊裝置之間存在多條可用路徑的網絡。若繁忙傳輸集中於同一路徑，另一條路徑可能仍未被充分使用。增加已安裝的總頻寬，並不保證流量能有效分配。
這正是硬件規格與傳輸行為交會之處：端點用來傳送、確認及復原資料的規則。這些規則會影響應用程式如何有效運用可用路徑，也決定當壅塞或遺失中斷通訊時會發生甚麼情況。
Meta 已發表的分散式訓練網絡工作提供了一個營運層面的例子。其工程師描述了路由挑戰、與通訊軟件的協調，以及考慮網絡佈局的排程方式。他們的經驗支持將網絡視為一個系統，而非單純採購交換器。
RoCE，即透過融合式乙太網路進行遠端直接記憶體存取，讓裝置能夠經由乙太網絡存取遠端記憶體。Meta 的說法指出，營運這類網絡所需的改變不僅限於原始鏈路速度。當中的教訓在於整合，而非普遍認可某一種配置。
工作放置是這種整合的一部分。把頻繁通訊的裝置在網絡中安排得較接近，可減少流經受限鏈路的流量。以不同方式分散它們，即使加速器總數不變，也可能增加壓力。
因此，排程決策會影響硬件表現所呈現的品質。採用有利放置方式的基準測試，可能在較不規整的生產環境中無法重現。買家在把基準測試表現視為服務承諾前，應理解這項差異。
Meta 於 2026 年 8 月 24 日發表的 MetaRoCE 傳輸設計，延續了同一場討論。該公司描述把更多路徑管理工作移至網絡端點，並支援亂序抵達的封包。它報告已使用 AMD Pensando 網絡硬件進行驗證。
這些都是公司自行報告的結果，並受其所述測試條件所限。它們並不證明每種加速器、介面卡或生產環境都會有等同表現。其意義在於，一家大型營運商正透過傳輸設計配合實體基礎設施，一同處理網絡限制。
因此，Broadcom、Nvidia 與 Meta 不應被簡化為一場交換器容量的競賽。它們的工作橫跨通訊系統的不同部分。硬件與軟件的改進可以互相配合。
對買家而言，這令供應商比較更複雜，卻也帶來更好的問題。效能是否依賴特定介面卡？通訊函式庫是否需要特定設定？鏈路故障後流量如何重新分配？
這些問題把 AI 網絡瓶頸連結到營運責任。必須有人維護能交付承諾結果的配置。若營運團隊無法觀察或排除故障，效能功能的實際價值便有限。
更廣泛的含意是，不能只從總容量推斷應用程式效能。有效路由、相容端點及工作負載放置，共同決定有多少容量能轉化為實用效益。更快的晶片帶來餘裕；系統決定如何有效運用它。
光學整合處理功耗，同時帶來營運問題
降低通訊功耗很有價值，但效率主張需要清晰界定衡量範圍。
Nvidia 於 2025 年 3 月公布光子網絡交換器，包括 Spectrum-X Ethernet 與 Quantum-X InfiniBand 產品。其公告把光學整合置於網絡策略的核心。Broadcom 亦描述了 Tomahawk 6 的光學整合選項。
共同封裝光學技術會把光學元件置於整合封裝內、接近交換器晶片的位置。這種方法縮短了訊號轉換為光之前所經過的部分電氣路徑。供應商將其定位為提升高速通訊效率的方法。
這處理了問題的重要部分，但不是全部。效率更高的光學連接，無法獨自解決不理想的流量放置，也不能證明整個設施能以相同應用程式輸出消耗更少能源。
衡量範圍十分重要。比較可能涵蓋光學元件、網絡設備，或整個運算設施。這些是不同的主張，應保持區分。
同樣地，通訊效率提升不會自動轉化為等量的應用程式改進。結果取決於應用程式花多少時間進行通訊，也取決於通訊改善後，是否有其他限制成為主導因素。
這是一般的效能關係，而非反對光學整合的證據。移除一項限制，可能會暴露另一項限制。買家需要知道，哪些改進在應用程式層面量度時仍能成立。
營運設計會引入更多問題。採用整合元件的設備可能改變更換程序及備件規劃。相關細節取決於特定系統，因此對可維護性的廣泛主張須審慎看待。
採購團隊應確定技術人員可以獨立更換哪些元件，也應了解隔離故障的程序。這些事實會影響效率改善如何融入營運環境。
可靠性比較同樣需要嚴謹態度。元件的失效行為與服務可用性彼此相關，但並不相同。即使個別元件故障，冗餘路徑與復原軟件仍可維持應用程式進度。
相反，高可靠性的元件並不保證服務不會中斷。軟件錯誤、配置失誤及其他位置的故障，仍可能影響應用程式。評估整體設計，可避免狹窄的可靠性指標演變成缺乏支持的服務主張。
因此，最有力的質疑角度在於範圍。更快的交換與光學整合解決了可識別的工程問題。證據必須顯示，這些方案如何影響所採購的工作負載、設施及維護流程。
這一標準同樣適用於永久網絡瓶頸的預測。隨着應用程式、傳輸軟件及設備改變，限制可能會轉移。有用的問題是，哪項限制主導下一次部署，而不是某項技術會否永久勝出。
對營運商而言，Broadcom Tomahawk 6 作為一項具體的硬件進展，應納入這項評估。其價值取決於它所促成的設計，以及該設計帶來的結果。
關注可部署系統、工作負載結果與復原行為
下一批證據應把產品能力連結至可重複的營運結果。
在未來數月，首個訊號將是指定配置下完整系統的可用性。晶片公告確立技術進展，但買家需要可供驗證、安裝及支援的設備。這些里程碑之間的關係值得明確報道。
對 Broadcom Tomahawk 6 系統而言，有用的披露資料會列明支援的端點速度、連接數目及網絡佈局。它們應區分可用配置與計劃中的選項，亦應說明哪些軟件功能已準備好投入營運使用。
這類證據將強化較新交換技術能紓緩當前限制的論點。已公布能力與通過驗證設備之間若持續存在落差，則會削弱該論點。兩種結果都不需要假設每名營運商遵循相同的部署時間表。
下一個訊號是在可比較條件下的工作負載效能。有用的比較會在識別網絡變更的同時，保持應用程式及加速器配置不變。否則，改善可能來自軟件或運算硬件的無關變更。
訓練比較應連同通訊量度，報告應用程式完成行為。推論比較則應描述請求特性及服務條件。沒有工作負載背景的結果，對採購決策的指引有限。
尾端延遲，即異常緩慢的完成時間，也值得關注。平均效能可能掩蓋影響協作工作或使用者體驗的延誤。買家需要知道，改善在持續需求下是否仍然一致。
強勁的結果會顯示，增加容量或改善傳輸能減少具意義的應用程式限制。疲弱的結果則會顯示，在納入真實營運條件後，效益不大。無論哪一種發現，都比另一項孤立的頻寬紀錄更具資訊價值。
最後一個訊號是在故障及混合需求下的復原行為。當鏈路失效、流量轉移或多個應用程式競爭時，應評估網絡表現。這些條件揭示架構能否在精心安排的示範以外，保留實用工作能力。
對端點驅動傳輸而言，相關證據包括相容硬件及其在不同網絡佈局下的行為。對光學整合而言，則包括元件出問題時的維護程序及服務持續性。這些都是技術主張的實際延伸，並非獨立議題。
可重複的復原結果將支持對更大規模部署的信心。難以排除故障或不穩定的行為，則會限制更高容量所呈現的效益。結果之所以重要，是因為營運商必須在系統整個使用壽命中支援它。
工程團隊應保留每項比較背後的假設，包括工作負載放置、設備配置及軟件版本。可搜尋的工程知識庫有助在部署條件改變時，保留這些決策資料。
在批准下一個叢集之前，要求供應商在你預期的營運條件下，展示你打算運行的應用程式。要求提供受支援的連接配置、通訊軟件假設，以及故障後的行為。把這些發現附於採購決策之上，讓後續團隊能區分設計限制與配置問題。Broadcom Tomahawk 6 表明交換器容量正在提升；你的驗收準則應確定這項提升是否改善實用工作。先從工作負載的通訊需求着手，據此比較完整系統，並把部署準備度納入效能討論。當安裝環境繁忙、不完美且超出基準測試情境時，哪一個網絡仍能支撐你的應用程式？
