La quantification vLLM peut permettre à un modèle de tenir dans moins de mémoire GPU, mais elle n’est pas un levier universel d’accélération. Un checkpoint plus petit peut laisser davantage de place pour le cache KV et les requêtes simultanées. Le débit réel dépend du modèle, du format de quantification, de l’architecture GPU, du kernel, de la longueur des prompts, de la longueur des sorties et du profil de trafic. La décision raisonnable consiste à choisir un format pris en charge, puis à mesurer une charge de travail représentative par rapport à une référence non quantifiée.
Ce guide de quantification vLLM vous propose un processus pratique de sélection et de test. Il ne prétend pas fournir un résultat de benchmark pour un GPU ou un modèle que nous n’avons pas testé.
Ce que change la quantification vLLM
La quantification stocke certaines valeurs du modèle dans moins de bits qu’un checkpoint typique FP16 ou BF16. L’effet de premier ordre le plus évident est une réduction de la mémoire des poids. Si la mémoire des poids empêche un modèle de tenir, un checkpoint quantifié compatible peut permettre de l’exécuter sur un GPU plus petit ou de laisser davantage de mémoire pour les requêtes. Un GPU a toujours besoin de mémoire pour les activations, le cache KV, la surcharge d’exécution et les éventuels workers parallèles. Diviser le nombre de paramètres par le nombre de bits par poids ne constitue donc qu’une borne inférieure approximative, et non une estimation de mémoire exploitable en déploiement.
Il existe deux approches courantes pour la quantification vLLM. Vous pouvez charger un checkpoint qui a été quantifié à l’avance, ou utiliser un chemin de quantification en ligne pris en charge au moment du chargement. Dans les deux cas, examinez la fiche du modèle et la matrice de compatibilité vLLM actuelle avant de choisir un format. La documentation sur la quantification vLLM fait autorité pour les méthodes et la prise en charge matérielle ; elle avertit explicitement que la matrice évolue à mesure que la prise en charge progresse.
Choisir le format en fonction du checkpoint et du GPU
| Option | Point de départ pratique | À vérifier avant le déploiement |
|---|---|---|
| AWQ | Un modèle distribué sous forme de checkpoint AWQ et un GPU compatible | La qualité du modèle, la sélection du kernel, les longueurs des prompts et la latence réelle. |
| GPTQ | Un modèle distribué sous forme de checkpoint GPTQ | La configuration exacte du checkpoint, la version de vLLM, la prise en charge GPU et la régression de qualité. |
| FP8 | Un checkpoint compatible et un GPU prenant en charge l’exécution FP8 | Si l’implémentation vLLM choisie prend en charge votre architecture et les couches du modèle. |
| GGUF | Un modèle déjà distribué au format GGUF | L’architecture spécifique et la prise en charge des fonctionnalités vLLM ; ne supposez pas que le comportement d’Ollama se transpose à l’identique. |
| BitsAndBytes ou tenseurs compressés | Un checkpoint et un chemin de déploiement qui les exigent explicitement | Les dépendances d’exécution, le comportement au chargement, les kernels pris en charge et le débit. |
La matrice vLLM actuelle répertorie AWQ et GPTQ pour Ampere, Ada et
Hopper. Elle répertorie FP8 via llm-compressor pour Ada,
Hopper et certains chemins GPU AMD, tandis que GGUF présente un schéma de prise en charge
différent. A100 est un GPU Ampere et H100 est un GPU Hopper, mais la prise en charge est
spécifique à chaque méthode. Ne déduisez pas que chaque variante FP8, FP4 ou Marlin
fonctionne sur chaque carte d’une même famille. Vérifiez la ligne exacte dans le tableau de
compatibilité matérielle ainsi que les métadonnées propres au checkpoint.
Si vous n’avez pas encore sélectionné de modèle, comparez deux checkpoints candidats qui utilisent le même modèle de base et le même jeu d’évaluation. Comparer un modèle AWQ d’une famille avec un modèle non quantifié d’une autre brouillera la quantification vLLM avec la qualité du modèle.
Un workflow de déploiement qui évite les faux gains
- Définissez l’objectif de service. Consignez le modèle, la longueur de contexte, les longueurs attendues des entrées et sorties, les requêtes simultanées, l’objectif de latence p95 et les tests de qualité. Un chatbot, un classifieur par lots et un agent à contexte long présentent des goulots d’étranglement différents.
- Consignez la référence. Exécutez le checkpoint non quantifié sur le même GPU et la même version de vLLM. Relevez le pic de mémoire GPU, le délai avant le premier token, le débit de tokens de sortie, la latence p50/p95 de bout en bout, les erreurs et le taux de résultats acceptés.
- Choisissez un checkpoint quantifié compatible. Lisez sa fiche de modèle et la matrice de méthodes actuelle de vLLM. Épinglez la révision du checkpoint, la version de vLLM, la pile CUDA/pilotes et la référence matérielle dans le compte rendu de test.
- Commencez par un petit canari. Vérifiez que le modèle se charge, sert l’endpoint requis et les paramètres de génération, et produit des sorties plausibles avant d’appliquer du trafic.
- Effectuez des benchmarks à plusieurs niveaux de concurrence. Mesurez avec vos longueurs réelles de prompts et de réponses. Une requête unique peut favoriser une configuration différente d’un service soutenu.
- Exécutez la même suite de qualité. La quantification peut modifier les sorties. Évaluez l’exactitude spécifique au domaine, le respect du format, les refus et les cas sensibles pour la sécurité plutôt que de vous fier uniquement à la perplexité.
- Calculez le coût par résultat accepté. Le prix horaire du GPU divisé par le nombre brut de tokens par seconde ne suffit pas si le modèle quantifié échoue à davantage de tâches ou nécessite des tentatives supplémentaires.
Pour un benchmark de service, vLLM documente vllm bench serve
et ses jeux de données et options d’endpoint dans le guide officiel de la CLI
de benchmark. Utilisez un jeu de données de trafic correspondant à votre
application ; les prompts aléatoires synthétiques sont utiles pour des comparaisons
contrôlées, mais ne doivent pas être présentés comme des performances en production.
Planification de la mémoire : les poids ne sont qu’un poste parmi d’autres
Une simple feuille de planification distingue quatre catégories :
mémoire GPU totale nécessaire ≈ poids du modèle + cache KV + surcharge d’exécution/activations + marge de sécurité
Le format de quantification modifie principalement la part des poids du modèle. La pression sur le cache KV augmente avec la longueur du contexte et le nombre de séquences actives. Un modèle qui tient tout juste pour une requête peut tout de même échouer ou ralentir fortement avec un trafic concurrent à contexte long. Dans les configurations multi-GPU, le parallélisme tensoriel modifie à la fois la mémoire par carte et la surcharge de communication ; le point de contrôle le plus petit possible n’est pas automatiquement le déploiement le moins coûteux.
Avant de louer un GPU, demandez-vous si vous devez faire tenir un modèle plus grand, augmenter la concurrence pour un modèle plus petit, ou réduire les coûts tout en préservant la qualité. La réponse détermine quel compromis entre mémoire et débit est important. Le Cloud GPU Compute de Flatkey répertorie les options de location de GPU et demande aux clients de confirmer la configuration, la région, la capacité et les conditions de location. Considérez la disponibilité et le prix en temps réel comme des données à vérifier au moment du devis, et non comme des chiffres fixes dans un article de benchmark.
Évaluer équitablement la quantification vLLM
Conservez le modèle de base, les paramètres de génération, l’ensemble de prompts, la limite de sortie, l’état du cache et le GPU. Mesurez au moins trois charges : une requête unique pour la réactivité, une concurrence représentative de la production et un point de stress où la latence commence à se dégrader. Indiquez à la fois le débit total et la latence p95. Si vous ne communiquez que les tokens par seconde à saturation, les utilisateurs ne peuvent pas déterminer si les requêtes interactives restent acceptables.
Incluez la qualité du modèle dans le tableau d’évaluation :
| Mesure | Pourquoi c’est important |
|---|---|
| Mémoire GPU maximale | Indique si la quantification crée une marge utile. |
| Temps jusqu’au premier token | Important pour les interfaces de streaming. |
| Tokens de sortie par seconde | Indique le débit de génération, mais pas la qualité de la tâche. |
| Latence p95 de bout en bout | Révèle le comportement en queue de distribution sous charge. |
| Taux d’erreurs et d’OOM | Détecte une configuration qui ne semble rapide que lorsque les requêtes réussissent. |
| Taux de résultats acceptés | Transforme la vitesse brute en travail utile. |
La comparaison essentielle pour la quantification vLLM n’est pas, dans l’absolu, « quantifié contre non quantifié ». C’est « ce point de contrôle et ce kernel sur ce GPU, avec cette charge de travail, contre notre référence ». Publiez les conditions avec chaque résultat. Si votre test ne comprend pas de contrôle qualité, qualifiez-le d’expérience axée uniquement sur les performances.
Modes de défaillance courants
Le modèle ne se charge pas. Vérifiez les métadonnées du point de contrôle, la méthode de quantification, la version de vLLM, les capacités du GPU et si la méthode prend en charge toutes les couches utilisées par l’architecture. La matrice des méthodes vLLM doit être consultée avant de modifier aveuglément les options de commande.
Les économies de mémoire n’ont pas amélioré la latence. Une empreinte de poids plus faible ne garantit pas un kernel plus rapide. Testez à votre concurrence cible et inspectez le temps jusqu’au premier token, la vitesse de décodage et l’utilisation du GPU. Une marge plus importante pour le cache KV peut être le véritable avantage.
Un point de contrôle à faible nombre de bits semble rapide, mais échoue aux tests de qualité. Conservez un ensemble d’acceptation de production et mesurez le pourcentage de sorties qui répondent aux critères de votre application. Un seuil de retour en arrière doit être défini avant le canari.
Le benchmark ne peut pas être reproduit. Enregistrez les révisions du modèle et du point de contrôle, les versions de vLLM et du pilote, la référence GPU, le jeu de données, la concurrence, les longueurs des prompts, les longueurs de sortie et les arguments de commande. Sans cela, un chiffre de débit relève du marketing plutôt que d’une preuve d’ingénierie.
Quand utiliser Flatkey Cloud GPU
Si vous devez exécuter votre propre serveur vLLM et comparer des points de contrôle quantifiés, choisissez la capacité GPU en fonction d’exigences mesurées de mémoire et de concurrence. Flatkey fournit des options de location de GPU NVIDIA via Cloud GPU Compute. Confirmez la référence disponible, la région de déploiement, la capacité, les tarifs et les conditions de service avant de vous engager. Un test de quantification vLLM doit être effectué sur la configuration que vous avez réellement l’intention de louer. Si vous avez besoin d’une API de modèle gérée plutôt que d’exploiter vLLM, évaluez séparément la route API et le répertoire de modèles de Flatkey ; il s’agit d’un modèle d’exploitation différent.
Pour les décisions de déploiement connexes, consultez notre guide de déploiement vLLM, notre guide d’inférence vLLM multi-GPU et notre comparaison entre vLLM et Ollama.
FAQ
La quantification vLLM rend-elle toujours l’inférence plus rapide ?
Non. Elle peut réduire la mémoire des poids, mais la latence et le débit dépendent du point de contrôle, du kernel, du GPU, des longueurs de séquence et de la charge de requêtes. Comparez une charge de travail réelle à une référence.
Puis-je utiliser AWQ sur un A100 ou un H100 ?
La matrice de compatibilité vLLM actuelle indique la prise en charge d’AWQ pour Ampere et Hopper, qui incluent les A100 et H100. Vérifiez le point de contrôle exact, la version actuelle de vLLM et l’architecture du modèle avant le déploiement.
FP8 est-il pris en charge sur tous les GPU NVIDIA ?
Non. La prise en charge varie selon l’implémentation de quantification et l’architecture. La matrice actuelle distingue des méthodes telles que llm-compressor FP8 et Marlin ; vérifiez la ligne exacte correspondant à votre matériel.
Dois-je quantifier avant ou après avoir sélectionné un GPU ?
Dimensionnez d’abord la charge de travail et l’objectif de qualité, puis testez les checkpoints candidats sur des GPU compatibles. Le choix du format et du matériel doit être évalué conjointement.
