들어가며: LLM 서빙의 병목, 메모리
LLM(대규모 언어 모델) 서빙 인프라를 운영하다 보면 GPU 메모리가 전쟁터라는 말을 자주 듣습니다. 특히 최근 주목받는 Kimi K2.6이나 GLM 5.2 같은 모델들은 수십억 개의 파라미터와 긴 컨텍스트를 처리해야 하기 때문에, 단순히 모델 가중치만 올려둔다고 끝이 아닙니다.
Cloudflare의 Workers AI 플랫폼은 전 세계 데이터 센터의 GPU에서 이런 대형 모델들을 서빙하고 있습니다. 이번에 공개된 사례에서는 단순히 '빠르게' 만드는 것을 넘어, **'더 많은 요청을 같은 하드웨어에 수용'**하는 데 초점을 맞췄습니다. 핵심은 세 가지입니다.
- KV 캐시 양자화 (FP8)
- 모델 가중치 압축 (INT4)
- 공유 캐시 보호 (무결성 검증)
이 글에서는 각 기법이 왜 필요하고, 실제 성능 지표로 어떻게 검증됐는지 살펴보겠습니다.
본론 1: KV 캐시를 FP8로 줄여 2배 많은 컨텍스트 확보
왜 KV 캐시가 문제인가?
모델이 텍스트를 생성할 때, 이미 처리한 토큰의 Attention Key(K)와 Value(V)를 KV 캐시라는 구조에 저장합니다. 이 캐시 덕분에 긴 대화에서 매번 전체 문맥을 다시 읽지 않아도 됩니다. 문제는 이 캐시가 GPU 메모리의 상당 부분을 차지한다는 점입니다.
기본적으로 KV 캐시는 16비트 정밀도(BF16)로 저장됩니다. Cloudflare는 이를 8비트 부동소수점(FP8, e4m3)으로 바꿔 캐시 크기를 절반으로 줄였습니다. Kimi K2.6 기준으로, 메모리에 보관할 수 있는 컨텍스트가 약 68만 6천 토큰에서 137만 토큰으로 2배 늘어났습니다.
성능 영향: 단순 속도가 아니라 '수용량'의 문제
# 개념 코드: KV 캐시 데이터 타입 변환 예시
import torch
# 기존 BF16 캐시 (메모리 사용량 2배)
k_cache_bf16 = torch.randn(4096, 128, dtype=torch.bfloat16)
# FP8로 변환 (메모리 사용량 절반)
from torchao.quantization import quantize_
quantize_(k_cache_bf16, fp8_e4m3)
print(f"BF16 메모리: {k_cache_bf16.element_size() * k_cache_bf16.nelement() / 1024**2:.2f} MB")
print(f"FP8 메모리: {k_cache_bf16.element_size() // 2 * k_cache_bf16.nelement() / 1024**2:.2f} MB")
아래 표는 Kimi K2.6 디코딩(생성) 단계에서 H200 GPU의 동시 요청 수에 따른 처리량을 비교한 것입니다. 중요한 포인트는 BF16이 단일 요청에서 소폭 빠르지만, 32개 동시 요청에서 메모리 한계에 도달한다는 점입니다.
| 동시 요청 수 | BF16 KV 캐시 (tok/s) | FP8 KV 캐시 (tok/s) |
|---|---|---|
| 1 | 137 | 125 |
| 8 | 731 | 689 |
| 16 | 1,106 | 1,028 |
| 32 | 1,558 | 1,489 |
| 64 | OOM | 2,192 |
FP8은 BF16의 최대 처리량(1,558 tok/s)보다 약 41% 높은 2,192 tok/s를 기록했고, 토큰당 비용은 약 30% 절감됐습니다. **핵심은 '더 빠른 속도'가 아니라 '더 많은 요청 수용'**이라는 점입니다.
정확도는 동일한가?
| 벤치마크 | BF16 KV | FP8 KV |
|---|---|---|
| GSM8K | 94.24 | 94.09 |
| ARC-Easy | 89.06 | 89.14 |
| ARC-Challenge | 66.72 | 67.49 |
| MMLU | 89.11 | 89.04 |
| MMLU-Pro | 80.29 | 79.29 |
| Tool-call 정확도 | 92.2% | 92.6% |
벤치마크 결과 FP8과 BF16은 사실상 동일한 정확도를 보여줍니다. 실무에서 적용해도 모델 품질 저하 없이 메모리 효율을 높일 수 있는 셈입니다.
본론 2: 모델 가중치 INT4 압축과 캐시 보호
가중치 압축: 705GB → 421GB
KV 캐시 다음으로 메모리를 차지하는 것은 모델 가중치입니다. GLM 5.2의 경우, Cloudflare는 가중치를 8비트 부동소수점(FP8)에서 4비트 정수(INT4)로 압축했습니다. 체크포인트 크기가 705GB에서 421GB로 약 40% 줄었고, 8-way 텐서 병렬 배포 기준 GPU당 메모리 사용량이 약 88GB에서 52GB로 감소했습니다.
# 개념 코드: FP8 vs INT4 가중치 메모리 비교
model_size_params = 400_000_000_000 # 400B 파라미터 가정
fp8_bytes = model_size_params * 1 # 8bit = 1byte
int4_bytes = model_size_params * 0.5 # 4bit = 0.5byte
print(f"FP8 모델 크기: {fp8_bytes / 1024**3:.1f} GB")
print(f"INT4 모델 크기: {int4_bytes / 1024**3:.1f} GB")
디코딩 단계에서는 가중치를 GPU 메모리에서 스트리밍하며 토큰을 생성하므로, 메모리 대역폭이 곧 속도입니다. INT4로 압축하면 읽어야 할 데이터가 줄어들어 단일 요청 기준 처리량이 55% 향상됩니다.
| 동시 요청 수 | GLM FP8 (tok/s) | GLM INT4 (tok/s) | INT4 이득 |
|---|---|---|---|
| 1 | 60 | 92 | +55% |
| 8 | 425 | 513 | +21% |
| 16 | 683 | 825 | +21% |
| 32 | 994 | 1,267 | +27% |
| 64 | 1,672 | 1,933 | +16% |
단, 프리필(Prefill) 단계는 연산량이 많아 INT4가 오히려 느립니다. FP8은 초당 10,160 토큰, INT4는 8,660 토큰입니다. 이 때문에 Cloudflare는 **프리필과 디코드를 분리(Disaggregation)**해서 각각 유리한 방식을 적용합니다.
공유 캐시 보호: 10억분의 1 확률도 용납할 수 없다
양자화와 압축 덕분에 수백 개의 요청이 같은 GPU 메모리를 공유하게 됐습니다. 효율성은 좋지만, 캐시 페이지를 잘못 참조하면 다른 사용자의 데이터가 섞일 수 있는 위험이 생깁니다. Cloudflare는 이를 방지하기 위해 KV 캐시 무결성 검증을 구현했습니다.
- 모든 물리적 캐시 페이지에는 재할당 시 변경되는 태그를 부여합니다.
- 서버는 각 요청이 사용할 페이지와 태그 매핑을 기록합니다.
- 디코딩 전에 매핑을 확인하고, 불일치가 발견되면 해당 요청을 중단합니다.
이 검증의 성능 비용은 매우 낮습니다.
| 동시성 | 처리량 변화 | p95 지연시간 변화 |
|---|---|---|
| 1 | -0.53% | +0.42% |
| 4 | -0.79% | +0.63% |
| 8 | -0.43% | +0.80% |
비용이 1% 미만이기 때문에, 기본적으로 활성화해도 서비스 품질에 영향을 주지 않습니다.
결론: 실무 적용을 위한 관점과 다음 단계
한국 개발 생태계에서의 적용 맥락
국내에서도 LLM 서빙에 GPU를 사용하는 스타트업과 대기업이 늘고 있습니다. 하지만 대부분은 단순히 GPU를 추가하는 방식으로 확장하고 있습니다. 이번 Cloudflare 사례는 **'소프트웨어 최적화로 하드웨어 효율을 극대화'**하는 접근법을 보여줍니다. 특히 한국의 클라우드 비용이 높은 상황에서, KV 캐시 양자화와 가중치 압축은 즉시 비용 절감 효과를 기대할 수 있는 전략입니다.
이 기술의 한계 또는 주의사항
- 정확도 미세 변화: FP8과 INT4 모두 벤치마크에서 유의미한 차이가 없지만, 특정 도메인(예: 의료, 법률)에서는 미세한 차이가 민감할 수 있습니다.
- 프리필/디코드 분리 필요: INT4는 디코드에만 유리하므로, 아키텍처를 분리하지 않으면 오히려 성능이 저하될 수 있습니다.
- 하드웨어 의존성: FP8 e4m3 변환은 최신 GPU(H100, H200 등)에서만 효율적으로 지원됩니다.
다음 단계 학습 방향
- SGLang 프레임워크 학습: 이번 최적화의 기반이 된 오픈소스 서빙 프레임워크입니다.
- 양자화 기법 심화: INT4, FP8 외에도 NVFP4, AWQ 등 다양한 기법을 비교해보세요.
- 비용 모델링: 동일한 하드웨어에서 처리량이 2배가 되면 비용이 어떻게 변하는지 직접 계산해보는 것을 추천합니다.
함께 보면 좋은 글
- MS 소버린 프라이빗 클라우드, Azure Local로 수천 노드까지 확장된다
- Generali Malaysia의 Amazon EKS 운영 최적화 사례 자동화, 보안, 비용 절감의 삼박자
본 포스팅은 Cloudflare 블로그 원문을 기반으로 재구성되었습니다.