S4 KV
Compression de KV-cache int4 pour vLLM
Un backend de KV-cache vLLM v1 qui sert plus d’utilisateurs concurrents et un contexte plus long par GPU. Il quantifie le KV cache en int4 (KEY par canal, VALUE par token, style KIVI), bit-identical au décodage greedy fp16 — environ 3× plus de densité KV. Se lance comme endpoint vLLM compatible OpenAI clé en main via le template CloudFormation inclus.
S4 KV stocke le KV cache paged-attention vLLM v1 en int4 au lieu de fp16 avec une quantification de style KIVI, bit-identical au décodage greedy fp16 (vérifié sur Qwen2.5 1.5B/3B/7B et Llama-3.2-3B / 3.1-8B). Vous obtenez environ 3× plus de densité KV — plus de requêtes concurrentes et un contexte plus long sur le même GPU — sans perte de qualité mesurée. Les modèles pris en charge ont head_dim 128 avec attention standard (familles Qwen2.5 et Llama-3) ; le backend échoue vite au démarrage plutôt que de servir une sortie incorrecte pour un modèle non pris en charge. Tarif basé sur la densité et la qualité, pas la latence. Fonctionne sur les instances GPU g5, g6, g6e, p4d et p5.
Le problème
Lors du serving de LLM sur un GPU, le plafond de requêtes simultanées et de longueur de contexte utilisable est généralement dicté par la mémoire GPU consommée par le KV cache d'attention. Comme ce cache est conservé en fp16, il augmente rapidement à mesure que les requêtes et le contexte s'allongent, limitant le débit à moins d'ajouter des GPU plus grands et plus coûteux. Votre capacité par GPU se retrouve ainsi limitée par la mémoire plutôt que par le calcul.
Fonctionnement
- 1
Stocker le KV cache en int4
Un backend de KV cache pour la paged attention de vLLM v1 stocke le KV cache d'attention en int4 au lieu de fp16. Il utilise une quantification de type KIVI — int4 asymétrique par canal pour KEY et int4 par token pour VALUE.
- 2
Rester identique au bit près à fp16
Il est identique au bit près au décodage greedy en fp16, validé sur Qwen2.5 1.5B/3B/7B et Llama-3.2-3B / 3.1-8B. Cela permet d'obtenir environ 3x plus de densité de KV cache — plus de requêtes simultanées et un contexte plus long sur le même GPU — sans aucune perte de qualité mesurée.
- 3
Lancer un endpoint clé en main
L'image est fournie sous la forme d'un endpoint vLLM compatible OpenAI avec int4_kivi activé, lancé via le template CloudFormation inclus. Définissez ModelId sur un modèle head_dim-128 (par exemple Qwen/Qwen2.5-7B-Instruct) ; l'API est disponible sur le port 8000 à l'adresse /v1, avec le health check sur /health.
Points forts
Quantification int4 KIVI, bit-identical au décodage greedy fp16 (vérifié sur Qwen2.5 / Llama-3) — aucune perte de qualité mesurée.
~3× plus de densité KV : plus de requêtes concurrentes et un contexte plus long sur le même GPU.
Endpoint vLLM compatible OpenAI clé en main (CloudFormation inclus) ; échoue vite au démarrage sur un modèle non pris en charge.
Ce qui est inclus
- AMI GPU Ubuntu 22.04 (x86_64) — démarre directement un serveur vLLM compatible OpenAI avec int4_kivi activé
- Un backend de KV cache int4 pour la paged attention de vLLM v1 (style KIVI : int4 asymétrique par canal pour KEY, int4 par token pour VALUE)
- Environ 3x plus de densité de KV cache (plus de requêtes simultanées et un contexte plus long par GPU, sans perte de qualité mesurée)
- Correspondance identique au bit près avec le décodage greedy en fp16 (validé sur Qwen2.5 1.5B/3B/7B et Llama-3.2-3B / 3.1-8B, greedy match 1.0000)
- API compatible OpenAI (port 8000 à l'adresse /v1, health check à l'adresse /health) — lancée avec un ModelId de type head_dim-128
- Template CloudFormation (deploy/cfn-gpu-serving.yaml) — crée le groupe de sécurité et le rôle IAM, puis démarre le serveur vLLM OpenAI
- Validation du modèle au démarrage — prend en charge head_dim 128 avec attention standard (familles Qwen2.5 et Llama-3) ; les modèles non pris en charge échouent rapidement (fail-fast) au démarrage plutôt que de servir des sorties incorrectes
Cas d'usage
Serving limité par le KV cache où vous souhaitez gérer plus d'utilisateurs simultanés sur un seul GPU
Charges de travail nécessitant un contexte plus long par requête sans ajouter de GPU
Servir les familles Qwen2.5 ou Llama-3 (head_dim 128) derrière une API compatible OpenAI
Inférence sur GPU de datacenter où vous souhaitez une capacité (densité) plus élevée par GPU sans sacrifier la qualité
FAQ
Le format int4 nuit-il à la qualité de sortie ?
Il n'y a pas de perte de qualité mesurée. Le backend est validé comme étant identique au bit près au décodage greedy en fp16, avec une correspondance greedy de 1.0000 sur Qwen2.5 1.5B/3B/7B et Llama-3.2-3B / 3.1-8B. Vous obtenez environ 3x plus de densité de KV cache sans sacrifier la qualité.
Quels modèles sont pris en charge ?
Les modèles avec head_dim 128 et attention standard — les familles Qwen2.5 et Llama-3. Pour un modèle non pris en charge, le backend échoue rapidement (fail-fast) au démarrage plutôt que de servir des sorties incorrectes, de sorte qu'un modèle incompatible ne produit jamais silencieusement des résultats erronés.
Cela affecte-t-il la latence d'inférence ?
Il est optimisé pour la densité et la qualité, pas la latence. Pour les contextes longs sur les GPU de datacenter, le backend échange un peu de latence de décodage contre de la densité. Il est particulièrement adapté aux charges de travail visant à accroître les requêtes simultanées et à allonger le contexte par GPU, et nous présentons ce compromis en toute transparence.
Sur quelles instances GPU fonctionne-t-il ?
Il fonctionne sur les instances GPU g5, g6, g6e, p4d et p5. Choisissez l'instance en fonction du débit et de la taille du modèle dont vous avez besoin.
Comment puis-je le déployer ?
Lancez-le avec le template CloudFormation inclus (deploy/cfn-gpu-serving.yaml) : il crée le groupe de sécurité et le rôle IAM, puis démarre le serveur vLLM OpenAI avec int4_kivi activé. Définissez ModelId sur un modèle head_dim-128 (par exemple Qwen/Qwen2.5-7B-Instruct) ; l'API compatible OpenAI est disponible sur le port 8000 à l'adresse /v1, avec le health check sur /health.
Modèle de tarification
Frais logiciels horaires + GPU EC2 (g5 / g6 / g6e / p4d / p5). Facturation à l’usage par type d’instance.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch