LLM推論エンジニアが押さえるべき技術知識：vLLM・SGLang・paged attentionを実務で使うために

AIを「使う」フェーズから「動かす・維持する」フェーズへ移行しようとしている会社員エンジニアにとって、LLM推論の技術知識は避けて通れなくなっています。ChatGPTのAPIを叩くだけなら不要ですが、自社でモデルをホストしてコストや速度を管理しようとした瞬間、知らなければ何もできない概念が山積みになります。この記事では、LLM推論エンジニアが実際に押さえておくべき技術的なポイントを、実務に近い視点で整理します。

なぜ「推論の仕組み」を知らないと詰まるのか

LLMをAPIで使っている間は、レスポンスが遅い理由も、コストが高い理由も、エラーの原因も「APIの問題」として片付けられます。ところが自社でモデルをデプロイした途端、その曖昧さが全部自分に跳ね返ってきます。「なぜこのバッチサイズで詰まるのか」「なぜGPUが80%使われているのにスループットが上がらないのか」という問いに答えられないと、改善策を打てないまま時間だけが過ぎていきます。

推論エンジンは今、vLLMとSGLangが事実上の標準になっています。どちらもオープンソースで、GitHubのスター数はそれぞれ3万を超えており、スタートアップから大手企業まで幅広く使われています。ただ「デプロイできた」と「理解して使っている」の間には大きな差があります。デプロイ自体はDockerコマンド数行で済みますが、その後のパフォーマンスチューニングや障害対応は、内部の動作を知っているかどうかで全く違う結果になります。

ルーフラインモデルとメモリバウンドの話

GPUの性能を語るとき、「計算能力（FLOPS）」と「メモリ帯域幅（GB/s）」の2軸で考えるフレームワークがルーフラインモデルです。LLMの推論、特にデコード（トークンを1つずつ生成するフェーズ）はメモリバウンドになります。つまり、GPUの計算能力が余っていても、メモリからデータを読み出す速度がボトルネックになって全体が遅くなるという状態です。

これを知らずにデコードを高速化しようとすると、計算側を最適化する方向に手を出して時間を無駄にします。メモリバウンドなら、バッチサイズを増やしてメモリ帯域幅を効率的に使うか、モデルの量子化でデータ量を減らすかという方向性が正しくなります。ルーフラインモデルはブログ記事で概念を読むより、自分が使っているGPU（たとえばA100やH100）のスペックシートと照らし合わせて手を動かすと理解が深まります。

paged attentionは「コードで読む」理由

paged attentionはvLLMが導入したメモリ管理の仕組みで、KVキャッシュ（過去のトークン情報を保持するメモリ領域）をページ単位で管理することで、GPUメモリの無駄遣いを減らします。従来の実装ではシーケンスごとに連続したメモリ領域を確保していたため、短いシーケンスが混在するとメモリが断片化してしまっていました。

ブログ記事で「OSのページングと同じ考え方」という説明を読んで「なるほど」と思っても、実際のコードを見ると理解の解像度が変わります。vLLMのGitHubリポジトリ内のcsrc/attention以下にCUDAカーネルのコードがあり、どのようにブロックテーブルを管理しているかが具体的に確認できます。実装を読むと「なぜプレフィックスキャッシュと相性がいいのか」という次の疑問への答えも自然に見えてきます。

プレフィックスキャッシュとは、同じプロンプトの先頭部分（システムプロンプトや定型文）を複数リクエストで使い回す仕組みです。たとえば社内向けのRAGシステムで「あなたは○○部門のアシスタントです。以下の社内規定に基づいて回答してください。（規定文書1000トークン）」という固定のシステムプロンプトを全リクエストで送っている場合、プレフィックスキャッシュをオンにするだけでTTFT（最初のトークンが返ってくるまでの時間）が大幅に短縮されます。これはコードを変えなくてもエンジンの設定1行で有効化できます。

計測しないまま最適化しない

推論エンジンを触り始めると、すぐに「continuous batchingを試してみよう」「chunked prefillを有効にしよう」と設定を変えたくなります。ただ、計測の仕組みを作る前に最適化を始めると、何が効いたのか分からないまま設定が積み重なっていきます。

最低限追うべき指標は4つあります。TTFT（Time To First Token：最初のトークンが返るまでの時間）、インタートークンレイテンシ（トークン間の生成速度）、スループット（単位時間あたりの処理トークン数）、そしてキューの深さ（リクエストが待機している数）です。この4つを見ていると、「TTFTは長いがスループットは高い」という状態はcontinuous batchingが効いてバッチ処理が増えているサイン、「キューが積み上がっている」なら並列処理数を増やすかモデルを軽量化する方向、という判断がつきやすくなります。

GrafanaとPrometheusの組み合わせが現場でよく使われています。vLLMはPrometheusのメトリクスエンドポイントを標準で持っているため、Prometheus側の設定は数行のYAMLで済みます。Grafanaのダッシュボードはコミュニティが公開しているテンプレートをそのまま使えるものが多く、ゼロから作る必要はほぼありません。

以下は、LLM推論の主要な指標と、それぞれが悪化したときに疑うべき原因を整理したものです。

continuous batchingとchunked prefillの使い分け

continuous batchingは、リクエストを固定サイズのバッチにまとめるのではなく、トークン生成のステップごとに空きができたリクエストを動的に追加していく仕組みです。従来の静的バッチングでは、バッチ内の最長シーケンスが終わるまで全員が待つ必要がありましたが、continuous batchingではGPUをほぼ休ませずに使い続けられます。スループットの改善効果は環境によりますが、同時接続数が増えるほど差が出やすい傾向があります。

chunked prefillはプリフィル（入力トークンを一度に処理するフェーズ）を小さなチャンクに分割して処理する仕組みです。長いプロンプトを一度に処理しようとするとデコード中の他のリクエストが待たされるため、それを防ぐ目的で使います。RAGシステムのように検索結果を大量にプロンプトに詰め込む用途では、chunked prefillを有効にするとTTFTのばらつきが小さくなります。

30代の社内SE職の方が「社内ドキュメント検索AIを自社サーバーで動かしたい」というケースを想定すると、プレフィックスキャッシュ（固定のシステムプロンプトが長い場合）とchunked prefill（検索結果を詰め込んだ長いコンテキストを扱う場合）の2つを優先的に試す価値があります。continuous batchingはvLLMではデフォルトで有効になっているため、特別な設定は不要です。

スケジューラのコードを読む意味

vLLMとSGLangはどちらもスケジューラ（どのリクエストをいつ処理するかを決める部分）を持っています。vLLMのスケジューラはFCFS（先着順）をベースにしつつ、メモリの空き状況に応じてプリエンプション（実行中のリクエストを一時停止して別のリクエストを優先する）を行います。SGLangはRadixTreeを使ったプレフィックスキャッシュ管理が特徴で、キャッシュヒット率を最大化するようにスケジューリングされます。

ChatGPTの使い方ガイドでも触れているように、AIツールを「使う」から「理解する」に移行するときの最大の壁は、抽象的な概念説明と実際の動作の間のギャップです。スケジューラのコードを読む目的は全行を理解することではなく、「どういう条件でプリエンプションが起きるのか」「キャッシュがどのタイミングで解放されるのか」という自分の疑問に答えられる箇所を見つけることです。

負荷テストは本番前に必ずやる

単一リクエストで動作確認してから本番に出したら、同時10リクエストで詰まった、という経験をしたエンジニアは少なくありません。負荷テストはlocustやk6のようなツールで、実際のユーザー行動に近いリクエストパターン（プロンプトの長さの分布、同時接続数の想定ピーク）を再現して行います。

プロンプトエンジニアリングの基礎を学んだ後に自社でモデルをホストしようとする場合、負荷テストで確認すべきは「平均レスポンスタイム」だけでなく「P99レイテンシ」（99パーセンタイル、つまり最も遅い1%のリクエストの応答時間）です。平均は良くてもP99が極端に悪い場合、特定の長いプロンプトがボトルネックになっている可能性があり、chunked prefillの適用や入力長の制限が有効な対処になります。

まとめ

LLM推論の技術スタックは、ここ1〜2年で急速に整備されてきました。vLLMやSGLangはデプロイのハードルが下がった一方で、「なんとなく動いている」状態と「理由を理解して動かしている」状態の差は広がっています。計測の仕組みを作り、指標を見ながら一つずつ設定を変えていくという進め方が、結果的に最も速く問題を解決できます。あなたの手元のシステムで、今どの指標が一番怪しいか、そこから始めてみてください。