推論エンジニアリングのためのオープンフィールドガイド

推論エンジニアリングのためのオープンフィールドガイド

注意

*数値、価格、ツールのバージョンは2026年10月時点のものです。

このガイドは、推論に不慣れなプラットフォームエンジニア向けです。モデルとGPUがどのように連携し、本番環境で推論を実行する方法を理解する必要がある場合、このガイドがお役に立ちます。使用すべきツールや、推論エンジニアリングの役割にどのように成長していくかについても学べます。

このガイドは、推論コミュニティの他の人々の業績に基づいています。推論エンジニアリングに興味がある場合は、以下で学習を続けてください。

• Viktor FarcicのLLM推論解説
• Philip Kielyの推論エンジニアリング
• The Pragmatic Engineer, 推論エンジニアリングとは？
• ByteByteGoのAI推論エンジニアリングガイド
• Data Gravity, 推論エンジニアリングの台頭
• Spheronの推論エンジニアリングガイド
• Vishakha SadhwaniのAI推論エンジニアリングロードマップ
• Upbound, プロジェクトシャンパンシリーズ

1. なぜ今なのか？

AIを重視する組織では、プラットフォームチームが推論チームになります。コーディングアシスタントはソースコードを第三者に送信できず、最先端モデルの請求額は月々増加します。サポートツールも、ホストされたモデルが到達できない内部データが必要です。

組織はこれらのモデルを自社で実行したいと考えており、オープンモデルがそれを実用的にしています。

Hugging Faceは200万以上のオープンモデルをホストしており、その中でも最良のものはクローズドモデルと競合します。DeepSeekは2025年1月にR1をリリースし、o1リリースから約1か月後に数学とコーディングのベンチマークでOpenAIのo1に匹敵しました。独自のモデルを実行すると、レイテンシ、稼働時間、データの行き先を制御できます。高負荷時には、コストを約80%削減することも可能です。

この作業はプラットフォームエンジニアに適しています。固定レベルのAI機能の価格は年間約10倍に低下しており、そのほとんどはGPUの改善ではなく、モデルの提供方法によるものです。CrossplaneとModelplaneの背後にある企業であるUpboundは、これを直接経験しました。そのプロジェクトシャンパンブログシリーズで、チームはModelplane上で独自のモデルを実行し、vLLMとスケジューリングが機能することを発見しました。時間はTLS、ID、タイムアウト、ストレージ、IAM、オブザーバビリティに費やされました。

引き継がれるスキル

推論エンジニアは、モデルを選択し、適切なGPUに配置し、サービスを維持し、高速化・低コスト化し、問題発生時にページングされます。これは新しいワークロードに対するSREであり、ほとんどのスキルは引き継がれます。

ホストされたAPIは、製品ライフサイクルの初期段階では依然として正しい選択肢です。API支出が実際の項目になった場合、レイテンシや信頼性のニーズがベンダーのそれを超えた場合、またはデータがネットワークを離れられない場合に、自己ホスティングが利益をもたらします。2026年8月、Chris Zeoliは公開キャリアボードで約58件のオープンな推論職を数えましたが、確立された役職名はありませんでした。

2. 推論101

このセクションでは、概念をほぼ出会う順にカバーします。ほとんどは、エンジンがGPUメモリに保持するもの、または速度を制限するものが何であるかに関するものです。

Viktor Farcicは、各概念がいつ重要になるかを尋ねることを提案しています。いくつかはデプロイメント直後に重要になり、いくつかは多くの人がモデルを使用するようになってから重要になり、いくつかは決して必要にならないかもしれません。このセクションの最後の表は、それぞれのシグナルを示しています。

推論エンジンとは

vLLMやSGLangのような推論エンジンは、モデルの重みをAPIに変換するサーバーです。プラットフォームエンジニアにとって、最も近いメンタルモデルは、GPUが接続されたステートフルデータベースサーバーです。起動時に大規模なデータセットをメモリにロードし、セッションごとの状態を保持します。また、内部で作業をスケジュールし、HTTP経由で応答します。ラップトップ上のOllamaは、小規模なスケールで同じアイデアであり、ホストされたすべてのモデルAPIは、その背後でこれを実行しています。

データベースとは異なり、エンジンは作業セットをシステムRAMではなくGPUメモリに保持します。GPUメモリは小さく高価なので、ほとんどのチューニングは、各リクエストがそのうちのどれだけを取得するかを決定することです。

推論スタック

エンジンは4つのレイヤーの1つです。最下層では、カーネルが算術演算を行います。あなたはめったに直接それらを選択しません。それらの上にはエンジンがあります。その上には、エンジンをデプロイおよび管理するコントロールプレーンがあります。なぜなら、遅かれ早かれあなたは1つ以上を実行することになるからです。最上部には、モデルとレプリカ間でトラフィックをルーティングするゲートウェイがあります。

［画像: 推論スタック：4つのレイヤーとそれらがサービスを提供するクライアント］

推論スタック：4つのレイヤーとそれらがサービスを提供するクライアント

リクエストはゲートウェイを通過してエンジンに到達し、エンジンはGPU上でカーネルを実行します。コントロールプレーンはゲートウェイとエンジンをデプロイおよび管理しますが、リクエストはそれを通過しません。

トークン

トークンは、言語モデルが処理する単位であり、おおよそ単語または単語の断片です。コンテキストウィンドウ、価格、速度はすべてトークンでカウントされます。誰かがトークン/秒を引用する場合、それはこの単位を意味します。

重みとKVキャッシュ

重みは固定されており、KVキャッシュは負荷とともに増加します。両方のサイズは、データベースのフットプリントと作業セットのように考えます。

重みは固定フットプリントです。ほとんどのモデルは、パラメータあたり2バイト（BF16またはFP16）でリリースされるため、8Bモデルは約16 GBを必要とし、システムRAMではなくGPUメモリに存在する必要があります。48 GBのL40Sでは、カードの約3分の2が他のすべてに使用できます。その数は、ユーザーが1人でも100人でも同じです。

KVキャッシュは作業セットです。各新しいトークンは、それ以前のすべてのトークンに対して計算されます。その履歴を再計算する代わりに、エンジンは進行中の各トークンのアテンションキーと値を保持します。そのサイズは、コンテキスト長に並行会話数を掛けたものに比例してスケーリングします。これは、セッションサイズとユーザー数の両方で増加するセッションストアに似ています。

モデルの構成から、トークンあたりのKVキャッシュを推定できます。

トークンあたりのKVバイト数 = 2 × レイヤー数 × KVヘッド数 × ヘッド次元 × 値あたりのバイト数

Llama 3 70B（FP16、80レイヤー、8 KVヘッド、ヘッド次元128）の場合、これはトークンあたり約320 KBです。128Kトークンの会話には約40 GBのキャッシュが必要です。そのサイズでは、KVキャッシュが通常、GPUがサービスできるユーザー数を制限します。

これらのサイジングミスに注意してください。

• Mixture-of-experts (MoE) モデルはすべての重みを常駐させます。 320Bの総パラメータと18Bのアクティブパラメータを持つモデルでも、FP8で約320 GBが必要です。計算のみがアクティブパラメータに比例してスケーリングします。

• チェックポイントサイズを読み、dtypeテーブルを読まないでください。 プロジェクトシャンパン（パート2）のために独自のモデルを自己ホストしていた間、UpboundはdtypeからMoEモデルを約315 GBと見積もりました（パート2）。実際のチェックポイントは177.7 GBでした。なぜなら、エキスパートは4ビット形式で保存されていたからです。

• ランタイムオーバーヘッドの余地を残してください。 CUDAグラフ、アクティベーション、メモリフラグメンテーションはすべてスペースを消費します。起動時にフィットしたモデルでも、数日後にメモリ不足になる可能性があります（プロジェクトシャンパン、パート2）。

2つのフェーズ、2つのボトルネック

各リクエストは、同じGPU上で2つのフェーズで実行され、それぞれ異なるもので制限されます。

1つのトークンを生成するには、メモリから読み取られたバイトあたり1つまたは2つの浮動小数点演算が必要です。H100は、忙しく保つためにバイトあたり約295回の演算が必要です。これは、Data Gravityによると、1つのリクエストがチップのわずかな割合しか使用せず、計算ユニットがメモリを待機していることを意味します。

ピーク計算能力は2年ごとに約3倍に増加していますが、メモリ帯域幅は約1.6倍です。ほぼすべての最適化は、トークンあたりのバイト数を減らすか、各バイトをより多くのトークンに分散させるかのいずれかです。

フェーズは逆のボトルネックを持つため、一方を高速化するテクニックは、もう一方にはほとんど効果がないことがよくあります。これが、ベンチマークがTTFTとトークン/秒を別々に報告する理由です。

追跡すべきメトリクス

トークンあたり百万コストは、GPU価格とスループットを1つの比較可能な数値に変換します。

トークンあたり百万コスト = GPUコスト/時間 / (トークン/秒 × 3600) × 1,000,000

Spheronの実例：時給2.90ドルのGPUが1,200トークン/秒を維持する場合、100万トークンあたり約0.67ドルかかります。

レイテンシ対スループット

より多くのリクエストをまとめてバッチ処理すると、全体のスループットが向上し、個々のユーザーの速度が低下します。インタラクティブなチャットとコーディングはレイテンシを優先します。夜間のバッチジョブはスループットを優先します。

これは、トランザクションまたは分析用にデータベースをチューニングするのと同じトレードオフです。チューニングする前に、ワークロードの制約を書き留めてください。

各概念を採用する時期

各行は、チームが必要になるおおよその順序で、行動を起こす必要があることを示すシグナルを提供します。

ほとんどのチームは初日に最初の数行しか必要としません。シグナルが現れたら、残りを追加してください。

エージェントが変えること

コーディングエージェントやその他のエージェントワークロードは、このすべてに負荷をかけます。Upboundは、Project Champagneシリーズのパート5（セクション1で紹介）でこれを測定しました。そこでは、約10人のエンジニアがClaude Codeやその他のコーディングエージェントを自己ホストモデルに対して実行しました。彼らのトラフィックは次のようになりました。

• プロンプトは長いです。 中央値プロンプトは59Kトークンで、p90は125Kでした。

• プロンプトはほとんどが繰り返しです。 プロンプトトークンの約3分の2はプレフィックスキャッシュにヒットします。なぜなら、エージェントはターンごとにトランスクリプトを再送信するからです。

• 思考は隠されています。 推論モデルは、最初の表示可能なトークンが表示される前に1分以上考えることがあります。エージェントとモデル間のすべてのタイムアウトは、それを許容する必要があります。

• 負荷はクライアントに依存します。 短いプロンプトセッションはサブエージェントを起動し、長いプロンプトセッションよりも多くのリクエストを進行中に保持できます。シートではなく、進行中のリクエストで容量を計画してください。

• セッションは数時間実行されます。 ストリーム、ツール呼び出し、認証情報はすべて、その期間中機能し続ける必要があります。

3. 本番環境での推論実行

本番環境では、すべての選択肢がレイテンシ、スループット、コスト、品質を互いにトレードオフし、通常はGPUが不足しています。プラクティスがProject Champagneのセクション5から来ている場合、詳細はそこにあります。

3.1 ハードウェアではなくユースケースから始める

各ユースケースは異なる要件を設定します。Project Champagneでは：

• コーディングエージェントは、品質低下なしの長いコンテキスト、信頼性の高いツール呼び出し解析、ストリーミング、数時間持続するセッション、Claude Code用のAnthropic互換APIを必要としました。

• チャットは、低い初回トークンまでの時間、実際の同時実行性、既存ツール用のOpenAI互換APIを必要としました。

• プラットフォームは、実際のホスト名でのTLSと、会社ドメインに関連付けられたIDを必要としました。また、健全なエンジンとビジーなエンジンを区別するオブザーバビリティと、監視なしでの正しい配置も必要でした。

インタラクティブワークロードとバッチワークロードを分離してください。それらは異なるターゲットを必要とし、多くの場合異なるデプロイメントを必要とします。テストする前に、合格と不合格の基準を書き留めてください。

3.2 モデルを慎重に選択する

• 独自のタスクで評価する。 公開ベンチマークは、他人のワークロードを測定します。セクション3.11でその方法をカバーします。

• 小さく始めて、成長させる。 数十億のアクティブパラメータを持つ小さなMoEモデルは、運用経験をより速く構築し、間違った場合のコストを削減します。

• 最新のモデルが常に正しいとは限りません。 モデルリリースはハードウェア計画よりも速く動きます。新しい「小さな」フラッグシップモデルは、いくつかの最大のカードを必要とする場合がありますが、現在のモデルはサポートされているコンテキストの半分で実行されている可能性があります。最も安い利益には新しいモデルが全く必要ないかもしれません。

• エンジンが実際にロードできることを確認する。 リリースノートでサポートされているとリストされているモデルでも、ハードウェアとエンジンのビルドでロードに失敗する場合があります。

• ライセンスを確認する。 ほとんどのオープンモデルは許可ライセンスを使用していますが、一部は商用利用を制限しています。

• チャットテンプレートとパーサーを確認する。 ツール呼び出しと推論出力は、各モデルがエンジンで必要とする設定に依存します。間違った設定は、すべてのリクエストが200を返す間、ツールの使用を妨げます。

3.3 ランタイムではなく、実行時にサイズを決定する

起動時にフィットするモデルでも、フラグメンテーションがプロファイルされたピークを超えると、実際のトラフィック下でメモリ不足になる可能性があります。これは数日後、リクエストの途中で発生する可能性があります。

• 3つのコストすべてを予算化する： 重み、KVキャッシュ、およびCUDAグラフやアクティベーションなどのランタイムオーバーヘッド。

• エンジンのメモリ設定が何をカバーしているかを知り、アップグレードごとに再度確認する。 vLLMは、CUDAグラフプール、および実際のトラフィックがその推定を超える可能性のあるすべてのものからの起動推定値からKVキャッシュをサイズ設定します。負荷中にメモリ不足エラーが発生した場合は、メモリの割合をわずかに下げ、拡張可能なセグメントを有効にし、同時シーケンスを制限してから、空きメモリを再度測定してください。

• 各リクエストを制限する。 各呼び出しで最大出力長を設定します。それがないと、任意のリクエストがモデルをすべての人にとってダウンさせ、放棄されたリクエストはクライアントが諦めた後も生成を続けます。

• コンテキストを慎重に短縮する。 最大コンテキストを短くすると、より多くのユーザーのためにKVキャッシュが解放されます。また、より長い会話をすべて拒否するため、それらの拒否をエラーとしてカウントしてください。

3.4 最適化技術を知る

ほとんどのエンジンは、デフォルトで継続的なバッチ処理とページングされたKVキャッシュをオンにします。残りは、モデルとワークロードごとに選択するオプションです。

いくつかの経験則：

• キャッシュのためにプロンプトを構造化する。 プレフィックスキャッシュは、最初の異なるトークンで停止します。システムプロンプトやツール定義のような共有コンテンツを最初に置き、可変ユーザー入力を最後に置きます。ホストAPIは、同じ理由で、2026年現在、キャッシュされた入力を新鮮な入力の10〜50%の価格で提供します）。

• 最も敏感なものから順に量子化する。 線形重みは量子化に最も耐性があり、次にアクティベーション、次にKVキャッシュです。アテンションレイヤーは、長いシーケンス全体で小さなエラーが累積するため、最も敏感です。評価でより低くできることが示されるまで、最も敏感な部分を高精度で保持してください。FP8のような浮動小数点形式は、整数形式よりも外れ値値をより良く処理します。

• 投機的デコーディングの受け入れを確認する。 受け入れは、温度、主題、ドラフトモデルに依存します。受け入れが崩壊した場合、各パスは推測のコストを支払い続け、他のパネルは正常に見える間、モデルは遅くなります。

• 複数のテクニックを適用する際の相互作用に注意する。 KVキャッシュの量子化は非集約に役立ちます。より大きなバッチは、投機のために余剰計算能力をほとんど残しません。あるBasetenエンジニアは、顧客のスループットを倍増させる構成を77個試しました（推論エンジニアリング）。一度に1つのことを変更し、測定してください（セクション3.10）。

• 長いプロンプトが他のストリームを停止させないようにする。 チャンク化されたプリフィルは、長いプロンプトを複数のパスに分割するため、デコードは他のすべての人のために移動し続けます。現在のvLLMはデフォルトでこれをオンにしており、非集約を検討する前に、パスあたりのトークン予算が調整すべき設定です。

3.5 GPUを取得し、正しく配置する

• クォータは容量を保証しない。 クォータはインスタンスを要求することのみを許可します。各インスタンスサイズは、同じGPUであっても独自の容量プールであり、どのクラウドAPIも実際に起動できるものを教えてくれません。

• 取得できるGPUに合わせて設計する。 計画したGPUを常に取得できるとは期待しないでください。モデルは、異なるゾーンのより小さなノードに分割され、通常のネットワーク経由でパイプライン並列処理を使用する可能性があります。マルチゾーンプールを許可し、モデル定義をインスタンスタイプとノードカウントから独立させてください。

• モデルとハードウェアを明示的に一致させる。 Kubernetes Dynamic Resource Allocation (DRA) デバイスセレクタは、モデルをGPUアーキテクチャまたは最小メモリサイズにピン留めできます。ステータスフィールド（宣言したことをエコーする）ではなく、GPUドライバーが公開するものに対して配置を確認してください。

• コントローラーだけでなく、クラウドを監視する。 マネージドノードグループは失敗を報告する可能性がありますが、クラウドはインスタンスの起動を試み続け、数時間後に到着したGPUはプールの後続の変更によってシャットダウンされる可能性があります。インスタンスとノードの参加を追跡し、プールを変更する前にプールのインスタンスをリストしてください。

• インターコネクトを知る。 H100、H200、B200のようなSXMデータセンターGPUはNVLinkでGPUをリンクします。L40SやRTX PRO 6000のようなPCIeカードはそうではないため、マルチGPU通信はPCIeとホストメモリを介して行われます。これは、どの並列処理戦略が有利になるかを変えます。

• システムプールもサイズ設定する。 GPUノードは推論のためにテイントされています。監視、コントローラー、ゲートウェイは、残りの一般的な容量を競合します。

3.6 ゲートウェイ、ルーティング、タイムアウト

• ラウンドロビンしない。 1つのレプリカはすでに会話のプレフィックスをキャッシュしている可能性がありますが、別のレプリカはそれを一度も見たことがないかもしれません。キャッシュアウェアまたはプレフィックスアウェアルーティングを使用してください。例：Gateway API Inference Extensionのエンドポイントピッカー。

• モデル名でルーティングする。 1つのホスト名が、リクエストのモデルフィールドに基づいてルーティングされる多数のモデルを提供できます。

• 両方の一般的なAPIを話す。 ほとんどのツールはOpenAI APIを期待しています。Claude CodeはAnthropic Messages APIを期待しており、vLLMはストリーミングとツール呼び出しを含め、ネイティブに提供します。

• パス上のすべてのタイムアウトを増やす。 長い生成と推論モデルはデフォルトを破ります。なぜなら、各ホップには、数分かかる生成ではなく、Webリクエスト用にサイズ設定されたデフォルトのタイムアウトがあるからです。典型的な原因は、応答全体を制限するゲートウェイのルートタイムアウト、ロードバランサーのアイドルタイムアウト、および待機時間を増やすリトライです。ルート、各ロードバランサー、ゲートウェイ、クライアント、およびクライアントが行うヘルパー呼び出しを確認してください。

• 切り詰められたストリームを検出する。 カットされたストリームは、有効なトークンでHTTP 200を返してから停止する可能性があります。クライアントにとっては、完了した回答のように見えます。

• 呼び出し元ごとに使用量を測定する。 トークンベースのレート制限とゲートウェイでのクォータは、1人のヘビーユーザーまたは暴走したエージェントが他のすべてを飢えさせないようにします。

3.7 セキュリティとID

• オープンエンドポイントを公開しない。 ゲートウェイがアドレスを取得する前に認証ポリシーを適用し、削除するときに最後に削除します。

• 実際のホスト名で実際のTLSを使用する。 証明書の発行と更新の計画を立てます。

• 3種類のクライアントを計画する。 人間が最も簡単なケースです。ブラウザはページロードやプリフライトリクエストにベアラートークンを添付できないため、ゲートウェイでOIDCを使用してブラウザログインを処理します。エージェントは数時間実行され、認証情報を一度読み取るため、60分間のIDトークンはセッション中に終了します。エージェントには長寿命のAPIキーまたは更新される認証情報を提供します。

• 2つの有効期限切れセッションをスタックしない。 アプリケーション自体にログイン機能がある場合に、外部ゲートウェイログインを前面に配置すると、外部セッションが期限切れになったときに障害が発生します。

• 拒否されるべきものをテストする。 ゲートウェイが拒否しなければならないリクエスト（欠落、無効、署名なし、期限切れまたは取り消されたキー、偽装された呼び出し元ヘッダーなど）のプローブマトリックスを構築します。到達可能でなければならないパス（ヘルスチェックなど）も含めます。スケジュールどおりにループで実行し、変更中に実行します。

• 使用記録にIDを渡す。 誰が何を送ったかを確認できるようにします。クライアントが偽装しようとする呼び出し元ヘッダーを上書きします。

• モデルの重みをコードのように扱います。pickleベースのチェックポイントよりもsafetensorsを優先し、読んだことのないモデルリポジトリからのリモートコードを有効にせず、各モデルを特定の改訂版にピン留めします。

3.8 オブザーバビリティ

• エンジンをスクレイプする。 エンジンは詳細なPrometheusメトリクスを公開します。何も収集されません。収集するように設定されていない限り、例えばServiceMonitorと名前付きポート。

• コアパネルを構築する： 同時実行性制限に対して実行中のリクエスト、待機中のリクエスト、KVキャッシュの使用量、TTFT、出力トークンごとの時間、リクエストあたりの出力トークン数、プレフィックスキャッシュヒット率、投機的デコーディングの受け入れ、ステータスコード別のエラー、およびキャンセル。

サーバー側で品質を測定する。壊れたツール呼び出し、切り詰められた回答、空の応答は、通常、サービングダッシュボードが正常に見える間にユーザーからの苦情として届きます。それらをサーバー側でカウントします。これには、解析に失敗したツール呼び出し、長さ制限で切り詰められた応答、空の出力、拒否、およびリクエストあたりの隠された推論トークンが含まれます。ゲートウェイはすべての応答を見るため、エンジンがエクスポートしないものをカウントできます。

• GPU-Utilを過ぎて見る。 何かが実行されたかどうかを報告しますが、チップのどれだけが機能したかは報告しません。GPUはほぼ100%のGPU-Utilを報告する可能性がありますが、SMアクティビティは約半分で、テンソルコアはほとんどアイドル状態です。SMアクティビティとテンソルアクティビティもグラフ化します。

• 遅い原因を区別する。 リクエストがキューイングされている場合、実行は制限に達し、待機はゼロを超え、KVキャッシュは満杯です。モデルが思考している場合、TTFTは正常に見えますが、各リクエストは多くの隠されたトークンを書き込みます。生成が遅い場合、出力トークンごとの時間は増加します。

• 監視対象を監視する。 モニタリングスタックの外部にある何かが、データが最新であり、新しいメトリクスが各クラスターから到着していることをチェックする必要があります。メトリクスアダプターはAPIが利用可能であると報告する可能性がありますが、空の結果を返す場合があります。

• デバッグ可能なログを保持する。 メトリクススクレイピングは、保持されたエンジンログのほぼすべてを構成する可能性があります。呼び出し元と共にリクエストごとのアクセスログを保持し、ログストアに送信し、クラッシュ後にkubectl logs --previousを覚えておいてください。

• エンジン間でメトリクス名を正規化する。 vLLMデプロイメントとSGLangデプロイメントが同じシグナルで評価されるようにします。

ユーザーが感じるものにSLOを設定します。リクエストごとにフロントドアで測定します。

• 応答性： ユーザーが実際に目にする最初のトークンまでの時間、しきい値未満。

• 十分な速さ： 出力トークンごとの時間、しきい値未満。

• 回答済み： リクエストはエラーなしで完了し、含まれるツール呼び出しは解析された。

合計リクエスト時間のSLOを設定しないでください。モデルがどれだけ書き込むかに依存するためです。低トラフィックモデルは、フリート全体SLO、より長いウィンドウ、または合成トラフィックを必要とします。欠落データは100%良好と読み取られるため、メトリクスが到着しなくなったことに対する別のアラートを保持してください。SlothやPyrraのようなオープンソースツールは、SLO定義をバーンレートアラートに変換します。背景については、オブザーバビリティエンジニアリングを参照してください。

3.9 自動スケーリングとコールドスタート

• 推論シグナルでスケーリングする。 キューの深さ、KVキャッシュ使用量、進行中のリクエストなど。CPU使用率はここではほとんど何も教えてくれません。

• トラフィックと負荷を組み合わせる。 トラフィックは需要の前にスケーリングを可能にし、負荷はそれに遅れて追従します。設定は、他のどのオートスケーラーでも調整する設定と同じです。最小および最大レプリカ数とメトリクスウィンドウの長さを設定します。次に、スケールダウン遅延と、1つのレプリカが保持すべき同時リクエスト数を設定します。Kielyの書籍では、推論のためにそれぞれを詳細に説明しています。

• 遅いコールドスタートを計画する。 新しいGPUノードは起動し、大きなエンジンイメージをプルし、重みをロードする必要があります。重みのロードだけでも、大規模モデルでは30分かかる場合があります。各クラスターの共有ストレージに重みをキャッシュして、新しいレプリカが再度ダウンロードしないようにします。

• ゼロへのスケーリングには注意する。 ノードが準備できる頃には、スパイクは終わっている可能性があり、希少なGPU容量が戻ってこない可能性があります。

• 大規模な場合は複数のクラスターを計画する。 数百GPUを超えると、容量はワークロードをリージョンやプロバイダー全体に分散させます。別々のプールを1つとして扱うコントロールプレーンは、1つのプールで容量をアイドル状態のままにしておくのを避け、別のプールが不足するのを防ぎます。

3.10 変更管理

• 3方向バージョンマトリックスを追跡する： モデル、ハードウェア、エンジンビルド。新しいモデルは、初日にナイトリーまたはモデル固有のエンジンビルドを必要とすることがよくあります。

• 排他GPUのロールアウトを計画する。 GPUクレームは排他であるため、1レプリカデプロイメントでのローリングアップデートはデッドロックします：新しいポッドはスケジュールできず、古いポッドは決して離れません。Recreate戦略を使用するか、1つの利用不可を許可し、ダウンタイムを予算化します。

• 準備完了はルーティング可能ではない。 ゲートウェイは、準備完了したレプリカから1〜2分遅れることがあります。

• サービング変更をコードのようにテストする。 各変更をプルリクエストにし、一度に1つのことを変更します。まずバーを書き留めます。ステップがバーを逃すまで負荷を上にスイープし、信頼区間付きの1つの数値として容量を報告します。

• テストリグを最初にテストする。 リグのバグは、数分間のラップトップでの作業で捕捉できたかもしれない希少なGPUウィンドウを無駄にする可能性があります。

• 独自のハードウェアで、独自のトラフィックでテストする。 エージェントプロンプトは長く、ほとんどがキャッシュされています。短く新鮮なプロンプトのベンチマークは、異なるシステムを測定します。

各ティアを通じてサービング変更を昇格させます。各ティアは前のティアよりもコストがかかり、異なる種類の障害を検出するため、ほとんどの問題はユーザーが見る前に現れます。

• オフライン。 設定を検証し、テストリグ固有のチェックを実行します。これはラップトップで数分かかり、GPUは不要です。

• リハーサル。 フェイクゲートウェイまたは小さなモデルに対してエンドツーエンドでフルテストを実行し、リグのバグがGPUウィンドウを消費しないようにします。

• スモークテスト。 対象ハードウェアでいくつかの実際の要求を送信します。長いプロンプト、ツール呼び出し、ストリーミング応答、および拒否されるべき要求を1つ含めます。

• 評価付き負荷テスト。 評価スイートを同時に実行しながら、同時実行性までスイープし、同じトラフィックで現在のバージョンと比較します。評価は一度に1つのリクエストをパスできますが、ツール呼び出しは同時負荷下で壊れ、サービングダッシュボードでは何も動きません。

• カナリアリリース。 新しいバージョンに実際のトラフィックのごく一部を送信し、サーバー側シグナル（TTFT、出力トークンごとの時間、エラー、ツール呼び出し解析失敗、長さ制限停止）を現在のバージョンと比較します。モデル名でルーティングするゲートウェイは、重みでトラフィックを分割できます。開始前にロールバックトリガーを書き留めます。

• フルロールアウト。 新しいバージョンのシグナルがトラフィックのピーク時でもバー内に収まるまで、古いバージョンをトラフィックを受け取れるように準備しておきます。

3.11 品質と評価

オープンモデルのスコアが低い場合は、モデルを非難する前に3つの場所を確認してください。

1. ハーネス。 モデルだけが変更されたか？まず、現在のホストモデルを実行します。弱いモデルよりもスコアが低い場合は、ハーネスが壊れています。

2. インフラストラクチャ。 モデルは回答する機会を得ましたか？タイムアウト、期限切れの認証情報、ルーティングエラーはモデルの失敗として表示されます。それらの実行を「測定せず」とマークします。

3. グレーダー。 チェックはあなたが気にかけている結果を測定していますか？エージェントの説明ではなく、終了状態を評価し、人々がすでに受け入れたり拒否したりした回答に対してグレーダーをテストします。

また、正しい答えが依存するデータをピン留めし、すべてのモデルに同じコンテキストを与えます。モデルが読み取れない場所にテストマーカーを保持します。各テストを複数回実行し、モデルをジャッジとして使用するよりも決定論的なチェックを優先します。バッチサーバーは、温度0でも同じリクエストに対して異なるトークンを返す可能性があるため、エンジンがより遅いバッチ不変モードで実行されない限り、ある程度のばらつきを期待してください。

3.12 インシデントとデバッグ

• サイレント障害を予想する。 コストのかかる問題はエラーを発生させないことが多い：切り詰められたストリームは200を返し、メトリクスAPIは利用可能と報告し、監視は6日間保留状態でした。プラットフォームの仕事の一部は、それらの障害を大声で知らせることです。

• 期間を見る。 丸い秒数での障害はタイムアウトです。その倍数、例えば4回の60秒試行後の239秒は、リトライを示します。

• レイヤーをバイパスする。 パスから1つのホップを取り除き、問題が移動するかどうかを確認します。

• ステータスと現実を照合する。 ステータスは、コンポーネントが自身のジョブをどのように見ているかです。ディスク、インスタンス、またはルート自体を確認します。

• 加算的に作業し、修正をアップストリームする。 コントローラーが所有するオブジェクトを編集するのではなく、ワークアラウンドをプラットフォームの横に、解体用にラベル付けして保持します。

4. スタック

エンジンについて深く学びましょう。Kubernetes、ゲートウェイ、オブザーバビリティはすでに知っているはずなので、推論で何が変わるかを学びましょう。カーネルについては、プロファイルを読めば十分です。ほとんどの推論エンジニアリングは、スタックの上位で行われます。

レイヤー別のツール

エンジンの選択

エンジンは、バッチ処理、メモリ管理、カーネル選択、API互換性を制御します。多くの場合、ハードウェアアップグレードよりもコストとスループットにとって重要です。

Hugging FaceのTGIは一般的な選択肢でしたが、現在はメンテナンスモードです。したがって、コミットする前にリリース頻度、メンテナ、および基盤のサポートを確認してください。エンジンは数週間ごとに新しいフラグを追加します。前四半期の数値を信頼するのではなく、アップグレード時にベンチマークを再実行してください。

Upbound自身のProject Champagne、パート5での比較はこれを実証しています。チームは2つの8GPUノードで約10人のエンジニアにコーディングモデルを提供しており、15人のチームにスケールアップする方法をテストしました。同じハードウェアとエージェントトラフィックで、vLLMからSGLangに切り替えることが、測定された最大の単一の利益でした。SGLangのホストメモリキャッシュをさらに追加しても、KVキャッシュが満杯になることはなかったため、測定可能な利益はありませんでした。

Modelplaneの適合性

ModelplaneはUpboundのオープンソースプロジェクトで、Crossplane上に構築され、Apache 2.0ライセンスでリリースされています。Kubernetesスタイルの宣言型APIを使用して、クラウド、ネオクラウド、および独自のGPU全体でモデル、推論エンジン、AIインフラストラクチャをオーケストレーションします。推論クラスターをプロビジョニングするか、既存のクラスターを使用します。ドキュメントはdocs.modelplane.aiにあります。

Modelplaneは作業を3つの所有レイヤーに分割します。異なるツールを使用する場合でも、同じ分割をメンタルモデルとして使用できます。

階層は、コアKubernetesの1つのスコープ上をミラーリングします。ModelDeployment → ModelReplica → ModelService → ModelEndpointは、Deployment → Pod → Service → Endpointに相当し、1つのクラスター内ではなくフリート全体に及びます。エンジンコンテナとそのフラグを提供し、Modelplaneはそれらの周りのトポロジーを形成します。人間やエージェントはこれらのいずれも作成しません。それらはモデル名でInferenceGatewayを呼び出します。

Modelplaneは、vLLMとSGLangのメトリクスを標準の名前空間にマッピングし、MetricMappingは他のエンジンを追加するため、異なるエンジンは同じシグナルで評価されます。

プラットフォームエンジニアにとって、2番目のレイヤーが新しい学習の場です。Upboundは、Project Champagne、パート1で自己ホストを開始したときにも同じことを発見しました。クラスターとゲートウェイの作業は馴染みがあり、モデルオペレーターレイヤーが未知の領域でした。

スタックを学習するための推奨順序

1. OpenAI互換APIの背後にある1つのGPUでvLLMを実行し、そのメトリクスエンドポイントを読み取ります。

2. NVIDIA GPU Operatorを使用してKubernetesにデプロイし、デバイスセレクタで配置します。

3. TLS、認証、および長いストリーム用にサイズ設定されたタイムアウトを備えたゲートウェイを前面に配置します。

4. PrometheusにエンジンとGPUメトリクスをスクレイプし、セクション3.8からコアパネルを構築します。

5. 同時実行性スイープでベンチマークし、小さな評価スイートを並行して実行します。

6. 同じモデルをSGLangで提供し、独自のトラフィックで比較します。

7. テンソルおよびパイプライン並列処理でより大きなモデルをGPUに分割し、次に分散サービングレイヤーを試します。

8. カーネルまたは設定が違いを生んだ理由を理解するために、十分なCUDAとプロファイリングを学びます。

推論を実行するために知る必要があることの多くは、壊れたものを書き込んだチームから来ています。それらの書き込みを批判的に読み、あなた自身のものを書きましょう（セクション6）。

ケーススタディの読み方

• セットアップを見つける。 モデル、ハードウェア、エンジンバージョン、トラフィック形状。日付をメモしてください。数値はすぐに古くなります。

• バーを見つける。 何が十分と見なされ、誰がそれを決定したか。

• 障害を追う。 何が壊れ、チームがそれをどのように発見し、検出するのにどれくらいの時間がかかったか。

• 方法を確認する。 一度に1つのことを変更し、独自のトラフィックで測定したか？

• 転移可能なものを分離する。 タイムアウトの教訓はどこにでも適用されますが、特定のフラグ値は、そのハードウェア上のそのエンジンリリースにのみ有効です。

ケーススタディ：プロジェクトシャンパン（2026）

CrossplaneとModelplaneの背後にある企業であるUpboundは、AWSとNebius GPU全体でModelplaneを使用して、チャット、コーディングエージェント、CVE修正ビルドエージェントをオープンモデルで自己ホストしました。チームは、5部構成のシリーズで壊れたものを公開しました。2026年時点のハイライトと数値：

• サービングはより小さな問題でした。 vLLMとスケジューリングは機能しました。TLS、ID、タイムアウト、ストレージ、オブザーバビリティに時間がかかりました。（パート2）

• クォータは容量を意味しませんでした。 H100インスタンスの768 vCPUの承認済みクォータは決して1つも生成されず、計画されたGPUは半分程度の時間しか利用できませんでした。1つのモデルは、2つのゾーンの2つのノードに分割されることになりました。（パート2）

• 起動時のフィットだけでは不十分でした。 きれいにフィットしたチャットモデルが、4日間で9回メモリ不足になりました。メモリの割合を0.92から0.88に下げ、拡張可能なセグメントを有効にし、同時シーケンスを16に制限することで、4.6 GiBが解放されました。（パート2）

• 高価な障害はサイレントでした。 切り詰められたストリームは200を返し、メトリクスAPIはデータなしで利用可能と報告し、監視は6日間保留状態でした。（パート2）

• タイムアウトが積み重なりました。 15秒のルートデフォルト、次に60秒のロードバランサーアイドルタイムアウトが、まだストリーミング中だった回答を打ち切りました。（パート2および3）

• エージェントが最も難しいクライアントでした。 1時間のセッションはトークンの60分間の有効期限を過ぎ、推論モデルは最初の表示可能なトークンが表示される前に1分以上考えました。（パート2および3）

• 低いスコアはモデルのせいではないことがよくありました。 テストハーネスの偽のシェルがClaudeに0スコアを付けました。60秒のアイドルタイムアウトは、制限が引き上げられるとすべての実行を完了したモデルを失敗させました。（パート3）

• 遅さにはいくつかの原因がありました。 エンジニアの「うわー、遅いな」は、すべてのダッシュボードが正常に見える間、隠された最大努力の推論に起因していました。1つのGPUは99%のGPU-Utilを示しましたが、テンソルコアの使用率は約10%でした。（パート4）

• 負荷はクライアントに依存しました。 エージェントプロンプトの中央値は59Kトークンで、約3分の2がプレフィックスキャッシュにヒットし、短いプロンプトセッションはサブエージェントを起動することでより多くのリクエストを進行中に保持しました。（パート5）

• エンジンは予想以上に重要でした。 同じ2つの8GPUノードで、vLLMからSGLangへの移行が最大の単一の利益でした。128Kコンテキストキャップは、長い会話を拒否したため、より速く見えただけでした。（パート5）

シリーズ全体を読む

Upboundブログの各投稿は、これらのストーリーを詳細に、設定、クエリ、およびそれらの背後にある数値とともに語っています。

• パート1：インテリジェンスを所有するために必要なこと。 Upboundが推論を自己ホストする理由、およびユースケースがモデルとハードウェアをどのように選択したか。

• パート2：コルクを見つける。 推論ライフサイクルを段階ごとに、選択と配置から変更と障害まで。

• パート3：ユースケース#1、ビルドセキュリティエージェント。 オープンモデルがホストモデルと同じくらい実際のジョブを実行できるかどうかを判断する方法。

• パート4：ボトルのろうそく立て。 チームが各ステップで何を見ることができ、何を見逃し、どのようにアラートを出す計画を立てたか。

• パート5：パイロットからチームへ。 サービング変更をテストし、成長するチームの容量を計画するための再現可能な方法。

6. キャリアチェンジ

最初からやり直す必要はありません。プラットフォームスキルに推論概念を追加し、公開で作業を示しましょう。この分野はまだ新しいため、新規参入者はすぐに追いつくことができます。

方向を選択する

あなたがすでにやっている仕事に最も近い方向を選んでください。ほとんどのプラットフォームエンジニアは最初の2つから始めて、3つ目に向かって成長します。

学習パスをたどる

Vishakha SadhwaniのAI推論エンジニアリングロードマップ2026は、この分野の徹底的な13段階のマップです。プラットフォームエンジニアリングから来ると、インフラストラクチャの半分をすでに所有しているため、より速く進むことができます。より短いパス：

1. コンテナだけでなく、モデルを学ぶ。 Transformerの基本、アテンションとKVキャッシュ、密結合対MoEモデル、およびモデル構成の読み方。目標は、5分で任意のモデルが必要とするメモリを推定することです。

2. 1つのエンジンを深く学ぶ。 vLLMを選択し、コアフラグのそれぞれが何を犠牲にするかを学び、初回トークンまでの時間とトークンあたりのレイテンシを自分で測定します。

3. プラットフォームスキルをGPUに翻訳する。 デバイス割り当て、長いストリームを保持するゲートウェイ、推論シグナルでの自動スケーリング、エンジンのオブザーバビリティ。

4. 品質とコストを判断する方法を学ぶ。 評価を構築し、容量スイープを実行し、トークンあたり百万コストを計算します。これはプラットフォームエンジニアが最もギャップを持つことが多い場所であり、役割が最も価値を追加する場所です。

実績を示すプロジェクトを構築する

以下の各プロジェクトは、1つまたは2つのレンタルGPUに収まり、それぞれが実際の数値を持つリポジトリを生成します。実行間にインスタンスをシャットダウンし、バッチ実験にはスポット容量を使用します。

公開で作業を示す

多くの推論職は、キャリアボードに到達する前にネットワークを通じて埋まります。2026年8月、Zeoliは175億ドルの評価額を持つサービング企業が、専用の推論パフォーマンスの求人をリストしていないことを発見しました。公開作業は、それらのネットワーク外の人々が見つけられる方法です。

• READMEを実験レポートのように書く。 質問、セットアップ（モデル、GPU、エンジンバージョン、フラグ）、方法、結果（数値付き）、驚いたこと、および再現方法を記載します。

• 壊れたものを公開する。 障害の明確な説明は、クリーンなデモよりも多くのスキルを示します。

• バージョンをピン留めし、コストを示す。 エンジンバージョンと価格のない結果は信頼しにくく、再利用しにくいです。

• それについて書き、話す。 各プロジェクトを短い投稿に変換します。ミートアップ、CNCFイベント、コミュニティライブストリームに講演を提出します。

オープンソースに貢献する

推論プロジェクトがまだ必要としていることの多くは、プラットフォーム作業です。Upbound自身のProject Champagneからのアップストリームリストは、プラットフォームのバックログのように見えます：設定可能なロードバランサー、証明書発行、排他デバイスのRecreateロールアウト、正直なReadyシグナル、すぐにスクレイプできるエンジンメトリクス、長寿命エージェントに適した認証。

フォローすべきプロジェクトには、vLLM 、SGLang 、llm-d 、KServe 、NVIDIA Dynamo 、Agent Router （旧Envoy AI Gateway）、Gateway API Inference Extension 、Modelplane 、Crossplane が含まれます。良い最初の貢献：

• 実行し、壊れたものを報告する。 再現と数値とともに。これがChampagneが最も貢献した方法です。

• オペレーターのドキュメントを書く： あなた自身の実行から引き出されたデプロイメント、チューニング、トラブルシューティングガイド。

• メトリクス、ダッシュボード、アラートを追加する サイレント障害を大声で知らせるもの。

• 実際の環境向けの構成、Helmチャート、コンポジションを改善する。

• 持っているハードウェア向けのベンチマークレシピとテストに貢献する。

各プロジェクトの貢献ガイドを読み、小さな変更から始めて、大きな変更を引き受ける前に問題にコメントしてください。

継続的な学習

エンジンは数週間ごとにフラグを追加し、研究は数か月以内に本番環境に到達します。

• 実行しているエンジンのリリースノートを、各リリースごとに読み、アップグレード時にベンチマークを再実行します。

• コア論文を読む： Orca（継続的バッチ処理）、PagedAttention 、DistServe（非集約）、元の投機的デコーディング論文、およびFlashAttention 。

• Philip Kielyの推論エンジニアリングを読む。 eブックはBasetenから無料で入手できます。

• 実践者をフォローする。 The Pragmatic Engineer、ByteByteGo、Data Gravityなどのニュースレターは、この分野をうまくカバーしています。使用しているエンジンのコミュニティチャンネルに参加してください。

• 評価を学ぶ。 オープンモデルがホストモデルを置き換えることができるかどうかは評価によって決まりますが、良い評価を構築できるエンジニアはほとんどいません。AnthropicのAIエージェントのための評価の誤解を解くとHamel HusainおよびShreya Shankarの評価FAQから始めてください。

• 経済学を学ぶ。 トークンあたり百万コストとユーザーセッションあたりコストを財務パートナーに説明できるようにします。

役割を見つける

まだ一貫した役職名を期待しないでください。同じ作業が推論エンジニア、パフォーマンスエンジニア、モデルサービングエンジニア、またはMLインフラストラクチャエンジニアとして、時にはAIプラットフォームエンジニアとしても現れます。そのため、すべてを検索してください。給与はスキルの希少性を反映しています：2026年8月、ZeoliはAnthropicの推論パフォーマンス職が35万ドルから85万ドル、OpenAIの同等の職が29万5千ドルから55万5千ドルで募集されているのを見つけました。

開始するために必ずしも転職する必要はないかもしれません。あなたの会社が最初のモデルを自己ホストする計画を立てているなら、手を挙げてください。あなたのチームはおそらくそのプロジェクトに責任を持つことになるでしょうし、それを実行することがあなたが得られる最も直接的な経験です。

面接の準備

これらに答える練習をしてください。それぞれがこのガイドの該当セクションを指しています。いくつかはLamhot Siagianの効率的な推論に関する面接ポケットノート（セクション7）から適応されています。

• プリフィルとデコード。 なぜデコードは通常計算ではなくメモリ帯域幅によって制限されるのか、そして長いコンテキストで何が変わるのか？（セクション2）

• ハードウェアのトレンド。 計算がメモリ帯域幅よりも速く成長し続ける場合、推論はすぐに計算バウンドになるか？（セクション2）

• メモリ計算。 指定されたコンテキスト長と同時実行性で、モデルとそのKVキャッシュはどれだけのメモリを必要とするか？（セクション2）

• グッドプット。 グッドプットとは何か、そしてなぜ容量計画にそれを使用するのか？（セクション2）

• プレフィックスキャッシュ。 どのアプリケーションがプレフィックスキャッシュから最も恩恵を受けるか？（セクション2）

• 精度。 2つの80GB GPUで70Bモデルをサーブする必要があります。どの精度を選択し、なぜですか？（セクション2および3.4）

• 量子化。 重みのみの量子化はいつ速度を向上させ、いつそうしないのか？（セクション3.4）

• 投機的デコーディング。 投機的デコーディングを使用しないのはいつか？（セクション3.4）

• チャンク化プリフィル。 長いプロンプトは他のユーザーのストリームをどのように遅くし、チャンク化プリフィルは何を変えるか？（セクション3.4）

• 並列処理。 指定されたモデルとGPUタイプに対してどの並列処理戦略を選択するか、そしてテンソル並列処理がパイプライン並列処理よりも優れているのはいつか？（セクション3.4および3.5）

• プロファイリング。 ワークロードが計算またはメモリ帯域幅によって制限されているかどうかをどのように判断するか？（セクション3.8）

• 「遅い」のデバッグ。 p99初回トークンまでの時間が急増しました。キューイング、隠れた推論、遅い生成をどのように区別するか？（セクション3.8）

• コスト。 あなたのGPUで100万トークンあたりのコストはいくらか、そしてそれはホストされたAPIと比較してどうか？（セクション2）

• 容量計画。 ユーザー数は6か月で10倍になります。容量をどのように計画するか？（セクション3.10）

• ロールアウトとSLO。 新しいモデルバージョンを安全にロールアウトするにはどうすればよいか、そしてサービスにどのようなSLOを設定するか？（セクション3.8および3.10）

• 障害の物語。 数値付きの障害について説明してください。何が壊れ、どのように発見したか、そして何を変更したかをカバーします。

7. ソースとさらなる読書

UpboundとModelplane

• Upbound, Drinking Our Own Champagneシリーズ（Upboundブログ）：パート1：インテリジェンスを所有するために必要なこと；パート2：コルクを見つける；パート3：ユースケース#1、ビルドセキュリティエージェント；パート4：ボトルのろうそく立て；パート5：パイロットからチームへ成長するために必要なこと？

• Viktor Farcic, LLM推論解説：実際に知っておくべき12の概念。

• Modelplane on GitHubおよびModelplaneドキュメント。

書籍と記事

• Philip Kiely, 推論エンジニアリング、Baseten Books、2026年。電子書籍として無料。

• Gergely Orosz & Philip Kiely, 推論エンジニアリングとは？深掘り 、The Pragmatic Engineer、2026年3月31日。

• ByteByteGo, AI推論エンジニアリングガイド 、2026年6月15日。

• Chris Zeoli, 推論エンジニアリングの台頭 、Data Gravity、2026年8月13日。

• Spheron, 推論エンジニアリングとは？2026年GPUクラウドガイド 、2026年10月19日更新。

• Vishakha Sadhwani, AI推論エンジニアリングロードマップ2026：完全学習パス 。

• Charity Majors, Liz Fong-Jones, George Miranda, オブザーバビリティエンジニアリング 、O’Reilly。

• Lamhot Siagian, 効率的なLLM推論：面接ポケットノート、第2版、2026年。

評価とベンチマーク

• Anthropic, AIエージェントのための評価の誤解を解く 、2026年1月。

• Hamel Husain and Shreya Shankar, AI評価FAQ 。

• UK AI Security Institute, Inspect 。

• Hugging Face, upskill 。

• SemiAnalysis, AgentX方法論とデータセット 。

論文

• Yu et al., Orca: Transformerベースの生成モデルのための分散サービングシステム 、OSDI 2022。

• Kwon et al., PagedAttentionによる大規模言語モデルサービングのための効率的なメモリ管理 、SOSP 2023。

• Zhong et al., DistServe：Goodput最適化大規模言語モデルサービングのためのプリフィルとデコードの非集約 、OSDI 2024。

• Leviathan et al., 投機的デコーディングによるTransformerからの高速推論 、ICML 2023。

• Dao et al., FlashAttention 、2022年、およびShah et al., FlashAttention-3 、2024年。

• Shoeybi et al., Megatron-LM：モデル並列処理を使用した数十億パラメータ言語モデルのトレーニング 、2019年。

• Shazeer et al., 途方もなく大きなニューラルネットワーク：スパースゲート付きMixture-of-Expertsレイヤー 、2017年。