Omdia把 capex 變成輸出

Omdia 的 AI factory playbook 把基礎設施改寫成 token 輸出、主權部署與最後一哩交付。

我最近一直在看 AI 基礎設施，越看越煩。不是因為它不重要，是因為大家還在用老掉牙的方式講它：多買 GPU、多上 rack、多接雲。聽起來很像在做事，實際上常常只是把錢堆進去，然後讓它在那邊等資料、等排程、等審批、等整合。這種場景我看過太多次了，預算過了，機房起了，產品團隊最後才發現自己蓋了一個很貴的等待室。

所以我看到 Omdia 這份 Light Reading 文章時，真的有被戳到。它沒有把 AI infra 當成一般雲端升級，而是直接當工業生產系統來看：有輸出、有瓶頸、有主權、有物理限制。這種講法比較不浪漫，但比較誠實。Omdia 提到全球資料中心累計投資到 2030 年可能接近 $1.6 trillion，而 2026 年領先科技企業在 AI infra 的 capex 可能超過 $600 billion。這不是「先試試看」的數字。

我想拆的不是標題，而是它背後那套 operating model。因為真正有用的，不是它說 AI 很大，而是它怎麼把大錢變成可衡量的輸出。

別再拿 FLOPS 當 KPI，先看輸出

“Budgets for compute hoarding have been frozen as enterprises confront a ‘Zombie GPU’ effect, in which expensive GPUs idle in I/O wait; evaluation metrics are shifting to Time-to-First-Token and vector retrieval speed.”

翻譯一下就是：你買到的算力，不等於你真的在產出。GPU 如果一直卡在 I/O、檢索、排程，那它不是算力，它是很貴的電暖器。我看過不少團隊一直炫耀 cluster 多大、卡多新，結果一問 latency，整條 pipeline 爛到不行。

Omdia 把 Time-to-First-Token 拉出來講，我覺得很對。因為這會逼你看使用者真的感受到什麼，而不是只看內部喜歡的指標。第一個 token 出不來，前面買再多 FLOPS 都沒用。向量檢索速度也是同一件事，RAG 的體感卡住，整個 AI app 就會像 demo 卡死。

我之前幫一個團隊看過一套 RAG stack，他們一直加 GPU，效益先有一點，然後很快平掉。後來真正有效的不是再加卡，而是把檢索路徑縮短、索引重整、重複呼叫砍掉。很煩，但事實就是這樣：問題通常在 plumbing，不在 horsepower。

實操寫法很簡單：

• 先追 TTFT、端到端 latency、retrieval latency，再追 GPU utilization。
• 找出 GPU 空轉是不是來自資料搬運、queueing 或 orchestration。
• 把重複 embeddings、重複 API call、重複 model hop 全部抓出來。
• 先優化 pipeline，再談買下一組 rack。

Omdia 提到一些 vendor case study，號稱有 12x vector indexing speed-up，以及最多 75% cost reduction，我不會把這種數字當神諭，但它至少提醒我：浪費通常就藏在那些看起來不起眼的中間層。

AI factory 不是資料中心改個名字

Omdia 把 AI Factory 定義成一種只為產出 intelligence 而存在的基礎設施，token 是基本輸出單位。這跟「我們有個 data center，順便跑 AI」是完全不同的腦袋模型。

我認同它的原因很直接：資料中心正在從 business support center，變成 digital product manufacturing center。這句話很像顧問話術，但你真的在企業裡做 AI 規模化，就會知道它不是形容詞。你需要能源、硬體、排程、虛擬化、產品交付全部一起動，少一層就會卡。

Omdia 把 stack 拆成四層：energy and physical infrastructure、hardware and network fabric、scheduling and virtualization orchestration、MaaS plus AI application ecosystem。我喜歡這個拆法，因為它直接打臉那種「模型層最重要」的偷懶講法。不是。你花三個月調 prompt，卻完全沒看 power density、network fabric、placement policy，最後就是漂亮簡報加上醜陋事故。

這種工業化的講法，也解釋了為什麼這市場會越來越資本密集、越來越政治化。當 AI output 變成戰略資產，底下那堆 infra 就不再只是 IT，而是某種國家級產能規劃。

實操寫法：

• 把 AI stack 拆成物理、網路、排程、應用四層。
• 每層都指定 owner，不要丟給「平台團隊」一口吞。
• 設計時就以 token production 為目標，不要只想 model hosting。
• 在第一個 production rollout 前，先看 power、cooling、network 假設。

如果你要對照 Omdia 用的詞彙，可以回頭看 原文。它的重點其實很明白：你不是在買雲端功能，你是在經營一台工業機器。

Hyperscaler 正在被迫分裂成兩條路

Omdia 說 hyperscaler 一邊要 agile，一邊要 sovereignty，所以現在大概只能走兩種 delivery paradigm。第一種是 full-stack drop-in，像 AWS、Huawei、Google Cloud、OCI 這類廠商，把整套 AI 能力直接塞進客戶自己的 data center。第二種是 software/hardware decoupling，把軟體能力本地化，硬體生態則依區域或政策條件去配。

這個分裂我覺得很合理。以前雲端故事太整齊了，大家都假裝只要上雲就好。但企業買 AI，常常想要的是 cloud-grade 的能力，外加控制權、資料駐留、合規。這些需求彼此打架，打到最後只能妥協。於是 hyperscaler 也只能把自己包成比較彆扭、比較在地、比較不優雅的樣子。

我在採購會議裡看過很多次同樣的戲碼：買方說要 private AI，翻譯一下通常是「我們不想讓敏感資料跨三個司法管轄區，再經過法務和資安各一輪」。供應商的回應也差不多：要嘛整套 drop-in，要嘛把軟體和硬體切開，讓本地化更容易。兩種都不完美，但都是真的。

重點是 sovereignty 早就不是附加條件，它正在直接改寫架構。這代表你選 vendor，不只是價格決策，而是政策決策、部署決策、長期依賴決策。

實操寫法：

• 先決定你的 use case 要 integrated deployment 還是 localized control。
• 在架構圖裡把 software portability 和 hardware sourcing 分開看。
• 直接問 vendor 怎麼處理 residency、auditability、operational boundary。
• 測試 workload 能不能搬，不要等到要遷移時才發現整包綁死。

如果你要看 Omdia 點到哪些廠商，可以先看 AWS、Google Cloud、Oracle Cloud Infrastructure、Huawei。重點不是它們一樣，而是它們正在被推向不同的部署妥協。

Compute-native AI cloud 會變成預設升級路徑

Omdia 提到 rack power density 從 2024 年的 10–15 kW，上升到 2026 年的 40–250 kW。這不是小幅變化，這是整個運作區間換掉。到了這種密度，還在說「再加幾個 rack」的人，通常只是還沒被現實打到。

它也說工作負載正在從 proof-of-concept 走向 production-grade deployment，像 Nebius 和 SenseTime 這類玩家，正在從 bare-metal leasing 轉向 Model as a Service。這和我看到的市場很一致：大家從租盒子，慢慢變成買結果，至少是想買結果。

我覺得有意思的是 Omdia 把 energy 跟 computing 綁在一起講。當 power envelope 變緊，compute 和 energy 就不是兩個話題了，是同一個話題。你不能控 power，就不能控 service quality；你不能控 service quality，AI platform 很快就只剩 demo。

所以 compute-native 這個詞不是裝飾，它有實際意義。compute-native AI cloud 不是雲上面掛幾張 GPU 而已，它是為高密度 workload、高利用率、production service delivery 設計的。如果你還是用 general-purpose infra 的假設去設計，基本上就是在跟工作負載對著幹。

實操寫法：

• 用現在的 rack density 重新檢查 power 和 cooling，不要沿用去年的規格。
• 把 PoC infra 和 production infra 分開。
• 評估 provider 是賣 bare metal、MaaS，還是完整 service layer。
• 把 energy procurement 和 workload scheduling 一起規劃。

這最後一點最容易被低估。我看過太多案子，算力都準備好了，結果 facility 扛不住 load profile。表面上叫「已核准」，實際上只是「沒人仔細看物理限制」。

最後一哩才是 AI 變成生意的地方

Omdia 把這段叫做 AI industrialization 的 last mile，我覺得這是整篇最有用的詞。vertical integrator、domain operator、ISV，最後真正吃到價值的，通常是那些把長週期 data governance、legacy integration、scenario-specific agent assembly 做完的人。

意思很簡單：錢不只在模型，也不只在 cluster，錢在把東西真的塞進 business 裡。這包含資料清理、workflow integration、權限、audit trail，還有簡報裡最常被跳過的那些髒活。

我做過夠多 enterprise AI 專案了，模式都差不多：模型在實驗室裡很能打，一碰到企業現場就撞牆。legacy system 很醜，資料政策很亂，domain logic 藏在老員工腦子裡。所謂 last mile，就是把這些東西翻成真的能上線的流程。

Omdia 提到 Inspur Cloud 那種 heavy-asset AI infrastructure strategy，也是在講同一件事：基礎設施不是結束，還要有人把工業線圍起來，對準真實 use case，然後長期維持運轉。

實操寫法：

• 從第一天就把 integration、governance、workflow mapping 算進預算。
• 找 domain owner，不要只找 technical owner。
• 做 scenario-specific agent，不要做那種沒人信的泛用 AI assistant。
• 評估 adoption 和 task completion，不要只看 model accuracy。

你不處理最後一哩，就不會得到 platform，只會得到一個有帳單的 prototype。

主權資料工廠正在把法規變成架構

Omdia 提到像 EU AI Act 和 DORA 這類框架，正在推動敏感資料留在實體隔離的設施裡。這也讓像 G42 這種區域型業者，從機櫃房東變成國家級資料的實體守門人。

這不是單純的 compliance 文書問題，它會直接改變 stack 裡誰有權力。資料不能出境時，本地 infra 就不是可有可無，而是戰略資產。控制設施的人，通常也控制了存取、延遲、政策執行，還常常一起控制商業關係。

這也是很多舊雲端假設會壞掉的地方。以前我們把 location 當部署細節，現在它可能就是整個 business model。區域與工業型 operator 被拉進來之後，角色就變成 infra、regulation、trust 三者混在一起。很亂，但市場就是往這裡走。

實操寫法：

• 把 workload 依 residency、sensitivity、regulatory exposure 分級。
• 需要時，直接把 physical isolation 寫進 infra 設計。
• 把 compliance requirements 當成 architecture requirements 來看。
• 法務還沒炸掉前，就先找 regional operator 對齊。

Omdia 也提到 2026 和 2027 會是 AI Factory 發展的關鍵窗口。我不會把這句話講得太大，但我同意方向：能把 local control、industrial ops、real AI delivery 湊在一起的人，確實比較有路可走。

可抄的模板

# AI Factory Operating Model Template

這份模板用來把 AI 基礎設施從「買 GPU」改成「可交付的生產系統」。

## 1) 定義輸出
- 主要輸出：tokens / completions / retrieval results / agent actions
- 對應的 business KPI：［填入］
- 使用者可感知 latency 目標：［填入］
- TTFT 目標：［填入］

## 2) 拆成四層
### Layer 1: Energy and physical infrastructure
- Power envelope：［填入］
- Cooling model：［填入］
- Facility constraints：［填入］
- Residency / geography constraints：［填入］

### Layer 2: Hardware and network fabric
- GPU / accelerator type：［填入］
- Network topology：［填入］
- Storage / data movement bottlenecks：［填入］
- GPU idle time sources：［填入］

### Layer 3: Scheduling and virtualization orchestration
- Scheduler：［填入］
- Placement rules：［填入］
- Multi-tenant isolation model：［填入］
- Queueing policy：［填入］

### Layer 4: MaaS and application ecosystem
- Model service layer：［填入］
- Retrieval layer：［填入］
- Agent / app layer：［填入］
- Domain owner：［填入］

## 3) 先量這些，再買更多算力
- TTFT
- End-to-end response latency
- Retrieval latency
- GPU utilization
- GPU idle time caused by I/O
- Cost per successful task
- Cost per 1,000 tokens delivered
- Task completion rate

## 4) 決定交付模式
從下面選一個：
- Full-stack drop-in
- Software / hardware decoupling
- Compute-native AI cloud
- Private AI foundation stack
- Regional / sovereign operator

每個模式都要寫清楚：
- Data residency requirements
- Integration effort
- Vendor lock-in risk
- Time-to-production
- Compliance burden

## 5) 先處理 Zombie GPU
在加 compute 之前，先問：
- GPU 是不是在等資料？
- Model 是不是在等 retrieval？
- Orchestration 有沒有造成 queueing？
- 我們是不是在重複 API calls？
- 能不能先減少 redundancy，再談 scale？

## 6) Production readiness checklist
- [ ] Data governance 已核准
- [ ] Network bottlenecks 已量測
- [ ] Power / cooling 已驗證
- [ ] Residency requirements 已映射
- [ ] Observability 已到位
- [ ] Domain owner 已指定
- [ ] Incident response 已定義
- [ ] Cost model 已審過

## 7) 一句規則
如果這套 infra 不能穩定產出 tokens，它還不算 AI factory。

這就是我會直接丟給團隊的版本。它會逼大家把討論從「我們能買多少 GPU」拉回到「我們到底在產什麼、卡在哪裡、誰負責哪一層」。這樣花錢比較不會瞎掉。

原始來源是 https://www.lightreading.com/ai-machine-learning/five-dynamics-redefining-ai-infrastructure-in-2026-omdia。我這篇主要是拆 Omdia 的框架，再加上我自己的實作判讀、案例和模板；五個 dynamics 與原始措辭來自來源，操作建議是我整理出來的。