Das nützliche Ergebnis festlegen, bevor Sie nach Durchsatz suchen
Bei der Interaktion messen Sie die Wartezeit auf das erste Token und die auf die vollständige Antwort. Für einen Offline-Korpus messen Sie die Zeit, die nötig ist, um alle erwarteten Ausgaben zu erhalten. In beiden Fällen legen Sie die Akzeptanzregel fest: Genauigkeit bei bekannten Antworten, Qualität einer Klassifizierung oder überprüfte Feldextraktion. Ein syntaktisch gültiges JSON kann dennoch eine falsche Antwort enthalten.
Trennen Sie die Wartezeit in der Warteschlange, die Verarbeitung und den vollständigen Weg, den Ihr Client beobachtet, sofern Ihre Werkzeuge dies erlauben. Eine motorsinterne Messung hat nicht dieselben Grenzen wie die der Anwendung. Die Dokumentation der vLLM-Metriken unterscheidet insbesondere Wartezeit, erstes Token und Gesamtdauer: Behalten Sie diese Unterscheidung in Ihren Aufzeichnungen bei, unabhängig vom gewählten Motor.
Technische Quellen: vLLM — Metriken für Anfragen und Latenz
Ihre Anfragen in Auswahlkriterien verwandeln
Bereiten Sie kurze, gewöhnliche und lange Eingaben mit stabilen Identifikatoren vor. Behalten Sie Modell, Tokenizer, Gesprächsvorlage und Generierungsparameter bei. Zählen Sie die tatsächlich übertragenen Tokens, einschließlich des Verlaufs und der von der Anwendung hinzugefügten Dokumente. Notieren Sie getrennt den angeforderten Batch, die gesendete Nebenläufigkeit und die tatsächlich gleichzeitig verarbeiteten Anfragen: dies sind nicht unbedingt dieselben Zahlen.
| Festzulegende Eingabe | Messung und Einheit | Konsequenz für die Auswahl |
|---|---|---|
| Vollständiger Prompt und Ausgabelimit | Eingabe- und Ausgabe-Tokens pro Anfrage | Lange Fälle und an der Grenze abgeschnittene Antworten prüfen |
| Gleichzeitige Anfragen und Ankunftsrate | Aktive, wartende und abgeschlossene Anfragen | Die nachhaltige Last bei der geforderten Verzögerung bestimmen |
| Genauigkeit, Quantifizierung und Cache | Speicherspitze pro GPU, in Bytes oder Gio | Einstellungen ausschließen, die den Speicher bei der geplanten Last überschreiten |
| Qualitätsregel und Referenzen | Akzeptierte Ausgaben / erwartete Ausgaben; fachliche Metrik | Nur Varianten vergleichen, die dasselbe Kriterium erfüllen |
| Umfang der Zeitmessung | Erstes Token, vollständige Antwort oder Korpus: Sekunden | Dauern mit denselben Grenzen vergleichen |
| Zeitplan bis zu den abgerufenen Dateien | Gesamtzeitfenster, in Stunden oder Tagen | Wählen Sie anschließend ein Paket für 3, 7 oder 30 Tage |
Den Speicher mit Kontext und Parallelität messen
Bei einem autoregressiven Modell, das Token für Token generiert, speichert der KV-Cache Attention-Zustände. Seine Größe hängt vom Modell und den beibehaltenen Tokens ab. Ein dynamischer Cache kann während der Generierung wachsen; ein statischer Cache reserviert eine maximale Größe. Bestimmte Schichten mit gleitendem Fenster begrenzen dieses Wachstum. Testen Sie daher die vorgesehenen Längen und die Parallelität mit der tatsächlich verwendeten Strategie.
Die Quantisierung der Gewichte und die des Caches sind zwei getrennte Entscheidungen. Beispielsweise ersetzt bitsandbytes bestimmte lineare Schichten durch quantisierte Versionen; dies beschreibt nicht alle Allokationen Ihrer Ausführung. Prüfen Sie nach einem Präzisionswechsel erneut Speicher und Qualität, statt anzunehmen, dass die gesamte Spitze im gleichen Verhältnis sinkt.
Erfassen Sie mit PyTorch den Spitzenwert der allokierten Tensoren und den der vom Allocator reservierten Speichers getrennt. Addieren Sie sie nicht. Geben Sie die gemessene GPU und die Einheit an: 1 GiB entspricht 2³⁰ Byte. Diese Zähler stellen nicht unbedingt die gesamte Belegung des Geräts dar. Der Speicherbereich erläutert ihre Grenzen.
Technische Quellen: Hugging Face Transformers 5.17 — KV-Cache-Strategien · Hugging Face Transformers 5.17 — bitsandbytes-Quantisierung · PyTorch 2.14 — Verwaltung und Zähler des CUDA-Speichers
Ein messbarer Testlauf über 300 Dokumente
Beispiel, das Sie mit Ihrem autorisierten Korpus durchführen können: Extrahieren Sie Datum, Betrag und Kategorie aus 300 Dokumenten. Prüfen Sie die erwarteten Werte nach, legen Sie den Umgang mit fehlenden Feldern fest und bestimmen Sie die Akzeptanzschwelle vor dem Testlauf. Die Anzahl der Dokumente beschreibt das Protokoll; keine Laufzeit, kein Score und kein Durchsatz wird vorausgesetzt.
- Fixieren Sie die 300 Identifikatoren, die Modellrevision, die Prompts, die Token-Grenzen und die Parsing-Regel. Halten Sie lange Dokumente im Fazit identifizierbar.
- Führen Sie eine Referenz mit jeweils einer Anfrage aus. Trennen Sie Laden, Aufwärmen und Messung; bewahren Sie die Vorhersagen und Fehler pro Dokument auf.
- Erhöhen Sie anschließend einen einzigen Parameter: Batch für eine gebündelte Verarbeitung oder Parallelität für eine Request-Engine. Behalten Sie dieselben Eingaben und Qualitätskriterien bei.
- Erfassen Sie für jeden Durchlauf die Dauer, den Speicherspitzenwert, die Anzahl der ohne Duplikat wiedergefundenen Identifikatoren und die akzeptierten Ausgaben. Wiederholen Sie die Messungen und bewahren Sie die Rohwerte mit ihrer Streuung auf.
- Wenn eine Variante fehlschlägt, halten Sie den Grund fest: Speicher, Abschneiden, Format oder Qualität. Ein reduzierter Batch oder ein Neustart schafft eine zu dokumentierende Entscheidung, nicht einen zu tilgenden Fehler.
Technische Quellen: IteraGPU — detailliertes Protokoll für den Vergleich bei gleichwertiger Qualität
Die Ressourcen von IteraGPU Lab v1 im richtigen Umfang einsetzen
Das Notebook und sein Begleitskript bieten eine Gewichtsberechnung und eine Messung an einem kleinen synthetischen Netzwerk. Ihr Messcode wurde auf einer lokalen RTX 5070 mit PyTorch 2.11.0 auf einer kleinen Konfiguration in float32 ausgeführt. Dieser Versuch überprüft diesen Ausführungsfall; er misst weder ein LLM noch einen KV-Cache noch die GPUs des Katalogs bei Ihren Anfragen.
Nutzen Sie das Notebook, um die Zähler zu verstehen, und messen Sie anschließend Ihre tatsächliche Last mit ihrer Umgebung. Das Qualitätsprotokoll und die Rohdatentabelle dienen der Vorbereitung des Vergleichs. Die Ausgaben des verteilten Notebooks und die Ergebniszeilen der CSV bleiben leer; das Verfahren installiert weder ein Modell noch einen Treiber. Lesen Sie die Voraussetzungen der README vor der Ausführung.
- Notebook zum Speicher von IteraGPU Lab v1
Berechnungen und kleines synthetisches Netzwerk zum Verständnis der Speichermessung.
- Noch auszufüllendes Qualitätsprotokoll
Feste Eingaben, Akzeptanz der Ausgaben und Vergleich der Testläufe.
- Leere Rohdatentabelle
Eine Zeile pro tatsächlichem Durchlauf, mit Parametern, Messwerten und Urteil.
- Voraussetzungen und Grenzen von IteraGPU Lab v1
Anweisungen und genauer Umfang des bereits durchgeführten lokalen Tests.
Von Messwerten zu einem Angebot
Ihr Auswahlblatt sollte kompatible Umgebung, Speicher pro Karte, Kontext, Nebenläufigkeit, erreichte Qualität und gemessene Zeiten zusammenführen. Vergleichen Sie die Konfigurationen, die diese Kriterien erfüllen, und danach die Pakete für 3, 7 und 30 Tage entlang des vollständigen Ablaufs: Vorbereitung, Verarbeitung, Bewertung, Wiederaufnahmen und Export. Der Rechner im Dossier benchmarks verwendet das gesamte Paket und tatsächlich validierte, nützliche Korpora.
Bewahren Sie dieses Blatt und die Codeversionen in Ihrem Notizbuch auf. Sie wählen Ihre Software und Ihre Verarbeitungen; IteraGPU nimmt keine Einsicht in den Inhalt Ihrer Dateien, Prompts oder Berechnungen vor. Eine Umgebungsauswahl bei der Bestellung bringt Ihren Vorbereitungsbedarf zum Ausdruck: Sie ist kein Nachweis, dass Ihr Modell bereits installiert oder getestet wurde.
Praktische Fragen
Reichen 24 GB für mein Inferenzmodell?
Die Kapazität von 24 GB reicht nicht aus, um die Frage ohne Kenntnis des Modells und der Last zu beantworten. Prüfen Sie gemeinsam Gewichte, Ausführungszuweisungen, Kontext und gleichzeitige Anfragen. Die Konfiguration muss die langen Fälle mit der geforderten Qualität abschließen; eine Dateigröße oder eine Schätzung der Gewichte allein belegt das nicht.
Welcher Durchsatz ist für einen Offline-Korpus zu vergleichen?
Vergleichen Sie zuerst die Zeit, die nötig ist, um denselben Korpus abzuschließen und zu bewerten. Wenn Sie einen Durchsatz veröffentlichen, geben Sie die Anzahl der akzeptierten nützlichen Ausgaben, die zugrunde gelegte Zeit und die Fehler an. Ein Durchsatz in Tokens pro Sekunde ohne Antwortlänge und ohne Qualitätskontrolle reicht nicht aus, um zwei Konfigurationen zu unterscheiden.
Erzwingt ein Speicherüberlauf den Wechsel der GPU?
Ein Speicherüberlauf erfordert zunächst, die Einstellung und die Eingabe zu identifizieren, die ihn verursacht haben. Sie können Batch, Nebenläufigkeit, Länge oder Präzision prüfen und dabei das Projektziel beibehalten. Jede Reduzierung, die die verarbeiteten Dokumente oder die erwarteten Antworten verändert, erfordert eine neue Qualitätsprüfung; mehr Speicher kann nötig sein, wenn diese Randbedingungen erhalten bleiben sollen.
Validiert das bereitgestellte Notebook meine Inferenzanwendung?
Das bereitgestellte Notebook validiert Ihre Anwendung nicht: Es misst ein kleines synthetisches Netzwerk und erklärt die Speicherzähler. Der dokumentierte lokale Test betrifft nur diesen Fall. Ihre Anwendung muss mit ihrem Modell, ihren Eingaben, ihrer Umgebung und ihren eigenen Abnahmekriterien bewertet werden, bevor eine Aussage über Kapazität oder Leistung getroffen wird.