Red Hat AI 3.5、本番運用へ向けてAIの評価・GPU管理・可観測性を拡充

Red Hat AI 3.5は、新しい単一モデルやチャットボット機能を前面に出したリリースではない。狙いは、AIをPoC（概念実証）から、統制された本番サービスへ移すための運用基盤を整えることだ。Red Hatは2026年9月9日に同リリースを発表し、9月11日のまとめでも、安全性、運用制御、性能の透明性を重視する姿勢を示した。4315

最大の変更点：EvalHubが一般提供に

本番導入の準備という観点で最も重要なのが、モデル／エージェント評価ツールキット EvalHub の一般提供（GA）だ。顧客が持ち込む、またはカスタマイズしたモデル、検索拡張生成（RAG）の構成、AIエージェントを対象に、プロンプトインジェクションやジェイルブレイクといったリスクを想定した安全性テストを実行できる。結果から、規制対応を意識した認証用の成果物も作成できる。13

試作段階で動くことと、業務システムに載せられることは別問題である。EvalHubは、各アプリケーションチームが個別にテストや記録の仕組みを作るのではなく、展開前の評価を反復可能な工程として組み込むことを目指す。

検証済みモデルのカタログも20以上のモデルを追加し、Google、NVIDIA、Alibaba Cloudのモデルを含めた。カタログ評価には、Garakベンチマークの結果に加え、有害性や個人識別情報（PII）露出の可能性を示す指標が含まれる。モデル選定時の判断材料を増やす狙いだ。34

共有GPUを「管理できるサービス」に近づける

AIの実証実験は、専用インフラを限られた利用者だけで使う形になりがちだ。一方、本番では複数ワークロードの競合、サービスの優先順位、コストの負担先を扱わなければならない。

Red Hat AI 3.5では、共有GPU環境向けにフェアシェア・スケジューリング、優先度を考慮したサービング、アドミッション制御、優先度ベースのリクエストルーティングを追加した。48

ユーザーごとのトークン計測も導入され、推論の健全性、GPU使用率、モデル性能を示すダッシュボードが提供される。プラットフォーム運用チームは、誰が容量を消費しているか、サービングのどこに問題があるかを把握し、チーム単位でのコスト配賦にもつなげられる。414

NVIDIA GPUを中心に運用する組織にとっては、モデルサービングをKubernetes上で運用するための実務的な層が拡張された形だ。Red Hat AI Inference 3.5では、NVIDIA CUDA向けに最適化された推論イメージが一般提供されるほか、AMD ROCm、Google TPU、Intel Gaudi、IBM Spyreも対象となる。35

RAGとエージェント向け機能も拡張。ただしGAではない機能がある

Red Hat AI 3.5は、検索拡張生成とエージェント型アプリケーションのツールも強化した。AutoRAG は、英語以外や複数言語が混在する文書コレクションに対応し、言語検出、言語を考慮したチャンク分割、多言語埋め込みモデルを最適化の探索対象に追加する。1

AutoRAGは、文脈を踏まえた検索、対話テスト、視覚的デバッグなどを通じ、RAGパイプラインの評価・チューニングを支援するものとして位置づけられている。もっとも、AutoRAG自体は**Technology Preview（テクノロジープレビュー）**であり、一般提供機能ではない。本番サービスの基盤に採用する際は、このサポート状況を考慮する必要がある。13

AI Hubには、コードレビュー、文書処理、リサーチなどのワークフローの出発点となるテンプレートも含まれる。43

OpenShift以外も視野に入るハイブリッドクラウド推論

llm-dを使う分散推論では、マネージドKubernetes上での配置先が広がる。Red Hatの文書では、Azure Kubernetes Service（AKS）、CoreWeave Kubernetes Service（CKS）、Amazon Elastic Kubernetes Service（EKS）が対象に挙げられ、Kubernetes 1.33以降とGPUノードの準備が要件とされる。37

ただし、3つの環境でサポート状況は同一ではない。Amazon EKS上のllm-d分散推論はTechnology Previewと明記されており、本番向けSLAの対象外で、本番利用は推奨されていない。39 一方、Red Hat AI Inferenceの文書では、AzureとCoreWeave Kubernetes Service向けのデプロイ手順が示されており、今回のリリースで本番運用を検討する際の対応経路となる。40

企業のAI運用で何が変わるのか

Red Hat AI 3.5は、PoCでは別々に扱われやすい4つの領域を、一つのプラットフォームの方向性としてまとめている。

1. 導入前の信頼性確保：独自モデル、RAG、エージェントを安全性リスクの観点で評価し、監査可能な成果物を作る。13
2. 稼働中の統制：フェアネスと優先度のポリシーで共有GPUを割り当て、トークン消費を計測する。4
3. 運用時の可視化：推論、利用率、モデル性能のダッシュボードで、サービス稼働後も状態を管理する。14
4. インフラ横断の選択肢：複数のアクセラレータスタックで最適化推論を実行し、サポート対象のKubernetes環境へ分散推論を展開する。3540

Red Hatはこれらを、ハイブリッド環境にまたがるAIを、個別の実験の寄せ集めではなく、共有の企業インフラとして扱うための運用基盤と位置づけている。43

Lightwellは関連するが、AI 3.5の機能ではない

IBMとRed Hatの広い「信頼性」戦略には、脆弱なサードパーティー製オープンソース依存関係を対象とする共同イニシアチブ Lightwell もある。9月にはLTMが、AIを活用した脆弱性修正を巡り、IBMおよびRed HatとLightwellで協業したと発表した。2425

これはRed Hat AI 3.5の機能ではなく、ソフトウェアサプライチェーンのセキュリティに関する別の取り組みである。ただし、検証と運用リスクの低減を重視する両社の方向性を示す事例ではある。

まとめ

Red Hat AI 3.5の中心的な価値は、AIを本番稼働させた後の現実的な運用にある。EvalHubによる導入前評価、共有アクセラレータ基盤の統制、ハイブリッド環境でのモデルサービングの監視を、プラットフォームチーム向けにまとめた。

特にEvalHubのGAは大きな変更点だ。一方で、AutoRAGとAmazon EKS上の分散推論はTechnology Previewにとどまる。導入を検討する企業は、機能の有無だけでなく、各コンポーネントが一般提供か、どの本番サポートの対象かを分けて判断する必要がある。1339