エージェント型 AI にオープンな推論スタックが必要な理由

「今この瞬間も、御社にサービスを提供している AI ラボはすべて赤字を出しています。彼らもそれを承知の上で、あえてそうしているのです。」

それは、ある記事の冒頭の一文でした。その記事が私の受信箱に届いたのと同じ週に、3 つの数字が明確になり、オープンな推論がもはや選択肢ではなくなった理由が明らかになりました。

ある開発者が、オープンソースのコーディングエージェントと直接の API キーを使用して、週末にシンプルなメモアプリを構築しました。ページは1つ、機能も1つだけ。費用は50ドル。費用： 50 ドルその翌日、20 ドル/月のサブスクリプションにより 50 倍のトークンが提供されました。

Red Hat の推論チームのあるエンジニアは、オープンウェイトモデルで 3 億トークンを 2 日間で消費しました。これは、プロプライエタリーな API を使用すれば数千ドルのコストがかかる作業と同じ内容でした。

最初の 2 つの数字は補助金に相当し、3 番目は解決策を示します。そして、Red Hat がその解決策を必要としている理由はエージェントにあります。

過渡期にある価格モデル

最先端のモデルプロバイダーは、目覚ましい成果を上げています。これらのプロバイダーは、2 年前には考えられなかったような価格設定で、世界クラスの AI を数百万人の開発者が利用できるようにしました。その利用しやすさが、AI の導入を爆発的に拡大させました。しかし同時に、現在のペースでは持続不可能となる可能せいのある経済構造も生み出しています。

Is AI profitable yet? という Web サイトは、AI 業界の一般的な財務状況を追跡しています。AI 企業は現在、収益の約 195% を支出に充てています。この議論へのある寄稿者は、2024 年のドル換算で、10 年間の AI 関連の設備投資総額が米国の 州間高速道路システム関連の費用の約 3 倍に相当すると試算しました。こうした投資は、最終的にサービス価格に反映されることになるでしょう。

その移行の兆候はすでに現れています。 一部の大型企業が、定額制のサブスクリプションに代わってトークンベースの課金方式が導入され、エンジニア 1 人あたりのコストが月額 500 - 2,000ドルに達していることを受け、AI コーディングツールのライセンスを見直しているという報告が広まっています。最新のフロンティアモデルは、ベンチマークの改善がわずかである一方で、タスクあたりのトークン消費量は 10% - 25% 増加しています。GPU の供給はすでに 3 - 4 年先まで確保されており、複数の GPU クラウドプロバイダーではすでに容量が売り切れ状態になっています。

これらはプロバイダーを批判するものではありません。プロバイダーは未来を構築しており、導入を加速するために積極的な価格設定を行っています。トークンあたりのユニットコストは今後も低下し続ける可能性が高く、Gartner は 2030 年までに 90% 削減されると予測しています。しかし、この分析が指摘するように、エージェント型ワークロードはタスクあたりに消費するトークンが非常に多いため、ユニットコストが低下しても、企業における推論の総支出額は増加することが予想されます。 Goldman Sachs は、2030 年までにトークン消費量が 24 倍に増加すると予測しています。今後 3 - 5 年の計画を立てている企業は、総コストの低下ではなく、上昇に備える必要があります。セルフマネージド型インフラストラクチャで実行されるオープンソースモデルは、消費規模が拡大しても AI のアクセシビリティを維持するための安全弁となるでしょう。

図 1： エージェント型推論のコストのパラドックストークンあたりのコストは 90% 低下するが (Gartner)、総消費量は 24 倍に増加し (Goldman Sachs)、ユニットコストが安くなっても企業の総支出額は増加します。

エージェントによる方程式の書き換え

サブスクリプションの価格設定は、人が人のスピードで入力することを想定して設計されています。エージェントは桁違いに多くの API 呼び出しを生成しますが、既存の価格モデルはそのような事態を想定して構築されていません。

ある OpenClaw のコントリビューターは、わずか 1 か月で 130 万ドルに相当する OpenAI API トークンを消費しました。これは、3 人で運用する約 100 の Codex インスタンスからの 760 万件のリクエストに対する 6,030 億トークンに相当します。1 日だけで、該当アカウントは 19,985.84 ドルの支出を記録しました。

Jensen Huang 氏は、エージェントによるトークン消費量は従来のモデルの使用と比較して約 1,000 倍に増加したと述べています。Latent Space ポッドキャストにおいて、Marc Andreessen 氏は、自身の周囲ではエージェントを実行する Claude トークンに 1 日あたり 1,000 ドルを費やしており、完全にデプロイされたパーソナルエージェント 1 台あたり 1 日 5,000 ドルから 10,000 ドルの潜在的な需要があると述べています。価格が 10 分の 1 に改善されたとしても、依然として 1 日あたり 100 ドルかかります。「依然として、人々が支払える金額をはるかに超えています」

一部のプロバイダーは、計算需要が価格モデルの維持可能な範囲を超えたため、定額制サブスクリプションでのサードパーティのエージェントフレームワークの実行をすでに制限せざるを得なくなっています。定額制の価格設定と自律型エージェントのワークロードの間には、構造的にミスマッチが存在します。

コストは問題の一部にすぎません。エージェント型ワークロードには、プロプライエタリーな API が公開することを想定していない技術的な要件があります。

API の断片化エージェント型 API の領域には、複数の競合する標準が存在します。Chat Completions (OpenAI の従来のステートレス形式)、Responses API (組み込みツールと Model Context Protocol 統合を備えた OpenAI の新しいステートフル形式)、Messages API (Anthropic の形式)、Interactions API (Google のエージェント型プロトコル) などがあります。それぞれが、ツールの呼び出し、状態管理、推論を異なる方法で処理します。各ハーネスは、それぞれ異なるものを選択します。

また、各モデルファミリーは、同じツール呼び出しをまったく異なるタグでラップします。get_weather(city="Seattle") を 5 つのモデルに送信すると、5 つの異なる形式が生成されます。Llama は <|python_tag|> を含む Python 構文を使用し、Mistral は JSON 配列の [TOOL_CALLS] を使用し、Gemma は タグを使用し、Hermes は XML を使用します。推論エンジンには、モデルファミリーごとに個別のパーサーが必要です。

ツール呼び出しプロプライエタリーな API を使用する場合、プロバイダーが提供するパーサーをそのまま使用することになります。それをカスタマイズすることはできません。学習済みの形式ではなく Python 構文を出力するモデルを修正することはできません。ユーザーに制御権はありません。

モデルのルーティング1 回のエージェント実行で、高度な推論、迅速な分類、コード生成を必要とするものなど、性質の異なるさまざまなサブタスクが生成されます。これらのタスクを異なるモデルにルーティングするには、提供レイヤーを制御する必要があります。単一プロバイダーの API を使用する場合、すべてのタスクが同じモデルに送られ、同じ価格が適用されます。

コンテキストエンジニアリング多数のターンにわたってモデルに渡される情報を管理することは、現在利用可能な最適化手法の中で最も効果が高いものです。適切に調整されたコンテキストパイプラインは、出力の品質を向上させながら、トークン使用量を 60% - 80% 削減できます。しかし、効果的なコンテキストエンジニアリングを行うには、推論レベルでモデルの動作を把握する必要があります。なぜなら、モデルが実際に何に注目しているかを測定し、どのコンテキストトークンが出力の品質に寄与しているかを特定し、推測ではなく実際のアテンションパターンに基づいて要約および検索戦略を調整する必要があるためです。

サーキットブレーカー推論レイヤーを制御できなければ、エージェントごとの予算制限、異常検知、モデルサーバーレベルでの自動シャットダウンなどを実装することはできません。無限ループの被害に遭った経験から言えば、プロバイダーが助けてくれることはありません。

経済学者はこれをジェボンズのパラドックス (Jevons Paradox) と呼んでいます。William Stanley Jevons は 1865 年にこのパターンに気づきました。石炭エンジンの効率が向上するにつれて、石炭の総消費量が増加しました。AI トークンも同じ軌道をたどっています。効率が向上するたびに新たなユースケースが生まれ、節約された分以上のトークンが消費されるようになります。トークンあたりの成果を最大化する企業は、AI の使用量を減らすのではなく、むしろ増やすことになります。

エージェント型ワークロードに対応可能なオープンモデル

前述のとおり、Red Hat の推論チームはオープンウェイトモデルを使用して、2 日間で 3 億トークンを処理しました。Nemotron 3 Super、Gemma 4、Qwen 3.6 は、すべて Red Hat AI 推論スタック上で動作しています。その結果は、プルリクエストのレビュー、初期実装、特定の調査などを行うのに十分な性能を示し、本来なら最先端モデルに割り当てられ、トークンコストを積み上げていたであろう作業を軽減することができました。

コストの差はわずかなものではありません。 市販の Blackwell GPU を用いたベンチマークでは、オープンウェイトモデルを実行する 500 ドルの GPU で 1 日に 3,000 万トークンを処理できることが示されています。この処理量であれば、100 万トークンあたり約 0.20 ドルの低価格帯 API プロバイダーで同じワークロードを実行した場合と比較して、3 か月以内にハードウェアコストを回収できます。最先端の API 価格と比較すると、投資回収期間はわずか数日にまで短縮されます。

ある研究者は、トークンあたり 40 億パラメータのみを活性化させるモデルを使用して、ベンチマークで 87% を達成したコーディングエージェントを構築しました。140 億パラメータを持つモデルを使用したエージェントのスコアは 75% でした。その差はモデルによるものではなく、複合的なツールとエラーフィードバックループによるものでした。 重要な役割を果たしたのはモデルのサイズではなく、ハーネスでした。

オープンモデルをエージェントのシナリオで適切に機能させるには、本格的なエンジニアリングが必要です。そして、そのエンジニアリングこそが、まさにオープンソースによって可能になるものです。 OpenCode および Claude Code で動作する Gemma 4 の最近のデモでは、カスタムチャットテンプレートの調整、各モデルファミリー向けのツール呼び出しパーサーのチューニング、複数の API 標準におけるプロンプトのフォーマット設定など、実際の動作例が示されています。40 億パラメータのモデルには、260 億パラメータの量子化バージョンや 310 億パラメータのモデルとは異なる処理が必要でした。

これは、ベンチマーク上のパフォーマンスと実環境でのエージェントのパフォーマンスとのギャップを埋めるための作業です。これには、チャット補完、メッセージ、および応答の各 API 間の変換や、ファジーロジックを用いたモデル出力の解析が含まれます。これは、モデルがツール呼び出しの開始トークンを見落としたり、ハーネスのシステムプロンプトの影響で予期しない構文を生成したりすることがあるためです。

この作業は、vLLM のアップストリーム、モデルベンダーのチャットテンプレート、およびハーネスのバグレポートを通じて進められています。そして、それはオープンな環境でしか実現できません。プロプライエタリーな推論サーバーでは、チャットテンプレートの修正を提案したり、ツール呼び出しパーサーを調整したり、エージェントの出力が失敗した理由を観察したりすることさえできません。オープンソースであれば、すべての修正がすべてのユーザーに利益をもたらし、パーサーのアップグレードは永続的な資産となります。提供スタック全体でエージェント型ワークロードに対するオープンウェイトモデルの信頼性を高めるこのアップストリーム統合の作業は、Red Hat AI の中心的な取り組みです。

エージェント型推論スタック

エンタープライズ規模でエージェント型推論を実現するには、8 つのレイヤーが連携する必要があります。すべてのレイヤーが他のすべてのレイヤーと相互に作用します。

図 2：エージェント型推論スタック：最上部のエージェントとハーネスから、API 変換、ゲートウェイ、ガードレール、分散型サービング、モデルサーバー構成、推論エンジン、そして最下部のハードウェアまでに及びます。赤い枠線は、エージェントの互換性に関する作業の大部分が行われる 2 つのレイヤーを強調しています。点線のサンドボックス境界は、コード実行とセキュリティ制御が最も厳格なエージェントのレイヤーを囲んでいます。

個々のオープンソースプロジェクトからこれらのレイヤーを組み立てることは可能ですが、運用コストが高くなります。Red Hat AI のようなセルフマネージド型推論プラットフォームの価値は、お客様のインフラストラクチャ上で動作する、テスト済みでサポート対象のスタックに統合されている点にあります。これにより、データがセキュリティ境界の外に出ることはなく、アップグレードサイクル、モデルの選択、ルーティングポリシーを自社で制御できます。

エージェント型 API レイヤー

API の多様性は現実の問題です。ハーネスは Chat Completions、Responses、Messages、Interactions API を使用しますが、基盤となるモデルサーバーが必ずしもこれらすべてをサポートしているとは限りません。エージェント型 API レイヤーはハーネスとインフラストラクチャの間に位置し、このギャップを埋める役割を果たします。OGX (旧 Llama Stack) などのプロジェクトは、エージェント型 API 自体のオープンな実装を提供しています。Chat Completions、Responses API、Messages API、Interactions API に加え、ベクトルストア、ファイル管理、ツール実行などの補助機能が、使用するモデル提供レイヤー上で提供されます。

一部の API には先行者利益があるものの、現時点では単一の API 標準が覇権を握る見通しは立っていません。重要なのは、これらすべてをオープンソースで実装することです。そうすれば、必要なときにいつでも、あらゆるハーネスをあらゆるモデルに適合させることができます。変換レイヤーがオープンであれば、ツール呼び出しの契約が完全に維持され、リクエストに対して何が起きているかを正確に把握できます。プロプライエタリーなプロバイダーが変換を処理する場合、何が失われたかを知る術はありません。

llm-d:エージェント型推論のスケーリング

単一インスタンスの vLLM は、1 人のエンジニアがエージェントを実行するには十分ですが、100 人のエンジニアが同じモデルに同時にアクセスする場合には機能しません。llm-d は、推論をプリフィルフェーズとデコードフェーズに分割し、異なるハードウェアで個別にスケーリングできるようにする分散型サービングレイヤーです。多数の短いリクエストと長い推論チェーンが混在するエージェント型ワークロードにおいて、このアーキテクチャはますます不可欠になっています。

ガードレールとサンドボックス

コンテンツの安全性もこのスタックに含まれており、エージェントに対応するものである必要があります。プロキシとして動作するガードレールフレームワークは、ツール定義、ツールの選択、推論パラメーターを含む完全なエージェント API の契約を維持する必要があります。そうしないと、エージェントの動作を密かに低下させるリスクがあります。

また、効果的なエージェント型ガードレールには、単純な入出力テキストフィルタリングでは提供できない推論レベルのデータへのアクセスが必要です。これには、最終出力の前にモデルの思考連鎖 (Chain-of-Thought) に安全でないステップが含まれていないかを評価する推論トレース、呼び出しされたツールと引数がポリシー内にあるかを検証するツール呼び出しパラメーター、ハルシネーションのリスクや信頼性の低い出力を検出するためのトークンレベルの対数確率 (logprobs)、監査証跡やコンプライアンスログ用の生成メタデータなどが含まれます。これも、推論レイヤーをオープンにすべき理由の 1 つです。入出力されるテキストしか監視できないガードレールは、エージェント型ワークロードには不十分です。 

ガードレールのプロキシがツール呼び出しパラメーターを削除してしまうブラックボックスである場合、エージェントが失敗したときにその原因を診断できません。オープンソースのガードレール (NVIDIA NeMo Guardrails の非プロキシ型 /v1/guardrails/checks エンドポイントなど) は、エージェント API の契約を損なうことなくコンテンツの安全性を確保します。

サンドボックス化も重要な要素です。エージェントはコードを実行し、ファイルを書き込み、ツールを呼び出します。 多層防御には、コンテナレベルの制限、ネットワークポリシー、ファイルシステムの制限、ランタイムの強制適用など、階層化された分離が必要です。エージェントをコンテナに配置するだけでは不十分です。スタック図のサンドボックスの境界がエージェントとハーネスを囲んでいるのは、そこで任意のコード実行が行われる可能性があり、セキュリティ制御を最も厳格にする必要があるためです。

オープンソースが選ばれる理由

レイヤーの半分が何をしているか見えない状態では、8 つのレイヤーからなるスタックをテストすることはできません。パーサーが見えない状態では、失敗したツール呼び出しをデバッグすることはできません。ガードレールプロキシがエージェントに必要なパラメータを密かに削除してしまうようでは、安全性を確保することはできません。スタックは密接に結合されているため、どのレイヤーも不透明であってはなりません。企業が自らスタックを組み立てる必要がないように、これらのレイヤーを統合して堅牢化すること、この課題を解決するために Red Hat AI が構築されました。

技術的な議論を超えて、オープンな推論はコスト以外の構造的な理由からも不可避です。

図 3：エージェント型ワークロードにおけるオープン推論とプロプライエタリー API の比較プロプライエタリーな API は、設定の容易さと最先端モデルの品質において他社をリードしています。オープンな推論は、本番環境のエージェント型ワークロードが依存する 7 つの機能において優位に立っています。モデルルーティング、ツール呼び出しのデバッグ、ドメインのカスタマイズ、エージェントごとの予算管理、データレジデンシー、プロバイダーからの独立性、および推論レベルのガードレールです。

教育は分野全体の発展を加速させます。オープンソースは、自由なソフトウェアと自由な知識という 2 つのものをもたらします。DeepSeek R1 はこのことを明確に示しました。推論機能は、広範なコミュニティが再現できるようになる数か月前から、プロプライエタリーなモデルに存在していました。DeepSeek がコードと論文を公開すると、3 か月以内にすべての主要なラボが推論機能を備えるようになりました。知識の拡散効果は、モデルそのものよりも価値があります。エージェント型推論に適用されると、ツール呼び出しパーサーのあらゆる修正、チャットテンプレートのあらゆる改善、ハーネスのあらゆるパッチが、エコシステム全体で相乗効果を生む共有インフラストラクチャとなります。

信頼には透明性が必要です。すべての組織が、自社のすべてのデータとワークフローを少数のクラウドのモデルプロバイダー経由でルーティングすることを望んでいるわけではありません。一部の組織には、厳格なコンプライアンスに関連した課題があります。ヘルスケアや金融などの業界は、データのプライバシーやレジデンシーに関する厳格な規制要件に直面しています。また、ベンダーロックインを回避し、知的財産の完全な所有権を保持するための戦略的な選択である場合もあります。

オープンソースは、組織に対し、独自のセキュリティ境界内で、システムの仕組みを完全に可視化した状態で、独自の条件でモデルを実行するという選択肢を与えます。規制対象の業界、政府機関、およびセキュリティ上重要なワークロードにとって、これは必須要件です。規制も同じ方向に動いています。2026 年 8 月から施行されるEU AI 法の透明性義務では、モデルのアーキテクチャ、トレーニング手順、パフォーマンス特性を網羅した技術文書が要求されます。これらの情報をすでに公開しているオープンソースモデルは、クローズドモデルには適用されない免除の対象となります。

カスタマイズには独自の重みが必要です。クローズドな API を使用する場合、すべての組織が同じモデルを実行することになります。自社のインフラストラクチャで重みを管理していれば、独自のデータを外部に送信することなく、自社のドメイン、社内ツール、およびコードベースの規約に合わせてファインチューニングを行うことができます。医療機関は、臨床用語や患者記録の形式に合わせてファインチューニングを行います。法務チームは、管轄区域固有の言語や契約構造にモデルを適応させます。金融機関は、独自のリスクモデルやコンプライアンスフレームワークに基づいてトレーニングを行います。エージェント型ワークロードにおいて、これは汎用エージェントと、自社システムの仕組みをすでに理解しているエージェントとの決定的な違いとなります。

オープンソースはエコシステムの引力を生み出します。ハードウェアベンダーがオープンソースの推論ソフトウェアに投資すると、よりアクセスしやすいモデルによってハードウェアの導入がさらに促進されます。vLLM (推論ランタイム) の最適化やオープンソースの提供スタックの改善への投資により、あらゆる GPU でエージェント型ワークロードの処理能力が向上し、ハードウェアの再利用が可能になります。その結果、オープンソースソフトウェアの改善がエコシステム全体で相乗効果を生む好循環が生まれます。

次のフェーズでは、分散型モデルが有利になります。新たに現れつつあるパターンは「共有コンテキスト中心型」であり、多くのモデルが共有ナレッジグラフやコンテキストストア上で動作します。これにより、単一の巨大なモデルから、インテリジェントなハーネスによって調整される特化型モデルのエコシステムへと焦点が移ります。すべてをこなせる 1 つのモデルが必ずしも必要というわけではありません。多くの場合、必要となるのは、それぞれが得意分野を受け持ち、複合システムとして連携する数多くの特化型モデルを使用することです。そのようなアーキテクチャは、本質的にオープンで分散されたものになります。

Pi や OpenClaw をはじめとする新興のエージェント・アーキテクチャは、すでにこの方法で構築されています。それらの設計は最小限で、多くの場合、大規模言語モデル (LLM)、bash シェル、ファイルシステム、Markdown 形式の状態ファイル、および cron ループで構成されています。状態は重みではなくファイルに保存されるため、エージェントのメモリを失うことなく LLM を入れ替えることができます。これらのエージェントは、クローズドかオープンかを問わず、あらゆるモデルで動作します。しかし、モデルの重みから提供インフラに至るまで、フルスタックがオープンであれば、あらゆる構造上の利点が相乗効果を発揮します。つまり、自身のドメインに合わせて微調整を行い、自身が管理するモデル間でルーティングを行い、自社が所有するツールで監視を行い、他の部分に支障をきたすことなく任意のレイヤーを交換することができるのです。これこそが、オープンな推論がエージェント型 AI の自然な基盤となり、Red Hat AI がそれを支えるプラットフォームとなる理由です。 

準備の手順

価格体系が変更される前に今すぐ実行すべき 3 つのこと

図 4： オープンなエージェント型推論に備えるための 3 つのアクション (それぞれ Red Hat AI スタックの特定のツールを使用)。タイムラインでは、API の可搬性から完全なセルフマネージド型エージェント・インフラストラクチャの構築まで、12 か月の準備期間を想定しています。

ハーネスに依存しない構築エージェント型ハーネスやエージェントをどのように設計するかは、どのモデルを実行するかと同じか、それ以上に重要です。エージェントが特定のプロバイダーの API にハードコーディングされている場合、価格体系が変更される前にベンダーロックインに陥ることになります。構築する際には、モデルと API の可搬性を考慮する必要があります。ここで、Red Hat AI を通じて利用可能な OGX などのプロジェクトが役立ちます。これらは Chat Completions、Responses、Messages、Interactions API にわたるオープンな変換レイヤーを提供し、下位のモデルやプロバイダーに関係なくエージェントの可搬性を維持します。

管理対象インフラストラクチャでのセルフホスト量子化された Gemma 4 または Qwen モデルを実行する単一の GPU で、プルリクエストのレビュー、ドキュメント作成、コードの要約をすでに処理できます。最先端の推論が真に必要とされるワークロードや、最先端モデルが依然として明らかな品質上の優位性を持つワークロードには API サブスクリプションを利用し、それ以外のワークロードについては、自社が管理するインフラ上でセルフホスティングを行うようにしてください。セルフマネージド型推論プラットフォームが、モデル提供、スケーリング、ルーティング、可観測性 の運用の複雑さを処理するため、チームは提供スタックの維持ではなくエージェントの構築に集中できます。 

オープンソースモデルが最先端モデルの機能との差を縮め続けるにつれ、セルフホスト可能なワークロードは増え続けていきます。今すぐ着手することで、オープンモデルがフルスタックを網羅するようになった際に必要となる運用体制を整えることができます。モデルルーティングに関する研究では、リクエストの大部分を小規模なモデルやセルフホスト型モデルに送り、複雑なタスクのみを最先端の API にエスカレーションすることで、品質の低下を最小限に抑えつつコストを 60% - 85% 削減できることが示されています。

エージェントスタック全体でのエンドツーエンドのテストベンチマークをクリアしたモデルであっても、ハーネスが不適切なプロンプトを出したり、ツールパーサーが出力を誤読したり、ゲートウェイが誤ったタスクをルーティングしたりすれば、失敗する可能性があります。モデル、ハーネス、設定の 3 つの組み合わせをテストすることが、適切なアプローチとなります。

トークンの予算管理もプロセスに組み込んでください。エージェントごとの制限や機能ごとの割り当て、異常検知も考慮に入れてください。 Red Hat AI スタックの一部である MLflow Tracing は、OpenTelemetry との完全な互換性を備え、プロンプト、推論ステップ、ツール呼び出し、トークンコストをキャプチャします。予算アラートは、実際に必要になる前に設定しておくべきです。

次の展開に備えた構築

通常、ハードウェアは減価償却されます。オープンな推論に使用される GPU は、それとは逆の現象が起きています。チップ自体は変わりませんが、その上で動作するソフトウェアは改善し続けています。vLLM のバッチ処理とアテンションカーネルの改善により、同じシリコンで 1 秒あたりにより多くのトークンを処理できるようになります。量子化技術の飛躍的な進歩により、かつては 80 GB を必要としたモデルが、同等の品質を維持しながら 20 GB に収まるようになっています。分散型サービングによってワークロードが分割されるため、同じクラスタでより多くのエージェントを同時に処理できるようになります。3 年前に購入したエンタープライズ GPU では、周囲のオープンソーススタックが改善されたことで、導入当時よりも現在の方がより多くの有用な推論を生成できます。

この相乗効果こそが、この議論全体における核心です。オープンなツール呼び出しパーサーは、あらゆるユーザーにとってより効果的になります。オープンなチャットテンプレートは、互換性の問題を一度に、かつ永続的に解決します。エージェント型 API の契約を維持するオープンなガードレールは、特定のベンダーの顧客だけでなく、あらゆるデプロイメントを保護します。オープンな分散型サービングは、すでに所有しているハードウェアでスケーリングが可能です。

これこそが、オープンソース AI プラットフォームの利点です。単にモデルを提供するだけでなく、ハーネスとモデルを橋渡しする API レイヤーから、ルーティングと計測を行うゲートウェイ、サービスエンジン、およびそれが動作するハードウェアに至るまで、自社のインフラストラクチャ上でエージェント型推論スタック全体を所有することについて、Red Hat では「メタルからエージェントまで (metal to agents)」という表現を使用しています。データはセキュリティ境界内に留まります。モデルは任意の場所で実行できます。すべてのレイヤーを制御できるため、コストを予測可能にできます。すべてのレイヤーがオープンです。すべてのレイヤーがデバッグ可能です。すべての改善が共有されます。

モデルの性能はすでに優れており、日々向上しています。スタックは形になりつつあります。経済的なメリットは明確です。重要なのは、オープンなエージェント型推論が実現するかどうかではなく (すでに実現しています)、コストが発生したときに備えができているかどうかです。