S4 KV
int4 KV-Cache-Kompression für vLLM
Ein vLLM v1 KV-Cache-Backend, das mehr gleichzeitige Nutzer und längere Kontexte pro GPU ermöglicht. Es quantisiert den KV cache auf int4 (per-channel KEY, per-token VALUE, KIVI-Style), bit-identical zu fp16 greedy decoding — etwa 3× mehr KV-Dichte. Startet über das enthaltene CloudFormation-Template als schlüsselfertiger, OpenAI-kompatibler vLLM-Endpoint.
S4 KV speichert den vLLM v1 paged-attention KV cache mit KIVI-Style-Quantization in int4 statt fp16, bit-identical zu fp16 greedy decoding (verifiziert auf Qwen2.5 1.5B/3B/7B und Llama-3.2-3B / 3.1-8B). Sie erhalten ungefähr 3× mehr KV-Dichte — mehr gleichzeitige Requests und längeren Kontext auf derselben GPU — ohne gemessenen Qualitätsverlust. Unterstützte Modelle haben head_dim 128 mit Standard-Attention (Qwen2.5- und Llama-3-Familien); das Backend schlägt beim Start fail-fast fehl, statt für ein nicht unterstütztes Modell falsche Ausgabe zu liefern. Preisgestaltung nach Dichte und Qualität, nicht Latenz. Läuft auf g5-, g6-, g6e-, p4d- und p5-GPU-Instances.
Das Problem
Beim Bereitstellen von LLMs auf einer GPU ist die Obergrenze für gleichzeitige Anfragen und die nutzbare Kontextlänge in der Regel der durch den Attention-KV-Cache verbrauchte GPU-Speicher. Da dieser Cache in fp16 gehalten wird, wächst er bei längeren Anfragen und Kontexten schnell an und deckelt den Durchsatz, sofern Sie nicht größere, teurere GPUs hinzufügen. Ihre Kapazität pro GPU ist letztlich durch den Speicher und nicht durch die Rechenleistung begrenzt.
Funktionsweise
- 1
KV-Cache in int4 speichern
Ein KV-Cache-Backend für vLLM v1 Paged Attention speichert den Attention-KV-Cache in int4 anstelle von fp16. Es verwendet eine Quantisierung im KIVI-Stil — asymmetrisches int4 pro Kanal für KEY und int4 pro Token für VALUE.
- 2
Bitidentisch mit fp16 bleiben
Es ist bitidentisch mit fp16 Greedy Decoding, verifiziert auf Qwen2.5 1.5B/3B/7B und Llama-3.2-3B / 3.1-8B. Dies führt zu einer etwa 3x höheren KV-Cache-Dichte — mehr gleichzeitige Anfragen und längere Kontexte auf derselben GPU — ohne messbaren Qualitätsverlust.
- 3
Schlüsselfertigen Endpunkt starten
Das Image wird als OpenAI-kompatibler vLLM-Endpunkt mit aktiviertem int4_kivi bereitgestellt, der über das mitgelieferte CloudFormation-Template gestartet wird. Setzen Sie die ModelId auf ein Modell mit head_dim 128 (z. B. Qwen/Qwen2.5-7B-Instruct); die API is auf Port 8000 unter /v1 erreichbar, der Health-Check unter /health.
Highlights
int4 KIVI Quantization, bit-identical zu fp16 greedy decoding (verifiziert auf Qwen2.5 / Llama-3) — kein gemessener Qualitätsverlust.
~3× mehr KV-Dichte: mehr gleichzeitige Requests und längerer Kontext auf derselben GPU.
Schlüsselfertiger OpenAI-kompatibler vLLM-Endpoint (CloudFormation enthalten); fail-fast beim Start bei einem nicht unterstützten Modell.
Lieferumfang
- Ubuntu 22.04 GPU-AMI (x86_64) — startet einen OpenAI-kompatiblen vLLM-Server mit aktiviertem int4_kivi out of the box
- Ein int4-KV-Cache-Backend für vLLM v1 Paged Attention (KIVI-Stil: asymmetrisches int4 pro Kanal für KEY, int4 pro Token für VALUE)
- Etwa 3x KV-Cache-Dichte (mehr gleichzeitige Anfragen und längerer Kontext pro GPU, ohne messbaren Qualitätsverlust)
- Bitidentische Übereinstimmung mit fp16 Greedy Decoding (verifiziert auf Qwen2.5 1.5B/3B/7B und Llama-3.2-3B / 3.1-8B, Greedy-Match 1.0000)
- OpenAI-kompatible API (Port 8000 unter /v1, Health-Check unter /health) — gestartet mit einer head_dim-128-ModelId
- CloudFormation-Template (deploy/cfn-gpu-serving.yaml) — erstellt die Security Group und die IAM-Rolle und startet den vLLM OpenAI-Server
- Modellvalidierung beim Start — unterstützt head_dim 128 mit Standard-Attention (Qwen2.5- und Llama-3-Familien); nicht unterstützte Modelle brechen beim Start per Fail-Fast ab, anstatt fehlerhafte Ausgaben zu liefern
Anwendungsfälle
KV-Cache-gebundenes Serving, bei dem Sie mehr gleichzeitige Benutzer auf einer einzelnen GPU verarbeiten möchten
Workloads, die eine längere Kontextlänge pro Anfrage erfordern, ohne zusätzliche GPUs hinzuzufügen
Bereitstellung der Qwen2.5- oder Llama-3-Familien (head_dim 128) hinter einer OpenAI-kompatiblen API
Datacenter-GPU-Inferenz, bei der Sie eine höhere Kapazität (Dichte) pro GPU erzielen möchten, ohne die Qualität zu beeinträchtigen
FAQ
Verschlechtert int4 die Ausgabequalität?
Es gibt keinen messbaren Qualitätsverlust. Das Backend ist nachweislich bitidentisch mit fp16 Greedy Decoding, mit einem Greedy-Match von 1.0000 auf Qwen2.5 1.5B/3B/7B und Llama-3.2-3B / 3.1-8B. Sie erhalten eine etwa 3x höhere KV-Cache-Dichte, ohne die Qualität zu beeinträchtigen.
Welche Modelle werden unterstützt?
Modelle mit head_dim 128 und Standard-Attention — die Qwen2.5- und Llama-3-Familien. Bei einem nicht unterstützten Modell bricht das Backend beim Start per Fail-Fast ab, anstatt fehlerhafte Ergebnisse zu liefern, sodass ein inkompatibles Modell niemals unbemerkt falsche Resultate erzeugt.
Hat dies Auswirkungen auf die Inferenzlatenz?
Es ist auf Dichte und Qualität optimiert, nicht auf Latenz. Bei langen Kontexten auf Datacenter-GPUs tauscht das Backend etwas Dekodierlatenz gegen Dichte ein. Es eignet sich am besten für Workloads, deren Ziel mehr gleichzeitige Anfragen und ein längerer Kontext pro GPU sind, und wir kommunizieren diesen Kompromiss offen.
Auf welchen GPU-Instanzen läuft es?
Es läuft auf den GPU-Instanzen g5, g6, g6e, p4d und p5. Wählen Sie die Instanz passend zu dem von Ihnen benötigten Durchsatz und der Modellgröße.
Wie wird es bereitgestellt?
Starten Sie es mit dem mitgelieferten CloudFormation-Template (deploy/cfn-gpu-serving.yaml): Es erstellt die Security Group sowie die IAM-Rolle und startet den vLLM-OpenAI-Server mit aktiviertem int4_kivi. Setzen Sie ModelId auf ein Modell mit head_dim 128 (z. B. Qwen/Qwen2.5-7B-Instruct); die OpenAI-kompatible API ist auf Port 8000 unter /v1 erreichbar, der Health-Check unter /health.
Preismodell
Stündliche Softwaregebühr + GPU EC2 (g5 / g6 / g6e / p4d / p5). Abrechnung nach Instance Type.
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern