算力下沉到邊緣：Workers AI、AI Gateway 與開源大模型邊緣推論

自己架過一次模型推論服務的人都懂那種心情：GPU 要租、要顧，離用戶遠的話延遲又很難看。Cloudflare 把這件事拆成兩層來解決。

Workers AI 負責把算力鋪到全球邊緣節點，AI Gateway 則負責管理所有模型呼叫，不管背後是自家模型還是外部供應商。這篇把兩者的分工，以及 2026 年幾個實際影響選型的變化整理清楚。

邊緣推論解決的從來不是「模型夠不夠聰明」，而是「這次呼叫要花多久才有回應，誰來管這一大堆呼叫」。

先分清楚：跑模型的層，跟管呼叫的層

Cloudflare 在 AI 這塊也是分兩層。Workers AI 是實際跑模型推論的地方，官方把它定位成「不必自己管 GPU，一次 API 呼叫就能在全球做推論」的無伺服器平台。

AI Gateway 則架在所有模型呼叫的前面，不管你呼叫的是 Workers AI 還是外部供應商，都先經過這一層做快取、記錄、限流與路由。

換句話說，Workers AI 回答「模型在哪裡跑」，AI Gateway 回答「這些呼叫要怎麼被管理」。兩者可以搭配，也可以只用其中一個，不是綁死的套件。

Workers AI：把算力鋪到使用者附近

Workers AI 的賣點是地理分佈，官方文件形容為「數十種模型跑在全球數百座城市，離使用者很近」。對延遲敏感的應用，這代表推論不必千里迢迢繞回單一區域的資料中心。

• 模型陣容涵蓋大型語言模型（Llama、Mistral、Gemma 系列）、圖片生成（Stable Diffusion、FLUX）、語音（Whisper 轉文字、文字轉語音）、與嵌入向量模型。
• 呼叫介面相容 OpenAI 格式，既有工具鏈通常不必大改就能接上。
• 計價方式已經從早期的神經元單位，改成單位計價，依實際推論用量收費，沒有請求時不必付閒置成本。

要注意的是，你拿到的是官方預先上架、由 Cloudflare 代管的模型清單，不是可以自己塞任意權重檔案的裸機器，客製化空間跟自架伺服器比起來是有取捨的。

2026 年的模型陣容：新模型上得快，舊模型也下得快

這塊的更新頻率遠比一般雲端服務快。依官方變更紀錄，2026 年上半年陸續加入 Moonshot AI 的 Kimi K2.6 與專攻程式生成的 Kimi K2.7 Code、Z.ai 的 GLM 5.2、Google 的 Gemma 4 系列，多半具備長上下文與函式呼叫能力。

跟著新模型上架的，是舊模型的陸續下架。官方在 2026 年五月底把一批舊版模型（包含部分 Llama 3.x 與 Mistral 7B）下線，選型時如果專案還在用這些型號，要留意遷移時程，避免上線前才發現模型已經不在清單上。

AI Gateway：所有模型呼叫共用的守門員

AI Gateway 本身不提供模型，它的角色更像是所有 AI 呼叫都要經過的一道關卡。核心功能包含請求快取（省下重複呼叫的延遲與費用）、完整的請求記錄、限流，以及失敗時的自動重試與備援模型。

• 動態路由：依請求屬性決定要怎麼處理，例如依用戶等級分流、模型之間做比較測試、或是把多個模型串成一條處理鏈。
• 統一計費：把額度存進 Cloudflare 帳號，就能拿去支付多家供應商的推論費用，不必在每家平台各自開帳戶付款。
• 安全控管：整合資料外洩防護，可以在請求經過時掃描敏感資訊，依規則擋下或發出警示。
• 統一端點：提供相容 OpenAI 與 Anthropic 訊息格式的通用端點，同一組呼叫邏輯可以在不同供應商之間切換。

什麼時候該用邊緣推論，什麼時候不必

邊緣推論不是所有情境的最佳解。它的強項是延遲敏感、請求量分散在全球各地的應用，例如即時客服對話、語音轉文字、embedding 檢索這類需要快速回應的任務。

1. 延遲敏感、使用者分散全球：適合直接用 Workers AI，不必自己在多個地區部署推論伺服器。
2. 已經在用多家模型供應商：適合接上 AI Gateway，用統一端點與計費簡化管理，不必各自維護串接邏輯。
3. 需要極致客製化模型或超大參數規模：邊緣推論的模型清單是官方預先上架的，如果需求超出清單範圍，可能還是要考慮自架或用其他雲端 GPU 服務。
4. 模型與計價都在快速變動：上線前務必查一次官方當下的模型清單與計價頁面，不要憑印象做架構決策。

整體來看，把「跑模型」跟「管呼叫」拆成兩層，是這套邊緣 AI 架構比較務實的地方，即使之後模型陣容又換了一輪，管理那一層的邏輯通常不必跟著大改。