Intelは10月14日、Inference Microservicesを発表した。対応するXeonプロセッサ上で、コンテナごとに1つの大規模言語モデルを提供するモデル別コンテナだ。起動時にホストを検出し、そのモデルとプロセッサに合うIntelのプロファイルを選び、OpenAI互換のHTTP APIの背後でvLLMを起動する。Xeonの処理能力を持つ開発者がまず行うべきなのは、文書に記載されたイメージが内部ネットワーク上のアプリケーション要求に応えられるかを判断し、そのホストでワークロードを測定することだ。

最初に公開されたイメージのタグは0.1.0。BF16精度の第4・第5・第6世代Xeonを対象とし、Linux上のDocker Engine 20.10以降、またはKubernetes 1.24以降が必要だ。ドキュメントが説明するのはローカルで動かすサービングパッケージであり、Intelがホストするエンドポイントではない。Intel APIキーを取得する必要はない。プロファイルで調整作業を減らしたり性能を高めたりできるという説明はIntelによる主張であり、BIG CHANGEはイメージを実行もベンチマークもしていない。

大きな変化

  • 何が変わったか：Intelはモデル別のvLLM設定をコンテナにまとめた。コンテナは対応するXeonホストを調べ、標準APIを公開する前に組み込みサービングプロファイルを選ぶ。
  • なぜ重要か：アプリケーションは使い慣れたチャットエンドポイントを呼び出せるが、コンテナがアプリケーションのルーティング、認証、TLS、モデルライセンスへの準拠を担うわけではない。また、特定のワークロードがレイテンシーや処理能力の目標を達成する証拠も示さない。
  • 注目点：必要なモデルにカタログ掲載イメージと対応プロファイルがあるかを確認し、予定するホストで準備状態、応答の挙動、負荷を試験する。IntelはGPU対応、他のエンジンや精度、Helm chart、operatorを初回版の機能ではなく今後の作業として挙げている。

コンテナが担うことと、チームに残る責任

Intelによると、起動時の検出ではXeonの世代、利用可能なコア、NUMA構成、対応するプロセッサ機能を考慮する。モデル別イメージは、vLLMの精度、作業分配、メモリ配置を決めるプロファイルを解決する。適合するモデル別プロファイルがない場合、一般プロファイルへ黙って切り替えるのではなく起動に失敗する。他のHugging Faceモデル向けIntelベースイメージには別の汎用プロファイルへのフォールバックがある。起動成功がチームの評価対象としたモデル別設定を示しているかを判断するうえで、この違いは重要だ。

文書に記載されたAPIではGET /health, GET /v1/models, POST /v1/chat/completions, POST /v1/completions、GET /metricsを既定でポート8000に公開する。/healthはモデル準備完了時に本文が空のHTTP 200、未準備時に503を返す。本文を探すよりステータスコードを確認する方が有用だ。/v1/modelsは提供中のモデルIDを1つ返す。アプリケーションはチャット要求にそのIDを含める必要があり、複数モデルを提供するなら要求の振り分け先も選ばなければならない。IntelはストリーミングとOpenAI互換クライアントライブラリを文書化しているが、要求形式の互換性だけではチーム固有のモデルとプロンプトの品質や速度は証明できない。

信頼境界も明確に示されている。セキュリティガイドによると、エンドポイント自体はTLSも呼び出し元認証も提供しない。保護ゲートウェイやネットワーク境界なしにポート8000を公開ネットワークへ出してはならない。KubernetesではNetworkPolicyでアクセスを制限し、TLSと認証にはゲートウェイまたはIngressを使うようIntelは勧める。サービスは顧客のインフラ上で動くため、ホスト容量、キャッシュ配置、監視、アクセス制限付きモデルの重みへのアクセスもチームが担う。

まず文書に沿ってローカル確認し、その後ワークロードを試験する

公開されているQwen3-4Bの例では、Intelのクイックスタートに次のLinux／Dockerコマンドがある。ここでは文書に記載された手順を示すだけで、BIG CHANGEは実行していない。

Terminal
docker run --rm -p 8000:8000 \
  --cap-add SYS_NICE \
  --shm-size=2g \
  intel/inference-xeon-qwen-qwen3-4b:0.1.0

Intelによると、初回起動ではモデルの重みをダウンロードするため数分かかることがある。別のターミナルでcurl -i http://localhost:8000/healthを実行し、エンジン準備完了後に本文なしのHTTP 200が表示されることを確認する。続いてGET /v1/modelsがQwen/Qwen3-4Bを示し、そのIDとPOST /v1/chat/completions配列を使うmessages要求がchat-completion応答を返すことを確認する。これらの確認で分かるのは、文書にあるエンドポイントが起動して応答したことだけだ。展開を決めるには、チーム自身のプロンプト、同時実行数、レイテンシー、リソースの測定に加え、障害や再起動時の挙動も確認する必要がある。

この 前提条件では、4B～8Bモデルに32 GBのRAMとキャッシュ用の空きディスク50 GBを推奨し、より大きなモデルにはさらにメモリが必要としている。Ubuntu 22.04 LTS以降を推奨するが、ソフトウェア要件はDocker Engine 20.10以降を実行できるLinuxだ。Intelの例のQwen3-4BにHugging Faceトークンは不要で、そのモデルカードにはApache 2.0と記載されている。他のモデルはアクセス制限付きの場合があるため、ライセンス、アクセス承認、読み取りトークンを個別に確認する必要がある。Intelの公開ドキュメントはmicroservicesソフトウェアの価格を示しておらず、この展開のハードウェア費や運用費も定めていない。

Intelの対応機能一覧は、組み込みの検証済み経路とvLLMのパススルーを区別している。ツール呼び出し、構造化出力、LoRA、コンテキスト長の変更には追加のINFERENCE_ENGINE_ARGSフラグが必要だ。これらは調整済み設定を変えたり無効にしたりする可能性があるため、Intelはdry-runで解決後のコマンドを確認し、結果を負荷試験するよう勧める。既定イメージで実証済みの機能ではなく、別の統合作業として扱うべきだ。Kubernetes展開ではレプリカやreadiness probeを追加できるが、モデル間の振り分けは引き続きアプリケーションまたはゲートウェイが担う。Intelの以前のDシリーズの記事は別のGPUハードウェア発表を扱っており、今回のXeonサービングリリースとは異なる。

出典と関連資料

  • Intelの発表、2026年10月14日。モデル別コンテナ、ホスト検出、プロファイル、Xeonの初期対応範囲、計画中の拡張を説明する。調整と性能に関する主張はIntelによるもので、BIG CHANGEは独自に検証していない。
  • Intel Inference Microservicesのドキュメント、2026年9月24日更新と表示。0.1.0のクイックスタートにはQwen3-4Bのコマンドと初期のhealth／chat手順がある。上記の手順は文書に基づく説明に限られる。
  • 前提条件、APIリファレンス、対応機能、セキュリティガイダンス。2026年9月24日更新と表示されたIntelの文書。対応ホスト、準備状態の応答、組み込み機能とvLLMパススルーの違い、認証のないHTTP境界を定義する。
  • Qwen/Qwen3-4Bのモデルカード、2026年10月15日参照。例のモデルについてApache 2.0ライセンスを示す。他のモデルでは条件やアクセス制限が異なる場合がある。