Passen dieser Server und dieses Modell zu meiner Aufgabe? Ein Assistent benötigt zügige Gespräche; Dokumentenverarbeitung kann Wartezeit verkraften, braucht aber korrekte Ergebnisse. Tokens pro Sekunde allein beschreiben nicht das gesamte Nutzungserlebnis.
Dieser Artikel bündelt unsere Testgrundsätze für LLMs, also Modelle zur Sprachverarbeitung. Er erklärt, was wir messen, wie wir Konfigurationen vergleichen und wo die Aussagekraft jedes Ergebnisses endet. GPU Server Hub / Bestconnect, der Anbieter des beschriebenen Services, erstellt diese Materialien.
Unser gemeinsamer Standard CORE 1.1 umfasst Vorbereitung, Durchführung und Verifikation. Die Artikel zu Geschwindigkeit, Speicher und gleichzeitigen Anfragen folgen denselben Grundsätzen. Jedes Ergebnis enthält Testbedingungen und herunterladbare Messdaten.
Mit einer Frage beginnen, nicht mit einer Einstellungsliste
Vor der Messung definieren wir die Frage: die Wartezeit einer Person, gleichzeitige Anfragen oder ein Modell, das größer als der GPU-Speicher ist. Unterschiedliche Versuche teilen dieselben Grundsätze: dokumentierte Einstellungen, wiederholbare Eingaben und eine definierte Bewertung.
Beim Vergleich von Hardware oder GPU-/CPU-Verteilung bleiben Modell und Format unverändert. Ändert sich auch das Modell, vergleichen wir vollständige Konfigurationen. Ein größeres Modell kann sich anders verhalten; Größe allein ist keine Qualitätsnote.
Wie lange warten Sie auf eine Antwort?
Wir unterscheiden den Beginn einer Antwort von ihrem Abschluss. Ein Mensch kann mitlesen, während das Modell schreibt; ein Programm zur Informationsextraktion benötigt meist das vollständige Ergebnis. Beide Zeiten zählen, beschreiben aber unterschiedliche Erfahrungen.
Manche Modelle führen zusätzliche Berechnungen durch, bevor sie eine Antwort zeigen. Praktische Aufgaben messen den ersten sichtbaren endgültigen Antworttext; Rechentests messen das erste generierte Token, also ein Textfragment. Das sind unterschiedliche Kennzahlen.
Der Basis-Geschwindigkeitstest verwendet 2048 oder 8192 Eingabe-Tokens und 256 Ausgabe-Tokens. Ein Token ist nicht zwingend ein ganzes Wort. Feste Längen verhindern den Vergleich eines Satzes mit einer ganzen Seite. Normale Aufgaben, deren Antworten früher enden können, werden separat bewertet.
Eine Messung innerhalb des Servers schließt die Internetverbindung des Kunden aus. Beim Test einer vollständigen Anwendung beschreiben wir außerdem den Verbindungsort des Clients und die Komponenten zwischen ihm und dem Modell.
Was ändert sich, wenn mehrere Fragen gleichzeitig eintreffen?
Ein Server kann durch mehrere gleichzeitige Anfragen insgesamt mehr Arbeit erledigen, während jede einzelne länger wartet. Deshalb weisen wir die Nutzerantwortzeit getrennt von der Gesamtausgabe des Servers aus. Vier Anfragen in einem Test bedeuten kein Limit von vier registrierten Nutzern.
Bei einem Unternehmensassistenten müssen Dutzende Zugriffsberechtigte nicht gleichzeitig aktiv sein. Die Konfigurationswahl hängt von parallelen Aufgaben, Dokumentlänge und akzeptabler Wartezeit ab — nicht von einer aus der Generierungsgeschwindigkeit abgeleiteten Mitarbeiterzahl.
Wir vergleichen eine und vier gleichzeitige Fragen. Hinzu kommt eine Kontrolle: Vier Slots sind reserviert, aber nur einer ist aktiv. Das hilft, den Effekt der Speicherreservierung von dem zusätzlicher Anfragen zu trennen. Die genauen Einstellungen aller drei Varianten stehen unten.
Was bedeutet es, dass ein Modell in den Speicher passt?
Das Öffnen der Modelldatei ist nur der Anfang. Das Modell muss auch Eingaben annehmen und eine Antwort abschließen. Wir prüfen den Betrieb bei einer angegebenen Eingabelänge und Anzahl gleichzeitiger Aufgaben. Das Ergebnis gilt für diese Kombination, nicht für jede mögliche Gesprächslänge.
VRAM ist der GPU-Speicher; RAM gehört zum Server als Ganzem. Wir trennen Laden und Antworten. Ein Programm kann beim Start mehr Speicher benötigen als später. Der Speicher des Modellprozesses schließt außerdem andere Anforderungen des Betriebssystems und benachbarter Anwendungen aus.
Übernehmen CPU und RAM einen Teil der Arbeit, zeigen wir den Speichervorteil zusammen mit der Änderung der Antwortzeit. Die Zahl der GPU-Schichten ist ein technisches Reproduktionsdetail, kein Speicherprozentsatz.
Ist die Antwort nützlich und korrekt?
Ein schnelles Ergebnis kann nutzlos sein, wenn der Inhalt falsch ist. Deshalb verwenden wir einen festen Satz von 24 kurzen Aufgaben, 12 polnischen und 12 englischen. Sie umfassen Rechnen, Informationsextraktion, Anwendung einer vorgegebenen Regel und Antworten ausschließlich aus einem kurzen Text. Erwartete Antworten werden vor dem Modelllauf festgehalten.
Wir bewerten Inhalt und verlangtes Format getrennt. Eine Anwendung könnte etwa Firmenname und Region als strukturierte Felder benötigen. Richtige Werte mit zusätzlicher Erläuterung sind für Menschen lesbar, für eine Programmeingabe aber möglicherweise ungeeignet. Beide Beobachtungen sollten berichtet und nicht in einer Gesamtnote verdichtet werden.
Einige Beispiele aus dem englischen Teil unserer Testsuite — die Anweisungen sind hier zugunsten der Lesbarkeit gekürzt:
| Aufgabe | Was soll das Modell tun? | Erwartetes Ergebnis |
|---|---|---|
| Berechnung | Von 9 Kartons mit je 14 Artikeln die 37 verbrauchten Artikel abziehen | 89 Artikel |
| Daten auslesen | Kennung und Menge 17 aus Bestellung BX-305 extrahieren, Status weglassen | Kennung BX-305 und Menge 17 |
| Regel anwenden | Den Wert 200 klassifizieren, wenn medium den Bereich 100 bis 200 umfasst | medium |
| Anhand einer Notiz antworten | Die tägliche Kopienzahl von Plan Pine ausschließlich aus der bereitgestellten Beschreibung auslesen | 3 Kopien |
Im tatsächlichen Test muss das Modell diese Ergebnisse in festgelegten JSON-Feldern zurückgeben. Die erste Aufgabe verlangt beispielsweise exakt {"remaining":89}, ohne Erläuterung. Dies sind kleine Operationen, die Teil einer automatisierten Ticket- oder Dokumentenverarbeitung sein könnten; sie testen keine vollständige Anwendung.
Diese Aufgaben prüfen bestimmte Fähigkeiten, nicht Ihre Dokumente, Ihren Schreibstil oder lange Zusammenfassungen. Die Artikel unterscheiden mögliche Anwendungsfälle von tatsächlich durchgeführten und bewerteten Aufgaben.
Die exakte Wertbewertung gilt nur als bestanden, wenn sowohl Format als auch Werte übereinstimmen. Aus Antworten, die die Formatprüfung nicht bestehen, retten wir keine richtigen Inhalte.
Warum Tests wiederholen und längere Lastläufe durchführen?
Ein einzelner Versuch kann einen günstigeren Moment treffen. Das Basisprofil nutzt eine vollständige Aufwärmrunde und danach fünf Messrunden pro Szenario. Wir nennen Versuchsanzahl und Streuung. Ein Median beschreibt eine typische Dauer: den mittleren Messwert nach dem Sortieren. Die praktische Testsuite hat einen anderen Zweck: Jede ihrer 24 Aufgaben wird einmal versucht.
Ein längerer Versuch untersucht das Verhalten einer Konfiguration über aufeinanderfolgende Stunden. Das Verfahren verlangt mindestens vier Stunden von der ersten gemessenen Anfrage bis zur letzten abgeschlossenen Antwort, ohne anfängliches Laden und Aufwärmen. Wir beobachten Antworten, Ressourcen und Kühlung. Auch Pausen zwischen Runden bleiben erhalten; wir bezeichnen nicht das gesamte Intervall als volle GPU-Last.
Ein Vierstundentest gilt für sein Modell und seine Konfiguration, nicht für jedes andere Modell. Ein paar schnelle Antworten stützen keine Zusagen über einen ganzen Servicemonat.
Wie helfen diese Artikel bei der Auswahl?
Beginnen Sie mit den Inhalten, die Ihrer Aufgabe am nächsten kommen. Für einen Assistenten betrachten Sie Antwortzeit und gleichzeitige Anfragen. Für ein größeres Modell lesen Sie den Speichervergleich und den GPU-Betrieb mit RAM-Unterstützung. Der Ratgeber zur privaten API erklärt den Weg zur Anwendung.
Prüfen Sie, was sich geändert hat und was gleich blieb. Eine gemeinsame Methodik hilft, die richtigen Konfigurationen zu vergleichen, ohne unterschiedliche Aufgaben auf eine Zahl zu reduzieren.
Wenn die Begriffe neu sind, nutzen Sie das KI- und GPU-Glossar. Sie können uns auch Ihre Aufgabe beschreiben: Modellname, eine beispielhafte Eingabelänge und die erwartete Zahl gleichzeitiger Anfragen sind ein guter Ausgangspunkt.
Technische Details
Version und dokumentierte Bedingungen
Die Reihe verwendet gsh-llm-core/1.1. Vor der Ausführung legen wir einen Plan fest, der Modelldateien, Tokenisierung, Chatvorlage, Engine- und Treiberversionen, Hardware, Fallreihenfolge und Zeitlimits dokumentiert. Das Ausführungsprogramm prüft tatsächliche Dateien und Einstellungen; ein separates Programm berechnet Ergebnisse aus aufgezeichneten Antworten und Telemetrie neu.
Die Chatvorlage definiert, wie Nachrichten dem Modell präsentiert werden. Wir erhalten getrennte Prüfsummen für die ursprünglichen GGUF-Bytes und den tatsächlich von der Engine verwendeten Quelltext. Die festgelegte llama.cpp-Version wendet bestimmte Kompatibilitätsregeln und Jinja-Zeilenendennormalisierung an. Das Prüfprogramm reproduziert exakt diese Regeln und vergleicht das Ergebnis mit dem laufenden Server; beliebiges Kürzen von Text oder eine Ersatzvorlage wird nicht akzeptiert.
Die Umgebung umfasst eine RTX PRO 6000 Blackwell Max-Q, einen EPYC-4565P-Prozessor mit 16 Kernen und 32 logischen CPUs sowie ein 4TB-NVMe-Laufwerk. Wir testen mit 96GB System-RAM; die angebotene Konfiguration nennt 192GB. Installierter Speicher wird anhand der Moduldatensätze geprüft, getrennt vom für das Betriebssystem sichtbaren Speicher. Die Bezeichnung 96GB VRAM ist die Produktklasse der GPU; die tatsächlich vom Treiber gemeldete Kapazität wird separat gespeichert. Betriebssystem-, Treiber- und Werkzeugversionen gehören zu jeder Messung und werden nicht aus dem Angebot abgeleitet.
Wiederholbare Rechen- und Parallelitätstests
| Variante | Gleichzeitige Anfragen | Reservierte Slots | Gesamte Kontextzuweisung |
|---|---|---|---|
| Basis C1 | 1 | 1 | 8704 Tokens |
| Kontrolle C1 | 1 | 4 | 34816 Tokens |
| Parallel C4 | 4 | 4 | 34816 Tokens |
Kontext ist der Platz für den vom Modell verarbeiteten Text. Jede Variante wird separat mit 2048 und 8192 Eingabe-Tokens und exakt 256 Ausgabe-Tokens getestet. Wir wiederholen und kürzen Tokens aus demselben deklarierten Ausgangstext. Gleiche Tokenzahlen bedeuten über Modelle hinweg nicht identischen Text: Ihre Wortzerlegung kann unterschiedlich sein.
Eine vollständige Aufwärmrunde mit der vorgesehenen Parallelität geht fünf Messrunden voraus. Das bedeutet fünf Antworten bei C1 und 20 bei C4, nicht fünf unabhängige Installationen. Die Wiederverwendung bereits verarbeiteter Prompts ist deaktiviert, damit Wiederholungen nicht überwiegend das Prompt-Cache-Verhalten messen.
Die Kontrolle C1/vier Slots gegenüber C4/vier Slots isoliert die Parallelität. Basis-C1 gegenüber C4 vergleicht vollständige Bereitstellungskonfigurationen, da sich auch die Speicherreservierung ändert. Weitere gemeinsame Einstellungen sind F16-KV, Flash Attention, 16 Threads, Batch 2048, Microbatch 512 und eine ausdrücklich dokumentierte Verteilung.
Antworten, Geschwindigkeit und praktische Aufgaben
Die Antwortzeit endet mit dem abschließenden Generierungsereignis, nicht mit einem späteren Verbindungsende. Wir unterscheiden das erste generierte Token vom ersten sichtbaren endgültigen Antworttext. API-Messungen laufen lokal auf dem Server, ohne Internetlatenz des Nutzers.
Für passende Szenarien berichten wir Latenzmediane und Streuung. Die mittlere Generierungsrate einzelner Antworten unterscheidet sich von gesamten Tokens geteilt durch ein gemeinsames Beobachtungsfenster. In den API-Messungen dieser Version umfassen 256 Ausgabe-Tokens 255 zeitlich gemessene Generierungsschritte nach der Eingabeverarbeitung. Der separate llama-bench-Engine-Test misst 256 Decode-Schritte; wir ersetzen diese Anzahlen nicht gegeneinander. p95 veröffentlichen wir nur bei mindestens 200 abgeschlossenen Anfragen in einem gleichartigen Szenario. Das ist eine Berichtsregel, keine Servicegarantie.
Die praktische Testsuite umfasst sechs Aufgaben in jeder von vier Gruppen, gleichmäßig auf Polnisch und Englisch verteilt. Nach separatem Aufwärmen läuft jede Aufgabe einmal mit natürlicher Beendigung und einem Ausgabelimit von 1024 Tokens. Die Reasoning-Einstellung jedes Modells wird festgehalten; unterschiedliche Einstellungen bedeuten keinen gleichen Rechenaufwand.
Wir bewerten das JSON-Format — strukturierte Felder für ein Programm — getrennt von erwarteten Werten. Die primäre Bewertung entfernt keine zusätzlichen Codezäune oder Kommentare, wandelt keinen Text in Zahlen um und verwendet kein anderes Modell als Richter. Falsches Format oder falsche Werte bleiben Aufgabenergebnisse. Die Ergebnisse beschreiben diesen Aufgabensatz, keine allgemeine Rangliste der Modellqualität.
Kapazität, GPU-/RAM-Verteilung und Engine
Der kontrollierte GPU-/CPU-Verteilungsvergleich verwendet dasselbe 72B-Q4-Modell und identische Eingabe-/Ausgabeeinstellungen. Nur die festgelegte Verteilung ändert sich: vollständig GPU oder Varianten mit 40 beziehungsweise 20 Schichten auf der GPU. Diese Zahlen machen den Versuch reproduzierbar; sie sind keine Prozentsätze von Speicher oder Leistung.
Qwen3-235B Q5 nutzt ein separates Hybrid-Kapazitätsprofil: Attention-Berechnungen gehen an die GPU, Experten aus 44 Schichten an CPU/RAM. Dies ist eine feste Konfiguration zum Test eines großen Modells, kein isolierter Einvariablenvergleich oder Nachweis des größtmöglichen Modells. Eine abgeschlossene Antwort bei definiertem Kontext ist eine stärkere Prüfung als das bloße Laden einer Datei.
Der 72B-Engine-Test bleibt von API-Messungen getrennt. Er misst Eingabeverarbeitung und Generierung unabhängig bei 2048, 8192 und 32768 Tokens, mit fünf internen Werkzeugmessungen pro neuem Prozess nach dem Aufwärmen. Seine Ressourcentelemetrie umfasst auch Laden und Aufwärmen. Der Umfang mit 32768 Tokens ist kein neuer 8B-API-Test mit dieser Eingabelänge.
CPU, RAM und Energie aus denselben Fällen
Die Artikel zu CPU, Speicher und Leistung nutzen Telemetrie derselben gekennzeichneten Fälle. Wir erzeugen keine unzusammenhängenden Tests nur für eine weitere Tabelle. Laden, Bereitschaft, Aufwärmen, Antworten und Herunterfahren sind getrennt. Kurze Bereitschaftsfenster messen keinen mehrere Minuten unbeschäftigten Server.
Die CPU-Auslastung des Modellserverprozesses wird aus seiner aufsummierten Prozessorzeit bezogen auf 32 logische CPUs berechnet. Das ist nicht die gesamte Host-CPU-Last. Der Mittelwert umfasst Intervalle zwischen Zählerständen vor und nach jeder Runde, nicht nur die Textgenerierung. 100% einer logischen CPU bedeuten nicht 100% des Servers. PSS ist der einem Prozess zugerechnete Speicher einschließlich seines proportionalen Anteils gemeinsamer Bereiche, nicht der gesamte belegte System-RAM. Verfügbarer Hostspeicher und VRAM werden separat erfasst. Wir addieren keine Spitzen verschiedener Zeitpunkte und behandeln abgetastete Spitzen nicht als minimal erforderlichen RAM.
Die Leistungsangabe beschreibt die GPU-Karte, nicht den Verbrauch des gesamten Servers an der Steckdose. Energie wird durch zeitliche Integration der Leistung mit der Trapezregel berechnet. Messwerte müssen beide Fenstergrenzen umschließen; keine Lücke darf drei Sekunden überschreiten. Bei fehlender Abdeckung ist der Wert nicht verfügbar. Die vier exakten Stundenfenster des Langzeittests beginnen mit der ersten gemessenen Anfrage; die mittlere Leistung ist zeitgewichtet und umfasst Pausen zwischen Runden. Es ist kein Durchschnitt historischer Zehnminutenzusammenfassungen.
Testprozesse laufen in einer separaten Gruppe mit einem Speicherlimit von 81 GiB und ohne Swap-Zulassung. Die Überwachung verlangt außerdem, dass mehr als 12 GiB für das Betriebssystem verfügbar bleiben. Das sind Schutzvorkehrungen dieser Konfiguration, keine experimentell ermittelten Mindestanforderungen des Modells. MemAvailable beschreibt das Gesamtsystem; es erlaubt einem Prozess nicht, sein eigenes Limit zu überschreiten.
Vierstundenverfahren und Kühlungsbewertung
Das API-Dauerprofil verwendet Qwen3-32B Q4_K_M, 8192 Eingabe-Tokens, vier gleichzeitige Anfragen und 256 Ausgabe-Tokens. Nach vollständigem Aufwärmen laufen die Runden weiter, bis zwischen erster gemessener Anfrage und letzter abgeschlossener Antwort mindestens vier Stunden liegen. Wir erfassen sowohl dieses Intervall als auch die Vereinigung aktiver Anfragezeiträume und dokumentieren Pausen separat.
Kühlungskriterien und Analyseprogramm werden vor der Ausführung festgelegt. Wir untersuchen die Messwertabdeckung, thermische Drosselungsereignisse und den Trend der letzten Stunde. Die aufgezeichnete Kalenderzeit wird gegen eine Uhr für verstrichene Zeit geprüft, damit eine Systemuhrkorrektur den Test nicht länger erscheinen lässt.
„Stabile Temperatur“ setzt das Bestehen der festgelegten Kriterien voraus; allein die erfolgreiche Lastbearbeitung reicht nicht. Die Leistung wird zudem in festen Zehnminutenblöcken gezeigt, ohne nachträglich eine Akzeptanzschwelle zu erfinden. Eine thermische Bewertung ist nicht automatisch eine Bewertung der Leistungsstabilität oder ein Urteil über jedes Modell. Exakte Temperaturen bleiben in privaten Nachweisen; die öffentliche Beschreibung ist qualitativ.
Archive und Ergebnisprüfung
Frühere kurze Messungen nutzten drei Wiederholungen; die frühere praktische Testsuite hatte drei Aufgaben mit je einem Versuch. Frühere API-Tests reservierten selbst für einen Client vier Slots und nutzten ein anderes Aufwärmverfahren. Die historische Kapazitätsreihe verwendete einen Slot. Diese Datensätze behalten ihre ursprünglichen Einstellungen und werden nicht mit CORE 1.1 zusammengeführt. Auch der historische Langzeittest ist eine separate Reihe: Zähler und Ergebnis werden nicht auf das neue Verfahren übertragen. Blender behält seine eigene Rendering-Methodik.
Vollständige Antworten, Telemetrie und Plandatensätze haben Prüfsummen. Ein separates Prüfprogramm kontrolliert die Dateien, berechnet Zeiten und Bewertungen aus der aufgezeichneten Kommunikation neu und validiert Messgrenzen. SHA-256-Prüfsummen belegen die Übereinstimmung mit den erhaltenen Aufzeichnungen; sie sind keine unabhängige Hardwarebescheinigung. Öffentliche CSV-/JSON-Dateien sind geprüfte Auszüge ohne administrative Daten.
Wir erhalten die tatsächlichen Mess-, Veröffentlichungs- und Aktualisierungsdaten. Angezeigte Ergebnisse werden direkt aus Daten voller Genauigkeit auf höchstens eine Dezimalstelle gerundet, ohne Softwareversionen oder Prüfsummen zu verändern. Neue Reihen erhalten separate Dateien; Archive bleiben unverändert.