AI推論エンジニアリングへのガイド（17分読了）

制御のない速度は偽りの経済です。AI コード生成がソフトウェア納品を加速する中、FeatureOps Summit 2026 は、より多く出荷する際に壊れることがないようにするためにここにあります。この主要なバーチャルイベントでは、Wayfair、Visa、Mintlify、Lloyds など多くの企業のエンジニア、アーキテクト、製品リーダーが集まり、恐れなき納品のインフラストラクチャーを探求します。 **主要テーマ:** **AI セーフティネット:** 自動生成コードの洪水に対するガードレール。**エッジ耐性:** スケールにおけるサブミリ秒評価。**継続的フロー:** 「固定リリース」マインドセットからの脱却。失敗しないリリース環境に必要なツールとパターンを習得するために、今日登録してください。 [Register Today](https://go.bytebytego.com/Unleashed_061526) LLM が応答を生成するたびに、同じ GPU 上で 2 つの操作が連続して実行されます。最初の操作は入力プロンプトを処理し、単一のトークンを出力します。2 つ目の操作は、その後のすべてのトークンを一度に一つずつ生成します。 外側から見ると、これらは一つのプロセスの段階のように見えます。しかし、ハードウェア内部では、これらには相反するボトルネックがあります。一方は純粋な計算能力によって制限され、他方はメモリを通過するデータの速度によって制限されます。生産環境の AI システムを高速化するエンジニアリング作業の多くはこの分裂に起因しており、それを処理するために使用される技術が推論工学（inference engineering）の基礎となっています。 推論エンジニアリングは、訓練済み AI モデルを生産環境で効率的に実行するための分野です。この仕事には、低レベルの GPU コード、モデルサービングフレームワーク、そしてそれらを結びつけるクラウドインフラストラクチャが含まれます。この分野のエンジニアたちは、レイテンシ（遅延）、スループット、コスト、品質のいずれかの組み合わせを最適化の対象としますが、具体的なバランスは支援する製品によって異なります。数年前までは、こうした仕事はほぼ完全に最先端 AI 研究所の中で行われていました。今日では、本格的な AI ワークロードを実行するあらゆる企業が投資する広範な専門分野となっています。 この記事では、推論がどのように機能し、なぜこの分野の最適化技術が存在するのかを順を追って解説します。 *免責事項：本投稿は、さまざまなソースから公開された詳細に基づいています。不正確な点にお気づきの方はコメントをお願いします。* 3 年前、推論エンジニアリングはほぼ完全に最先端 AI 研究所内で実践される専門分野でした。この仕事は、業界の他の部分が API を通じて消費するクローズドモデルを構築する少数のエンジニアたちに関わるものでした。しかし、2024 年以降、この状況は劇的に変化しました。 オープンモデルがこの変化を牽引しました。AI モデルの公開レジストリである Hugging Face には、現在 200 万を超えるオープンモデルが登録されており、5 年前の数値のおよそ 25 倍に達しています。DeepSeek V3 などのオープンリリースにより、クローズドモデルとの能力格差は縮まり、企業にとってはクローズド API の利用料を支払うか、自前でオープンモデルを実行するかという現実的な選択肢が生まれました。 オープンモデルを自社でホストすることは、クローズド API に比べて以下の 3 つの運用上の利点をもたらします： - レイテンシプロファイルは、特定の製品のワークロードパターンに合わせてチューニング可能であり、パブリック API は多くの顧客にわたる一般的なスループットを最適化しています。 - 専用デプロイメントではアップタイムが 4 つの 9（99.99%）以上を達成でき、パブリック API で典型的な 2 つの 9（99.9%）と比較して有利です。 - スケール効果により、エンジニアリング投資に見合うボリュームに達すれば、コストは通常約 80% 低下します。 その結果、多くのカテゴリの企業が本格的な推論スタックを構築するようになり、AI ネイティブのスタートアップから既存ワークフローに AI を統合した確立された製品、さらに従来慎重だった医療分野に至るまで含まれています。 Cursor は代表的な例です。同チームはオープンモデルの上に Composer 2.0 を構築し、広範な推論エンジニアリングを適用することで、クローズド API が提供するものよりも低いオートコンプリートのレイテンシを実現しました。 なぜ推論エンジニアリングが現在の姿をしているのかを理解するには、プロンプトが LLM（大規模言語モデル）に到達した際に実際に何が起こるかを理解する必要があります。このプロセスは、GPU に対して非常に異なる物理的負荷を要求する 2 つのフェーズに分かれます。 トークンは、LLM が扱う原子単位です。おおよそ、単語または単語の一部を指します。「inference」という単語は 1 トークンですが、「engineering」は 2 つに分割される可能性があります。秒間あたりのトーク数（tokens per second）というレイテンシ指標もこの単位で計測されます。 最初のフェーズはプリフィル（prefill）と呼ばれます。 モデルは入力プロンプト全体を受け取り、すべての重み層を並列に処理します。このバーストから得られる2 つの出力とは、応答の最初のトークンと KV キャッシュです。KV キャッシュは、アテンション機構からの中間値を保存する構造体であり、より多くのトークンが生成される際に参照できるようになっています。 プリフィル（初期処理）は計算リソースに制約されます。GPU の数値演算ユニットがボトルネックとなります。なぜなら、すべての入力トークンがモデルの各層を通じて同時に処理されるためです。この段階には、より多くの純粋な計算能力を投入することで高速化が可能です。プリフィルのパフォーマンスを表す指標は「最初のトークンまでの時間（TTFT）」です。ChatGPT にプロンプトを送信してから最初のトークンが表示されるまでのわずかな遅延が、まさにプリフィルの動作を示しています。 2 つ目のフェーズはデコードフェーズです。モデルは各トークンを1 つずつ生成し、各トークンに対して重み層全体を順方向に完全に通します。新しいトークンはそれ以前のすべてのトークンに依存するため、このプロセスは本質的に逐次的になります。長い応答では、GPU はこれを数千回実行することになります。 デコードはメモリー帯域幅に制約されます。数値演算のスループットは主にアイドル状態となり、GPU のサイクルの多くは、各順方向パスのためにメモリからモデル重みを読み込むことに費やされます。ボトルネックは演算ではなくデータ転送にあります。デコードのパフォーマンスを表す指標は「1 秒あたりのトークン数（TPS）」です。長い応答におけるストリーミング速度が、まさにデコードフェーズの動作を示しています。 prefill と decode は逆のボトルネックを抱えているため、一方のフェーズを加速する技術は他方のフェーズにはほとんど影響を与えません。これがベンチマークで TTFT（Time To First Token）と TPS（Tokens Per Second）が別々の数値として報告され、各フェーズのパフォーマンスが独立して測定される理由です。 この分割はまた、推論エンジニアリングの残りの部分を組織化する構造的洞察でもあります。prefill と decode を2 つの異なる操作として理解すれば、分野内の技術は自然と3 つのグループに分類されます：prefill を加速するもの、decode を加速するもの、そして両者のバランスを再調整するものです。 上記の図は少し単純化されています。実際の推論エンジンでは、バッチ処理やスケジューリングなど、他の複雑な要素が層状に重ねられて実行されており、そのすべての下で prefill-decode の分割という構造が維持されています。これが、本記事の残りの部分の基礎として機能する理由です。 prefill-decode の分割を意識すれば、推論エンジニアリングにおける主要な技術ははるかに整理しやすくなります。各技術は特定のフェーズを加速するか、異なる理由で両方に作用するか、あるいはシステム構造そのものをこの分割を中心に再構築します。 それでは、6 つの技術をそれぞれ詳しく解説しましょう。 バッチ処理（Batching）は、単一の GPU の出力をスケーリングする最も基本的な方法です。推論エンジンは複数のリクエストをトークン単位で織り交ぜて実行するため、1 つの GPU で同時に多くのユーザーに対応できます。GPU の計算容量がリクエスト間のアイドル状態ではなく最大限に活用されるため、スループットは大幅に向上します。 その代償として、ユーザーごとのレイテンシが増加します。 バッチ処理を行わないシステム上の単一ユーザーは、可能な限り最短の応答時間を得ますが、同じユーザーが重度にバッチ処理されたシステムでは、GPU が他のリクエストも処理しているため、より長い待ち時間が発生します。このトレードオフこそが、あらゆる他の技術が回避しようとする主要な緊張関係であり、異なる製品はこのスペクトラム上の異なる地点で位置づけられています。消費者向けのチャットツールは低レイテンシを重視し、バッチ処理パイプラインは高いスループットを優先する傾向があります。 プレフィックスキャッシング（先頭部分キャッシュ）は、リクエスト間で KV キャッシュ（キー・バリューキャッシュ）の値を再利用することで、プリフィル（事前計算）フェーズを加速します。2 つのプロンプトが共通の冒頭セグメント（例えば、数千件のリクエストで同一となる長いシステムプロンプトなど）を共有する場合、エンジンはそのプレフィックスを一度だけ計算し、その後はキャッシュから読み出します。これが API プロバイダーがキャッシュされた入力トークンに対して料金を安く設定する理由です。 ただし、このキャッシュの恩恵は、シーケンスの先頭から最初の不一致トークンに至るまでしか得られません。2 つのプロンプト間で最初のトークンが異なる場合、残りのシーケンスが完全に一致していても、プレフィックスキャッシングによる節約効果はゼロとなります。したがって、プロンプトの構造には直接的なコストとレイテンシへの影響があり、共有コンテンツを先頭に配置し、可変的なユーザー入力を後方に配置することで、キャッシュが活用できる余地を作ることができます。 量子化（Quantization）は、異なる理由ではあるものの、推論の両フェーズにおいて有益です。 基本となる手法は、モデルの重みをより低い精度の数値形式で保存することです。現代のほとんどのモデルは 16 ビット浮動小数点（floating-point）で学習されますが、量子化（quantization）によってこれらの値を 8 ビットまたは 4 ビットの表現に圧縮します。これにより、重みのサイズが小さくなりメモリ使用量が削減され、データ転送の必要も減ります。 プリフィル（prefill）が高速化する理由は、現代の GPU 内部にある専用数学演算ユニット上で低精度の計算がより速く実行されるためです。デコード（decode）が高速化する理由は、メモリ帯域幅への負荷が軽減され、各フォワードパスで重みをメモリからより迅速に読み込めるようになるためです。精度を一段階下げることで、モデルや適用された技術によって異なりますが、概ね 30% から 50% の性能向上が得られます。 その代償として、品質の低下というリスクがあります。また、モデル内の異なる部分は量子化に対して異なる耐性を持っています。 線形層（linear layers）の重みはこれに良く耐えますが、活性化値（activations）はやや敏感であり、KV キャッシュ（KV cache）はさらに敏感です。そして何よりも、アテンション層（attention layers）が最も敏感です。その理由は、アテンション層における小さな精度誤差がトークンのシーケンス全体にわたって累積し、各トークンの計算が前の計算に基づいて行われるためです。そのため、わずかな誤差でも長い応答期間中に雪だるま式に膨らみ、意味のある品質低下へとつながります。 この理由から、多くの本番環境（production）のセットアップでは、アテンション層は完全な精度で維持されます。量子化におけるエンジニアリング作業の大部分は、どの部分を圧縮し、どれほど積極的に圧縮するかを決定することに帰着します。 Speculative decoding は、非対称性を活用することでデコードプロセスを加速します。ゼロからトークンを生成するのは高コストですが、候補となるトークンがメインモデルが生成するものと同じかを確認することははるかに安価です。この点で、数独のパズル解決には労力が必要である一方、完成したパズルの確認は迅速であるというアナロジーが成り立ちます。 Speculative decoding では、小さなドラフトモデルが次のいくつかのトークンを予測し、メインモデルがそれらすべてを単一のフォワードパスで検証します。メインモデル自身の予測と一致するトークンは受け入れられ、残りは拒否されます。その結果、通常は 1 つしか現れないはずのトークンが、メインモデルを通る単一のフォワードパスあたり複数個出現することになります。 Speculative decoding は、プリフェッチ（prefill）が通常通り実行されるため、TPS（Tokens Per Second）を向上させつつ、TTFT（Time To First Token）は変化させません。この手法は、GPU に余剰な計算リソースがあり検証に費やせる場合、つまりバッチサイズが小さい場合に最も効果的です。一方、バッチサイズが大きくなり一度に多くのリクエストを処理している場合は GPU がすでに飽和状態であり、すべてのサイクルがメインのワークロードに必要なため、推測（speculation）は動的に無効化されます。 並列化技術により、単一の GPU では不足する場合、つまりモデルが大きすぎてメモリに収まらない場合や、単一 GPU のレイテンシが高すぎる場合に、大規模モデルを複数の GPU にわたって実行することが可能になります。オープンなモデルの現状において支配的な 2 つの主なアプローチは、テンソル並列化（tensor parallelism）とエキスパート並列化（expert parallelism）です。 テンソル並列化は、モデルの各層を複数の GPU に分割します。各 GPU は各層の一部を持ち、順伝播ごとに作業を共有します。これには NVIDIA の NVLink などの高帯域幅インターコネクトが必要であり、結果は各層の後に結合される必要があるためです。テンソル並列化は、非常に大規模な密モデル（dense models）のサービスにおいてデフォルトの選択肢となります。ここでは、帯域幅を多く消費する通信が、層ごとの作業を共有することによる速度向上によって相殺されます。 エキスパート並列化は、混合エキスパートモデル（mixture-of-experts models）に特化した手法です。このモデルでは、各トークンに対してモデルパラメータの一部のみが活性化します。異なるエキスパートは異なる GPU に分散され、トークンは必要なエキスパートへルーティングされます。エキスパートは独立して動作するため、通信オーバーヘッドはテンソル並列化よりも低く、帯域幅がより限られているマルチノード展開に適しています。実際の生産環境でのデプロイでは、両方を組み合わせて使用することが多く、ノード内ではテンソル並列化を、ノード間ではエキスパート並列化を採用します。 非集約（disaggregation）は、プリフィルとデコードの分割を文字通り適用するアプローチです。アイデアとしては、プリフィルをある GPU セットで実行し、デコードを別の GPU セットで実行し、KV キャッシュ（Key-Value cache）をネットワーク経由で両者の間で転送することです。各セットは特定のボトルネックに最適化されたハードウェアを使用し、それぞれのトラフィックパターンに基づいて独立してスケーリングします。 このフローは 3 つのステップのプロセスになります： - Prefill エンジンは入力シーケンスを受け取り、最初のトークンと KV キャッシュを生成します。 - このキャッシュは高速な相互接続を介してデコードエンジンに送信され、デコードエンジンがその後のすべてのトークンを処理します。 - 条件付きの分離では、短いかすでにキャッシュされたリクエストはハンドオフを完全にスキップし、デコードエンジンだけで実行されます。これは、長いプロンプトと短いプロンプトの混合を含む実際のトラフィックに対してより優れたパフォーマンスを発揮します。 分離（disaggregation）は、ここで取り上げられた技術の中で最もアーキテクチャ的なアプローチです。これは、prefill と decode を別々のサービスとして扱い、それぞれに異なる運用上の課題があるものとして扱います。これにより、オペレーターは各サービスを独立してスケールするためのレバーを手にすることができます。大規模な推論を実行している企業では、ワークロードのミックスが十分に理解された段階で、この手法をほぼ必須のステップと考えることが一般的です。 これらの技術を本番環境に導入することは真剣に取り組むべき課題であり、複数の技術を組み合わせることでさらに複雑さが増します。すべてのエンジニアリングチームが答えなければならない問いは、この作業を引き受けるか、それとも市販の API のままが適切な選択かどうかです。その答えは製品の段階によって異なります。 AI プロダクトの構築初期段階では、確立されたプロバイダーからの市販 API を利用することがほぼ常に最適な選択です。意味のある最適化には、実際に機能する現実的な制約が必要であり、初期段階のプロダクトはトラフィックパターン、レイテンシ要件、単体経済性について不確かな仮定を抱いている傾向があります。この段階でのエンジニアリングの努力は、プロダクトをリリースすることに注ぐべきです。なぜなら、カスタム推論スタックの運用に伴う複雑さが、実際には重要となるイテレーション速度を低下させてしまうからです。 方程式が変化したことを示すシグナルとして、通常以下の 3 つが挙げられます： - API コストが意味のある支出項目に成長した。 - レイテンシ要件がクローズド API が提供できる範囲を超えた。 - 信頼性要件がベンダーの SLA で保証されるレベルを上回り始めた。 Cursor はこの移行をうまく処理しました。サブ秒単位の自動補完レイテンシこそがプロダクトそのものであり、クローズド API は多数の顧客にわたる一般的なスループットを目指しますが、コード補完モデルは特定の速度形状を要求します。オープンモデルをセルフホストし、スタック全体に推論エンジニアリングを適用することで、レイテンシ目標を達成可能にし、投資対効果も得られました。なぜなら、制約が現実的なものであり、ワークロードが十分に理解されていたからです。 LLM 推論は、物理的制約が正反対である 2 つの操作から成り立っています。 Prefill は計算リソースに制約され、1 リクエストごとに 1 回実行されます。Decode はメモリー帯域幅に制約され、トークン生成ごとに 1 回実行されます。推論エンジニアリングにおける技術のほとんどは、この 2 つのフェーズの分離によって存在しており、これを理解することが分野全体をより容易にナビゲートする鍵となります。 上記で取り上げた各技術は、prefill-decode フレームワークの中に位置づけられます: - Batching（バッチ処理）は、ユーザーごとのレイテンシと引き換えに総スループットを向上させます。 - Prefix caching（プレフィックスキャッシュ）は、プロンプトの冒頭部分が共通している場合に prefill 作業を削減します。 - Quantization（量子化）はモデル重みを圧縮し、両フェーズを支援します。 - Speculative decoding（推測デコーディング）は、アイドル状態の計算リソースを活用して、decode フェーズからより多くのトークンを引き出します。 - Parallelism（並列処理）は、複数の GPU にわたってモデルをスケーリングします。 - Disaggregation（非集約化）は、prefill と decode を完全に異なるハードウェア上で実行します。 これらの上に重ねられるのが、ビルドか購入かの選択です。初期段階の製品では、市販の API が依然として最適な選択肢ですが、API コストが実質的な経費項目となる場合や、レイテンシ要件がクローズドな API の提供能力を超えた場合、あるいは信頼性要件がベンダーの SLA を上回る場合に、セルフホスティングが意味を持ち始めます。 **References:** - Hugging Face Hub Documentation - DeepSeek-V3 Technical Report -Cursor — Composer: 強化学習を用いた高速な最前線モデルの構築 -Cursor — Composer 2 の紹介 -DistServe: 処理効率を最適化した大規模言語モデル推論におけるプリフィルとデコーディングの非同期化 -PagedAttention を用いた大規模言語モデル推論のための効率的なメモリ管理 -Anthropic — プロンプトキャッシングドキュメンテーション -NVIDIA TensorRT Documentation -Fast Inference from Transformers via Speculative Decoding -Megatron-LM: モデル並列性を用いた数十億パラメータの言語モデルのトレーニング -NVIDIA Megatron-Core Developer Guide — Tensor Parallel -Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer -NVIDIA NVLink and NVLink Switch -Anthropic Claude API Documentation

AI推論エンジニアリングへのガイド（17分読了）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト