過去企業認知的 Google TPU 可能是「模型訓練與推論」加速器，現如今 Google 稍早宣布擴充的第八代 TPU 陣容，TPU 8t、TPU 8i、TPU 8tx、TPU 8i Max 則是一整套支援企業 AI 代理的運算基礎設施，不僅提供了更高運算能力，AI 也從線性對話回答問題，朝向以企業資料為基礎，呼叫外部工具協同執行任務的「夥伴」，以系統配置與軟體整合回應企業需求，讓過去的 AI 基礎設施的競爭近一步轉為完成實際任務的整體配置要求。
關於 TPU 8t 與 TPU 8i，今年 4 月舉辦的 Google Cloud Next 已經對外公開過，兩者分別面向大規模模型訓練，以及低延遲推論與化學習。大致來說，此次加入的 8tx 與 8i Max，是既有晶片基礎上的系統延伸，並非傳聞的第九代 TPU。8tx 主打機密推論，8i Max 則主要面向長上下文與高機櫃運算密度。Google 同步強化記憶體管理、開發工具與雲端叢集調度，試圖降低 AI 代理從實驗走向正式營運所需成本，我將這四組系統分別介紹如下：
TPU 8t：主要定位為大規模模型訓練系統，是第八代模型訓練的基礎平臺。
TPU 8i：主要定位為低延遲推論與推理系統，亮點是可針對記憶體與晶片之間的通訊做最佳化。
TPU 8tx：主要定位精密推論與小規模訓練，大致上沿用 8t 系統，但可因企業需求搭配客製化的 AMD CPU 主機以及 Boardfly 網路來拓建。
TPU 8i Max：將兩顆8i 晶片整合到單一封裝，主要針對長上下文與高運算密度所設計。
Google AI 與基礎設施資深副總裁暨首席技術長 Amin Vahdat 在公開說明當中指出，TPU 的需求已從 Google 內部服務，延伸至外部模型實驗室、交易公司、零售商及大學等領域，部署模式已延伸至客戶自有資料中心，目前客戶數接近百家。
TPU 8tx 可串接企業資料 著重資安防護
TPU 8tx 鎖定政府及受監管企業，重點是讓敏感資料與模型權重在實際運算期間，也能受到硬體層級的保護與隔離。一般資料保護常著重於儲存與傳輸階段，機密運算則可以更進一步的處理資料進入記憶體、解決程式使用時的信任問題。
Google 表示，8tx 沿用 TPU 8t 的晶片，搭配客製化 AMD CPU 主機，並導入針對即時推理設計的低延遲 Boardfly 網路。相較 TPU 8t，8tx 延遲最高可降至約一半，而安全功能帶來的效能損失接近零。
除了推論，8tx 也支援小規模訓練、私有資料微調、模型蒸餾及代理強化學習。這種設計的價值，在於讓企業有機會在同一系統中完成模型客製化與執行，減少敏感資料在不同叢集間搬移的流程。不過，硬體隔離不代表自動符合所有法規，也不能阻止 AI 因權限設定不當、提示注入或錯誤工具操作而洩漏資料，企業仍需確認保護範圍、驗證機制、金鑰管理及代理存取政策，才能判斷是否適合正式導入。
TPU 8i Max 用雙晶片封裝回應長上下文瓶頸
同步公開的 TPU 8i Max，則針對多代理處理大型程式碼庫、長影片及百萬 token 等級上下文的需求，強化資料供應能力。Google 表示，8i Max 將兩顆 TPU 8i 晶片整合在單一封裝中，相較 8i 提供兩倍運算能力、兩倍 SRAM，以及兩倍 HBM 記憶體頻寬，並在既有機櫃占地中配置更多矽晶片，提升運算密度。但兩倍運算及頻寬，不代表實際任務一定快兩倍；模型架構、批次大小、上下文長度與跨晶片通訊都會影響結果。
對長上下文推論而言，運算單元能算多快只是其中一環。模型還要持續讀取權重與 KV cache；後者是處理既有上下文時保存的注意力中間資料，可減少後續生成的重複計算。當同時服務的請求與上下文長度增加，記憶體及資料搬移便可能限制效能。
雲端平台同步升級
除了硬體之外，Google 也以 AI Hypercomputer 為基礎，整合開發工具、模型狀態管理及叢集調度。根據後續回應，這是既有 Google Cloud AI 基礎設施的擴充，並不是另一個與 Google Cloud 分離的新雲端品牌。
Agent Compute Engine 要處理 AI 代理經常「等待」的特性。代理可能暫停數秒甚至數小時，等待資料庫查詢、外部工具或人工確認。依文件描述，系統可自動暫停閒置代理工作階段，並在毫秒級時間內將工作記憶體移出加速器，以減少閒置資源占用。
Google 另規劃開源 TPU Sync，將加速器 HBM、主機 DRAM、共享儲存與資料中心網路整合為協同設計的模型狀態管理層，支援 KV cache 分層移轉、prefill 與 decode 節點之間的上下文串流，以及強化學習權重同步。Google 指出，相關最佳化可讓 KV 傳輸延遲與首個 token 回應時間降低超過 90%。
在大規模部署方面，Google 還提供文件將 Cloud Pathways 在 GKE 的一般供應，讓客戶以單一控制器管理多個 TPU slice，支援預訓練、強化學習與跨主機推論，並透過切片替換及重新分片等機制，降低硬體中斷對長時間工作的影響。GKE dynamic slicing 則將實體資源配置，與工作執行時的邏輯拓樸分離。它可透過光路交換技術，將較小 TPU 資源區塊組合為大型切片，或拆分為不同工作的獨立切片，減少每次更換需求都得重建 node pool 的負擔。
Google 指出，相較建立靜態 node pool，動態切片可讓工作啟動時間最高改善至約五分之一，恢復時間最高改善至約四點五分之一。需要注意的是，這些數據描述的是啟動與恢復效率，不是模型推論速度提高五倍。
另外，Google 近期透過開源 TorchTPU，讓 PyTorch 開發者以原生後端使用 TPU，並串接 vLLM、SGLang 等推論工具；此次也公開了仍在預覽階段的 TPU agent suite，以及面向 TPU、GPU、CPU 部署的 XLA Serving Engine。像是 TPU agent suite 的用途，是將 TPU 文件、效能分析與核心調校流程帶入程式助理，協助處理模型導入、瓶頸診斷及自訂 kernel 最佳化。對已使用 PyTorch 的團隊而言，這有助降低試用另一種加速器的工程成本。
小結
整體而言，Google 試圖把競爭單位從單顆加速器，拉高到完整 AI 工作流程。次升級顯示 AI 基礎設施正從擴充算力，進一步走向針對代理任務設計系統，對 AI 產業來說，這也是下一階段競爭的核心：同樣的預算與能源，究竟能完成多少可靠、可持續營運的 AI 任務。
對企業來說，更有意義的指標將是：在指定準確度、上下文長度與延遲要求下，每個成功完成的任務需要多少運算、記憶體與人力成本，而非只看每秒 token 數或峰值算力。
首先，8tx 若能以低效能損失提供可驗證的機密運算能力，可能擴大金融、政府及持有敏感資料企業的部署選擇。其次，8i Max 搭配模型狀態分層管理，有機會改善大型程式碼庫與多模態長上下文服務的資源瓶頸。
第三，PyTorch 相容性提升，可能讓更多團隊在既有 GPU 之外評估 TPU，增加企業選擇加速器與雲端服務的彈性，需要注意的是，這不代表 GPU 會被取代；Google 同時也在公開產品路線中提供 NVIDIA 平台。實際採用仍取決於工作負載、價格、可取得容量及成熟軟體的支援程度。
最後可以觀察的是「平台依賴」，當模型框架更開放，確實有利程式移植；但若部署深入依賴 TPU 拓樸、Pathways 與特定記憶體管理機制，跨平台遷移仍可能需要重新設計，因為開源工具與雲端部署可攜性，不能直接畫上等號。
Google 能否把模組化 TPU、開源工具與雲端調度的優勢轉成市場成果，後續仍需觀察新系統正式供應範圍、價格，以及具備完整條件的真實工作負載測試才能確知。