Kann ein großes Sprachmodell auf einer einzelnen GPU laufen? Wir untersuchen Qwen2.5-72B im Format Q4_K_M auf einer NVIDIA RTX PRO 6000 Blackwell Max-Q. Dieser Artikel misst die Rechenengine selbst. Wartezeiten für Nutzer und gleichzeitige Anfragen messen wir separat in unserem API-Benchmark.
„72B“ bezeichnet ungefähr 72 Milliarden Modellparameter, nicht die Größe in Gigabyte. Q4_K_M ist eine kompaktere Speicherform dieser Parameter. Modell und Format bleiben in allen folgenden Szenarien gleich. Wir verändern die von der Engine verarbeitete Eingabemenge nach unserer gemeinsamen CORE-1.1-Methodik.
Zwei Phasen, die getrennt betrachtet werden sollten
Vor der Antwort verarbeitet ein Modell seine Eingabe: Anweisungen, die Frage und begleitendes Material. Diese Phase heißt Prefill. Anschließend erzeugt es die aufeinanderfolgenden Teile der Antwort — Decode. Für den Nutzer ist dies ein Ablauf, doch die beiden Phasen haben unterschiedliche Verarbeitungsgeschwindigkeiten.
Ein Token ist ein Textbaustein: ein Wort, ein Wortteil oder ein Zeichen. Tokens pro Sekunde bedeuten daher nicht Wörter pro Sekunde. Wir rechnen Eingabelängen auch nicht pauschal in feste Seitenzahlen um; diese hängen von Sprache und Inhalt des Dokuments ab.
Ergebnisse für drei Eingabelängen
| Eingabe-/Kontext-Tokens | Prefill, Mittelwert Tokens/s | Decode, Mittelwert Tokens/s |
|---|---|---|
| 2048 | 1236.6 | 25.9 |
| 8192 | 1173.0 | 25.6 |
| 32768 | 964.0 | 22.5 |
Die Tabelle zeigt mittlere Raten aus fünf Wiederholungen nach dem Aufwärmen. Dies ist eine synthetische Rechenmessung, kein Test des Dokumentverständnisses. Eingabeverarbeitung und Generierung werden in getrennten Läufen des Benchmark-Werkzeugs gemessen, nicht mit zwei Zeitmessern im selben Gespräch. Die herunterladbaren Daten enthalten außerdem exakte Werte, Minimum, Maximum und Median.
Die Erhöhung von 2048 auf 8192 Eingabe-Tokens änderte die Generierungsrate kaum: von 25.9 auf 25.6 Tokens/s. Bei 32,768 Tokens erreichte die Generierung 22.5 Tokens/s, während die Eingabeverarbeitung auf 964.0 Tokens/s sank. Die Konfiguration bewältigte damit auch den längsten getesteten Kontext auf einer einzelnen GPU, allerdings mit geringeren Verarbeitungsraten.
Was bedeutet das für die Arbeit mit Dokumenten?
Bei einer kurzen Frage kann die Eingabeverarbeitung nur einen kleinen Teil der Aufgabe ausmachen. Ein umfangreiches Dokument erfordert mehr Berechnung, bevor die Antwort beginnt. Selbst wenn nur wenige Sätze als Antwort gewünscht sind, muss das Modell zuerst den bereitgestellten Text verarbeiten.
Ein Praxisbeispiel ist ein Dokumentationsassistent: Eine Anwendung wählt relevante Passagen aus und sendet sie zusammen mit einer Frage an das Modell. Entwürfe von Zusammenfassungen sind ein weiterer möglicher Einsatz. Dies sind Anwendungsideen, die Sie anhand eigener Dokumente prüfen sollten, keine in diesem Engine-Benchmark bewerteten Aufgaben.
Es ist nicht immer nötig, alles auf einmal zu senden. Die Auswahl relevanter Passagen kann Zeit und Speicher sparen, sofern keine für die Antwort notwendigen Informationen verloren gehen. Verfügbarer Kontext ist eine Möglichkeit, keine Pflicht, das gesamte Limit bei jeder Frage auszuschöpfen.
Warum Geschwindigkeit allein nicht das beste Modell bestimmt
Wir bewerten Antworten anhand von praktischen Aufgaben, die gemeinsam mit Messungen zur Speicherkapazität vorgestellt werden. Dabei unterscheiden wir das verlangte Ausgabeformat von der exakten Übereinstimmung mit vorab festgelegten Antwortwerten.
Auch der Ablauf der Anwendung zählt. Für eine einzelne Person kann eine schnelle Antwort Priorität haben; eine Dokumentenwarteschlange profitiert davon, insgesamt mehr Aufgaben abzuschließen. Ein Mikrobenchmark umfasst weder Warteschlangen noch Authentifizierung, Dokumentensuche oder die Internetverbindung.
Berücksichtigen Sie vor dem produktiven Einsatz neben Geschwindigkeit auch Antwortqualität, API-Messungen und Speicheranforderungen. Serverangebot ansehen oder das gewünschte Modell und die Aufgabe beschreiben.
Technische Details
Was genau verglichen wird
Die CORE-1.1-Reihe verwendet Qwen2.5-72B-Instruct Q4_K_M, llama.cpp b11146 mit Commit 7fe450e19305b828c199d602c23a8337aaa1f03b, NVIDIA-Treiber 595.91.07 und Rocky Linux 10.2. Modell- und Laufzeitdateien sind durch feste SHA-256-Prüfsummen festgelegt. Dies ist ein konkret getesteter Build, keine Behauptung, die neueste stabile Version zu verwenden.
Für jede Eingabelänge — 2048, 8192 und 32,768 Tokens — gibt es eine separate Prefill-Messung und einen Generierungstest mit 256 Tokens bei der angegebenen Kontexttiefe. Jeder llama-bench-Prozess führt seinen integrierten Aufwärmlauf und fünf Messungen durch. Einstellungen: alle Schichten auf der GPU, Flash Attention, F16-KV, 16 Threads, Batch 2048, Ubatch 512, ausdrücklich mmap und lazy-mode off. Zwischen den Prozessen erfolgt eine kontrollierte Abkühlung; sie ist nicht in den internen Zeitmessungen der Engine enthalten.
Engine-Messungen verwenden weder einen HTTP-Server noch API-Slots. Wir schreiben ihnen keine praktische Latenz bis zur ersten sichtbaren Antwort zu. Ressourcenbeobachtungen umfassen den gesamten Prozess einschließlich Laden und Aufwärmen: Das Werkzeug stellt keine absoluten Start-/Endzeitpunkte für jede interne Messung bereit. Wir stellen diese Beobachtungen nicht als exakt isolierten Decode-Ressourcenverbrauch dar.
Reproduktion und Umfang
Die aktuellen Ergebnisse stehen in den folgenden CORE-JSON- und CSV-Dateien. Sie enthalten Versionen, Einstellungen, Stichprobenanzahl und ungerundete Statistiken. Die auf die verwendete Version bezogene llama-bench-Dokumentation beschreibt den Messumfang des Werkzeugs; das Modell-Repository belegt Herkunft und Lizenz.
Frühere Datensätze bleiben mit ihren ursprünglichen Methoden und Wiederholungszahlen im Archiv. Sie werden nicht mit diesen Messungen aus fünf Stichproben zusammengefasst. Das Szenario mit 32,768 Tokens ist hier ein 72B-Engine-Test, keine neue 8B-API-Messung. Die separate mehrstündige Lastmessung betrifft 32B; ihr Ergebnis wird nicht automatisch auf 72B übertragen.