Licensed to be used in conjunction with basebox, only.
// installation
Benchmarks
Gilt für
Produkt: Server · Zielgruppe: Platform Operator
Gemessene Ergebnisse auf Referenzkonfigurationen: Durchsatz, Latenz, Verhalten bei langem Kontext und unter Mischlast. Gelistet werden nur Ergebnisse, die basebox gemessen und dokumentiert hat. Schätzungen – etwa die Parallelitätsrichtwerte der Sizing-Referenz – sind als solche gekennzeichnet.
Gemessen: Referenz-Workload 2 × H200 141 GB
Einzelknoten; eine H200 komplett für die Inferenz, die zweite als 4 × MIG 1g.35gb für GPU-RAG, Dokumentextraktion, OCR und Sprache-zu-Text. Sprachmodell-Verkehr und alle vier Hilfsdienste gleichzeitig auf demselben Server.
| Messung | Ergebnis |
|---|---|
| Dauer kontinuierlicher Mischlast | 60 Minuten |
| Kurze Sprachmodell-Anfragen | 720/720 mit erwartetem Ergebnis |
| Sprachmodell-Anfragen mit langem Kontext | 12/12 mit erwartetem Ergebnis |
| Eingabegröße bei langem Kontext | ca. 258.000 Tokens |
| Kombinierte RAG-, Extraktions-, OCR- und STT-Lastspitzen | 12/12 abgeschlossen |
| Neustarts des Inferenz-Workloads während des Laufs | 0 |
| Dokumentverarbeitung | 120-seitiges PDF in 28,47 s extrahiert und durchsuchbar gemacht |
| Sprache-zu-Text | 60-minütige synthetische Audiodatei in 31,31 s transkribiert |
| Kaltstart-Toleranz der Inferenz | ca. 6 Minuten von Neustart bis Warm-up |
Dokument- und Audiozeiten sind Messungen auf Dienstebene; die tatsächliche Zeit variiert mit Dateiformat, Inhalt, Modellwahl und Konfiguration. Quelle und Topologie: Referenzkonfiguration 2 × H200.
Gemessen: Einzelwerte aus der Sizing-Referenz
| Modell | Hardware | Messung |
|---|---|---|
| Qwen3 4B Instruct FP16 | 1 × 24-GB-GPU | ~23 Tokens/s; praktisch maximaler Kontext ~30k |
| Qwen2.5 72B Instruct Int8 vs. Llama 3.3 70B FP8 | 4 × H100 | Qwen2.5 72B mit schnelleren Antwortzeiten im Test |
Quelle: LLM-Empfehlungen. Ohne dokumentierte Version und Datum – als Orientierung lesen.
Geschätzt (keine Messung): Parallelität nach Kontext
Die Richtwerte für gleichzeitige Nutzer in der Sizing-Referenz sind Schätzungen aus VRAM-Rechnung (Gewichte + KV-Cache bei FP16-Cache), keine Lastmessungen:
| Modell / Hardware | Kontext | Gleichzeitige Nutzer (geschätzt) |
|---|---|---|
| Llama 3.3 70B FP8 / 4 × H100 (320 GB) | 65k | 10–12 |
| 32k | 20–25 | |
| 16k | 40–50 | |
| GPT-OSS 120B MXFP4 TP=4 / 4 × H100 | 128k | 15–20 |
| GPT-OSS 120B AWQ TP=4 / 4 × L40S | 32–64k | 5–8 |
| GPT-OSS 20B MXFP4 / 2 × RTX 4090 | 64k | 2–3 |
KV-Cache-Quantisierung kann die Kapazität etwa verdoppeln. Formel und weitere Tabellen: LLM-Empfehlungen → VRAM-Bedarf.
Methodik
Was basebox als gemessen führt, erfüllt:
- Definierte Konfiguration: Referenzkonfiguration, Modell, Quantisierung, Backend-Version, basebox-Version, Kontext, TP.
- Synthetische Testdaten: keine Kunden-, Patienten- oder Produktionsdaten.
- Mischlast, nicht nur isolierte Inferenz: Chat plus Dokumentaufnahme, OCR und STT gleichzeitig – so zeigt sich, ob Service-Modelle und Inferenz sich stören.
- Stabilitätskriterien: erwartete Ergebnisse je Anfrage, keine Workload-Neustarts, Wiederanlauf nach geplantem Neustart.
- Festgehaltene Metadaten: Betriebsmetadaten und geschwärzte Zusammenfassungen, keine Prompts, Dokumente oder Antworten.
Eigene Messung
Messen Sie auf Ihrer Hardware, bevor Sie Kapazität zusagen:
- Modell und Kontext wie in Produktion konfigurieren; Warm-up-Generierung abwarten.
- Inferenz isoliert: mit einem Lastwerkzeug (z. B. dem Benchmark-Skript Ihrer vLLM-Version) Tokens/s, Time-to-first-Token und Latenz bei 1, 4, 8, 16 gleichzeitigen Anfragen mit realistischer Prompt-Länge messen.
- Mischlast: währenddessen Dokumente in eine Wissensbasis laden, ein OCR- und ein STT-Auftrag – Chat-Latenz darf nicht einbrechen.
- Langer Kontext: eine Anfrage nahe
AISRV_LLM_CONTEXT_SIZE. - GPU-Metriken (DCGM: Auslastung, Speicher), Pod-Neustarts und Fehlerraten festhalten.
- Ergebnis mit Konfiguration an basebox melden – Vorlage unter Andere Modelle nutzen.
Was zu überwachen ist, dauerhaft: Monitoring.
Nächster Schritt: Andere Modelle nutzen