導入
Llamaシリーズの登場は、オープンソースの大規模言語モデル（LLM）の歴史において、明確な転換点となりました。特に最新のLlama 3.3（10億から4050億パラメータ、12万8000トークンの長文脈対応）や、複数の専門家モデルを組み合わせるMoE（Mixture of Experts）アーキテクチャを採用し、最大1,000万トークンの超長文脈を処理できるLlama 4のリリースにより、その実用性はかつてない水準に達しています。
OpenAIのGPT-5.2クラスに匹敵する高度な推論性能を、自社の管理下で、しかもデータプライバシーを完全にコントロールできる状態で運用する。これは多くの組織にとっての悲願であり、同時に巨大な技術的挑戦でもあります。さらに、GPT-4oなどの旧モデルが2026年2月13日をもって廃止されるという動向を受け、特定のAPIベンダーに依存しない独自のAI基盤への移行や、用途に応じて日本語処理に優れたQwen3系モデルと使い分けるような柔軟な設計が強く求められるようになっています。
「4050億（405B）パラメータの巨大モデルをダウンロードした。さあ、動かそう」
そう意気込んでシステムへの配置（デプロイ）を試みたエンジニアの多くが、最初に直面するのは圧倒的な「重さ」と、期待を裏切る「遅さ」ではないでしょうか。H100のような高性能GPUを並べた高価なサーバー環境を用意しても、デフォルト設定のままではGPUメモリはすぐに枯渇し（OOM：Out Of Memoryエラー）、文章の生成速度は実用レベルに達しないことが多々あります。
生成AI基盤のシステム設計の現場では、ハードウェアの性能を上げるだけでこのパフォーマンス問題を解決しようとするケースが珍しくありません。しかし、高価なGPUを追加購入する前に、まずはソフトウェアの仕組み、特に推論エンジンの挙動を論理的に理解し、手元の計算資源を極限まで「使い切る」設計ができているかを見直すことが重要です。
本記事では、現在最も有力な推論エンジンの一つであるvLLMを題材に、Llama 3.3やLlama 4といった最新鋭の巨大モデルのポテンシャルを最大限に引き出すための技術的な検証結果と設計思想を分かりやすく解説します。単なる設定ファイルのコピー＆ペーストではなく、「なぜそのパラメータが必要なのか」という内部の仕組みを読み解き、最適な推論基盤を構築するための判断材料として活用してください。
1. 405Bモデル推論における「メモリの壁」と「計算の壁」
まずは、対象となるモデルの特性を正確に把握することから始めましょう。Llamaの最新405Bモデルのような超巨大モデルが、物理的にどのようなリソースを要求するのかを論理的に理解する必要があります。これは感覚的な「重い」ではなく、計算可能な数値としての制約です。
Llamaの最新モデルモデルのパラメータ規模が突きつけるハードウェア要件
モデルのサイズを単純計算してみましょう。4050億（405B）のパラメータを持つこのモデルを、標準的なBF16（16ビット浮動小数点）というデータ形式で読み込む場合、モデルの重みデータだけで以下のGPUメモリ（VRAM）容量を消費します。
[ 405 \times 10^9 \times 2 \text{ Bytes} \approx 810 \text{ GB} ]
これは重みデータのみの数値です。実際の推論時にはこれに加え、過去の計算結果を保持するKVキャッシュ（Key-Value Cache）と、計算途中のデータを一時的に保存するメモリ領域が必要になります。
現在、企業向けで主流となっているNVIDIA H100（80GB版）を用いた場合、8枚構成の単一サーバー（DGX H100等）の合計VRAMは ( 80 \times 8 = 640 \text{ GB} ) となります。
お気づきでしょうか。BF16のフル精度では、H100の8枚構成ですらモデルを読み込むことすらできないのです。 これが405Bクラスのモデル運用の最初のハードルとなります。したがって、必然的に以下のいずれかのアプローチを選択することになります。
- マルチノード分散推論: 2台以上のサーバー（例: 16基のGPU）を高速なネットワークで連結して、必要なVRAM容量を確保する。
- 高度な量子化（Quantization）: モデルのデータ形式をFP8や最新のNVFP4などに圧縮し、1台のサーバーに収める。例えばFP8量子化を用いれば、405Bモデルを約405GB程度まで圧縮でき、8枚構成のH100にKVキャッシュ領域を含めても搭載可能になります。
推論ボトルネックの構造的理解：Memory Bound vs Compute Bound
LLMの推論処理は、その段階（フェーズ）によって処理が滞る原因（ボトルネック）の性質が異なります。
- Prefillフェーズ（プロンプト処理）: 入力された文章（トークン）を一気に並列処理するため、GPUの計算能力そのものが問われる Compute Bound（計算律速） になりやすい領域です。
- Decodeフェーズ（トークン生成）: 1文字（トークン）ずつ順番に生成していくため、計算機は暇を持て余し、メモリから重みデータを転送する速度が限界を決める Memory Bound（メモリ帯域幅律速） に陥ります。
特に405Bのような巨大モデルでは、重みデータのサイズが極めて大きいため、Decodeフェーズでのメモリアクセスにかかるコストが甚大になります。従来の推論サーバーが遅い主な原因は、このMemory Boundな状況で、GPUの計算コア（Tensor Core）を十分に活用しきれていないことにあります。
なぜ従来の推論サーバーではスループットが出ないのか
素朴な実装（Hugging Face Transformersのデフォルト設定など）では、リクエストが来るたびにメモリを確保し、処理が終われば解放するという動きをします。また、複数のリクエストをまとめて処理（バッチ処理）する際も、最も長い文章に合わせて無駄な空白データ（パディング）を入れるため、計算資源の浪費が発生します。
405Bクラスになると、KVキャッシュのサイズも無視できません。最新モデルが対応する12万8000トークンといった長い文章では、KVキャッシュは数十GBから数百GB単位でメモリを圧迫します。メモリが足りなくなれば、一度に処理できる量（バッチサイズ）を小さくせざるを得ず、結果としてスループット（単位時間あたりの処理量）が低下するという悪循環に陥るのです。
ここで、vLLMの論理的かつ効率的なアプローチが活きてきます。
2. vLLMのアーキテクチャ：PagedAttentionとContinuous Batching
vLLMが高いスループットを叩き出せる理由は、魔法ではありません。パソコンのOS（オペレーティングシステム）で使われているメモリ管理技術をGPUメモリに応用した、極めて論理的な仕組みによるものです。
OSのメモリ管理に学ぶPagedAttentionの革新性
従来のLLM推論におけるKVキャッシュの管理は、OSにおける「連続したメモリ領域の割り当て」に似ていました。あらかじめ最大文字数に合わせて巨大な連続メモリを予約してしまうため、実際には短い文章しか生成しなかった場合、予約したメモリの大部分が無駄になってしまいます（内部断片化）。また、メモリが足りなくなると新しいリクエストを受け付けられません。
vLLMの中核技術である PagedAttention は、OSの「ページング方式」にヒントを得ています。KVキャッシュを固定サイズのブロック（ページ）に分割し、物理メモリ上の離れた領域に動的に割り当てます。論理的には連続しているKVキャッシュが、物理メモリ上ではバラバラに配置されていても、PagedAttentionの仕組みが効率的にアクセスして計算を行います。
これにより、メモリの無駄な空き地（フラグメンテーション）がほぼ解消されます。メモリの無駄がなくなるということは、同じVRAM容量でより多くのリクエストを同時に詰め込めることを意味します。同時に処理できる量が増えれば、Memory BoundなDecodeフェーズにおいて、一度のメモリアクセスで処理できるデータ量が増え、GPUの使用効率が劇的に向上します。
Continuous BatchingによるGPUアイドル時間の最小化
もう一つの重要な仕組みが Continuous Batching（継続的バッチング） です。
従来の「静的なバッチング」では、まとめたリクエストのすべての処理が完了するまで、次の処理に進めませんでした。例えば、短い質問と長い論文要約が同じグループに入っていると、短い質問の回答が終わっても、長い処理が終わるまでGPUの一部が待機状態になってしまいます。
Continuous Batchingでは、グループ内の個々のリクエストが完了した瞬間にその枠を解放し、順番待ちをしている新しいリクエストを即座に投入します。これにより、GPUは常に無駄なく稼働し続けることができます。
分散推論エンジンとしてのRayとの統合アーキテクチャ
vLLMは単体でも動作しますが、405Bのような巨大モデルを扱う際は、分散処理の仕組みである Ray と連携して動作します。vLLMはRayを利用して複数のGPUを管理し、KVキャッシュの同期や処理の受け渡しを行います。
ここで重要なのは、vLLMが「メモリ管理の達人」であるということです。システム設計者が設定すべきは、「この達人にどれだけの裁量（メモリリソース）を与えるか」という点に集約されます。
3. スループット最大化のための分散推論設計パターン
Llamaのような巨大なモデルを動かすためには、複数のGPUを効率的に連携させる必要があります。ここでは、処理量を最大化するための分散戦略（Parallelism Strategy）を設計します。
テンソル並列（TP）とパイプライン並列（PP）の最適な組み合わせ
分散推論には主に2つの手法があります。
- Tensor Parallelism (TP: テンソル並列): 1つの層の計算を複数のGPUで分割して行います。計算のたびにGPU間でデータのやり取り（通信）が発生するため、極めて高速な接続（NVLinkなど）が必須です。
- Pipeline Parallelism (PP: パイプライン並列): モデルの層をグループ分けし、異なるGPUに配置します（例：1〜40層はGPU A、41〜80層はGPU B）。通信は層の境界でのみ発生するため、TPに比べて通信頻度は低いですが、処理の待ち時間（バブル）が発生しやすい欠点があります。
vLLMでは、基本的に TP（テンソル並列） を優先して使用します。TPの方が応答速度（レイテンシ）が速く、メモリ効率も良いからです。しかし、TPはGPU間の通信速度に極めて敏感であるため、ハードウェア構成に応じた使い分けが重要になります。
Llama向け推奨トポロジー構成（8xH100 vs 16xA100）
405Bクラスのモデルを実用的な速度で稼働させるための構成例を見てみましょう。最新のLlamaでは、12万8000トークンという長文脈への対応により、KVキャッシュのメモリ要件も考慮する必要があります。
ケースA：H100 (80GB) x 8基（単一ノード） + FP8量子化
これが現在の実証データに基づく「ゴールデンスタンダード」と言える構成です。H100の機能を活用したFP8量子化を用いることで、モデルサイズを約405GB（BF16の半分）まで圧縮できます。これにより、8枚のH100（合計640GB）内にモデルの重みを収めつつ、長い文章を扱うためのKVキャッシュ領域も十分に確保可能です。
- 設定:
tensor_parallel_size=8,pipeline_parallel_size=1 - メリット: すべてのGPUが高速なNVLinkで接続されているため、TPによる通信の遅延が最小限に抑えられ、最高のスループットが期待できます。
ケースB：A100 (80GB) x 16基（2ノード） + BF16フル精度
FP8がハードウェア的にサポートされていないA100環境や、精度の観点でBF16を維持したい場合の構成です。モデルサイズだけで800GB近くを消費するため、1台のサーバー（8基=640GB）には収まりません。したがって、2台のサーバーに跨る構成となります。
- 設定:
tensor_parallel_size=8,pipeline_parallel_size=2 - 戦略: 各サーバー内（8GPU）でTPを行い、サーバー間はPPで接続します。TPをサーバー跨ぎで行うと、ネットワークの通信速度がボトルネックとなり、性能が激減するため避けるべきです。
補足：次世代アーキテクチャへの展望
Blackwellアーキテクチャ（B200等）や最新のRTXシリーズでは、NVFP4などのより圧縮率の高い量子化技術により、さらなるメモリ削減と高速化が期待されていますが、現時点でのvLLMによる安定稼働には上記構成が推奨されます。
インターコネクト帯域（NVLink/Infiniband）の影響度分析
「TP=16」という設定は、すべてのGPUが専用のスイッチ（NVSwitch）で接続されている特殊な環境（DGX GH200等）でない限り、推奨されません。一般的な複数サーバー環境でTPをサーバー跨ぎに設定すると、通信待ちでGPU使用率が10%以下に落ち込むこともあります。
設計の鉄則: TPは同一サーバー（NVLinkで繋がった範囲）内に閉じ込め、サーバー間はPPで接続する。これが、Llamaの性能を最大限に引き出すための基本原則です。
4. パラメータチューニングの理論と検証設計
ハードウェア構成が決まったら、次はいよいよvLLMの設定値（パラメータ）の調整です。デフォルト設定は「安全に動く」ことを優先しているため、性能を限界まで引き出すには論理的な調整が必要です。
gpu_memory_utilization：ギリギリを攻めるための計算式
gpu_memory_utilization は、vLLMがGPUメモリのどれくらいを確保するかを決めるパラメータです（デフォルトは0.9）。残りのメモリは、システムの裏側で動く処理のために残されます。
405Bモデルの場合、モデルの重み自体が巨大なため、この値を慎重に設定する必要があります。
計算アプローチ:
- 固定使用量: モデルの重み + 一時的な作業領域（数百MB〜数GB）。
- 可変使用量: KVキャッシュ（
gpu_memory_utilizationで確保された領域の残り全てがここに割り当てられます）。
もし gpu_memory_utilization を高く設定しすぎると（例: 0.98）、推論実行時にOOM（メモリ不足エラー）でシステムが停止します。逆に低すぎると、KVキャッシュに使える領域が減り、同時に処理できる量が稼げずスループットが低下します。
H100 x 8 (FP8) 環境での実証データに基づく一般的な推奨値は 0.95 前後となります。ただし、他のプログラムがGPUを使っていないことが前提です。
# config.yaml (vLLM設定例)
engine:
model: "meta-llama/Meta-Llama-3.1-405B-Instruct-FP8"
tensor_parallel_size: 8
gpu_memory_utilization: 0.95
max_model_len: 8192 # 必要コンテキスト長に合わせて調整
max_num_batched_tokens：スループットとOOMのトレードオフ境界線
max_num_batched_tokens は、1回の処理サイクルで扱う最大トークン数を指定します。これを増やすとスループット（トークン/秒）は上がりますが、KVキャッシュの消費速度が上がり、最初の文字が出るまでの時間（TTFT: Time To First Token）が悪化する可能性があります。
405Bモデルは計算負荷が高いため、あまり大きくしすぎるとPrefillフェーズでの遅延が顕著になります。デフォルトのままでも機能しますが、応答速度の要件が厳しい場合は、この値を 4096 や 8192 程度に制限することで、安定したレスポンスタイムを得られる場合があります。
max_model_lenとKVキャッシュ容量の相関関係
Llamaは最大12万8000トークンの長文脈に対応していますが、max_model_len を12万8000に設定すると、vLLMはそれに対応するための巨大なKVキャッシュ枠を確保しようとします（実際にはPagedAttentionで動的に確保されますが、内部的な枠の計算に影響します）。
もし実際の用途が社内文書検索（RAG）などで「長くても8000トークンしか使わない」のであれば、max_model_len を 8192 や 16384 に明示的に制限してください。これにより、KVキャッシュの管理が効率化され、実質的な同時接続数を増やすことができます。
5. 実用性とコスト効率：量子化（FP8/AWQ）という選択肢
第1章で触れた通り、Llamaのような巨大モデルを現実的なコストで運用するための切り札が 量子化（Quantization） です。ここでは、特にH100世代や最新のBlackwellアーキテクチャで標準となりつつある FP8（8ビット浮動小数点） について解説します。
Llamaにおける量子化の影響評価
「データを圧縮（量子化）すると、AIの賢さが低下するのではないか？」という懸念は常にあるでしょう。しかし、公式の発表やコミュニティによる検証データの結果、LlamaにおけるFP8量子化の精度劣化は極めて限定的であることが確認されています。
特にMMLUなどの主要な性能テストのスコア低下はわずかで、実務上の対話や論理的な推論においては、人間が知覚できる差はほとんどありません。なお、コスト効率を最優先する場合、70Bパラメータで405B相当の性能を実現するモデルを選択するのも有力ですが、405B特有の幅広い知識や複雑な推論能力が必須のケースでは、FP8量子化による405B運用が依然として強力な選択肢となります。
精度劣化とスループット向上の損益分岐点
FP8を採用するメリットは、単にメモリ容量が半分になるだけではありません。
- メモリ帯域幅の節約: データの転送量が半分になるため、Memory BoundなDecodeフェーズが大幅に高速化します。
- Tensor Coreの活用: H100やB200などの最新GPUに搭載された計算回路は、FP8の計算に最適化されており、理論上の計算性能はBF16と比較して飛躍的に向上します。
vLLMはFP8のKVキャッシュ量子化もサポートしています。これを有効にすると、KVキャッシュのサイズも半分になり、同じVRAM容量で2倍の長さの文章、あるいは2倍の同時処理数を扱えるようになります。
# KVキャッシュのFP8量子化を有効にする起動オプション例
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Meta-Llama-3.1-405B-Instruct-FP8 \
--kv-cache-dtype fp8 \
--tensor-parallel-size 8
本番環境での採用基準チェックリスト
FP8導入の判断基準として、以下のチェックリストを活用することをおすすめします。
- ハードウェア: GPUはH100、L40S、または最新のBlackwell世代か？（A100はFP8非対応のため、AWQ (Int4) などの別方式を検討）
- タスク: 極めて繊細な数値計算や、詩の生成など微細なニュアンスが重要なタスクではないか？（一般的な要約、翻訳、RAG、コード生成ならFP8で問題なし）
- コスト: 1台のサーバー（8GPU）で収めたいか？（405Bを8枚で運用する場合、FP8はほぼ必須）
6. 運用を見据えたモニタリングとオートスケーリング設計
最適な設定でvLLMを起動できても、運用はそこで終わりではありません。負荷状況に応じてシステムを維持・拡張するための仕組みが必要です。特に405Bクラスの巨大モデル運用においては、リソースのわずかな不足が致命的な遅延を招くため、精密な監視が求められます。
vLLMが出力するメトリクスの解読
vLLMはPrometheus形式でシステムの稼働状況（メトリクス）を公開しています（デフォルトでは /metrics エンドポイント）。特に注視すべきは以下の指標です。
vllm:num_requests_running: 現在処理中のリクエスト数。vllm:num_requests_waiting: 順番待ちをしているリクエスト数。これが0より大きい状態が続くなら、リソース不足の明確なサインです。vllm:gpu_cache_usage_perc: KVキャッシュの使用率。これが常に90%を超えている場合、新たなリクエストが来た際にキャッシュが溢れて再計算が発生し、性能が急激に低下する予兆となります。
スループット低下を検知するための監視ダッシュボード構成
Grafana等で監視画面を構築する際は、単にGPU使用率（nvidia-smi的な情報）を見るだけでは不十分です。GPU使用率が100%でも、vLLM内部で処理の詰まりが発生していればユーザー体験は損なわれるからです。
推奨アラート設定:
- Warning（警告）:
vllm:num_requests_waiting > 5が1分間継続。 - Critical（重大）:
vllm:gpu_cache_usage_perc > 95%が継続。
リクエストキュー滞留時のスケーリング戦略
Kubernetes (K8s) 上で運用している場合、自動拡張（オートスケーリング）の引き金として、CPU使用率ではなく、上記のカスタム指標（特に num_requests_waiting）を使用すべきです。
ただし、405Bモデルの起動（モデルの読み込み）には、データサイズに比例して数分単位の時間を要します。「待機列ができてからサーバーを増やす」のでは手遅れになるケースがほとんどです。過去のデータから予測して拡張する仕組み（Predictive Scaling）や、あらかじめ余裕を持たせた設計が、実際の運用では不可欠になります。
また、最新のLlamaでは12万8000といった長大なコンテキスト長がサポートされていますが、文章が長くなればなるほどKVキャッシュの消費量は増大します。最大文字数でのリクエストが集中した場合のメモリ消費を論理的に見積もり、安全な余裕（マージン）を確保しておくことが重要です。
まとめ
Llamaの最新405Bモデルにおける推論スループット最大化は、単なる「設定ファイルいじり」ではなく、ハードウェアの特性とソフトウェアの仕組みの深い理解に基づくエンジニアリングです。
- メモリの壁を論理的に理解し、BF16での高精度運用か、FP8等の量子化による効率化かを戦略的に選択する。
- PagedAttentionの特性を活かすために、適切な最大文字数の制限を設ける。
- 分散推論において、サーバー間の通信遅延を避ける構成を設計する。
- モニタリングを通じて、実証データ（KVキャッシュの使用率など）に基づいた運用を行う。
これらを実践することで、405Bという巨大なモデルを制御し、ビジネスに確かな価値をもたらすAI基盤を構築することが可能です。
さらに、技術トレンドは日々進化しています。最新のGPUアーキテクチャ（Blackwell世代等）ではFP4/FP8量子化による劇的なメモリ削減が期待されるほか、70Bサイズで405Bに匹敵する性能を持つモデルも登場しています。
「405Bをどう動かすか」という問いだけでなく、「解決したい課題に対して最適なモデルサイズと精度のバランスはどこか」という仮説検証の視点を常に持ち続けることが、効率的で持続可能なAIシステム運用の鍵となるでしょう。
コメント