Grafikkarte und Prozessor übernehmen in einer KI-Anwendung unterschiedliche Aufgaben. Die GPU kann Modellberechnungen ausführen, während die CPU Dokumentensuche, Datenbank und Dateiimporte bearbeitet. Wir messen, wie sich die Prozessornutzung verändert, wenn das Modell auf der Karte läuft oder einen Teil der Arbeit mit CPU und RAM teilt. Neben den Prozentwerten steht die Antwortzeit.
Die CORE-1.1-Reihe vergleicht GPU-residente 8B-, 32B- und 72B-Modelle mit demselben 72B-Modell, das teilweise auf CPU und System-RAM läuft. Unsere gemeinsame LLM-Benchmark-Methodik legt Eingabe- und Ausgabelängen, Aufwärmläufe und Messanzahlen fest. Beim 72B-Modell lässt sich dadurch die veränderte Verteilung vergleichen, ohne zugleich das Modell zu ändern.
CPU, GPU und Antwortzeit in einem Vergleich
Das B im Modellnamen bedeutet Milliarden Parameter, nicht Gigabyte. Q4_K_M ist eine kompaktere Speicherform; unser KI- und GPU-Glossar erläutert diese Bezeichnungen.
Die Tabelle betrifft jeweils eine Anfrage: 2048 Eingabe-Tokens und 256 Ausgabe-Tokens. Tokens sind die vom Modell verarbeiteten Wort- und Zeichenbausteine. Jede Konfiguration hat fünf Messrunden nach einer separaten Aufwärmrunde. Die Antwortzeit ist der mittlere Wert dieser fünf Messungen.
In der CPU-Spalte entsprechen 100% der insgesamt verfügbaren Zeit aller 32 Hardware-Threads, nicht einem einzelnen Kern. Wir messen den Anteil des Programms, das das Modell bereitstellt; andere Dienste sind nicht enthalten.
| Modell, Format und Verteilung | CPU-Anteil des Prozesses am gesamten Server | GPU-Auslastung, Stichprobenmittelwert | Median der vollständigen Antwort |
|---|---|---|---|
| Qwen3-8B Q4_K_M — Modell auf GPU | 3.1 % | 94.2 % | 1.5 s |
| Qwen3-32B Q4_K_M — Modell auf GPU | 3.1 % | 99.0 % | 5.5 s |
| Qwen2.5-72B-Instruct Q4_K_M — Modell auf GPU | 3.1 % | 100.0 % | 11.6 s |
| Qwen2.5-72B-Instruct Q4_K_M — GPU + CPU: geringere VRAM-Nutzung | 47.0 % | 5.8 % | 249.2 s |
| Qwen2.5-72B-Instruct Q4_K_M — GPU + CPU: weiter reduzierte VRAM-Nutzung | 47.5 % | 5.9 % | 363.5 s |
Bei den drei auf der GPU laufenden Modellen nutzte der Modellserverprozess durchschnittlich 3.1% der gesamten CPU-Zeit des Servers. Beim selben 72B-Modell erhöhte die Verlagerung eines Teils der Arbeit auf die CPU diesen Anteil auf 47.0–47.5% und die typische Antwortzeit von 11.6 s auf 249.2 s beziehungsweise 363.5 s. Der Verbleib auf der GPU bedeutete damit kürzere Wartezeiten und geringere Prozessorlast — ein nützlicher Ausgangspunkt für Tests der unterstützenden Anwendungsdienste.
Die CPU-Nutzung in der Tabelle gehört zum Modellserverprozess, nicht zu allen Programmen auf dem Server. Der GPU-Wert beschreibt separat die Kartenaktivität bei der Bearbeitung der gemessenen Anfragen. Keiner der Prozentwerte allein bestimmt die Nutzerkapazität: Auch die Dauer der Ressourcenbelegung pro Aufgabe zählt.
Was macht die CPU, bevor das Modell antwortet?
Stellen Sie sich vor, ein Mitarbeiter fragt einen Assistenten nach der Rückgaberichtlinie. Das Modell muss nicht den gesamten Dokumentenbestand erhalten. Die Anwendung prüft zuerst die Zugriffsrechte, findet das relevante Dokument, wählt Passagen aus und bereitet die Eingabe vor. Erst dann sendet sie diese an das Programm mit dem Modell. Nach Eingang der Antwort kann sie das Ausgabeformat prüfen und das Ergebnis speichern.
Viele dieser Tätigkeiten beanspruchen Prozessor, Speicher oder Datenbank. Der Import neuer PDFs ergänzt das Einlesen und die Vorbereitung für die Suche. Dies ist ein beispielhafter Ablauf, kein weiteres gemessenes Szenario. Er verdeutlicht, warum allein die Textgenerierungsgeschwindigkeit der GPU für die Serverwahl nicht ausreicht.
Trennen Sie zwei Fragen: Wie viel CPU benötigt das Modell selbst und wie viel benötigen die Dienste, die ihm Aufgaben liefern? Unsere Messung beantwortet die erste Frage für die angegebene Konfiguration. Die Reserve für die zweite muss mit Ihrer Anwendung ermittelt werden.
Welche Skala verwenden die CPU-Prozentwerte?
In diesem Artikel bedeuten 100% CPU die insgesamt verfügbare Zeit aller 32 Hardware-Threads. Manche Systemwerkzeuge verwenden stattdessen eine Skala, bei der 100% einer logischen CPU entsprechen. Teilen Sie einen solchen Wert beispielsweise durch 32, erhalten Sie etwa 3.1% auf der hier verwendeten Gesamtsystemskala. Das erklärt die Berechnung; es ist kein weiteres Messergebnis.
Das bedeutet nicht, dass das Programm während des gesamten Tests einen physischen Kern belegte. Threads können auf verschiedenen Kernen laufen, und ein Durchschnitt verdeckt kürzere Laständerungen. Es belegt auch nicht, dass eine Beschränkung auf einen Thread dieselbe Leistung erhalten würde: Diesen Versuch haben wir nicht durchgeführt.
Betrachten Sie CPU-Nutzung zusammen mit Antwortzeit. Wenn Nutzer länger warten, prüfen Sie, ob die Arbeit auf Dokumentenvorbereitung, Datenbankzugriff oder einen Platz in der Modellwarteschlange wartet. Ein niedriger Mittelwert des Gesamtservers schließt Verzögerungen in einer dieser Phasen nicht aus.
Wann führt die CPU die Modellberechnungen aus?
Die Situation ändert sich, wenn ein Teil des Modells auf der CPU mit System-RAM läuft. Diese Anordnung heißt Offloading. Der Prozessor hilft dann, Antworten zu erzeugen, statt nur Anfragen vorzubereiten.
Unser separater 72B-Vergleich auf GPU und mit RAM untersucht diesen Zielkonflikt. Weniger GPU-Speicherbedarf kann längere Wartezeit bedeuten. Deshalb enthält die Tabelle neben CPU-Nutzung auch Antwortzeit: Zusätzliche Ressourcen helfen, wenn sie die benötigte Aufgabe in akzeptabler Zeit ermöglichen.
Denken Sie an Dokumentenverarbeitung in einer nächtlichen Warteschlange. Eine längere einzelne Aufgabe kann akzeptabel sein, wenn die Ergebnisse erst morgens benötigt werden. Bei einem interaktiven Assistenten kann das Gegenteil gelten: Nutzer erwarten eine schnelle Antwort. Dies sind Anwendungsbeispiele, keine weiteren Messszenarien. Die Entscheidung erfordert eine Prüfung Ihrer Warteschlange und der erwarteten Bearbeitungsdauer.
Wie nutzen Sie dieses Ergebnis für die Anwendungsplanung?
Beginnen Sie mit einem einfachen Ablauf und einer repräsentativen Anfrage. Prüfen Sie die Modellantwort ohne die umgebenden Dienste und ergänzen Sie dann Dokumentensuche und Ausgabeprüfung. Fügen Sie schließlich normale Hintergrundarbeit wie Dateiimporte hinzu. Vergleichen Sie Wartezeiten sowie CPU-Nutzung des Prozesses und des gesamten Hosts über dieselben Intervalle.
Fazit: Betrachten Sie die CPU als Teil des gesamten Services. Lässt das Modell Reserven, prüfen Sie deren Nutzung für Suche und andere Arbeit. Beansprucht das Modell den Prozessor selbst stark, teilen sich benachbarte Dienste diese Ressourcen. Die Messungen liefern eine Grundlage für diese Entscheidungen, kein fertiges Nutzerlimit.
Unser Ratgeber zu System-RAM vervollständigt das Bild; das KI- und GPU-Glossar erklärt die Begriffe. Serverkonfiguration ansehen oder uns Ihre Anwendung beschreiben.
Technische Details
Umfang der aktuellen Reihe
Die aktuellen Ergebnisse verwenden gsh-llm-core/1.1. Die Haupttabelle verwendet 2048 Eingabe-Tokens, 256 Ausgabe-Tokens, C1 und einen Slot. Die GPU-Konfigurationen umfassen Qwen3-8B Q4_K_M, Qwen3-32B Q4_K_M und Qwen2.5-72B-Instruct Q4_K_M. Die beiden Konfigurationen mit teilweisem Offloading verwenden dasselbe 72B-Modell, dieselbe Revision und Quantisierung. Nur die angeforderte Anzahl der GPU-Schichten ändert sich; die genauen Einstellungen stehen in den herunterladbaren Daten.
Der Vergleich unterschiedlicher Modelle ist ein Konfigurationsvergleich, kein isolierter Test von Modellgröße oder Antwortqualität. Die API-Leistungstests decken auch längere Eingaben und gleichzeitige Anfragen ab.
Hardware und Methode
| Komponente | Messkonfiguration |
|---|---|
| CPU | AMD EPYC 4565P, 16 Kerne / 32 Threads |
| GPU | RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| System-RAM | 96 GB |
| Betriebssystem und Treiber | Rocky Linux 10.2, NVIDIA 595.91.07 |
| Engine | llama.cpp b11146, 16 Engine-Threads |
Zu den gemeinsamen Einstellungen gehören eine vollständige Aufwärmrunde und fünf Messrunden pro Eingabelänge. Die lokale API verwendet 8704 Tokens Kontext, F16-KV-Cache und Flash Attention. Das Laden erfolgt mit mmap, wobei Lazy Loading, automatische Anpassung und Prompt-Caching deaktiviert sind. Dateiprüfsummen werden vor dem Laden geprüft; wir behaupten keinen Kaltstart und rechnen nicht den gesamten Dateicache einem Modell zu.
Zähler und Messfenster
Die Prozess-CPU-Zeit ergibt sich aus dem Anstieg der /proc-Zähler zwischen Momentaufnahmen unmittelbar vor und nach jeder Runde. Der angegebene Mittelwert teilt die gesamten CPU-Sekunden durch die Summe dieser Intervalle und die Anzahl logischer CPUs. Es ist eine zeitgewichtete Rate, kein Durchschnitt beliebig ausgewählter Werte. Der Zähler umfasst den gesamten Prozess, ohne Berechnung, Treiberinteraktion und aktives Warten zu trennen. Wir beschränkten den Prozess nicht auf einen Kern.
Die mittlere GPU-Aktivität verwendet Stichproben innerhalb abgeschlossener Antwortintervalle. Ihr Fenster unterscheidet sich leicht von den CPU-Momentaufnahmen, die jede Runde umschließen. Die Antwortzeit endet mit dem Ereignis der abgeschlossenen Generierung; sie ist weder reine CPU- noch reine GPU-Ausführungszeit. Die Abtastung erfolgt nominell einmal pro Sekunde; der Export enthält Anzahl und größte Lücke. Linux beschreibt Prozess- und Systemzähler in der /proc-Dokumentation.
Aktuelle Daten und Archiv
core-v1-results.json, core-v1-results.csv und core-v1-chart.json beschreiben die aktuelle Reihe. Die früheren results.json, results.csv und chart.json bleiben unten im Datenarchiv unverändert erhalten. Die alten drei Wiederholungen oder die andere Slotzuweisung werden nicht mit den fünf CORE-Runden vermischt.