AI・GPU

S4 KV

vLLM向け int4 KVキャッシュ圧縮

KV密度約3倍置き換え対象のAWSサービス: vLLM の fp16 KVキャッシュ

1GPUあたりの同時ユーザー数と文脈長を増やす、vLLM v1向けKVキャッシュバックエンド。KVキャッシュをint4に量子化(KEYはチャネル別・VALUEはトークン別、KIVI方式)し、fp16グリーディ復号とbit-identical — KV密度が約3倍になります。CloudFormationテンプレート同梱のOpenAI互換vLLMエンドポイントとしてすぐ起動。

S4 KV は、vLLM v1のpaged-attention KVキャッシュをfp16でなくint4で保持するバックエンドです。KIVI方式の量子化でfp16グリーディ復号とbit-identical(Qwen2.5 1.5B/3B/7B・Llama-3.2-3B / 3.1-8Bで検証済)、測定上の品質劣化なしに同一GPUでより多くの同時リクエストと長い文脈を捌けます。対応はhead_dim 128の標準アテンション(Qwen2.5 / Llama-3系)で、非対応モデルは誤出力を返すのでなく起動時にfail-fast。密度と品質に課金する設計(レイテンシではない)で、g5 / g6 / g6e / p4d / p5上で動作します。

課題

GPU で LLM を提供する際、同時リクエスト数と扱えるコンテキスト長の上限を決めるのは、多くの場合 attention の KV キャッシュが消費する GPU メモリです。KV キャッシュは fp16 で保持されるため、リクエストとコンテキストが長くなるほどメモリを急速に食い潰し、より大きく高価な GPU を追加しない限り処理量が頭打ちになります。1 枚の GPU あたりの収容能力が、計算性能ではなくメモリによって制約されてしまう点が課題です。

仕組み

1
KV キャッシュを int4 で保持

vLLM v1 の paged attention 向けの KV キャッシュバックエンドが、attention の KV キャッシュを fp16 ではなく int4 で保持します。KIVI 方式の量子化を用い、KEY はチャネル単位の非対称 int4、VALUE はトークン単位の int4 で格納します。
2
fp16 とビット一致を維持

greedy デコードにおいて fp16 とビット一致することを Qwen2.5 1.5B/3B/7B および Llama-3.2-3B / 3.1-8B で検証済みです。これにより、計測上の品質低下なしに KV キャッシュ密度が約 3 倍になり、同一 GPU でより多くの同時リクエストとより長いコンテキストを扱えます。
3
ターンキーのエンドポイントを起動

イメージは int4_kivi を有効化した OpenAI 互換の vLLM エンドポイントとして提供され、付属の CloudFormation テンプレートから起動します。ModelId に head_dim 128 のモデル（例：Qwen/Qwen2.5-7B-Instruct）を指定すると、ポート 8000 の /v1 で API が、/health でヘルスチェックが利用できます。

特長

int4 KIVI量子化でfp16グリーディ復号とbit-identical(Qwen2.5 / Llama-3で検証) — 測定上の品質劣化なし。

KV密度約3倍: 同一GPUで同時リクエスト数と文脈長を拡大。

ターンキーのOpenAI互換vLLMエンドポイント(CloudFormation同梱)。非対応モデルは起動時にfail-fast。

含まれるもの

Ubuntu 22.04 ベースの GPU AMI（x86_64）— int4_kivi を有効化した OpenAI 互換 vLLM サーバーをそのまま起動
vLLM v1 paged attention 向けの int4 KV キャッシュバックエンド（KIVI 方式：KEY はチャネル単位の非対称 int4、VALUE はトークン単位の 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）— ModelId に head_dim 128 のモデルを指定して起動
CloudFormation テンプレート（deploy/cfn-gpu-serving.yaml）— セキュリティグループと IAM ロールを作成し、vLLM OpenAI サーバーを起動
起動時のモデル検証 — head_dim 128 と標準 attention（Qwen2.5・Llama-3 ファミリ）に対応し、非対応モデルは誤った出力を返す前に起動時に fail-fast

こんな用途に

1 枚の GPU でより多くの同時ユーザーをさばきたい、KV キャッシュのメモリに制約されたサービング

GPU を増やさずにリクエストあたりのコンテキスト長を伸ばしたいワークロード

Qwen2.5 または Llama-3 ファミリ（head_dim 128）を OpenAI 互換 API で提供したいケース

品質を犠牲にせず、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）で起動します。テンプレートがセキュリティグループと IAM ロールを作成し、int4_kivi を有効化した vLLM OpenAI サーバーを開始します。ModelId に head_dim 128 のモデル（例：Qwen/Qwen2.5-7B-Instruct）を指定すると、OpenAI 互換 API がポート 8000 の /v1 で、ヘルスチェックが /health で利用できます。