S4 KV
vLLM용 int4 KV-cache compression
GPU당 더 많은 concurrent user와 더 긴 context를 제공하는 vLLM v1 KV-cache backend입니다. KV cache를 int4로 quantize(per-channel KEY, per-token VALUE, KIVI-style)하며 fp16 greedy decoding과 bit-identical입니다 — KV density가 약 3× 증가합니다. 포함된 CloudFormation template을 통해 turnkey OpenAI-compatible vLLM endpoint로 시작할 수 있습니다.
S4 KV는 vLLM v1 paged-attention KV cache를 fp16 대신 int4로 저장하는 backend입니다. KIVI-style quantization을 사용하며 fp16 greedy decoding과 bit-identical입니다(Qwen2.5 1.5B/3B/7B 및 Llama-3.2-3B / 3.1-8B에서 검증). 측정된 quality loss 없이 동일 GPU에서 대략 3× 더 높은 KV density — 더 많은 concurrent request와 더 긴 context — 를 얻습니다. 지원 model은 standard attention을 사용하는 head_dim 128(Qwen2.5 및 Llama-3 family)이며, unsupported model에 대해 잘못된 output을 제공하는 대신 startup 시 fail fast합니다. latency가 아니라 density와 quality 기준으로 pricing됩니다. g5, g6, g6e, p4d, p5 GPU instance에서 실행됩니다.
해결하고자 하는 과제
GPU에서 LLM을 제공할 때 동시 요청 수와 사용 가능한 컨텍스트 길이의 상한선은 대개 attention KV 캐시가 차지하는 GPU 메모리에 의해 결정됩니다. 이 캐시는 fp16으로 보관되므로 요청과 컨텍스트가 길어질수록 메모리를 빠르게 소비하여, 더 크고 고가의 GPU를 추가하지 않고서는 처리량을 늘릴 수 없습니다. 결국 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 quantization, fp16 greedy decoding과 bit-identical(Qwen2.5 / Llama-3에서 검증) — 측정된 quality loss 없음.
~3× 더 높은 KV density: 동일 GPU에서 더 많은 concurrent request와 더 긴 context.
Turnkey OpenAI-compatible vLLM endpoint(CloudFormation 포함). unsupported model은 startup 시 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) — head_dim-128 ModelId를 지정하여 실행
- CloudFormation 템플릿(deploy/cfn-gpu-serving.yaml) — 보안 그룹과 IAM 역할을 생성하고 vLLM OpenAI 서버를 기동
- 시작 시 모델 검증 — 표준 attention을 사용하는 head_dim 128 모델(Qwen2.5 및 Llama-3 제품군)을 지원하며, 미지원 모델은 잘못된 출력을 서빙하는 대신 기동 단계에서 fail-fast 처리
주요 활용 사례
단일 GPU에서 더 많은 동시 사용자를 처리하고자 하는 KV 캐시 메모리 제약형 서빙
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 모델에서 1.0000의 greedy match를 달성했습니다. 따라서 품질 희생 없이 약 3배 높은 KV 캐시 밀도를 얻을 수 있습니다.
어떤 모델을 지원하나요?
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)을 설정하면, 8000번 포트의 /v1에서 OpenAI 호환 API가 가동되며 /health에서 헬스체크를 제공합니다.
요금제 모델
시간당 software fee + GPU EC2(g5 / g6 / g6e / p4d / p5). instance type별 metered.
