北京
在硅谷一場關于下一代AI基礎設施的閉門討論中，一位網絡架構師在白板上畫下這樣一句話：“以太網當初的設計目標，和今天超大規模訓練集群的需求幾乎是反著來的。” 這句話當場引發一陣沉默。他所指的，正是剛剛在OCP社區正式浮出水面的ESUN方案——Ethernet for Scale-Up Networking，一次試圖讓以太網從“盡力而為”躍遷到“無損、低時延、確定性傳輸”的集體改造。
這位架構師后來在技術備忘錄里解釋了自己的觀察：每一代AI基礎設施都在重新定義“網絡”二字的含義。在當下的訓練集群中，加速器數量從幾百顆急速擴張到數十萬顆，互連技術已不再是配角，而是決定系統吞吐量、利用率和單token成本的“第一元素”。加速器之間并不只是搬運數據，而是在每一步訓練中基于這些數據進行同步。只要一小部分流量遲到，昂貴的算力就得空轉等待。正是這個現實，逼著業界不得不重新審視網絡本身的結構。
ESUN正是在這種壓力下誕生的——一個由OCP掌管的開放項目，目標就是對以太網進行深度定制，使其能適配AI加速器之間那種緊耦合、高并發的通信模式。它的訴求非常明確：減少乃至消滅丟包，讓時延變得可預測，讓傳輸過程呈現出確定性。換句話說，讓加速器感覺彼此像是插在同一個巨型機器內部，通信如同本地操作，網絡本身最好“消失”掉。
要想理解這種改造為何必要，就得回頭看清楚經典以太網的“盡力而為”本性。它天然容忍偶發的丟包、重傳和抖動，因為大多數云負載能把這些波動消化掉。但AI訓練完全不同。它的性能由“尾部時延”決定——也就是集合通信操作中最慢的那個數據包。即便99%的流量準時到達，只要有一個包遲到，整個全歸約（all-reduce）操作就可能被堵住，整群加速器跟著停擺。丟包更會把問題放大：重傳引入的額外延遲和不確定性會像漣漪一樣擴散到整個同步負載里。當集群規模膨脹到數十萬顆加速器，這種低效就會直接轉化為帶寬浪費、功耗飆升和基礎設施成本失控，純粹是算不過賬的事情。
OCP文檔中詳細拆解了這一矛盾。以太網其實內置了一些擁塞控制工具，比如優先級流控（PFC）和顯式擁塞通知（ECN），但它們原本是為通用數據中心設計的，根本對付不了AI計算艙（AI pod）里那種緊耦合、對時延極度敏感的流量模式。在橫向擴展（scale-up）的距離和數據速率下，這工具集暴露出三個結構性的缺陷。首先是協議開銷。標準IP報文頭部就吃掉28到48個字節。在橫向擴展流量里，消息往往又短又密，這部分開銷直接侵蝕可用吞吐量。其次是沒有鏈路級的錯誤恢復。除了前向糾錯（FEC），以太網依賴上層傳輸協議來修復錯誤，這在時延上的代價要比鏈路級恢復高出好幾個數量級。最后是粗粒度的擁塞控制。PFC是鏈路全停的機制，無法區分不同的流量類別或虛擬通道，結果就是出現頭部阻塞，而AI負載最脆弱、最受不了的恰巧就是這種阻塞。
正是這些缺口，把一部分架構師推向了專用的互連技術。而ESUN所代表的開放路徑，則試圖用另一種方式擦掉白板上那句令人沉默的話。它的邏輯并不復雜：摒棄以太網為通用云環境準備的那些讓步，重新圍繞AI加速器之間真實的通信行為來設計報文格式、流控機制和錯誤恢復策略，在保留以太網規模優勢和生態成本優勢的同時，把幾個關鍵缺陷硬碰硬地補上。至于這條路能不能跑通，目前社區內部既充滿探索的興奮，也夾雜著審慎的疑問。畢竟，從“盡力而為”到“確定性傳輸”，要改的不只是協議棧，還有二十年積累下來的工程假設。
一位長期跟蹤互連技術的工程師在評價ESUN時打了個比方：“這就好比公路本來是為汽車修的，現在突然要跑磁懸浮列車。路還是那條路，但路面和調度系統都得重新鋪。” 他的困惑很有代表性：開放社區能否在足夠短的時間內走到落地那一步，還是會像過去幾輪以太網增強嘗試那樣，被訓練成本這個硬指標直接篩掉？目前還沒有答案。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
