AMD 讓 AI 堆疊變平台選擇

以前買 AI 只看模型和 GPU，現在得一起看治理、運維和平台選擇。

我這陣子一直在看企業 AI 怎麼落地，越看越有一種熟悉的煩躁：大家嘴上都在講模型、Agent、Demo，真的進到 production，立刻變成電力、排程、CPU/GPU 怎麼分、誰負責稽核、誰背 3 點的帳單。很多廠商把這件事講得像買一張卡就能解決，結果我每次看完都只想問一句：你是賣晶片，還是賣一整套能跑的東西？

AMD 這波讓我停下來的原因，就是它開始把話題從單一硬體拉到整個堆疊。EPYC、Instinct、ROCm、夥伴平台、企業軟體、治理，全部混在一起講。這種講法我不會說它完美，但至少它終於碰到真問題：AI 不是一個 demo，它是一個要被長期維運的系統。

我拆這篇的外部錨點，是 SiliconANGLE 這篇 2026/07/07 的文章：AMD Advancing AI highlights enterprise AI infrastructure。文裡把 AMD、Nutanix、Rackspace、theCUBE Research 幾方的觀點串起來；其中 Paul Nashawaty 提到一個很刺眼的數字：64% 的組織把資料與基礎設施瓶頸視為 AI 部署最大障礙。

AMD 這次不想只當 GPU 廠

Enterprise artificial intelligence infrastructure has become as critical to AI success as the models themselves.

這句話我很買單，因為它直接把很多公司最愛逃避的事講穿了。模型重要，沒錯；但如果你的 infra 撐不起來，模型再強也只是簡報上的漂亮字。AMD 現在的語氣，已經不是「我們有更快的加速器」那麼簡單，而是把 AI 當成一個系統工程來賣。

翻譯一下就是：它想讓你先想整套 operating model，再回頭選晶片。這個順序很重要。我以前看過太多團隊先買模型、先上 Agent、先做 PoC，最後才發現資料管線、部署方式、權限控管、成本模型全部沒準備好。那時候不是技術問題，是整體設計一開始就歪了。

我自己碰過最常見的狀況，是團隊把「能跑」當成「能上線」。Demo 跑得漂亮，到了真實流量，延遲、重試、監控、回滾、權限全冒出來。AMD 這次把話題拉回 stack，我反而覺得它比較像在講企業買東西的現實，而不是在講一場發表會。

實操上，我現在看 AI 平台第一件事不是 benchmark 截圖，而是畫 stack map：

• 哪些工作跑在 CPU
• 哪些工作跑在 GPU
• 哪些流程需要集中治理
• 哪些能力可以跨環境搬移
• 哪些地方被單一供應商綁死

如果對方只能講「我們很快」，不能講清楚這張圖怎麼畫，我就會直接把它放回待觀察名單。

開放生態比較煩，但它比較像企業真的會用的東西

Through our partnership with Nutanix, we’re building a scalable, full-stack AI platform rooted in openness, designed to give enterprises and service providers the flexibility to innovate, extend and grow AI deployments across enterprises.

這段是 Dan McNamara 的說法，我覺得它的重點不是「開放」這個詞本身，而是「可伸縮、可延展、可長大」。企業 AI 不會永遠停在一個模型、一個工作流、一個雲環境。今天是客服摘要，明天可能是內部知識助理，後天又變成受管制產業的決策輔助。你如果把平台鎖得太死，之後每次改動都像在拆牆。

我以前很容易被那種「一站式 AI 平台」吸引，因為看起來省事。後來吃過幾次虧才懂：省事常常只發生在前兩週，真正的成本在後面。你想換模型、想改部署拓樸、想把某些流程拉回內網，結果每一步都要跟原廠談條件。那不是平台，那是溫柔版的綁架。

AMD 跟 Nutanix 這條線之所以值得看，是因為它把企業最在意的彈性放在前面。Nutanix 的定位本來就偏向把基礎設施複雜度藏起來，AMD 則想把算力、軟體和硬體串成一條可交付的路。這種組合至少比單純喊「我們有 AI」更接近真實採購流程。

實操上，我會直接問三個 portability 問題：

• 模型能不能搬
• 基礎設施能不能搬
• 政策和治理能不能一起搬

只要其中一項答案是「要看情況」，我就會再追問到能不能不用重寫。因為企業最貴的從來不是第一版，而是第二版開始的改造成本。

相關工具我會一起看：ROCm、EPYC、Instinct。我不是在幫它背書，我只是想看它到底有沒有一條能走的路，而不是一張很漂亮的 PPT。

Agentic AI 會把 CPU/GPU 的分工逼回來

In the agentic flow, where you’re running multi-system agents, the first step you do when an agent request comes in [is] you need to start planning … that’s a combination of CPU and GPU.

這段很實際，也很不討喜，因為它提醒所有人：Agent 不是拿 GPU 硬堆就會變聰明。真正麻煩的是 planning、routing、tool call、retry、state management、policy check，這些東西很多都偏控制面，不是純運算面。你把所有東西都丟給 GPU，等於拿高價算力去做本來就不該昂貴的事。

我之前看過一個團隊很得意地說自己「把整個流程都搬上 GPU」，結果成本直接炸開。後來一查，發現大量時間都耗在 orchestration 和串接邏輯。這種錯誤很常見，因為大家太容易把 acceleration 跟 architecture 混在一起。AMD 這次的說法比較像在提醒：先看工作型態，再看硬體。

白話一點講，Agentic AI 最怕的不是慢，而是你根本不知道慢在哪裡。只要 planning 跟 execution 混在一起，成本、延遲、除錯都會一起變爛。這時候 CPU/GPU 的分工就不是教科書問題，而是帳單問題。

我現在會把 agent stack 拆成三層：

• 控制層：規劃、路由、權限、重試
• 執行層：模型推理、生成、批次運算
• 治理層：稽核、觀測、政策、追蹤

然後我會問：哪一層真的需要 GPU？哪一層只是因為大家懶得拆，所以被硬塞上去？這個問題一問下去，很多架構就露餡了。

如果你也在做 Agent，我建議直接看這四件事：Nutanix 類型的平台怎麼管控、AMD 的 ROCm 怎麼串、推理和排程怎麼切、成本怎麼按 task 算。只看 token 成本，常常只是自我安慰。

治理已經不是後補文件，是架構的一部分

Enterprises in regulated industries need AI infrastructure that is governed from the ground up, with one operator accountable for business outcomes, not a collection of vendors each owning a piece.

這句是 Rackspace 的 Gajen Kandiah 講的，我覺得很到位。因為很多企業 AI 失敗，不是因為模型不行，而是因為責任被切碎了。模型廠商說自己只管模型，雲廠商說自己只管雲，整合商說自己只管整合，最後真的出事，沒人知道 pager 到底該找誰。

治理以前常常是上線後才補的文件，現在不行了。只要你的 AI 會碰資料、會做決策、會觸發系統動作，治理就得先放進架構裡。這不是法務的額外工作，是系統設計的一部分。

我以前幫團隊看受管制場景時，最常見的坑就是「先把東西跑起來再說」。結果等到要補 audit trail、補權限、補資料隔離，才發現原本的架構根本沒留位置。那種補法很痛，通常還很貴。

實操上，我會要求每個 AI 專案先把五個 owner 寫清楚：

• 模型行為誰負責
• 基礎設施誰負責
• 資料存取誰負責
• 稽核紀錄誰負責
• 業務結果誰負責

如果五項都回答成「供應商」，我就會開始懷疑這個案子是不是把責任外包得太乾淨。因為真正出問題時，外包不會幫你簽報告。

如果你想看 Rackspace 自己怎麼講 AI，這頁可以一起看：Rackspace AI solutions。我不是要你去買，我只是要你把治理這件事拉回採購清單，而不是等出事才補。

真正的產品是選擇權，不是某一顆晶片

I think that the story is all about choice.

John Hampton 這句話很直白，我反而覺得最有用。企業買 AI，不是真的只想買更快的卡，他們想要的是選擇權：能不能接現有機房、能不能接既有權限系統、能不能沿用現有雲策略、能不能在不同工作負載之間切換而不崩盤。

這才是 AMD 現在最值得注意的地方。它沒有把自己包裝成「一鍵解決所有 AI 問題」的萬能平台，而是把自己放進企業現實裡：既有電力限制、既有採購流程、既有安全規範、既有運維團隊。這種講法聽起來不性感，但真的比較像會落地的東西。

我越來越相信，好的 AI 平台不是讓你忘記限制，而是讓你在限制裡還能做事。只要一個方案需要你把整個組織重建一次，那它就不叫平台，它叫大型專案災難。

實操上，我現在都用 constraint checklist 來打臉自己和供應商：

• 現有電力和散熱撐不撐得住
• 能不能接現有 identity 和 policy 系統
• 能不能混合 CPU/GPU 工作負載
• 能不能跨 on-prem 和 cloud 部署
• 之後換供應商會不會整個重寫

這五題答不出來，平台再好看都先放一邊。因為企業最後買的不是炫技，是可維運性。

這篇最值得抄走的，其實是判斷框架

The event will feature conversations with AMD executives, customers, developers and partners focused on enterprise AI infrastructure, open ecosystems and AI deployment.

這整篇我看下來，最有價值的不是某個產品名，而是它把 enterprise AI 的判斷框架講清楚了：先看堆疊，再看治理，再看選擇權，最後才是硬體型號。這對做平台、做架構、做採購的人都很實用。

如果你在公司裡要推 AI，我會建議你直接把討論從「要不要上某個模型」拉到「我們要不要一個能被長期維運的 AI operating model」。這個問題一換，很多原本吵不完的細節會突然變得比較好談。

我也不覺得 AMD 這套說法就沒有商業味道，當然有。每個廠商都想把自己放進你的主架構裡，這很正常。但至少這次它碰到的方向是對的：企業不缺 demo，缺的是能活下來的系統。

所以我最後會把這篇壓成一句話：AI 基礎設施的競爭，已經不只是算力，還是你能不能把選擇權、治理和工作負載分工一起交付給團隊。

可抄的模板

# Enterprise AI infrastructure decision memo（可直接複製改寫版）

## 目標
建立一套開放、可治理、可擴充的 AI 平台，能支援 agentic workloads，且不需要把現有基礎設施整個重做。

## 我們要解的問題
- 資料與基礎設施瓶頸
- GPU 被拿去做不該昂貴的 orchestration 工作
- 閉鎖式平台造成供應商綁定
- 治理、稽核、責任歸屬不清楚

## 工作負載切分
### CPU-heavy tasks
- Agent planning
- Tool routing
- Policy checks
- Control-plane logic
- Retry / fallback orchestration

### GPU-heavy tasks
- Model inference
- Batch generation
- Embedding / scoring
- Parallelizable compute

### Governance layer
- Audit logging
- Access control
- Runtime policy enforcement
- Observability
- Incident ownership

## 平台需求
- 支援開放生態
- 可混合 CPU/GPU 部署
- 能沿用現有電力、散熱與機房限制
- 可接現有 identity / policy 系統
- 有 audit trail
- 支援 model portability
- 支援 infrastructure portability
- 清楚定義 business outcome owner

## Vendor 評估問題
1. Planning 跑在哪一層？
2. Orchestration 跑在哪一層？
3. 哪些工作真的需要 GPU？
4. 模型能不能搬，不用重寫應用？
5. 基礎設施能不能換，不用改整個流程？
6. 誰負責 uptime、policy、auditability？
7. 成本能不能按 task 算，而不只按 token 算？
8. 這套能不能塞進我們現有的 operating model？

## 決策規則
如果平台講不清楚 CPU/GPU 分工、治理責任、可攜性，就不要進下一輪。

## Pilot 範圍
- 一個業務流程
- 一個 agentic use case
- 一個治理 owner
- 一個成本 baseline
- 一個 rollback plan

## 成功指標
- 降低 infra bottlenecks
- 降低 GPU 浪費時間
- 有完整 audit trail
- 延遲穩定
- 沒有被單一供應商綁死

這段模板是我根據 SiliconANGLE 那篇整理出來的實戰版，不是 AMD 原文。你可以直接貼進內部提案、架構評審或採購評估表，再依你們公司的限制去改。

原始來源：SiliconANGLE。我這篇是衍生拆解，判斷框架與可抄模板則是我自己整理的版本。