한 줄 정의

FP8 quantized weights는 모델의 가중치를 FP8 정밀도로 저장한 배포 방식이야. 모델 구조나 파라미터 수를 새로 만든다는 뜻이 아니라, 이미 학습된 가중치 숫자를 더 작은 8비트 부동소수점 표현으로 담아 추론 때 GPU 메모리와 대역폭 부담을 줄이려는 선택에 가까워.

이 표현에서 중요한 단어는 weights야. Qwen/Qwen3.6-27B-FP8 모델 카드는 이 저장소가 FP8-quantized model weights와 설정 파일을 담고, quantization method가 fine-grained FP8이며 block size가 128이라고 적어. 같은 카드에는 27B parameters, 64 layers, hidden dimension 5120, native 컨텍스트 윈도우 262,144 tokens도 같이 나와.

그래서 이 표현을 보면 “모델 전체가 FP8로 돈다”보다 좁게 읽어야 해. 가중치는 FP8일 수 있지만 KV 캐시는 BF16일 수 있고, 일부 연산은 더 높은 정밀도로 남을 수 있어. 이 차이를 놓치면 로컬 GPU에 올라가는지, 200K 문맥을 버티는지, 답변 품질이 유지되는지를 한 문장으로 섞어 버리게 돼.

어떻게 작동하나

가중치는 모델이 학습해서 들고 있는 행렬과 텐서야. 원래 BF16이나 FP16으로 배포하면 값 하나가 16비트 단위에 가깝고, FP8로 배포하면 값 하나를 8비트 단위로 줄여. 단순히 보면 저장량이 절반 쪽으로 내려가지만, 실제 모델에서는 scale, block size, 지원 커널, 런타임 로딩 방식이 같이 붙어.

Qwen3.6 27B FP8 사례에서는 block size 128이라는 말이 붙어. 이건 가중치 전체를 아무렇게나 8비트로 뭉개는 게 아니라, 일정 블록 단위로 값의 범위와 스케일을 맞춰 FP8 표현에 담는다는 뜻으로 읽으면 돼. 그래서 양자화라고 해도 INT4 GGUF처럼 강하게 줄인 파일과 같은 성격은 아니고, FP8을 지원하는 GPU와 서빙 런타임을 타는 배포 형식에 더 가까워.

vLLM 0.20.1 엔진 인자 문서를 보면 이 구분이 더 분명해져. --quantization은 가중치를 어떤 방식으로 양자화했는지 고르는 축이고, --kv-cache-dtype은 KV cache storage dtype을 고르는 축이야. 같은 서버 명령 안에서도 가중치는 FP8이고 캐시는 bfloat16일 수 있어.

실행할 때는 모델 카드만 보지 말고 서버 로그와 인자를 같이 봐야 해. 예를 들어 --max-model-len, --kv-cache-dtype, --gpu-memory-utilization, attention backend, prefix caching 설정이 바뀌면 같은 FP8 가중치라도 VRAM 사용량과 tok/s가 달라져.

왜 중요한가

FP8 가중치 배포가 중요한 이유는 로컬 추론의 첫 번째 벽인 “가중치를 GPU에 올릴 수 있나”를 낮춰 주기 때문이야. 27B dense 모델을 16비트 가중치로 올리면 가중치만으로도 큰 VRAM이 필요하지만, 8비트 부동소수점 배포본은 그 압박을 줄여서 48GB급 카드에서 실험할 여지를 만들어.

다만 긴 문맥에서는 두 번째 벽이 바로 따라와. 이전 토큰들의 key/value를 저장하는 KV 캐시는 문맥 길이에 비례해서 커져. LocalLLaMA 게시글은 Qwen3.6 27B FP8을 RTX 5000 PRO 48GB 한 장에서 vLLM 0.20.1, CUDA 12.9, --max-model-len 196608, --kv-cache-dtype bfloat16으로 띄운 사례를 제시해. 글 제목은 약 200K tokens의 BF16 KV cache와 약 80 tok/s를 말하지만, 이건 특정 장비와 런타임 조건이 붙은 커뮤니티 실행값이야.

StartupFortune 분석은 이 사례를 FP8 model weights 약 27GB, 200K BF16 KV cache 약 19~21GB로 해석해. 숫자 자체보다 중요한 건 구조야. 가중치를 줄여도 긴 문맥의 캐시가 남은 VRAM을 다시 채울 수 있다는 점이야.

하드웨어 숫자도 따로 봐야 해. NVIDIA RTX PRO 5000 Blackwell 사양은 이 계열을 48GB 또는 72GB GDDR7 ECC, 1,344 GB/sec memory bandwidth, 300W 카드로 적어. Blackwell 세대와 1,344 GB/sec 같은 수치는 긴 컨텍스트 로컬 추론에 유리한 조건이지만, 그 자체가 특정 모델의 품질이나 80 tok/s를 보장하지는 않아.

무엇과 헷갈리나

첫째, FP8 가중치와 FP8 KV cache는 다른 말이야. 앞쪽은 가중치 파일의 정밀도고, 뒤쪽은 생성 중 계속 다시 읽는 KV 캐시의 정밀도야. 가중치를 FP8로 줄이면 모델 파일과 weight load 쪽 부담이 내려가지만, KV 캐시를 BF16으로 두면 긴 문맥 메모리는 여전히 크게 잡아먹어.

둘째, FP8 가중치와 BF16 KV도 반대편 선택지가 아니야. Qwen3.6 27B FP8 사례처럼 둘은 같이 나올 수 있어. “가중치는 공격적으로 줄이고, 긴 문맥 캐시는 조금 더 보수적으로 남긴다”는 조합이 되는 거야.

셋째, 이 배포 방식은 모델 능력 향상 기술이 아니야. 양자화는 같은 모델을 더 작은 숫자 표현으로 배포하는 방식이라서, 좋은 GPU와 런타임을 만나면 처리량이나 메모리 예산이 좋아질 수 있어. 반대로 코드 생성, 긴 추론, tool call, 한국어 문서처럼 민감한 작업에서는 BF16 기준선과 결과를 나란히 재야 해.

넷째, FP8이라는 이름만 보고 “48GB GPU면 넉넉하다”로 읽으면 위험해. vision encoder를 같이 쓰는지, 동시 요청이 몇 개인지, prompt가 실제로 몇 토큰인지, 출력 토큰 여유가 얼마나 남는지에 따라 같은 카드에서도 운영 여유가 크게 달라져.

실무에서 확인할 것

이 표현이 보이면 아래 순서로 보면 좋아.

  • 모델 카드에서 가중치 형식을 확인해. FP8인지, block size가 얼마인지, 라이선스와 원본 모델이 무엇인지 먼저 잡아야 해.
  • 런타임 인자를 확인해. vLLM이라면 --quantization, --dtype, --kv-cache-dtype, --max-model-len, --gpu-memory-utilization을 같이 봐.
  • KV 캐시 dtype을 따로 적어. 가중치가 FP8이어도 캐시가 BF16이면 200K 안팎 문맥에서 메모리 계산이 완전히 달라져.
  • 같은 prompt 묶음으로 BF16 기준선과 FP8 가중치 결과를 비교해. tok/s, prefill 시간, p95 지연시간, 최대 VRAM, 답변 품질 회귀를 같은 표에 둬야 해.
  • 커뮤니티 벤치마크를 옮길 때는 GPU, CUDA, 드라이버, vLLM 버전, attention backend, prompt 길이, 동시성까지 같이 옮겨. 80 tok/s 같은 숫자만 떼어 오면 거의 쓸모가 없어.
  • 비용 판단에는 장비 가격, 전력, 냉각, 장애 대응, 모델 업데이트 비용을 넣어. FP8 가중치는 로컬 실행 가능성을 높이는 단서지, API 비용을 자동으로 이긴다는 결론은 아니야.

정리하면 이 용어는 “가중치를 줄였다”는 말이야. 그다음 판단은 캐시를 무엇으로 남겼는지, 얼마나 긴 문맥을 열었는지, 어떤 GPU와 런타임이 실제로 그 경로를 타는지에서 갈려.

같이 볼 항목은 두 묶음으로 나누면 덜 헷갈려. 개념 비교는 FP8, 양자화, 가중치, BF16 KV, KV 캐시처럼 정밀도와 메모리 계산을 가르는 쪽이야. 반면 Qwen3.6 27B FP8, 200K, 80 tok/s, CUDA 12.9, Blackwell, 1,344 GB/sec는 이번 실행 사례와 하드웨어 조건을 확인하는 근거 쪽으로 보면 돼.