왜 큰 오픈 모델은 GPU가 아니라 GPU 메모리에서 먼저 막히고, 이 글은 그 병목을 어떻게 풀려 하나요?

요약 듣기

0:009:47

요약 보기

이 글은 좋은 오픈 모델을 서비스하는 일이 왜 어려운지부터 짚어요. 클라우드플레어는 사용자 가까운 데이터센터의 GPU에서 Kimi K 시리즈와 GLM 같은 큰 모델의 추론을 돌린다고 하는데, 문제는 이런 모델이 크고 긴 문맥을 다루다 보니 메모리 요구가 아주 크다는 점이에요. 여기서 추론은 모델을 새로 학습시키는 게 아니라, 이미 있는 모델이 입력을 받아 답을 만들어 내는 운영 단계라고 이해하면 돼요. 또 긴 문맥 모델이라는 말은 긴 대화나 긴 문서를 한 번에 참고할 수 있다는 뜻인데, 그 편리함 뒤에는 중간 상태를 오래 들고 있어야 한다는 비용이 붙어요. 원문에 나오는 mixture-of-experts의 내부 동작까지는 여기서 자세히 풀지 않지만, 적어도 서비스하기 까다로운 대형 모델이라는 맥락은 분명해요.

글의 큰 방향은 단순히 모델 하나를 더 빠르게 만드는 요령이 아니라, 같은 GPU 자원으로 더 많은 요청을 안전하게 처리하는 운영 전략에 가까워요. 글쓴이들은 이미 prefill과 decode를 분리해 운영하고 있었고, 그 위에 세 가지를 더 얹었다고 말해요. KV 캐시를 더 작게 저장하고, 모델 가중치도 더 작게 압축하고, 그 결과 더 많은 요청이 같은 하드웨어와 캐시를 공유하게 되니 그 공유 상태를 보호하겠다는 거예요. 그리고 이런 실험과 실제 운영 트래픽은 SGLang이라는 프레임워크에서 측정했다고 밝혀요. 즉, 성능 수치가 어떤 환경에서 나온 것인지도 같이 알려 주는 셈이에요.

여기서 핵심 배경지식 하나가 KV 캐시예요. 모델은 문장을 생성하면서 앞에서 이미 처리한 토큰들의 K와 V를 저장해 두는데, 이 저장소가 있어야 다음 토큰을 만들 때마다 앞의 긴 문맥을 처음부터 다시 읽지 않아도 돼요. 이해를 위해 긴 계약서를 읽으며 중요한 줄마다 접착 메모를 붙여 두는 장면을 떠올려 보면 돼요. 메모가 많을수록 다시 찾기는 쉬워지지만, 메모 자체가 책상 공간을 차지하듯이, 긴 문맥 모델에서는 이 캐시가 아주 빨리 커져요. 그래서 글은 종종 모델 가중치보다 KV 캐시가 먼저 GPU 메모리를 채운다고 설명해요. 서비스 병목이 계산량 자체가 아니라, 이 중간 상태를 어디에 얼마나 담아 둘 수 있느냐에서 생긴다는 뜻이에요.

첫 번째 해법은 그 KV 캐시를 BF16 대신 FP8로 저장하는 거예요. 저장 정밀도를 낮춰 크기를 절반으로 줄이면, Kimi K2.6에서는 메모리에 잡아 둘 수 있는 문맥이 대략 68만 6천 토큰에서 137만 토큰 정도로 늘었다고 해요. 그런데 글쓴이들이 특히 강조하는 건, 이 이득이 토큰 하나를 계산하는 순간속도에서 바로 나오지는 않는다는 점이에요. FP8 캐시는 읽을 때 변환 작업이 조금 더 들어가서, 같은 동시성 수준만 놓고 보면 BF16이 토큰당 속도는 몇 퍼센트 더 빠를 수 있다고 해요. 대신 진짜 차이는 동시에 몇 개 요청을 메모리에 붙잡아 둘 수 있느냐에서 생겨요. BF16은 동시 요청 32개에서 메모리 한계에 걸리지만 FP8은 64개까지 가고, 그 결과 전체 처리량과 토큰당 비용에서 더 유리했다고 글은 주장해요.

여기서 prefill과 decode를 나눠 보는 이유도 자연스럽게 드러나요. decode는 답을 한 토큰씩 이어서 생성하는 단계라서, 많은 요청을 동시에 메모리에 유지할 수 있으면 이득이 커져요. 반면 글쓴이들 설명에 따르면 prefill은 메모리보다 계산량의 제약을 더 받는 구간이라, 여기서는 FP8 캐시로 줄였을 때 얻는 장점보다 BF16의 약간 더 높은 처리량이 더 중요해요. 그래서 이들은 한 가지 숫자 표현을 시스템 전체에 획일적으로 쓰지 않고, 어느 단계가 무엇에 막히는지에 따라 다르게 선택한다고 말해요. 또 FP8 캐시가 답변 품질을 흔들지 않는지 평가 세트로 확인했고, 자신들의 평가에서는 BF16과 구분되지 않았다고 보고해요. 다만 이건 어디까지나 이들이 사용한 평가와 배치 방식에서의 주장으로 읽는 게 맞아요.

두 번째 해법은 모델 가중치 압축이에요. GPU 메모리를 먹는 두 축이 KV 캐시와 가중치라면, 첫 번째는 대화 기록을 줄이는 방법이었고 두 번째는 모델 본체를 더 작게 싣는 방법이라고 보면 돼요. GLM 5.2에서는 가중치를 FP8에서 INT4로 압축했고, 체크포인트 크기가 705GB에서 421GB로 줄었다고 해요. 또 8개 GPU에 나눠 올린 배치에서는 GPU 하나당 메모리 사용량이 대략 88GB에서 52GB로 내려갔다고 해요. 중요한 표현은 그 다음인데, 이 변화로 같은 하드웨어에서 KV 캐시를 약 118만 토큰 정도 담을 수 있는 공간이 남는다고 설명해요. 기존보다 118만 토큰을 추가로 더 담는다고 단정하는 게 아니라, 압축 뒤의 메모리 예산 안에서 그 정도 KV 캐시를 둘 여유가 생긴다는 뜻으로 읽어야 해요.

가중치를 줄였을 때 왜 decode가 빨라지는지도 글은 꽤 분명하게 설명해요. 토큰을 하나 생성할 때마다 GPU 메모리에서 가중치를 계속 읽어 와야 하니, decode는 메모리 대역폭의 영향을 크게 받는다는 거예요. 상자를 옮기는 일이 병목인 창고라면, 상자 자체를 작게 만들었을 때 효과가 바로 나는 것과 비슷해요. 실제로 글의 수치에서는 동시 요청이 1개일 때 INT4가 FP8보다 초당 토큰 수가 55% 높았고, 요청 수가 늘어도 계속 이득이 남아요. 하지만 이것도 모든 단계에 그대로 통하는 건 아니에요. prefill은 계산량이 더 중요한 구간이라, INT4 가중치를 계산 전에 다시 펼쳐야 하는 추가 작업 때문에 오히려 FP8보다 느려졌다고 해요. 그래서 여기서도 글쓴이들은 decode에는 INT4, prefill에는 FP8을 쓰는 식으로 나눠 운영한다고 설명해요. 품질 역시 자신들의 벤치마크에서는 FP8과 사실상 구분되지 않는 수준이라고 주장해요.

세 번째 해법은 앞의 두 최적화가 만든 새로운 위험을 다뤄요. 캐시와 가중치를 줄여서 한 GPU에 더 많은 요청을 태우면, 효율은 좋아지지만 동시에 수많은 요청이 같은 물리적 KV 캐시 페이지를 읽고 쓰게 돼요. 글은 paged attention, continuous batching, cache reuse 같은 장치들이 이런 공유를 빠르게 만들어 주지만, 대신 장부 정리가 아주 정확해야 한다고 말해요. 요청량이 크면 극히 드문 실수도 실제 운영에서는 반복해서 드러날 수 있으니까요. 그래서 이들은 KV 캐시 무결성 검사를 방어층으로 넣었다고 설명해요. 각 캐시 페이지에 재할당될 때마다 바뀌는 태그를 붙이고, 각 요청이 어떤 페이지와 태그를 기대하는지 기록해 두었다가, decode가 캐시를 읽기 전에 맞는지 확인하는 방식이에요. 어긋나면 잘못된 데이터를 내보내는 대신 그 요청을 중단한다고 해요. 속도를 위해 공유를 늘렸다면, 그 공유가 안전한지 감시하는 장치도 같이 있어야 한다는 논리예요.

안전장치는 좋아도 너무 비싸면 실제 서비스에 못 넣겠죠. 그래서 글쓴이들은 이 검사 비용도 따로 재 봤다고 해요. 자신들이 측정한 중간 규모 운영 모델과 특정 입력·출력 길이 조건에서는 처리량과 p95 지연시간 변화가 둘 다 1% 미만이었다고 보고해요. 이 비용을 낮추기 위해 attention 커널 안에 검사를 억지로 합치지 않고, 별도의 배치 검사로 돌렸다고 설명해요. 커널 안에 섞으면 GPU 스레드 그룹 사이 경쟁 상태가 생길 수 있다는 이유도 붙여요. 다만 이 부분은 특히 조건을 붙여 읽어야 해요. 원문 수치는 특정 배포 구성에서의 측정값이고, 기능도 배포별로 켜고 끌 수 있으며, 기본 경로는 사실상 오버헤드가 없도록 설계했다고 말할 뿐이에요. 그러니 모든 모델과 하드웨어에서 언제나 같은 비용이라고 일반화하기보다는, 글쓴이들이 실제 운영에 넣을 만한 수준으로 낮췄다고 주장하는 정도로 받아들이는 게 안전해요.

마지막으로 이 글은 이 작업을 끝난 해법이 아니라 계속 움직이는 과제로 묘사해요. 더 많은 장비에 FP8 KV 캐시를 확대하고, 다른 가중치 형식도 검증하고, 무결성 검사를 거의 비용 없이 널리 켜 둘 수 있게 만들겠다는 계획을 말해요. 그리고 이런 최적화가 더 많은 고객을 더 낮은 비용으로, 같은 정확도로 지원하는 데 도움이 될 것이라고 전망해요. 핵심을 한 문장으로 잡아 보면 이래요. 큰 모델 서빙의 병목은 단순히 연산이 무겁다는 데만 있지 않고, 어떤 단계는 메모리에 막히고 어떤 단계는 계산에 막히기 때문에, 단계마다 다른 압축과 정밀도를 쓰고, 그 대가로 커진 공유 위험은 별도 안전장치로 다뤄야 실제 운영 이득이 난다는 게 글쓴이들의 주장입니다.