Kapazität prüfen, dann zwei modellierte Tempogrenzen vergleichen
Der Rechner verbindet eine Speicherprüfung mit Bandbreiten- und Rechenschätzungen; ihr Schnittpunkt ist eine zu prüfende Modellmarke.
KI-gestützte Lernvisualisierung · schematische Erklärung zum Artikel
Gewichte sind nur ein Teil des Speicherverbrauchs. Nach Gewichten und Runtime-Reserve muss das übrige KV-Budget gespeicherte Tokens über gleichzeitige Anfragen abdecken.
Zwei interaktive Tools zur Planung von LLM-Serving-Hardware. Der Planer schätzt VRAM-Bedarf, Decode-Durchsatz und Time-to-First-Token für eine konkrete Kombination aus Modell, GPU, Präzision und Batch-Größe ein. Die Break-Even-Analyse beantwortet die tiefere Kapazitätsfrage: Ab welcher Batch-Größe ist Decode nicht mehr bandbreitenlimitiert, ab welchem Punkt ist er compute-limitiert, und welche maximale Sequenzlänge ist bei dieser Batch-Größe noch machbar.
Die Durchsatzzahlen sind idealisierte Roofline-Schätzungen, keine gemessenen Serving-Raten. Der Effizienzregler ist eine Annahme; ein allgemeingültiger Bereich von 60–80 % ist nicht belegt. Der Guide zur Inferenz-Mathematik erklärt die Formeln.
1. Der Planer: Kapazität, Durchsatz, Latenz
Interaktiver Rechner
LLM-Inferenz-Planer beta
Die Gesamtzahl der Parameter bestimmt die VRAM-Kapazität; aktiven Parameter bestimmen die Decode-Geschwindigkeit (nur MoE lädt pro Token die gerouteten Experten). MLA- und Hybrid-Attention-Modelle nutzen komprimierte KV-Cache-Berechnung.
Kapazitätsprüfung (Einzelne GPU)
- Modellgewichte (gesamt)
- 65,52 GB
- Aktive Gewichte pro Token
- 65,52 GB
- KV-Cache pro Token
- 0,26 MB
- KV-Cache gesamt (5.120 Tok × 1)
- 1,34 GB
- Aktivierungen
- 0,8 GB
- Runtime-Overhead
- 1,2 GB
- Benötigter VRAM gesamt
- 68,86 GB
- Verfügbarer VRAM
- 96 GB
- Puffer
- 27,14 GB
- Max. Batch @ aktuellem Kontext
- ~21
- Max. Kontext @ Batch 1
- ~108.639 tok
Roofline-Abgleich
- GPU-Ops/Byte (BF16 (2 B))279,02 ops/byte
- Decode-Intensität (Batch 1)1 ops/byte
- Effektive Intensität (Batch 1)1 ops/byte
- Abstand278,02 ops/byte
Speicherlimitiert: eine größere Batch erhöht die effektive Intensität, weil sich mehr Tokens jeden Active-Weight-Lesevorgang teilen.
Latenz-Momentaufnahme
- Decode-Durchsatz
- 20,51 tok/s
- Zeit pro Token
- 48,75 ms
- Durchsatzgrenze
- Speicher
- Zeit bis zum ersten Token (4.096 Tok)
- 762,62 ms
- Gesamtzeit pro Anfrage
- 50,69 s
- Speicherbegrenzte Obergrenze
- 20,51 tok/s
- Rechenbegrenzte Obergrenze
- 5.723,09 tok/s
Decode ≈ min(aggregierte Bandbreite ÷ Bytes pro Schritt, FLOPS(BF16) ÷ 2·aktive Parameter, Sync-Latenz pro Ebene). Sync-Modell: 0 Sync(s)/Ebene × PCIe Gen5 x16 Latenz, skaliert mit der Kernel-Effizienz — TP+EP auf PCIe-Fabrics ist sync-limitiert, nicht bandbreiten-limitiert.TTFT = max(vollständiger Gewichtsstrom, lineare + quadratische Attention-FLOPS).MoE-Kapazität benötigt trotzdem alle 32.762B Parameter im VRAM.
2. Break-Even: Ab wann hilft Batching nicht mehr?
Bei kleinen Batches können Gewichtslesevorgänge den Decode-Schritt begrenzen. Bei dichten Modellen liest das vereinfachte Roofline-Modell die Gewichte einmal pro Batch-Schritt; zusätzliche Anfragen können den aggregierten Durchsatz erhöhen und die Gewichts-Bytes pro generiertem Token senken. KV-Verkehr, Attention, Kernel und Scheduling beeinflussen weiterhin das Tempo je Anfrage. Bei MoE können verschiedene Anfragen dieselben oder unterschiedliche Experten verwenden; die Zahl der unterschiedlichen Gewichte je Schritt hängt vom Routing ab.
Zwei modellierte Grenzen sind relevant:
- Compute-Crossover — bei B* treffen sich die idealisierten Bandbreiten- und Rechenobergrenzen. Der reale Übergang hängt zusätzlich von KV-Lesevorgängen, Attention, Kernel-Effizienz und Kommunikation ab.
- Näherung für MoE-Abdeckung — der Rechner begrenzt die gelesenen Gewichte je Schritt auf die Gesamtmodellgröße:
min(aktive Gewicht-Bytes × Batch, gesamte Gewicht-Bytes). Das setzt unterhalb der Grenze keine Überschneidung und an der Grenze vollständige Abdeckung voraus. Beides ist für geroutete Experten im Allgemeinen falsch; die angezeigte Sättigungs-Batch-Größe ist eine Modellmarke, keine gemessene Schwelle.
B* ist der Schnittpunkt dieser beiden modellierten Grenzen. Für ein dichtes Modell mit Batch-unabhängigen Gewichtslesevorgängen lautet die Formel GPU-FLOPS × Bytes pro Parameter ÷ (2 × Bandbreite), jeweils mit konsistenten effektiven Leistungswerten. B* kann über der durch VRAM möglichen Batch-Größe liegen. Verwenden Sie die Kurve zur Erkundung von Annahmen und messen Sie danach Latenz und Durchsatz bei geplantem Kontext und geplanter Nebenläufigkeit.
Break-even-Analyse
Decode-Break-even-Rechner beta
Diese vereinfachte Roofline schätzt Gewichtslese- und Rechengrenzen bei verschiedenen Batch-Größen. B* ist der Schnittpunkt dieser modellierten Grenzen. MoE-Expertenüberlappung, KV-Verkehr, Attention und Scheduling können den realen Übergang verschieben; messen Sie Ihren Workload. Der Rechner schätzt außerdem die KV-Kapazität bei B*.
Break-even-Betrachtung
B* ≈ 280 braucht mehr KV-Speicher, als dieses Setup bietet (VRAM passt ~53 Sequenzen bei 2.048 Tokens). Der modellierte Compute-Übergang ist bei diesem Kontext unerreichbar. Größere Batches können den Gesamtdurchsatz erhöhen; Tempo und Latenz je Anfrage müssen gemessen werden..
Decode-Durchsatz über Batch-Größe
Aggregierte Tokens/s = min(Bandbreiten-Decke, Compute-Decke). Das MoE-Gewichtslesemodell nimmt unter seiner Gesamtgewichtsgrenze keine Expertenüberschneidung und an der Grenze vollständige Abdeckung an; die reale Kurve hängt vom Routing ab. B* ist der erste Schnittpunkt der modellierten Speicher- und Rechengrenzen. Die VRAM-Linie ist die Kapazitätsgrenze bei einem 2.048-Token-Kontext.
Wie der Break-Even berechnet wird
Beide Rechner teilen dasselbe Decode-Modell:
- Bandbreitenschätzung (aggregierte tok/s) = Batch × effektive Bandbreite × belegte GPU-Kapazität ÷ modellierte Gewicht-Bytes pro Schritt. Für MoE werden diese durch
min(aktiveBytes × Batch, GesamtGewichtBytes)angenähert. - Rechenschätzung (aggregierte tok/s) = effektive FLOPS × GPUs ÷ (2 × aktive Parameter), ohne Attention und andere Operationen.
- B* = erste modellierte Batch-Größe, bei der die Bandbreitenschätzung die Rechenschätzung erreicht. Sie ist weder eine Runtime-Scheduling-Einstellung noch eine verifizierte Grenze für ein reales Modell.
- Maximale Sequenzlänge bei B* = (Gesamt-VRAM − Gewichte − Laufzeit-Overhead) ÷ (KV-Bytes pro Token × B*), begrenzt durch das Kontextfenster des Modells.
Die Analyse schätzt außerdem die maximale Batch-Größe nach KV-Kapazität bei einem Kontext von ~2k Token. Runtime-Belegungen und Aktivierungsspeicher können die reale Grenze senken. Ein größerer Batch kann das Tempo je Anfrage auch unter B* verringern, etwa durch MoE-Routing, KV-Verkehr oder Scheduling-Overhead.
Verwandte Artikel
- LLM-Inferenz-Ökonomie: Kosten & Cloud-Break-Even — was die Break-Even-Kurve in Dollar kostet.
- LLM-VRAM-Bedarf: Ein mathematischer Deep Dive — das Speichermodell hinter der Fit-Spalte.
Einschränkungen
- Keine Continuous-Batching-Ankunftsdynamik: B* ist eine Ceiling im Gleichgewichtszustand, keine Scheduling-Policy.
- Attention-Decode-FLOPs (die mit der Kontextlänge wachsen) sind nicht in der Compute-Obergrenze enthalten; bei sehr langen Kontexten kommt der reale Crossover früher.
- Die Break-even-Kurve verwendet bei mehreren GPUs Tensor-Parallelität und idealisierte Bandbreitenskalierung. Der Planer ergänzt einen heuristischen Kommunikationsaufschlag; beides ersetzt keinen Benchmark auf der tatsächlichen Topologie.