翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CPU 推論とオーケストレーション

概要

CPU インスタンスは、Amazon EKS の幅広い AI ワークロード用のファーストクラスコンピューティングオプションです。小規模言語モデル (SLMs) や従来の ML 推論からデータパイプラインやエージェントオーケストレーションまで、CPUs強力な価格パフォーマンス、幅広い容量可用性、使い慣れた Kubernetes スケジューリングセマンティクスを提供します。

CPU と GPU は補完的であり、競争的ではありません。エージェント AI パイプラインが複雑化するにつれて、CPU ワークロードの表面はそれらとともに大きくなります。すべての推論呼び出しは、すべて CPU で実行されるツール実行、コンテキストアセンブリ、ベクトル検索、ガードレール、オーケストレーションロジックに囲まれています。両方のコンピューティングタイプを意図的に使用するアーキテクチャを設計し、各ワークロードを最高のコストパフォーマンスを実現する階層に配置することをお勧めします。

すべてのワークロードに GPU が必要なわけではありません。ルーティング、分類、取得、埋め込み、オーケストレーション、言語モデル推論の割合の増加はすべて CPU で効果的に実行されます。arm64 および x86 全体の現行世代の CPU インスタンスは、ML 推論に強力な価格パフォーマンスを提供します。Karpenter のノード統合、KEDA のイベント駆動型スケーリング、および量子化されたモデルサービスと組み合わせることで、プラットフォームチームが GPU の深い専門知識なしで運用できる本稼働対応のスタックが提供されます。

このガイドは以下を対象としています。

学習内容:

AI ワークロード用の CPUs を使用する理由

本番稼働用 AI パイプラインは、多くのコンピューティング層に作業を分散します。CPUs、ルーティング、分類、取得、オーケストレーション、および推論の割合の増加を処理します。現行世代の CPU インスタンスは、強力な価格パフォーマンスと使い慣れた Kubernetes スケジューリングを提供し、多くの AI ワークロードにとって実用的なオプションとなります。

これらのワークロードでは、次の 3 つの要因によって CPU が説得力を持ちます。

キャパシティの可用性

GPU インスタンスでは、数週間前にキャパシティ予約が必要になることがよくあります。CPU インスタンスは、特殊なデバイスプラグイン、DRA 設定、MIG パーティショニングなしで、すべての AWS リージョンで広く利用できます。迅速にスケールする必要がある場合、CPU 容量が最も簡単に利用できるオプションです。

経済学

現行世代の CPU インスタンスは、ML 推論に強力な価格パフォーマンスを提供します。FinOps レビューを実行しているチームやマルチテナントクラスターを管理するチームにとって、CPU と GPU のコスト差は大きく、特に GPU アクセラレーションがリターンを低下させる量子化された SLMs では顕著です。利用可能なインスタンスファミリー (Graviton、AMD、Intel) 全体でベンチマークを行い、ワークロードに最適なcost-per-tokenを見つけることをお勧めします。

運用のシンプルさ

CPU ポッドは、標準の Kubernetes スケジューリング (requests、limits、ノードアフィニティ、トポロジースプレッド) を使用します。デバイスプラグインなし、カスタムスケジューラなし、nvidia.com/gpuリソースタイプなし。GPU の深い専門知識なしで AI ワークロードを実行したいチームは、CPU でより迅速に本番環境に到達できます。

エージェントパイプラインの CPU 表面の増加

エージェント AI パイプラインでは、すべての GPU 推論呼び出しは、ツール実行、コンテキストアセンブリ、ベクトル検索、埋め込みルックアップ、ガードレール、レスポンス検証、メモリ管理、オーケストレーションロジックなどの CPU 作業に囲まれています。エージェントが複雑になるにつれて (より多くのツール、長いチェーン、複数ステップの推論）、これらの CPU ワークロードは超直線的に増加します。MCP (モデルコンテキストプロトコル) などのプロトコルは、これをさらに拡張します。各 MCP ツール呼び出しは、CPU 上で完全に実行されるデータの取得、変換、フォーマットをトリガーします。

CPU と GPU/Trainium: それぞれを選択するタイミング

ワークロード決定フレームワーク

AI ワークロードに適したコンピューティングの選択は、次の 4 つのディメンションに分けられます。

以下の表をディシジョンマトリックスとして使用します。

クイックベンチマークワークフロー

インスタンスファミリーにコミットする前に、ターゲット p95 レイテンシーで 1,000 クエリあたりのコストという 1 つの同等のメトリクスで、候補 CPU ファミリー (arm64 と x86) と GPU を比較する構造化されたベンチマークを実行することをお勧めします。同じモデル設定 (同じ量子化、コンテキストサイズ、スレッド数) でファミリーごとに 1 つのノードをデプロイし、それぞれを負荷テストして比較します。CPU インスタンスが p95 SLO を満たしている場合、コストがかかる可能性があります。わずかなマージンで を見逃した場合は、GPU に移行する前に、そのファミリーの最新世代を試してください。同時実行ターゲットでレイテンシーがまだ高すぎる場合、ワークロードを GPU に移動するシグナルです。

本番稼働用パターン

パターン 1: エージェント AI — LLM エスカレーションによる CPU での SLM 事前フィルター

ほとんどのエージェントワークフローは、リクエストの分類、ツールの選択、構造化データの抽出、レスポンスの検証など、同じ狭いパターンを繰り返し実行します。これらのタスクには 70B パラメータモデルは必要ありません。

SLMs に関する調査 (arXiv:2506.02153) では、10Bパラメータ未満のモデルは、ドメインに特化している場合、CPU で効率的に実行しながら、制約のあるサブタスクで大きな LLMs と一致または超過する可能性があり、コストとレイテンシーが大幅に削減されます。特定のドメインに合わせてモデルを微調整すると、そのフットプリントが小さくなるため、汎用 LLM を呼び出すよりも正確で安価になります。

このパターンでは、CPU 上の SLM がリクエストの大部分をend-to-end。ルーティングレイヤー (CPU でも実行) は、真に複雑なケースのみを GPU がホストする LLM にエスカレートします。

CPU で実行されているコンポーネント:

GPU/Trainium のコンポーネント:

このパターンが機能する理由: 多くのエージェントワークフローでは、リクエストの 60～80% が SLM によって分類可能または抽出可能です。回避する LLM 呼び出しごとに、大きなコンテキストウィンドウを組み立て、長いレスポンスでガードレールを実行し、複雑な状態を管理する CPU 作業を回避できます。CPU 階層は GPU 階層とは独立してスケーリングされます。

一般的なエージェントパイプラインの CPU ワークロードカテゴリには、ツール実行 (MCP サーバーコール、API コール、データベースクエリ）、コンテキストアセンブリ、ベクトル検索と埋め込みルックアップ、オーケストレーションと計画ロジック、ガードレールと安全フィルタリング、レスポンスの検証とフォーマット、エージェントのメモリと状態管理、ログ記録/オブザーバビリティが含まれます。

このパターンはファインチューニングライフサイクルにも適しています。CPU ノードでドメインデータを収集し、GPU でファインチューニングしてから、量子化されたモデルを CPU にデプロイして、LLM エンドポイントよりも大幅に低コストで推論します。LoRA Land (arXiv:2405.00732) の研究によると、微調整された 7B モデルは、テストされたドメイン固有のタスクの大部分で GPT-4 を上回り、多くの本番稼働用ユースケースで「小さなモデルを微調整して CPU で実行」パスを実行可能にします。

パターン 2: 高密度 CPU モデルファーム

本番稼働用 ML パイプラインは、埋め込み、レコメンダー、分類子、BERT ベースのスコアラー、コンピュータビジョンモデルなど、数百または数千の小規模なモデルを定期的にデプロイします。これらのモデルは、それぞれに独自の GPU リソースが割り当てられると、個別に軽量になります。

Karpenter がノードのライフサイクルを管理し、観測負荷に応じて KEDA スケーリングを行う、高密度 CPU 供給 (TorchServe または Triton on CPU を使用してノードごとに複数のモデルをバイナリパックする) をお勧めします。

このパターンは RAG アーキテクチャに自然に拡張されます。生成の埋め込み、ドキュメントチャンキング、OpenSearch からの取り出しはすべて CPU ノードでコスト効率よく実行され、最終生成ステップでのみ GPU がホストする LLM に結果を提供します。CPU ファームがボリュームを処理し、GPU が複雑さを処理します。

規制された業界 (金融サービス、医療、政府) では、このパターンは特に説得力があります。CPU で VPC 内で動作する数百の特殊なモデルで、完全な監査証跡とデータがアカウントを離れることはありません。セルフマネージド推論のコンプライアンス要件は、sub-8Bモデルの CPU のコスト上の利点と自然に一致します。

最適化のベストプラクティス

量子化

CPU で 7B モデルをフル BF16 で実行するのは実用的ではありません。Q4 量子化で実行すると、実行可能でコスト効率が高くなります。量子化が CPU に役立つ理由を理解することは、インフラストラクチャに関する適切な意思決定を行う上で重要です。

CPU 推論で量子化が重要な理由。CPU 推論はメモリ帯域幅の境界であり、コンピューティングの境界ではありません。デコードフェーズ (トークンを一度に 1 つずつ生成) では、生成されたトークンごとにモデルの重み全体が RAM から読み取られます。CPU は、数学を行うのではなく、メモリからデータが到着するのを待つことにほとんどの時間を費やします。BF16 の 7B モデルは約 14GB で、Q4_K_M では約 4GB に縮小されます。ボトルネックは RAM から CPU コアにバイトを移動しているため、3.5 倍小さいモデルでは読み取りが 3.5 倍速くなり、トークン生成がほぼ 3.5 倍速くなります。そのため、量子化は CPU 推論にとって最も影響の大きい唯一の最適化であり、メモリチャネルが多い新しい CPU 世代は、同じクロック速度でも推論を高速化します。

アーキテクチャに最適化されたバックエンド (arm64 の場合は ARM NEON/SVE2、x86 の場合は AVX-512/AMX) を使用して推論エンジンを構築し、vCPU 数と等しいスレッド数を設定し、Q4_K_M または Q8_0 量子化形式を選択することをお勧めします。

sub-2Bモデルの場合、CPU は GPU と比較して価格パフォーマンスで勝ちます。これらのモデルは小さく、GPU アクセラレーションの利点は最小限に抑えられますが、1 時間あたりのコストは大幅に高くなります。ワークロードがsub-2Bモデルを使用できる場合、CPU が推奨デフォルトです。

アーキテクチャ固有の最適化: arm64 では、現行世代の Graviton インスタンスが SVE2 をサポートしています。ターゲットに適した-marchフラグを使用して推論エンジンを構築します。x86 では、AMD EPYC インスタンスは AVX-512 をサポートし、Intel Xeon インスタンスはマトリックスアクセラレーションに AMX を追加します。推論はメモリ帯域幅の境界であるため、DDR5 メモリチャネルが多い新しい CPU 世代では、同じクロック速度であっても推論が速くなります。インスタンスタイプを選択するときは、コア数よりもメモリ帯域幅を優先します。

コンテキストウィンドウのサイズ設定: 分類およびルーティングワークロードの場合、入力は通常 200 トークン未満で、出力は 2～3 トークンです。デフォルトの 2048 の代わりに小さなコンテキストウィンドウ (512 トークンなど) を設定すると、KV キャッシュメモリの使用量が減少し、リクエストごとのレイテンシーが向上します。入力が本当に長い場合にのみ、コンテキストウィンドウを増やします。

フラッシュアテンション: 推論エンジンがサポートしている場合はフラッシュアテンションを有効にします。フラッシュアテンションは、全アテンションマトリックスのマテリアライズを回避することで、アテンション計算のメモリ使用量を削減します。CPU の場合、利点は GPU よりも小さくなりますが、入力を長くするのに役立ちます。

高密度供給用のビンパッキング

クラシック ML モデルと埋め込みモデル (通常は各 <500 MB) の場合、目標は安定したテールレイテンシーでノードあたりの最大ポッド密度です。これを実現するかどうかは、正確なリソースリクエストと制御されたスレッドの 2 つによって決まります。

は、実際の負荷下で観測された p50-p90 の使用requestsに基づいています。負荷テストから、Goldilocks、VPA レコメンデーション、または Prometheus ヒストグラムを使用します。デフォルトは、ほとんどの場合、双方向で間違っています。

ML ライブラリ (PyTorch、ONNX Runtime、MKL、OpenBLAS) は、ポッドに割り当てられた CPUs ではなく、ノードに vCPUs が表示されるスレッドをできるだけ多くスポーンします。20 個のポッドを持つ高密度ノードでは、すべてのポッドが 32 個のスレッドのスポーンを試みます。ノードは、コンテキスト切り替えと p99 レイテンシースパイクをスラッシュします。これを明示的に修正します。

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

各値を CPU リクエスト以下に設定します。4 コア以上のポッドの場合、2～4 スレッドからベンチマークを行います。多くの小規模モデルでは、キャッシュ効率のためにスレッド数が少なく、パフォーマンスが向上します。HPA を多くのシンポッドで使用すると、ポッドあたり 1～2 スレッドがほとんどの場合成功します。

スケジューリングとコスト最適化

CPU 推論コストを大幅に削減するための 2 つのプラクティスは複雑です。Karpenter 統合のスポットインスタンスとマルチアークコンテナイメージです。

Karpenter の統合は、キューまたはロードバランサーの背後にあるステートレス推論ポッドが中断を適切に許容するため、CPU 推論に適しています。スケールダウン中の容量の減少を避けるため、同時中断を制限する予算 (一度にノードの 20% など) で、使用率の低いノードに対応するように統合を設定します。Karpenter のnodePool仕様では、スポット容量とオンデマンド容量を 1 つのプールで組み合わせることができます。スポットは優先オプション、オンデマンドはフォールバックです。

マルチアーキイメージ (arm64 と amd64) を構築すると、さらにロックが解除されます。どちらのアーキテクチャも利用できるため、Karpenter はリアルタイムの料金と可用性に基づいて、幅広いインスタンスファミリー (Graviton、AMD、Intel) から選択できます。これは、インスタンスタイプとアーキテクチャを分散させることで中断頻度が低下するスポットワークロードに特に役立ちます。マルチプラットフォームビルドで docker buildxまたは CI パイプラインを使用して、両方のアーキテクチャをカバーする単一のマニフェストを生成します。

コンテナの起動の最適化

Karpenter が新しいノードをプロビジョニングする場合 (スケールアップ、スポット置換）、コンテナランタイムはポッドを起動する前に推論イメージをプルする必要があります。マルチ GB 推論イメージの場合、ポッドの起動に 30～60 秒かかることがあります。

Bottlerocket を推論ワークロードのノード OS として使用し、SOCI スナップショットと並行プル/アンパックモードで組み合わせることをお勧めします。SOCI は、デフォルトのシーケンシャルレイヤー抽出を並列チャンクベースのダウンロードに置き換え、大きなイメージのイメージプル時間を大幅に短縮します。コンテナイメージに変更を加える必要はありません。

詳細な設定ガイダンスについては、このガイドの「パフォーマンス」セクションを参照してください。このセクションでは、SOCI 設定、EBS スナップショットのプル前、コンテナランタイムキャッシュ戦略について説明します。

オブザーバビリティ

モデルレイヤーでオブザーバビリティがない場合、目立たずにスケーリングしています。すべての推論サービスに Prometheus メトリクスを公開し、それらを使用して KEDA スケーリングダッシュボードと運用ダッシュボードの両方を駆動することをお勧めします。

ほとんどの推論サーバー (llama.cpp、vLLM、Triton、TorchServe) は、/metricsエンドポイントで Prometheus 互換メトリクスを公開します。メトリクス名はサーバーによって異なりますが、概念は同じです。

計測する主要なメトリクス:

Auto Scaling: CPU 使用率ではなくキューの深さに基づいてスケールする

CPU 使用率は飽和メトリクスです。レイテンシーが既に低下するとスパイクします。使用率ベースの自動スケーリングが反応するまでに、ユーザーは既に待機しています。

キューの深さ (リクエストの遅延/待機) は主要な指標です。すべての処理スロットがビジー状態のときにリクエストがキューイングを開始するため、レイテンシーが低下する前に増加します。キュー深度でのスケーリングは、既存のレプリカが正常に応答している間に新しいレプリカがプロビジョニングされることを意味します。

KEDA は、 を使用して複数のメトリクスを単一のスケーリング式に結合することをサポートしています scalingModifiers (KEDA 2.12 以降が必要）。推論ワークロードの推奨パターンは、キューに入れられたリクエストと処理中のリクエストを組み合わせて、キューメトリクスに重みを付けることです。

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

この式は、キューに入れられた 3 つのリクエストでさえ、合計メトリクスを 55 にプッシュし、ターゲットの 25 を大幅に上回っているrunning + (waiting * 10)ことを意味します。レイテンシーが低下する前にスケーリングが開始されます。activationTarget が 5 の場合、ノイズがscale-from-zeroイベントをトリガーするのを防ぎます。

CPU ファーストワークロードのモデル品質の評価

CPU に量子化された SLM をデプロイすることは、コストとレイテンシーの決定です。これは、モデルがワークロードに対して正しい有用な出力をまだ生成している場合にのみ意味があります。

モデルや量子化が小さいほどコンピューティングコストは削減されますが、品質が低下する可能性があります。影響はさまざまです。CPU でうまく機能するワークロード (分類、抽出、ルーティング、要約、埋め込み) は、多くの場合、適切な量子化とプロンプトを使用して 3B-7B の範囲に良好な品質を維持します。

評価対象

ワークロードごとに、さまざまな方法でパフォーマンスが低下します。

実用的な評価ワークフロー

インスタンスタイプを選択する前に負荷テストを実行する方法と同様に、本番稼働前に品質チェックを作成することをお勧めします。ワークフローには 4 つのステージがあります。

品質を回復する方法

モデルのパフォーマンスが低い場合は、労力の順に試してください。

リファレンス