CXL三種設備形態

CXL從2019年發布1.0版本以來，到2023年11月已經陸續發布了1.1， 2.0， 3.0和3.1版本，如下圖所示。圖中沒有顯示出來的是，在這段時間內，其他的開放一致性互連標準，Gen-Z，OpenCAPI和CCIX，分別于 2021年11月 ， 2022年8月和2023年8月將他們的IP納入到CXL旗下。整個業界朝著一個統一的開放一致性互連標準邁進。

CXL協議發展史

CXL的每個版本都確保后向兼容，但又有其新的特性。這里不對每個特性做詳細介紹，但有必要對每個版本中新增特性所覆蓋的范圍作個簡要說明。 如下圖所示，CXL 1.0/1.1解決的問題是單個節點內，主機和設備之間的內存一致性互連；而CXL 2.0把一致性互連的范圍擴大到了機柜層面，實現了一個機柜上多個節點間內存或其他設備的資源池化；CXL 3.0/3.1進一步將一致性互連范圍擴大到了機柜間，通過拓展CXL Switch路由能力，構建Switch Fabric，實現機柜內/機柜間資源的分離，池化和共享。

CXL協議發展史

觀點辯駁

在簡要了解CXL互連的背景之后，我們再來詳細分析下Dylan Patel的這篇《CXL is Dead In the AI Era》文章中的觀點。文章的整體行文邏輯是從PCIe SerDes IO帶寬效率不高和硅片IO Beachfront面積受限這兩點，推演出 “CXL Will Not Be The Interconnect in The AI Era”，并由此來支撐“CXL is Dead In the AI Era”這樣抓眼球的題目。 可以看出這并不是一個嚴謹的邏輯推演，它有兩個大的方面問題：

●首先，偏差性比較。正如前文所述，CXL并非為AI而生，它首要解決的問題是，主機內存與其他設備內存之間一致性內存互訪的問題，而不是AI所要求的超大帶寬問題。這一目標就決定了CXL協議在設計上的很多選擇。比如，它選擇兼容PCIe并采用其物理層來充分利用其龐大的PCIe生態，實現對最廣泛主機設備的支撐，畢竟絕大部份設備都是通過PCIe接入服務器主機的。也正是因為這樣，CXL在業界迅速得到廣泛認可，并陸續統一了其他開源一致性互連協議如GenZ，OpenCAPI以及CCIX等。 但這種生態上的綁定也意味著CXL的帶寬演進強依賴于PCIe的演進速度。 相比之下，NVIDIA NVLink  專門針對GPU-GPU互連而生，后拓展到GPU-CPU互連(早期的IBM PowerPC及近期的NVIDIA NVLink-C2C)。作為一個私有協議， NVLink可以不必考慮后向兼容以及相應生態成熟的問題，演進速度自然比PCIe更加迅速。 這就好比“一個人走的快，但一群人走的遠”一個道理。 非讓“一群人”和“一個人”比誰走的快，這就是偏差性的比較。

●其次，以偏概全。AI時代，并非所有應用都是AI的。有大量的應用，譬如數據庫事務處理，Web Serving，Java類應用，傳統機器學習，搜索，編譯，加解壓/加解密等等，都需要通用算力來承擔。事實上，依據信通院《2023智能算力白皮書》[1]，到2022年底，全球IDC通用算力規模498EFLOPS，占總算力的76.6%， 而相比之下，智能算力占比為21.9%（剩余部份為超算算力，占比1.5%）。相較于前一年，智能算力以25.7%的速度增長，但需要注意到的是，通用算力的增長同樣達到了25%。 從國內來看， 2022年底，我國總算力規模180EFLOPS，通用算力137EFLOPS， 智能算力 41 EFLOPS，智能算力占總算力的22.8%。按照工信部的規劃[2]，2025年算力總規模達到300EFLOPS，其中通用算力達到189EFLOPS，相較2022年增長52EFLOPS，而智算算力增加64EFLOPS。 這些數據清楚的表明，在AI時代，通用算力依然在成長，依然占據了總算力規模的大部分。不能因為AI應用吸引眼球，而認為它就是算力的全部；也不能因為某項技術在AI應用中效果有限，就認為該技術已經死于這個時代。

算力規模比較。 來源：中國信通院《2023智能算力白皮書》

在解釋了這兩點宏觀邏輯鏈條上的問題之后，我們再來詳細的對文中的論據和觀點進行深入探討。這里我們的目的是指出原文論據中的紕漏和缺陷，從而讓讀者能以更加辯證和批判的角度來看待原文的結論。

●原文論據1: “IO for chips generally must come from the edges of the Chips”，而在GPU上，HBM接口會擠占掉大量的硅片上Shoreline資源，導致留給其他IO的空間非常有限。

○我們先來分析下該論據的前半段：IO真的只能從Chip邊緣出來么？在回答這個問題之前，我們先簡單回顧下集成電路中的IO Pad。IO Pad通?？煞譃镻eripheral IO Pad和Area IO Pad。顧名思義，前者是指放在硅片邊緣的IO Pad。它通常應用在采用引線鍵合（Wire Bond）封裝的芯片上，如下左圖所示。因為需要引線，IO Pad無法利用硅片中間的空間，否則，引線長度過大，強度和電氣特性都會存在問題，因此，IO Pad只能放在硅片的邊緣；而后者是指可以分布在整個硅片平面上的IO Pad。它廣泛應用于Flip-chip Ball Grid Array （FC-BGA）封裝中。相較于前者，它可以提供更高的IO密度，更多的IO引腳數目，因此通常被高性能CPU/GPU所采用。但為保證電源的均勻分布，電源和地線通常通過位于硅片中間的Pad引入。這就造成了用于通信的IO都處在硅片的周圍，形成了我們通常所說的“Beachfront”或者“Shoreline”，其周長和深度決定了信號IO Pad的可用面積。這么看來，原文論據中的說法，除了“edge”的說法有些模凌兩可以外，貌似沒有大問題。但這里有一個紕漏，它并沒有考慮到3D集成封裝所帶來的額外IO空間。與傳統的2D或2.5D封裝不同，通過TSV（Through-Silicon-Via），3D集成可以充分利用硅片的上下兩個平面， 提供更為充足的信號引腳。一些典型的3D集成產品包括AMD的3D V-Cache，Intel的Lakefield CPU等，如圖6所示。事實上，大家所熟知的HBM就是將多個DRAM硅片通過3D集成構建的。有了3D集成，HBM可以直接堆疊到計算硅片之上， 從而將IO數量消耗巨大的HBM接口移到計算硅片的背部，為計算硅片底部其他IO騰出了空間，同時，它也可以避免使用昂貴的Silicon Interposer作為介質來做多硅片封裝。 當然，如何有效的進行散熱是一個主要挑戰。雖然我們現在還沒看到這樣的封裝用于實際的產品中，但SK Hynix已經在做這方面的研究，并計劃在HBM4上實現HBM和計算硅片的直接堆疊[4]。 所以，我們認為這一論據并不普遍成立，原作者并沒有充分考慮到可以通過封裝技術進步來緩解IO空間受限這一挑戰。

IO 在硅片上的排布。 來源： Ultra Librarian

3D V-cache以及Lakefield 3D Foveros集成。 Source：AMD & Intel

●原文論據2：PCIe PHY的單位面積帶寬效率沒有NVLink的高，所以芯片設計者會選擇112G 以太網PHY而不是PCIe PHY。

○首先，我們來看下單位面積的帶寬效率這個指標。 嚴格來說，它可以從兩個不同的角度來定義： 一個是從所需的Shoreline面積，也就是引腳數目的角度來看；另一個是從實現PCIe/NVLink PHY所占用的硅片面積的角度來看。 對前者來說，相應的指標就是單位引腳帶寬。 為做相應的對比， 我們將每一代NVLink和PCIe的具體指標總結在下表中。 這里需要注意的是，在NVLink體系中，每個Link包含了多條lane，而在PCIe體系中1X就指一條lane， 這就解釋了為什么在下表中最后一行，NVLink的單位Link雙向帶寬（BiDir BW/Llink）看上去遠大與PCIe的相應數值。我們認為：合理的指標應該是單條lane上的帶寬，因為對lane的定義NVLink和PCIe是一致的， 都是指TX和RX，兩對差分信號，共四個引線。折合到單位引腳帶寬上，NVLink和PCIe的比較顯示在圖7上。 在時間軸上，我們對PCIe的數據進行了區分，PCIe-Spec與PCIe協議標準發布的時間對齊，而PCIe-Prod是指新的PCIe標準發布后在市場上可以獲得相應產品的時間對齊。通常PCIe-Prod會晚于標準發布時間2-3年左右；而NVLink，因為是私有協議，它發布時通常就以產品的形態出現。 可以看到，NVLink的單位引腳帶寬與同期的PCIe產品相比高大約3倍左右。 因此，原文中所述的NVLink總帶寬比PCIe高7倍并不是一個嚴謹的說法。那么這3倍左右的帶寬密度差距是怎么來的呢？這里面相當一部分來源于PCIe在Gen3上等待了太多時間。 PCIe通常的迭代周期為3～4年，而在PCIe Gen3到Gen4的迭代用了7年。至于為什么花了那么久，江湖上有很多不同的猜測，但都于與技術無關，故這里不再展開。 而正是在這7年中，NVLink完成了1.0的引入和2.0的迭代， 確立了單位引腳帶寬比同期PCIe產品高3倍的優勢，并一直保持到現在。所以兩者的帶寬差距是由于迭代演進的時間節奏不同造成的，并不反映協議設計本身的優劣。 我們再來看看按照第二種角度定義的效率。我們沒法知道NVLink PHY所占用的面積?；诠_信息猜測NVLink4.0采用112G SerDes而NVLink 5.0采用224G SerDes，我們可以找到與112G 以太網PHY進行相關比較的文獻[5]: Intel 針對PCIe 7.0/CXL 4.0進行了早期PHY實現，其面積帶寬密度（GB/s/mm^2）幾乎和在同一工藝下的112G以太網PHY相同，且其線性帶寬密度（GB/s/mm）還比112G以太網提高了25%。這表明112G以太網PHY相較于PCIe 7.0 PHY并沒有帶寬密度上的優勢。 那如果是224G以太網PHY呢？Intel觀察到了在相同工藝下， 224G比112G提升了30%的單位面積帶寬密度和65%的線性帶寬密度，而并非是一般認為的兩倍提升。 綜上所述，PCIe PHY的帶寬密度不一定比112G以太網PHY差，與224G以太網PHY相比，差別也沒像文中所說的那么大。

單位引腳帶寬比較：NVLink vs PCIe。其中PCIe-Spec表示PCIe協議標準發布，PCIe-Prod表示PCIe標準產品化

AI時代的CXL互連：我們的觀點

在分析和辯駁完了Dylan那篇文章的觀點后，我們也來拋一下自己的觀點：我們認為在AI時代CXL和NVLink將共存且協同發展。這個觀點是基于如下兩個方面的原因：

 1. 在GPU-GPU之間的互連領域，高帶寬是剛需，NVLink以其顯著的帶寬優勢加上其封閉私有協議所帶來快速迭代優勢，短期內沒有其他方案可以撼動。 作為一個完整的AI智算系統，還包括了GPU-CPU互連，GPU與擴展內存或存儲的互連，CPU與其他設備間的互連等等。而這些互連中，CXL的開放生態優勢也很顯著。GPU-CPU互連在NVIDIA 的生態中可以通過NVLink-C2C來實現（如Grace-Hopper和Grace-Blackwell之間的互連），在更廣泛x86和ARM生態中，GPU-CPU的互連大概率將采用CXL互連；同樣道理， 在面對有多元供應商的存儲時，當前GPU都是通過PCIe來和存儲設備進行互連，隨著這些存儲設備都將支持CXL。也正是由于這樣的原因，我們認為在不久的將來，NVIDIA的GPU或將其PCIe接口替換成CXL接口。

2. 隨著AI大模型應用逐步落地，推理將占據絕大部分的智算算力，而成本則是AI商業模式是否可持續的關鍵。在GPU上集成更多的HBM，將會使GPU更加昂貴，并不是一個適合推理的低成本解決方案。而使用CXL擴展內存或內存池，將部份HBM/顯存需求卸載到這些內存上，可以構建出一個在滿足SLA條件下的，更加經濟高效的推理解決方案[3]。 我們將這個討論放眼到更長遠和廣泛的產業背景下，我們認為GPU間的開放互連標準正在快速崛起并成為主流：針對Scale-up互連，業界正在組建開放的Ultra Accelerator Link （UALink）標準；而針對Scale-out互連，行業正逐漸團結在Ultra Ethernet Consortium （UEC）旗下。盡管UAL和UEC之間可能存在一些灰色地帶，但有一點是可以肯定的，他們都不會去做主機和設備間的互連，這樣CXL作為主機與設備間互連的地位將更加鞏固和聚焦。下面，我們例舉幾個CXL在AI領域的應用。

a.類GDR和GDS的CXL高效實現

如圖8所示，借助與PCIe Switch和NVIDIA 的ConnectX網卡，NVIDIA 可以實現不同主機的GPU與GPU之間的GPUDirect RDMA（GDR）。相比之下，如果GPU支持CXL 3.0接口，我們可以將PCIe Switch換成CXL Switch，并且無需網卡轉發，便可以通過CXL Peer2Peer實現不同主機GPU之間顯存的互訪。而且，它們之間的訪問無需通過DMA的producer-consumer語義，而是直接通過load/store語義的互訪，極大的降低了軟件開發的復雜度。

基于PCIe的NVIDIA GPUDirect RDMA vs 基于CXL的 P2P

類似的，如圖9所示，借助與PCIe Switch，NVIDIA GPUDirect Storage（GDS）可以無需通過CPU側內存上的Bounce Buffer，實現直接從掛載在PCIe Switch上的SSD上讀取或寫入數據。同樣，如果GPU支持CXL 3.0接口，我們可以將PCIe Switch換成CXL Switch，便可以實現GPU到SSD的直接訪問。而且，這種模式不單單適用于SSD，還可以用到Storage-Class Memory（SCM）等非易失性介質的內存上，實現內存語義的存儲操作。

基于PCIe的NVIDIA GPUDirect Storage vs 基于CXL的Storage方案

b.Retrieval-Augumented Generation （RAG）支持

為解決大模型推理受訓練數據的時效限制的影響，最新主流的ChatBot服務（如ChatGPT 4, Gemini 1.5）以及主流的LLM推理框架（e.g.，NVIDIA TensorRT-LLM）都支持RAG。 不僅如此，RAG可以將強大的通用LLM能力高效擴展到各個垂直專業領域，而無需重新訓練模型。 如下圖所示，RAG的基本工作流程可大體上分成兩部份：首先是依據輸入查詢數據庫，從而獲取與輸入相關的最新上下文信息。這些信息通常存儲在向量數據庫中，以便高效的獲取與查詢信息高度相關的內容；然后，這些相關信息與原輸入信息通過提示詞工程技術構建一個新的Prompt輸入給LLM，從而使大模型的輸出更加準確，專業和具備時效性?？梢钥吹秸麄€RAG流程中，數據庫查詢需要用到CPU，LLM推理需要用到GPU，兩者缺一不可，且都處在關鍵路徑上。 通過CXL來提升數據庫的查詢效率，可以有效降低整個RAG鏈路的時延和總吞吐。 可見，在更大的AI應用系統中，CXL不但沒有死，而且還將發揮至關重要的作用。

RAG和LLM協同工作示意圖. Source: AWS

c.大容量的內存擴展

AI模型發展的一個趨勢是參數的大幅增加，在過去的10年間參數快速增長到GPT4的1.8T MoE模型，即使以FP8存儲，僅模型參數的內存占用量就到達TB以上。同時這種大模型處理過程中，KVcache以及數據預處理的內存占用量也非常大。如果單純依賴GPU上的HBM或者GDDR來保存這些數據，整個AI系統會變得極其昂貴且效率低下，經濟上不可持續。 利用CXL接口的內存擴展，提供低成本、高性能的超大的內存池，其CXL/PCIe接口可以同時滿足CPU和GPU的訪存模式，助力未來的智算系統降低成本，提高效率。

5、總結

我們認為CXL所帶來的服務器可編排和軟件定義，是對服務器乃至數據中心架構的全面重構，將會對數據中心的成本，性能，運維及穩定性都帶來深遠的，積極的影響。如上所述，CXL不僅不會在AI時代變得無關緊要，相反，它會對包括AI在內的各類云端應用帶來更多性能和成本上的紅利。 阿里云服務器團隊在CXL領域與業界一起進行了多年的技術儲備，一直走在業界的前列，我們將在后續的文章中陸續對各項技術進行詳細介紹，敬請關注。

參考文獻：

[1] 中國信通院，“2023智能算力白皮書”，https://roadshow.h3c.com/zl/pdf/2023zhinengsuanli.pdf

[2] 工信部，“算力基礎設施高質量發展行動計劃”，https://www.gov.cn/zhengce/zhengceku/202310/P020231009520949915888.pdf

[3] Adam Armstrong, “What role does CXL play in AI? Depends on who you ask”, https://www.techtarget.com/searchstorage/news/366575974/What-role-does-CXL-play-in-AI-Depends-on-who-you-ask

[4] “3D-stacks HBM memory directly on top of the processing cores”, https://www.tomshardware.com/news/sk-hynix-plans-to-stack-hbm4-directly-on-logic-processors

[5]. “CXL Q&A for AI”, https://members.computeexpresslink.org/wg/Board/document/3445

[6]. Dylan Patel and Jeremie Eliahou Ontiveros, “CXL is Dead in the Era of AI”, https://www.semianalysis.com/p/cxl-is-dead-in-the-ai-era