우리가 사는 건 GPU가 아니라 HBM 아닐까?

우리는 정말 GPU를 사고 있는 걸까. 토큰 팩토리를 만들다 보면 이런 질문이 생긴다. 우리는 GPU를 사서 연산력을 확보하고, 그 연산력으로 토큰을 생산한다고 생각한다. 그래서 GPU를 비교할 때 FLOPS를 보고, 초당 몇 토큰이 나오는지 보고, 디코딩이 몇 배 빨라지는지를 본다. 그런데 실제 서비스를 운영하는 관점에서는 조금 다른 자원이 보인다. 우리가 돈을 내고 있는 것은 정말 연산력일까. 아니면 HBM을 시간 단위로 임대하고 있는 것일까. 긴 프롬프트를 한 번에 처리하고 짧은 답을 만드는 작업이라면 연산력이 중요하다. 행렬 연산을 얼마나 빠르게 밀어 넣느냐가 성능을 결정한다. 하지만 멀티턴 대화가 이어지고, 긴 문맥을 유지하면서 계속 토큰을 생성해야 하는 순간부터 이야기가 달라진다. 이때 희소해지는 자원은 FLOPS만이 아니다. HBM, 즉 메모리다. 모델 본체보다 사용자의 문맥이 더 많은 메모리를 차지하는 경우도 생긴다. 모델 weight가 20GB 남짓이어도, 몇 개의 동시 세션만으로 KV Cache가 50~60GB를 점유할 수 있다. 모델이 기억해야 하는 문맥이 모델 자체보다 더 커지는 것이다. HBM을 부동산에 비유하면 이해하기 쉽다. 모델 weight는 건물의 공용시설이고, 각 사용자의 KV Cache는 입주한 세입자다. 세입자가 실제로 일을 하고 있든, 잠시 기다리고 있든, 퇴거하지 않는 이상 공간은 계속 점유한다. 코딩 에이전트가 대표적이다. 에이전트는 토큰을 생성하는 시간보다 코드를 실행하고, 테스트 결과를 기다리고, 원격 서버에 접근하고, 오류를 확인하는 데 더 많은 시간을 쓸 수 있다. 그동안에도 에이전트의 문맥은 살아 있어야 한다. 캐릭터 챗봇은 더 극단적이다. 모델이 답변을 1초 만에 만들어도 사용자가 다음 메시지를 30초 뒤에 보낸다면, 그 세션의 문맥은 계속 메모리를 차지한다. 디코딩이 20배 빨라져도 사람이 답장하는 속도나 테스트 결과를 기다리는 시간까지 20배 빨라지지는 않는다. 따라서 디코딩 성능이 20배 좋아졌다고 해서 같은 HBM으로 20배 많은 세션을 처리할 수 있는 것은 아니다. 이 관점에서 보면 토큰의 원가는 단순한 $/GPU-hour가 아닐 수 있다. 오히려 $/GB·hour, 혹은 $/KV-cache·hour가 실제 서비스 경제성을 더 잘 설명할지도 모른다. 토큰 팩토리가 최적화해야 하는 것은 GPU 한 장에서 초당 몇 토큰을 생산하느냐만이 아니다. 한정된 HBM에 얼마나 많은 문맥을 입주시키고, 그 문맥을 얼마나 오래 유지하며, 언제 효율적으로 퇴거시키느냐가 더 중요할 수 있다. Prefix Cache, KV Cache 압축, offloading, eviction, session scheduling이 단순한 서빙 최적화가 아니라 토큰 팩토리의 원가 구조를 바꾸는 기술이 되는 이유다. GPU 회사는 우리에게 FLOPS를 판다. 우리는 고객에게 토큰을 판다. 그런데 그 사이에서 실제로 가장 비싼 자원을 점유하는 것은 어쩌면 연산 자체가 아니라 문맥의 시간일 수 있다. 그래서 요즘은 이렇게 생각한다. 우리는 GPU를 사고 있는 것이 아닐지도 모른다. 토큰 팩토리의 관점에서 우리가 실제로 지불하는 것은 HBM이라는 메모리의 시간당 임대 비용일지도 모른다. 출처: 고석현님 페이스북