들어가며

지난 3-way LLM 서빙 벤치마크에서 vLLM·LMDeploy·Ollama를 비교했다면, 이번엔 같은 vLLM 위에서 BF16 vs FP8 온라인 양자화를 붙여봤습니다. "FP8이 더 빠르다"는 통념을 그대로 받아 적지 않고, gcube RTX 5090 컨테이너에서 두 번의 독립 실행으로 재현성까지 확인했습니다.

먼저 결론부터: FP8은 무조건 빠르지 않습니다. 동시 요청이 적을 때는 오히려 BF16보다 토큰당 지연시간(TPOT)이 늘어나고, 동시 요청이 많아져야 FP8의 진짜 이점 — 늘어난 KV 캐시 여유 — 이 발휘됩니다.

왜 이 실험을 했나

지난 온라인 FP8 양자화 시도(Gemma 3 27B, BF16 58GB)는 32GB GPU에서 OOM으로 실패했습니다. 원인은 단순합니다. vLLM의 온라인 FP8 변환은 원본 BF16 레이어와 변환된 FP8 레이어가 순간적으로 동시에 VRAM에 존재해야 하는 구조라, 모델 크기가 GPU 메모리의 60%를 넘으면 위험합니다.

이번엔 그 교훈을 반영해 Qwen3-8B(BF16 기준 16GB)로 크기를 낮추고, 같은 조건에서 BF16과 FP8을 정면으로 비교했습니다.

환경

항목	값
GPU	RTX 5090 32GB (gcube 컨테이너)
모델	Qwen/Qwen3-8B
vLLM	0.16.1 (dev)
양자화	`quantization='fp8'` (온라인, 동적)
실행 모드	`enforce_eager=True`

실전 팁: 이 vLLM 버전에서는 enforce_eager=True 없이 온라인 FP8을 로드하면 VLLM_COMPILE 모드 초기화가 타임아웃까지 걸려 죽습니다. 컴파일 최적화보다 이 옵션이 우선입니다.

1. VRAM·메모리 풋프린트

항목	BF16	FP8 (온라인)	차이
순수 가중치 크기	~16 GB	8.8 GiB	-45%
총 VRAM 사용량	27.82 GiB	28.18 GiB	비슷함 (동일 `gpu_memory_utilization=0.85` 캡)
GPU KV 캐시 여유	71,696 토큰	118,784 토큰	+66%
최대 동시성 (4096 토큰 기준)	17.5x	29.0x	+66%

총 VRAM 사용량 자체는 거의 같습니다. gpu_memory_utilization 캡이 있는 한 남는 메모리를 KV 캐시가 채우기 때문입니다. FP8의 진짜 효과는 모델이 작아진 만큼 KV 캐시가 늘어나는 것 — 즉 더 많은 요청을 동시에 처리할 수 있는 여유가 생기는 것입니다.

2. 처리량 벤치마크 — 동시성별 반전

동시성 8 / 32 / 64, 입력·출력 각 128 토큰 조건으로 vllm bench serve를 돌렸습니다. (동시성 8은 콜드스타트 왜곡을 피하기 위해 워밍업 요청 후 측정)

동시성	지표	BF16	FP8	FP8 우위
8	처리량 (tok/s)	~625	~464	❌ -26%
	TTFT (ms)	~58	~48	✅ -17%
	TPOT (ms)	~12.4	~17.0	❌ +37%
32	처리량 (tok/s)	~1,711	~1,718	거의 동일
	TTFT (ms)	~222	~135	✅ -39%
	TPOT (ms)	~17.1	~17.6	거의 동일
64	처리량 (tok/s)	~3,058	~3,176	✅ +4%
	TTFT (ms)	~240	~170	✅ -30%
	TPOT (ms)	~19.1	~18.9	거의 동일

패턴이 뚜렷합니다.

TTFT는 항상 FP8이 이깁니다. 가중치가 작으니 로드/연산 경로가 짧아서입니다.
TPOT(토큰당 생성 속도)는 동시성 8에서 FP8이 확실히 손해를 봅니다. FP8 커널의 디퀀타이즈 연산 오버헤드가 작은 배치에서는 처리량 이득보다 크게 작용합니다.
동시성 32부터 격차가 사라지고, 64에서는 FP8이 처리량까지 앞서기 시작합니다. 늘어난 KV 캐시 덕에 배치를 더 키울 수 있어서입니다.

이 결과는 gcube RTX 5090 환경에서 두 번의 독립 실행으로 재현했습니다. VRAM·KV 캐시 수치는 완전히 일치했고, 처리량은 오차 1% 이내, TTFT/TPOT은 오차 4% 이내였습니다. 저동시성에서 FP8이 손해를 보는 패턴도 두 실행 모두에서 동일하게 나타났습니다 — 우연이 아니라 vLLM CUTLASS FP8 커널의 실제 특성입니다.

3. 품질 — 정말 떨어질까?

Temperature=0으로 7개 프롬프트(코드 생성, 수학, 한국어 마케팅 문구, 하이쿠 등)를 BF16·FP8 양쪽에 던져 비교했습니다.

토큰 단위로는 100% 동일하지 않지만(양자화 특성상 당연), 추론 과정과 최종 답은 논리적으로 일치했습니다.
유일하게 표현이 갈린 건 마케팅 문구 생성처럼 원래 변동성이 큰 창작형 프롬프트였고, 이마저 양자화 때문이라 단정하기는 어렵습니다.

결론 — 언제 FP8을 써야 할까

상황	권장
트래픽이 적고(동시 요청 10건 미만) 지연시간이 중요	BF16 유지 (TPOT 손해 회피) 또는 TTFT만 중요하면 FP8
트래픽이 많고(동시 요청 30건 이상) 처리량이 중요	FP8 — KV 캐시 여유로 처리량·TTFT 모두 우세
GPU 메모리가 빠듯해 더 큰 배치가 필요	FP8 — 가중치 절반, 배치 여유 대폭 증가
모델이 GPU 메모리의 60% 이상 (예: 32GB GPU + 20GB+ 모델)	온라인 FP8 대신 오프라인 사전 양자화(llm-compressor) 고려 — OOM 위험

FP8 온라인 양자화는 "일단 켜면 다 빠르다"가 아니라, 실사용 트래픽 패턴(동시성)에 맞춰 켤지 말지 결정하는 최적화입니다.

이 글의 모든 수치는 gcube RTX 5090 컨테이너에서 실측했으며, 재현성 검증을 위해 별도 컨테이너에서 동일 절차를 반복해 확인했습니다.