S4 KV
Compressão de KV-cache int4 para vLLM
Um backend de KV-cache para vLLM v1 que atende mais usuários simultâneos e contextos mais longos por GPU. Ele quantiza o KV cache para int4 (KEY por canal, VALUE por token, estilo KIVI), bit-identical à decodificação greedy fp16 — cerca de 3× mais densidade de KV. Inicializa como endpoint vLLM turnkey compatível com OpenAI via o template CloudFormation incluído.
S4 KV armazena o KV cache de paged-attention do vLLM v1 em int4 em vez de fp16 usando quantização estilo KIVI, bit-identical à decodificação greedy fp16 (verificado em Qwen2.5 1.5B/3B/7B e Llama-3.2-3B / 3.1-8B). Você obtém aproximadamente 3× mais densidade de KV — mais requests simultâneos e contexto mais longo na mesma GPU — sem perda de qualidade medida. Os modelos compatíveis têm head_dim 128 com atenção padrão (famílias Qwen2.5 e Llama-3); o backend falha rápido na inicialização em vez de servir saída incorreta para um modelo não compatível. Preço baseado em densidade e qualidade, não em latência. Roda em instâncias GPU g5, g6, g6e, p4d e p5.
O problema
Ao servir LLMs em uma GPU, o limite para requisições simultâneas e comprimento de contexto utilizável geralmente é a memória da GPU consumida pelo cache KV de attention. Como esse cache é mantido em fp16, ele cresce rapidamente à medida que as requisições e o contexto aumentam, limitando o throughput a menos que você adicione GPUs maiores e mais caras. Sua capacidade por GPU acaba limitada pela memória, e não pela computação.
Como funciona
- 1
Armazene o cache KV em int4
Um backend de cache KV para paged attention do vLLM v1 armazena o cache KV de attention em int4 em vez de fp16. Ele usa quantização no estilo KIVI — int4 assimétrico por canal para KEY e int4 por token para VALUE.
- 2
Permaneça idêntico em bits ao fp16
É idêntico em bits à decodificação greedy em fp16, verificado no Qwen2.5 1.5B/3B/7B e Llama-3.2-3B / 3.1-8B. Isso resulta em cerca de 3x mais densidade de cache KV — mais requisições simultâneas e contexto mais longo na mesma GPU — sem perda de qualidade medida.
- 3
Inicie um endpoint pronto para uso
A imagem é fornecida como um endpoint vLLM compatível com OpenAI com int4_kivi ativado, iniciado via template do CloudFormation incluso. Defina ModelId para um modelo head_dim-128 (ex: Qwen/Qwen2.5-7B-Instruct); a API está na porta 8000 em /v1, com health em /health.
Destaques
Quantização int4 KIVI, bit-identical à decodificação greedy fp16 (verificada em Qwen2.5 / Llama-3) — sem perda de qualidade medida.
~3× mais densidade de KV: mais requests simultâneos e contexto mais longo na mesma GPU.
Endpoint vLLM turnkey compatível com OpenAI (CloudFormation incluído); falha rápido na inicialização em um modelo não compatível.
O que está incluído
- AMI de GPU com Ubuntu 22.04 (x86_64) — inicializa um servidor vLLM compatível com OpenAI com int4_kivi ativado pronto para uso
- Um backend de cache KV em int4 para paged attention do vLLM v1 (estilo KIVI: int4 assimétrico por canal para KEY, int4 por token para VALUE)
- Cerca de 3x mais densidade de cache KV (mais requisições simultâneas e contexto mais longo por GPU, sem perda de qualidade medida)
- Correspondência idêntica em bits com a decodificação greedy em fp16 (verificado em Qwen2.5 1.5B/3B/7B e Llama-3.2-3B / 3.1-8B, greedy match 1.0000)
- API compatível com OpenAI (porta 8000 em /v1, health em /health) — iniciada com um ModelId head_dim-128
- Template do CloudFormation (deploy/cfn-gpu-serving.yaml) — cria o security group e a role do IAM e inicia o servidor vLLM OpenAI
- Validação do modelo na inicialização — suporta head_dim 128 com attention padrão (famílias Qwen2.5 e Llama-3); modelos não suportados falham rapidamente na inicialização em vez de fornecer saídas incorretas
Casos de uso
Serviço de inferência limitado pelo cache KV onde você deseja atender mais usuários simultâneos em uma única GPU
Workloads que necessitam de contexto mais longo por requisição sem a adição de GPUs
Hospedagem das famílias Qwen2.5 ou Llama-3 (head_dim 128) atrás de uma API compatível com OpenAI
Inferência em GPUs de datacenter onde você deseja maior capacidade (densidade) por GPU sem sacrificar a qualidade
FAQ
O int4 prejudica a qualidade da saída?
Não há perda de qualidade medida. O backend foi verificado como idêntico em bits à decodificação greedy em fp16, com um greedy match de 1.0000 no Qwen2.5 1.5B/3B/7B e Llama-3.2-3B / 3.1-8B. Você obtém cerca de 3x mais densidade de cache KV sem sacrificar a qualidade.
Quais modelos são suportados?
Modelos com head_dim 128 e attention padrão — as famílias Qwen2.5 e Llama-3. Para um modelo não suportado, o backend falha rapidamente na inicialização em vez de fornecer saídas incorretas, de forma que um modelo incompatível nunca produzirá resultados incorretos silenciosamente.
Isso afeta a latência de inferência?
Ele é precificado com base na densidade e qualidade, não na latência. Em contextos longos em GPUs de datacenter, o backend troca um pouco da latência de decodificação por densidade. Ele é mais adequado para workloads cujo objetivo é mais requisições simultâneas e maior contexto por GPU, e somos transparentes sobre essa troca.
Em quais instâncias de GPU ele roda?
Ele roda em instâncias de GPU g5, g6, g6e, p4d e p5. Escolha a instância de acordo com o throughput e o tamanho do modelo que você precisa.
Como implantá-lo?
Inicie-o com o template do CloudFormation incluso (deploy/cfn-gpu-serving.yaml): ele cria o security group e a role do IAM e inicia o servidor vLLM OpenAI com int4_kivi ativado. Defina ModelId para um modelo head_dim-128 (ex: Qwen/Qwen2.5-7B-Instruct); a API compatível com OpenAI fica na porta 8000 em /v1, com health em /health.
Modelo de precificação
Taxa horária de software + GPU EC2 (g5 / g6 / g6e / p4d / p5). Cobrança por tipo de instância.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch