產品新訊

Red Hat AI 3.4 重磅升級(下):讓 AI 品質可量測、成本可控、部署更彈性

Red Hat 紅帽
2026/07/09

Gartner 近期報告指出,超過 80% 的企業在將 GenAI 與 AI Agent 推向規模化生產時,面臨著「成本難以預測」與「輸出品質不穩定」的雙重瓶頸。到 2028 年,更有高達一半的 GenAI 專案可能會超出預算。

當企業 AI 應用從概念驗證(PoC)走向全面落地,考驗的不再只是模型有多聰明,而是底層架構的治理能力。為了讓您全面掌握 Red Hat AI 3.4 的關鍵升級,Red Hat 台灣總代理-MetaAge 邁達特透過上、下篇系列文章帶您完整了解 Red Hat AI 3.4。

上篇已探討 Red Hat AI 3.4 在 Agent 治理方面的核心機制:AgentOps 生命週期管控、SPIFFE/SPIRE 身份驗證,以及 Chatterbox Labs 與 Garak 的安全防護。上述能力均解決了「Agent 能不能被信任」的問題。

延伸閱讀:Red Hat AI 3.4:當 AI Agent 開始自主運作,企業的治理基礎準備好了嗎?(上篇)

不過,當企業 AI 落地時,還有另一半的棘手挑戰:模型的輸出品質夠不夠穩定?成本有沒有辦法預測與控制?推論基礎設施能不能隨需求彈性擴展?這正是 Red Hat AI 3.4 下篇(本篇)將談的主題:用四大升級核心,破解企業 AI 落地的深水區難題。


核心一:讓 AI 品質可量測,Eval Hub 統一評估控制平面

許多企業在導入 AI 時面臨一個共同困境:模型到底表現得好不好,沒有一套客觀的衡量標準。不同團隊用不同的方式測試、不同工具評估,結果難以比較,更難以在版本迭代時持續追蹤品質變化。這個問題在 Agent 身上更嚴重,因為 Agent 的行為鏈條更長、涉及更多工具呼叫,任何一個環節出問題都可能影響最終結果,卻沒有統一的方式去量測。

Eval Hub:一套 API,統一評估整個 AI 生命週期

Red Hat AI 3.4 推出的 Eval Hub,是一個框架無關的統一 AI 評估控制平面。無論企業使用什麼 AI 框架,舉凡 LangChain、AutoGen、Haystack 或自研框架,都可以透過同一套 REST API 與 Kubernetes controller 進行評估,不需要為每個框架建立獨立的測試流程。

Eval Hub 內建了 MLflow dashboard,讓評估結果有可視化的呈現介面,並提供 CLI 與 SDK 存取,方便整合進 CI/CD 流程。對 AI 工程師來說,這意味著模型品質的評估從「手動、臨時、難以重現」,變成了「自動化、持續、可追蹤」。

更重要的是,Eval Hub 的評估對象不限於 LLM 本身,而是涵蓋整個 AI 應用與 Agent。換言之,它量測的不只是模型,而是「模型加上工具呼叫、加上 prompt 策略、加上記憶機制」組合起來的整體表現。這才是企業真正需要知道的品質維度。


核心二:把 Prompt 當資產管理,MaaS 與 Prompt Registry

在大多數企業的 AI 實踐中,prompt 是一個混亂的存在:散落在各個工程師的筆記本、程式碼裡,沒有版本控管、沒有審核流程、更沒有辦法追蹤「這個 prompt 改了之後,模型的輸出品質有沒有變好」。

Prompt Registry:讓 Prompt 成為一等公民

Red Hat AI 3.4 在 MaaS(Model as a Service)框架下,新增了集中式的 Prompt Registry,意即把 prompt 視為需要版本控制、需要審核、需要持續評估的企業資料資產。每一個 prompt 的修改都有記錄,每一個版本都可以和評估結果對應,讓 prompt 工程從「個人技藝」變成「可管理的工程實踐」。

MaaS:統一管控內部模型與外部 API

MaaS 的更大意義在於統一治理層。企業往往同時使用自建模型(跑在內部 GPU 上)與外部模型 API(OpenAI、Anthropic、各家雲端服務),這兩條路徑的存取方式、計費方式、安全政策完全不同,管理起來非常破碎。

MaaS 在這兩者之上提供了一個受治理的統一介面:統一的存取控制、統一的用量追蹤、統一的配額管理。IT 部門不再需要為內外部模型各自建立一套管理機制,而是透過同一個控制平面,掌握企業全域的模型使用狀況。


核心三:從黑盒到透明,MLflow 與 OpenTelemetry 的端對端追蹤

「Token 用量暴增,但我不知道是哪個應用在消耗。」這是許多企業 AI 負責人的日常困境。推論成本不透明,是企業 AI 規模化最常見的隱形地雷。

Red Hat AI 3.4 則透過整合 MLflow 與 OpenTelemetry,為企業提供端對端的 AI 可觀測性。每一次 LLM 呼叫、每一個推論步驟、每一個模型回應,都會被追蹤記錄:消耗了多少 token、延遲了多少毫秒、哪個 Agent 觸發了哪個工具呼叫。

這套追蹤能力有兩個實際意義:

  • 成本歸因:清楚知道哪個部門、哪個應用、哪個 Agent 在消耗推論資源,讓成本分攤和優先順序決策有數據可依。

  • 異常診斷:當某個 Agent 的回應品質忽然下滑,可以透過追蹤記錄快速定位問題。例如:是 prompt 被修改了、是模型版本換了、還是某個工具呼叫失敗了。

對於維運團隊來說,AI 可觀測性不是錦上添花,而是在規模化之後必然需要的基礎能力。沒有可觀測性,成本控制就只能靠猜。


核心四:推論基礎設施升級!從單節點到分散式、從 OpenShift 到任意 Kubernetes

當企業的 AI 應用從少數幾個 PoC,進入大規模生產後,推論基礎設施的彈性與效率就成了關鍵瓶頸。單一推論伺服器節點應付不了突增的並行請求;而把整套平台綁在特定雲端或特定硬體上,也限制了企業的靈活性。

Red Hat AI Inference:從伺服器到分散式推論引擎

Red Hat AI 3.4 將原本的 Inference Server 升級為 Red Hat AI Inference,意即在既有的 vLLM 推論引擎基礎上,加入了 llm-d 驅動的分散式推論編排能力。llm-d 是由 Red Hat 領導貢獻的開源專案,專為在 Kubernetes 上進行大規模 LLM 推論優化而設計,能夠跨節點進行請求排程與負載平衡,顯著提升高吞吐量場景下的推論效率。

跨越平台限制:CoreWeave、Azure 上的任意 Kubernetes

更重要的是,Red Hat AI Inference 不再侷限於 OpenShift 環境,而是可以在任何符合標準的 Kubernetes 平台上運行,包含 CoreWeave 與 Microsoft Azure 託管的 Kubernetes 叢集。這對於已在特定雲端環境投入資源、或是有多雲部署需求的企業來說,意味著可以把 Red Hat 的推論能力帶到既有的基礎設施上,而不是被迫重建環境。

硬體支援:NVIDIA Blackwell 與 AMD MI325X 的 Day-0 支援

在硬體層面,Red Hat AI 3.4 提供對 NVIDIA Blackwell GPU 架構與 AMD MI325X 的 Day-0 支援,意即這些硬體在正式上市的同一天,就能與 Red Hat AI 平台完整整合,企業不需要等待額外的驅動支援或相容性認證窗口。

對於計劃在 2025–2026 年採購新一代 GPU 的企業而言,這份支援保證降低了「買了硬體卻發現平台還沒跟上」的風險,也讓硬體投資可以更快轉換為實際的推論產能。


核心五:MCP Catalog 讓 Agent 工具整合有治理依據

AI Agent 的能力邊界,取決於它能呼叫多少工具。MCP(Model Context Protocol)是近年來快速普及的 Agent 工具整合標準,讓模型能夠以標準化的方式連接外部資料源、API 與服務。然而,在生產環境中部署 MCP Server,過去需要大量的手動配置工作,且缺乏統一的審核與治理機制。

Red Hat OpenShift AI 3.4 推出的 MCP Catalog,提供了一個受治理的 MCP Server 部署路徑。平台工程師可以在 Catalog 中探索、審核、並部署已驗證的 MCP Server,AI 開發人員則可以直接在 OpenShift 上連接這些 Server,而不需要自行處理底層的部署細節。

這個機制讓「哪些工具可以被 Agent 使用」的決定,從個別工程師的自由裁量,變成了平台層級的治理決策——與企業的安全政策對齊,而不是繞過它。

圖:MCP Server 生命週期的四個階段——SELECT、DEPLOY、CONNECT、CONSUME(資料來源:Red Hat OpenShift AI 3.4 官方文件)


快速總覽:Red Hat AI 3.4 核心升級效益對照表

功能模組

解決痛點

商業價值

Eval Hub

  • 各團隊評估標準不一

  • Agent 品質難以量測

統一評估平面,自動化追蹤 AI 全生命週期品質

Prompt Registry

  • Prompt 散落各處

  • 缺乏版本控管與審核

Prompt 資產化,讓變更與效果可追蹤、可稽核

MaaS 控制平面

  • 內外部模型管理破碎

  • 計費與權限混亂

統一入口,精確控管全域模型配額與存取安全

MLflow & OpenTelemetry

  • Token 消耗與延遲形同黑盒,成本無法歸因

提供端對端可觀測性,精準實現成本歸因與異常診斷

Red Hat AI Inference

  • 單節點推論效能瓶頸

  • 綁定單一雲端環境

支援 llm-d 分散式推論,相容任意 K8s 及新一代硬體

MCP Catalog

  • Agent 呼叫外部工具缺乏治理,衍生資安風險

建立受治理的工具型錄,符合企業安全合規政策


總結:從「能跑 AI」到「會管 AI」,邁向生產級成熟期

綜合上下兩篇,Red Hat AI 3.4 的核心主張可以用一句話概括:企業 AI 的成熟,不在於模型有多聰明,而在於圍繞模型的治理體系有多完整。

上篇解決的是「能不能信任 Agent 的行為」,透過 AgentOps、SPIFFE/SPIRE 與安全防護機制,建立 Agent 的可控性與可追責性。

下篇解決的則是「能不能持續管好 AI 的品質與成本」,透過 Eval Hub、Prompt Registry、MaaS、全面可觀測性,以及更彈性的推論基礎設施,讓 AI 從實驗性的試跑,走向可持續、可量測、可擴展的生產級運作。

對於正在規劃或已經啟動 AI 規模化的企業而言,這些能力不是可選的加分項,而是讓 AI 投資能夠持續兌現價值的基礎條件。


免費諮詢 Red Hat 台灣總代理 – MetaAge 邁達特

有高達 50% 的 GenAI 項目,因缺乏運行治理與架構不當,正面臨著成本失控。

您是否想進一步了解 Red Hat AI 3.4 如何在您的 IT 環境中落地?MetaAge 邁達特是 Red Hat 台灣總代理,擁有近 30 年雲地整合、混合多雲治理的實戰經驗。MetaAge 邁達特不僅提供產品授權,更專精於規劃、導入與客製化您的 AI 基礎設施策略,確保平台效益能在您的環境中真正持續擴展。

您可由此填寫【免費諮詢表單】聯繫 MetaAge 邁達特顧問團隊,讓 MetaAge 邁達特的 Red Hat 認證工程師為您量身打造以 AI 為核心的混合雲架構策略,助您掌握企業 AI 部署全局。

聯絡 我們