BitDecoding-FP4: 네이티브 FP4 KV 캐시 디코딩
긴 컨텍스트 LLM 서빙에서 KV 캐시는 GPU 메모리 용량과 대역폭을 동시에 차지합니다. NVFP4, MXFP4 같은 4비트 microscaling 포맷은 캐시를 줄이고 attention을 FP4 Tensor Core에서 실행할 수 있게 합니다. 그러나 기존 FP4 KV 시스템은 단순 양자화를 써서 정확도 손실이 크고, 정확도를 중시하는 4비트 알고리즘은 벡터 코드북에 의존해 테이블 조회 오버헤드가 디코딩 처리량을 떨어뜨립니다. BitDecoding-FP4는 알고리즘과 시스템의 공동 설계로 이 간극을 메웁니다. 알고리즘은 세 가지입니다. Dual-Residual Query Quantization은 query를 두 개의 FP4 텐서로 나눠 query logit 오차를 60%에서 1%로 낮춥니다. Underflow-Aware Probability Scaling은 E4M3 scale이 긴 컨텍스트의 확률을 0으로 반올림하는 것을 막습니다. Outlier-Aware Key Quantization은 정적 스무딩, Hadamard 회전, scale 탐색을 결합해 key 이상치를 억제합니다. 시스템 측면에서는 전치 softmax, 융합된 확률 양자화, paged KV 캐시용 스택형 query MMA로 softmax 병목을 없앱니다. 밀집 모델과 MoE, GQA와 MLA 구조 전반에서 NVFP4 정확도는 BF16 KV와 0.5점 이내, MXFP4는 1점 이내이며, RL 학습 rollout에서도 BF16 KV를 따라갑니다. NVIDIA B300에서 Qwen3-4B와 Qwen3-30B-A3B를 서빙할 때 최대 처리량은 BF16 KV보다 2.4~3.0배 높습니다.
배경
긴 컨텍스트 LLM 서빙에서 KV 캐시는 GPU 자원을 가장 많이 쓰는 항목 중 하나입니다. 캐시는 메모리 용량을 차지하고, 디코딩 단계마다 전체를 다시 읽기 때문에 메모리 대역폭도 소모합니다. 컨텍스트가 길어지거나 동시 요청이 늘어나면 두 비용이 함께 커집니다.
자연스러운 해법은 캐시를 4비트로 줄이는 것입니다. NVFP4, MXFP4 같은 4비트 microscaling 포맷은 캐시 크기를 줄이고, attention을 FP4 Tensor Core에서 바로 실행하게 해 역양자화 우회 경로를 없앱니다. 그러나 BitDecoding-FP4 논문은 알고리즘 연구와 시스템 가속 사이에 간극이 있다고 지적합니다. 기존 FP4 KV 시스템은 단순 양자화를 써서 속도는 얻지만 정확도가 크게 떨어집니다. 정확도를 중시하는 4비트 알고리즘은 벡터 코드북에 의존하며, 테이블 조회 오버헤드가 디코딩 처리량을 떨어뜨립니다.
BitDecoding-FP4는 이 간극을 메우려는 알고리즘·시스템 공동 설계입니다. 목표는 정확하면서 빠른 네이티브 FP4 KV 디코딩입니다. 저자들은 오차의 원인을 query, 확률, key 세 곳으로 나눠 각각 다루고, 시스템 수준에서 softmax 병목을 제거합니다. 밀집 모델과 MoE, GQA와 MLA 구조에서 검증했고 구현은 GitHub에 공개되어 있습니다.
심층 분석
첫 번째 기법은 Dual-Residual Query Quantization입니다. 네이티브 FP4 연산에서는 query도 양자화해야 하는데, FP4 한 번으로는 query logit에 큰 오차가 남습니다. 저자들은 query를 두 개의 FP4 텐서로 나누고, 두 번째 텐서가 첫 번째의 잔차를 보정하게 했습니다. 초록에 따르면 이로써 query logit 오차가 60%에서 1%로 줄어듭니다. 두 번째는 Underflow-Aware Probability Scaling입니다. 긴 컨텍스트에서는 softmax 확률 하나하나가 매우 작습니다. 확률을 양자화할 때 쓰는 E4M3 scale이 0으로 반올림되면 블록 전체의 확률이 0이 되고, 이후 value와의 곱셈·누산에서 정보가 사라집니다. 이 기법은 확률의 스케일링을 조정해 이런 언더플로를 막습니다. 세 번째는 Outlier-Aware Key Quantization입니다. key 텐서에는 이상치가 있어, token-wise scaling에서는 이상치 하나가 해당 토큰 전체의 양자화 범위를 넓혀 다른 채널의 정밀도를 해칩니다. 저자들은 정적 스무딩, Hadamard 회전, scale 탐색을 결합했습니다. 스무딩과 회전이 이상치의 에너지를 분산시키고, scale 탐색이 그룹마다 더 알맞은 스케일을 고릅니다.
BitDecoding-FP4는 softmax 병목을 어떻게 없앨까요? 전치 softmax와 융합된 확률 양자화를 함께 써서, 확률 양자화가 별도의 메모리 읽기·쓰기를 요구하지 않게 했습니다. paged KV 캐시에는 스택형 query MMA를 적용해 행렬곱 유닛을 더 충분히 활용합니다. 정확도는 BF16 KV 대비로 보고됩니다. NVFP4는 0.5점 이내, MXFP4는 1점 이내입니다. RL 학습 rollout에서도 BF16 KV를 따라갑니다. KV 양자화로 분포가 크게 바뀌면 학습 신호가 흔들릴 수 있어, 민감한 검증입니다. 초록은 벤치마크 이름을 밝히지 않아 격차만 옮깁니다.
산업 영향
성능은 NVIDIA B300에서 Qwen3-4B(소형 밀집 모델)와 Qwen3-30B-A3B(MoE 모델)를 대상으로 종단 간 서빙으로 측정했습니다. 최대 처리량은 BF16 KV보다 2.4~3.0배 높습니다. 캐시가 작아지면 같은 카드에 더 긴 컨텍스트나 더 많은 동시 요청을 담을 수 있고, 처리량 상승은 같은 하드웨어에서 토큰당 서빙 비용을 낮출 여지를 줍니다.
이 결과는 문제의 틀도 바꿉니다. 기존 경로는 단순 양자화로 정확도를 포기하거나, 코드북으로 처리량을 포기해야 했습니다. 오차 원인을 하나씩 분리하고 알고리즘을 하드웨어 데이터 경로에 맞추면 둘을 함께 얻을 수 있음을 보였습니다. Blackwell 세대 B300의 FP4 Tensor Core를 겨냥한 만큼, 이후 하드웨어의 저정밀 attention 연구에도 참고가 됩니다.
공개된 구현은 추론 엔진 개발자에게 전치 softmax, 융합 확률 양자화, 스택형 query MMA를 직접 살펴볼 기회를 줍니다. RL rollout에서 BF16 KV와 맞먹는다는 점은 학습과 추론이 저정밀 캐시를 공유하려는 팀의 걱정을 하나 덜어 줍니다.
전망
논문의 근거에는 한계가 있습니다. 초록은 Qwen3 두 모델의 서빙 결과만 제시하고, 기법별 소거 실험 수치가 없어 각 요소의 기여도를 이 글에서 따로 계산할 수 없습니다. 더 많은 모델과 더 긴 컨텍스트에서의 동작은 후속 연구가 확인해야 합니다.
앞으로 볼 점은 세 가지입니다. 첫째, NVFP4의 0.5점, MXFP4의 1점 격차가 다른 모델 계열과 다양한 컨텍스트 길이에서도 유지되는가. 둘째, 2.4~3.0배 향상 중 캐시 축소와 시스템 기법이 각각 얼마나 기여하는가. 셋째, 스택형 query MMA와 융합 확률 양자화가 주요 추론 엔진에 채택되는가.
지금으로서 BitDecoding-FP4는 구체적인 사례입니다. 네이티브 FP4 KV 디코딩이 BF16에 가까운 정확도를 유지하면서 B300의 최대 처리량을 끌어올릴 수 있음을 보여 줍니다.
Sources
FAQ
BitDecoding-FP4는 무엇인가요?
BitDecoding-FP4는 긴 컨텍스트 LLM 서빙에서 FP4 KV 캐시를 네이티브로 디코딩하기 위한 알고리즘과 시스템의 공동 설계입니다. query, 확률, key의 오차를 각각 억제하고, 전치 softmax와 융합된 확률 양자화로 softmax 병목을 없앱니다. 구현은 GitHub에 공개되어 있습니다.
BitDecoding-FP4가 LLM 서빙에서 왜 중요한가요?
긴 컨텍스트 서빙에서 KV 캐시는 GPU 메모리 용량과 대역폭을 동시에 차지합니다. BitDecoding-FP4에서 NVFP4 정확도는 BF16 KV와 0.5점 이내, MXFP4는 1점 이내입니다. NVIDIA B300에서 Qwen3-4B와 Qwen3-30B-A3B를 서빙하면 최대 처리량이 BF16 KV보다 2.4~3.0배 높습니다.
BitDecoding-FP4에서 앞으로 무엇을 지켜봐야 하나요?
BitDecoding-FP4는 검증 범위를 넘어서도 결과가 유지되는지 지켜봐야 합니다. 기사는 NVIDIA B300에서 Qwen3-4B와 Qwen3-30B-A3B의 서빙 결과만 제시하며, 기법별 소거 실험 수치는 제공하지 않습니다. 더 많은 모델과 긴 컨텍스트에서의 검증이 필요하고, 공개된 GitHub 코드로 직접 시험할 수 있습니다.