AI時代的數據中心，正在被網絡“卡脖子”丨ToB產業觀察

Leo張ToB雜談2026.08.17 17:42 · 來自北京全文3944字00:00 / 11:56芯片算力的增長速度，已經遠遠超過了數據在芯片之間搬運的速度。過去幾年，人們習慣用單顆GPU的算力指標來衡量AI基礎設施的先進程度。但在2026年，算力競賽的底層邏輯已經被改寫。當大模型訓練集群從千卡邁向萬卡甚至十萬卡，真正的瓶頸早已不是芯片算力，而是網絡。就像一條高速公路，車道修得再寬，如果收費站堵死了，車還是跑不起來。AI集群正在遭遇的，正是這樣一場擁堵。GPU在等數據先看一組數據。

是德科技網絡與數據中心副總裁Joachim Peerlings在Keysight World大會上展示了一組令人深思的數字：在計算機視覺模型訓練中，GPU有超過60%的時間花費在數據移動和通信上，真正用於計算的時間僅佔20%左右。換句話說，一塊昂貴的GPU，大部分時間不是在“算”，而是在“等”，等數據從隔壁的GPU傳過來。這還不是最糟糕的。在資源最密集的大語言模型訓練任務中，因網絡問題導致的訓練失敗率高達21%。每五次訓練就有一次因為網絡問題而中斷，而一次中斷可能意味著數小時甚至數天的計算成果付諸東流。

中科曙光高級副總裁李斌算過一筆賬：傳統CPU計算節點，一臺機器配一張網卡就夠了；但如今以GPU為中心的計算節點，一臺機器需要配置八張甚至更多網卡。“相比原來的數據中心高速網絡用量，基本提升了10到20倍。”更棘手的問題在於，上萬張卡需要在同一時間高度協同工作，任何一個節點的網絡抖動、擁塞或丟包，都可能導致成百上千張卡進入等待狀態。今天的AI大模型訓練集群，單端口流量已經逼近400G。但傳統網絡的負載均衡算法依然停留在“逐流ECMP”的時代，這種模式將每一條數據流通過哈希算法分配到某一條鏈路上。

問題是，AI訓練的流量模式需要成千上萬個GPU同時發起通信，流量像潮水一樣湧來，哈希算法根本來不及反應。結果就是部分端口滿載，部分端口閒置的資源錯配。相比傳統ECMP方案，新的端到端負載均衡方法可將網絡帶寬利用率提升最高38%，模型訓練任務時長縮短超過3%。38%的帶寬提升和3%的訓練加速，聽起來不算驚人，但在十萬卡集群裡，3%可能意味著節省數百萬美元的電力成本和數週的研發週期。而這些困境的底層原因是因為，芯片算力的增長速度，已經遠遠超過了數據在芯片之間搬運的速度。這也就造成了網絡已成為制約AI集群發展的核心因素。

重新思考AI需要的網絡面對這樣的矛盾，一個最本能的反應是堆硬件，堆更高速的光模塊，堆更大端口的交換機，堆更粗的銅纜。從400G到800G再到1.6T，接口速率每隔一兩年就翻一倍。但這條看似最直接的路，正越走越窄。對此，是德科技網絡應用安全部門技術經理楊益鋒表示，當前帶寬翻倍的速度，遠遠追不上模型規模翻倍的速度。一個典型的大語言模型，參數量從千億級到萬億級只用了不到兩年，而光模塊從400G迭代到800G再迭代到1.6T，每一次躍進背後都是漫長的產業鏈協同。更關鍵的是，帶寬翻倍帶來的成本、功耗和散熱壓力是指數級增長的，到了某個臨界點之後，每提升1G帶寬所付出的代價會讓任何財務總監都皺眉頭。

與此同時堆硬件也帶來了ROI的問題。楊益鋒告訴我們，不少企業在落地AI網絡時，都踩過同一個坑：為了提帶寬買了一批最先進的高速交換機和高性能光模塊，興致勃勃地上架，結果一跑大模型訓練，算力利用率遠沒達標。一位互聯網大廠的基礎設施負責人曾對我們表示，設備採購花了幾個億，實際跑起來發現，三分之一的算力都損耗在網絡等待上，相當於每三臺GPU就有一臺在空轉。造成這種情況主要是因為：AI網絡的性能瓶頸，往往不在設備本身的標稱規格上，而在於流量調度機制的精細度。你可以把帶寬修到400G、800G，但如果流量調度依然靠“蠻力”，大部分帶寬依舊是被浪費的。

也正是在這個背景下，行業開始從堆硬件轉向了，如何通過協議、軟件等方式，讓數據流跑得更順暢。傳統的TCP/IP網絡，是為人與人通信設計的，比如網頁請求、郵件發送、文件下載，這些場景中流量隨機且不著急，丟幾個包大不了重傳。但AI網絡完全不同，GPU集群內部通信是“機器與機器”的對話，週期性極強、同步要求極高。在大規模模型訓練中，所有GPU必須在一個同步週期內完成全部梯度交換，任何一個慢節點都會拖垮整個集群。這就形成了“木桶效應”，在AI網絡裡，一個微小的網絡抖動，就是那塊最短的板。在此背景下，LLR與CBFC這兩個原本並不受關注的技術開始被AIDC運營方關注。

其中，LLR把重傳機制下沉到鏈路層，讓交換機自己發現丟包、自己重傳，不等上層發號施令，把恢復時間從毫秒壓到微秒級，解決了傳統IDC網絡中，因一個數據包丟失引發的重傳延遲。CBFC則可以理解為是一個“網絡紅綠燈”系統。發送端在發數據之前，先確認接收端有足夠的緩存空間再發，避免數據發過去了對方裝不下、只能丟棄。聽起來很基礎，但在大規模AI集群裡，成百上千個發送端同時向一個接收端匯聚流量時，這套紅綠燈系統的協調精度直接決定了網絡的通暢程度。今年3月，是德科技與Broadcom在OFC 2026上完成了業界首個基於超以太網聯盟規範、在800GE線速下實現LLR和CBFC的公開互操作性演示。

這標誌著這兩項技術正式從實驗室協議走向了真實的互聯互通。但從協議到大規模現網部署，還有很多路要走。不同廠商的設備、不同的網絡拓撲、不同的工作負載，都需要精細化的參數調優才能讓LLR和CBFC真正發揮威力。協議寫好了，標準通過了，但到了真實的生產環境，每一個參數設置都可能影響網絡性能的成敗。更關鍵的是，調參的前提是得先知道網絡到底哪裡出了問題。而這則引出了AI網絡驗證這個最容易被忽視的命題。測通非真通網絡環境搭建好了，如何確認它真的能跑順了？很多企業在服務器買回來了，交換機上架了，線也插好了，標準測試跑了一遍，顯示帶寬達標、延遲正常，一切看起來完美。

但一跑大模型訓練，問題就來了：要麼頻繁掉線，要麼速度上不去，要麼莫名其妙地卡住。對此，楊益鋒表示，這個問題主要出在了驗證環節。他從Scale-Up、Scale-Out和Scale-Across三個維度，分享了是德科技對AI網絡驗證的些許看法。楊益鋒認為，這三個環節中，最容易被企業忽視的就是Scale-Up環節，“Scale-Up發生在機櫃內部，距離短、看起來技術含量不高，很多企業採購完服務器，插上線就認為Scale-Up網絡已經Ready了，”楊益鋒進一步指出，“但恰恰是這些短距離的連接，承載著最密集、最頻繁的數據交換。

GPU之間每一次參數同步、每一次梯度聚合，都要通過Scale-Up網絡完成。一旦這裡出了問題，整個集群的性能都會打折扣。”更麻煩的是，Scale-Up涉及的技術正在快速迭代，LLR和CBFC的關鍵應用場景就在這個維度。與此同時，Scale-Out和Scale-Across方面企業依舊面臨著不少的挑戰。Scale-Out涉及大量交換機之間的互聯，拓撲復雜、路徑繁多，傳統驗證方式，驗證不了真實負載下的性能；Scale-Across則面對長距離傳輸的延遲和可靠性問題，在跨數據中心協同訓練的場景下，光速本身都成了限制因素。

是德科技的一項調查顯示，95%的運營商認為真實工作負載測試對AI網絡驗證至關重要。但現實是，很多企業在部署AI網絡時，依然在用傳統數據中心的測試方法，比如跑幾個標準benchmark，測一下帶寬和延遲，就認為沒問題了。等到真正跑大模型訓練時，才發現問題層出不窮。這是因為傳統數據中心的網絡，承載的是可預測的流量，比如網頁瀏覽、視頻播放、文件下載等流量模式相對穩定。但AI網絡的流量模式突發性強、東西向流量巨大、對丟包和延遲極度敏感。在AI訓練中，哪怕一個數據包的丟失，都可能引發連鎖反應，最終導致整輪訓練失敗。

楊益鋒坦言，未來五年AI集群的東西向流量將增長10倍或更多，等GPU到位再測試網絡的舊模式根本無法擴展。企業如果不能及早建立系統級的網絡驗證能力，堆再多的硬件也只是擺設。值得注意的是，這種現象在推理場景中尤為明顯。過去的大模型推理，用戶提交一個任務，系統批量處理，等個十幾秒甚至幾十秒出結果，大家都能接受。但現在，AI正在嵌入對話系統、實時翻譯、自動駕駛、金融高頻交易等場景都要求AI做出毫秒級響應。在推理場景中，有兩個關鍵時延指標：首Token時延（用戶發出請求到收到第一個輸出Token的時間）和Token間時延（後續Token之間的間隔）。

“首Token時延決定了用戶有沒有反應的感知，而Token間時延決定了整個交互過程的流暢度。如果Token間時延不穩定，對話就不會流暢，用戶體驗瞬間崩塌。”楊益鋒指出。這也就意味著網絡不僅要快，還要穩。傳統網絡可以容忍偶爾的抖動（視頻卡一下，文件下載慢幾秒，不會太影響體驗）。但在實時推理場景下，每一次抖動都會直接轉化為用戶感知到的“卡頓”。而網絡驗證的目標，也從能不能跑到標稱速率，變成了在最惡劣的流量衝擊下，時延和抖動能不能穩定在承諾範圍內。當十萬卡集群成為標配，實時推理滲透進每一個日常應用，網絡就不再只是傳輸流量的管道，而是決定AI算力能否真正釋放的“命門”。

網絡也不再只是簡單的堆硬件，只有搭建起真正可靠的系統，才能讓網絡不再是卡住AI發展的阻礙。（文｜Leo張ToB雜談，作者｜張申宇，編輯丨楊林）