[테크다이브] 구글 ‘터보퀀트’로 불붙은 메모리 장벽 "뭣이 중헌디" 작성일 04-04 29 목록 <div id="layerTranslateNotice" style="display:none;"></div> <strong class="summary_view" data-translation="true">[메모리 월 대응] ① 급증한 KV캐시, 압축으로 효율 높인다…상용화가 난제</strong> <div class="article_view" data-translation-body="true" data-tiara-layer="article_body" data-tiara-action-name="본문이미지확대_클릭"> <section dmcf-sid="2xvnxhd8y9"> <figure class="figure_frm origin_fig" contents-hash="460592b6774bf1765fb4e73258153ebe2fa1e4db155a42a697145f0d2dece2ce" dmcf-pid="VMTLMlJ6yK" dmcf-ptype="figure"> <p class="link_figure"><img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070012352qjks.jpg" data-org-width="640" dmcf-mid="bZs5y4Hlvf" dmcf-mtype="image" height="auto" src="https://img4.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070012352qjks.jpg" width="658"></p> </figure> <p contents-hash="a7ea848bc9be75a2c5eca91c4d0630c35c69fedcd36d66ae8db655f7407d7e97" dmcf-pid="fRyoRSiPSb" dmcf-ptype="general">[디지털데일리 고성현기자] 최근 등장한 구글의 한 논문 '터보퀀트(TurboQuant)'가 국내외 증시에 폭풍을 몰고 왔습니다. 인공지능(AI) 인프라 확대의 걸림돌이 됐던 메모리 장벽(Memory Wall)을 타개할 안이 제시되면서 메모리 무용론이 제기된 영향이죠.</p> <p contents-hash="80e77908fe89b348cbc3a72a13926f8174766c64b3e325494b5dd4d02815fdd9" dmcf-pid="4eWgevnQyB" dmcf-ptype="general">최근에는 '제번스의 역설'을 필두로 한 메모리 수요 상승 의견이 신빙성을 얻으며 회복 추세를 타기도 했습니다. 다만 이번 터보퀀트 쇼크로 향후 AI 인프라의 미래를 좌우하는 핵심 요소는 메모리라는 점은 더욱 분명해지는 모습입니다.</p> <p contents-hash="3005077d6cb3c7b4b02e79b2137439b8bee85834d896c87cfa06a3e8addd9f11" dmcf-pid="8dYadTLxWq" dmcf-ptype="general">현재 AI 인프라에서 발생하는 메모리 병목은 단일 지점이 아니라 다층적인 구조에서 나타납니다. AI 연산을 수행하는 랙(Rack) 내부는 물론, 랙과 랙 간 연결 구간, 나아가 AI가 참조하는 데이터베이스(DB)와 이를 구성하는 스토리지(Storage) 영역과 연산 노드(Node) 간에서도 병목이 발생합니다. 이번 테크다이브에서는 이 가운데 랙과 스토리지 간 데이터 이동 과정에서 발생하는 병목, 특히 GPU와 HBM의 병목에 초점을 맞춰 살펴보겠습니다.</p> <p contents-hash="189f81e49f66270cd5d6d25ebcaf31676990ae26cbab4a4adb87a11632dc73bd" dmcf-pid="6tn7tdpXvz" dmcf-ptype="general">AI가 사용자 요청을 처리하기 위해서는 몇 가지 핵심 요소가 필요합니다. 우선 용도에 맞는 AI 모델이 있어야 하고 이 모델이 실시간 정보를 반영할 수 있도록 외부 데이터를 제공하는 DB가 필요합니다. 여기에 사용자 질의를 해석하고 필요한 데이터를 불러오는 CPU 기반 제어 영역과 실제 추론 연산을 수행하는 GPU 기반 연산 영역이 결합된 노드 영역이 결합돼 하나의 처리 구조를 이룹니다.</p> <p contents-hash="967dd9d6d3ffa7a67206eed17db275468959042c0d85e8bf0e4efcaceadc56e2" dmcf-pid="PFLzFJUZT7" dmcf-ptype="general">이 과정에서 모델 매개변수(Parameter)와 원천 데이터(Raw data)는 스토리지와 메모리 계층에 분산 저장됩니다. DB는 이를 효율적으로 검색·제공하는 역할을 맡습니다. 반면 CPU와 GPU로 구성된 서버 노드는 사용자 요청에 따라 데이터를 불러오고 연산을 수행하는 실행 주체입니다. 결국 AI 서비스는 저장된 데이터를 얼마나 빠르게 불러오고, 이를 얼마나 효율적으로 연산에 연결하느냐에 따라 성능이 좌우되는 구조죠. 쉽게 말하면 스토리지에 있는 정보를 불러와 CPU가 정리하고 GPU가 실제 답변을 만들어내는 식입니다.</p> <p contents-hash="a8549b06e90ff5599df7bec367fbd5add2f5b4f86583cface0c14461b13067d5" dmcf-pid="Q3oq3iu5Su" dmcf-ptype="general">해당 구조에서는 사용자의 응답 요청을 처리하기 위해 생성되는 데이터가 있습니다. 바로 KV캐시입니다. KV캐시는 모델이 새로운 답변을 생성할 때 앞선 토큰 정보를 다시 활용하기 위해 만들어진 데이터로, 각 토큰의 키(Key)와 값(Value)을 저장해두고 반복적으로 참조할 수 있도록 합니다. 이를 활용하면 중복된 질문에 동일한 연산을 반복하지 않아도 돼 추론 속도를 높일 수 있죠.</p> <div contents-hash="9734e07019393cb6cf7f10787da557c598a13fe2c599dda5b2afa35ce0078217" dmcf-pid="x0gB0n71hU" dmcf-ptype="general"> 문제는 AI 모델이 고도화되고 에이전트(Agent) 방식이 늘면서 KV캐시 용량이 급증하고 있다는 겁니다. 사용자의 요청이 복잡다단해지면서 크기가 증가하고, 이전에도 쌓여 있던 KV캐시들도 계속해 저장이 되면서 HBM의 단점으로 꼽히는 용량 한계를 크게 압박하고 있는 셈이죠. 여기에 사용자 요청을 동시 처리하거나 이미지, 영상을 처리하는 멀티모달 데이터가 결합되면서 정보량 자체도 크게 증가해 HBM가 감당할 수 없는 숫자로 불어났습니다. </div> <figure class="figure_frm origin_fig" contents-hash="aeb5f2b5852e8988e3caef528db3826709f5416aa10a3a284e77c32f8e7fdf6f" dmcf-pid="yNFwN5kLSp" dmcf-ptype="figure"> <p class="link_figure"><img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070013844qhgu.jpg" data-org-width="640" dmcf-mid="KTKTOqlwyV" dmcf-mtype="image" height="auto" src="https://img3.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070013844qhgu.jpg" width="658"></p> </figure> <p contents-hash="e6fa3a6032baec720d8643dd40cc1c5ae0897e9aa585845ee7980f24696e711d" dmcf-pid="Wj3rj1Eol0" dmcf-ptype="general">이로 인해 등장한 것이 바로 KV캐시 계층화입니다. 중요도와 사용빈도에 따라 핫(Hot)·웜(Warm)·콜드(Cold)로 나누고 이를 각각 HBM·시스템 메모리(D램)·SSD에 내려보내는 식으로 효율적으로 관리하기 시작한 거죠. 최근 엔비디아가 제시한 ICMS(Inference Context Memory Storage) 구조도 이와 마찬가지의 개념입니다. 자주 사용하지 않는 콜드 KV캐시를 SSD에 내려보내고, 필요할 때만 HBM에 올려두는 식으로 부담을 줄이겠다는 뜻이죠.</p> <p contents-hash="34cd6b1b6787576cee6a91e6909911694d7b85a0ba1718292c332d4c43eef176" dmcf-pid="YA0mAtDgy3" dmcf-ptype="general">이 역시 근본적인 해결 방식은 아니라는 의견이 많습니다. 결국 HBM과 SSD가 함께 KV캐시를 관리하려면 양 장치 간 속도의 균형이 맞아야 합니다. 하지만 SSD가 현저히 느린 탓에 GPU가 SSD로부터 오는 데이터를 기다리면서 연산을 멈추거나 트래픽 급증에 유연하게 대처하지 못하게 될 수 있습니다.</p> <div contents-hash="2cd05351a6bfc9089d182d6f6d0cae41cd18d5a03b2dd6f2d79083b147401046" dmcf-pid="GcpscFwaTF" dmcf-ptype="general"> 구글이 제시한 터보퀀트는 여기서 발생한 문제를 줄일 수 있다는 점에서 의미가 있습니다. KV캐시를 계층화해 문제를 푸는 것이 아니라, KV캐시 자체의 용량을 낮춰 성능 효율을 높이겠다는 이유에서죠. </div> <figure class="figure_frm origin_fig" contents-hash="70eefd5d92d8e50757ef934ad26e766da02f4bd25541a299e76993d7329e20fc" dmcf-pid="HkUOk3rNlt" dmcf-ptype="figure"> <p class="link_figure"><img class="thumb_g_article" data-org-src="https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070014142zpxt.png" data-org-width="463" dmcf-mid="9wuIE0mjy2" dmcf-mtype="image" height="auto" src="https://img4.daumcdn.net/thumb/R658x0.q70/?fname=https://t1.daumcdn.net/news/202604/04/552796-pzfp7fF/20260404070014142zpxt.png" width="658"></p> </figure> <p contents-hash="cc3585fab0a30c59c47acf811d121137af5dcb36ccbf97a8b41b938bd54065ab" dmcf-pid="XEuIE0mjv1" dmcf-ptype="general">터보퀀트는 크게 두 단계로 나눠 데이터를 압축하는 구조를 갖고 있습니다. 데이터를 압축하는 폴라퀀트(PolarQuant)와 QJL(Quantized Johnson-Lindenstrauss) 방식을 활용합니다.</p> <p contents-hash="b807a3687f4aadbc77bd234f920a515a08b8f3993c774aa52a38e8ad06c114a0" dmcf-pid="ZD7CDpsAh5" dmcf-ptype="general">우선 첫 단계인 폴라퀀트(PolarQunat)에서는 입력 벡터(Vector)의 좌표계를 재구성에 값의 분포를 균일하게 만든 뒤, 이를 일정한 규칙에 따라 낮은 비트(Bit)로 변환합니다. 기존 방식대로 각 좌표값을 그대로 줄이는 게 아니라 데이터를 방향과 크기로 변환해 압축하기 유리한 구조로 바꾼다는 뜻입니다.</p> <p contents-hash="f5c54c106f72bc9347f93e617ebb834a905c37a881170edb2b5f6dc1d7c0ce8d" dmcf-pid="5wzhwUOcWZ" dmcf-ptype="general">압축은 표현 가능한 정보량을 줄이는 것이기에 필연적으로 정보 손실이 발생합니다. 폴라퀀트에서 압축된 데이터는 정확한 값을 담는 게 아닌 가까운 값으로 대체되는 겁니다. 이 손실을 줄이려면 실제 데이터와의 유사도 구조가 유지되도록 오차를 보정해주는 과정이 필요합니다. 이 방식이 두번째 단계인 QJL입니다. 이 과정을 거쳐 급증한 KV캐시의 용량을 1/6 수준으로 줄이면서도 성능 저하를 거의 없앨 수 있다는 게 주된 요지입니다.</p> <p contents-hash="0e5ec8a4bb78761ba0ce2eb0da3bb672f4bd811d451993e90e4272df5b4bd941" dmcf-pid="1C2WCbvmWX" dmcf-ptype="general">만약 터보퀀트 알고리즘이 데이터센터에 실제 적용이 되면 KV캐시로 겪는 메모리 용량 압박이 확 줄어들게 됩니다. 현재 있는 HBM 기준으로도 더 많은 메모리 여유가 확보되고, 그만큼 병목 현상도 크게 줄일 수 있습니다. 현재 막대한 비용을 요하는 인프라 투자를 줄이면서도 더욱 효과적인 서비스를 제공할 수 있게 되는 겁니다.</p> <p contents-hash="d5b8966808d20da6ceac50e7c793c4a216e79ee0e7397248f6b55e1cc4554fda" dmcf-pid="thVYhKTsvH" dmcf-ptype="general">역설적으로는 메모리 수요를 더욱 높이고 고도화된 AI 발전을 이룰 수 있는 토대가 될 수도 있습니다. 이른바 '제번스의 역설' 효과가 나타날 수 있다는 뜻이죠. 구체적으로는 KV캐시 부담이 줄면서 생긴 여유로 다른 멀티모달 기반 서비스를 제공하거나 더 많은 사용자들의 요청을 한꺼번에 처리할 수도 있을 겁니다.</p> <p contents-hash="9ebed63b46e2bf24dd4c6e1f35ef64c10a9a6983288a47b077e92c7fbaa2a037" dmcf-pid="FlfGl9yOhG" dmcf-ptype="general">다만 이러한 터보퀀트 방식이 언제 적용될지, 실제로 그 성과를 상용화로 이뤄낼 수 있을지에 대해서는 아직 의문부호가 붙습니다. 구글리서치 블로그를 통해 공개된 실험 결과가 일부 모델을 대상으로 제한적으로 이뤄진 만큼, 대규모 데이터센터 환경에서 다양한 모델과 워크로드에서도 동일한 효과가 나타는지는 검증되지 않았기 때문입니다. 특히 수많은 사용자 요청이 동시 처리되는 환경에서는 KV캐시에 대한 접근 패턴과 데이터 이동이 훨씬 복잡해, 실제 성능과 안정성에서는 아직 미지수입니다.</p> <p contents-hash="a32e108557080c3f9faf6c1d9faec287f92528e8a939dc3cdbdd6b2a880217a9" dmcf-pid="3S4HS2WICY" dmcf-ptype="general">결국 터보퀀트와 같은 압축 방식의 고도화와 함께 이전에 언급한 메모리 계층화 방식의 발전도 병행돼야 할 겁니다. 하나의 기술만으로는 해결하기 어려울 만큼 복잡해졌기 때문이죠. 다음 편에는 메모리 계층화 방식의 발전을 위해 추진되고 있는 다양한 기술과 국내 기업들의 노력들을 소개해보도록 하겠습니다.</p> </section> </div> <p class="" data-translation="true">Copyright © 디지털데일리. All rights reserved. 무단 전재 및 재배포 금지.</p> 관련자료 이전 ‘우월한 유전자’ 그 이상의 시너지... 스타 형제·자매들 맹활약 [스타와치] 04-04 다음 뭉치면 산다? 통신3사 'AX 뉴노멀'은…"그룹사·빅테크 총동원" 04-04 댓글 0 등록된 댓글이 없습니다. 로그인한 회원만 댓글 등록이 가능합니다.
