Models-as-a-Service ガイド

AI に対する関心は急速に拡大しており、組織は、大規模言語モデル (LLM)、予測分析、ビジョン機能などの高度なツールを活用してビジネス価値を引き出すことに意欲的です。しかし、隔離された実験環境から組織への広範な導入へと AI を移行するには、インフラストラクチャと運用において大きな課題が生じます。

多くの組織は、OpenAI や Anthropic などの商用 LLM アプリケーション・プログラミング・インタフェース (API) に接続することから AI 導入の取り組みを開始します。それがプロダクション環境に導入する最速の手段だと考えられているからです。しかし、利用が拡大するにつれてコストが増加し、チームはデータのプライバシー、可観測性、カスタマイズに関する制限に直面します。さらに、商用 AI プロバイダーが事前の警告なしにモデルを変更することがあり、組織のビジネスでの使用に混乱をもたらすケースもあります。

それとは対照的に、独自のモデル・インフラストラクチャをゼロから構築している組織もあります。このような DIY では、多くの場合、各チームが個別に Llama や Mistral などのオープンソースモデルをデプロイし、ほとんど連携されない状態になります。その結果、複数のグループがそれぞれ独自のスタックを立ち上げるという断片化が生じ、冗長なインフラストラクチャ、アイドル状態の GPU (グラフィックス・プロセッシング・ユニット)、運用上の多大なオーバーヘッドが発生します。これではセキュリティとガバナンスが損なわれ、コストが上昇する一方、大きなビジネス価値がもたらされることはありません。

Llama、DeepSeek、Mistral、Qwen など、最近の LLM の規模は拡大しているため、これらの課題はさらに深刻になっています。わずか数年前の比較的小規模な AI モデルとは異なり、今日の大規模なモデルにはテラバイト規模の vRAM が必要になります。そして、そのような GPU は高価です。これらのリソースの使用効率が悪ければ、すぐにコストが高騰してしまいます。同じ組織内の複数のチームが個別にこれらのモデルをデプロイしようとすると、状況はさらに悪化します。このように断片化したアプローチでは運用上のオーバーヘッドが積み重なり、支出が増大します。

組織に必要なのは、モデルの使用を効率化および統合し、ハードウェアリソースを最適化し、多様な社内ユーザー向けに制御されたスケーラブルなアクセスを提供する、社内向けのアプローチです。このようなアプローチがなければ、AI イニシアチブには低い導入率と高い運用コストというリスクが伴い、インフラストラクチャへの投資を十分活用できなくなります。これでは、生産性の向上、運用コストの削減、知見を得るための時間の短縮など、測定可能な成果を達成することは困難になります。

Models-as-a-Service (MaaS) は、AI モデルを一度デプロイするだけで、セキュリティを重視した共有リソースとして組織全体に提供できるように支援するアプローチです。チームごとに個別のデプロイを管理するのではなく、AI インフラストラクチャと運用を一元化できるため、社内での AI 導入が単純化されます。

一元化されたモデル運用で AI への共有アクセスを提供

• AI エンジニアは、MaaS を使用することで API を介して高性能なモデルにすばやくアクセスできるようになります。これにより、モデルのダウンロード、依存関係の管理、時間のかかる IT チケットによる GPU 割り当てリクエストが不要になります。

MaaS では、AI 運用チームが共有 AI リソースの一元化されたオーナーとなります。モデルは、スケーラブルなプラットフォーム (Red Hat® OpenShift® AI やその他の類似のプラットフォームなど) にデプロイされ、API ゲートウェイを介して公開されます。この設定により、複数のユーザー、開発者、事業部門がエンドユーザーに単純化されたアクセスを提供でき、IT チームと財務チームのセキュリティおよびガバナンスの優先事項に対応できます。この優先事項には、チャージバック機能や、ハードウェアへの直接アクセスや深い技術的専門知識を必要とせずにモデルを利用できることなどが含まれます。目標とするのは、GPU やテンソル・プロセッシング・ユニット (TPU) などのモデル実行に必要なリソースではなく、AI モデルに簡単にアクセスできるようにすることです。このすべてを、エンタープライズ・パフォーマンスとコンプライアンスの要件を満たしながら、エンドユーザーのアクセスを複雑にすることなく実現します。

実際には、ユーザーはモデルが生成した応答を提供する API とのみやり取りします。パブリック AI プロバイダーがハードウェアの複雑性を抽象化するのと同様に、MaaS の社内デプロイもエンドユーザーにシンプルさを提供します。ユーザーは、ハードウェアやソフトウェア・インフラストラクチャを直接管理することはなく、IT チケットが解決されるのを待ったり環境が構成されるのを待ったりすることもありません。IT 運用チームと AI チームは、モデルのライフサイクル、セキュリティ、更新、インフラストラクチャのスケーリングを一元的に管理し、最適化されながらも制御されたアクセスをユーザーに提供できます。

この一元化により、社内の AI 運用が効率化されるだけでなく、セキュリティ重視とガバナンスも強化されます。AI モデルへのアクセスは、API ゲートウェイを介した認証情報管理により厳密に制御されます。組織は容易に使用量を追跡し、社内のチャージバック・メカニズムを設定し、プライバシーのコンプライアンス・ガイドラインに準拠していることを確認し、明確な運用上の境界を確立できます。これにより、エンタープライズ AI は実用的で管理しやすいものになります。使用量の追跡は、トークンレベル (入力と出力) で行うのが最も正確で粒度の小さい方法で、GPU レベルのメトリクスよりもはるかに正確です。

使用量の制御、アクセスのスロットリング、コストの管理

• IT エンジニアやプラットフォームエンジニアは一元的な監視によるメリットを得られます。これにより、モデルの不正デプロイの防止、セキュリティおよびコンプライアンス標準の適用、ライフサイクルおよびインフラストラクチャ管理の単純化が実現します。
• 財務チームについては、一元化された使用量の追跡と社内チャージバック・メカニズムによって無駄が減り、GPU の使用の予測可能性と説明責任が向上します。これにより、使用率の低い、チームごとのハードウェア割り当てによる過剰な支出を回避できます。

MaaS における制御は、主に API ゲートウェイを AI インフラストラクチャに統合することで実現します。これにより、チームは AI の使用を粒度が極めて小さいレベルで管理および監視できます。

従来の AI のデプロイでは、管理されていない方法や非効率的な方法で使用されることが多く、それが課題となります。一元的に監視されることなく個人やチームが個別にモデルをデプロイするからです。このような断片化したアプローチでは、GPU リソースがアイドリング状態となったり、十分に活用されなかったりするため、コストがかかり非効率的になる可能性があります。API ゲートウェイを AI インフラストラクチャの中心に据えると、ユーザーとモデル間に制御されたアクセスポイントが生まれます。

この設定により、個々のトークンレベルまで、使用状況の正確な追跡が容易になります。チームは、各ユーザー、チーム、またはアプリケーションが消費する量を明確に特定し、GPU とインフラストラクチャのコストを正確に特定できます。たとえば、組織は特定のユーザーまたはアプリケーションがリソースを過剰に使用しているかどうかを判断して、使用量をスロットリングしたり社内のチャージバック・メカニズムを通じてコストを割り当てたりするなど、修正措置を講じることができます。

API ゲートウェイによるスロットリング機能は、一貫したパフォーマンスを確保してリソースの枯渇を防ぎます。スロットリングを使用すると、IT チームはアクセスの負荷を管理できます。これにより、1 人のユーザーが GPU リソースを独占したり、他のユーザーのパフォーマンスが低下したりするのを防ぐことができます。

さらに、API ゲートウェイによって認証情報のきめ細かい管理とアクセス制御が可能になります。社内ユーザーは認証情報を生成して個別に AI モデルにアクセスできるため、管理オーバーヘッドを最適化できます。また、セキュリティ要件や使用パターンの変化に対応して、認証情報の取り消しや修正を短時間で行うことができます。

これらはすべて、コスト管理の透明性と説明責任の向上につながります。IT チームは、GPU とインフラストラクチャの費用を、それらを使用するチームや事業部門に正確に割り当てることができます。

あらゆるモデル、アクセラレーター、クラウドをサポート

MaaS アプローチの中心的な原則は、制御性です。組織は幅広い AI モデルから選択してデプロイし、好みのハードウェア・アクセラレーターを選択し、既存のクラウド環境やオンプレミス環境内で運用することができます。このアプローチにより、組織は技術的なニーズ、セキュリティ要件、運用上の好みに応じて AI を自由に実装することができます。

• AI を導入する際、組織は厳しい制限に直面します。主な制限は次のようなものです。
  • 特定のクラウドサービスに制限される
  • プロプライエタリーなモデルのエコシステムに縛られる
  • 固定されたハードウェア・インフラストラクチャの制約を受ける
• MaaS は、次のようなさまざまな方法でこれらの制限に対処します。
  • オープンソースまたはプロプライエタリーなモデル、カスタムのトレーニングが実行されたモデル、一般的な LLM (Llama や Mistral など) のサポート
  • テキストベースのモデルにとどまらず、予測分析、コンピュータビジョン、音声テキスト変換ツール、画像や動画生成などのマルチモーダル生成 AI のユースケースへの拡張
• MaaS はハードウェア・アクセラレーターに依存しないため、次のことが可能です。
  • ワークロード、コスト構造、パフォーマンスのニーズに合わせて、GPU やその他のアクセラレーターを選択できる
  • 一元化された AI チームでサイジングやデプロイに関する重要な意思決定を行うことができるため、効率が向上し、技術知識の乏しいユーザーによるエラーが減少する
• 一元管理により、次のことが可能になります。
  • インフラストラクチャの最適な割り当てと使用
  • 運用オーバーヘッドの削減とリソースの構成ミスの防止
• MaaS は、次のようなあらゆる環境でのデプロイをサポートします。
  • オンプレミス、ハイブリッドクラウド、エアギャップ環境、パブリッククラウド。データ主権、法令順守、厳格なセキュリティ制御を必要とする、規制の厳しい業界では特に有益です。

Red Hat は社内に MaaS を取り入れ、AI モデルのデプロイとアクセスを一元化しました。Red Hat の社内 AI チームは、Red Hat OpenShift と Red Hat OpenShift AI を基盤となるプラットフォームとして使用し、AI リソースとモデルの運用を一元管理しています。この一元化されたモデルデプロイメントにより、組織全体のユーザーによる AI の使用が単純化され、開発者やビジネスチームは専用のハードウェアや深い技術的知識を必要とせずに AI 機能をワークフローに効率的に統合することができます。

当社の実装は、OpenShift AI 内で GPU を使用し、一元化された API ゲートウェイを介してユーザーを接続する、スケーラブルなサービス提供アーキテクチャを特徴としています。これにより、AI モデルへのアクセスが制御され、セキュリティ重視で追跡可能なものとなります。使用量はトークンベースの監視を通じて慎重に管理され、誰がモデルをどの程度の頻度でどれだけの量を使用しているのかを正確に追跡することができます。その結果、ハードウェアの使用が最適化され、GPU リソースの不要な消費が削減されます。また、詳細な知見が提供されるため、さまざまな社内チームやプロジェクト間でコストを正確に割り当てることができます。

Red Hat の MaaS の実装では GitOps ワークフローを使用し、高可用性と信頼性を実現しています。この運用アプローチにより、人手による介入や潜在的なエラーが減少し、AI のデプロイに対する明確な制御が確立されます。

Red Hat の社内 MaaS 導入の主なメリットとして、リソース効率とユーザーエクスペリエンスの大幅な改善が挙げられます。複数のチームが個別に GPU のプロビジョニングとモデルのデプロイを行うのではなく、MaaS によって重複する作業が排除され、社内業務が最適化され、価値実現までの時間が大幅に短縮されました。新しいモデルのテストと検証が完了すると、ハードウェアの割り当てやプロビジョニングのタスクに時間を取られることなく、Red Hat チームはすぐにモデルを統合して使用することができます。

AI の提供を単純化し、インフラストラクチャへの投資から真の価値を引き出す準備はできていますか？まず、MaaS の仕組みに関する詳細な説明をご覧ください。そして OpenShift AI の製品ページをご覧になり、プラットフォームの機能を評価し、GPU の使用に関するガイダンスをご確認ください。

社内で MaaS を構築しているチームのために、Red Hat コンサルティングは、組織のニーズに合わせたモデル提供環境の設計と運用化を支援します。詳細については、AI 向け Red Hat コンサルティングのページをご覧ください。

実際の例をより包括的に知りたい場合は、MaaS に関するセッションを含むオンデマンド Web セミナーシリーズをご覧ください。