한 줄 정의

INT8은 숫자를 8비트 정수로 표현하도록 줄이는 양자화 방식이야. LLM에서는 모델 가중치, 활성값, 때로는 KV 캐시를 더 작은 값으로 저장하거나 계산하려고 써.

중요한 건 INT8이 새 모델이나 새 추론 엔진이 아니라는 점이야. 같은 모델을 더 낮은 정밀도로 다루는 선택이고, 8비트라는 숫자만 같아도 FP8처럼 부동소수점인 포맷과는 경계가 달라.

vLLM의 INT8 W8A8 문서는 가중치와 활성값을 INT8로 줄이는 경로를 다뤄. 반면 vLLM의 Quantized KV Cache 문서는 KV 캐시를 kv_cache_dtype="fp8"로 다루는 FP8 문서야. 이 둘을 섞으면 설정을 잘못 읽기 쉬워.

어떻게 작동하나

INT8은 원래 BF16이나 FP16으로 들고 있던 값을 8비트 정수 칸에 다시 맞춰 넣어. 값 전체를 그냥 반으로 자르는 게 아니라, 실제 값 범위를 보고 scale과 zero point 같은 보정값을 붙여 “이 정수 칸이 원래 어느 값에 해당하는지”를 복원할 수 있게 해.

가중치 쪽에서는 Linear 계층 같은 큰 행렬곱이 먼저 대상이 돼. Hugging Face Transformers bitsandbytes 문서는 load_in_8bit=True 같은 8비트 로딩 경로를 보여주고, LLM.int8()은 민감한 계산 일부를 높은 정밀도로 남기는 방식을 쓴다고 설명해. LLM.int8 논문도 outlier 차원을 따로 16비트로 처리하고, 나머지 대부분을 8비트 행렬곱으로 돌리는 쪽에 초점을 둬.

활성값까지 INT8로 줄이는 W8A8은 더 조심해야 해. vLLM 예시는 llmcompressor로 보정 데이터를 준비하고, 512개 calibration sample과 2048 max sequence length를 시작값으로 보여줘. 운영 데이터와 전혀 다른 보정셋을 쓰면 scale이 빗나가서 응답 품질이 흔들릴 수 있어.

KV 캐시는 또 다른 축이야. Hugging Face KV cache quantization 글은 HQQ backend에서 int8 KV cache quantization을 지원한다고 적지만, 성능 비교는 주로 int4와 fp16을 놓고 설명해. 그래서 “HF가 int8을 지원한다”와 “int8에서 이런 성능이 나온다”는 같은 말이 아니야.

왜 중요한가

INT8이 중요한 이유는 메모리와 대역폭 병목을 직접 건드리기 때문이야. 원자료 폭만 보면 8비트는 16비트 BF16·FP16의 절반이라, 큰 가중치나 반복해서 읽는 활성값에서는 이득을 기대할 수 있어.

하지만 실제 절감률은 그 숫자 그대로 나오지 않아. scale, zero point, outlier 처리, residual cache, padding, dequantize 연산, 커널 지원이 같이 붙어. 그래서 INT8을 켰다는 사실보다 같은 입력과 같은 batch에서 최대 VRAM, p50·p95 지연 시간, tokens/sec, 평가셋 점수, 긴 문맥 답변 품질이 어떻게 바뀌었는지를 봐야 해.

특히 에이전트나 긴 문서 처리에서는 컨텍스트 윈도우와 KV 캐시가 같이 커져. 이때 INT8 KV cache가 있는 backend를 쓰면 메모리 부담을 낮출 수 있지만, 다음 토큰 계산에 계속 재사용되는 값이라 긴 멀티턴 작업으로 회귀 테스트를 해야 해. 짧은 프롬프트 20개만 통과했다고 안전하다고 보기는 어려워.

INT8을 시험할 조건

먼저 적용 대상부터 나눠. 가중치만 8비트로 줄이는지, W8A8처럼 활성값도 줄이는지, KV 캐시 저장 형식을 바꾸는지에 따라 위험이 달라져. 같은 “INT8”이어도 설정 파일과 측정 지표가 달라야 해.

  • 가중치 INT8: 모델이 VRAM에 안 들어가거나, 같은 GPU에서 더 큰 배치를 처리하고 싶을 때 먼저 볼 만해. bitsandbytes의 LLM.int8()처럼 일부 민감한 계산을 높은 정밀도로 남기는 구현이면 naive INT8보다 시작점이 나아.
  • W8A8 INT8: vLLM처럼 가중치와 활성값을 같이 줄이는 경로야. vLLM 문서 기준 NVIDIA GPU compute capability > 7.5에서 지원되고, Blackwell 계열 >= 10.0에는 INT8 미지원 경고가 붙어. 이 경우 FP8이나 다른 정밀도를 먼저 봐야 할 수 있어.
  • KV cache INT8: Transformers 쪽 HQQ backend처럼 KV cache에서 int8을 지원하는 경로가 있을 때만 해당돼. vLLM 최신 KV cache 문서는 FP8 경로라서, vLLM 설정을 int8로 읽으면 안 돼.

실험 순서는 단순해. BF16 또는 FP16 기준선을 먼저 만들고, 같은 모델·같은 prompt set·같은 batch·같은 sampling으로 INT8 결과를 붙여. 그다음 최대 VRAM, throughput, p95 지연, perplexity나 task score, 긴 문맥 응답 품질을 한 표로 봐. 비용이 줄어도 품질이 흔들리면 그건 성공이 아니야.

FP8·INT4·BF16과 경계

BF16은 16비트 부동소수점이라 범위를 넓게 유지하는 기본값에 가까워. 품질 기준선을 만들거나 보정 데이터가 부족할 때는 BF16이 더 편해.

FP8은 8비트 부동소수점 포맷이라 INT8과 다르게 지수와 가수 구조를 가져. vLLM KV cache처럼 fp8_e4m3, fp8_e5m2를 직접 고르는 경로라면 INT8 페이지가 아니라 FP8 기준으로 읽어야 해.

INT4는 더 세게 줄이는 선택이야. Hugging Face KV cache 글은 residual_length=128을 baseline으로 두고, int4 cache와 fp16을 비교한 결과를 많이 보여줘. INT4가 통과한 결과를 INT8 성능 보장으로 옮겨도 안 되고, INT8이 더 보수적일 거라고만 보고 검증을 생략해도 안 돼.

정리하면 INT8은 “메모리를 줄일 수 있는 중간 지점”이지 자동으로 더 빠르고 안전한 설정은 아니야. 보정 데이터가 없거나, backend가 INT8 커널을 제대로 타지 않거나, 긴 문맥 품질을 측정할 수 없다면 BF16·FP16 기준선에 남는 편이 낫다.