AI伺服器的成本主角正從運算晶片轉向記憶體。SEMICON Taiwan 2026記憶體高峰論壇1日登場，Alphabet（NASDAQ：GOOGL）旗下Google Cloud供應鏈基礎架構資深總監Nikhil Cherian指出，隨著多模態、混合專家模型（Mixture-of-Experts，MoE）及AI代理快速普及，AI基礎設施已從「算力受限」轉向「記憶體受限」，高頻寬記憶體（High Bandwidth Memory，HBM）與先進DRAM等高效能記憶體，更已占AI伺服器系統物料清單（Bill of Materials，BOM）成本逾75％。
這道「記憶體之牆」帶來的問題不只是伺服器成本上升。當昂貴的AI加速器因為等不到資料而閒置，等同數十億美元的運算資本支出無法充分發揮效益。為此，Google正從硬體、軟體兩端同步出手：硬體方面首度將第八代張量處理單元（Tensor Processing Unit，TPU）拆分為訓練專用的TPU 8t，以及推論專用的TPU 8i；軟體方面則以TurboQuant量化演算法，壓縮大型語言模型的鍵值快取（Key-Value Cache，KV Cache）。
不過，Cherian也坦言，即使TurboQuant能把KV Cache占用的記憶體容量縮小至少6倍，面對Google接下來的AI服務規模，「仍然不夠」。這也意味著，軟體效率提升不一定會降低記憶體總需求，反而可能因AI使用成本下降、應用擴大，進一步推升整體用量。
AI從「算力受限」轉向「記憶體受限」
Cherian表示，25年前的Google主要負責蒐集、索引全球資訊，讓使用者快速找到資料，當時的核心命題是「以光速提供資訊」；25年後，產業進入智慧時代，AI不只搜尋資料，還要即時理解、綜合複雜內容，甚至預判使用者所需，運算典範也轉向「以光速提供智慧」。
Google目前約有15項產品的使用者超過5億人，其中至少7項產品突破20億人，這些服務正全面導入AI能力。Google Cloud客戶也開始將AI代理應用於員工生產力、創意內容、程式開發、資安、資料處理與軟體流程，約四分之三的Google Cloud客戶已經使用Google的AI產品。
過去的生成式AI多半是一次性問答，使用者提出問題、取得答案後，運算工作便告一段落；現在的AI代理卻會持續進行推理、規劃、呼叫工具、執行任務與修正結果，運作時間從數分鐘延伸至數小時、數天，甚至更久。
MoE、AI代理、KV Cache成三大記憶體消耗元凶
記憶體需求為何快速膨脹？Cherian歸納出三項主要來源，首先是MoE模型架構。相較於單一龐大的模型，MoE由數十甚至數百個專家模組組成，系統可依據不同問題，動態選擇部分專家執行任務。
這種架構雖然不必在每次推論中啟動全部參數，卻仍須將不同專家的模型權重保存在記憶體中。隨模型參數從數億、數十億一路增加至兆級，光是容納專家權重，就需要相當龐大的HBM容量。
第二項來源是長時間運作的AI代理。傳統聊天機器人的上下文通常只需維持一段對話，但AI代理要持續掌握先前的決策、工具執行結果與環境變化，才能在長時間工作流程中維持一致性。當代理從一次問答走向長時間、自主、多功能的即時工作者，相關狀態也必須持續保存在記憶體中。
第三項則是KV Cache。大型語言模型在生成內容時，會將先前處理過的鍵值資訊暫存在記憶體，避免每產生一個新詞元（Token），就重新計算全部上下文。這相當於模型進行推論時的「工作記憶」，可以加快回應速度，但占用容量會隨上下文長度、同時服務的使用者數量，以及AI代理運作時間而持續增加。
更棘手的是，KV Cache與模型權重必須競爭同一批高價、高頻寬記憶體。當記憶體容量或頻寬不足，運算核心就必須停下來等待資料，使得價格高昂的AI加速器無法滿載運作。
Cherian指出，從超大規模雲端服務商的角度來看，記憶體已成為運算伺服器BOM中最主要的成本來源；當處理器因等待記憶體而閒置，等同已投入的數十億美元運算資本支出遭到浪費，「這樣的成本結構，對下一階段的生成式AI並不可持續。」
硬體解方：TPU 8首度分流，訓練、推論各走一條路
面對記憶體瓶頸，Google第一項解方是將訓練與推論硬體分流，不再要求一款晶片同時滿足所有AI工作負載。
AI模型訓練追求龐大運算吞吐量、共享記憶體，以及高速晶片間互連；推論則須分散部署到全球不同地區，以極低延遲回應大量使用者，並長時間保存對話狀態與KV Cache。兩種工作負載使用記憶體的方式已有明顯差異，若繼續共用相同架構，將難以同時兼顧效能與成本。
因此，Google首度在同一世代推出兩款客製化AI晶片，分別是主攻大規模訓練的TPU 8t，以及針對低延遲推論與代理式AI設計的TPU 8i。
TPU 8t的單一超級運算叢集（Superpod）可串聯9,600顆晶片，形成2 PB的共享HBM池，並提供121 ExaFLOPs運算能力，讓複雜模型可以使用單一大型共享記憶體空間。Google並導入TPUDirect Storage，使訓練資料可更直接地傳送至TPU，繞過部分CPU主機及DRAM資料搬移環節，避免加速器因等待資料而閒置。
Google也為TPU 8i設計Boardfly晶片互連架構，縮短不同晶片之間的資料傳輸路徑，並導入集合加速引擎（Collectives Acceleration Engine，CAE），處理推論及MoE模型所需的同步與集合運算。這顯示Google並非只是增加HBM容量，而是重新安排SRAM、HBM、儲存、CPU主機與晶片互連的分工，從整個記憶體階層降低等待時間。
軟體解方：TurboQuant壓縮至少6倍，精準度不打折
第二項解方則是從軟體端降低每一項AI工作所需的記憶體容量。Cherian表示，Google正重新整合旗下產品的記憶體管理方式，將原本由不同軟體團隊分別處理的記憶體運算元、資料庫快取政策及資料處理框架，逐步移轉至共同平台，並重新檢視每單位運算應搭配多少記憶體的傳統假設。
其中一項關鍵技術是Google開發的TurboQuant。這套演算法不需要重新訓練或微調模型，可將大型語言模型的KV Cache量化至約3位元。Google測試顯示，TurboQuant可使KV Cache記憶體占用縮小至少6倍，同時未見模型準確度下降。
至於運算速度，Google Research的測試結果顯示，4位元TurboQuant在NVIDIA H100加速器上計算注意力分數時，相較32位元未量化鍵值，最高可帶來8倍加速。換言之，「3位元、壓縮6倍」與「4位元、最高加速8倍」分屬不同測試設定，不能直接視為同一組效能結果。
Cherian強調，TurboQuant雖可大幅降低單一模型推論所需的記憶體，但這並不代表Google未來需要的記憶體會隨之減少。他直言，即使把記憶體需求降低6倍，對Google接下來要支撐的AI規模而言，「仍然不夠」。
背後原因在於，模型規模、上下文長度、AI代理數量與使用者需求正在同步增加。當效率提升使AI服務成本降低，企業與消費者也可能導入更多AI工作負載，進而抵銷單位記憶體用量下降所節省的容量。
舊世代DDR4重回AI伺服器，記憶體走向分層使用
除了TPU架構及TurboQuant，Google也試圖從供應鏈與循環利用角度，提高既有記憶體資源的使用效率。Cherian表示，Google會翻修伺服器中的可用零組件，回收仍具有使用價值的元件，建立內部循環利用機制；Google也透過專用硬體與介面轉換，將DDR4等舊世代記憶體整合至較新一代AI伺服器。
不過，舊世代DRAM並非用來取代HBM，也無法承擔最需要高頻寬的核心AI運算，而是透過記憶體分層，讓不同效能、容量與成本的記憶體承接不同工作負載。如此可避免所有資料都占用供給有限、價格高昂的HBM，同時延長既有零組件生命週期。
這套做法反映AI伺服器的記憶體策略已不再只是「採購最新產品」，而是必須把晶片上SRAM、HBM、一般DRAM及儲存設備視為完整階層，依照資料存取速度與工作負載需求重新配置。
Google Cloud待履約訂單達5,140億美元，籲供應鏈走出交易式採購
儘管Google同時推動硬體專用化、軟體壓縮、零組件翻修及舊世代DRAM整合，Cherian仍預期，Google的記憶體需求將隨AI服務擴張持續增加。
根據Alphabet財報，截至2026年6月底，Google Cloud待履約訂單達5,139億美元，以9月1日新台幣兌美元銀行間收盤匯率31.633元換算，約新台幣16.25兆元。這些金額代表已簽約、尚未認列為營收的客戶承諾，也凸顯Google必須持續取得運算晶片、記憶體、網路、電力及資料中心容量，才能將龐大的訂單轉化為實際服務與營收。
Cherian因此向記憶體及半導體供應鏈喊話，超大規模雲端服務商不能再只是被動接受既有記憶體限制，供需雙方也不能停留在報價、下單與交貨的交易式採購關係，而應更早進入產品共同設計、產能安排與量產規劃。
當AI瓶頸從單一運算晶片的算力，轉向記憶體容量、資料搬移與系統延遲，下一階段競爭也將不再只是GPU或TPU之爭，而是記憶體、先進封裝、晶片互連、軟體演算法與供應鏈共同設計的系統戰。
