오픈 웨이트 대형언어모델이 실용 단계로 접어들면서, 이제 경쟁의 무게중심은 '어떤 모델을 쓰느냐'에서 '그 모델을 얼마나 싸고 빠르게 서빙하느냐'로 옮겨가고 있다. Cloudflare는 자사 Workers AI 플랫폼에서 Moonshot의 Kimi K 시리즈와 Z.ai의 GLM을 사용자 근처 데이터센터의 GPU로 추론하는데, 이 두 모델은 성능이 뛰어난 만큼 서빙하기가 까다롭다. 긴 컨텍스트를 다루는 대형 MoE(Mixture-of-Experts) 구조라서, 무엇보다 GPU 메모리를 두고 끊임없이 씨름해야 하기 때문이다. Cloudflare가 공개한 이번 글은 prefill과 decode 단계를 분리하는 기존 최적화 위에, 메모리를 더 짜내기 위해 얹은 세 가지 기법을 다룬다. 모든 실험과 프로덕션 트래픽은 오픈소스 추론 프레임워크 SGLang 위에서 측정됐다.
KV 캐시를 절반으로: 속도가 아니라 밀도의 문제
첫 번째는 KV 캐시 양자화다. 모델은 텍스트를 생성하면서 이미 처리한 모든 토큰의 어텐션 키(K)와 값(V)을 KV 캐시에 저장해 둔다. 덕분에 새 토큰마다 전체 문맥을 다시 읽지 않고도 긴 대화를 이어갈 수 있지만, 긴 컨텍스트 모델에서는 이 캐시가 빠르게 불어나 대개 모델 가중치보다 먼저 GPU 메모리를 채운다. 기본값인 16비트(BF16) 대신 8비트 부동소수점(FP8, e4m3)으로 저장하면 캐시 크기가 절반으로 줄고, Kimi K2.6 기준으로 메모리에 담을 수 있는 컨텍스트가 약 68만6천 토큰에서 약 137만 토큰으로 두 배가 된다.
여기서 짚어야 할 점은, 이 이득이 순수한 속도에서 오는 것이 아니라는 것이다. FP8 어텐션 커널은 값을 읽으면서 변환 작업을 하므로 토큰당 연산이 오히려 조금 늘어난다. 실제로 동일 동시성 수준에서는 BF16이 토큰당 몇 퍼센트 빠르다. 그러나 disaggregated H200 환경에서 Kimi K2.6을 디코딩할 때 BF16은 동시 요청 32개에서 캐시가 바닥나 33번째를 받지 못하는 반면, FP8은 64개까지 버티며 초당 2,192토큰에 도달한다. 이는 BF16 최고치보다 약 41% 높고 토큰당 비용은 약 30% 낮다. 관건은 개별 요청의 속도가 아니라 한 GPU에 얼마나 많은 요청을 동시에 상주시키느냐다. prefill은 메모리가 아니라 연산에 묶여 있으므로, 그쪽 캐시는 처리량이 약간 더 높은 BF16으로 남겨 둔다.
가중치는 INT4로, 단 디코드에서만
두 번째는 가중치 압축이다. GLM 5.2의 가중치를 8비트 부동소수점에서 4비트 정수(INT4)로 압축하면 체크포인트가 705GB에서 421GB로 약 40% 줄고, 8-way 텐서 병렬 배치에서 GPU당 메모리가 약 88GB에서 52GB로 내려간다. 그만큼 확보된 공간에 같은 하드웨어에서 약 118만 토큰의 KV 캐시를 더 담을 수 있다. 디코드 단계는 토큰마다 가중치를 GPU 메모리에서 흘려보내는 과정이라 메모리 대역폭에 속도가 좌우되는데, 옮길 데이터가 줄어드니 토큰이 더 빨리 나온다. 이 효과는 요청당 지연이 중요한 저동시성 구간에서 가장 크다.
반면 prefill은 성격이 다르다. 연산에 묶여 있는 데다 INT4 가중치를 곱셈 전에 다시 펼쳐야 하므로 오히려 느려진다. GLM은 FP8에서 초당 약 10,160토큰의 prefill을 유지하지만 INT4에서는 8,660토큰에 그친다. 그래서 Cloudflare는 이를 타협이 아닌 선택으로 바꾼다. 이득이 나는 디코드에는 INT4를, 이득이 나는 prefill에는 FP8을 쓰는 것이다. 정확도는 모든 벤치마크에서 FP8 대비 0.8점 이내로, 사실상 구분되지 않는다. KV 캐시 양자화에서도 FP8과 BF16의 평가 결과는 동일했다.
밀도가 높아지면 무결성이 문제가 된다
두 기법 모두 결국 하나의 GPU 메모리를 훨씬 많은 요청이 나눠 쓰게 만든다. 효율의 핵심이지만, 동시에 수백 개의 요청이 같은 물리적 KV 캐시 페이지를 읽고 쓴다는 뜻이기도 하다. 페이지드 어텐션, 연속 배칭, 캐시 재사용 같은 고속화 장치는 전부 장부 관리를 정확히 맞추는 데 의존하는데, Cloudflare 정도의 요청량에서는 10억 분의 1 확률의 실수도 주기적으로 드러난다. 이를 막기 위해 도입한 것이 KV 캐시 무결성 검사다. 모든 물리 페이지에는 재할당될 때마다 바뀌는 태그가 붙고, 서버는 각 요청이 어떤 페이지와 태그를 기대하는지 기록한다. 디코드 연산이 캐시를 읽기 전에 이 대응을 확인해, 어긋나면 잘못된 페이지의 데이터를 반환하는 대신 해당 요청을 중단시킨다.
안전장치가 실제로 배포되느냐를 가르는 것은 결국 비용이다. 8,192토큰 입력과 1,000토큰 출력, 2-prefill·2-decode 구성의 중형 프로덕션 모델에서 측정한 결과, 처리량과 tail 지연 모두 1% 미만의 오버헤드에 그쳤고 95% 신뢰구간 상한도 1% 근처에 머물렀다. 검증을 어텐션 커널에 녹이면 GPU 스레드 그룹 간 경쟁이 생기므로, 이를 피해 별도 배치 검사로 돌린 것이 저비용의 비결이다. 배치별로 켜고 끌 수 있으며 기본 경로는 오버헤드가 없는 no-op 추적기라, 필요 없는 배치는 아무 비용도 치르지 않는다.
국내 실무자 입장에서 이 글이 주는 시사점은 분명하다. 대형 오픈 모델의 서빙 원가는 단일 요청의 속도가 아니라 메모리 밀도, 즉 한 GPU에 얼마나 많은 동시 요청을 상주시키느냐로 결정된다는 점, 그리고 prefill과 decode를 분리해 두면 정밀도 선택이 성능 손실 없는 '골라 쓰기'가 된다는 점이다. 다만 이 수치들은 특정 모델과 H200급 하드웨어, SGLang 환경에서의 값이므로 다른 모델·GPU·프레임워크에 그대로 옮겨 적용하기는 어렵고, 자체 워크로드에서의 재측정이 전제되어야 한다. Cloudflare는 앞으로 FP8 KV 캐시를 더 넓히고, Blackwell에서 NVFP4 가중치를 검증하며, 무결성 검사를 무시할 만한 비용으로 상시 켜 두는 방향을 예고했다.