---
title: "從 GPU 中心轉向記憶體中心：AI 半導體典範的轉變"
locale: zh-hant
category: trends
category_name: "趨勢"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/memory-centric-ai-chips-hbm-hbf-packaging
published_at: 2026-08-17T21:47:47+09:00
---

# 從 GPU 中心轉向記憶體中心：AI 半導體典範的轉變

> AI 系統的瓶頸正從單純的運算效能，轉向儲存與移動資料的能力。隨著 HBM、以 NAND 為基礎的 HBF、客製化基礎晶粒、3D 封裝與光互連相互結合，共同設計加速器與記憶體的記憶體中心運算正迅速崛起。

## Key Points

- 記憶體中心運算並非淘汰 GPU 的概念，而是共同設計運算單元與記憶體階層，以降低資料移動成本的方法。
- 長上下文與同時請求的增加會擴大 KV 快取容量，使整體記憶體容量與分層技術的重要性不亞於 HBM 頻寬。
- HBF 運用 NAND 快閃記憶體的高整合密度，但受延遲時間、寫入壽命與錯誤管理問題影響，更可能補充而非直接取代 HBM。
- 在 GPU 上方或下方垂直堆疊記憶體的架構可縮短布線距離，但也帶來熱密度、良率、供電與冷卻等新限制。
- 客製化 HBM 擴大了記憶體企業對設計的參與，但不會因此消除記憶體價格波動與供應週期本身。

AI 半導體的競爭標準，正從單純的運算次數，擴展至**能以多低的功耗儲存及搬移多少資料**。在大規模 AI 推論中，GPU 並非無法執行運算，而是可能因無法及時取得所需的模型權重與 KV 快取而陷入等待。

這項變化通常被形容為「從以 GPU 為中心轉向以記憶體為中心」。但這並不代表 GPU 將消失或停止發展。更準確地說，是朝向將 GPU、HBM、外部記憶體、儲存設備、網路與軟體共同設計為單一資料搬移系統。

## 什麼是記憶體中心運算

**記憶體中心運算，是為了降低將資料反覆搬運至運算單元的成本，而以記憶體的位置、頻寬、容量及運算功能作為系統設計起點的方法。**

AI 晶片的算術運算吞吐量快速增加，但從晶片外部取得資料的過程相對緩慢，且會消耗大量電力。因此，以下技術也變得同等重要。

- 配置於 GPU 或 AI 加速器附近的 HBM
- 垂直連接記憶體與邏輯的 3D 封裝
- 在基礎裸晶中加入控制或部分運算功能的客製化 HBM
- 利用 CXL 進行記憶體擴充與池化
- 透過寬介面連接 NAND 快閃記憶體的 HBF 構想
- 旨在降低晶片與伺服器之間傳輸功耗的光互連
- 在靠近資料的記憶體端進行處理的 PIM 與 near-memory computing

換言之，「記憶體中心」並非指某一種特定記憶體產品，而是一項系統原則：整合從高速記憶體到大容量儲存設備的多個層級，將資料搬移降至最低。

## 為何 AI 推論會加劇記憶體瓶頸

### 模型權重與 KV 快取帶來不同的負擔

AI 推論所需的記憶體大致可分為模型權重、執行期間產生的啟用值，以及 KV 快取。即使沒有請求，模型權重仍會占用固定空間；KV 快取則會隨輸入長度、輸出長度與同時請求數增加。

Transformer 模型為了避免每次都從頭計算先前的 token，會將各層的注意力鍵值資訊儲存在 KV 快取中。簡化而言，單一請求的 KV 快取大小與下列因素成正比。

確切的 KV 快取大小必須根據模型架構與實作規格確認。

KV 快取會分別儲存鍵與值。因此，當上下文變長或同時處理的使用者增加時，KV 快取會迅速膨脹。並非所有模型都會使用數百萬個 token，快取也不會一律增加數百倍，但長文本推論與代理型工作會提高記憶體壓力，這一趨勢十分明確。

### 幻覺與記憶體容量並非同一個問題

更長的上下文與檢索增強生成，可以為模型提供更多依據。然而，僅增加記憶體並不會讓幻覺消失，還需要搭配檢索結果品質、提示詞設計、模型推論能力、來源驗證及評估體系。

### 軟體也能降低實體記憶體需求

KV 快取瓶頸並非只能透過擴充硬體解決。

- MQA 與 GQA 可減少必須儲存的 KV 頭數量。
- 量化可減少權重與快取的位元組數。
- PagedAttention 以頁面為單位管理快取，減少碎片化與浪費。
- 連續批次處理可有效整合多個請求。
- 前綴快取可重複使用反覆出現的系統提示詞或共用上下文。
- 快取移除與分層卸載可將重要性較低的資訊移至速度較慢的記憶體。

因此，資料中心實際投入的記憶體規模，不僅取決於模型大小，也取決於推論引擎的效率。

## AI 資料中心的記憶體階層

單一記憶體很難同時滿足速度、容量、價格與能源效率的需求。AI 資料中心很可能朝以下階層架構發展。

| 階層 | 代表技術 | 優勢 | 主要限制 | 預期角色 |
|---|---|---|---|---|
| 晶片內部 | SRAM、暫存器 | 延遲時間最短 | 容量非常小，且面積成本高 | 立即使用的資料與運算中間值 |
| 加速器鄰近 | HBM | 高頻寬與相對較短的延遲時間 | 容量、封裝成本與散熱限制 | 活躍權重、頻繁使用的 KV 快取 |
| 伺服器記憶體 | DDR、CXL 連接記憶體 | 擴充容量大於 HBM | 距離加速器較遠且頻寬較低 | 快取擴充、模型分層、記憶體池 |
| 高頻寬快閃記憶體 | HBF 構想 | 基於 NAND 的高密度與非揮發性 | 讀取延遲時間、寫入壽命、控制複雜度 | 較少使用的權重與 KV 快取層 |
| 儲存設備 | NVMe SSD | 大容量與較低的每位元成本 | 延遲時間長於記憶體 | 檢查點、資料集、冷資料 |

重點不在於 HBM 與 HBF 之中何者勝出，而是依據資料的使用頻率配置多個層級。

## FMS 2026 所呈現的下一代記憶體競爭

2026 年 8 月於美國聖塔克拉拉舉行的 FMS，將 HBM 之後的 AI 記憶體與儲存架構列為主要議題。討論核心包括更高的堆疊層數、基於 NAND 的大容量階層、客製化記憶體，以及資料中心連接技術。

三星電子的 GHBM，以及 SK hynix 與 Google、SanDisk 討論的 HBF 等，均被視為展現這一方向的案例。不過，很難斷言 GHBM、HBF、THBM 等名稱，全都是已由 JEDEC 以相同規格確立的通用世代名稱。解讀時，必須區分企業發表階段的技術、共同開發概念與已標準化的商用產品。

此外，世代名稱較高，也不代表實際 AI 服務必然更快。必須同時比較有效頻寬、記憶體容量、延遲時間、功耗、冷卻、封裝良率與軟體支援。

## HBM 的優勢與容量限制

HBM 將多個 DRAM 裸晶垂直堆疊，並透過矽穿孔與寬介面連接。相較於一般板載記憶體，其核心優勢在於能從靠近加速器的位置，平行供應大量資料。

然而，HBM 容量無法無限增加。

1. 堆疊層數增加後，製造良率與檢測難度也會提高。
2. 同時配置 GPU 與 HBM 的封裝面積會擴大。
3. 必須在狹小空間內排除加速器與記憶體產生的熱量。
4. 供電網路與中介層布線也會變得更複雜。
5. 若使用昂貴的 HBM 儲存使用頻率較低的資料，經濟效益便會下降。

因此，由 HBM 負責最常使用的資料，並將其餘資料轉移至 CXL 記憶體、快閃記憶體或 SSD 的分層方式，正變得愈來愈重要。

## HBF 能否取代 HBM

HBF 是 High Bandwidth Flash 的縮寫，其構想是將 NAND 快閃記憶體平行化並堆疊，建立比傳統 SSD 更接近加速器的高頻寬記憶體階層。NAND 的密度高於 DRAM，且具備非揮發性，因此有機會在相同實體空間內容納更多資料。

然而，NAND 與 DRAM 的特性不同。

- 讀取延遲時間較長。
- 覆寫前需要經過抹除程序。
- 必須根據寫入次數管理壽命。
- 需要處理壞區塊、錯誤修正與耗損平均。
- 相較於小單位的非規則存取，更適合大單位的循序存取。

因此，即使 HBF 商用化，也很可能不會直接取代 HBM，而是作為 **HBM 與 SSD 之間的大容量階層**運作。以讀取為主的模型權重、重複使用頻率較低的快取、檢查點與檢索資料，都可能成為候選對象。實際適用性取決於介面標準、延遲時間、耐用性、控制器及推論軟體支援。

## GHBM 與 THBM 所提出的 3D 封裝問題

將加速器與 HBM 並排配置於封裝上的方式，在連接寬度與封裝面積方面存在限制。為了克服這些限制，將邏輯與記憶體垂直堆疊以縮短布線長度的構想應運而生。

### 將記憶體配置於 GPU 上方的結構

被稱為 GHBM 或 Z 軸 HBM 的概念，是透過垂直整合 GPU 與 HBM，縮短資料搬移距離。大量且短距離的垂直連接，令人期待其可實現高頻寬與低輸出入功耗。

問題在於熱。若將記憶體放在 GPU 上方，GPU 產生的熱可能必須穿過記憶體與冷卻裝置之間。「記憶體會熔化」這種說法，與其說是技術說明，不如說是用來強調散熱問題的比喻。實際風險包括接合部與記憶體超過容許溫度、漏電流增加、效能受限及壽命縮短。

### 記憶體在下、GPU 在上的結構

據悉，由 KAIST 教授金正浩團隊提出的 THBM，是將 GPU 放在 HBM 堆疊上方，使高發熱量的邏輯元件更靠近冷卻裝置。這可能有利於散熱，但仍面臨以下課題。

- 大型邏輯裸晶與記憶體堆疊的機械穩定性
- 電力供應與訊號布線
- 以不同製程製造之裸晶的接合良率
- 瑕疵裸晶的更換與可測試性
- 包含冷卻板在內的封裝設計

不能僅憑概念圖判斷垂直堆疊的競爭力，還需要實際測量熱阻、有效頻寬、良率與總持有成本。

## 光互連是擺脫記憶體依賴的替代方案嗎

若要使用 GPU 外部的記憶體與儲存設備，資料就必須移動更遠的距離。電氣訊號的傳輸距離愈長、速度愈高，訊號校正與重傳所需的電力也愈多。光互連因有望改善伺服器、機架與叢集之間高速連線的頻寬密度及傳輸功耗，而受到關注。

很難僅將 NVIDIA 強化光網路的趨勢，解釋為避免依賴特定記憶體企業的一項策略。更直接的背景是，隨著加速器規模從單一伺服器擴展至機架與資料中心層級，網路正成為整體 AI 系統的瓶頸。

光連接也不會取代 HBM。加速器旁的低延遲存取將由 HBM 負責，而光連接則很可能承擔連接遠端記憶體池與多個加速器的角色。

## 客製化 HBM 改變記憶體產業的方式

傳統通用 DRAM 具有向多個客戶供應相同規格產品的特性。HBM 則必須共同調整 GPU 封裝、中介層、基礎裸晶，以及電力與散熱設計，因此客戶與記憶體企業共同設計的比重更高。

客製化 HBM 或 CHBM 可在基礎裸晶中加入下列功能。

- 記憶體控制與介面最佳化
- 錯誤修正與可靠性管理
- 資料壓縮與搬移控制
- 安全性或虛擬化功能
- 有限的資料前處理與運算

這種結構可將記憶體供應商從單純的零組件製造商，提升為系統共同設計者。由於會在開發初期協商數量與規格，長期合約與客戶鎖定效應也可能增強。

不過，客製化並不會完全消除記憶體週期。AI 投資速度、客戶集中度、封裝產能、良率與通用 DRAM 價格，仍可能造成業績波動。針對特定客戶最佳化的產品，也存在需求改變後難以銷售給其他客戶的風險。

## 認為 GPU 發展已經停滯是否準確

很難斷言 GPU 的發展實際上已經停滯。加速器仍持續朝低精度運算格式、稀疏性處理、Transformer 專用引擎、Chiplet、網路與冷卻等方向發展。

改變的是評估標準。相較於單一晶片的最大運算效能，下列指標變得更加重要。

- 在實際模型中達成的有效記憶體頻寬
- 每位使用者的首 token 延遲時間與 token 生成速度
- 每瓦處理的 token 數
- 每機架記憶體容量與網路頻寬
- 服務模型的整體成本

開源模型的普及，也不代表所有模型的能力都已趨於一致。不過，隨著多個業者可使用類似模型，硬體營運效率與服務部署能力的重要性確實有所提升。

## 容易忽略的變數：可靠性、安全性與程式設計模型

下一代記憶體的討論聚焦於頻寬與容量，但還有其他會左右實際商用化的因素。

### 資料準確性與壽命

記憶體堆疊層數與密度愈高，熱、錯誤率與壽命問題就愈重要。在 AI 推論中，無聲資料損毀可能不會立即造成系統中斷，而是以錯誤輸出的形式出現。錯誤修正、資料完整性檢查與故障隔離，與效能同樣重要。

### 共享記憶體的安全性

若由多個加速器與客戶共享 CXL 記憶體池或外部快取，就必須具備資料隔離、加密、存取權限與殘留資料刪除機制。記憶體容量愈大，需要保護的模型權重與使用者上下文也愈多。

### 開發者是否能夠使用

即使具備新的記憶體階層，若編譯器與推論引擎無法自動決定資料配置方式，其利用率仍會偏低。需要有執行階段系統，管理哪些張量與 KV 快取應放在 HBM、HBF、CXL 記憶體或 SSD 中。最終，硬體競爭也會延伸為記憶體排程器與系統軟體的競爭。

## AI 資料中心是記憶體工廠嗎

將大規模 AI 資料中心稱為「記憶體工廠」，作為強調記憶體戰略重要性的比喻相當有用。這是因為模型權重、KV 快取、訓練資料、檢查點與檢索索引，都會儲存在不同階層中。

然而，若概括認為資料中心成本總有固定比例用於記憶體與電力，則缺乏充分依據。成本結構會依訓練與推論的占比、電價、伺服器折舊、網路、冷卻、利用率及模型效率而有所不同。

更準確的結論如下。

> 未來的 AI 資料中心將不只是大量安裝 GPU 的場所，而是把資料配置在最合適的記憶體階層，並以最低功耗加以搬移的系統。

## 對韓國半導體產業的意義

韓國具備大規模製造 HBM 與 NAND 快閃記憶體的能力，因此在記憶體中心轉型中占有重要地位。然而，僅憑記憶體產量很難保證長期優勢。

所需策略如下。

1. 確保能夠共同設計 HBM、HBF 與先進封裝的能力。
2. 提高基礎裸晶、介面 IP 與記憶體控制器的設計比重。
3. 培育熱管理、功率半導體、光互連與資料中心系統企業。
4. 建立軟體生態系，讓編譯器與推論引擎能有效利用韓國製記憶體。
5. 在智慧型手機、汽車、機器人與家電領域，確保連接硬體、AI 模型及服務的實際使用案例。
6. 管理對特定客戶或單一封裝供應鏈的依賴風險。

「若不經過韓國，就難以打造 AI 的地位」並非僅靠產量就能形成。只有當標準、設計資產、製造、封裝、軟體與最終服務彼此連結時，才能建立難以取代的產業地位。

## 展望：並非取代，而是分層與共同設計

與其認為 AI 半導體將從 GPU 中心完全轉換為記憶體中心，不如將其視為運算單元與記憶體之間界線逐漸模糊的過程，這樣更為準確。

- HBM 負責必須最快使用的資料。
- HBF 與 CXL 記憶體提供更大容量。
- SSD 負責長期儲存與冷資料。
- 光互連降低連接遠端資源的成本。
- 客製化基礎裸晶與 PIM 將部分運算移至更靠近資料的位置。
- 推論軟體決定各類資料應配置在哪一個階層。

下一代 AI 基礎設施的贏家，很可能不是打造出單一最快 GPU 的企業，而是能將運算、記憶體、連接、電力、冷卻與軟體最佳化為一套系統的生態系。

## FAQ

### 記憶體中心運算是指用記憶體取代 GPU 嗎？
不是。GPU 和其他加速器仍會繼續負責運算。記憶體中心運算是一種將加速器、HBM、外部記憶體、儲存裝置與網路一併設計，以減少資料移動所需時間與電力的方法。

### 為什麼 KV 快取在長上下文中會變大？
Transformer 會逐層儲存先前 token 的鍵和值資訊，以免重複相同的運算。儲存量大致與 token 數、層數、KV head 數和資料格式的大小成正比，因此長上下文和大量並行請求會增加記憶體用量。

### 如果 HBF 的容量比 HBM 大，就一定更好嗎？
並非如此。以 NAND 為基礎的 HBF 具有高整合密度和非揮發性的優點，但延遲時間比以 DRAM 為基礎的 HBM 更長，寫入壽命和錯誤管理也更複雜。將常用資料放在 HBM、使用頻率較低的資料放在 HBF 的分層配置更為實際。

### HBF 和一般 NVMe SSD 有什麼差異？
HBF 是透過更寬且高度平行的介面，將 NAND 快閃記憶體連接到更靠近加速器的位置，旨在提供比傳統 SSD 更高頻寬的概念。具體效能和連接方式可能會因產品與標準化結果而異。

### 將 GPU 和 HBM 垂直堆疊有什麼優點？
由於連接距離縮短，且可使用大量垂直布線，因此在頻寬和輸入輸出功耗方面可能更具優勢。另一方面，熱密度、供電、接合良率、檢測和冷卻問題會變得更棘手。

### 光互連可以取代 HBM 嗎？
光互連適合在遠距離連接多個加速器或記憶體資源，但無法直接取代緊鄰加速器的 HBM 所具備的低延遲。這兩項技術很可能分別負責不同距離和記憶體階層。

### 客製化 HBM 能消除記憶體價格週期嗎？
客製化設計和長期供應合約比通用記憶體更能強化價格穩定性和客戶關係。然而，AI 投資波動、產能、良率、客戶集中度以及通用 DRAM 價格的影響並不會因此消失。

### 支援長上下文就能消除 AI 幻覺嗎？
不能。長上下文可以提供更多依據，但如果檢索資料的品質、模型能力、提示詞設計和來源驗證不足，仍可能產生錯誤答案。擴充記憶體只是緩解幻覺的手段之一。

### GHBM、HBF、THBM 已經是確定的產業標準了嗎？
不應將所有名稱都視為同等程度的確定標準。部分名稱可能仍處於企業公布或研究提案階段，因此必須分別確認 JEDEC 等標準化組織的規範、製造商的最終規格，以及是否實際量產。

## Sources

- [FMS：記憶體與儲存的未來](https://futurememorystorage.com/)
- [使用 PagedAttention 為大型語言模型服務進行高效記憶體管理](https://arxiv.org/abs/2309.06180)
- [FlashAttention：具備 IO 感知能力的快速且記憶體高效之精確注意力機制](https://arxiv.org/abs/2205.14135)
- [精通 LLM 技術：推論最佳化](https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/)
- [Compute Express Link 聯盟](https://www.cxlconsortium.org/)
- [UCIe 聯盟](https://www.uciexpress.org/)

## Images

![中央AI晶片透過資料路徑連接RAM、堆疊記憶體、伺服器與儲存裝置](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTAxOCwicHVyIjoiYmxvYl9pZCJ9fQ==--5e9ff3355e5af64800fe3a3753eb07a1847f7fba/ai-db43622c.webp)
![分層AI晶片結合堆疊記憶體、處理器、伺服器機櫃與發光資料連線](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6OTAyNCwicHVyIjoiYmxvYl9pZCJ9fQ==--0b4dbc6fd04a7a2893bbf9865c8b7e32463f6e20/ai-29d9b4a3.webp)