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
| コントラスト | CPU | GPU |
|---|---|---|
| 建築上の特徴 | 少数の複雑なコンピューティング コア | 大規模並列コンピューティング ユニット |
| 仕事が得意 | 制御フロー、システムスケジューリング、一般的なコンピューティング | 大規模並列計算、行列演算 |
| 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 は次のように近似的に理解できます。
これは Memory-bound を理解するための単純化されたモデルにすぎず、実際のパフォーマンスの正確な公式ではありません。
FLOPS および Memory Bandwidth
| インジケーター | 主な対策 | 共通の関連付け |
|---|---|---|
| FLOPS | GPU 浮動小数点演算能力 | Prefill、大規模行列計算 |
| Memory Bandwidth | GPU データの読み取りおよび書き込み速度 | 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 / Driver | GPU プログラムの実行とデバイス管理 |
| CUDA Kernel | GPUで実行される計算機能 |
| 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
関連概念:
| テクノロジー | 機能 |
|---|---|
| Metal | Apple GPU 低レベルのコンピューティングとグラフィックス API |
| Metal Performance Shaders(MPS) | GPU 最適化計算ライブラリ |
| PyTorch MPS Backend | PyTorch に Apple GPU の使用を許可する |
| MLX | Apple Silicon に最適化された機械学習フレームワーク |
| llama.cpp | Metal を含む複数のコンピューティング バックエンドをサポート |
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の比較
| コントラスト | CUDA | ROCm | Metal |
|---|---|---|---|
| 大手メーカー | NVIDIA | AMD | Apple |
| メインプラットフォーム | NVIDIA GPU | AMD GPUをサポート | Apple GPU |
| GPU プログラミング | CUDA C++ など | HIPなど | Metal Shading Language |
| PyTorch Device | cuda | 通常 cuda API | mps |
| LLM関連の生態 | vLLM、TensorRT-LLM | ROCm互換推論エンジン | MLX、llama.cpp、Ollama |
| 主な利点 | AI ソフトウェア エコシステムは成熟しています | NVIDIA以外のGPU計算解を提供します | Apple Silicon ユニファイド メモリと緊密に統合 |
注: PyTorch ROCm ビルドでは通常、torch.rocm Device を使用するのではなく、torch.cuda API という名前を再利用します。
8. OOM とモデルのメモリ使用量
OOM (Out of Memory) はメモリ不足を示します。
LLM 推論には、モデルの重みだけでなく、より多くのメモリが必要です。
一般的な OOM の原因は次のとおりです。
- モデルの重みが大きすぎます。
- Context Length は長すぎます。
- 同時リクエストが多すぎます。
- KV Cache は成長を続けています。
- 実行時の一時メモリ要件が高すぎます。
一般的な処理方法:
- 精度の低い量子化モデルを使用します。
- Context Lengthを減らします。
- 同時実行の最大数を減らします。
- より効率的な KV Cache 管理または量子化を使用します。
- ビデオメモリ容量の大きいGPUをご使用ください。
一部の推論エンジンは、モデルが利用可能なビデオ メモリを超えた場合に重みを CPU RAM にオフロードできますが、クロスデバイス データ転送により速度が大幅に低下する可能性があります。
概要
LLM 推論ハードウェアは主に 3 つの次元を理解する必要があります。
| 寸法 | 核心的な問題 |
|---|---|
| GPU Compute | GPU は 1 秒あたり何回の計算を完了できますか? |
| Memory Capacity | 型式KV Cacheは取り付け可能ですか? |
| Memory Bandwidth | GPU は 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 のコンピューティング能力、メモリ帯域幅、コンピューティング コア、推論スケジューリング戦略にも影響されます。