AI의 인생은 B(Big Data)와 D(Deployment) 사이의 C(Choice)다

추론 비용의 승부처는 "무엇을 남기고 버릴 것인가"를 고르는 데 있어요. (좁은 책상 = 한정된 GPU 메모리)

안녕하세요, 아크릴 테크블로그의 음유시인 갈리엄(Galliam)입니다. 지난 주말 저는 집안의 안 입는 옷들을 한 무더기 정리하는 시간을 가졌어요. "이 옷, 과연 내가 입을까?"라는 질문 하나에 수많은 자켓과 셔츠, 바지들이 시험대에 올랐는데요, 무엇을 남기고 버릴지 고르는 과정이 정말 어렵더라구요(갈리엄의 살찜 이슈로 대부분 탈락의 고배를 마셨습니다). "무엇을 남기고 버릴 것이냐"라는 선택과 집중의 문제, 오늘은 우리 AI 산업에서 모델이 추론 과정에서 반드시 겪는 선택과 집중에 관련된 KV 캐시(Key-Value Cache)에 대한 재미난 이야기를 가져와봤습니다.

같은 GPU인데 추론 단가가 다른 이유

똑같은 GPU를 쓰는데도 어떤 때는 추론 비용이 낮고, 어떤 때는 유독 높은 것을 본 적이 있나요? 흔히 이런 문제를 두고"GPU가 부족해서 그렇다"고만 생각하기 쉬워요. 물론 GPU 공급도 중요한 요인이에요. 하지만 실제 추론 단가는 같은 칩을 쓰더라도 소프트웨어가 얼마나 효율적으로 요청을 묶고, 메모리를 관리하고, 유휴 시간을 줄이느냐에 따라 크게 달라져요. 핵심은 칩의 개수가 아니라, 같은 칩을 얼마나 높은 이용률로 안정적으로 굴리느냐거든요.

특히 긴 문서를 읽거나 긴 답변을 생성하는 모델은 이전 문맥을 계속 참조해야 해요. 이때 매번 처음부터 다시 계산하지 않으려고 중간 계산 결과를 GPU 메모리에 저장해 두는데, 이걸 KV 캐시라고 불러요. KV 캐시는 응답 속도를 높이는 데 필수적이지만, 문맥이 길어질수록 거의 선형적으로 커지기 때문에 비싼 GPU 메모리를 빠르게 점유해요.

결국 추론 비용은 단순히 "어떤 GPU를 쓰느냐"만의 문제가 아니에요. 같은 GPU 위에서도 KV 캐시를 얼마나 효율적으로 배치하고, 여러 요청을 어떻게 함께 처리하며, 메모리 낭비와 대기 시간을 얼마나 줄이느냐에 따라 실제 처리량과 단가가 크게 달라져요. 그래서 추론 인프라의 경쟁력은 칩 자체뿐 아니라, 그 칩을 알뜰하게 쓰게 만드는 소프트웨어 스택에서 갈려요.

문맥이 길어질수록 KV 캐시는 선형으로 불어나 GPU 메모리를 점유해요. 어느 지점부터는 모델 가중치보다 KV 캐시가 더 커져요. (개념 설명용 예시 수치)

필드에서는 무슨 일이 벌어지고 있냐면요

메모리 관리의 차이는 추론 비용을 책임지는 팀 입장에서 보면 체감이 확 돼요. 긴 문맥이나 추론을 돌릴 때 GPU 메모리를 가장 많이 잡아먹는 게 바로 이 KV 캐시거든요. 어떤 경우엔 모델 자체보다 더 많은 메모리를 차지할 정도에요.

그래서 연구자들은 이 메모리의 양을 줄이기 위해서 '덜 중요한 메모는 버리자'는 목표로 압축 기법을 만들어 왔어요. 품질을 지키면서 메모를 더 많이 버릴 수 있다면, 같은 GPU 한 대에 더 많은 일을 얹을 수 있으니까요. 지금까지는 주로 '최근에 자주 들여다본 토큰'을 제외한 나머지를 지우는 방향으로 만들어왔는데요, 얼마 전 Jushi Kai 연구팀의 InfoKV 논문이 이에 대해 새로운 기준을 제시했어요.

'얼마나 자주 봤는가' 대신 '얼마나 정보가 많은가'

학창시절 독서실에서 책상은 좁은데, 올려둘 책은 너무 많아서 골머리를 앓아본 경험 있나요? 과거의 메모리 압축 기술은 이 책상 위에 '방금 들춰본 책'들을 남기는 방식이었어요. 기술 용어로는 어텐션 가중치(attention weight)를 기준으로 토큰의 중요도(token importance)를 정하는 방법인데요. 이렇게 되면 당장 눈앞의 일에는 잘 맞지만, 먼 미래의 추론에 대해서는 성능을 보장할 수 없다는 단점이 있어요.

그래서 InfoKV는 책상에 '방금 들춰본 책'보다 '고난이도 문제가 있는 책'을 두기로 했어요. '고난이도 문제'라 함은 곧 예측 불확실성(high predictive uncertainty)을 의미하는데요, 이번 연구는 모델의 예측 불확실성이 높은 토큰일수록 미래의 추론 품질에 더 큰 영향을 미친다는 점을 관찰했어요. 실제로 어텐션 점수와 정보량 점수를 적당히 섞어서(논문 기본값은 어텐션 0.9) Llama-3.1, Llama-3.2, DeepSeek-R1 등으로 실험했을 때, 기존 어텐션 기반 압축 기법보다 우수한 결과를 보이기도 했고요. 눈앞의 2점 문제를 자주 푸는 것보다, 뒷장의 4점 문제를 푸는 것이 점수 향상에 더 도움이 되는 것과 비슷한 원리랄까요? (갈리엄도 그랬으면 얼마나 좋았을까요 흑)

InfoKV 개념도 — 어텐션 점수에 예측 엔트로피·레이어별 표현 변화라는 정보 신호를 결합해 남길 토큰을 골라요. (Kai et al., arXiv:2606.26875를 참고해 재구성)

결국은 '운영체제'가 풀어야 할 문제예요

그런데 이 논문에는 주의해야 할 점이 있어요. '켜두면 항상 이득인 설정'이 되는 마법의 값은 아직 없거든요. InfoKV 논문 스스로도 인정해요. 레이어마다 예산을 다르게 주는 방식이 어떤 모델에선 도움이 됐는데, 다른 모델에선 오히려 성능을 흔들기도 했거든요. 어텐션과 정보량을 섞는 비율도 과제마다 달랐고요. 즉, 최적값은 워크로드마다 달라서, 단순히 이 기술을 고객에게 전달만 할 경우 고객이 매번 손으로 맞출 수 있는 것이 아니에요. 이건 실제로 저희가 고객으로부터 가장 많이 듣는 말 중 하나이기도 해요.

"좋은 기술인 건 알겠는데, 우리는 매번 튜닝할 사람이 없어요"

사실 이건 완전히 새로운 문제가 아니에요. 과거 vLLM의 PagedAttention이 컴퓨터 운영체제(OS)의 가상 메모리 아이디어를 빌려 KV 캐시를 블록 단위로 관리했듯이, '무엇을/언제/어디에 둘지'는 원래 OS가 풀던 문제거든요. 개별 압축 기법 하나하나가 아니라, 특정 엔진·기법에 묶이지 않는 운영 계층이 워크로드를 이해하고 이런 선택을 대신해줄 때 비로소 현장에서 쓸 수 있는 기술이 돼요. 아크릴이 GPUBASE로 GPU 인프라의 '운영'에 집중하는 이유도 여기에 있어요. [확인 필요: GPUBASE 관련 최종 문구 — 개발팀 컨펌 후 확정]

이번 InfoKV 논문은 아직 코드도 공개되지 않았고, 성능 수치 또한 저자들이 직접 측정한 값인 만큼 조금 더 두고봐야 해요. 실제로 KV 캐시 압축이 특정 상황에서는 지시 이행 성능을 크게 떨어뜨릴 수 있다는 지적도 있고요. 하지만 그들의 발표가 업계에 전하고자 하는 메세지는 확실해 보여요. 바로 기술 그 자체보다는 OS와의 연계 가능성, 그리고 효율적인 운영의 중요성이에요.

맺음

저 갈리엄은 효율적인 AI 인프라 사용의 핵심이 '더 강력한 하드웨어' 혹은 '더 많은 하드웨어'에 있다고 생각하지 않아요. 지금 내가 가지고 있는 인프라 위에서 무엇을 남기고 무엇을 버릴지, 언제 압축하고 언제 옮길지를 더 똑똑하게 고르는 데있다고 생각해요. InfoKV 같은 연구가 반가운 이유도 여기에 있고요. 좋은 AI의 승부처가 더 이상 '칩 경쟁'이 아닌 '칩을 잘 굴리는 운영'으로 넘어오고 있다는 신호니까요.

B(Big Data)와 D(Deployment) 사이에서 AI의 성능을 결정지을 선택(Choice)의 기술, 저도 오늘부터 좀 더 신중한 선택을 하는 데 집중해봐야겠습니다. 이상, 아크릴의 음유시인 갈리엄이었습니다.

참고 자료

1. Kai, J., Xiao, Z., Birch, A., & Lin, Z., Information-Aware KV Cache Compression for Long Reasoning(arXiv:2606.26875) — https://arxiv.org/abs/2606.26875

2. Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H., & Stoica, I., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023, arXiv:2309.06180) — https://arxiv.org/abs/2309.06180

3. The Pitfalls of KV Cache Compression (arXiv:2510.00231) — https://arxiv.org/abs/2510.00231