下一個HBM：HBF，能行嗎？

公眾號記得加星標??，第一時間看推送不會錯過。

前言

高帶寬閃存 (HBF：High Bandwidth Flash) 的出現，旨在解決人工智能的內存瓶頸問題。其理念是將 NAND 閃存像 HBM 一樣堆疊起來，從而在提供 HBM 級別帶寬的同時，實現 16 倍的容量提升。SK 海力士和閃迪正在聯合開發這項技術，目標是在 2026 年底推出樣品。從表面上看，它似乎是解決 LLM 推理內存容量問題的完美方案。

然而，對SK海力士研究人員發表的H3論文（論文名稱：H3: Hybrid Architecture using High Bandwidth Memory and High Bandwidth Flash for Cost-Efficient LLM Inference）進行深入分析后發現，HBF在實際應用中面臨的障礙遠比最初預想的要大得多。本文從半導體工程師的角度出發，探討了H3架構的假設和局限性，回顧了HBF在商業化過程中將面臨的技術和經濟挑戰，并考察了業界目前正在開發的替代技術方案。

H3 中只讀工作負載的假設在實際的 LLM 推理場景中非常有限。克服 NAND 閃存的根本物理限制（延遲相差 1-2 個數量級）需要 40MB 的 SRAM 緩沖區、DRAM 和復雜的控制器，這削弱了最初“廉價 NAND”的承諾。生產良率、散熱管理和可靠性驗證等實際障礙比預期更高。CXL 內存、HBM4 和軟件優化等替代方案正在更快地走向成熟。

為了方便大家了解HBF，在文章最后我們還將附上SK海力士這篇文章的翻譯參考。

HBF 的背景

人工智能引發的內存容量危機

AI工作負載的瓶頸不再是計算性能。為了跟上NVIDIA H100 989 TFLOPS的計算能力，內存必須以同樣快的速度提供數據。HBM3以819GB/s的帶寬和100ns的訪問延遲滿足了這一要求，但它存在一個關鍵弱點：容量。每個GPU（B200）的最大容量僅為192GB，對于在單個GPU上運行像Llama 3.1 405B（FP8模式下約為405GB）這樣的大型模型來說，HBM的容量遠遠不夠。

更大的問題在于鍵值緩存（KV cache）。對于擁有 100 萬個token上下文（context）的 Llama 3.1 405B 版本，僅預計算的鍵值緩存就需要約 540GB。如果擴展到 1000 萬個令牌，則需要 5.4TB。僅使用 HBM 來處理如此龐大的緩存需要數十個 GPU，這將導致成本和功耗成比例地增加。

這就是 SanDisk 和 SK 海力士所稱的“內存墻”及其提出的 HBF 方案的背景。

HBF的優勢顯而易見：將NAND閃存與類似HBM的TSV（硅通孔）技術堆疊，即可在相同帶寬（8TB/s）下提供HBM 16倍的容量（約3TB）。由于NAND的成本約為HBM的五分之一，因此經濟效益也相當可觀。表面上看，這似乎是一個完美的解決方案。但我們需要更深入地分析。

H3論文的方法

混合架構和核心假設

H3 架構概述

SK海力士的研究人員提出的H3（采用HBM和HBF的混合架構）承認HBF單獨使用時的局限性，并采用了一種結合HBM和HBF的混合方法。其核心設計工作原理如下：

HBM 直接連接到 GPU 的底層，以實現最大帶寬。HBF 通過 HBM 基片以菊花鏈方式連接。HBM 基片內部的地址解碼器和路由器將 HBM 和 HBF 的訪問隔離。一個 40MB 的基于 SRAM 的延遲隱藏緩沖區 (LHB) 可以緩解 NAND 閃存的訪問延遲。

在這種架構中，GPU 通過統一的地址空間將 HBM 和 HBF 都視為主內存。只讀數據（模型權重、預計算的鍵值緩存）存儲在 HBF 中，而動態生成的鍵值緩存則保存在 HBM 中。

核心假設

一、H3 的性能聲明基于幾個重要的假設：

工作負載假設：大多數LLM推理數據是只讀的。模型權重和共享的預計算KV緩存在整個推理期間不會改變。

訪問模式假設：LLM推理是確定性的、順序的。因此，所需數據可以被準確預測并提前預取。

性能假設：40MB SRAM 緩沖區達到足夠高的命中率（論文中沒有明確說明，但隱含地要求 80% 以上），使得 HBF 的 20μs 延遲大部分時間都不會被察覺。

延遲隱藏假設：由于 LLM 推理受限于內存帶寬，因此 HBF 訪問的跳延遲可以充分隱藏。

成本假設：由于 NAND 芯片價格低廉，即使加上額外的組件（SRAM、DRAM、控制器、TSV），整個系統與僅使用 HBM 的系統相比仍然經濟。

該論文的仿真結果令人印象深刻。在 100 萬個token的情況下，吞吐量提升了 1.25 倍；在 1000 萬個令牌的情況下，吞吐量提升了 6.14 倍。每功耗吞吐量最高可達 2.69 倍。即使將 HBF 帶寬減半，其性能仍然優于僅使用 HBM 的架構。

但只有在滿足上述所有假設的前提下，才能取得這些結果。而問題就出在這里。

假設的局限性和技術可行性問題

只讀工作負載假設的局限性

該論文將模型權重和共享的預計算 KV cache歸類為“只讀”（read-only），但這種假設在實際生產 LLM 服務中有多有效？

一、模型權重的現實意義：

微調和 PEFT：在生產環境中，像 LoRA 和 QLoRA 這樣的參數高效微調方法很常見。適配器權重雖然很小，但更新頻繁。

模型版本控制：A/B 測試或逐步推廣方案涉及同時提供多個模型版本。HBF 如何處理模型切換？

量化變化：在 INT8、FP8 和 FP16 之間動態切換是一種常見的生產優化技術。

二、KV Cache的現實情況：

預計算緩存的范圍：本文提出的緩存增強生成（CAG）是一個有效的用例，但它僅涵蓋了整個LLM推理的一小部分。像ChatGPT和Claude這樣的通用對話服務會為每個請求生成新的KV Cache。

緩存失效：當共享文檔更新時，如何刷新預先計算的緩存？鑒于 HBF 的寫入耐久性較低，這是一個關鍵問題。

緩存淘汰：管理數百 GB 的共享緩存池需要 LRU 等替換策略，這涉及到寫入操作。

二、NAND的物理極限：一道無法逾越的障礙

即使只讀假設成立，仍然存在一個更根本的問題。NAND 單元和 DRAM 單元之間的延遲差異并非架構技巧可以解決的問題。這源于物理定律的差異：

DRAM單元：讀取和寫入電容器中的電荷。僅需電開關操作。10-20納秒。

NAND單元：通過隧穿效應將電子移動到浮柵。需要高電壓和較長時間，耗時25-100微秒。

這可是1到2個數量級的差距。這也是英特爾傲騰（3D XPoint）無法取代DRAM的根本原因。即使傲騰的延遲只有約100納秒，也無法與DRAM的10-20納秒相媲美。而HBF的延遲只有20微秒？這可是1000倍的差距。

40MB 的 SRAM 緩沖區可以“緩解”這種差異，但并不能“解決”它。一旦發生 SRAM 未命中，這種差異就會完全暴露出來。

換句話說，“純只讀”工作負載在實踐中非常有限，即使保證只讀，也無法克服NAND閃存的物理延遲限制。本文的仿真代表的是一種理想化的場景。

成本結構真相

“廉價NAND”陷阱

HBF的支持者強調“NAND晶圓的成本遠低于HBM晶圓”。沒錯。單就NAND芯片本身而言，它肯定比HBM芯片便宜。但總成本呢？

對于HBM而言，主要成本在于內存芯片、TSV堆疊和封裝。控制器集成在GPU內部，無需單獨的緩沖區或中間層。其結構相對簡單。

HBF技術以廉價的NAND閃存芯片為基礎，但這并非終點。為了彌補NAND閃存的低延遲，它需要40MB的SRAM緩存。這并非小型緩存，而是容量巨大的高速內存。SRAM的單位面積成本遠高于NAND閃存。

此外，還需要單獨的DRAM來運行FTL（閃存轉換層）。就像SSD控制器存儲元數據一樣，HBF需要工作內存來進行地址映射和損耗均衡。這部分DRAM會增加成本。

TSV堆疊和鍵合本身就是一個成本高昂的工藝。TSV需要在硅片上垂直鉆出微小的孔，然后用金屬填充。這需要昂貴的設備和精確的工藝控制，任何一個錯誤都可能導致整個芯片缺陷。HBM采用相同存儲芯片的同質堆疊，因此工藝相對標準化。HBF采用異質堆疊，混合使用NAND、SRAM和控制器邏輯芯片。

對具有不同特性的芯片進行對準和鍵合要困難得多。它們的膨脹系數、電性能和可靠性要求各不相同。這顯著增加了工藝復雜性，直接導致良率降低和成本上升。諸如鉆孔硅通孔 (TSV) 時芯片開裂、鍵合過程中錯位或熱應力導致的分層等問題發生的可能性也隨之增加。

封裝和測試也變得更加復雜。對于HBM來說，內存訪問測試是主要的驗證項目。對于HBF來說，則需要驗證SRAM緩沖區命中率、FTL精度、損耗均衡算法、ECC（糾錯碼）運行情況、垃圾回收效率等等。這本質上是SSD控制器級別的復雜性。

管理所有這些功能的控制器邏輯本身的成本也不容忽視。HBM 只是一個簡單的內存接口，但 HBF 需要一個復雜的控制器來執行復雜的地址轉換、預取、緩存管理、損耗均衡和垃圾回收等操作。

更重要的是， HBF 架構存在開發成本和風險。它是一種全新的架構，需要大量的研發投入和時間，包括標準化工作、軟件生態系統構建和客戶驗證。HBM 架構已經完成了所有這些步驟，產量穩定，生態系統也已成熟。而 HBF 架構則必須從零開始。

早期生產的低良率也至關重要。HBM 最初良率低，單位成本高，但經過幾代改進后逐漸提高。HBF 采用比 HBM 更復雜的異構堆疊結構，因此初始良率可能更低。如果良率減半，成本實際上會翻倍。

軟件集成成本也不容忽視。PyTorch、TensorFlow、CUDA 以及所有 AI 框架的設計都基于 HBM 和 DRAM。要高效利用 HBF 的 SRAM 緩沖區，需要在軟件層面優化內存分配策略、數據放置、預取提示等。這需要大量的工程資源。

因此，“NAND閃存價格低廉”的說法固然沒錯，但“HBF系統價格低廉”的說法仍需驗證。從廉價的材料開始，所有使其成為實用產品的因素都會推高總成本。HBF要證明其經濟優勢，不僅需要證明其每GB的價格優勢，還需要證明其在實際工作負載下的總擁有成本（TCO）。

替代技術解決方案和市場動態

HBF計劃在2026-2027年進行樣品測試，而其他技術已經在快速成熟。業界正以不同的方式解決內存容量擴展的同一問題。

HBM4：常規進化的力量

SK海力士、三星和美光正集中精力研發HBM4。預計量產時間：2026年。

帶寬：每立方體 1.5TB/s（比 HBM3e 提升 50%）

容量：每塊 32-48GB（采用改進的堆疊技術）

可靠性：保持已驗證的 HBM 可靠性

生態系統：與現有軟件棧完美兼容

如果單GPU容量達到384GB（8個48GB顯存單元）成為可能，HBF的“容量優勢”就會縮小。此外，HBM4在延遲、可靠性和生態系統方面都已得到驗證。

HBM-PIM（內存內處理）：三星的 HBM-PIM 技術在內存內部執行簡單的操作（向量加法、激活），從而減少數據傳輸，提高有效帶寬。它比 HBF 技術更具創新性，同時又依托于現有的 HBM 生態系統。

CXL 內存：可擴展性的新范式

Compute Express Link (CXL) 是一種通過 PCIe 連接 CPU/GPU 和內存的標準。CXL 2.0/3.0 支持內存池化：

容量擴展：多臺服務器訪問共享內存池。可實現TB級擴展。

靈活性：只分配所需資源。提高資源利用率。

帶寬：CXL 3.0 基于 PCIe 6.0，傳輸速度為 256GB/s（x16 通道）。雖然低于 HBF，但其容量擴展性遠勝于 HBF。

生態系統：英特爾、AMD、英偉達均支持。行業標準。

三星、SK海力士和美光已經開始量產CXL內存模塊。這滿足了HBF所針對的“大容量內存擴展”需求，但方式有所不同。

軟件優化：減少問題本身

除了通過硬件增加內存外，通過軟件減少內存使用量的方法也在快速發展：

FlashAttention-3：優化鍵值緩存訪問模式，降低內存帶寬需求。FlashDecoding++ 將長上下文推理的延遲降低至原來的三分之一。

分組查詢注意力（GQA）：被 Llama 3 等最新型號采用。在保持性能的同時，將 KV 緩存大小減少 4-8 倍。

量化：FP8 和 INT4 量化可將內存占用減少一半甚至更少。NVIDIA H100/B200 原生支持 FP8。

vLLM、TensorRT-LLM：優化內存管理的推理引擎。分頁注意力機制減少內存浪費，連續批處理提高內存利用率。

這些軟件優化無需硬件投資即可降低內存壓力。等到 HBF 投入生產時，我們可能根本就不需要那么多內存了。

市場中的不同戰略選擇

SanDisk 和 SK 海力士在 HBF 技術研發方面處于領先地位。有趣的是，其他主要內存廠商選擇了不同的技術路線：

三星：專注于HBM4和HBM-PIM的研發。尚未發布HBF官方公告。

美光：開始供應HBM3e內存。擴大CXL內存產品線。未提及HBF內存。

NVIDIA：B200、GB200路線圖采用基于HBM3e和NVLink的內存擴展策略。

AMD、英特爾：專注于構建CXL生態系統。

這表明業界正試圖通過不同的技術途徑解決同一個“大容量內存擴展”問題。HBF 是一種基于 NAND 的創新方案，HBM4 是對成熟技術的逐步改進，而 CXL 則專注于系統級可擴展性。每家公司似乎都根據自身的技術能力和市場定位選擇了最佳策略。

最終哪種方法能在市場上勝出，將取決于實際的生產績效、經濟效益和客戶接受度。

HBF 為何依然重要

存儲器公司的平臺戰略

盡管HBF面臨諸多挑戰，但這項技術之所以備受關注，背后是存儲器行業根本性的商業戰略轉變。傳統上，存儲器公司是商品供應商。無論是DRAM還是NAND，它們都按照標準化規格生產，并通過價格競爭來獲取市場份額。這種模式的問題在于難以實現差異化和利潤率低。

HBM的出現開始改變這種格局。HBM不僅僅是一種內存芯片，而是一個需要與GPU緊密集成的系統組件。它需要復雜的工程設計，包括TSV堆疊、散熱管理、電源管理以及與GPU的接口優化。這為內存公司提供了提供更高價值產品和獲得更高利潤的機會。

HBF是這一趨勢的延伸。它不僅提供內存，還提出了一種重新設計整個內存層次結構的解決方案。HBF系統是一個復雜的平臺，集成了NAND閃存、SRAM緩沖器、DRAM、控制器和接口邏輯。這使得內存公司能夠：

在系統架構層面與客戶協作

將影響力擴展到軟件棧（預取提示、數據放置優化等）

除了簡單的價格競爭之外，還要創造技術差異化。

積累知識產權和技術訣竅以提高準入門檻

三星的HBM-PIM也遵循同樣的理念。通過在內存內部添加計算功能，內存公司從單純的存儲設備供應商轉型為計算架構的一部分。美光的CXL內存與之類似，它是一種平臺解決方案，改變了服務器系統管理內存的方式。

從這個角度來看，HBF 的技術挑戰并不一定意味著項目失敗。即使 HBF 最終未能取代 HBM 在通用 AI 加速器市場的地位，內存公司也能從中獲益：

異構存儲器堆疊技術

使用NAND作為存儲器的專業知識

與GPU/AI加速器供應商的系統級協作經驗

可用于未來平臺產品開發的知識產權積累

SK海力士與閃迪合作開發HBF技術，正是在此背景下展開的。SK海力士在DRAM和HBM領域占據主導地位，而閃迪則在NAND領域遙遙領先。此次合作是一項戰略舉措，旨在探索存儲技術融合和平臺化，超越單一產品的成功模式。

歸根結底，HBF 不僅僅是“容量比 HBM 更大的內存”，它更是內存行業從商品化業務向平臺化業務轉型的一個例證。無論這款產品最終能否在市場上取得成功，這一轉型方向本身對于內存行業的長期生存戰略都至關重要。

科技的承諾與現實的壁壘

高帶寬閃存最初帶來了一個極具吸引力的承諾：擁有 HBM 級別的帶寬、16 倍的容量以及低廉的 NAND 成本。它看起來似乎能夠一舉解決人工智能的內存瓶頸問題。

但深入分析SK海力士研究人員撰寫的H3論文，就會發現要兌現這一承諾需要付出怎樣的代價：

物理限制：NAND 單元 1-2 個數量級的延遲差異無法通過架構設計來克服。40MB 的 SRAM 緩沖區只是權宜之計，并非根本解決方案。

復雜性爆炸：在“廉價的 NAND”上添加 40MB SRAM、數十 GB DRAM、復雜的 FTL 控制器和困難的 TSV 堆疊，使得整個系統一點也不廉價。

脆弱的假設：H3 假設的純只讀工作負載和確定性訪問模式在實際生產中極其有限。

可靠性問題：NAND 閃存在 GPU 熱環境下的老化、讀取干擾和耐久性問題能否滿足生產要求，目前尚不清楚。

市場冷漠：由于主要參與者保持沉默，而替代技術正在迅速成熟，HBF 的市場定位看起來不明朗。

這是否意味著HBF會失敗？

不。SanDisk和 SK 海力士的技術能力毋庸置疑。他們會在 2026-2027 年的樣品階段證明這項技術有效。但“有效”和“成功”是兩個不同的問題。

HBF的未來很可能是：

針對高度專業化的CAG工作負載，提供有效的利基解決方案

在一些對功率和容量平衡要求極高的特殊市場，例如邊緣人工智能設備。

這是旨在彌補“HBM 和 SSD 之間的差距”的補充方案，而不是 HBM 的替代品。

技術始于美好的愿景，但必須克服現實的重重阻礙才能走向市場。HBF 目前就正面臨著這道障礙。

H3：面向低成本大語言模型推理的 HBM+HBF 混合架構

摘要

大語言模型（LLM）推理需要海量內存來處理長序列，而高帶寬內存（HBM）的容量限制成為一大挑戰。高帶寬閃存（HBF）是一種基于 NAND 閃存的新型存儲器件，其帶寬可與 HBM 媲美，且容量大幅提升，但同時存在訪問延遲更高、寫入耐久性更差、功耗更大等缺點。本文提出一種混合架構 H3，旨在充分發揮 HBM 與 HBF 各自的優勢，實現高效協同利用。

該架構將只讀數據存儲在 HBF 中，其余數據存放在 HBM 中。在相同 GPU 數量下，搭載 H3 的系統可同時處理更多請求，使其非常適用于大語言模型推理中的海量只讀場景，尤其是采用共享預計算鍵值緩存的場景。仿真結果表明，搭載 H3 的 GPU 系統，其單位功耗吞吐量最高可達純 HBM 系統的 2.69 倍。該結果驗證了 H3 在處理含海量只讀數據的 LLM 推理時所具備的成本效益。

引言

大語言模型（LLM）持續發展，已從簡單的聊天機器人逐步演進為科研助手、智能體 AI 與多模態 AI 。在這一發展過程中，大語言模型推理所需的序列長度急劇增長，例如最新的 Llama 4 已支持最長達 10M 量級的序列長度。目前已有大量研究致力于高效處理這類超長序列，以及面向多請求共享的長序列數據設計預計算鍵值緩存（KV cache）。當請求到達時，這些預計算的 KV cache僅被讀取而不執行寫入操作。在 LLM 推理中以這種方式處理極長序列需要極大的內存容量，并會產生大規模的 KV cache讀取。以 Llama 3.1 405B 推理為例，1M 和 10M 長度的共享預計算 KV cache所需容量分別約為 540GB 和 5.4TB，僅存儲這些數據就需要數十塊 GPU。

從硬件角度看，高帶寬內存（HBM）的容量難以滿足 LLM 推理中不斷增長的數據量。為彌補 HBM 的容量短板，研究人員提出了高帶寬閃存（HBF）：它通過垂直堆疊 NAND 閃存來模擬 HBM 的結構。HBF 可提供與 HBM 相近的帶寬，且容量遠大于 HBM，但同時也存在訪問延遲更高、寫入耐久性更差、單位比特功耗更高等缺點。因此，需要能夠揚長避短、充分發揮 HBF 優勢的子系統架構與應用場景。

本文結合 HBF 的優缺點，提出一種可高效利用 HBF 的混合架構。

本文主要貢獻如下：

提出H3混合架構，可高效協同利用 HBM 與 HBF；

探索與 H3 高度適配的應用場景；

通過基于仿真的性能評估，驗證 H3 的成本效益。

研究動機

A. 海量只讀應用場景

在大語言模型（LLM）推理過程中，許多數據類型呈現只讀特性。例如，LLM 模型權重參數會被反復讀取。以 Llama 3.1 405B 為例，采用 FP8 精度時，模型權重約需 405 GB 存儲空間，這意味著每處理一個批次就會產生 405 GB 的讀取量。

特別地，在近期受到廣泛關注的緩存增強生成（CAG：cache-augmented generation）中，當 LLM 接收到查詢時，會先讀取大規模的共享預計算鍵值（KV）緩存，再進行計算并輸出結果（圖 1）。換言之，共享預計算 KV cache本質上是只讀數據。在 CAG 中，注意力計算采用共享 KV 注意力機制，能夠攤薄內存訪問開銷，因此即使使用較大批次，也不會帶來明顯的時延上升。通過增大批次大小，可以顯著提升系統吞吐量。

然而，受限于 GPU 上高帶寬內存（HBM）的容量不足，在大批次下運行 CAG 面臨巨大挑戰。若將海量的共享預計算 KV cache全部存放在 HBM 中，需要更多 GPU，從而大幅提升成本與整機功耗。

圖 1 緩存增強生成（CAG）的概念，是海量只讀應用場景的典型示例。

B. 高帶寬閃存

如圖 2 所示，高帶寬閃存（HBF）通過垂直堆疊 NAND 閃存裸片，并利用硅通孔（TSV）連接基底裸片與閃存裸片，從而實現高帶寬。目前，多家存儲與閃存廠商正在研發 HBF，目標是達到與 HBM 相近的帶寬，同時提供遠大于 HBM 的容量。由于 HBF 尚未商用，本文基于其目標設計指標展開研究。

圖 2 高帶寬閃存（HBF）的概念。

HBF 的預期優勢：容量可達 HBM 的 16 倍；帶寬與 HBM 相當。

HBF 的預期不足：訪問時延更高（納秒級 vs 微秒級）；寫入耐久性更差；功耗最高可達 HBM 的 4 倍。

由于 HBF 優缺點鮮明，僅適合在特定場景下使用，而本節所述的海量只讀場景正是其理想應用方向。HBF 的大容量可以存放超大 KV cache與模型權重；同時，由于數據為只讀訪問，HBF 寫入耐久性差的缺點不再成為短板。本文后續將提出方案，用以克服 HBF 訪問時延較高的問題。

所提出的架構及其使用方式

A. H3：使用 HBM 和 HBF 的混合架構

如 II-B 中所述，由于 HBF 是一種同時具有優點和缺點的器件，單獨使用存在局限性。因此，我們提出 H3，一種同時利用 HBM 和 HBF 的混合架構，旨在凸顯 HBF 的優勢并彌補其不足。混合架構可以有多種實現方式。例如，一種方法是將 HBM 和 HBF 直接放置在 GPU 的管腳區域旁邊。然而，這種方法的缺點在于，由于 GPU 上的管腳區域空間有限，會減少 HBM 的數量。

為了最大化 HBM 和 HBF 的帶寬，如圖 3 (a) 所示，H3 中的 HBM 連接到 GPU 的管腳區域，并且 HBM 和 HBF 采用菊花鏈連接。在 HBM 基底裸片內部，存儲器訪問通過地址譯碼器與路由器被分為兩條路徑：一條訪問 HBM，另一條訪問 HBF。因此，GPU 可以通過 HBM 基底裸片直接訪問 HBF（圖 3 (b)）。

換句話說，HBM 和 HBF 共同作為 GPU 的主存。由于 HBM 和 HBF 均被用作主存，主機在訪問 HBM 或 HBF 時使用劃分了內存區域的統一地址空間（圖 3 (c)）。

圖 3 H3 架構總覽

在圖 3 (b) 中，假設 GPU、HBM 基底裸片和 HBF 基底裸片通過裸片間（D2D）接口連接，并且 GPU 與 HBM 基底裸片之間的帶寬等于每個基底裸片與核心裸片之間的帶寬。我們同樣假設 HBM 和 HBF 控制器位于各自的基底裸片上。這一點可以根據芯片面積情況進行調整。

B. 使用方式：面向海量只讀數據的大語言模型

H3 適用于具有 II 中所述的海量模型權重和共享預計算鍵值（KV）緩存的大語言模型推理。這些海量且只讀的數據非常適合使用容量大但寫入耐久性有限的 HBF。因此，模型權重和共享預計算 KV cache被存儲在 HBF 中。此外，生成的 KV cache和其他數據被存儲在 HBM 中。圖 4 說明了其工作方式。在圖 4 中，訪問 HBF 時可能會增加跳轉時延，但由于大語言模型推理受內存帶寬限制，跳轉時延可以被充分隱藏。

由于大語言模型推理的數據訪問模式是確定性的，我們期望在深度學習框架的支持下，可以將數據合理分配到 HBM 和 HBF 中。處理某一特定運算可能需要同時使用存儲在 HBM 和 HBF 中的數據。但是，由于運算所需的張量可以被準確預測，因此可以實現張量級調度，從而使得 HBM 和 HBF 之間的爭用可控。

圖 4 在包含海量共享預計算鍵值緩存的大語言模型推理中，HBM 與 HBF 的訪問方式說明

將 H3 應用于海量只讀場景的優勢在于，它支持更大的容量，從而可以在相同數量的 GPU 下實現更大的批次處理。更大的批次處理能夠提升吞吐量，最終在運行大語言模型推理系統時降低成本。將 HBF 用于只讀場景還具有減少垃圾回收和損耗均衡開銷的額外好處。

C. 優化：時延隱藏緩沖區

由于 HBF 本質上基于 NAND 閃存，其訪問時延比 HBM 更長。因此，隱藏其長時延對于將其用作內存至關重要。為了彌補 NAND 閃存的長時延，時延隱藏緩沖區（LHB）—— 一種預取緩沖區 —— 被集成到 H3 的 HBM 或 HBF 的基底裸片中（在圖 3 (b) 中，LHB 位于 HBM 的基底裸片中）。對于大語言模型推理，只有前一層完成后才能處理下一層，并且一層中計算所需的模型權重和 KV cache是預先確定的。

換句話說，大語言模型推理具有確定性和順序性的數據模式。因此，可以提前準確預測計算所需的數據，并通過將計算所需的數據持續載入 LHB 來隱藏 NAND 閃存的時延。為了有效利用 LHB，需要修改深度學習框架以提供預取提示。由于預取提示是確定性的，并且預取數據單元為粗粒度的張量級，預取開銷預計很小。LHB 的預期大小和芯片面積開銷將在后面討論。

四、評估

A. 實驗設置

1）方法：由于 HBF 是處于開發階段的器件，無法進行實際測量。因此，本文基于已在先前研究中得到驗證的解析建模，開發了一款內部仿真器，用于評估搭載 H3 系統的性能。該內部仿真器根據計算時間、數據傳輸時間以及 GPU 之間的通信時間，估算執行時間、吞吐量、單位功耗吞吐量。計算時間基于 LLM 模型的運算量與 GPU 性能進行計算。

HBM 與 HBF 的數據傳輸時間基于 LLM 模型大小、KV cache大小以及器件帶寬進行計算。在計算數據傳輸時間時，通過考慮張量并行（TP）與數據并行，對數據進行劃分與復制以優化性能。此外，GPU 之間的通信時間在假設采用張量并行時所使用的環形全規約（ring all-reduce）的前提下進行計算。

2）工作負載：本文選用 Llama 3.1 405B 作為性能評估的工作負載。所選的 Llama 3.1 405B 具有足夠的代表性，因為其規模足以與最新的前沿大語言模型相當，且預計算 KV cache與上下文窗口長度相關，而與模型權重大小無關。原始的 Llama 3.1 405B 上下文窗口為 128K，為評估長序列處理性能，本文假設其支持 1M 與 10M 長度。本文假設輸入序列長度（ISL）與輸出序列長度（OSL）均為 1K，除 ISL 與 OSL 之外的剩余空間由共享預計算 KV cache占用。在當前實驗環境下，對于 1M 與 10M 場景，共享預計算 KV cache分別占用總容量的約 35% 與 84%。

3）HBF 參數：本文假設所使用的 GPU 為當前最新的 B200。B200 搭載 HBM3e，單 GPU 支持 192GB 容量與 8TB/s 帶寬（每個 Cube 為 24GB、1TB/s）。基于 II-B 中 HBF 的相對性能，本文假設 HBF 容量為 3TB，約為 HBM3e 的 16 倍，帶寬為 8TB/s，與 HBM3e 相同。結合當前 NAND 閃存的單 Cube 容量與單位比特功耗，本文假設 HBM3e 與 HBF 的單 Cube 熱設計功耗（TDP）分別為 40W 與 160W。功耗估算基于當前 NAND 閃存技術。但本文預計，在 HBF 開發過程中通過功耗優化，其功耗將進一步降低。

4）硬件配置：本文假設采用 DGX 風格系統。序列長度 1M 的實驗使用 8 塊 GPU，序列長度 10M 的實驗使用 32 塊 GPU。這些 GPU 數量是純 HBM 場景下運行對應序列長度所需的最小 GPU 數量。因此，在 10M 場景中，GPU 服務器之間的通信通過橫向擴展互聯（如 InfiniBand）實現，而非縱向擴展互聯（如 NVLink）。

B. 實驗結果

1）批次大小：通過將海量共享預計算 KV cache存儲在 HBF 中，HBM 可獲得更多空閑容量，使得搭載 H3 的 GPU 能夠處理更大的批次大小。圖 5 展示了在 1M 與 10M 場景下，可處理的批次大小隨 GPU 數量的變化情況。在圖 5 (a) 所示的 1M 場景中，使用 H3 可處理的批次大小最大為純 HBM 方案的 2.6 倍。類似地，在圖 5 (b) 所示的 10M 場景中，使用 H3 可使批次大小最大達到純 HBM 方案的 18.8 倍。提升吞吐量的因素有多種，但增大批次大小顯然是最重要的因素。

圖 5 基于 GPU 數量的最大批次大小（× 表示因內存容量不足無法運行）

一個值得關注的現象是，搭載 H3 的單 GPU 即可運行 1M 場景，僅需兩塊 GPU 便可運行 10M 場景。這一結果表明，盡管性能會有所下降，但可以以極低的成本處理長序列。

2）吞吐量：處理更大的批次大小可帶來吞吐量的提升。圖 6 展示了每秒token數（TPS）/ 請求，這一吞吐量指標主要由 LLM 推理系統的批次大小與執行時間決定。在 1M 場景下 H3 的吞吐量為純 HBM 方案的 1.25 倍，在 10M 場景下為 6.14 倍。這意味著采用 H3 可在相同執行時間內生成更多token，直接降低 LLM 服務成本。此外，由該結果可預測，隨著序列長度增加，吞吐量差距將進一步擴大。

圖 6 吞吐量與單位功耗吞吐量對比

3）單位功耗吞吐量：為證明盡管增加了功耗更高的 HBF，H3 仍具備更高的成本效益，本文還開展了單位功耗吞吐量評估。單位功耗吞吐量由仿真得到的吞吐量除以總熱設計功耗（包含 GPU 功耗，假設無 HBM/HBF 時為 680W ）計算得到。如圖 6 (b) 所示，盡管搭載 H3 的 GPU 熱設計功耗更高，但其單位功耗吞吐量最高可達純 HBM 方案的 2.69 倍。這些結果表明，H3 可高效低成本地處理海量只讀型 LLM 推理任務。

4）HBF 帶寬降低：盡管本文假設 HBF 帶寬與 HBM 相同，但在產品化過程中的實際問題可能導致其支持更低的帶寬。因此，本文探究將 H3 中 HBF 帶寬減半對性能的影響。圖 6 表明，即使 HBF 帶寬減半，在 1M 場景下 H3 的吞吐量仍優于純 HBM 方案。此外，在 10M 場景下，H3 的單位功耗吞吐量仍為純 HBM 方案的 2.09 倍。對于 H3 而言，由于并非所有數據都存儲在 HBF 中，整體性能不會隨 HBF 帶寬的降低而同比例下降。

C. 時延隱藏緩沖區的芯片面積開銷

為計算芯片面積開銷，首先需要確定 LHB 的容量需求。其由 HBF 的帶寬與訪問時延計算得到。為不間斷地以滿帶寬向 GPU 提供數據，本文采用雙緩沖機制。

CapacityLHB = 2 × BWHBF × LatencyHBF . (1)

容量 LHB = 2 × BW HBF × 時延 HBF . (1)

式（1）中，容量 LHB、BW HBF、時延 HBF 分別表示 LHB 大小、HBF 單 Cube 帶寬與 HBF 訪問時延。根據 IV-A，BW HBF 為 1TB/s。基于公開的 SLC NAND 閃存讀取訪問時延，本文假設時延 HBF 為 20μs。因此，LHB 的容量需求為 40MB。由于當前商用 NAND 閃存產品中觀測到的 20μs 時延在 HBF 商用后預計會進一步改善，LHB 的容量需求預計將低于 40MB。

基于容量需求可計算 LHB 的芯片面積。考慮到未來 HBF 商用時的基底裸片工藝，本文假設采用最新的 3nm SRAM。已知 3nm SRAM 的比特密度為 0.021μm2。因此，40MB SRAM 核的面積為 6.72mm2。假設額外電路帶來 20% 的開銷，總面積估算為 8.06mm2。這約為 121mm2 基底裸片面積的 6.7%，考慮到基底裸片的可用空間，該值處于可接受范圍。作為參考，121mm2 是當前已商用 HBM 的基底裸片面積，預計未來 HBM 與定制 HBM 的面積將進一步增大。

結論與未來工作

本文提出了 H3 混合架構，通過有效整合高帶寬內存（HBM）與高帶寬閃存（HBF），解決了長序列大語言模型推理中 HBM 容量受限的問題。H3 利用大語言模型工作負載的確定性特征對數據進行合理布局：將海量只讀的共享鍵值（KV）緩存與模型權重存儲在 HBF 中，將頻繁訪問的動態生成 KV cache存儲在低延遲的 HBM 中。為緩解 HBF 固有的高延遲問題，本文引入了時延隱藏緩沖區。仿真結果表明，與純 HBM 架構相比，所提架構能夠支持顯著更大的批次大小，且單位功耗吞吐量最高提升 2.69 倍，證明其在構建面向海量只讀數據的低成本高效益 LLM 推理基礎設施方面具有巨大潛力。

H3 是利用 HBF 的多種架構之一。HBM 與 HBF 存在多種協同使用方式（例如 HBM 與 HBF 混合堆疊），在某些場景下甚至可以單獨使用 HBF。因此，未來工作將重點探索能夠充分發揮 HBF 優勢的最優架構，以及適用于 HBF 的其他應用場景。

*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業觀察對該觀點贊同或支持，如果有任何異議，歡迎聯系半導體行業觀察。

今天是《半導體行業觀察》為您分享的第4323期內容，歡迎關注。

加星標??第一時間看推送

求推薦