Intel Inference Microservices、既存XeonサーバーでGPU優先AI戦略に対抗
Intelは10月14日、3世代のXeonプロセッサーを大規模言語モデル向けの事前構成済みサーバーへ転換するIntel Inference Microservicesを発表した。初回リリースは第4世代、第5世代、第6世代のXeon CPUをサポートする。あらゆる本番AIプロジェクトは新しいGPU容量から始めなければならないという前提に挑むものだ。
このソフトウェアは、モデル、vLLMサービングエンジン、ハードウェア固有の設定をコンテナ内にまとめている。起動時には利用可能なプロセッサーを検出し、そのモデルとシリコンの組み合わせについてIntelが検証した構成を選択する。アプリケーションはOpenAI互換APIを介して接続し、一般的なAI開発ツールで使われる馴染みのあるリクエスト形式に従う。
重要なのはこのパッケージ化だ。Intelは、汎用CPUが突如としてすべての専用アクセラレーターを上回ると主張しているわけではない。同社は企業に対し、すでに保有している可能性があるサーバー上で、選択したモデルを展開する手段を提供している。これにより、Intelの既存Xeon基盤は、Nvidiaや他のアクセラレーター供給企業が推進するGPU優先の調達経路と競合することになる。
Intel Inference Microservices、CPUチューニングをコンテナ化
Intelは、専門的な最適化作業を、一般的なプラットフォームチームでも実行できるデプロイメント成果物へ変換した。
発表によると、各マイクロサービスは1台のホスト上で1つのモデルを提供するコンテナだ。検証済みイメージには、特定のモデルとXeonハードウェアの組み合わせに選定された設定が含まれる。
Intelの最初の例では、40億パラメーターの言語モデルであるQwen3-4Bを、Dockerコマンド1つで提供する。推奨ハードウェアの最低要件は、対応Xeonプロセッサーと32 GBのメモリーだ。より大きなモデルには、さらに多くの容量が必要になる。
コンテナは、プロセッサー世代、割り当てられたコア、メモリーレイアウト、利用可能な命令セット、非一様メモリーアクセスのトポロジーを調べる。NUMAは、どのプロセッサーソケットがメモリー領域を所有しているかによってメモリーアクセス時間が異なるシステムを指す。不適切な配置は、サーバーに十分な総メモリーがあっても推論性能を低下させる可能性がある。
その後、ランタイムは対応するプロファイルを選び、vLLMを起動する。このオープンソースエンジンは、モデル実行、リクエストのバッチ処理、トークン生成、アプリケーションが使用するAPIエンドポイントを管理する。
Intelによると、プロファイルは精度、コア間の作業分散、メモリー配置を制御する。こうした選択によって、プロセッサーの演算ユニットが稼働し続けるか、データ待ちになるかが決まる。
最近のXeonチップには、ニューラルネットワーク全体で使われる行列演算を高速化するAdvanced Matrix Extensions（AMX）が搭載されている。また、AVX-512、AVX2、VNNIといったベクトル命令セットも含まれる。これらの機能がアプリケーション性能に影響するには、ソフトウェアがそれらを認識して利用しなければならない。
検証済みモデルイメージは保守的なアプローチを取る。モデル固有のイメージが対応プロファイルを見つけられない場合、未検証の構成を黙って実行するのではなく、起動エラーを出す。この動作により、運用担当者は明確な失敗シグナルを得られる。
Intelは、検証済みカタログ外のモデル向けにベースイメージも提供している。ベースイメージはHugging Faceモデル識別子を受け取り、互換性のある汎用ハードウェアプロファイルを使用できる。ただし、この経路には同じモデル固有の検証はない。
この違いは重要だ。「動作する」と「Intelがこの正確な組み合わせをチューニングした」は別の主張である。このソフトウェアを評価するチームは、結果を比較する前に、どちらの経路を使うか記録すべきだ。
初回リリースでは、従来の32ビット計算と比べてメモリー使用量を削減する16ビット数値形式BF16を使用する。追加の数値形式と推論エンジンは、提供済みではなく、今後の計画にとどまっている。
アプリケーションは標準的なチャット補完、テキスト補完、モデル、ヘルス、メトリクスのエンドポイントを呼び出す。Intelによると、OpenAI SDK、LangChain、LlamaIndex、LiteLLM、Haystackは、ベースURLを変更することで接続できる。
この互換性によりアプリケーション側の変更は減るが、運用作業が不要になるわけではない。チームは引き続き、モデルアクセス、コンテナイメージ、ストレージ、認証、ネットワーク、監視、容量を管理しなければならない。
モデルの重みを取得する間、初回ダウンロードには数分かかる場合もある。Intelは、不変ではない「latest」ラベルを使うのではなく、イメージバージョンを固定するよう推奨している。バージョン固定は、チームがデプロイメントを再現し、アップグレードを制御するのに役立つ。
その結果は、ホスト型AIプラットフォームよりも限定的な製品だ。同時に、単なる最適化ライブラリー群より具体的でもある。Intelは自社の推奨事項を、インフラチームが取得、検査、テスト、スケジュールできる形にまとめた。
既存Xeon容量が調達上の問いを変える理由
直近の機会は、すべてのGPUクラスターを置き換えることではない。GPU購入を正当化しなくなったワークロードを見つけることだ。
企業は一般に、データベース、仮想化、業務アプリケーション、社内サービス向けに大規模なx86サーバーフリートを運用している。その多くには、従来のワークロードでは活用されていないアクセラレーション機能を備えた最近のXeonプロセッサーが含まれる。
Intel Inference Microservicesは、この容量をAI計画に関連付ける。チームは、専用ハードウェアを要求する前に、既存ホスト上で対応モデルをテストできる。これにより、最初の調達上の問いは「どのアクセラレーターを買うべきか」から「このワークロードにアクセラレーターは必要か」へ変わる。
この違いには実務上の影響がある。ハードウェア調達には、承認、納品、ラック容量、電力計画、統合作業が伴う。モデルとワークロードが適合する場合、利用可能なCPU容量は実験段階を短縮できる。
小規模な社内アシスタントが一例となる。ポリシーの要約、サポートリクエストの分類、文書からのフィールド抽出、限定されたナレッジコレクションに対する質問応答などを行うかもしれない。このようなアプリケーションが、常に最高のトークン処理量を必要とするわけではない。
レイテンシーは依然として重要だが、需要パターンは異なる。営業時間中に1部門が使うツールと、数千件の会話を同時に処理する公開サービスでは、容量に関する課題が異なる。
既存のメモリー容量がピーク時の生成速度より重要なアプリケーションでは、CPU推論も適している場合がある。システムメモリーはアクセラレーターメモリーより豊富なことが多いが、その帯域幅とレイテンシー特性は大きく異なる。
データの所在も考慮事項となる。Intelのコンテナは顧客環境内で動作するため、プロンプトや取得した文書をホスト型推論のためにそのデプロイメント外へ出す必要がない。これはインストールを自動的に安全にするものではないが、運用担当者に境界を直接管理する権限を与える。
OpenAI互換インターフェースは、アプリケーションの可搬性を維持するのに役立つ。開発者は、ホスト型サービスとローカルデプロイメントの間でエンドポイントを移動しながら、同じ一般的なリクエスト構造を維持できる。ただし、モデルの動作や対応機能は依然として異なり得る。
Intelはこのインターフェースを、ハードウェアポートフォリオ全体にわたる長期的な契約として提示している。現行リリースはXeon CPUを対象とし、Intel GPUのサポートは今後の予定だ。Intelによると、同じアプリケーションインターフェースが最終的にはプロセッサーと専用アクセラレーターの両方にまたがるという。
この方向性は、Intelのより広範なヘテロジニアス戦略と一致する。10月のインフラ更新では、Xeonを専用アクセラレーターに並ぶオーケストレーションおよび汎用コンピュート層として位置付けた。同じ更新では、以前Crescent Islandと呼ばれていたGPU D-seriesについても詳細を明らかにした。
GPU D-seriesは、持続的かつメモリー集約的な推論向けに設計されている。Intelによると、パートナー設計では最大480 GBのLPDDR5Xメモリーを提供でき、自社ブランドのカードには160 GBが搭載される。
このハードウェアロードマップは、単純なCPU対GPUという議論の限界を示している。Intel自身も、モデルサイズ、同時実行性、経済性が必要とするワークロードは専用アクセラレーターが処理することを想定している。Xeonマイクロサービスは入口であり、万能の終着点ではない。
企業の購入担当者にとって、最も有用な枠組みはワークロード配置だ。断続的な需要を持つ控えめなモデルは、既存のCPUサーバーに適合する可能性がある。厳しいレイテンシー目標の下で多くのユーザーに提供する大規模モデルは、専用アクセラレーションが有利になる可能性が高い。
Intelのソフトウェアは、この配置判断をテストしやすくする。ただし、答えをあらかじめ決めるものではない。
本当の競争はXeon再利用とGPU優先デプロイメントの間にある
Intelが競っているのは単に1社の競合チップではなく、本番推論はアクセラレーターから始まるという前提だ。
Nvidiaはすでに、GPUを中心に類似のパッケージングパターンを確立している。一般にNIMと呼ばれるNvidia Inference Microservicesは、モデル、最適化プロファイル、サービングエンジン、標準APIをデプロイ可能なコンテナにまとめている。
現在のNIMアーキテクチャも、対応する大規模言語モデルのワークロードでvLLMを使用する。エンジンの周囲に、プロファイル選択、ヘルス管理、可観測性、ルーティング、その他の本番機能を加えている。
このため、Intelの動きは理解しやすい。この製品は推論マイクロサービスという考え方を導入するものではない。そのパターンを、企業環境ですでに一般的なXeonサーバーから始めて、Intelプロセッサーに適用している。
両アプローチは同じ問題を認識している。推論エンジンには多くの設定があり、最適な構成はモデル、ハードウェア、精度、メモリー、予想トラフィックに依存する。ほとんどのアプリケーションチームは、デプロイメントごとにベンチマークラボを維持したくはない。
違いはハードウェアの出発点にある。Nvidiaの提供はワークロードを対応GPUへ向かわせる。IntelはXeon CPUから始め、同じインターフェースの背後でIntel GPUへ向かう将来の経路を約束している。
これはIntelに特有の営業上の主張を与える。組織は利用可能なプロセッサーから始め、処理能力を超えたワークロードだけを移行できる。その価値は、Intelがその移行を運用上どれだけ簡潔に保てるかに左右される。
両者は重要な標準も共有する。いずれもOpenAI互換エンドポイントを公開し、関連する構成ではvLLMを使用する。標準化されたインターフェースは、アプリケーションレベルの切り替えコストの一部を弱める。
ただし、インフラのロックインをなくすわけではない。コンテナイメージ、ドライバー、最適化プロファイル、対応モデル、数値形式、監視システム、サポート契約は、依然としてベンダーごとに異なる。互換APIは可搬性の一層にすぎない。
AMDは、EPYCプロセッサーラインとROCmアクセラレーターソフトウェアを通じても追加の圧力を生む。しかし、Intelの新リリースにとって当面の対抗相手は、確立されたGPU優先デプロイメントの習慣だ。Intelは、識別可能なワークロードに対してCPU再利用が許容可能なサービス品質を生み出すことを示さなければならない。
これは主にピーク性能の競争ではない。GPUが毎秒より多くのトークンを生成することを示すベンチマークだけでは、調達判断は決着しない。購入者は利用率、利用可能な容量、デプロイ時間、電力、サポート、エンジニアリング労力も考慮する。
逆に、Xeonサーバーを所有しているからといって、推論が無料になるわけではない。AIの実行はメモリー、コア、電力、ストレージ帯域幅、運用上の注意を消費する。モデルに割り当てた容量は、同時に別のワークロードへ提供できない。
統合環境では、機会費用が特に重要になる。ある観測時点でアイドルに見えるサーバーでも、フェイルオーバー容量を提供していたり、予測可能な業務ピークを吸収したりしている可能性がある。
ソフトウェアライセンスも、引き続きモデルごとに異なる。Intelは、ユーザーがデプロイする各モデルに付随するライセンスに従う必要があると説明している。使いやすいコンテナ内にモデルをパッケージ化しても、その許容利用条件は変わらない。
したがって、最も有力なユースケースは、測定可能な余剰容量、サポート対象のモデル、そして中程度のサービス要件を持つワークロードを備えるケースだ。この3条件がなければ、CPUの再利用は健全なアーキテクチャではなく、魅力的なスローガンにとどまりかねない。
Intel Inference Microservicesは、チームがこの仮説を検証するための構造化された手段を提供する。購入者は、このコンテナを評価の結論ではなく、出発点として扱うべきだ。
自動チューニングが解消するのはセットアップの摩擦であり、推論の物理法則ではない
このリリースは設定作業を削減するが、プロセッサ、メモリシステム、ワークロード形状の間にある性能差をなくすものではない。
言語モデルの推論には、大きく2つの段階がある。Prefillは入力プロンプトを処理し、デコーディングは出力トークンを順次生成する。各段階はハードウェアに異なる負荷をかける。
長いプロンプトでは、Prefill中にかなりの計算処理が必要になる。デコーディングは、システムがモデルの重みと増加していくキー・バリューキャッシュを繰り返し読み込むため、メモリ移動が制約となる場合がある。このキャッシュは、後続トークンを生成する際に使われる中間的なアテンションデータを保存する。
GPUなどのアクセラレータは、高いメモリ帯域幅と大規模な並列計算を提供する。CPUは柔軟性、幅広い可用性、大容量のシステムメモリの選択肢、成熟したエンタープライズ統合を提供する。特定のモデルとトラフィックパターンがなければ、どちらの特徴も性能を決定しない。
バッチ処理は別のトレードオフをもたらす。リクエストをまとめることでハードウェアを稼働状態に保ち、スループットを向上させられる。一方で、個々のユーザーが体感する待ち時間を増やす可能性もある。
Intelのプロファイルは、こうした判断のための妥当な設定を組み込める。ただし、すべての組織のサービスレベル目標、プロンプト分布、同時実行パターンを把握できるわけではない。
製品の現在の対象範囲は、この制約を明確にしている。1つのマイクロサービスは、1台のホスト上で1つのモデルを提供する。より大規模なデプロイには、追加のオーケストレーション層、ロードバランシング、レプリカ管理、セキュリティ制御、ルーティングが必要だ。
Intelは、共有フリートを必要とする顧客に対し、AI for Enterprise Inference toolkitを案内している。このオープンソーススタックには、LLMゲートウェイ、認証、認可、テレメトリー、モニタリング、Kubernetesオーケストレーション、複数の推論エンジンが加わる。
これらのコンポーネントは、システムの異なるレベルに対応する。マイクロサービスはチューニング済みエンドポイントを提供し、エンタープライズツールキットは複数のユーザーとチームのためにエンドポイントを調整する。
本番導入を検討する購入者は、この分離を慎重に確認すべきだ。テストプロンプトに応答できるコンテナは、まだ信頼できる社内サービスではない。信頼性には、ヘルスチェック、容量ポリシー、アップグレード手順、障害処理、可観測性、アクセス制御が必要となる。
機能互換性もテストに値する。Intelの初回リリースは、vLLMのパススルー動作を通じてツール呼び出しと構造化出力を公開している。Intelは、これらの機能をハードウェアプロファイルと同じ形で検証済み機能とは説明していない。
ツール呼び出しでは、モデルが外部関数を要求できる。構造化出力では、応答を定義済みの形式に制約する。どちらもエージェント型の業務アプリケーションにとって重要だ。基本的なテストで動作する機能でも、複雑なスキーマやモデル固有のプロンプトでは失敗する可能性がある。
初期段階でBF16に焦点を当てていることも、もう1つの境界を生む。INT8やINT4などの低精度形式はメモリ消費を減らし、スループットを改善できるが、別途検証が必要になる可能性がある。Intelは追加精度を今後の作業として挙げている。
モデル対応範囲も同様に重要だ。Intelは、カタログ掲載モデル向けのモデル固有イメージと、その他のHugging Faceモデル向けの汎用ベースイメージを提供している。汎用パスは対応範囲を重視し、検証済みパスは予測可能な設定を重視する。
チームは、これらのパスを同一の保証を伴うものとして比較すべきではない。汎用プロファイルは、非対応モデルを正常に実行できる場合があるが、モデル固有のチューニングに期待される結果を提供するとは限らない。
デプロイメントドキュメントでは、実務上の要件も示されている。一部のゲート付きモデルにはHugging Faceトークンと事前のライセンス受諾が必要だ。モデルファイルにはローカルストレージが必要であり、より大きなモデルには推奨される32 GBのベースラインを超える容量が必要となる。
セキュリティチームは、トークンがどのようにコンテナへ渡されるか、またシェル履歴、環境変数、クラスタマニフェストによって露出していないかを確認すべきだ。さらに、イメージをスキャンし、ネットワークアクセスを制限し、推論エンドポイントを認証する必要がある。
こうした懸念はIntelのアプローチを否定するものではない。むしろ、チューニングの簡素化と運用の簡素化の隔たりを定義する。初回リリースがより完全に対処しているのは、後者ではなく前者だ。
Intelは購入者が必要とする比較をまだ公表していない
中心となる不確実性は、コンテナがモデルを起動できるかどうかではなく、実際のワークロードにおける経済的な性能である。
Intelは、検証済みプロファイルが、サポート対象のモデルとプロセッサの組み合わせについて同社が測定した最適な設定をパッケージ化したものだと説明している。この記述はIntelのチューニングプロセスを示すものだ。チューニングされていないXeonデプロイ、競合CPU、あるいは現行アクセラレータとの独立した比較を提供するものではない。
この発表では、マイクロサービスについて完全なレイテンシー、スループット、エネルギー、総コストの結果は示されていない。したがって、購入者はローンチだけから普遍的な優位性を推測することはできない。
有用な評価には、平均トークン毎秒以上の指標が必要だ。チームは、最初のトークンまでの時間、トークン間レイテンシー、リクエスト全体のレイテンシー、異なる同時実行レベルでのスループット、メモリ消費量、エラー率を記録すべきである。
最初のトークンまでの時間は、ユーザーが最初の応答をどれだけ早く目にできるかを測る。トークン間レイテンシーは、その後の生成速度を測定する。アプリケーションは高い総合スループットを示していても、個々のユーザーには遅く感じられることがある。
テストでは、代表的なプロンプトと出力長を使うべきだ。短い分類リクエストと、長文書を受け取り詳細な回答を生成するリサーチアシスタントでは、挙動が異なる。
同時実行数も本番環境に近いものでなければならない。1件のリクエストを処理するプロセッサは、キューが蓄積した場合には異なる挙動を示しうる。バッチ処理ポリシーは総出力を改善できる一方、リクエストの最も遅い部分を表すテールレイテンシーを悪化させる可能性がある。
エネルギー測定にも同等の注意が必要だ。すでにラックに設置されているCPUサーバーでも、継続的な推論時には追加の電力を消費する。チームは、1つのコンポーネントの定格電力だけでなく、エネルギー単位あたりの完了作業量を比較すべきだ。
総コストにはエンジニアリング時間も含めるべきである。Intelの最も強い主張は、プロファイルが置き換える手動チューニング作業に関するものだ。公正な試行では、パッケージ化されたパスと自己管理パスの両方について、デプロイ、安定化、更新にかかる時間を測定すべきである。
比較には、CPUを経済的に見せるために選ばれた過大なクラスタではなく、適切なGPUデプロイも含めるべきだ。ハードウェアはワークロードと予想される成長に合わせる必要がある。
テスト全体で品質は一定に保たなければならない。精度、量子化、モデルバージョン、コンテキスト長を変えると、出力の挙動が変わりうる。モデルの精度や利用可能な機能セットが変わる場合、より高速な結果は比較可能ではない。
Intelはプロファイルと初期の性能ナラティブの両方を管理しているため、独立ベンチマークが重要になる。顧客、クラウドプロバイダー、中立的なベンチマーク組織による再現可能なテストは、購入者により強い根拠を与えるだろう。
Intelの以前のMLPerf結果は、同社がCPUとGPUにまたがる標準化された推論テストに参加していることを示している。ただし、これらの提出結果をこの新しいコンテナリリースの直接的な検証とみなすべきではない。
パッケージ化は性能、サポート機能、運用上の挙動を変える可能性があるため、マイクロサービスには独自の結果が必要となる。バージョン0.1.0は、バージョン番号が特定の成熟度を保証するものではないとしても、製品が初期段階にあることも示している。
モデル固有イメージは、検証済みプロファイルを見つけられない場合、意図的に失敗する。この設計は予測可能性を支えるが、初期ユーザーが利用できるハードウェアとモデルの組み合わせも狭める。
ベースイメージはフォールバックプロファイルを通じて対応範囲を広げる。しかし、フォールバックの成功を最適化された性能と誤解すべきではない。チームは、ベンチマーク記録に正確なイメージ、モデル、ホスト、プロファイル、ランタイムバージョンを記載すべきだ。
こうした規律は、Intel Inference Microservicesが本当にAIインフラの負担を軽減するかどうかを企業が判断する助けになる。また、依然としてアクセラレータに適したワークロードも明らかにするだろう。
IntelのXeon AI戦略が機能するかどうかを示す3つのシグナル
検証済みモデルの対応範囲、独立した本番結果、ハードウェア間の可搬性が、これがプラットフォームになるのか、有用なデプロイショートカットにとどまるのかを決める。
第1のシグナルは、検証済みモデルカタログの拡大だ。購入者は、Intelが広く導入されているモデル、新しいアーキテクチャ、追加精度、改訂プロファイルをどれだけ迅速に追加するかを注視すべきである。
モデル固有の検証は、汎用コンテナに対するこの製品の最も明確な優位性であるため、カタログの成長は重要だ。更新が遅ければ、チームはIntelがワークロード固有の保証をあまり提供しないベースイメージへと向かうことになる。
新モデルがリリース直後に検証済みイメージを受け取れば、このシグナルはIntelの主張を強める。ユーザーが実際に使いたいモデルで汎用フォールバックに依存しなければならない場合、その主張は弱まる。
第2のシグナルは、再現可能な顧客性能データだ。有用なレポートには、プロセッサモデル、ソケット数、メモリ構成、コンテナバージョン、プロンプト長、同時実行数、サービス目標が記載される。
大まかな「より高速な推論」という主張は、ほとんど指針にならない。購入者が必要とするのは、Xeonの再利用がアクセラレータ容量の購入、レンタル、再割り当てを上回る条件を示す、ワークロードレベルの証拠だ。
本番環境の証拠には、運用上の成果も含めるべきである。デプロイ時間、障害復旧、更新頻度、スタッフの工数は、推論を容易にするというIntelの約束の中心にある。
第3のシグナルは、Intelが計画するGPUへの拡張だ。Intelは、同じマイクロサービス契約が、GPU D-seriesを含むデータセンター向け推論ハードウェアを最終的にサポートすると説明している。
この移行は、同社の可搬性に関する主張を試すことになる。アプリケーションが最小限の変更でXeonからIntel GPUへ移行できれば、Intelは信頼できるスケールアップパスを提供することになる。
異なるイメージ、運用ツール、機能面での妥協、あるいは大規模な再チューニングが必要になる場合、共通APIの価値は発表が示唆するより小さくなる。
Intelは、同社のソフトウェアがアップストリームプロジェクトと整合し続けることも示さなければならない。Intelのデータセンターソフトウェア担当バイスプレジデント、Bill Pearsonは、基盤となる最適化はvLLMを含むフレームワークにコントリビュートされていると述べた。
アップストリームでの作業は、クローズドなランタイムへの依存を減らし、Intelのパッケージ製品の外部にいるユーザーにも改善を届ける助けになる。購入者は、それでもどの最適化がアップストリームに存在し、どれがIntelイメージ固有のままなのかを確認すべきだ。
開発者にとって、このリリースは実用的な実験を提供する。利用可能なXeonホストにサポート対象モデルをデプロイし、実際のアプリケーショントレースに対して測定し、適切な規模のアクセラレータと比較する。
エンタープライズ購入者にとって、これは交渉力を生む。すでに最近のCPU容量が存在する場合、GPUの導入要請には、より明確な比較基準が生まれる。
知識集約型アプリケーションには、推論エンドポイントだけでは不十分です。チームは、モデルをガバナンスされたドキュメント、検索システム、そして検索可能なナレッジベースに接続して初めて、業務で役立つ出力を得られます。
Intel Inference Microservicesが成功するかどうかは、受け入れがたい性能上の妥協を隠すことなく、こうしたより広範な導入を低コストかつ容易に実現できるかにかかっています。次に必要なのは証拠です。より多くの検証済みモデル、透明性の高いワークロードテスト、そして実用的なCPUからGPUへの移行パスが求められます。現在のAIワークロードのうち、実際にアクセラレータを必要とするものはどれで、すでにラックに搭載されているXeonの容量でテストすべきものはどれでしょうか。
