Cloudflare AI Platform 的核心定位，是把 AI 應用與 agents 所需的執行、模型、資料、觀測、安全與成本控制放在同一套 developer platform 裡。
AI 應用真正上線後，通常會遇到一整串問題：模型要怎麼選、流量要怎麼控、向量資料放哪裡、檔案放哪裡、使用者狀態怎麼保存、成本怎麼看、agent 任務怎麼重試、瀏覽器自動化怎麼做。
Cloudflare 的策略，是用既有 edge 與 developer platform 把這些問題串起來。2026-06-15 Ensemble AI 核心成員加入後，這張拼圖又多了一層：模型推論效率。
2026-06 最新：Ensemble AI 補上 Workers AI 的推論效率層
Cloudflare 在 2026-06-15 宣布 Ensemble AI 的核心成員加入 Cloudflare，目標是強化 AI infrastructure，讓開發者能以更低的記憶體、運算與部署負擔服務大型模型與多模態模型。
這次更新要放回 Cloudflare AI Platform 的架構來看。原本的 Workers、AI Gateway、Vectorize、Durable Objects、Workflows 解決的是 AI app 與 agents 的應用層、資料層與流程層；Ensemble AI 帶進來的能力，瞄準 Workers AI 與 serverless GPU inference 下方的效率層。
Cloudflare 官方提到兩個技術方向：
| 技術方向 | 官方說法的重點 | 對開發團隊的意義 |
|---|---|---|
| NdLinear | 取代標準 linear layers，直接處理 multidimensional activations，保留 heads、channels、spatial dimensions 等結構 | 代表 Cloudflare 想在模型架構層降低 parameter count 與 compute，而非只靠硬體堆疊 |
| NdLinear-LoRA | 降低 fine-tuning 所需的 trainable parameters | 對未來客製化模型、微調成本與部署彈性有潛在影響 |
短期不要把 NdLinear 解讀成 Workers AI 已經開放的新功能。比較務實的讀法，是 Cloudflare 正把 model compression、efficient inference、GPU utilization 與 scalable deployment 納入平台長期投資。對 AI agents 來說，這很重要，因為 agent 一次任務可能包含多輪推理、檢索、工具呼叫、重試與回滾；每一層效率都會放大成成本與延遲差異。
Cloudflare AI Platform 包含哪些能力？
可以分成幾塊：
| 能力 | 代表服務 | 用途 |
|---|---|---|
| 執行層 | Workers | API、前後端邏輯、工具調用 |
| 模型層 | Workers AI | 在 Cloudflare 平台上使用模型 |
| 推論效率層 | Workers AI、serverless GPU inference、Ensemble AI 技術方向 | 降低模型服務的記憶體、運算與部署負擔 |
| 模型治理 | AI Gateway | 管理模型請求、快取、log、rate limit、成本 |
| 資料層 | R2、KV、D1 | 檔案、低延遲 key-value、結構化資料 |
| 語意搜尋 | Vectorize | RAG、embedding search、知識庫查詢 |
| 狀態協調 | Durable Objects | session、多人協作、agent state |
| 長流程 | Workflows | 多步驟任務、重試、等待與恢復 |
| 網頁操作 | Browser Rendering | 截圖、讀頁面、browser automation |
這些能力合在一起，形成一個 AI 應用 stack。Cloudflare 這次新增的訊號，是 stack 底層的模型服務效率開始變成平台競爭的一部分。
為什麼只接模型 API 不夠？
早期 AI app 可以很簡單：
- 前端送 prompt。
- 後端呼叫模型 API。
- 把答案回傳。
但只要產品稍微成熟，就會多出很多需求：
- 要支援多模型 fallback。
- 要看每個使用者花了多少 token。
- 要把文件切 chunk 做 embedding。
- 要限制某些資料只能特定角色查詢。
- 要快取相同問題。
- 要保存 conversation state。
- 要讓 agent 等待外部事件。
- 要把錯誤請求追蹤回來源。
這些問題和模型能力分屬不同層，卻決定 AI 產品能不能穩定運行。模型本身回覆得再好，若成本失控、資料權限混亂、任務無法恢復，產品仍然很難進入正式營運。
AI Gateway 的角色
Cloudflare AI Gateway 的統一模型路由與成本治理像模型流量的控制塔。
它能幫開發者處理：
- request logging。
- caching。
- rate limiting。
- cost tracking。
- provider routing。
- failure visibility。
企業導入 AI 後，常見痛點是看不到模型使用細節。哪個產品線最耗 token？哪個 prompt 最容易失敗？哪個模型供應商延遲最高？如果沒有 gateway 層，這些問題會分散在各個應用裡。
AI Gateway 的價值，是把模型使用變成可管理的 infrastructure。Ensemble AI 代表的 model compression 與 efficient inference 則處理另一個層面：模型實際被服務時需要多少記憶體、compute、GPU utilization 與部署成本。兩層一起看，才接近 production AI 平台需要的成本治理。
Vectorize 與資料層的角色
大多數企業 AI 應用都離不開 retrieval。
原因很簡單：模型本身不知道你的公司文件、客戶資料、內部流程、最新產品規格。這些都需要從資料層取回。
Vectorize 負責語意搜尋，R2 可以放文件與大型物件，D1 可以放結構化資料，KV 可以放低延遲狀態。搭配 Workers，就能建立常見的 RAG 應用：
- 文件上傳到 R2。
- 文件切段後建立 embedding。
- embedding 存進 Vectorize。
- 使用者提問時檢索相關段落。
- Workers 組合 prompt 並呼叫模型。
- AI Gateway 追蹤請求與成本。
這種架構比單純把文件塞進 prompt 更可靠，也更容易控管權限。
為什麼 agents 需要 Workflows 和 Durable Objects？
Agent 和一般 AI app 的差別在任務長度。Agent 通常會跨多個步驟、工具與等待時間。
例如一個網站 QA agent 可能要：
- 打開頁面。
- 截圖。
- 檢查按鈕。
- 填表。
- 等待結果。
- 比對預期畫面。
- 產生報告。
這是一段流程，單次 prompt 承載不了完整狀態。
Durable Objects 可以保存狀態，Workflows 可以管理步驟、重試、等待與恢復。Browser Rendering 則讓 agent 能和真實網頁互動。若再加上 Agents SDK 的 Durable Think 與 chat recovery，Cloudflare 的 agent 路線會更接近可營運的 runtime，而非一次性 demo。
Mason 的判斷：Cloudflare 在補 AI 平台最貴的一層
Mason 的判斷很直接：這次 Ensemble AI 核心成員加入，對一般讀者看起來像人才新聞，對工程團隊則是 Cloudflare AI Platform 往「推論成本層」補強的訊號。
已經使用 Workers、R2、D1 或 Vectorize 的 SaaS 團隊，可以開始把 Cloudflare 視為 AI app 與輕量 agents 的候選平台。下一步先挑一個低風險流程：客服摘要、站內搜尋、後台營運助理、文件問答或 QA agent，測量 latency、cost per task、失敗率、log 可追溯性與 fallback 設計，暫時不要搬動所有模型。
重度模型訓練、長時間 batch inference、封閉內網資料中心或需要專用 GPU topology 的團隊，可以先維持既有雲端或自架方案。Cloudflare 目前更適合放在應用層、edge runtime、模型治理與部分 serverless inference 場景。
最大風險是把平台選型簡化成「哪個模型比較便宜」。真正會出問題的地方，通常是權限、觀測、重試、資料邊界與成本歸屬。台灣與繁中團隊如果要導入，先把每個 agent 任務的資料來源、可用模型、最大呼叫次數、fallback、人工確認點與成本上限寫清楚，再決定是否把工作負載放到 Workers AI 或 AI Gateway。
什麼團隊適合用這種架構？
適合：
- 已經使用 Cloudflare Workers 的工程團隊。
- 想快速部署 AI API、RAG、agent workflow。
- 需要全球分散式低延遲。
- 希望統一觀測模型成本。
- 想降低伺服器維運負擔。
- 要把 AI 功能嵌進既有網站或 SaaS。
- 需要用小型專案驗證 企業 AI ROI 與 token 成本壓力 是否可控。
較不適合：
- 主要需求是模型訓練。
- 需要重度 GPU batch processing。
- 公司所有資料都在封閉內網。
- 只想用現成 no-code chatbot。
- 沒有人負責權限與觀測設計。
導入前檢查表
如果你是已用 Workers 的產品團隊，可以用這份清單判斷是否值得試 Cloudflare AI Platform：
| 檢查項 | 要先回答的問題 |
|---|---|
| 任務邊界 | 這個 AI 功能是一次回答、RAG、長流程 agent，還是需要瀏覽器操作？ |
| 成本單位 | 要用 cost per request、cost per user，還是 cost per completed task 追蹤？ |
| 模型路由 | 哪些模型可用？失敗時切到哪個 provider？ |
| 資料權限 | 哪些文件可被檢索？哪些路徑要排除？ |
| 狀態與恢復 | 任務中斷後要從哪一步恢復？誰可以人工接手？ |
| 觀測與稽核 | log 要保留什麼？誰能看 prompt、回覆與成本？ |
| 效率評估 | 要看 latency、throughput、memory footprint、GPU utilization，還是成功率？ |
這份檢查表也能和 企業導入 AI agents 前的 Agent Readiness 檢查 搭配使用。先把任務與資料邊界畫出來，再選 runtime、gateway 與模型，會比先買工具更安全。
FAQ
Ensemble AI 加入 Cloudflare 跟 Cloudflare AI Platform 有什麼關係？
它補的是 Workers AI 與 serverless GPU inference 下方的效率層。Cloudflare AI Platform 原本已經有 Workers、AI Gateway、Vectorize、Durable Objects、Workflows 等元件；Ensemble AI 的 model compression 與 efficient inference 經驗，讓這個平台在模型服務成本、記憶體與 GPU utilization 上有更多研發空間。
NdLinear 是什麼？一般開發者需要懂嗎？
NdLinear 是 Ensemble AI 研究的方向之一，目標是用能保留多維結構的 layer 取代標準 linear layers，降低參數量與 compute。一般應用開發者不需要自己實作，但要理解它代表 Cloudflare 正在投資模型服務效率，而非只把模型 API 包成一層平台。
AI Gateway 也能控成本，和 model compression 差在哪？
AI Gateway 管的是流量層：logging、caching、rate limit、provider routing、成本追蹤。Model compression 與 efficient inference 管的是模型被服務時的資源效率，例如記憶體、compute、throughput 與 GPU utilization。前者幫團隊看清楚錢花在哪，後者影響單次任務的底層成本結構。
Workers AI 的 serverless GPU inference 跟自己租 GPU 差在哪？
自己租 GPU 的控制度較高，也要自己處理 utilization、部署、監控、擴縮與故障。Serverless GPU inference 的目標是讓開發者用平台方式取得模型推論能力，降低維運負擔。若你的需求是短任務、全球低延遲、AI app 或輕量 agents，Cloudflare 路線值得測；若是長時間訓練或大量 batch，專用 GPU 平台仍可能更合適。
現有 Workers、AI Gateway、Vectorize 架構需要因為這次更新重寫嗎？
短期不需要。這次更像 Cloudflare 對 Workers AI 效率層的投資訊號。現有團隊應該先補上成本觀測、fallback、資料權限與 agent recovery，再觀察 Workers AI 的模型選擇、價格、效能與文件更新。
Cloudflare AI Platform 和其他 gateway 或雲端平台怎麼比較？
Cloudflare 的優勢在 Workers 生態系、edge 部署、AI Gateway、資料層與 agent runtime 的整合。若重點是模型供應商控管，可以參考 Vercel AI Gateway provider allowlist 的治理路線；若重點是大型模型訓練或專用 GPU 叢集，hyperscaler 與專用 ML platform 還是更主要的選項。
官方來源
- Cloudflare Blog：Growing the Cloudflare AI team with talent from Ensemble AI，2026-06-15。
- Cloudflare Blog，Building the Cloudflare AI Platform，2026-04-16。
重點整理
Cloudflare AI Platform 的關鍵，是把 AI 應用從「呼叫模型」推到「完整平台」：執行、資料、狀態、流程、瀏覽器、自動化、觀測、成本治理與模型服務效率，都會影響 AI 功能能否正式上線。
Ensemble AI 核心成員加入後，Cloudflare 傳出的訊號更清楚：下一階段 AI infrastructure 會同時競爭 developer experience、模型流量治理與 inference economics。對繁中工程團隊來說，最務實的做法是先選一個低風險 agent 或 RAG 流程，在 Cloudflare stack 上測 latency、成本、可觀測性與恢復能力，再決定是否擴大到 production。