AI 競爭主軸正從「硬體性能」轉向「軟體主權」
重構軟硬整合，是打破模型規模與算力瓶頸的關鍵。
核心觀點
- 未來的壟斷邊界不再取決於晶片製造能力，而是誰能建立「平台級軟體主導權」
所謂「軟體主權」，是指對 kernel、compiler、生態整合層的控制力。掌握這些的企業，不僅模型能跑得更快，也能以更低成本提供 AI 服務。
- 算力瓶頸不只在硬體，而在軟體無法有效釋放硬體潛力
- NV 壟斷的是 token 成本，不是晶片效能
NV掌握CUDA、生態型 FlashAttention / FlashDecoding / MoE kernel，使其平台在現行軟體架構下成為唯一能有效釋放推論效能並壓低 token 成本的供應商； 表面上 ＮＶ硬體價格較高，但實際運算後token成本隨使用量增加反而展現更高經濟性。
- 非NV平台的劣勢並非來自硬體，而是缺乏軟體解放能力
不是因為 AMD / ASIC 硬體本身差，而是因為缺乏 kernel 生態與工具鏈，使其效能無法釋放，導致 token 成本反而高於 NV。
軟體層成為AI落地應用的瓶頸
當前困境
即使大語言模型提供者都跨過軟體層瓶頸，但實際上他們並未提供下層平台可廣泛使用的解決方案。
中小AI應用開發商、雲平台租戶、非NV平台供應商，因缺乏統一接口與可部署環境，無法承接 LLM 外溢紅利。
若未來仍無跨平台適配層、共通 compiler、通用推論框架出現，整個 AI 行業將落入平台壟斷與成本結構不可逆的「技術封閉循環」
🧩一、AI 模型規模極速膨脹：計算瓶頸已非線性上升
🔸1. Transformer 的崛起與魔力
- Transformer 模型具高度歸納偏差（inductive bias）與通用性，能以 token 為單位處理各式資料（文字、影像、語音、指令等）。
- 它為 GPU 天生設計的平行運算架構量身打造，能隨算力擴展而提高性能。
- 特殊現象：每增加一點算力與資料，模型會產生「非預期的 emergent 能力」，這帶來一種「魔法般」的發展速度。
🔸2. 問題：我們正逼近極限規模
- 從最早數億參數模型（2018年）發展至今日的萬億（trillion）參數 LLM。
- 要達成下一代 AGI 所需的計算量級為：10²⁷～10³⁰ FLOPs
- 這意味著：
- 需要 Zetta-scale 超級電腦
- 每台需 12～13GW 電力（等同十幾座核電廠）
- 這在實務上「根本無法擴建」
🧠二、演算法 × 硬體 × 軟體：系統瓶頸在多處同時發生
🔹1. 當前限制並非單一層級
- 神經網路本身有擴展潛力，但系統不同部件的 scaling 不對稱。
- 例如：模型容量可擴展，但記憶體（HBM）、頻寬、能耗卻無法同步跟上。
- 真正挑戰是：「整體 AI 系統的效能擴張性」。
🔹2. 必須全面協同設計
未來 AI 擴張的解法來自「多層同時優化」：
| 層級 |
可望提升效能 |
主力技術 |
| 🧠模型架構 |
×100 |
MoE, SSM, 上下文窗口增強 |
| ⚙️軟體棧 |
×1,000 |
編譯器重構, IR VM, 運行時優化 |
| 🧩硬體演進 |
×1,000 |
2.5D/3D 封裝、Chiplet、功耗優化 |
| 🏢資料中心建設 |
×10 |
能源、土地、地緣政治、基礎建設 |
| ✅總潛力合計 |
= 10⁹ (十億倍) |
需整體協同設計達成 |
硬體演進+軟體編譯與優化 如何高度耦合，是未來效能勝出最重要的關鍵
🛠️三、軟體是主要瓶頸： PyTorch 與開發棧已落後
🔹1. 軟體現狀混亂與低效
- 影響誰- 大語言模型開發商以外的AI應用開發者
- 多數 AI 開發流程依賴 PyTorch，但底層連接的是：
- Numpy
- CUDA / Triton
- FlashAttention（僅對特定 GPU 最佳化）
- deployment 還需 ONNX、TVM、XLA 等工具
- 結果導致開發者必須熟悉大量工具，且在跨硬體時經常效能大幅損失。
效能上的損失是什麼概念- 實際損失可以被「效能 × 成本 × 生產力」量化
效能與成本損失量化分析
1️⃣效能損失（跨硬體時）
| 範例情境 |
效能損失（推論速度 / 記憶體） |
| NVIDIA H100 使用 FlashAttention |
baseline（最快、記憶體最低） |
| 換到 AMD Instinct GPU |
FlashAttention 無法執行，需 fallback → 效能損失 40～80% |
| 換到 AWS Trainium / Google TPU |
不支援 PyTorch stack，需轉 XLA → 效能損失 + latency 加倍 |
實際部署時，同一個模型部署在不同平台的 throughput 可差 3～5 倍
2️⃣成本損失（以 inference 為例）- PyTorch 模型部署成本比較
假設你有一個預訓練好的 70B 模型（像 LLaMA-2 70B）
| 項目 |
方案 A：NVIDIA A100 |
方案 B：便宜硬體（如 AWS Trainium） |
| 單張硬體租金（每小時） |
$3.00 |
$1.50（便宜一半） |
| 推論速度（tokens/sec） |
100,000 tokens/sec |
⚠️ 只剩 30,000（PyTorch kernel 無法最佳化） |
| 每百萬 tokens 需運算時間 |
10 秒 |
33 秒（多 3.3 倍） |
| 每百萬 tokens 成本 |
✅ $0.0083 |
❌ $0.0138（更貴） |
| 最終推論成本對比 |
baseline |
➕ 成本增加約 66% |
混亂的開發棧如何限制邊緣運算
🎯例子 1：OpenAI 想推 GPT-4o 至邊緣設備（Edge TPU / AI box）
- 但 FlashAttention 無法跑在非 NVIDIA 架構
- ONNX 到 TVM 到 edge runtime 效率崩潰
- 結果：Edge 推論卡住 → 必須等新的 export path（或靠第三方如 OctoML 幫忙）
🎯例子 2：Meta 推 LLaMA 3 想讓 CSP 部署
- 若使用者想跑在 AMD GPU → LoRA、FlashAttention、Tensor layout 全部要改
- PyTorch 沒有統一 kernel 抽象，必須手動 best-effort tuning
- 結果：Meta 模型即使開源，90% 部署者還是跑不動，拖慢 adoption
🎯例子 3：AWS 推 Trainium，想吸引 Open Model Zoo
- 結果 HuggingFace 上模型很難轉 → kernel不相容、XLA 不支援、tokenizer 不連接
- 即使 AWS 提供便宜算力，沒人能輕鬆部署 → 沒人用
現在很多「便宜的硬體」根本租不出去，因為沒人會用跑不動主流 LLM 的平台來部署服務，即使再便宜都沒用。
🔹2. FlashAttention 案例說明現狀荒謬
- FlashAttention在現階段已幾乎成為「高效語言模型」的必備元件: FlashAttention 是一種專為 Transformer 模型設計的 高效能注意力演算法（Efficient Attention Algorithm），目的是大幅加速訓練與推論時的 attention 計算，同時降低 GPU 記憶體使用。
效能提升有多大？
| 模型規模 |
序列長度 |
傳統 attention |
FlashAttention |
提升幅度 |
| GPT-2 |
1024 |
baseline |
~2× |
~2倍 |
| GPT-NeoX / LLaMA |
2048 |
慢 + memory high |
快速且省記憶體 |
3～5倍 |
| GPT-4o（長上下文） |
32K～128K |
幾乎無法訓練 |
可訓練 / 可推論 |
成為關鍵突破 |
- FlashAttention 2 為 NVIDIA Ampere 架構設計
- FlashAttention 3 則為 Hopper 專屬 (Blackwell 延續Hopper架構)
- FlashAttention 2/3 之所以無法良好對應到 AMD 或 TPU，是因為它對 NVIDIA Hopper 架構的「硬體細節綁定程度極高」。 它不只是個演算法，而是一個針對 Hopper 記憶體與執行模型的低階 Kernel 實作。
- 所以FlashAttention 2、3 拿去跑在 AMD / ASIC 上 → 效能幾乎崩潰
🧠在 token 化推論時代，這件事為何關鍵？
所謂「token 化推論時代」是指：
- GPT/Claude/Gemini 等模型都是 token-by-token 預測輸出
- 每秒可產出多少 token 是一個決定性 UX 參數
- 這也會影響 token cost / inference cost / scaling
而 FlashAttention 就是幫助模型「更快產出 token、消耗更少資源」的關鍵技術。
→ 如果 AMD / TPU / 新創 accelerator 無法對應 FlashAttention 等等硬體綁定型最佳化，
就等於：
- 相同模型，在 NVIDIA 上比在其它平台快 2~3 倍
- 甚至在其他平台會被 fallback 回傳統 attention → 效能差數量級
- 最終會形成效能 × 成本 × 生態黏著度 × 開發路徑全面優勢
🛠️四、軟體對推論競爭力的影響- 為什麼NV全面勝出
✅現階段的推論競爭力取決於是否能跑下列關鍵 kernel：
| Kernel 類型 |
功能 |
是否屬於關鍵競爭力 |
| FlashAttention |
加速 transformer attention 運算、降低 memory bandwidth 壓力 |
✅絕對必要，影響 token/sec |
| FlashDecoding |
加速推論過程中「每次產出一個 token」的自回饋路徑（autoregressive decoding） |
✅必須支援，否則推論 latency 過高 |
| MoE kernel（Mixture of Experts） |
在模型中動態選擇部分 sub-network 參與計算，以減少 FLOPs |
✅支援此 kernel 可讓推論 FLOPs 下降 3--10x |
這些 kernel 是推論成本與 throughput 的非線性放大器：
❗ 有支援，可能推論成本 0.1 美分 / 1K tokens；沒支援，可能 0.5～1 美分或更高。
🧠如果不能跑這些 kernel，推論成本會怎麼樣？
| 項目 |
有 kernel 支援（NVIDIA） |
無 kernel（fallback 到 baseline attention） |
| Token latency |
每 token 20~50ms |
每 token 100~200ms |
| Token/sec per GPU |
400~1000 |
100~200 |
| 每 token 所需 FLOPs |
大幅減少 |
按 full model 跑完整 attention（O(n²)） |
| 單位成本 |
低 |
明顯偏高 |
| 雲端可賣價 |
可競價租出 |
成本高 → 利潤薄甚至虧損 |
結論：即使你的硬體 TOPS 再高、再便宜，如果沒這些 kernel，你的推論效能不值錢。
📊具體案例：為什麼這些 kernel = 推論護城河？
以 GPT-3.5 為例（13B 模型，context 2048 tokens）：
- 傳統 attention：需要 2048² = 4.2M 個乘法（O(n²)）
- FlashAttention：切成 128×128 block，L2 reuse，最多只需 0.8M FLOPs，效能提高 3~4 倍
- FlashDecoding：讓 autoregressive token 產生速度從每 token 200ms → 30ms
MoE kernel 更極端：
- OpenMoE 模型可將 175B 模型每次推論只啟用 12B 參數
- 使得推論成本降低約 7--10 倍（而不是等比例縮小模型效能）
✅FlashAttention / FlashDecoding / MoE 為何特別綁 NVIDIA？
| Kernel 類型 |
NVIDIA 優化手法 |
為什麼 AMD / ASIC 難以對應 |
| FlashAttention |
使用 TMA（Tensor Memory Accelerator）與 L2 tiling，匹配 warp 并行與 SM |
AMD 沒有 TMA，TPU 無 user-accessible tiling 控制 |
| FlashDecoding |
使用 register reuse + dynamic scheduling 讓 autoregressive 推理更快 |
TPU 不支援 token-by-token 回饋路徑，ASIC 通常靜態圖限制 |
| MoE Kernel |
Warp-level routing、masking、sparse dispatch |
TPU 支援 MoE 需特製 graph，AMD 缺乏對應軟體 kernel 工具 |
簡單說：這些 kernel 在 CUDA 上可直接寫 low-level kernel，而其他平台不是不能寫，而是「寫起來沒效率、成本極高、維護困難」。
🧠AMD 的狀況：為什麼現在還跟不上？
| 面向 |
現況 |
評論 |
| ROCm 軟體棧 |
正在建設中，但支援 PyTorch kernel fragment 很零碎 |
難以支援 Triton / Flash 系列 |
| Kernel 生態 |
沒有像 cuDNN、cuBLAS、Triton 這樣的對應層 |
開發者不願為 AMD 重寫 kernel |
| Attention kernel |
沒有開放等效 FlashAttention 3 的 kernel |
需業界手動移植，效能可能損失一半以上 |
| Decode kernel |
Autoregressive 推理支援度較低，需 fallback 到 baseline 解法 |
高 latency、高 token 成本 |
🚫CSP 自研 ASIC（如 TPU、Inferentia）面臨的困境
| 問題點 |
說明 |
| ❌無法自定 kernel |
TPU 無法插入自定 low-level kernel，需靠 XLA auto-fuse |
| ❌記憶體設計不支持 block-level reuse |
TPU 為 systolic array + streaming buffer 設計，不支援 register tiling |
| ❌Decoder 模型設計非主流 GPT 路徑 |
Inferentia 設計初衷不是為 autoregressive decoding，效能遠低於 H100 |
| ❌MoE routing 不支援 dynamic gating |
大部分 ASIC 僅支援靜態計算圖，不適合動態 token 分派 |
因此即使這些 ASIC 每 TOPS 成本低、TDP 好看，若不能跑主流 kernel，token 成本反而更高、延遲更長、開發更麻煩。
📌所以現況是什麼?
FlashAttention、FlashDecoding、MoE kernel 不是「附加效能」，而是「推論成本壓縮的必要條件」
AMD 與 CSP ASIC 若無法支援這三者，即使硬體便宜，也無法在 token 化推論時代具備商業競爭力。
當前市場主流情況（以 Hugging Face 模型為例）
| 雲平台 |
模型部署方式 |
預設支援 |
問題 |
| AWS EC2 + H100 |
可直接跑 LLaMA、Mixtral、Mistral，搭配 Flash kernel |
✅滑順支援 |
NVIDIA 平台先天被優化 |
| AWS EC2 + Inferentia 2 |
雖然便宜，但 Hugging Face 的 LLM 沒有 kernel 適配 |
❌效能跑不動 or 無法部署 |
開發者棄用 |
| GCP + TPU v5e |
大部分 LLM 沒有 kernel 適配、token/sec 很低 |
❌無法 scale 起來 |
模型 fallback 成效差 |
現在很多「便宜的硬體」根本租不出去
因為沒人會用跑不動主流 LLM 的平台來部署服務，即使再便宜都沒用。
🧨NV 的 kernel 生態已壓到別人沒得玩
| 關鍵點 |
結果 |
| CUDA + Triton + Flash 系列 kernel |
開發者與框架都已深度綁定 NVIDIA |
| GPT/LLM inference 主要 bottleneck |
來自 FlashAttention / Decoding / MoE，NV 平台獨有 |
| 租用推論 GPU 平台（如 AWS/GCP） |
提供的是「token 成本」，而不是「TOPS 價格」，NV 平台 Token/sec 高，成本低 |
| AMD / TPU / ASIC |
要嘛沒 kernel、要嘛無法支援某些特性，只能 fallback 回效率很差的做法 |
→ 這代表 短期內，所有想搶 token 化推論市場的非 NV 平台，根本沒有勝算。
🧱死結在哪裡？
| 問題 |
為什麼解不開 |
| FlashAttention 的效能依賴 TMA / L2 layout / warp shuffle |
AMD/TPU 架構完全不同，kernel 得重寫，且無現成替代功能 |
| FlashDecoding 依賴 dynamic scheduling + cache reuse |
ASIC 很多是靜態圖，且不給開發者插 kernel |
| MoE kernel 需要 fast routing + sparse tensor dispatch |
XLA/TensorRT 除 NV 以外都支援不好，GPU routing 也非標準化 |
→ 所以 不是寫不出來，而是：寫了跑不快、還沒人會用、維護超貴 → 沒有商業誘因做這事。
未來要觀察什麼?
要扭轉現況需要花很多資源跟時間成本，以下情況大致上都沒有發生
🔭未來三條可觀察的突圍主線：
- Kernel 解綁策略
- FlashAttention 若有跨平台版本出現（OctoML / Modular 等成功推出 universal IR）
- 非 NV 平台開始跑主流 Flash kernel with near-parity
- 模型架構轉型策略
- 主流 LLM 改採 MoE / SSM / State Space Models（如 Mamba），不再依賴 attention kernel
- HuggingFace 或 LLaMA 預設支援非 attention 路徑
- 平台商業化策略
- AWS / GCP 願意商品化 Inferentia / TPU 以 token/sec 模式公開比價，並補齊 SDK
- Groq、Tenstorrent、Cerebras 等新平台在特定市場建出 token cost 領先案例