LLM FP8 엔드투엔드 파이프라인, 추론 비용이 왜 이렇게 줄어드나

LLM 인프라 쪽 최신 논문이랑 블로그를 보면 FP8 얘기가 계속 나옵니다. 그냥 서빙 단계 양자화 기법 하나가 아니라, 사전학습부터 파인튜닝, 서빙까지 전체 파이프라인을 FP8로 통일하려는 흐름 자체가 지금 인프라 진영의 화두더라고요. 이번엔 실제 학술 논문이랑 공식 기술 문서까지 확인하고 썼어요.

FP8이 정확히 뭘 줄여주나

FP8은 기존에 많이 쓰던 FP16이나 BF16 대비 숫자를 표현하는 비트 수를 절반으로 줄인 부동소수점 형식이에요. 엔비디아 텐서RT-LLM 관련 기술 블로그에 따르면 FP8 양자화를 적용한 엔진을 FP16 베이스라인과 비교했을 때 정밀도 손실을 최소화하면서 메모리 요구 사항과 추론 지연 시간을 동시에 줄일 수 있다고 해요.

 

이 방식을 제대로 쓰려면 호퍼 아키텍처 이상의 엔비디아 GPU, 그러니까 H100급 하드웨어가 필요하고요. AMD 쪽에서도 MI300X와 MI355X가 hipBLASLt FP8 GEMM 연산과 aiter 어텐션 커널 라이브러리를 통해 FP8 추론을 지원해요.

왜 엔드투엔드로 확장하는가

기존에는 FP8을 서빙 단계, 그러니까 추론할 때만 적용하는 경우가 많았어요. 학습은 더 높은 정밀도로 하고, 배포할 때만 사후 양자화를 거는 식이었죠. 그런데 최근 연구들은 이 경계 자체를 없애려는 방향으로 움직이고 있어요.

 

파이토치 팀이 낸 토치AO 논문이 이 흐름을 잘 보여주는 사례예요. 이 논문에서 소개하는 첫 번째 워크플로우는 토치AO의 FP8 학습 지원 기능을 활용해서 토치타이탄으로 사전학습하고 토치튠으로 파인튜닝한 다음, 같은 FP8 설정 그대로 vLLM에서 서빙하는 구조예요.

사전학습은 보통 C4처럼 범용적인 대규모 데이터셋으로 진행하고 파인튜닝은 도메인 특화 데이터로 별도 단계를 거치는데, 이 워크플로우는 두 단계 모두 텐서 단위 동적 스케일링을 쓰는 토치AO의 FP8 학습 방식을 그대로 적용해서 학습 속도를 높이는 구조예요. 핵심은 사전학습부터 서빙까지 정밀도 변환 과정 없이 FP8을 그대로 유지한다는 점이에요.

 

이게 왜 중요하냐면, 학습 때 쓰던 정밀도와 추론 때 쓰는 정밀도가 다르면 그 사이에서 별도의 변환·보정 과정이 필요했고, 이 과정에서 추가 연산 비용이나 미묘한 정확도 손실이 발생할 수 있었어요. 처음부터 끝까지 같은 정밀도를 유지하면 이 변환 비용 자체가 사라지는 거예요.

강화학습 파이프라인에서도 엔드투엔드 FP8 검증

2026년에 나온 FP8-RL 논문은 이 흐름을 한 단계 더 밀고 나간 사례예요. 연구진은 큐웬3-8B-베이스 모델을 대상으로 8장의 H100 GPU에서 DAPO와 AIME24 검증 방식을 써서 세 가지 정밀도 조합을 비교했어요.

BF16 학습에 BF16 롤아웃을 쓰는 완전 BF16 기준선, BF16 학습에 FP8 롤아웃만 섞는 방식, 그리고 학습과 롤아웃 둘 다 FP8로 통일하는 완전 엔드투엔드 방식이었어요. 이 실험은 강화학습 단계에서도 처음부터 끝까지 FP8을 쓰는 게 실제로 안정적으로 작동하는지 검증하려는 목적이었고, NeMo-RL 프레임워크 위에서 진행됐어요.

 

또 다른 연구인 LLMQ 논문은 소비자용 GPU에서의 저정밀도 사전학습을 다뤘는데, RTX 4090 네 장으로 15억 파라미터급 큐웬 스타일 모델을 처음부터 FP8로 사전학습하는 실험을 진행했어요.

E4M3 포맷을 순전파와 역전파 모두에 적용했을 때 손실 곡선이 BF16 기준선과 거의 같은 궤적을 그렸다는 결과가 나왔고요. 이건 큰 데이터센터 클러스터가 아니라 개인이나 소규모 팀이 보유한 하드웨어에서도 FP8 사전학습이 현실적인 선택지가 될 수 있다는 걸 보여주는 사례예요.

실제로 어디까지 왔나

큐웬 계열은 FP8과 NF4 같은 양자화 기법을 학습 파이프라인에 직접 통합하는 흐름의 대표적인 사례로 자주 언급돼요. vLLM은 큐웬3 모델을 페이지드어텐션과 FP8 KV 캐싱 기본 지원으로 서빙하고 있고요.

 

서빙 쪽에서는 텐서RT-LLM이 FP8을 가장 적극적으로 활용하는 프레임워크로 꼽히는데, vLLM에서도 --quantization fp8 플래그 하나로 텐서 단위 동적 양자화를 바로 적용할 수 있어서 진입 장벽이 낮은 편이에요.

더 높은 정확도가 필요하면 허깅페이스에 미리 양자화돼서 올라온 FP8 체크포인트를 --quantization compressed-tensors 옵션으로 불러와서 캘리브레이션 단계에서 계산된 정적 스케일을 쓸 수도 있어요.

# vLLM에서 FP8 동적 양자화로 서빙 (별도 캘리브레이션 불필요)
vllm serve meta-llama/Llama-3.1-8B-Instruct --quantization fp8

# TensorRT-LLM에서 FP8 양자화 체크포인트로 엔진 빌드
trtllm-build \
  --checkpoint_dir ./model_fp8_checkpoint \
  --output_dir ./trt_engine_fp8 \
  --gemm_plugin fp8 \
  --use_fp8_context_fmha enable

 

이렇게 체크포인트를 FP8로 빌드해두면, 이후 서빙 과정에서 추가 변환 없이 바로 최적화된 추론 엔진을 실행할 수 있어요. 다만 이 명령어는 하드웨어와 모델 아키텍처에 따라 옵션이 달라지니까, 실제 적용하실 땐 사용 중인 모델의 공식 문서에서 FP8 지원 여부부터 확인하시는 걸 추천드려요.

FP8이 잘 안 맞는 상황

Spheron의 기술 문서에 따르면 모든 모델과 태스크가 FP8에 똑같이 잘 반응하는 건 아니에요. OPT나 GPT-2 스타일처럼 오래된 아키텍처는 활성화 값의 분포가 FP8의 동적 범위를 부담스러워하는 경향이 있는 반면, 최신 모델들은 상대적으로 양자화에 관대하다고 해요.

태스크 측면에서는 다단계 산술 연산, 화학이나 생물학 예측처럼 정확한 숫자 출력이 중요한 작업, 정밀한 수치가 그대로 나와야 하는 코드 생성에서 FP8로 인한 정확도 손실이 벤치마크상으로 가장 뚜렷하게 드러난다고 해요.

 

이런 상황에서 쓸 수 있는 완화 방법도 몇 가지 있어요. 가중치는 BF16으로 유지하면서 KV 캐시만 FP8로 낮추는 부분 적용 방식이 있고, 텐서RT-LLM의 레이어별 폴백 기능을 써서 민감한 레이어만 선택적으로 BF16으로 유지할 수도 있어요.

트랜스포머 엔진의 레이어별 레시피를 통해 FP8과 BF16을 섞어 쓰는 방법도 있고요. A/B 테스트에서 MMLU나 태스크별 정확도가 1% 이상 떨어진다면 BF16으로 되돌리거나, 호퍼 이전 하드웨어에서는 활성화 인식 캘리브레이션을 쓰는 AWQ INT4 같은 대안을 검토해보시는 걸 권장한다고 해요.

실무 체감

체감되는 가장 큰 부분은 역시 비용이에요. 메모리 요구량이 줄면 같은 GPU로 더 큰 배치를 처리할 수 있고, 그만큼 GPU당 처리량이 늘어나니까 토큰당 비용이 떨어져요.

다만 정밀도를 낮추는 작업인 만큼 모델과 태스크에 따라 미묘한 품질 저하가 있을 수 있어서, 적용 전후로 본인 워크로드 기준 평가를 꼭 돌려보시는 게 안전해요. 특히 정확한 숫자 출력이 중요한 도메인이라면 앞서 말씀드린 완화 방법들을 같이 검토하시길 권해드려요.

정리

FP8은 이제 단순한 배포 시점 최적화 기법을 넘어서, 사전학습부터 파인튜닝, 강화학습, 서빙까지 전체 파이프라인을 관통하는 표준으로 자리 잡아가는 중이에요. 토치AO나 FP8-RL, LLMQ 같은 최신 연구들이 이 방향이 실제로 안정적으로 작동한다는 걸 검증하고 있고요. 호퍼 이상 GPU를 보유하고 계시고 메모리나 처리량이 병목인 상황이라면, FP8 양자화부터 먼저 시도해보시는 게 비용 대비 효과가 가장 큰 최적화일 가능성이 높아요. 다만 정확한 수치 연산이 중요한 워크로드라면 전면 적용보다는 KV 캐시만 먼저 FP8로 낮추는 식의 점진적 접근을 추천드려요.