83 lines
4.4 KiB
Markdown
83 lines
4.4 KiB
Markdown
# AIPerf Token-Metriken: Einheit & Interpretation
|
||
|
||
AIPerf exportiert mehrere Metriken die alle "tokens/sec" im Namen tragen, aber unterschiedliche Einheiten haben. Das führt zu Fehlinterpretationen wenn man die falsche Metrik für die falsche Frage verwendet.
|
||
|
||
## Metrik-Übersicht
|
||
|
||
| Metrik (JSON-Key) | Einheit | Bedeutung |
|
||
|-------------------|---------|-----------|
|
||
| `prefill_throughput_per_user` | **tokens/sec/user** | Wie schnell der Prompt **eines Users** verarbeitet wird (Prompt → erstes Token) |
|
||
| `output_token_throughput` | **tokens/sec** | **Gesamter Output-Durchsatz** aller parallelen Sessions zusammen |
|
||
| `output_token_throughput_per_user` | **tokens/sec/user** | Output-Generierungsgeschwindigkeit, **pro einzelnem User** |
|
||
| `e2e_output_token_throughput` | **tokens/sec/user** | End-to-End Throughput: Gesamtzeit (inkl. TTFT) / Output-Tokens, **pro User** |
|
||
| `total_token_throughput` | **tokens/sec** | (Input + Output)-Tokens gesamt, alle Sessions |
|
||
| `request_throughput` | **requests/sec** | Anzahl abgeschlossener Requests pro Sekunde |
|
||
|
||
## Kritische Unterscheidung
|
||
|
||
### „Per User" = Session-Rate
|
||
Diese Metriken beschreiben das Erlebnis **eines einzelnen Endnutzers**:
|
||
|
||
- `prefill_throughput_per_user: 505` → Jeder User bekommt seinen Prompt mit 505 tok/s verarbeitet
|
||
- `output_token_throughput_per_user: 13.4` → Jeder User sieht ~13.4 neue Tokens pro Sekunde (die "Schreibgeschwindigkeit" des Modells)
|
||
- `e2e_output_token_throughput: 11.9` → Inklusive Wartezeit bis zum ersten Token braucht der Request pro Output-Token länger
|
||
|
||
**Wichtig:** Bei `prefill_throughput_per_user` ist der Einheitshinweis irreführend. Es ist keine Durchschnittsbildung über alle Users, sondern tatsächlich die Rate **pro Session**. Bei 100 parallelen Sessions mit je 505 tok/s benötigt der Node also insgesamt **50.500 tok/s Prefill-Kapazität** (was nicht direkt gemessen wird).
|
||
|
||
### „Gesamt" = Node-Rate
|
||
Diese Metriken beschreiben die **gesamte Leistung der Inferenz-Instanz**:
|
||
|
||
- `output_token_throughput: 1083` → Alle 100 Sessions zusammen generieren 1083 Output-Tokens pro Sekunde
|
||
- `total_token_throughput: 5468` → (Input + Output) zusammen → inklusive Prefill-Arbeit
|
||
|
||
## Praktische Berechnungen
|
||
|
||
### Input Token/s (nicht direkt gemessen)
|
||
"Input" oder "Prefill" in Gesamtzahlen ist nicht separat exportiert. Annäherung:
|
||
|
||
```
|
||
input_tokens/sec ≈ total_token_throughput - output_token_throughput
|
||
```
|
||
|
||
Beispiel (gemma @ conc=100):
|
||
- total: 5468 tok/s
|
||
- output: 1083 tok/s
|
||
- → input ≈ 4385 tok/s
|
||
|
||
### Gesamtleistungs-Ranking
|
||
Für Kapazitätsplanung (wie viele Tokens kann der Node pro Sekunde verarbeiten?) verwende `total_token_throughput`:
|
||
|
||
| Modell @ conc=100 | Input t/s | Output t/s | **Total t/s** |
|
||
|-------------------|-----------|------------|---------------|
|
||
| moonshotai-kimi-k2.6 | ~5115 | 1270 | **6385** |
|
||
| gemma-4-31b-it | ~4385 | 1083 | **5468** |
|
||
| qwen3.6-27b-nvfp4 | ~4191 | 992 | **5183** |
|
||
| gpt-oss-120b | ~3300 | 804 | **4104** |
|
||
|
||
### Erlebnis-Ranking
|
||
Für Kundenerfahrung (was spürt ein einzelner User?) verwende die _per_user-Metriken:
|
||
|
||
| Modell @ conc=100 | Prefill/User | Output/User |
|
||
|-------------------|-------------|-------------|
|
||
| moonshotai-kimi-k2.6 | 276 | 17.9 |
|
||
| qwen3.6-27b-nvfp4 | 226 | 15.7 |
|
||
| gemma-4-31b-it | 505 | 13.4 |
|
||
| gpt-oss-120b | 137 | 12.3 |
|
||
|
||
## Fehlerquellen
|
||
|
||
1. **Prefill mit Output vergleichen** – Prefill ist `tok/s/user`, Output-Gesamt ist `tok/s`. Ein Modell mit hohem `prefill_throughput_per_user` und niedrigem `output_token_throughput` ist ein "Prompt-Monster" aber ein "Generation-Schnarcher".
|
||
|
||
2. **Gesamtleistung mit User-Erlebnis verwechseln** – Ein Node mit 10.000 tok/s Gesamtleistung bei 500 concurrent Sessions gibt jedem User nur 20 tok/s. Das ist unbrauchbar für Chat.
|
||
|
||
3. **Input/Prefill vernachlässigen** – Bei RAG-Anwendungen (lange Contexte) dominiert der Prefill die Gesamtlaufzeit. Ein Modell mit 505 tok/s Prefill braucht für 4K Context ~8 Sekunden bis zum ersten Token.
|
||
|
||
## Empfohlene KPIs pro Use-Case
|
||
|
||
| Use Case | Primäre Metrik | Sekundäre Metrik | Warnschwelle |
|
||
|----------|---------------|------------------|-------------|
|
||
| Chat-UI (Echtzeit) | `output_token_throughput_per_user` | `ttft_p99` | < 20 tok/s pro User |
|
||
| API-Burst (Batch) | `output_token_throughput` (gesamt) | `request_throughput` | Steigt nicht mehr mit Conc |
|
||
| RAG / Lang-Context | `prefill_throughput_per_user` | `ttft_p99` | > 10s für 4K Input |
|
||
| Kapazitätsplanung | `total_token_throughput` | `ttft_p99` | Degradation > 2× |
|