謝至恩「當企業 AI 要走向規模化，以後需要的就不只是一個模型，而是一個平台。」Red Hat 全球副總裁暨大中華區總裁曹衡康指出，企業往往同時使用多種模型，也要在 GPU 、 CPU 、 NPU 及不同雲端環境間配置算力。選擇愈來愈多之後，真正的挑戰已不再是找到唯一、最強的模型，而是企業能否掌握成本、權限、資料與執行流程。
這項轉變也構成 Red Hat Summit 2026 的主軸。 Red Hat 提出「The Next Platform is Choice」，試圖以 Red Hat AI 、 Red Hat OpenShift 、 Red Hat Enterprise Linux 及 Red Hat Ansible Automation Platform 建立統一平台，讓企業在模型、硬體與部署環境持續變動時，仍保有改變選擇的能力。
台灣企業卡在 PoC 走向生產的轉折點
Red Hat 台灣區總經理孫媛音觀察，台灣企業前兩年導入 AI 時，多半先透過公有雲快速進行概念驗證；隨著專案與使用部門增加，原本分散的小型實驗逐漸演變成基礎架構問題。企業開始盤點需要多少 VM 與 GPU 、如何在部門間分配 Token，以及哪些資料可以上雲、哪些必須留在地端。
政府、製造與金融業面對的情境不同，卻有相同的管理難題。政府部門重視資料與數位主權；製造業希望讓 AI 從 PoC 進入產線、研發與供應鏈；金融業則從客服應用延伸至 AIOps 及自動化營運。當 AI 不再只是少數團隊的試驗工具，單獨為每個專案準備模型、算力與權限的做法便難以延續。
孫媛音表示，Red Hat 在台灣的重點，是協助企業把 AI 從 PoC 推向正式生產環境。這不只代表擴大算力，也意味企業必須建立一致的治理方式，避免不同團隊各自申請 AI 服務、持有 API 金鑰及管理資料，形成成本與風險都難以掌握的「影子 AI」。
MaaS 把模型與 Token 納入統一管理
Red Hat AI 3.4 首先從模型與 Token 著手，導入模型即服務 (Model-as-a-Service, MaaS) 。平台工程團隊可透過單一、受治理的介面，向內部開發人員及 AI 代理提供經過篩選的模型，並依部門或使用者設定模型存取權、 Token 配額與身分驗證。
MaaS 透過 API 閘道統一管理內部模型及外部 API，讓 Token 從難以追蹤的使用量，轉化為可以分配、計量與控管的企業資源。對企業而言，這項設計的意義不只是提供模型目錄，而是把模型選擇、使用權限與推論成本放入同一個管理框架。
底層則結合 vLLM 推論伺服器、 llm-d 分散式推論引擎、智慧推論路由及推測解碼 (Speculative decoding)，提高跨節點推論與 GPU 使用效率。 Red Hat 解決方案架構經理游政杰說明，智慧推論路由會依 KV Cache 狀態，將請求導向已有相關快取的節點，減少重複運算；實際效益則會依工作負載與快取命中率而異。
Red Hat 表示，推測解碼可讓回應速度提升 2 至 3 倍，並在幾乎不影響品質的情況下降低互動成本。這也反映企業 AI 的競爭焦點正從單純採購模型，逐步轉向如何有效供應、分配及治理 Token 。
AI 代理開始行動，治理從輸出延伸至執行
模型與 Token 受到管理後，下一個問題是 AI 代理的行動。當 AI 只負責回答問題，錯誤通常停留在內容層；當代理能呼叫工具、修改設定或執行修復，錯誤便可能直接影響生產系統。因此，企業需要知道代理使用哪一個模型、根據哪些提示詞推理、呼叫哪些工具，以及最後採取何種行動。
Red Hat AI 3.4 新增 AgentOps 功能，涵蓋代理追蹤、可觀測性、評估、加密身分及生命週期管理。平台整合 MLflow 與 OpenTelemetry，記錄 LLM 呼叫、推理步驟、工具執行、模型回應與 Token 用量，並為提示詞、詞嵌入及檢索增強生成 (RAG) 設定留下可供除錯與稽核的軌跡。
評估中心則用於統一測試大型語言模型、 AI 應用程式及代理的品質、準確性與風險。平台也能檢查越獄、提示詞注入與偏見等問題，並以短效期權杖取代長期共用或寫死的 API 金鑰，讓代理及其工作節點依最小權限原則執行任務。
但追蹤代理仍不足以防止錯誤行動。 Red Hat 因此把 Ansible Automation Platform 定位為 AI 代理與生產系統之間的可信任執行層。 AI 可以分析事件並提出建議，人員保留核准權，再由 Ansible 依既有 Playbook 及政策執行經過驗證的流程。
技術預覽階段的自動化調度器可在同一工作流程中串聯事件偵測、 AI 推理、人工審核與確定性執行，並留下端到端的稽核紀錄。 Ansible 的 MCP 伺服器則讓 AI 工具連接企業既有的自動化內容，不必為每一套代理工具重新開發整合。這使 AI 不必直接在生產環境任意嘗試，而是透過企業已知、可重複且可控管的方式採取行動。
主權 AI 重點不是全部自建，而是保留控制權
當企業能管理模型、 Token 及代理行動後，控制權還必須延伸至資料與基礎架構。若 AI 工作負載完全受制於單一模型、雲端或硬體供應商，即使內部治理完善，企業仍可能因服務條款、地緣政治或供應商策略改變而失去選擇。
孫媛音以開餐廳為例說明，經營者不必自行興建發電廠，但必須知道食材來源、掌握經營方式，並確保流程符合安全與法規要求。企業同樣可以採用不同模型、 GPU 及雲端服務，但資料位置、營運政策、模型生命週期及最終選擇權仍應掌握在自己手中。
Red Hat 擴充主權雲與私有雲功能，以 Red Hat OpenShift 、 RHEL 、 Ansible Automation Platform 及 Red Hat AI 作為統一基礎，支援地端、私有雲、主權雲與氣隙環境。企業可在 OpenShift 上提供 GPU 即服務、模型即服務與推論即服務，並把成本管理遙測資料完整保留於自身控制的環境內。
對 Red Hat 而言，主權 AI 不等於把所有工作負載搬回自有機房，而是讓企業能依資料敏感度、延遲、成本與法規要求決定部署位置，並在必要時移轉模型、算力及服務供應商。
控制權延伸至作業系統與安全基礎
Red Hat 也將控制權向下延伸至作業系統。預計推出的 RHEL 10.2 與 9.8 導入後量子密碼學 (Post-Quantum Cryptography, PQC) 、機密運算及 AI 輔助升級，協助企業保護 AI 工作負載與敏感資料。
RHEL 新增的封閉映像檔 (Sealed images) 技術預覽，可讓企業在建置階段簽署映像檔，並以硬體信任根確保系統只啟動經過驗證的內容。 Red Hat Satellite 6.19 也為氣隙環境提供在地漏洞分診，使無法持續連接外部服務的關鍵系統仍能進行漏洞管理。
曹衡康所說的「平台」，因此不只是一個承載模型的運算環境，而是讓企業在 AI 快速演進、代理開始採取行動後，仍能掌握成本、身分、權限、資料與執行流程。從 MaaS 管理模型與 Token，到 AgentOps 追蹤代理，再由 Ansible 約束實際行動，Red Hat 爭取的不是單一模型市場，而是企業 AI 進入生產環境後的控制平面。
對企業而言，真正的選擇權也不只是能選擇哪一個模型，而是在任何模型、硬體與雲端之間，始終保有改變選擇的能力。