PCIe bandwidth

概要

PCIe bandwidth（PCIeバンド幅）は、PCI Express規格で接続されたCPUとGPU（あるいはNVMe SSD等）の間のデータ転送速度のことです。単位はGB/s（ギガバイト毎秒）で表され、「PCIe世代」×「レーン数」の組み合わせで理論上の上限が決まります。ローカルLLM運用では、モデル読み込み時間、VRAMに収まりきらない層をCPU/RAM側へ逃がす「オフロード」時の速度、マルチGPU構成でのGPU間通信の3点に直接影響する指標です。

結論から言うと、モデルが完全にVRAM内に収まって推論する一般的なケースでは、PCIe帯域幅が推論速度（tokens/秒）そのものを大きく左右することはほとんどありません。GPUコアはVRAM内のデータを読み書きして計算するため、推論中はPCIeバスをほぼ使わないからです。一方で、モデルの一部をシステムRAMに置く「CPUオフロード」構成や、複数GPUでモデルを分割するテンソル並列構成では話が変わり、PCIe帯域幅がボトルネックとして表面化します。この「効くケースと効かないケースの見極め」がPCIe bandwidthを理解する上で最も重要なポイントです。

適切なPCIe世代とレーン数の選択により、限られた予算の中でもハードウェアの潜在能力を無駄なく引き出すことができます。特に中古GPUや型落ちマザーボードを組み合わせて自宅にLLM推論環境を構築する場合、PCIe周りの理解不足は「GPUは強いのに思ったより速くならない」「マルチGPUにしたのに遅くなった」といった典型的な失敗の原因になります。

仕組み：PCIe世代とレーン数

PCIeの帯域幅は「世代（Gen）」と「レーン数（x1/x4/x8/x16）」という2つの軸の掛け算で決まります。1レーンは送信・受信それぞれ1組の信号線ペアで構成され、GPUスロットは物理的にx16（16レーン）であることが一般的です。マザーボードによっては、スロットは物理的にx16でも、CPU直結のレーンをM.2 SSDやチップセットと共有しているため、電気的にはx8やx4動作に制限される「レーン共有・帯域分割」がある点に注意が必要です。BIOS画面やCPU-Z、GPU-Zで実際の動作レーン数（Current Link Width）を確認する習慣をつけておくと、購入後の「思ったより遅い」を防げます。

PCIe帯域幅（レーンあたり、片方向）

• PCIe 3.0: 約1GB/s per lane（8GT/s、128b/130bエンコード）
• PCIe 4.0: 約2GB/s per lane（16GT/s）
• PCIe 5.0: 約4GB/s per lane（32GT/s）
• PCIe 6.0: 約8GB/s per lane（64GT/s、PAM4変調。対応マザーボード・GPUは2026年時点でも一般消費者向けにはほぼ流通していない）

x16スロット総帯域幅の比較

重要な比較対象として、GPU内部のVRAM帯域幅（GDDR6/GDDR6X/GDDR7がGPUダイと直結する帯域）は、RTX 4090クラスで概ね1000GB/s前後に達します。これはPCIe 4.0 x16（約32GB/s）の30倍以上です。つまりPCIeは「GPUの外」と「GPUの中」をつなぐ細い通路であり、GPUが計算に使うVRAM帯域幅そのものとは桁違いに遅いという事実が、後述の「メリット・デメリット」を理解する前提になります。

ローカルLLMでの影響

モデル読み込み時間

# Llama 2 70B（140GB FP16）の読み込み時間例
PCIe 3.0 x16 (16GB/s): 140GB ÷ 16GB/s = 8.75秒
PCIe 4.0 x16 (32GB/s): 140GB ÷ 32GB/s = 4.38秒
PCIe 5.0 x16 (64GB/s): 140GB ÷ 64GB/s = 2.19秒

# 実際は効率性を考慮（約70-80%）
PCIe 3.0実測: 約12-15秒
PCIe 4.0実測: 約6-8秒
PCIe 5.0実測: 約3-4秒

CPU-GPU間データ転送

• モデル分割時: CPU-GPU間でのレイヤー転送
• メモリオフロード: VRAM不足時のRAM退避
• 動的ロード: 必要な部分のみ読み込み
• 複数モデル切替: モデル間の高速切り替え

VRAM要件とモデルサイズ・量子化の関係

PCIe帯域幅の影響度は、そもそも「モデルがVRAMに収まるか」で決まります。ここで鍵になるのがGGUF形式に代表される量子化（4bit、5bit、8bit等）です。量子化はモデルの重みを16bit/32bitより低いビット幅で表現し直すことで、必要なVRAM容量とPCIe経由の転送量を同時に削減します。目安は以下の通りです（実際のサイズはモデル構造や量子化方式・KVキャッシュ設定で前後します）。

量子化ビット幅を下げるほど、同じモデルの読み込み時間・PCIe転送量が比例して小さくなります。例えば同じ70Bモデルでも、FP16（約140GB）に比べてQ4量子化（約40GB前後）はロード時のPCIe転送量が3分の1以下になり、体感の起動待ち時間も大きく短縮されます。この「量子化はVRAM節約だけでなくPCIe負荷軽減にも効く」という関係は、意外と見落とされがちなポイントです。

推論速度（tokens/秒）の目安とPCIeの関わり方

推論速度は主にGPUの演算性能とVRAM帯域幅で決まり、モデルが完全にVRAM内に収まっていればPCIe帯域幅はほぼ無関係です。一般的な目安として、RTX 4090クラスのGPUで7B〜8Bクラスの4bit量子化モデルを動かした場合は概ね60〜100 tokens/秒程度、13B前後では30〜60 tokens/秒程度が報告される水準です（プロンプト長やバッチサイズ、フレームワークの実装差で大きく変動するため、あくまで目安として捉えてください）。一方、70BクラスのモデルをVRAM容量不足のためCPUオフロードしながら動かす構成では、PCIe帯域幅とシステムRAM帯域幅がボトルネックとなり、1桁台のtokens/秒（数tokens/秒程度）まで落ち込むことが一般に知られています。つまり「PCIeが遅いから推論が遅い」のではなく、「VRAMに収まらずCPU/RAM側にオフロードしているから、PCIe経由のやり取りがボトルネックになる」という因果関係を理解しておくことが重要です。

Ollama・LM Studio・llama.cppでの扱われ方

• llama.cpp: --n-gpu-layers（GPUに載せるレイヤー数）を指定してCPU/GPUの分担を細かく制御可能。GPUオフロード層が多いほどPCIe経由の転送は減るが、VRAM使用量は増える。
• Ollama: 内部でllama.cppベースのランタイムを使用し、VRAM空き容量に応じて自動的にGPU/CPUオフロード比率を調整する。ユーザーが直接PCIe設定を意識する場面は少ないが、挙動の理屈は同じ。
• LM Studio: GUI上で「GPU Offload」スライダーを操作してオフロード層数を調整できる。スライダーを最大にしてVRAMからあふれると、途端にPCIe/RAM経由の低速動作に切り替わるため、VRAM使用量モニターを見ながら調整するのが定石。
• 共通の考え方: いずれのツールでも「モデル全体をVRAMに収める」のが最速構成であり、PCIe帯域幅の選択が効いてくるのはVRAMからあふれた分をどれだけ高速にやり取りできるか、という補助的な役割になる。

GPU別推奨PCIe構成

単一GPU構成

マルチGPU構成

• 2GPU: 各PCIe 4.0 x16（CPUレーン数要確認）
• 4GPU: 各PCIe 4.0 x8以上
• NVLink/SLI: GPU間直接接続併用
• AMD Infinity Cache: GPU間高速通信

メリット・デメリット（注意点）

メリット

• VRAM不足を補う逃げ道になる: 潤沢なPCIe帯域幅があれば、VRAMに収まらない大型モデルでもCPUオフロードで動作させられる（速度は犠牲になるが「動かない」よりはまし）。
• 下位互換性がある: PCIe 5.0対応マザーボードにPCIe 3.0/4.0のGPUを挿しても問題なく動作する。逆にPCIe 3.0マザーボードにPCIe 5.0 GPUを挿しても動作する（帯域幅はマザーボード側の世代に律速される）。
• マルチGPU構成の拡張性を支える: レーン数とスロット数が十分なプラットフォーム（Threadripper、EPYC等）を選べば、複数GPUを並べて大規模モデルを分割実行する構成の土台になる。
• モデル切り替えの体感速度に直結: 複数モデルを頻繁に切り替えて検証するワークフローでは、PCIe世代が新しいほどロード待ちのストレスが減る。

デメリット・注意点

• VRAM不足の根本解決にはならない: PCIe帯域幅はGPU内部のVRAM帯域幅（GDDR6X等で概ね1000GB/s前後）の数十分の一しかない。CPUオフロードは「動く」ようにはなるが、フルVRAM推論と比べて速度は大幅に低下する。PCIe世代を上げても、この構造的な速度差そのものはなくならない。
• レーン数はCPU/チップセット依存で青天井ではない: 一般的なコンシューマ向けCPU（Ryzen、Core iシリーズ等）が提供するPCIeレーン総数には上限があり、GPU2枚挿しでx8/x8に分割されたり、NVMe SSDと帯域を取り合ったりする。潤沢なレーン数が欲しい場合はThreadripperやXeon/EPYC系のプラットフォームが必要になり、コストが跳ね上がる。
• 体感効果が状況依存で分かりにくい: 「モデルがVRAMに収まっている限りPCIe世代を上げても推論速度はほぼ変わらない」という性質上、高価なPCIe 5.0対応マザーボードに買い替えても、用途によっては投資対効果が見えにくい。
• マルチGPUのスケーリング効率に上限がある: NVLinkのような専用GPU間インターコネクトを持たないコンシューマGPU同士をPCIe経由で連携させる場合、GPU台数を増やしても理想通りには性能が伸びず、通信オーバーヘッドが無視できなくなる。

混同されやすい用語・類似技術との違い

プラットフォーム別対応

Intel プラットフォーム

• Z790/B760: PCIe 5.0 x16 + PCIe 4.0 x4
• Z690/B660: PCIe 5.0 x16 + PCIe 3.0 x4
• X299: PCIe 3.0 x16×4（HEDT）
• W790: PCIe 5.0多レーン（ワークステーション）

AMD プラットフォーム

• X670E/B650E: PCIe 5.0 x16 + PCIe 4.0 x16
• X570/B550: PCIe 4.0 x16 + PCIe 4.0 x16
• TRX40: PCIe 4.0 x16×4（Threadripper）
• WRX80: PCIe 4.0多レーン（Pro）

パフォーマンス測定

帯域幅テストツール

# NVIDIA GPU帯域幅測定
nvidia-smi dmon -i 0 -s pcie -c 10

# PyTorchでのPCIe帯域幅測定
import torch
import time

def measure_pcie_bandwidth():
    device = torch.device('cuda')
    size = 1024 * 1024 * 1024  # 1GB
    
    # CPU → GPU転送測定
    cpu_tensor = torch.randn(size // 4, dtype=torch.float32)
    start = time.time()
    gpu_tensor = cpu_tensor.to(device)
    torch.cuda.synchronize()
    upload_time = time.time() - start
    
    # GPU → CPU転送測定
    start = time.time()
    cpu_result = gpu_tensor.to('cpu')
    download_time = time.time() - start
    
    print(f"Upload bandwidth: {size / upload_time / 1e9:.2f} GB/s")
    print(f"Download bandwidth: {size / download_time / 1e9:.2f} GB/s")

measure_pcie_bandwidth()

ボトルネック診断

• GPU-Z: リアルタイムPCIe使用率
• HWiNFO64: 詳細なPCIe統計
• perfmon: Windowsシステム監視
• iotop: LinuxのI/O監視

最適化のポイント

システム設計

• CPUレーン数確認: 総PCIeレーン数の把握
• スロット配置: 最適なGPU配置
• M.2 SSD共有: PCIeレーンの競合回避
• 将来拡張性: アップグレード計画

データ転送最適化

• ピン留めメモリ: より高速な転送
• 非同期転送: 計算と転送の並列化
• バッチ転送: 小さなデータの統合
• データ圧縮: 転送量の削減

実用的な制約と対処

一般的な制約

対処法

• モデル事前読み込み: 起動時間の短縮
• ローカルキャッシュ: 頻繁に使用するモデル
• 量子化モデル: データサイズ削減
• SSD高速化: NVMe SSDでI/O改善

2025-2026年の最新動向

PCIe 5.0の普及が進み、Intel（Z790/Z890系）・AMD（X670E/X870系）の最新プラットフォームでCPU直結スロットへの標準搭載が一般化しています。帯域幅が前世代比で倍増したことで、特に大規模モデル（30B〜70Bクラス）のロード時間短縮という恩恵が体感しやすくなっています。一方で、GPU側がPCIe 5.0にネイティブ対応する消費者向けGeForce/Radeonはまだ限られており、多くのハイエンドGPUはPCIe 4.0 x16動作にとどまっている点には注意してください（スロットが5.0対応でも、GPU側が4.0対応ならリンク速度は4.0基準になります）。

CXL（Compute Express Link）の実用化がサーバー・データセンター領域で先行して進んでおり、メモリプーリングによる大容量メモリ拡張を活かした新しい推論アーキテクチャの研究が進められています。ただし個人のローカルLLM環境にCXLが降りてくるのはまだ先の話で、当面はPCIe 4.0/5.0とVRAM容量・量子化の組み合わせで最適化するのが現実的な選択です。

PCIe 6.0は仕様上x16で約128GB/s（双方向）の帯域幅を持ちますが、対応するコンシューマ向けマザーボードやGPUの普及はまだこれからの段階です。当面の実務判断としては、新規に組む場合はPCIe 4.0以上（できれば5.0）対応プラットフォームを選び、既存のPCIe 3.0/4.0システムは無理に買い替えず、VRAM容量と量子化設定の最適化を優先する、というのが妥当な指針です。

世代選びの推奨戦略

• 既存システムの流用: PCIe 3.0 x16環境でも、単一GPU・VRAM内完結の推論であれば実用上の問題は小さい。買い替えを急ぐ必要はない。
• 新規構築: 現時点で新規に組むなら、CPU直結スロットがPCIe 4.0以上（できれば5.0）のマザーボードを選んでおくと、GPU更新時にも帯域幅がボトルネックになりにくい。
• マルチGPU・大型モデル前提: 70Bクラスを複数GPUで分割する計画があるなら、レーン数に余裕のあるHEDT/ワークステーション系プラットフォーム（Threadripper、Xeon W等）を検討する価値がある。
• 将来の拡張性: PCIe 6.0やCXLはまだ個人利用の主戦場ではないため、「今すぐ対応必須」と焦る必要はなく、量子化とVRAM容量の最適化を優先するのが費用対効果に優れる。

よくある質問（FAQ）

関連用語

外部リンク

• PCI-SIG - PCIe標準化団体（公式仕様情報）
• NVIDIA NVLink 公式ページ
• llama.cpp（GitHubリポジトリ）