KI-Optimierungsstrategien für Ihre Hardware auswählen
Die Wahl der richtigen Optimierungsstrategie beginnt damit, Ihre Hardware-Architektur auf Ihren primären Leistungsengpass abzustimmen. Jede Plattform setzt strikte physische Grenzen für Rechendurchsatz, Speicherbandbreite und Kapazität.
1. Architektur-Trade-offs der Zielhardware
Verschiedene Hardware-Plattformen lösen das Verschieben und Multiplizieren von Tensoren auf grundlegend unterschiedliche Weise.
| Hardware-Klasse | Speicherarchitektur | Recheneinheiten | Software- und Kernel-Ökosystem | Primäre Stärken und harte Grenzen |
|---|---|---|---|---|
| NVIDIA-Rechenzentrums-GPUs (H100, B200, R100) | Diskrete HBM3e / HBM4 (80 GB–288 GB, 3.35–19.2 TB/s) + schnelles On-Chip-SRAM. | Tensor Cores (FP16, BF16, FP8, NVFP4) + asynchrone TMA-Kopiereinheiten. | CUDA, cuDNN, Triton, TensorRT-LLM, vLLM, NCCL. | Höchste rohe FLOPS und Multi-GPU-Skalierung; teuer und durch PCIe-/NVLink-Grenzen eingeschränkt. |
| NVIDIA-Consumer-GPUs (RTX 4090 / 5090) | Diskrete GDDR6X / GDDR7 (24 GB–32 GB, ~1.0–1.8 TB/s). | Tensor Cores (FP16, FP8, FP4) mit geringeren FP64-/NVLink-Fähigkeiten. | CUDA, PyTorch, Triton, llama.cpp, ExLlamaV2. | Unübertroffenes lokales Preis-Leistungs-Verhältnis; stark eingeschränkt durch die 24–32-GB-VRAM-Grenze und fehlendes NVLink. |
| Apple Silicon (M3/M4 Max & Ultra) | Unified Memory (LPDDR5), gemeinsam von CPU/GPU/NPU genutzt (bis zu 192–512 GB, ~400–800 GB/s). | GPU-Kerne + Simdgroup-Matrix-Einheiten + Apple Neural Engine (ANE). | Metal (MSL), MLX, PyTorch MPS, llama.cpp. | Riesige RAM-Kapazität zum lokalen Laden massiver Modelle; die moderate Speicherbandbreite begrenzt die Prompt-Prefill-Geschwindigkeit. |
| Mobile SoCs (Snapdragon 8 Elite, Apple A18/A19) | Stromsparender gemeinsamer LPDDR5X-RAM (8 GB–16 GB, ~50–85 GB/s). | Mobile GPU (Adreno/Apple) + dedizierte INT4/INT8-NPU (Hexagon/ANE). | Vulkan, Metal, ExecuTorch, LiteRT, MLC-LLM. | Extrem niedrige Leistungsaufnahme (3–8 W); striktes Thermal Throttling und enge 3–6-GB-App-Speicherlimits des OS. |
2. Spezifische Engpässe und Engineering-Ziele lösen
Sobald Sie Ihre Zielhardware identifiziert haben, fällt jeder Leistungsengpass in eine von drei Engineering-Kategorien, von denen jede ein eigenes technisches Playbook erfordert.
Ziel A: Trainingsgeschwindigkeit maximieren (Durchsatz und Skalierung)
Beim Training dominieren das Speichern von Aktivierungen/Gradienten und die kontinuierliche Auslastung der Tensor Cores über mehrere Schritte.
- Python- und Speicher-Overhead beseitigen: Aktivieren Sie torch.compile(mode="max-autotune") und BF16/FP8 Mixed Precision, damit die Tensor Cores mit voller Geschwindigkeit laufen, während der Aktivierungsspeicher halbiert wird.
- Kommunikation mit Berechnung überlappen: Nutzen Sie über mehrere GPUs hinweg PyTorch FSDP2 oder ZeRO-3 mit Gradientenakkumulation, damit All-Gather- und Reduce-Scatter-Transfers asynchron hinter den Matrixmultiplikationen ablaufen.
- Activation Checkpointing: Wenn große Batch-Größen Out-Of-Memory-Fehler (OOM) auslösen, verwerfen Sie Zwischenaktivierungen während des Forward-Pass und berechnen sie während der Backpropagation neu – Sie tauschen ~25% zusätzliche Rechenleistung gegen massiven Spielraum bei der Batch-Größe.
Ziel B: Inferenzlatenz minimieren (TTFT und Tokens/s)
Inferenz teilt sich in Prefill (rechenbegrenzte Prompt-Aufnahme) und Decode (speicherbandbreitenbegrenzte Token-Generierung).
- Time-To-First-Token (TTFT) senken: Verwenden Sie FlashAttention-2/3 und Prefix Caching (Wiederverwendung von KV-Cache-Blöcken für gemeinsame System-Prompts), damit lange Prompts die Tensor Cores ohne redundante Berechnungen sättigen.
- Token-Generierung beschleunigen (TPOT): Quantisieren Sie Gewichte auf FP8 oder INT4 (AWQ/Marlin), um HBM-Lesevorgänge um 2×–4× zu reduzieren, aktivieren Sie CUDA Graphs, um CPU-Kernel-Startlücken zu beseitigen, und fügen Sie Speculative Decoding (EAGLE/Medusa) hinzu, um 3–5 Tokens pro Forward-Pass zu verifizieren.
- Batch-Interferenz beseitigen: Verwenden Sie in Multi-User-Produktionsumgebungen PagedAttention mit Continuous Batching – oder trennen Sie Prefill und Decode auf separate GPU-Pools –, damit schwere Prompts aktive Token-Streams nie blockieren.
Ziel C: Speicherbedarf verringern (Modelle auf begrenzten Geräten unterbringen)
Wenn ein Modell den verfügbaren VRAM oder mobilen RAM übersteigt, werden aggressive Komprimierung und Zero-Copy-Ausführung zwingend erforderlich.
- Sub-Byte-Gewichtskomprimierung: Nutzen Sie 4-Bit-Quantisierung (Q4_K_M oder AWQ), um ein 70B-Modell von 140 GB auf ~40 GB oder ein 8B-Modell von 16 GB auf ~4.9 GB zu verkleinern.
- Den KV-Cache komprimieren: Lange Konversationen verbrauchen oft mehr RAM als die Modellgewichte selbst. Wenden Sie FP8/INT4-KV-Cache-Quantisierung, Sliding Window Attention oder Architekturen mit Multi-Head Latent Attention (MLA) an, um den Kontextspeicher um 50%–90% zu senken.
- Zero-Copy-Streaming (mmap): Mappen Sie auf Unified-Memory-Laptops und -Telefonen quantisierte Modelldateien direkt aus dem NVMe-/UFS-Speicher, damit das OS die Gewichte bei Bedarf einlagert, ohne die RAM-Nutzung beim Start zu verdoppeln.