S4 KV
面向 vLLM 的 int4 KV-cache compression
何時收回成本？
回收週期取決於成本項目和替換範圍
該產品的回收週期取決於您目前的 AWS 支出、替換範圍和執行環境。請使用帳單模擬器識別符合的成本項目並取得粗略的節省估算。
面向 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 的並行請求數和上下文長度為目標的工作負載，我們對這一權衡十分坦誠。
它可以在哪些 GPU 實例上執行？
它可以在 g5、g6、g6e、p4d 和 p5 GPU 實例上執行。請根據您需要的吞吐量和模型大小選擇合適的實例。
如何部署？
透過隨附的 CloudFormation 範本 (deploy/cfn-gpu-serving.yaml) 啟動：它將建立安全性群組 and IAM 角色，並啟動啟用了 int4_kivi 的 vLLM OpenAI 伺服器。將 ModelId 設定為 head_dim 128 的模型（例如 Qwen/Qwen2.5-7B-Instruct）；OpenAI 相容 API 位於連接埠 8000 的 /v1，健康檢查位於 /health。
為什麼更便宜
假設使用 vLLM 服務 70B 級 LLM，KV 快取是 GPU 顯示記憶體的瓶頸。
- g5.4xlarge × 3 隨需
- $3,560 / 月
- 月度合計
- $3,560 / 月
- g5.4xlarge × 1 + 軟體費
- $1,260 / 月
- 月度合計
- $1,260 / 月
依併發數 × 上下文長度選擇 S4 KV 執行個體
| 併發 × 上下文 | 推薦執行個體 | S4 KV 執行個體費用 | 每月合計對比 fp16 KV |
|---|---|---|---|
| 20 × 4k | g6.xlarge | $620 / 月 | $620 / 月 (fp16 $1,260, −51%) |
| 100 × 8k | g5.4xlarge | $1,260 / 月 | $1,260 / 月 (fp16 $3,560, −65%) |
| 300 × 32k | g6.12xlarge | $5,000 / 月 | $5,000 / 月 (fp16 $13,500, −63%) |
僅供參考。fp16 KV 快取隨上下文長度 × 併發線性增長，達到上限後需增加 GPU 執行個體。S4 KV 使用 int4 量化將有效 KV 密度提高約 3 倍，在更少 GPU 上達到相同吞吐量。輸出與 fp16 位元等價 (取決於模型)。EC2 部分使用 g5/g6 隨需價格，1 年 Savings Plan 可降低 30–40%。
計費模式
按小時計費的軟體費用 + GPU EC2（g5 / g6 / g6e / p4d / p5）。按 instance type 計量。
