【2026年】vLLM×RTX 4090/5090マルチGPU推論サーバー構築｜tensor parallel

vLLM×RTX 4090/5090マルチGPU推論サーバー構築｜tensor parallel

2026年、ローカルLLM（大規模言語モデル）の活用は、単なる研究者の趣味を超え、企業のプライバシー保護や低遅延なエッジコンピューティングの要へと進化しました。クラウドAPI（OpenAIやAnthropicなど）への依存を減らし、自前でモデルを動かす「ローカル推論サーバー」の需要が爆発的に増加しています。

その中核を担うのが、高効率な推論エンジンである「vLLM」です。vLLMは、PagedAttention技術を用いることで、従来の推論エンジンを圧倒するスループットを実現します。しかし、Llama 4やLlama 3といった巨大なパラメータを持つモデルを、実用的な速度で動かすには、単一のGPUではVRAM（ビデオメモリ）容量が決定的なボトルネックとなります。

本記事では、次世代フラッグシップとなるRTX 5090、あるいは現役最強のRTX 4090を2枚使用し、Tensor Parallelism（テンソル並列化）を駆使して、巨大なモデルを高速に推論させるマルチGPUサーバーの構築手法を徹底解説します。ハードウェアの選定から、量子化技術の使い分け、そしてOpenAI互換APIとしての運用まで、プロフェッショナルな視点で詳細に記述します。

究極の推論基盤：GPU選定とスペック比較

マルチGPUサーバーの成否は、GPUのVRAM容量とメモリ帯域幅によって決まります。LLMの推論において、モデルの重みをメモリに載せきれるかどうかが、動作の可否を分けるからです。2026年現在、コンシューマ向けGPUの選択肢として、RTX 5090とRTX 4090の2種類が検討の遡上に上がります。

RTX 5090は、GDDR7メモリを採用し、メモリ帯域幅が飛躍的に向上しています。一方で、RTX 4090は依然としてコストパフォーマンスに優れ、VRAM 24GBという容量は、量子化モデルを扱う上で非常に強力な武器となります。2枚のGPUを組み合わせることで、合計48GB（4090×2）または64GB（5090×2）のVRAM空間を確保でき、これにより70B（700億パラメータ）クラスのモデルを、4bit量子化状態で余裕を持ってロードすることが可能になります。

以下の表は、主要なGPUスペックの比較です。

RTX 5090を採用する場合、メモリ帯域の向上が推論速度（Tokens per second）に直結するため、大規模なバッチ処理を行うサーバーには最適です。しかし、電源ユニットへの負荷が極めて高く、冷却設計にも高度な知識が求められます。

ハードウェア構成：PCIeレーン数と電源容量の重要性

マルチGPU構成において、最も見落とされがちなのが「PCIeレーンの分割」と「電源の安定性」です。2枚のGPUを搭載する場合、マザーボードが両方のスロットに対して十分なレーン数（x16/x16、あるいは少なくともx8/x8）を提供できるかを確認しなければなりません。PCIeレーンが不足し、x4/x4といった低速な接続になると、GPU間のデータ転送（Tensor Parallelismの通信）がボトルネックとなり、推論速度が大幅に低下します。

また、RTX 5090のようなモンスター級のGPUを2枚運用する場合、システム全体のピーク消費電力は、GPUだけで1000Wを超える可能性があります。これにCPU、SSD、ファン、水冷ポンプの電力を加えると、1500Wクラスの電源ユニットが必須となります。ATX 3.1規格に対応した、高効率な80PLUS PLATINUM以上の電源ユニットを選定してください。

以下に、推奨されるサーバー構成の例をまとめます。

CPUには、コンシューマ向けのRyzen 9やCore i9ではなく、レーン数の多いThreadripperやXeon Wシリーズを推奨します。これにより、GPU間のP2P（Peer-to-Peer）通信がスムーズになり、Tensor Parallelismの効果を最大限に引き出すことができます。

vLLMの核心：Tensor ParallelismとPagedAttention

vLLM（Virtual Large Language Model）がなぜこれほどまでに高速なのか、その理由は「PagedAttention」と「Tensor Parallelism (TP)」にあります。

PagedAttentionは、OSの仮想メモリ管理技術をLLMのKVキャッシュ（Key-Value Cache）に応用したものです。従来の推論エンジンでは、入力テキストが長くなるにつれて、KVキャッシュが断片化され、メモリの無駄遣いが発生していました。PagedAttentionは、キャッシュを固定サイズの「ページ」として管理することで、メモリの断片化を防ぎ、極めて高いバッチサイズでの同時推論を可能にします。

一方、Tensor Parallelism（TP）は、巨大なモデルの重み行列を分割し、複数のGPUに分散して計算させる技術です。vLLMでは、tensor_parallel_sizeというパラメータを指定するだけで、自動的に行列演算を分割して各GPUに割り当てます。

• Tensor Parallelismの仕組み:
  • Attention層の重み行列を、列方向または行方向に分割。
  • 各GPUが部分的な計算を行い、結果をAll-Reduce演算によって集約。
  • これにより、単一GPUでは載らない巨大なモデル（例：Llama-4-70B）の分散ロードが可能に。
• メリット:
  • VRAM容量の拡張（GPU数 × GPU単体のVCR）。
  • 計算リソースの並列化による、単一GPUあたりの負荷軽減。
• デメリット:
  • GPU間の通信オーバーヘッド（PCIe帯域に依存）。
  • 通信遅延が大きすぎると、逆に推論速度が低下するリスク。

量子化戦略：AWQとGPTQの使い分け

LLMの推論において、モデルの精度（Perplexity）と速度を両立させる鍵は「量子化（Quantization）」にあります。量子化とは、モデルの重みを高い精度（FP16やBF16）から、より低いビット数（4bitや8bit）に圧縮する技術です。

2026年現在、主に利用されているのは「AWQ (Activation-aware Weight Quantization)」と「GPTQ (Generalized Post-Training Quantization)」です。

| 量子化手法 | 特徴 | メリット | デメリット | | :--- | :--- | :--- | :配置 | | FP16 / BF16 | 非量子化（オリジナル） | 精度が最高。計算が単純。 | VRAM消費が極めて大きく、巨大モデルには不向き。 | | AWQ (4-bit) | 重要な重みを保護して量子化 | 精度低下が極めて少なく、推論速度が非常に高速。 | 量子化プロセスにやや時間がかかる。 | | GPTQ (4-bit) | 誤差を最小化する事後量子化 | 互換性が高く、多くのモデルが提供されている。 | 非常に複雑なモデルでは、精度劣化が見られる場合がある。 | | GGUF (8-bit) | CPU/GPU混在推論向け | llama.cppなどで利用可能。柔軟性が高い。 | GPU単体でのスループットはvLLMに劣る。 |

推論サーバー構築においては、AWQの使用を強く推奨します。AWQは、重みの量子化プロセスにおいて、アクティベーション（活性化値）の大きさに応じて重要な重みを保護するため、4bitまで圧縮してもモデルの論理的整合性が崩れにくいという特性があります。これにより、RTX 4090/5090の広大な帯域を活かしつつ、驚異的なトークン生成速度を実現できます。

実装手順：vLLM推論サーバーの立ち上げ

ソフトウェア環境は、Ubuntu 24.04 LTS（または最新の26.04 LTS）をベースとしたDocker環境が最も安定しており、管理も容易です。NVIDIA Container Toolkitを導入することで、Dockerコンテナ内からホストのGPUへ直接アクセスすることが可能になります。

以下に、2枚のGPUを用いたTensor Parallel（TP=2）構成での起動コマンド例を示します。

## NVIDIA Docker環境の準備
docker run --gpus all \
    -v ~/.cache/huggingface:/root/.cache/hware \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model meta-llama/Llama-4-70B-Instruct \
    --tensor-parallel-size 2 \
    --quantization awq \
    --dtype half \
    --max-model-len 32768

このコマンドの重要なパラメータは以下の通りです。

1. --gpus all: ホスト上のすべてのGPUをコンテナに割り当てます。
2. --tensor-parallel-size 2: 2枚のGPUにモデルを分割してロードします。
3. html--quantization awq: AWQ形式の量子化モデルを使用することを指定します。
4. --max-model-len 32768: コンテキストウィンドウ（入力可能な最大トークン数）を設定します。この値を大きくすると、VRAM消費量が増大するため、GPUの空き容量に合わせて調整が必要です。

起動後、vLLMはOpenAI互換のAPIエンドポイント（http://localhost:8000/v1）を公開します。これにより、既存のLangChainやLlamaIndex、あるいは自作のPythonスクリプトから、まるでOpenAIのAPIを叩くかのような感覚で、ローカルモデルを利用できるようになります。

パフォーマンス測定：Tokens per Second (TPS) の実測値

構築したサーバーの性能を評価するには、単なる「動作」ではなく、「Tokens per second (TPS)」という指標を用いる必要があります。これは、1秒間にモデルが何個のトークン（単語の断片）を生成できるかを示す数値です。

以下に、RTX 5090×2構成とRTX 4090×2構成における、Llama-4-70B (AWQ 4-bit) の推論性能の推定比較を示します。

RTX 5090のGDDR7によるメモリ帯域の恩恵は、特に大規模なモデル（70B以上）において顕著に現れます。生成速度が20 tokens/secを下回ると、人間が文章を読む速度よりも遅くなり、チャットインターフェースとしての実用性が低下します。一方、40-50 tokens/secを維持できれば、ほぼリアルタイムな対話が可能となり、プロフェッショナルな用途に耐えうる品質となります。

運用上の注意点：熱管理と電力の安定化

マルチGPUサーバーを24時間稼働させる場合、最大の敵は「熱」と「電力の変動」です。

GPUがフルロード状態で動作すると、各カードの温度は80度を超え、サーマルスロットリング（熱による性能低下）が発生します。特に、2枚のGPUを隣接させて配置すると、上のカードが下のカードの排熱を吸い込んでしまい、致命的な温度上昇を招きます。 解決策として、以下の対策を推奨します。

• スロット間隔の確保: 可能であれば、PCIeスロットを1つ空けて配置する。
• ブロワーファンモデルの採用: 側面に排気口があるブロワータイプ（Blower-style）のGPUは、熱をケース外へ直接排出するため、マルチGPU構成に向いています。
• ケース内エアフロー: フロントから強力な吸気を行い、リア・トップから熱を逃がす、高風量のファン構成（Noctua製などが理想）を構築してください。

また、電源ユニットの容量不足は、システムの突然のシャットダウンや、最悪の場合はコンポーネントの物理的破損を招きます。ACコンセントの容量（15A/100Vの制限）にも注意し、ブレーカーを落とさないような運用設計が不可欠です。

よくある質問（FAQ）

Q1: RTX 4090を2枚使う場合、電源は何ワット必要ですか？ A1: 最低でも1200W、推奨は1500W〜1600Wです。GPU単体で最大900Wの消費を見込む必要があり、CPUやその他のパーツを含めると、ピーク時に非常に高い負荷がかかります。

Q2: Tensor Parallelism (TP) を使うと、通信速度が遅くなることはありますか？ A2: はい、あります。GPU間の通信はPCIeバスを経由するため、PCIe 4.0 x8/x8のような低速な接続では、計算速度よりも通信待ち（Latency）が支配的になり、性能が低下します。可能な限りPCIe 5.0 x16/x16の構成を目指してください。

Q3: 4bit量子化を使うと、モデルの賢さが落ちますか？ A3: わずかに低下しますが、AWQなどの高度な量子化手法を用いれば、人間が知覚できるレベルの差はほとんどありません。むしろ、VRAM容量を節約して、より大きなモデル（例：8Bから70Bへ）を動かせるメリットの方が遥かに大きいです。

Q4: Dockerを使わずに、直接U[bun](/glossary/bun-runtime)tuにvLLMをインストールできますか？ A4: 可能ですが、CUDAライブラリや依存関係の管理が非常に困難です。NVIDIA公式のDockerイメージを使用することで、ドライバーやランタイムの不整合を回避でき、環境の再現性も高まります。

Q5: 70Bのモデルを動かすのに、VRAMは最低何GB必要ですか？ A5: 4bit量子化の場合、モデルの重みだけで約35〜40GB、これにKVキャッシュ（コンテキスト用）として追加の数GBが必要です。したがって、最低でも48GB（RTX 4090×2）の環境が推奨されます。

Q6: 複数のユーザーが同時にAPIを使用しても大丈夫ですか？ A6: はい、vLLMのPagedAttention技術により、継続的なバッチ処理（Continuous Batching）が可能です。複数のリクエストを効率的にまとめ、高いスループットを維持しながら同時処理できます。

Q7: 途中でGPUを1枚追加して、TPサイズを増やすことはできますか? A7: 物理的な追加は可能ですが、ソフトウェア（vLLMの実行コマンド）の再起動と、モデルの再ロード、およびPCIeレーンの再配置（スロットの構成変更）が必要になります。

Q8: モデルのロード時間が非常に長いのですが、何か対策はありますか? A8: ストレージの読み込み速度が原因です。Gen5 NVMe SSDなどの高速なストレージを使用し、モデルファイルを配置することで、ロード時間を劇的に短縮できます。

まとめ

本記事では、2026年における最先端のローカルLLM推論サーバー構築について解説しました。重要なポイントを以下にまとめます。

• GPU選定: 圧倒的な帯域を持つRTX 5090、あるいは高コスパなRTX 4090のマルチ[GPU](/glossary/gpu)構成が、巨大モデル推論の鍵となる。
• ハードウェア設計: [PCIe 5.0 x16/x16のレーン分割と、1500Wクラスの信頼性の高い電源ユニットが必須。
• ソフトウェア: vLLMのTensor ParallelismとPagedAttentionを活用し、効率的なメモリ管理と並列計算を実現する。
• 量子化: 精度と速度のバランスに優れたAWQ（4-bit）を採用し、VRAM容量の限界を突破する。
• API運用: OpenAI互換APIとして公開することで、既存のAIエコシステム（[LangChai](/glossary/chai-ai-2021)n等）へ容易に統合可能。

自作LLMサーバーの構築は、ハードウェアの知識とソフトウェアの最適化技術が交差する、非常にエキサイティングな領域です。本ガイドが、あなたのローカルLLM環境構築の助けとなれば幸いです。