AI & GPU

S4 KV

面向 vLLM 的 int4 KV-cache compression

KV 密度 ~3× 替换的 AWS 服务: vLLM 中的 fp16 KV 缓存

面向 vLLM v1 的 KV-cache backend，可让每个 GPU 服务更多并发用户和更长 context。它将 KV cache 量化为 int4（per-channel KEY、per-token VALUE，KIVI-style），与 fp16 greedy decoding bit-identical — KV density 约提升 3×。通过内置 CloudFormation template，一键启动为 OpenAI-compatible vLLM endpoint。

S4 KV 使用 KIVI-style quantization，将 vLLM v1 paged-attention KV cache 以 int4 而不是 fp16 存储，并与 fp16 greedy decoding bit-identical（已在 Qwen2.5 1.5B/3B/7B 和 Llama-3.2-3B / 3.1-8B 上验证）。在同一 GPU 上获得约 3× 更高 KV density — 更多并发请求和更长 context — 且没有测得质量损失。支持模型为 head_dim 128 且使用 standard attention（Qwen2.5 与 Llama-3 系列）；对于不支持的模型，backend 会在启动时 fail fast，而不是提供错误输出。按 density 和 quality 定价，而不是 latency。运行于 g5、g6、g6e、p4d 和 p5 GPU instances。

面临挑战

在 GPU 上部署 LLM 时，并发请求数和可用上下文长度的上限通常取决于 attention KV 缓存所消耗 of GPU 内存。由于该缓存以 fp16 格式保存，随着请求和上下文变长，它会迅速消耗内存，除非添加更大、更昂贵的 GPU，否则会限制吞吐量。这导致单张 GPU 的承载能力最终受限于内存而非算力。

工作原理

1
以 int4 格式存储 KV 缓存

用于 vLLM v1 paged attention 的 KV 缓存后端将 attention KV 缓存以 int4 格式（而非 fp16）进行存储。它采用 KIVI 方式的量子化 —— KEY 采用每通道非对称 int4，VALUE 采用每 token 的 int4。
2
与 fp16 保持比特完全一致

在 greedy 解码中与 fp16 保持比特完全一致，已在 Qwen2.5 1.5B/3B/7B 和 Llama-3.2-3B / 3.1-8B 上进行验证。这带来了约 3 倍的 KV 缓存密度提升 —— 在相同的 GPU 上支持更多的并发请求和更长的上下文，且无测量上的质量损失。
3
启动开箱即用的端点

该镜像作为启用了 int4_kivi 的 OpenAI 兼容 vLLM 端点交付，可通过附带的 CloudFormation 模板启动。将 ModelId 设置为 head_dim 128 的模型（例如 Qwen/Qwen2.5-7B-Instruct）；API 位于端口 8000 的 /v1，健康检查位于 /health。

产品亮点

int4 KIVI quantization，与 fp16 greedy decoding bit-identical（已在 Qwen2.5 / Llama-3 上验证）— 没有测得质量损失。

约 3× 更高 KV density：同一 GPU 上更多并发请求和更长 context。

Turnkey OpenAI-compatible vLLM endpoint（包含 CloudFormation）；遇到不支持的模型会在启动时 fail fast。

包含内容

Ubuntu 22.04 GPU AMI (x86_64) — 开箱即用启动启用了 int4_kivi 的 OpenAI 兼容 vLLM 服务器
用于 vLLM v1 paged attention 的 int4 KV 缓存后端（KIVI 方式：KEY 采用每通道非对称 int4，VALUE 采用每 token 的 int4）
约 3 倍的 KV 缓存密度（在同一张 GPU 上支持更多并发请求和更长上下文，且无测量上的质量损失）
与 fp16 greedy 解码比特完全一致（已在 Qwen2.5 1.5B/3B/7B 和 Llama-3.2-3B / 3.1-8B 上进行验证，greedy match 1.0000）
OpenAI 兼容 API（端口 8000 的 /v1，健康检查为 /health）— 启动时指定 head_dim 128 的 ModelId
CloudFormation 模板 (deploy/cfn-gpu-serving.yaml) — 创建安全组和 IAM 角色并启动 vLLM OpenAI 服务器
启动时模型验证 — 支持 head_dim 128 的标准 attention（Qwen2.5 和 Llama-3 系列）；不支持的模型在启动时会 fail-fast，而不是输出错误的结果

适用场景

受 KV 缓存内存限制，且希望在单张 GPU 上承载更多并发用户的服务场景

在不增加 GPU 的情况下，需要延长每个请求的上下文长度的工作负载

希望在 OpenAI 兼容 API 后部署 Qwen2.5 或 Llama-3 系列（head_dim 128）的场景

希望在不牺牲质量的情况下提高单张 GPU 承载能力（密度）的数据中心 GPU 推理

常见问题

使用 int4 会降低输出质量吗？

没有任何可测量的质量损失。该后端已验证与 fp16 greedy 解码比特完全一致，在 Qwen2.5 1.5B/3B/7B 以及 Llama-3.2-3B / 3.1-8B 上确认 greedy match 为 1.0000。因此，您可以在不牺牲质量的情况下将 KV 缓存密度提升约 3 倍。

支持哪些模型？

支持 head_dim 128 且采用标准 attention 的模型 — 即 Qwen2.5 系列和 Llama-3 系列。对于不支持的模型，该后端在启动时会 fail-fast，而不是返回错误输出，因此不兼容的模型绝不会静默输出错误结果。

会影响推理延迟吗？

本产品针对密度和质量进行了优化，而非延迟。在数据中心 GPU 上的长上下文下，该后端会牺牲一部分解码延迟来换取密度。它最适合以增加单张 GPU 的并发请求数 and 上下文长度为目标的工作负载，我们对这一权衡十分坦诚。

它可以在哪些 GPU 实例上运行？

它可以在 g5、g6、g6e、p4d 和 p5 GPU 实例上运行。请根据您需要的吞吐量和模型大小选择合适的实例。

如何部署？

通过附带的 CloudFormation 模板 (deploy/cfn-gpu-serving.yaml) 启动：它将创建安全组和 IAM 角色，并启动启用了 int4_kivi 的 vLLM OpenAI 服务器。将 ModelId 设置为 head_dim 128 的模型（例如 Qwen/Qwen2.5-7B-Instruct）；OpenAI 兼容 API 位于端口 8000 的 /v1，健康检查位于 /health。