AI推論とは

メールのスパム検知モデルから自動運転車を動かすナビゲーションシステム、生成AIに至るまで、すべての機械学習はパターン認識に帰着します。モデルは、サンプル用タスクまたはデータ・ポイントのデータ・セットで適切に機能するように「トレーニング」されます。モデルのトレーニング中、モデルのパラメータ（およびハイパーパラメータ）が調整され、モデルの意思決定がトレーニング・データのパターンに「適合」するまで調整されます。機械学習の中心となる前提は、トレーニング・データがモデルが現実世界のシナリオで見るものと十分に関連している場合、現実世界のユースケースで正確な予測を行うというものです。

多くのAI用語は非常に専門的なものですが、「AI推論」は実際には文字どおり直感的な用語です。

• 株式市場予測モデルは、ある銘柄の株価がどのように変化するかを知るのではなく、その銘柄の歴史と過去の株価の動きの傾向との比較に基づいて、次に何が起こるかを推測します。

• スパム検知モデルでは、特定のEメールがスパムかどうかは分かりません。トレーニングで見たスパムの例にEメールがどの程度似ているかに基づいて、それがスパムかどうかを推測します。

• 大規模言語モデル（LLM）は、何百万ものテキストサンプルの言語パターンに基づいて、次の単語（トークン）が何であるかを繰り返し推測します。

• ソーシャル・メディア・ネットワークは、お客様やその類似した人々が以前にエンゲージしたコンテンツに基づいて、お客様がエンゲージする可能性が最も高いコンテンツを推測します。

AIトレーニングの目標はモデルの精度と整合性を達成することです。一方、AI推論の目標は、トレーニングされたモデルを最大限に効率的かつコスト効率の高い方法でデプロイすることです。同じAIモデルでも、推論フレームワークが異なると動作が異なる場合があります。

単一の「最適な」AI推論セットアップは存在しません。ワークロードを分割する方法、ハードウェアの種類、ハードウェア（およびそれらを使用する計算アルゴリズム）、そのハードウェアにアクセスする環境はさまざまです。特定のシナリオに最適なセットアップは、ユースケースとワークロードの性質によって異なります。企業にとっての課題は通常、低遅延への要望と、スケーラブルかつコスト効率に優れる必要性のバランスを取る推論アプローチを特定することです。

AI推論とAIトレーニングはどちらも、インプット・データに関する予測を行うモデルが必要です。違いはそれぞれの目的にあり、AIトレーニングの場合は、その目的に向けて取られる追加の手順にもあります。

トレーニングとは、機械学習における「学習」が行われることです。モデル・トレーニングでは、機械学習モデルが一連のトレーニング・データ例に対して予測を行います。教師あり学習では、損失関数が各予測の平均誤差（または「損失」）を計算し、最適化アルゴリズムが損失を減らす方法でモデル・パラメータを更新するために使用されます。このプロセスは、損失が許容できるレベルまで最小化されるまで繰り返し行われます。強化学習も同様に機能しますが、損失関数を最小化するのではなく報酬関数を最大化することを目標とします。

要するに、AIの学習には通常、モデルが各インプットに応答してアウトプットを生成するフォワード・パスと、モデルのパラメーターを改善する可能性を計算するバックワード・パスの両方が必要です。これらのパラメーター更新は、機械学習モデルの「知識」を構成します。

AI推論では、トレーニングされたモデルが実世界のインプット・データに基づいて予測を行います。AI推論は、「学習」したもの、つまりトレーニング・データに対する性能を向上させるために行われたモデル・パラメーターの更新を使用して、新しいインプット・データの正しいアウトプットを推測することで機能します。モデル・トレーニングとは異なり、推論にはフォワード・パスのみが含まれます。

トレーニングと推論は通常、別々の異なる段階ですが、相互に完全に排他的ではないことに注意してください。例えば、ソーシャル・メディア・プラットフォームの推奨アルゴリズムは、ユーザーがプラットフォームに参加する前に、ユーザーの行動に関する大規模なデータ・セットを用いて既にトレーニングされており、コンテンツの提案を提供するたびに推論を行っています。ただし、トレーニングされたこのモデルは、ユーザー個人の行動に合わせて継続的にファイン・チューニングされ、ユーザーがコンテンツに個人的にどのように関与するかに基づいて提案を洗練させます。

「種類」は曖昧な言葉です。AI推論を実行する方法はさまざまであり、したがってその亜種を区別する方法も数多くあります。しかし、AI推論ストラテジーの最も基本的な2つのカテゴリーは、バッチ推論とオンライン推論です。

オンライン推論では、トレーニングされたモデルは、一度に1つのインプットでインプット・データを即座に処理します。オンライン推論は、アウトプットが時間的制約があるAIシステム（自律走行車、デジタル広告入札、料金体系など）や、ユーザーとのライブ対話が必要なAIシステム（チャットボットや機械翻訳など）に適しています。

オンライン推論は一般的にコストと複雑さが増します。特に重負荷やディープラーニングモデルを支える大規模なニューラル・ネットワークではなおさらですが、リアルタイムの意思決定が必要な実際のユースケースにはしばしば必要です。チャットボットや自動運転車は、ユーザーのエクスペリエンスを低下させないように、データをリアルタイムで処理する必要があります。特定の申請者がローンを受ける必要があるかどうかを予測するAIシステムのユーティリティーは、インプットとアウトプットの間のわずかな遅延によってそれほど影響を受けることはありませんが、自動運転車では、数ミリ秒の遅れが乗客の危険にさらされる可能性があります。

バッチ推論では、トレーニングされたモデルは大量のインプットをグループ（または「バッチ」）で非同期に処理します。各バッチは通常、特定の時間にスケジュールされます。例えば、ある企業はバッチ推論を使用して、その日のすべてのアクティビティについて毎晩レポートを実行するかもしれません。これにより、柔軟性と効率性が向上し、バッチ推論がよりコスト効率の高いオプションになります。ただし、これは時間が重要ではない状況でのみ実用的です。

バッチ推論により、ハードウェアをより効率的に使用することもできます。例えば、GPUには数千の処理装置（または「コア」）が含まれており、それぞれが同時に並列で計算を実行できます。すべてのコアがリストされていない単一のインプットに対して推論を実行することは、バスの座席を空席にしておくことに似ています。時間に敏感な状況では必要かもしれませんが、リソース効率からは最適とは言えない状態です。バッチ推論では、いわばハードウェアが「フル」になったときにのみ推論を実行できます。

さらに、モデル・パラメーター（ディープラーニング・モデルの場合は、文字どおり数十億のモデル重みを含む）をシステム・メモリーにロードする必要があります。これにはエネルギー使用量とコストが伴います。バッチ推論により、重みをRAMにロードする回数が減り、コストがバッチ全体に分散されます。

マイクロ・バッチ処理は、オンライン推論とバッチ推論の間の中間的なアプローチです。その名前が示すように、小さなバッチで推論を実行します。

「マイクロ・バッチ処理」と「バッチ処理」を区別する、明確かつ定量化可能なバッチ・サイズはありません。代わりに、この2つのアプローチは主に目標によって区別されます。マイクロ・バッチ処理はモデル速度を（主に）維持しながらモデルのスループットを向上させることを目的としていますが、従来のバッチ推論は効率を最大化することを目的としており、一般にレイテンシーは考慮されていません。バッチ推論では、インプットは受信後数分または数時間後に処理される場合がありますが、マイクロ・バッチ処理では通常、それ以上のミリ秒から数秒の遅延を目指します。

おそらく、マイクロ・バッチ処理の最も顕著な用途は、AnthropicのClaudeやOpenAIのChatGPTなどの主要プラットフォームを介したクラウド・ベースのLLM推論です。数千人のユーザーがチャットボットに同時にプロンプトを出す場合、これらのサービスは通常、複数のプロンプトを並行して処理するため、個々のエンド・ユーザーに顕著な遅延はなく、効率が向上します。

AIエコシステムを設計する際に最も重要な考慮事項の1つは、推論ワークロードを実際に実行する場所を決定することです。言い換えれば、ハードウェアがどこにあるか、そのハードウェアにアクセスする方法です。

デプロイメント環境は通常、4つのカテゴリーのいずれかに分類され、それぞれに独自の強みとトレードオフがあります。

• オンプレミス

• クラウド

• エッジ・デプロイメント

• デバイス上

オンプレミスまたは「オンプレミス」デプロイメントでは、AIモデルはお客様（またはお客様の組織）が所有し、保守する物理ハードウェア上で実行されます。

オンプレミスのデプロイメントでは、データの処理方法とタイミング、および計算リソースの割り当てについて、ユーザー自身が自律性を持つため、AIワークロードを最大限に制御することができます。これは、データ・プライバシーとセキュリティーの要件を厳守する必要がある医療、金融、官公庁・自治体、法律などの規制の厳しい業種・業務では特に有益です。

このコントロールには、関連するコストと労力のトレードオフが伴います。特にエンタープライズ規模のワークロードに必要なハードウェアや、通常は生成AIに関連する大規模モデルを使用するオンプレミスでのデプロイメントには、多額の先行投資が必要です。また、これらのサーバーを管理する専用のIT専門家が必要になります。

クラウド・デプロイメントでは、モデルは大規模データセンター内のサードパーティー・ベンダー（IBMなど）が管理するリモート・サーバー上で実行されます。これにより、組織は高性能なAIハードウェアを活用することができます。そのハードウェアの購入に伴う多額の初期投資や、それを維持するための継続的な労力は不要です。そのため、クラウドでのデプロイメントは通常、拡張性への最も早い方法であり、特に需要の急増に対応するためにコンピューティング・リソースを迅速に拡張する必要がある場合に最も効果的です。

その柔軟性とスケーラビリティには、データ主権のトレードオフが伴い、場合によってはレイテンシーと長期的なコストも伴います。データはクラウド・サーバーとの間で送受信される可能性があるため、推論速度に悪影響を与える可能性があります（ただし、主要なクラウド・プロバイダーを通じて通常提供される、より強力なハードウェアによって、相殺されることがよくあります）。また、データはオンプレミスのシナリオよりも多くのエンティティに公開されるため、データの出所に関する理論的な複雑さも生じます。

エッジ・デプロイメントとは、モノのインターネット（IoT）デバイスやローカル・エリア・ネットワークなど、データ・ソースに物理的に近い計算リソースを利用することを指します。

大まかに言えば、エッジ・デプロイメントは、「オンプレミス・クラウド」のようなものとして理解できます。最も有益なのは、工場の組立ラインのセンサーや病院のモニタリング・デバイスなど、複数のデバイスからデータを集約したり、分散したりして、ほぼリアルタイムで処理する必要がある場合です。このようなシナリオでは、ローカル・ネットワークの「エッジ」にあるデバイスを介して推論を実行すると、クラウドでのデプロイメントよりも高速な処理とより高いプライバシー確保が可能になります。

こうしたメリットは、通常、エッジコンピューティングで使用されるハードウェアはクラウド・プロバイダーを通じて利用できるものと比べて比較的限られたものであるため、ある程度は軽減されます。そして、ローカル・ネットワークが大きくなるにつれて、数百、数千の「エッジ・ノード」にわたる更新の管理はますます複雑になります。

デバイス上でのデプロイメントは最も簡単で、AI推論はノートPCやスマートフォンなどのエンド・ユーザーのデバイス上で直接実行されます。

デバイス上でのデプロイメントはシンプルかつ安全で、理論上は可能な限り最大のユーザー・プライバシーが提供されます。もちろん、デバイス自体のコンピューティング能力によって制限されます。スマートフォンや高性能の消費者向けコンピューターで利用できるコンピューティングは、一般的に、特殊なハードウェアに比べると性能に劣ります。特にスマートフォンでは、デバイス上での推論は通常、カメラフィルター、顔認識、Speech to Textなどの特定のタスクに限定されます。

AI推論は、正確な応答を推論できるようになるまで、適切なデータ・セットでAIモデルをトレーニングする複雑なプロセスです。これは非常に計算負荷の高いプロセスであり、専用のハードウェアとソフトウェアが必要です。AI推論用にAIモデルをトレーニングするプロセスを見る前に、それを可能にする特殊なハードウェアをいくつか見てみましょう。

GPUは、その名前が示すように、元々は（ビデオゲームなどの）グラフィックスをレンダリングするために設計されたものです。ディープ・ニューラル・ネットワークで推論を実行するなど、3Dグラフィックスのレンダリングには、大規模な行列乗算が必要です。例えば、数千ピクセルに対する光とテクスチャーの効果を同時に計算する場合です。

この並列処理を数学（グラフィックスの代わりに）に使う能力は、NVIDIAがCompute Unified Device Architecture（CUDA）を導入したことで大きく進歩しました。CUDAは、開発者がGPUの数千の並列コア上で直接動作するコードを書けるソフトウェアプラットフォーム、API、プログラミングモデルです。現在でも、GPUはディープラーニング・モデルのトレーニングと実行のための業種・業務標準ハードウェアです。

TPUは、ニューラル・ネットワーク専用に構築されたGoogle独自のカスタム・チップです。GPUは柔軟な汎用並列プロセッサーですが、TPUは高速行列計算に特化して設計されています。TPUはGPUよりも汎用性が低くなりますが、大量のニューラル・ネットワーク・データを処理する際の速度とエネルギー効率に優れています。

Neural processing units（NPUs）, like TPUs, were explicitly designed to process the computations of neural networks.これらは通常、スマートフォンやその他のモバイル・デバイスで使用されます。これは、対象範囲が狭いため、GPUに比べて消費電力が削減されるためです。

フィールド・プログラマブル・ゲート・アレイ（FPGA）は、人工知能オペレーションを含む特定のアプリケーションの要求に合わせてプログラム（および再プログラム）できる構成可能な集積回路の一種です。FPGAは、一般的にトップフライトGPUよりも処理能力が低くなりますが、極端なカスタマイズが必要な場合にはFPGAが有利です。

また、ASICSはFPGAとは異なり、カスタマイズや再構成はできません。単一のタスクを最大の効率で実行するように明示的に設計されています。例えば、Google社のTPUは、Tensorflow、PyTorch、JAXを通じてニューラル・ネットワークオペレーションのみを実行するように設計されたASICです。

大規模な生成AIモデルのトレーニングまたは推論ワークロードは、最大のアクセラレーター・ハードウェアの容量を超えることがよくあります。ワークロードが単一のGPUでは大きすぎる場合は、1つ以上の並列処理技術を使用して作業を分割して分散することで、複数のプロセッサーに分散できます。並列処理のパラダイムは数多く存在しますが、最も代表的なものはデータ並列処理、テンソル並列処理、パイプライン並列処理です。

開発者は、vLLMなどのオープンソースフレームワークを利用することで、複数のデバイス間で推論を分散させるプロセスを最適化し、多くの場合簡素化できます。