Die vLLM-Quantisierung kann dazu führen, dass ein Modell in weniger GPU-Speicher passt, sie ist jedoch kein universeller Geschwindigkeitsschalter. Ein kleinerer Checkpoint kann mehr Platz für den KV-Cache und parallele Anfragen lassen. Der tatsächliche Durchsatz hängt vom Modell, Quantisierungsformat, der GPU-Architektur, dem Kernel, der Prompt-Länge, der Ausgabelänge und dem Verkehrsmuster ab. Die sinnvolle Entscheidung besteht darin, ein unterstütztes Format zu wählen und anschließend eine repräsentative Arbeitslast mit einer unquantisierten Baseline zu messen.
Dieser Leitfaden zur vLLM-Quantisierung bietet Ihnen einen praktischen Auswahl- und Testprozess. Er beansprucht kein Benchmark-Ergebnis für eine GPU oder ein Modell, das wir nicht getestet haben.
Was die vLLM-Quantisierung verändert
Bei der Quantisierung werden einige Modellwerte mit weniger Bits gespeichert als in einem typischen FP16- oder BF16-Checkpoint. Der deutlichste Effekt erster Ordnung ist ein geringerer Speicherbedarf für Gewichte. Wenn der Speicherbedarf der Gewichte der Grund dafür ist, dass ein Modell nicht passt, kann ein kompatibler quantisierter Checkpoint den Betrieb auf einer kleineren GPU ermöglichen oder mehr Speicher für Anfragen freilassen. Eine GPU benötigt weiterhin Speicher für Aktivierungen, den KV-Cache, Runtime-Overhead und parallele Worker. Die Parameteranzahl durch Bits pro Gewicht zu teilen, ist daher nur eine grobe Untergrenze und keine Schätzung des für die Bereitstellung erforderlichen Speichers.
Für die vLLM-Quantisierung gibt es zwei gängige Wege. Sie können einen bereits im Voraus quantisierten Checkpoint laden oder beim Laden einen unterstützten Online-Quantisierungspfad verwenden. Prüfen Sie in beiden Fällen vor der Formatwahl die Modellkarte und die aktuelle vLLM-Kompatibilitätsmatrix. Die vLLM-Quantisierungsdokumentation ist die maßgebliche Quelle für Methoden und Hardwareunterstützung; sie weist ausdrücklich darauf hin, dass sich die Matrix mit der Weiterentwicklung der Unterstützung ändert.
Format anhand von Checkpoint und GPU wählen
| Option | Praktischer Ausgangspunkt | Vor der Bereitstellung prüfen |
|---|---|---|
| AWQ | Ein als AWQ-Checkpoint bereitgestelltes Modell und eine kompatible GPU | Modellqualität, Kernel-Auswahl, Prompt-Längen und tatsächliche Latenz. |
| GPTQ | Ein als GPTQ-Checkpoint bereitgestelltes Modell | Exakte Checkpoint-Konfiguration, vLLM-Version, GPU-Unterstützung und Qualitätsrückgang. |
| FP8 | Ein kompatibler Checkpoint und eine GPU mit unterstützter FP8-Ausführung | Ob die gewählte vLLM-Implementierung Ihre Architektur und Modellschichten unterstützt. |
| GGUF | Ein bereits im GGUF-Format bereitgestelltes Modell | Die spezifische Architektur und vLLM-Feature-Unterstützung; gehen Sie nicht davon aus, dass sich das Verhalten von Ollama eins zu eins übertragen lässt. |
| BitsAndBytes oder komprimierte Tensoren | Ein Checkpoint und Bereitstellungspfad, die diese ausdrücklich erfordern | Runtime-Abhängigkeiten, Ladeverhalten, unterstützte Kernel und Durchsatz. |
Die aktuelle vLLM-Matrix führt AWQ und GPTQ für Ampere, Ada und Hopper auf. Sie führt FP8 über llm-compressor für Ada, Hopper und einige AMD-GPU-Pfade auf, während GGUF ein anderes Unterstützungsmuster aufweist. A100 ist eine Ampere-GPU und H100 eine Hopper-GPU, doch die Unterstützung ist methodenspezifisch. Leiten Sie nicht ab, dass jede FP8-, FP4- oder Marlin-Variante auf jeder Karte einer Familie funktioniert. Prüfen Sie die exakte Zeile in der Hardware-Kompatibilitätstabelle und die Metadaten des Checkpoints selbst.
Wenn Sie noch kein Modell ausgewählt haben, vergleichen Sie zwei Kandidaten-Checkpoints, die dasselbe Basismodell und denselben Evaluierungssatz verwenden. Der Vergleich eines AWQ-Modells aus einer Familie mit einem unquantisierten Modell aus einer anderen vermischt die vLLM-Quantisierung mit der Modellqualität.
Ein Bereitstellungs-Workflow, der Scheinerfolge vermeidet
- Service-Ziel definieren. Erfassen Sie Modell, Kontextlänge, erwartete Eingabe- und Ausgabelängen, parallele Anfragen, p95-Latenzziel und Qualitätstests. Ein Chatbot, ein Batch-Klassifikator und ein Agent mit langem Kontext haben unterschiedliche Engpässe.
- Baseline erfassen. Führen Sie den unquantisierten Checkpoint auf derselben GPU und mit derselben vLLM-Version aus. Erfassen Sie maximalen GPU-Speicher, Zeit bis zum ersten Token, Ausgabetoken-Durchsatz, End-to-End-p50/p95-Latenz, Fehler und die Rate akzeptierter Ergebnisse.
- Kompatiblen quantisierten Checkpoint auswählen. Lesen Sie dessen Modellkarte und die aktuelle Methodenmatrix von vLLM. Fixieren Sie Checkpoint-Revision, vLLM-Version, CUDA-/Treibersystem und Hardware-SKU im Testprotokoll.
- Mit einem kleinen Canary-Test beginnen. Bestätigen Sie, dass das Modell geladen wird, den erforderlichen Endpunkt und die Generierungseinstellungen bedient und plausible Ausgaben erzeugt, bevor Sie Traffic anwenden.
- Bei mehreren Parallelitätsstufen benchmarken. Messen Sie mit Ihren tatsächlichen Prompt- und Antwortlängen. Eine einzelne Anfrage kann eine andere Konfiguration begünstigen als ein dauerhafter Serving-Betrieb.
- Dieselbe Qualitätssuite ausführen. Quantisierung kann Ausgaben verändern. Bewerten Sie domänenspezifische Korrektheit, Formateinhaltung, Ablehnungen und sicherheitskritische Fälle, statt sich allein auf Perplexität zu verlassen.
- Kosten pro akzeptiertem Ergebnis berechnen. Der GPU-Stundenpreis geteilt durch rohe Tokens pro Sekunde reicht nicht aus, wenn das quantisierte Modell mehr Aufgaben nicht besteht oder Wiederholungen benötigt.
Für einen Serving-Benchmark dokumentiert vLLM vllm bench serve sowie seine Datensätze und Endpunktoptionen im offiziellen Leitfaden zur Benchmark-CLI. Verwenden Sie einen Traffic-Datensatz, der Ihrer Anwendung entspricht; synthetische zufällige Prompts sind für kontrollierte Vergleiche nützlich, sollten jedoch nicht als Produktionsleistung dargestellt werden.
Speicherplanung: Gewichte sind nur ein Posten
Ein einfaches Planungsarbeitsblatt trennt vier Kategorien:
total GPU memory needed ≈ model weights + KV cache + runtime/activation overhead + safety headroom
Das Quantisierungsformat verändert hauptsächlich den Anteil für die Modellgewichte. Der Druck auf den KV-Cache wächst mit der Kontextlänge und der Anzahl aktiver Sequenzen. Ein Modell, das bei einer Anfrage gerade noch passt, kann bei gleichzeitigem Long-Context-Traffic dennoch scheitern oder deutlich langsamer werden. Bei Multi-GPU-Setups verändert Tensorparallelismus sowohl den Speicherbedarf pro Karte als auch den Kommunikations-Overhead; der kleinstmögliche Checkpoint ist nicht automatisch die kostengünstigste Bereitstellung.
Bevor Sie eine GPU mieten, sollten Sie sich fragen, ob Sie ein größeres Modell unterbringen, die Parallelität für ein kleineres Modell erhöhen oder Kosten bei gleichbleibender Qualität senken müssen. Die Antwort bestimmt, welcher Kompromiss zwischen Speicher und Durchsatz relevant ist. Flatkeys Cloud GPU Compute führt GPU-Mietoptionen auf und bittet Kunden, Konfiguration, Region, Kapazität und Mietbedingungen zu bestätigen. Behandeln Sie die Live-Verfügbarkeit und den Preis als Eingaben zum Zeitpunkt der Angebotserstellung, nicht als feste Zahlen in einem Benchmark-Artikel.
vLLM-Quantisierung fair benchmarken
Halten Sie Basismodell, Generierungsparameter, Prompt-Satz, Ausgabelimit, Cache-Zustand und GPU konstant. Messen Sie mindestens drei Laststufen: eine einzelne Anfrage für die Reaktionsfähigkeit, eine repräsentative Produktionsparallelität und einen Belastungspunkt, an dem sich die Latenz zu verschlechtern beginnt. Berichten Sie sowohl den Gesamtdurchsatz als auch die p95-Latenz. Wenn Sie nur Tokens pro Sekunde bei Sättigung angeben, können Nutzer nicht erkennen, ob interaktive Anfragen weiterhin akzeptabel bleiben.
Nehmen Sie die Modellqualität in die Scorecard auf:
| Messgröße | Warum sie wichtig ist |
|---|---|
| Maximaler GPU-Speicher | Zeigt, ob die Quantisierung nutzbaren Spielraum schafft. |
| Zeit bis zum ersten Token | Ist für Streaming-Schnittstellen wichtig. |
| Ausgabe-Tokens pro Sekunde | Zeigt den Generierungsdurchsatz, aber nicht die Aufgabenqualität. |
| p95-Ende-zu-Ende-Latenz | Zeigt das Verhalten am Rand der Verteilung unter Last. |
| Fehler- und OOM-Rate | Erkennt eine Konfiguration, die nur dann schnell aussieht, wenn Anfragen erfolgreich sind. |
| Rate akzeptierter Ergebnisse | Übersetzt Rohgeschwindigkeit in nutzbare Arbeit. |
Der entscheidende Vergleich bei der vLLM-Quantisierung ist nicht abstrakt „quantisiert versus unquantisiert“. Er lautet: „Dieser Checkpoint und Kernel auf dieser GPU bei dieser Arbeitslast im Vergleich zu unserer Basislinie.“ Veröffentlichen Sie die Bedingungen zusammen mit jedem Ergebnis. Wenn Ihr Test keine Qualitätsprüfung enthält, bezeichnen Sie ihn als reines Performance-Experiment.
Häufige Fehlermodi
Das Modell wird nicht geladen. Prüfen Sie Checkpoint-Metadaten, Quantisierungsmethode, vLLM-Version, GPU-Fähigkeiten und ob die Methode jede von der Architektur verwendete Schicht unterstützt. Die vLLM-Methodenmatrix sollte geprüft werden, bevor Sie Kommando-Flags blind ändern.
Speichereinsparungen haben die Latenz nicht verbessert. Ein kleinerer Speicherbedarf für Gewichte garantiert keinen schnelleren Kernel. Testen Sie mit Ihrer Zielparallelität und prüfen Sie die Zeit bis zum ersten Token, die Decodierungsgeschwindigkeit und die GPU-Auslastung. Mehr Spielraum für den KV-Cache kann der eigentliche Vorteil sein.
Ein Low-Bit-Checkpoint wirkt schnell, besteht aber Qualitätstests nicht. Behalten Sie einen Produktions-Akzeptanzsatz bei und messen Sie den Prozentsatz der Ausgaben, die Ihre Anwendungskriterien erfüllen. Vor dem Canary sollte ein Rollback-Schwellenwert festgelegt werden.
Der Benchmark kann nicht reproduziert werden. Halten Sie Modell- und Checkpoint-Revisionen, vLLM- und Treiberversionen, GPU-SKU, Datensatz, Parallelität, Prompt-Längen, Ausgabelängen und Kommandoargumente fest. Ohne diese Angaben ist eine Durchsatzkennzahl Marketing statt technischer Evidenz.
Wann Flatkey Cloud GPU verwendet werden sollte
Wenn Sie Ihren eigenen vLLM-Server betreiben und quantisierte Checkpoints vergleichen müssen, wählen Sie die GPU-Kapazität anhand eines gemessenen Speicher- und Parallelitätsbedarfs. Flatkey bietet über Cloud GPU Compute NVIDIA-GPU-Mietoptionen an. Bestätigen Sie vor einer Verpflichtung die verfügbare SKU, Bereitstellungsregion, Kapazität, Preise und Servicebedingungen. Ein vLLM-Quantisierungstest gehört auf die Konfiguration, die Sie tatsächlich mieten möchten. Wenn Sie statt des Betriebs von vLLM eine verwaltete Modell-API benötigen, bewerten Sie Flatkeys API-Route und Modellverzeichnis separat; das ist ein anderes Betriebsmodell.
Für verwandte Bereitstellungsentscheidungen lesen Sie unseren vLLM-Bereitstellungsleitfaden, den Leitfaden zu vLLM-Multi-GPU-Inferenz und den Vergleich von vLLM und Ollama.
FAQ
Macht vLLM-Quantisierung die Inferenz immer schneller?
Nein. Sie kann den Speicherbedarf der Gewichte reduzieren, aber Latenz und Durchsatz hängen vom Checkpoint, Kernel, der GPU, den Sequenzlängen und der Anfragelast ab. Benchmarken Sie eine reale Arbeitslast gegen eine Basislinie.
Kann ich AWQ auf einer A100 oder H100 verwenden?
Die aktuelle vLLM-Kompatibilitätsmatrix führt AWQ-Unterstützung für Ampere und Hopper auf, zu denen A100 und H100 gehören. Prüfen Sie vor der Bereitstellung den genauen Checkpoint, die aktuelle vLLM-Version und die Modellarchitektur.
Wird FP8 auf jeder NVIDIA-GPU unterstützt?
Nein. Die Unterstützung variiert je nach Quantisierungsimplementierung und Architektur. Die aktuelle Matrix unterscheidet Methoden wie llm-compressor FP8 und Marlin; prüfen Sie die genaue Zeile für Ihre Hardware.
Sollte ich vor oder nach der Auswahl einer GPU quantisieren?
Bestimmen Sie zunächst die Größe der Arbeitslast und das Qualitätsziel und testen Sie dann in Frage kommende Checkpoints auf kompatiblen GPUs. Die Wahl von Format und Hardware sollte gemeinsam bewertet werden.
