← AIページの先頭へ

GPU Hardware & Computing Stack

LLM の推論パフォーマンスは、モデル パラメーターの数だけでなく、GPU の計算能力、メモリ容量、メモリ帯域幅、および基礎となるコンピューティング ソフトウェア スタックにも依存します。

中心となる概念:

Hardware
├── CPU
├── GPU
├── RAM / VRAM
├── Unified Memory
├── Memory Bandwidth
└── PCIe / NVLink

GPU Computing Stack
├── CUDA(NVIDIA)
├── ROCm(AMD)
└── Metal(Apple)

1. CPU、GPUとメモリ

CPU および GPU

コントラストCPUGPU
建築上の特徴少数の複雑なコンピューティング コア大規模並列コンピューティング ユニット
仕事が得意制御フロー、システムスケジューリング、一般的なコンピューティング大規模並列計算、行列演算
LLM 推論の責任Tokenization、リクエストのスケジューリング、部分的なデータ処理Attention、MLP、行列演算

RAM および VRAM

  • RAM: 主に CPU とオペレーティング システムによって使用されるシステム メモリ。
  • VRAM: GPU で使用されるビデオ メモリは、通常、高いメモリ帯域幅を持っています。

一般的な独立したグラフィックス カード アーキテクチャ:

CPU ─── System RAM
 │
 │ PCIe / NVLink
 │
GPU ─── VRAM

CPU と GPU 間のデータ伝送には相互接続リンクが必要です。

GPU ローカル メモリ帯域幅は、通常、PCIe 送信帯域幅よりもはるかに高くなります。したがって、推論中にモデルの重みが RAM から VRAM に繰り返し転送されると、パフォーマンスが大幅に低下する可能性があります。

2. GPU Memory Bandwidth

Memory Bandwidth は、GPU メモリ システムが単位時間あたりに送信できるデータ量を表し、通常は GB/s または TB/s で表されます。

これは、LLM Decode のパフォーマンスの重要な指標の 1 つです。

たとえば:

Model Weights
      ↓
Read from VRAM
      ↓
GPU Compute
      ↓
Generate Token

Batch は小さく、主にメモリ帯域幅によって制限されますが、Decode は次のように近似的に理解できます。

Tokens/s≲Effective Memory BandwidthBytes Read per Decode Step\text{Tokens/s} \lesssim \frac{\text{Effective Memory Bandwidth}} {\text{Bytes Read per Decode Step}}

これは Memory-bound を理解するための単純化されたモデルにすぎず、実際のパフォーマンスの正確な公式ではありません。

FLOPS および Memory Bandwidth

インジケーター主な対策共通の関連付け
FLOPSGPU 浮動小数点演算能力Prefill、大規模行列計算
Memory BandwidthGPU データの読み取りおよび書き込み速度Decode、重みおよび KV Cache へのアクセス
VRAM Capacityどれくらいのデータ量を収容できるかモデルサイズ、Batch、Context Length

ビデオ メモリの容量によって、モデルのインストールが簡単かどうかが決まります。ビデオ メモリの帯域幅はモデルの実行速度に影響します。この 2 つを混同することはできません。

3. Unified Memory

Apple SiliconはUnified Memory Architecture(UMA)を採用。

Apple Silicon
├── CPU
├── GPU
├── Neural Engine
└── Unified Memory
       ↑
   Shared Memory Pool

CPU と GPU は同じ物理メモリ プールにアクセスできるため、従来のディスクリート グラフィック カードのように、完全に別個の RAM と VRAM の間ですべてのデータをコピーする必要がなくなります。

利点

  • CPU/GPU間のデータコピーを削減します。
  • より柔軟なメモリ割り当て。
  • GPU がユニファイド メモリの大部分を使用してモデルを実行できるようにします。

限界

  • CPU、GPU、およびその他のシステム コンポーネントは総容量を共有します。
  • GPU 実際に割り当て可能なメモリは、依然としてシステムによって制限されています。
  • メモリ容量が大きいからといって GPU の計算速度が速いわけではありません。
  • 推論エンジンと GPU Kernel のサポート レベルもパフォーマンスに影響します。

たとえば、MacBook の 16 GB Unified Memory は、完全に独立した 16 個の GB があり、そのすべてがモデル VRAM で使用できることを意味するわけではありません。

また、Apple Silicon の Unified Memory と NVIDIA CUDA の Unified Memory を区別する必要があります。2 つの名前は似ていますが、基礎となるハードウェア アーキテクチャとメモリ移行メカニズムは必ずしも同じではありません。

4. CUDA: NVIDIA GPU コンピューティング プラットフォーム

CUDA は、GPU 並列コンピューティング プラットフォームおよび NVIDIA のプログラミング エコシステムです。

NVIDIA GPU
     ↑
CUDA Driver / Runtime
     ↑
CUDA Libraries / Kernels
     ↑
PyTorch / vLLM / TensorRT-LLM
     ↑
LLM Application

CUDA の生態には次のものが含まれます。

コンセプト機能
CUDA Runtime / DriverGPU プログラムの実行とデバイス管理
CUDA KernelGPUで実行される計算機能
CUDA Stream非同期 GPU 操作の実行順序の管理
cuBLAS線形代数と行列演算
cuDNN深層学習コンピューティング ライブラリ
NCCL複数のGPU通信

GPU Kernel

KernelはGPU上で実行される計算プログラムです。

たとえば、Transformer では次のようになります。

  • Matrix Multiplication。
  • Attention。
  • RMSNorm。
  • Softmax。
  • Quantized Matrix Multiplication。

同じモデルと GPU の場合、異なる GPU Kernel を使用すると、推論パフォーマンスが大きく異なる場合があります。

FlashAttention は、Attention の計算とメモリ アクセスを最適化する重要なアルゴリズムおよび Kernel 実装シリーズです。

CUDA Stream

CUDA は、GPU タスクの非同期実行をサポートします。

Stream は、GPU 演算の実行順序を調整し、依存関係とハードウェア条件が満たされた場合に部分的な計算とデータ送信のオーバーラップを実現するために使用されます。

CPU Thread とは異なります。

5. ROCm: AMD GPU コンピューティング プラットフォーム

ROCm は、AMD の GPU コンピューティング ソフトウェア エコシステムです。

AMD GPU
    ↑
ROCm / HIP
    ↑
PyTorch / Supported Inference Engines
    ↑
LLM Application

その中で、HIP は、CUDA プログラミング モデルと同様の GPU プログラミング インターフェイスを提供します。

ROCm エコシステムには、対応するコンピューティング ライブラリ、コンパイル ツール チェーン、および GPU 通信機能が含まれます。

次の点に注意する必要があります。

  • すべての AMD GPU が同じソフトウェア サポートを受けられるわけではありません。
  • PyTorch、vLLM、その他のツールが利用可能かどうかは、特定の GPU モデルとバージョンの互換性を確認する必要があります。
  • CUDA Kernel は通常、適応させないと AMD GPU 上で直接実行できません。

6. Metal: Apple GPU 計算 API

Metal は Apple の基礎となるグラフであり、GPU は API を計算します。

Apple GPU
    ↑
Metal / Metal Performance Shaders
    ↑
MLX / PyTorch MPS / llama.cpp
    ↑
LLM Application

関連概念:

テクノロジー機能
MetalApple GPU 低レベルのコンピューティングとグラフィックス API
Metal Performance Shaders(MPS)GPU 最適化計算ライブラリ
PyTorch MPS BackendPyTorch に Apple GPU の使用を許可する
MLXApple Silicon に最適化された機械学習フレームワーク
llama.cppMetal を含む複数のコンピューティング バックエンドをサポート

PyTorch の例:

import torch

device = "mps" if torch.backends.mps.is_available() else "cpu"

x = torch.randn(1024, 1024, device=device)
y = x @ x

ここで、mps は PyTorch であり、Device は Apple Metal GPU アクセラレーション機能にアクセスするために使用されます。

7. GPU Computing Stackの比較

コントラストCUDAROCmMetal
大手メーカーNVIDIAAMDApple
メインプラットフォームNVIDIA GPUAMD GPUをサポートApple GPU
GPU プログラミングCUDA C++ などHIPなどMetal Shading Language
PyTorch Devicecuda通常 cuda APImps
LLM関連の生態vLLM、TensorRT-LLMROCm互換推論エンジンMLX、llama.cpp、Ollama
主な利点AI ソフトウェア エコシステムは成熟していますNVIDIA以外のGPU計算解を提供しますApple Silicon ユニファイド メモリと緊密に統合

注: PyTorch ROCm ビルドでは通常、torch.rocm Device を使用するのではなく、torch.cuda API という名前を再利用します。

8. OOM とモデルのメモリ使用量

OOM (Out of Memory) はメモリ不足を示します。

LLM 推論には、モデルの重みだけでなく、より多くのメモリが必要です。

Memory Usage≈Weights+KV Cache+Activations+Runtime Overhead\text{Memory Usage} \approx \text{Weights} +\text{KV Cache} +\text{Activations} +\text{Runtime Overhead}

一般的な OOM の原因は次のとおりです。

  • モデルの重みが大きすぎます。
  • Context Length は長すぎます。
  • 同時リクエストが多すぎます。
  • KV Cache は成長を続けています。
  • 実行時の一時メモリ要件が高すぎます。

一般的な処理方法:

  1. 精度の低い量子化モデルを使用します。
  2. Context Lengthを減らします。
  3. 同時実行の最大数を減らします。
  4. より効率的な KV Cache 管理または量子化を使用します。
  5. ビデオメモリ容量の大きいGPUをご使用ください。

一部の推論エンジンは、モデルが利用可能なビデオ メモリを超えた場合に重みを CPU RAM にオフロードできますが、クロスデバイス データ転送により速度が大幅に低下する可能性があります。

概要

LLM 推論ハードウェアは主に 3 つの次元を理解する必要があります。

寸法核心的な問題
GPU ComputeGPU は 1 秒あたり何回の計算を完了できますか?
Memory Capacity型式KV Cacheは取り付け可能ですか?
Memory BandwidthGPU は 1 秒あたりどのくらいのデータを読み取ることができますか?

ソフトウェア層:

LLM Framework / Inference Engine
               ↓
CUDA / ROCm / Metal Backend
               ↓
GPU Kernels
               ↓
GPU Hardware

実際の展開の場合:

  • NVIDIA GPU: CUDA、VRAM、Memory Bandwidth に注目します。
  • AMD GPU: ROCm の互換性に重点を置きます。
  • Apple Silicon: Unified Memory、Metal、MLX、llama.cpp に焦点を当てます。

の核となる結論: LLM が実行できるかどうかは、主にメモリ容量によって制限されます。実行速度は、GPU のコンピューティング能力、メモリ帯域幅、コンピューティング コア、推論スケジューリング戦略にも影響されます。


参考資料