Stanford CS25: Serving Transformers - Lessons from the Trenches

Executive Summary

スケールでトランスフォーマーモデルを提供するには、モデルの能力に焦点を当てることから、プロダクション推論の「退屈なインフラ」最適化へ根本的なシフトが必要です。主な課題は、プレフィル（入力処理）フェーズとデコード（トークン生成）フェーズの不均衡にあり、デコードフェーズは通常メモリ帯域幅にボトルネックされ、ハードウェア利用率が低下します。プロダクション推論で成功するには、サービスレベル目標（SLO）によって正確なワークロードを定義し、効率対能力の境界でモデルを選択し、投機的デコードや量子化といった積極的な最適化手法を用いることが重要です。

Defining Inference Workloads and SLOs

効果的な推論エンジニアリングは、ハードウェアとソフトウェアアーキテクチャを決定するワークロードの明確な定義から始まります。ワークロードは主に以下の3つのアーキタイプに分類されます。

• Chatbot Plus: 人間と対話するシステム（例: ChatGPT、Claude）で、主な指標はユーザーあたり秒間出力トークン数というインタラクティブ性です。
• Background Agents: 数秒から数分かけて複雑なタスクを実行するシステム（例: コーディングエージェント）で、主な指標は最終トークンまでの時間です。
• Data Processors: 高ボリュームでバースト的なワークロード（例: 文書インデックス作成）で、主な指標は総スループットで、通常はメガトークン／ドルで測定されます。

Key Performance Metrics

これらのワークロードを管理するために、エンジニアはレプリカごとに以下の指標を追跡し、システムのスケーリング方法を決定します。

• Time to First Token (TTFT): ユーザーが最初の出力バイトを見るまでのレイテンシ。
• Inter-token Latency: 連続トークン間の経過時間。
• Queries Per Second (QPS): リクエスト量で、季節変動や変動が大きいことが多いです。
• Prefix Reuse: 入力トークンの重複頻度で、KVキャッシュを利用して計算コストを削減できます。

Model Selection: Efficiency vs. Capability Bounds

モデル選択は、タスクが効率重視か能力重視かによって決まります。

Efficiency-Bound Workloads

この種のタスクでは、必要な知能レベルは比較的低く、容易に達成できます。コストが主なドライバーとなります。これらのワークロードは通常、オープンソースモデル（例: Mistral、Gemma）で提供され、コストパフォーマンスを最大化するために単一GPUレプリカで実行されます。

Capability-Bound Workloads

最高レベルの知能が求められるタスクで、現在はスケーリングが唯一の解決策です。これらのモデル（例: 最先端のプロプライエタリモデル）は非常に大規模で、レプリカあたり複数GPU、場合によっては複数ノードが必要です。主にマルチエージェントシステムのオーケストレータとして使用され、効率重視のサブエージェントを管理します。

The Inference Stack: Engines and Hardware

Inference Engines

推論エンジンは、トークナイゼーション用サーバープロセス、CPU上のスケジューラ、GPU実行から構成されます。スケジューラの主な役割は GPU がアイドルにならないようにすることです。現在の主要なオープンソースエンジンは以下です。

• vLLM: 幅広く採用され、オープンガバナンスが特徴。
• SGLang: 高性能志向で、積極的な最適化を実装。
• TensorRT-LLM: NVIDIA が提供する C++ コンパイルランタイムで、小規模モデルや小バッチサイズに最適。

Hardware Constraints

プロダクション推論は NVIDIA のデータセンター GPU（SXM フォームファクタ）が支配的です。これは High Bandwidth Memory（HBM）を搭載しているためです。デコードフェーズは極度にメモリ帯域幅に依存しており、Tensor Core がバイトあたり数千の演算を行える一方で、デコードフェーズは数個の演算しか行いません。そのため、HBM と高速インターコネクト（NVLink）が必須で、計算ユニットのアイドルを防ぎます。

Deployment and Robustness at Scale

数千台の GPU を提供する際には、信頼性とコストの課題が顕在化します。

• Hardware Failure: H100 GPU の平均故障間隔は数日から数週間です。ハードウェア障害がシステム障害に直結しないよう、冗長性を持たせる必要があります。
• Cold Start and Scaling: アイドル GPU に無駄なコストをかけずに変動トラフィックに対応するため、レプリカの高速起動が求められます。これはファイルシステムの遅延ロード、マルチティアクラウドキャッシュ、チェックポイント復元技術（例: CRIU）により、数分かかる JIT コンパイルや CUDA グラフキャプチャ時間を回避して実現します。

Performance Optimization Techniques

最適化は階層的に進めます：インパクトの大きいアルゴリズム変更 → ホスト側エンジニアリング → 低レベルカーネル作業 の順です。

Speculative Decoding

投機的デコードはデコードフェーズのメモリ帯域幅ボトルネックを緩和します。小さな「ドラフト」モデルが次の数トークンを予測し、より大きなターゲットモデルが単一のフォワードパスで検証します。これにより、特にアプリケーション固有のドラフトモデルを使用する場合、2〜8 倍の速度向上が期待できます。

Quantization

精度を下げる（例: FP8 から FP4）ことで、メモリ帯域幅が削減され、演算数が増えるため、メモリバウンド・計算バウンドの両シナリオで線形スピードアップが得られます。ただし、長シーケンスでの累積誤差により性能が低下する可能性があるため、"vibe check" と正式評価で慎重に検証する必要があります。

Host-Side Optimization

カスタム CUDA カーネルを書く前に、py-spy などのツールで Python レベルのボトルネックを特定すべきです。例えば、テンソルを再生成する代わりに辞書にポインタをキャッシュするだけでも、マルチモーダル推論で 10% の改善が得られ、GPU 側の変更は不要です。

Observability and Debugging

Observability（可観測性）とは、ログだけでシステムをデバッグできる能力です。重要な実践は以下の通りです。

• Logging Token IDs: 文字列だけのログでは不十分です。トークン ID を記録することで、トークナイザーやチャットテンプレートの微妙なバグをデバッグできます。
• Monitoring Power Draw: GPU の消費電力と温度は「無料」の指標で、ホスト側のボトルネックを示すことがあります（例: GPU が 3kW ではなく 2kW しか消費していない場合、CPU が十分に仕事を供給できていない可能性があります）。
• Evaluating Tails: P95 と P99 のレイテンシは重要です。これらはユーザーが体感する「カクつき」体験を表し、中央値（P50）が低くても無視できません。

Summary

Charles Frye（Modal） は、スケールでトランスフォーマーモデルを提供する際のエンジニアリング課題について語ります。特にプレフィルフェーズとデコードフェーズの重要な違いと、ハードウェア利用率の最適化に焦点を当てています。