FP8 and FP4: Throughput Needs Scaling

FP8과 FP4를 “모델을 더 작게 저장하는 방법”으로만 보면 8장의 핵심을 놓친다.

Serving throughput이 문제일 때 FP8/FP4의 진짜 목적은 matmul 자체를 더 빠른 hardware path로 실행하는 것이다.

W4A16 GPTQ/AWQ:
weights are small
activations remain FP16/BF16
compute path may stay high precision

FP8 / FP4:
weights and activations can enter low-bit tensor core path
compute throughput can increase

Throughput per GPU

FP8 / FP4

Buys: low-precision tensor cores
Needs: H100+ for FP8, Blackwell-class path for FP4

format without kernel support is just storage

Fine-tuning memory

NF4 + QLoRA

Buys: frozen 4-bit base + adapters
Needs: PEFT training stack and stable adapter recipe

base is compressed, optimizer state still matters

CPU-only inference

Ternary / BitNet

Buys: multiply-light linear layers
Needs: model trained with ternary constraint

post-training ternary conversion usually breaks

Sub-8-bit 선택은 bit 수 경쟁이 아니다. 먼저 deployment pressure를 고르고, 그 pressure를 실제로 줄이는 format과 kernel, training 조건이 있는지 확인해야 한다.

Throughput pressure가 있을 때 본다

Decode 한 요청만 보면 weight와 KV cache를 계속 읽는 memory-bound 성격이 강하다. 그래서 W4A16 weight-only quantization도 큰 이득이 있다.

하지만 high batch, long prompt prefill, peak traffic serving에서는 큰 GEMM이 많아지고 compute throughput이 중요해진다.

이때 FP8/FP4는 다음 질문에 대한 답이다.

bytes를 줄이는 것으로 충분한가?
아니면 tensor core가 처리하는 dtype 자체를 낮춰야 하는가?

H100 이후의 FP8 tensor core나 Blackwell 계열의 FP4 path는 후자에 해당한다.

FP8은 E4M3와 E5M2를 구분해야 한다

FP8은 하나의 format이 아니다.

E4M3:
more mantissa
better precision
smaller range

E5M2:
more exponent
larger range
less precision

Forward pass의 weight와 activation은 대체로 0 근처에 많이 몰려 있으므로 E4M3가 자주 맞는다. Gradient처럼 갑자기 큰 값이 나올 수 있는 곳은 E5M2의 range가 필요할 수 있다.

즉 FP8 선택은 단순히 8-bit를 고르는 것이 아니라, tensor의 분포와 역할에 맞는 exponent/mantissa split을 고르는 일이다.

FP4는 block scaling 없이는 위험하다

FP4는 더 공격적이다. 4-bit 안에 sign, exponent, mantissa를 모두 넣어야 하므로 표현 가능한 값이 매우 적다.

FP4 E2M1:
few levels
non-uniform spacing
small values get some density
large values are sparse

그래서 scale 하나를 tensor 전체에 공유하면 outlier 하나가 전체 표현을 망칠 수 있다.

per-tensor FP4:
simple
but quality cliff risk

block-wise FP4:
more scale metadata
but local range fits better

8장의 핵심은 FP4가 “INT4보다 항상 낫다”가 아니다. FP4도 충분히 작은 block 단위 scaling이 있어야 품질 cliff를 피할 수 있다는 것이다.

Kernel caveat가 마지막 관문이다

FP8/FP4 checkpoint가 있다고 해서 실제 serving이 빨라지는 것은 아니다.

bad case:
FP8/FP4 stored
-> runtime dequantizes to BF16
-> BF16 matmul
-> memory saving만 있고 throughput gain은 약함

good case:
FP8/FP4 operands
-> native low-bit tensor core kernel
-> high precision accumulate
-> real throughput gain

그래서 FP8/FP4는 algorithm만의 결정이 아니다.

format
scaling granularity
runtime kernel
hardware generation
serving workload

이 다섯 가지가 같이 맞아야 한다.

확인

FP8/FP4가 GPTQ/AWQ와 달리 throughput 문제를 직접 겨냥하는 이유는 무엇인가?
FP4에서 block-wise scaling이 사실상 필수에 가까운 이유는 무엇인가?
FP8/FP4 checkpoint가 있어도 속도가 안 나올 수 있는 runtime 이유는 무엇인가?