한 줄 정의

FP8 KV는 LLM이 다음 토큰을 만들 때 다시 읽는 KV 캐시를 FP8 8비트 부동소수점 형식으로 저장하거나, FP8 attention 경로에서 계산하게 하는 실행 설정이야. 모델 가중치가 FP8이라는 뜻과는 달라. 가중치는 FP8인데 캐시는 BF16 KV일 수도 있고, 가중치는 BF16인데 캐시만 FP8로 줄일 수도 있어.

먼저 숫자부터 보면 감이 와. BF16은 원소 하나가 2바이트고 FP8은 1바이트라서, 같은 key/value 값을 같은 개수만큼 저장하면 FP8 KV가 raw dtype 폭 기준으로 절반이야. 그래서 긴 컨텍스트 윈도우나 여러 동시 요청에서 GPU VRAM 사용량을 줄이는 선택지가 된다.

다만 이건 “공짜로 긴 문맥이 좋아진다”는 말이 아니야. KV 캐시는 생성 중 계속 다시 읽히는 값이라서, 스케일 보정, 어텐션 실행 경로, 모델 구조, 실제 프롬프트 길이에 따라 품질 회귀가 생길 수 있어. FP8 KV는 메모리와 생성 비용을 줄이는 선택지이고, 품질 기준선은 여전히 BF16 KV와 나란히 재야 해.

어떻게 작동하나

토큰을 하나 생성할 때 모델은 앞 토큰들의 key와 value를 다시 참고해. KV 캐시는 이 값을 저장해 두었다가 다음 토큰에서 재사용하는 내부 메모리야. Hugging Face 블로그는 Llama-2 7B 예시에서 10,000 token의 KV cache가 2 * 2 * 32 * 32 * 128 * 10000 계산으로 약 5GB가 될 수 있다고 보여 줘. 모델 파일만 GPU에 올리는 문제가 아니라, 문맥이 길어질수록 캐시가 따로 커지는 구조라는 뜻이야.

vLLM에서는 --kv-cache-dtype fp8 설정으로 이 캐시를 FP8로 둘 수 있어. vLLM Quantized KV Cache 문서는 per-tensor scale과 per-attention-head scale을 나눠 설명하고, scale을 잡는 방식도 세 가지로 갈라. 무보정이면 scale을 1.0으로 두고, warmup 중 random token에서 scale을 잡을 수도 있고, llm-compressor로 calibration dataset을 써서 scale을 추정할 수도 있어.

여기서 중요한 건 FP8 KV가 단순 파일 압축이 아니라는 점이야. vLLM의 2026년 4월 22일 블로그는 이 캐시 dtype을 켜면 KV cache 양자화와 QK·ScoreV attention matmul이 함께 FP8 경로를 탄다고 설명해. FA3 경로에서는 query까지 FP8로 양자화될 수 있으니, 실제 결과는 “캐시 저장량”과 “attention kernel”을 같이 봐야 해.

왜 중요한가

FP8 KV가 중요한 이유는 긴 문맥 서빙이 자주 메모리 병목으로 바뀌기 때문이야. vLLM 블로그는 full-attention decoder에서 128k 이상 context가 되면 KV cache가 GPU memory를 크게 차지하고, decode 단계에서 매 토큰마다 캐시의 큰 부분을 읽어야 한다고 설명해. 이때 FP8 KV는 캐시 저장량과 메모리 트래픽을 줄여서 더 긴 문맥, 더 높은 동시성, 낮은 decode 지연을 노릴 수 있어.

숫자로 보면 장점이 꽤 분명해. vLLM의 H100 단일 요청 Llama-3.1-8B 실험에서 FP8의 ITL slope는 BF16의 54%였고, decode break-even은 약 7,010 tokens로 내려갔어. 동시성 8, 약 20k 입력 토큰과 약 2k 출력 토큰 조건의 처리량 실험에서는 output throughput이 14.9% 높아졌다고 보고돼. 이건 “짧은 질문 하나가 무조건 빨라진다”가 아니라, 긴 문맥에서 캐시 읽기가 병목일 때 이득이 커진다는 뜻이야.

Blackwell 쪽도 같은 식으로 봐야 해. 같은 vLLM 블로그는 B200과 FlashInfer 조합에서 Llama-3.1-8B FP8 decode break-even을 약 4k tokens로 제시하지만, gpt-oss 20b는 약 13k tokens라고 나눠 적어. GPU 세대가 좋아졌다고 모든 모델의 FP8 KV 판단이 같아지는 건 아니야.

BF16 KV와 어디서 갈리나

BF16 KV는 캐시를 16비트로 남기는 보수적인 기준선이야. 메모리는 더 쓰지만, 긴 코딩 에이전트 작업이나 도구 호출처럼 앞 문맥의 작은 차이가 뒤 행동을 바꾸는 작업에서는 먼저 비교해야 할 기준점이 된다. 반대로 FP8 KV는 캐시를 줄여서 더 긴 문맥이나 더 많은 동시 요청을 밀어 넣는 선택이야.

Reddit의 LocalLLaMA 논의는 이 차이가 왜 실제로 헷갈리는지 잘 보여 줘. 원문 작성자는 Qwen3.6 27B FP8 safetensors를 vLLM에서 두 장의 RTX 3090으로 돌리며 긴 문맥을 쓰는 코딩 에이전트 실행 환경을 운영했고, KV를 FP8로 두면 작은 실수와 도구 호출 문제가 늘었다고 썼어. 그러면서 16비트 KV로 고정했을 때 더 믿고 쓸 수 있었다고 느꼈다고 해.

이 글은 공식 벤치마크가 아니야. 하지만 좋은 경고는 돼. 같은 스레드에서도 FP8 KV와 Q8 KV를 구분해야 한다는 댓글이 이어지고, 어떤 사용자는 200K 문맥에서 Q8 KV가 BF16보다 훨씬 빠르다고 보고해. 결론은 “FP8 KV는 나쁘다”가 아니라, 같은 모델, 같은 프롬프트 묶음, 같은 실행 경로에서 BF16 KV와 FP8 KV를 직접 비교해야 한다는 쪽이야.

vLLM 블로그도 같은 방향이야. 예전 Hopper FA3 경로에서는 128k needle-in-a-haystack에서 FP8 accuracy가 91% BF16 기준선에서 13%까지 떨어진 사례가 있었고, 2단 누산 수정 뒤 89%로 회복됐다고 설명해. FP8 KV가 쓸 만해졌다는 최신 주장은 이런 kernel fix와 검증 경로까지 포함해서 읽어야 해.

주의해서 볼 점

첫째, 짧은 문맥에서는 FP8 KV가 이득이 아닐 수 있어. vLLM은 context가 약 7k tokens보다 짧으면 FP8의 고정 overhead 때문에 BF16이 ITL에서 더 나을 수 있다고 적어. 짧은 챗봇 요청만 처리한다면 먼저 BF16 기준선과 실제 p50·p95 지연시간을 재는 게 맞아.

둘째, 입력 채우기가 무거운 작업과 생성이 무거운 작업을 나눠 봐야 해. 긴 문서를 처음 넣는 prefill은 입력 길이의 영향을 크게 받고, 이미 긴 문맥을 들고 다음 토큰을 계속 만드는 decode는 KV cache 읽기 비용이 크게 들어와. vLLM은 head_dim = 256 모델에서 2단 누산 때문에 긴 문맥 TTFT가 BF16보다 약 1.6x 나빠질 수 있다고 적어. FP8 decode가 빨라도 첫 토큰 대기가 길어지면 실제 사용감은 나빠질 수 있어.

셋째, hybrid attention 모델은 레이어별로 다르게 볼 수 있어. gpt-oss 20b처럼 고정 window 레이어가 섞인 모델에서는 작은 window 범위를 FP8로 줄여도 긴 문맥 이득이 잘 나오지 않고 overhead만 남을 수 있어. vLLM은 이런 경우 skip-layers 설정으로 해당 레이어는 BF16으로 남기는 경로를 제시해.

실무에서는 FP8 KV를 켜기 전에 아래 항목을 같은 표에 넣어야 해.

  • 모델 가중치 dtype과 KV cache dtype
  • 어텐션 실행 경로와 GPU 세대: H100, H200, B200, FA3, FlashInfer 등
  • max-model-len, 실제 프롬프트 토큰, 출력 토큰
  • prefill TTFT, decode ITL, output tok/s, 최대 GPU VRAM
  • 무보정 scale인지, random token calibration인지, dataset calibration인지
  • 코딩 작업, 도구 호출, 긴 문맥 검색 같은 실제 작업 정확도

FP8 KV는 긴 문맥 서빙에서 검토할 만한 설정이야. 대신 품질 검증을 빼고 “캐시가 절반이니 무조건 좋다”로 읽으면 위험해. 좋은 적용 순서는 BF16 KV 기준선을 먼저 재고, FP8 KV를 켠 뒤 같은 작업에서 속도와 품질을 같이 비교하는 쪽이야.