Eine schnelle Antwort für eine Person und eine hohe Gesamtzahl abgeschlossener Antworten sind unterschiedliche Ziele. Dieser Test deckt beides ab: eine Anfrage und vier gleichzeitig gesendete Anfragen. Wir vergleichen Qwen 8B, 32B und 72B auf derselben GPU. Für 32B haben wir außerdem einen separaten vierstündigen Lauf abgeschlossen.
Eine API ist die Schnittstelle, über die eine Anwendung eine Frage sendet und eine Antwort erhält. Wir messen lokal auf dem Server, ohne Internetlatenz und zusätzliche Clientanwendung. Alle aktuellen Ergebnisse folgen unserer gemeinsamen CORE-1.1-Methodik.
So lesen Sie die Tabelle
Die erste Zeit zeigt, wann der Messclient das erste generierte Token empfing. Dies ist nicht immer der erste für den Nutzer sichtbare Teil der endgültigen Antwort. Die zweite Zeit bezeichnet den Abschluss der gesamten Antwort. Menschen können gestreamten Text während seiner Entstehung lesen; Software, die ein vollständiges Datenobjekt erwartet, muss bis zum Ende warten.
Wir testen Eingaben mit 2048 und 8192 Tokens, den Textbausteinen eines Modells. Jede Antwort hat eine feste Länge von 256 Tokens. Eine Konfiguration kann also nicht allein dadurch schneller sein, dass sie weniger schreibt. Dies ist ein kontrollierter Rechentest, keine Bewertung der Bedeutung des erzeugten Textes.
Der Gesamtdurchsatz beschreibt die Anfragegruppe als Ganzes. Er ist nicht die Geschwindigkeit, die jeder einzelne Nutzer erlebt. Die Zeiten sind Mediane: die mittleren Beobachtungen nach dem Sortieren der Messwerte.
Eine Anfrage und vier gleichzeitige Anfragen
Die Bezeichnungen 8B, 32B und 72B nennen die ungefähre Anzahl der Modellparameter in Milliarden, nicht die Dateigröße. Q4_K_M ist eine kompaktere Speicherform dieser Parameter. Unser KI- und GPU-Glossar erklärt diese Begriffe mit einfachen Beispielen.
| Modell und Format | Eingabe-Tokens | Gleichzeitige Anfragen | Erstes Token, Median | Median der vollständigen Antwort | Gesamtdurchsatz, Tokens/s |
|---|---|---|---|---|---|
| Qwen3-8B Q4_K_M | 2048 | 1 | 0.2 s | 1.5 s | 171.9 |
| Qwen3-8B Q4_K_M | 8192 | 1 | 0.8 s | 2.4 s | 108.8 |
| Qwen3-8B Q4_K_M | 2048 | 4 | 0.7 s | 3.3 s | 313.0 |
| Qwen3-8B Q4_K_M | 8192 | 4 | 2.5 s | 6.5 s | 155.5 |
| Qwen3-32B Q4_K_M | 2048 | 1 | 0.8 s | 5.5 s | 46.2 |
| Qwen3-32B Q4_K_M | 8192 | 1 | 3.4 s | 8.3 s | 30.8 |
| Qwen3-32B Q4_K_M | 2048 | 4 | 2.8 s | 12.5 s | 81.8 |
| Qwen3-32B Q4_K_M | 8192 | 4 | 10.1 s | 24.5 s | 41.5 |
| Qwen2.5-72B-Instruct Q4_K_M | 2048 | 1 | 1.7 s | 11.6 s | 22.0 |
| Qwen2.5-72B-Instruct Q4_K_M | 8192 | 1 | 7.1 s | 17.5 s | 14.7 |
| Qwen2.5-72B-Instruct Q4_K_M | 2048 | 4 | 6.1 s | 26.2 s | 38.9 |
| Qwen2.5-72B-Instruct Q4_K_M | 8192 | 4 | 21.2 s | 50.9 s | 20.0 |
Jedes Szenario umfasst eine vollständige Aufwärmrunde mit der vorgesehenen Parallelität und fünf Messrunden. Sowohl bei einer als auch bei mehreren Anfragen werden vier Service-Slots reserviert. Wir ändern die Anzahl aktiver Anfragen bei unveränderter Speicherzuweisung. Separate Basismessungen mit einem Slot beantworten eine andere Frage und ersetzen diese Kontrolle nicht.
Das 32B-Modell mit der längeren Eingabe veranschaulicht den Zielkonflikt: Vier gleichzeitige Anfragen steigerten den Gesamtdurchsatz von 30.8 auf 41.5 Tokens/s, ein Zuwachs von 34.9%. Gleichzeitig dauerte eine typische einzelne Antwort 24.5 s statt 8.3 s. Der Server erledigte mehr Arbeit pro Zeiteinheit, aber jede Person wartete länger. Das kann für eine Hintergrundwarteschlange passen; bei Live-Gesprächen zählt die akzeptable Wartezeit stärker.
Was bedeutet das für einen Unternehmensassistenten?
Vier gleichzeitige Anfragen bedeuten kein Limit von vier Benutzerkonten. Mehr Personen können Zugriff haben, ohne genau gleichzeitig eine Frage zu stellen. Für die Planung braucht man die Zahl gleichzeitiger Aufgaben und die Eingabelängen, nicht nur die Mitarbeiterzahl.
Ein sinnvoller nächster Schritt ist, repräsentative Fragen und längere Dokumente vorzubereiten und unter der erwarteten Last zu erproben. Unsere praktischen Aufgaben ergänzen Geschwindigkeitsmessungen um Prüfungen von Ausgabeformat und exakten Antworten.
Dauerbetrieb mit 32B
| Gemessene Dauer | Abgeschlossene Antworten | Gesamtdurchsatz, Tokens/s |
|---|---|---|
| 240.3 min | 2304 | 40.9 |
In 576 Runden schloss der Server 2304 Antworten ab. Der Median der einzelnen Antwort betrug 24.9 s; 95% dauerten ungefähr 25.1 s oder weniger — dieser zweite Wert heißt p95. Das beschreibt die Verteilung in diesem Lauf, keine garantierte Zeit für beliebige Fragen. Der Gesamtdurchsatz von 40.9 Tokens/s gilt für die Gruppe aus vier Anfragen, nicht für jede Person einzeln.
Der Server schloss einen vierstündigen Test zur Anfragebearbeitung ab. Die Temperatur blieb in der gemessenen Konfiguration stabil. Dieses Ergebnis beschreibt diesen Lauf, nicht eine ununterbrochen volle GPU-Auslastung oder identische Geschwindigkeit jeder Antwort.
Die Dauerlast betrifft eine konkrete Konfiguration: Qwen3-32B Q4_K_M, die längere Eingabe und vier gleichzeitige Anfragen. Ihr Ergebnis wird nicht auf jedes Modell der Tabelle übertragen. Die Messzeit beginnt mit der ersten gemessenen Anfrage und endet mit der letzten abgeschlossenen Antwort, ohne Laden und Aufwärmen.
Gemessen wird die wiederholte Anfragebearbeitung, keine garantiert ununterbrochene volle GPU-Auslastung in jeder Sekunde. Unser Artikel zu Leistung und Energie untersucht ebenfalls die längere Lastphase.
Eine Konfiguration auswählen
Beginnen Sie mit akzeptabler Wartezeit, Eingabelänge und erwarteten gleichzeitigen Anfragen. Bewerten Sie anschließend die Modellantworten anhand Ihrer eigenen Daten. Zusammen zeigen diese Beobachtungen, ob die Konfiguration zur Anwendung passt.
Für einen ersten Prototyp führt der Ratgeber zur privaten API durch eine geschützte erste Bereitstellung. Serverangebot ansehen oder Ihre Anwendung beschreiben.
Technische Details
Vergleichbarkeit der Messungen
Die kurze CORE-1.1-Matrix umfasst Qwen3-8B Q4_K_M, Qwen3-32B Q4_K_M und Qwen2.5-72B-Instruct Q4_K_M. Zwei Eingabelängen × zwei Parallelitätsstufen × drei Modelle ergeben 12 Szenarien. Jedes hat eine vollständige Aufwärmrunde und fünf Messrunden; eine Runde mit vier Anfragen enthält vier Antworten.
Sowohl C1 als auch C4 reservieren vier Slots mit je 8704 Tokens, insgesamt 34816. Alle weiteren Einstellungen bleiben identisch: sämtliche Schichten auf GPU, F16-KV, Flash Attention, 16 Threads, Batch 2048, Ubatch 512 und mmap; Lazy Loading, automatische Anpassung, Prompt-Caching und Kontextverschiebung sind deaktiviert. Die Umgebung besteht aus Rocky Linux 10.2, NVIDIA 595.91.07 und llama.cpp b11146.
Berechnung von Zeiten und Durchsatz
Gleichzeitige Anfragen starten über eine gemeinsame Synchronisationsbarriere; wir bestätigen ein gemeinsames aktives Intervall aller Antworten. Die Anfragezeit endet mit dem abschließenden Generierungsereignis, nicht mit dem späteren Schließen der HTTP-Verbindung. Ein synthetisches erstes Token ist nicht dasselbe wie der erste sichtbare endgültige Antworttext eines Reasoning-Modells.
Der Gesamtdurchsatz ist die Anzahl generierter Tokens geteilt durch die Vereinigung der Antwortfenster. Überlappende Zeit wird nicht mehrfach gezählt. Das ist weder der historische Mittelwert der Rundenraten noch eine individuelle Decode-Rate. Bei 256 Ausgabe-Tokens kann die interne Engine-Zeitmessung 255 Decode-Schritte umfassen; die Daten bewahren beide Bedeutungen.
Fünf Runden erlauben keine belastbaren Aussagen über seltene Verzögerungen. Im gleichartigen Dauerszenario wird ein beschreibendes p95 erst ab 200 Antworten ausgewiesen. Es beschreibt die beobachtete Verteilung unter diesen Bedingungen, kein SLA.
Dauermessung und Quellen
Plan, Ausführungsprogramm, Analyseprogramm und Kriterien zur Kühlungsbewertung werden vor der Dauerkampagne festgelegt. Wir verlangen mindestens vier Stunden von der ersten gemessenen Anfrage bis zur letzten abgeschlossenen Antwort und erhalten dabei Pausen und Telemetrie. Numerische Ergebnisse stehen im CORE-JSON; thermische Bewertung und stündliche Leistung stehen in der Dauerlaufanalyse.
Alle älteren Dateien bleiben im Archiv unverändert. Der historische 8B-API-Test mit 32,768 Eingabe-Tokens gehört nicht zur neuen 2048/8192-Matrix. Die separate neue Messung mit 32,768 Tokens betrifft die 72B-Rechenengine, nicht diese HTTP-Schicht.
Die Anhänge enthalten Laufzeit- und Modellversionen sowie ungerundete Statistiken. Das Endpunktverhalten ist in der festgelegten llama-server-Referenz dokumentiert.