EP 112
AI 반도체 안에서 일어나는 일들: KV Cache부터 Roofline까지
AI 인프라로 이동하는 가치 포착 00:00
노정석 녹화를 하고 있는 오늘은 2026년 8월 30일 일요일 아침입니다. 오늘은 HyperAccel의 이진원 CTO님을 모셨습니다. 저희가 요새 소식이 너무 많잖아요. 그런데 소식을 좀 배치해 보면, 저 아래 데이터센터부터 칩, 모델, 그리고 그 위의 애플리케이션까지 다양한 레이어가 있는데, 요새 느껴지는 게 모델 쪽의 발전이 너무 빠르게 일어나다 보니까 이른바 가치 포착이라고 하죠. 돈을 실질적으로 벌어내는 구간이 아래 인프라 쪽으로 이동하는 것, 그리고 위의 좀 더 애플리케이션 쪽으로 이동하는 것, 이 두 가지 트렌드를 저희가 느끼고 있는데요. 오늘은 굉장히 중요한 이야기를 저희가 모시고 수업으로 들을 텐데요. 이 아래쪽에 대한 이야기입니다. 저희가 도대체 전력을 투입해서 칩을 구성하고, 그 안에 training된 모델을 넣어서 고객들에게 어마어마한 inference를 제공하고 있단 말이죠. 그 안에서 어떤 일이 일어나고 있는지, 그리고 그 안의 벤치마크를 읽기 위해서는 무엇을 이해해야 하는지, 저희가 승준님과 함께 이 얕은 지식을 가지고 얼마 전에 Dwarkesh의 roofline analysis를 하면서 inference 이야기를 한 번 다뤘고, 그 이후로도 inference 이야기를 굉장히 자주 하고 있는데요. 자주 하고 있는 이유는 그게 굉장히 중요하기 때문이겠죠. 오늘은 그것의 끝판왕 수업 에디션입니다. 저희 이진원 CTO님의 강연을 한 번 찬찬히 따라오시면 SemiAnalysis에서 새롭게 나오는 각종 벤치마크들, 그리고 NVIDIA에서 발표하는 것들, 또 칩 회사에서 발표하는 것들을 이해하실 수 있게 되니까요. 오늘 모시고 한 번 들어보도록 하겠습니다. CTO님, 어서 오십시오.
이진원 안녕하세요. 반갑습니다. 오랜만에 또다시 출연했습니다.
노정석 오늘 정말 내용이 너무너무 깊고 방대해요. 그래서 시간이 얼마나 들더라도 저희에게 찬찬히 가르쳐 주셨으면 좋겠고요. 잘 부탁드립니다.
최승준 Dwarkesh 이야기한 게 5월이었지 않아요? 벌써
노정석 한 3개월 정도가 지났는데, 그사이에도 AI 세상의 3개월이니까 3년 지났다고 봐야죠.
영원한 compute 부족과 폭발하는 토큰 수요 02:13
이진원 시작해 볼까요? 오늘 제가 말씀드릴 내용은 inference engineering과 관련된 이야기입니다. 지금 여러분도 AI를 굉장히 많이 쓰고 계실 텐데, 도대체 주로 쓰이는 GPU 혹은 다른 AI 반도체에서 어떤 일들이 일어나고 있는지를 어려운 내용이지만 제가 최대한 쉽게 오늘 설명해 드릴 거고요. 저희 회사와 관련된 이야기를 먼저 앞부분에서 하고, 본격적으로 시작해 보도록 하겠습니다. 이게 올해 4월에 Sam Altman이 OpenAI Forum에서 이야기했던 내용을 가져온 건데, 여기 보시면 compute crunch라고, compute가 굉장히 부족한 세상에 살고 있는데 거기서 언제 벗어날 수 있을 거냐, 이런 이야기를 OpenAI 사람들과 수년간 해 왔는데, 지금 생각으로는 아마 앞으로 우리가 영원히 이것을 벗어나지 못할 것 같다. 그러니까 우리가 항상 compute가 부족한 세상에 살 거라는 이야기를 하고 있어요. 그만큼 training이든 inference든 compute가 부족한 상황에 있습니다.
그걸 또 잘 보여 주는 게 5월 Google I/O에서 발표한 건데, 자기네 GCP에서 토큰 사용량을 조사해 봤더니 월간 사용량이 12개월 만에 50배로 늘었다고 발표했고요. 그리고 제가 작년 9월에 AI Infrastructure Summit이라는 곳에 갔는데, 그때 Google에서 또 나와서 발표하기를 그로부터 두 달 만에 다시 2배가 늘어서 14개월 만에 100배가 됐다는 이야기를 했어요. 그리고 지금은 어떻게 됐느냐? 다시 거기서 또 많이 늘어서 처음 2024년과 비교해서 330배 정도로, 엄청난 폭발적 수요가 있다는 이야기를 계속하고 있고요. 모델도 다들 잘 아시지만 계속 커지고 있습니다. 여기 나와 있는 것은 비공식 추정도 있고, 최근에 Fable 5가 8T 파라미터 정도 된다는 이야기도 들었는데, 한동안 모델이 많이 커지지 않는 것처럼, 수T 파라미터에서 더 커지지 않는 것처럼 보이다가 Mythos는 10T 파라미터라는 이야기도 있을 정도로 모델 스케일도 다시 커지고 있습니다.
그리고 이걸 소화하기 위해서 전 세계적으로 데이터센터를 엄청나게 짓고 있죠. GW 데이터센터라고 해서, 여기 보시면 오른쪽에 2030년까지 데이터센터에 약 6.7조 달러 정도, 그러면 이게 대충 한화로 따지면 거의 1경 원 정도 될 것 같은데요. 그리고 우리나라도 지금 4대 메가프로젝트라고 해서 2035년까지 18.4GW 규모로 우리나라 땅에 데이터센터를 짓겠다고 하고 있고요. 이렇게 하다 보니까 다들 많이 이야기하시다시피 전기가 문제입니다. 전력을 어떻게 공급할 거냐에 대한 이야기를 누구나 다 하고 있고, 여기 보면 미국에서 데이터센터를 지어서 거기에 전기가 들어오는 데까지 평균 5년 정도 걸리더라. 그리고 우리나라 수도권에서 데이터센터 전력 심사를 하면 절반 이상 탈락하더라는 이야기들이 계속 나오고 있고요. 그래서 전력이 굉장히 문제고, 또 하나는 이것도 Dwarkesh 팟캐스트에 나왔던 건데, Anthropic이 지금 3년 연속 매출을 10배씩 성장시키는 회사가 되고 있는데, 이 프론티어 랩들에서 compute, 즉 연산은 1년에 3배씩 더 늘리고 있습니다.
매출·compute 격차가 밀어 올리는 inference 단가 05:17
이진원 그러면 1년에 3.3배씩 간극이 벌어지게 되는데요. 그럼 GPU compute는 3배씩 더 늘어나는데 매출은 10배 늘어나는 이 간극을 어떻게 해석할 거냐 하면, 세 가지 방법이 있는데요. 첫 번째는 inference할 때 마진을 올려서 매출을 늘리는 방법이 있겠죠. 그런데 지금 이미 Anthropic의 inference 마진이 70~80%라고 알려져 있고, 이게 상한이 90%라고 보면 거의 올라갈 여지가 얼마 남지 않았습니다. 그리고 두 번째는 내가 GPU를 100개, 100대를 가지고 있으면 그중 지금은 70대를 training에 쓰고 30대를 서비스에 쓰고 있다면, 그 비중을 5 대 5로 늘려서 inference에 사용하는 GPU 비중을 늘리면 거기서 매출이 발생할 테니까 똑같은 compute로 매출을 올릴 수 있는 방법이 되겠죠. 그런데 지금 대략 5 대 5 정도 되는 것으로 알려져 있는데, 이것을 더 늘리기는 힘들다고 사람들이 많이 이야기하고 있습니다. 왜냐하면 training에 쓰는 비중을 줄인다는 것은 모델 개발에 힘을 빼겠다는 것이고, 그러면 지금 이 프론티어 랩들은 생존이 힘든 상황이잖아요. 그래서 이것도 많이 올리기는 힘든 상황입니다. 그러면 남은 건 무엇이냐 하면, 결국에는 compute의 단가가 오르는 것밖에 없고요. 그래서 지금 neocloud 회사들이나 이런 회사들에서도 굉장히 수익이 잘 나고 있고, 단기 임대하면 장기 임대보다 2배 이상 비싸게 줘야 하고, 이런 식으로 실질적으로 compute 단가도 많이 오르고 있는 추세입니다.
HBM 대신 LPDDR을 택한 HyperAccel Bertha 칩 07:17
이진원 그래서 왜 앞에 이런 배경을 깔았느냐 하면, 저희가 만드는 칩이 Bertha라고 하는 칩이고요. 이게 저희의 첫 번째, 저희 회사에서 만든 첫 번째 데이터센터형 AI 반도체고, 저희 제품의 특징은 모두가 쓰고 있는 HBM을 쓰지 않고 LPDDR이라고 하는 저전력 DDR 메모리를 사용했다는 것입니다. 그래서 이를 통해 얻을 수 있는 것은 전력 소모량도 HBM을 쓰는 칩들에 비해 더 적을 수 있고요. 그리고 무엇보다 HBM은 굉장히 비싸고 구하기도 힘든데, 저희는 DDR을 쓰기 때문에 굉장히 저가에 공급할 수 있습니다. 그래서 여러분이 쓰시는 AI 서비스의 비용을 획기적으로 낮출 수 있는 그런 제품을 기획해서 만들었고요. 지금 Samsung 4nm 공정으로 만들었고, 올해 3월 말에 이 칩이 나와서 저희가 지금 열심히 bring-up을 하고 있습니다.
bring-up한다는 것은 칩에 소프트웨어를 올려서 서비스 가능한 수준으로 만드는 작업을 말하고요. 저희가 지난주에 열렸던 Hot Chips에서 데모를 하기는 했는데요. 조금 더 보완해서 한두 달 안에 시장에 PoC 목적으로 많이 출시할 계획을 가지고 있습니다. 그래서 저희 칩은 굉장히 저렴하고 저전력인 칩이라고 기억해 주시면 좋을 것 같아요.
LPDDR로 확보한 bandwidth와 5천 달러 목표 가격 08:42
박종현 LPDDR을 사용했다고 말씀해 주셨는데, HBM을 많이 쓰는 이유가 memory bandwidth가 중요하고, memory bandwidth를 LPDDR로 늘리기 힘들기 때문이잖아요. 그러면 LPDDR을 써서도 memory bandwidth를 늘리게 하는 어떤 방법이 들어가 있거나, 다른 어떤 것들이 적용된 건가요?
이진원 여기 지금 저희 PCIe 카드를 보면 LPDDR 메모리들이고요. 이게 총 4개씩 8개가 붙어 있는 게 보이실 텐데, 저희가 일단 첫 번째로 DDR을 굉장히 많이 넣었습니다. 이렇게 많이 넣은 칩이 전 세계에 몇 개 없어요. NVIDIA나 예전에 Meta에서 만들었던 칩 정도가 있고요. 그래서 DDR을 많이 넣어서 bandwidth를 어느 정도 확보했고요.
또 하나, 제일 중요한 것은 저희 회사 아키텍처가 여기서는 bandwidth를 거의 90% 이상 활용할 수 있는 내부 아키텍처를 가지고 있다는 것입니다. 그러니까 bandwidth가 저희는 지금 546GB/s라고 되어 있는데, H100 같은 GPU는 3TB/s 정도 되거든요. 그러면 한 6분의 1 정도 되는데, 실제로 그것은 이론적인 수치이고 실제로 어떤 AI workload를 올려서 돌렸을 때 이 bandwidth의 실제 사용률이 얼마나 되는지를 utilization으로 재 보면, 아무런 최적화를 하지 않으면 한 50% 정도 나오고, 최적화를 열심히 하면 한 70%까지 올라갈 수 있는데, 저희는 90% 이상 나오는 아키텍처를 가지고 있어서 거기서 어느 정도 극복할 수 있습니다.
그래서 그럼 얼마나 싸냐 하면, 지금 저희가 목표로 하고 있는 가격이 약 5천 달러이기 때문에 GPU 가격과 비교해 보시면 굉장히 저렴하다는 것을 알 수 있습니다. 한화로 1천만 원이 안 되는 가격입니다. 그리고 메모리 용량도 DDR을 쓰기 때문에 저희가 칩당 192GB를 가지고 있어서 큰 모델을 적은 수의 칩으로 serving할 수 있다는 장점도 가지고 있습니다.
노정석 저희가 앞에서도 배경을 계속 얘기해 드렸지만 수요가 끊임없이 늘어나고 있기 때문에 이런 형태의 칩을 만드는 것은 앞으로도 한참은 더 의미가 있겠네요.
이진원 수요가 늘어나다 보니까 애플리케이션의 요구 사항도 굉장히 다양해서 bandwidth는 결국 뒤에서 또 말씀드리겠지만 속도와 직결되거든요. bandwidth가 낮으면 속도가 조금 느릴 수 있는데 속도가 그렇게 중요하지 않은 애플리케이션들도 굉장히 많이 있어서 그런 쪽 시장도 저희가 비용이 저렴하기 때문에 잘 맞을 거라고 생각하고 있습니다.
노정석 저희가 ChatGPT와 일하는데 대부분의 시간은 글을 읽고 기다리는 데 쓰니까 그러한 비효율들이 이런 inference 시장에 그대로 쌓일 거잖아요.
LPU 이름의 유래와 OpenAI Jalapeño 11:29
최승준 LPU가 뭔가요? 이걸 단독으로 쓸 수 있는 거예요? 아니면 더 거대한 것의 부품으로 들어가는 거예요?
이진원 공교롭게도 NVIDIA가 인수한 Groq도 LPU라는 이름을 쓰고 있고 저희도 LPU라는 이름을 쓰고 있는데 저희가 사실 LPU라는 이름을 훨씬 더 먼저 썼습니다. Groq은 원래 처음에 TSP, Tensor Streaming Processor라는 이름을 가지고 있다가 나중에 LPU라는 이름으로 바꿨어요. 그런데 Groq의 LPU가 더 유명하다 보니까 많이 질문하시는데, LPU가 뭐냐, 또 새로운 종류의 NPU 같은 거냐고 물어보시는데 이건 그냥 이름이고요. 큰 의미에서는 다 똑같은 NPU의 하나고 저희는 단독으로 동작할 수 있습니다. GPU도 PCIe 카드 형태로 나오는 제품들이 있잖아요. 그것과 똑같다고 생각하시면 됩니다.
그래서 최근 소식을 하나 또 말씀드리면, 아까 제가 말씀드렸던 Hot Chips라고 하는 곳에서 OpenAI가 Jalapeño라고 하는 굉장히 재미있는 이름으로 지은 AI 반도체, 자체적으로 제작한 AI 반도체를 공개했고요. HBM4를 그것도 썼습니다. 지금 HBM4를 쓰는 GPU도 Rubin에 가서야 NVIDIA가 HBM4를 쓰고 있고요. 지금 Blackwell 시리즈는 다 HBM3E로 되어 있는데, 그래서 가장 앞선 메모리 기술을 사용했고 좀 독특한 점은 OpenAI의 Jalapeño 아키텍처와 저희 Bertha라고 하는, 앞에 소개해 드렸던 제품의 아키텍처가 굉장히 유사합니다.
그래서 저희가 Hot Chips에 가서 데모를 할 때 많은 분이 오셔서 너희가 OpenAI 아키텍처와 굉장히 비슷한 것 같다, 이런 얘기를 많이 해 주셨어요. 저희도 그렇게 많이 느꼈고요. 조금 설명해 드리면, 이렇게 HBM이 있고 저희도 DDR이 옆에 있는데, 여기서 오는 데이터들을 여기에 인접해 있는 core에서 바로 받아서 연산하는 구조로 되어 있고 그 연산 결과들을 여기 안에 있는 core들끼리 이렇게 공유하는 구조도 저희와 Jalapeño가 굉장히 유사해서 저도 완전히 다른 곳에서 다른 시기에 개발했는데 이렇게 비슷비슷할 수도 있구나, 재미있게 생각하고 있습니다.
노정석 OpenAI에서 연락이 올 수도 있겠네요. Hot Chips는 최근 Stanford에서 열렸던 콘퍼런스죠?
이진원 매년 Stanford에서 열리고요. 재미있는 게, 콘퍼런스라고 하면 굉장히 큰 컨벤션 센터 같은 곳에서 트랙도 여러 개로 나눠서 진행하잖아요. Hot Chips는 굉장히 오래된 학회인데 딱 Stanford University의 한 건물, 강당 같은 한 공간에서 트랙도 분리하지 않고 이틀 동안 진행하고요. AI 반도체 업계의 유명한 회사들은 모두 다 옵니다. NVIDIA는 물론이고 AMD, Intel을 포함해서 OpenAI도 이번에 참여했고요. 그래서 굉장히 많은 회사가 참여하는 학회입니다.
박종현 갔다 오셨나요?
이진원 저는 bring-up 하느라고 바빠서 못 갔고 저희 회사의 대표님과 엔지니어들이 갔다 왔습니다.
박종현 제가 X에서 보니까 Hot Chips에서 gpt-oss 2T 파라미터 모델이 유출됐다고 그런 얘기를 봤습니다.
이진원 저도 그걸 인터넷에서만 봤는데 실제로 확인은 못 해 봤네요.
박종현 일단 루머인 것으로 알겠습니다.
LLM inference의 두 단계인 prefill과 decode 15:01
이진원 그러면 본격적으로 시작해 보도록 하겠습니다. 맨 처음에 LLM inference가 어떻게 되는지부터 간단하게 살펴보고 가면, 사용자가 넣어 주는 prompt라고 하죠. 그게 입력으로 들어오면, 예를 들어 여기 지금 “Is tomato a fruit?”라고 물어봤다고 하면, 이 LLM이 동작해서 연산을 열심히 한 다음에 “Yes”라고 하는 첫 번째 token을 뱉어 주게 됩니다. 그래서 사용자가 이걸 편의상 4개의 token이라고 할게요. 한 단어를 token이라고 치환해서 4개의 token을 입력으로 줬을 때 그 4개의 token을 한 번에 연산해서 첫 번째 다음 token인 “Yes”를 뱉어 주는 데까지의 과정을 prefill이라고 하고요.
그다음부터는 이게 autoregressive하게 계속 돌아가면서 그다음에 “Yes”가 입력으로 들어오면 다시 LLM이 한 번 연산해서 다음 “it”이라고 하는 token을 뱉어 주고 그다음에는 “it”이 들어가서 “is”가 나오고 “is”가 들어가서 만약 end-of-sentence라고 하는 EOS, 문장이 끝났다는 token이 나오면 이 iteration이 종료됩니다. 그래서 여기 빨간색으로 표시된, 이렇게 한 token이 들어가서 다음으로 한 token이 나오는 과정을 decode phase라고 부르게 됩니다. 그래서 이 LLM이 inference하는 과정은 prefill과 decode, 이렇게 두 단계로 나뉘어 있습니다.
노정석 Prefill은 이게 4개의 token을 말씀해 주셨지만 사실 저기에 1,000개, 2,000개 token이 들어갈 수도 있는 거고 저희가 책 한 권을 던져 넣으면 그 책 한 권을 다 볼 수도 있는 건데, 사실 이건 GPU가 단 한 번의 병렬 연산을 통해 한 번에 연산해 낼 수 있는 거니까 GPU의 이점을 굉장히 잘 살리는 거잖아요. 앞에 있는 한 단어가 처리돼야 뒷단어가 나올 수 있는 구조라서 그때는 정말 한 자 한 자씩밖에 처리되지 않으니까 이건 좀 느린 거죠.
이진원 오늘 얘기하려고 하는 핵심 중 하나입니다.
노정석 Prefill과 decode로 나뉘어 있다. 그래서 prefill은 여러 개의 단어가 한 번에 들어가서 GPU가 한 번에 연산하는 건데, 뒤에서 한 자 한 자 내는 것은 decode 과정이고, 이건 굉장히 sequential하다. 이 두 개의 workload를 최적화하는 게 inference에서 중요한데, 그게 도대체 왜 이런 모양인지를 이진원 CTO님이 저희에게 하나하나 가르쳐 주실 예정입니다. 정신 바짝 차리고 오늘 수업을 따라가야 합니다.
최승준 저도 질문이 하나 있습니다. 석현 대표님 때도 나왔었는데, TTFT라고, time to first token이 파란색에서 빨간색 사이에
이진원 있는 게 맞습니다. 이 까만색 입력이 들어가서 “Yes”가 나올 때까지의 시간이 TTFT, time to first token이고요. 그다음에 “Yes”가 들어가서 “it”이 나오는 이 decode의 한 iteration을 TBT라고도 하고, time between tokens라고도 하고 TPOT라고도 합니다. Time per output token이라고도 하고, 여러 가지 용어가 조금씩 다른데요. 의미가 아주 살짝 다르기는 하지만 혼용해서 사용해도 크게 문제는 없습니다. 그러면 LLM iteration 안에 도대체 뭐가 있는지 살펴보겠습니다. 이 안에 Transformer라는 알고리즘이 있는데, 한 번 더 요약해 보면 위에서부터 아래로 내려가는 방향인데요. 처음에 token이 들어오면 요즘은 position embedding도 안쪽에서 하긴 하는데, RoPE를 하죠. 그게 attention 안으로 들어와 있는데, 어쨌든 token이 들어오면 중요한 건 제가 색깔을 칠한 attention이라는 걸 하고 그다음에 feed-forward network, FFN이라고 부르는 걸 통과하고 다시 이걸 계속 반복한 다음에 제일 마지막에 LM head라고 하는 데 가서 다음 token이 뭔지를 선정하게 됩니다. 그런데 여기에 모델이, 우리가 100B짜리 모델이라고 하면 그 모델 parameter들이 존재하게 되는데, 그 parameter가 attention과 feed-forward network에 어느 정도 비율로 존재하는지를 보면 attention이 대략 20%, 그리고 FFN이 80% 정도 돼요. 그러니까 4 대 1 정도로 FFN이 더 많은 parameter를 갖고 있는 거죠. 그런데 이건 dense model, 우리가 MoE라고 하는 최근에 많이 사용하는 모델이 아닐 경우에 그렇고, MoE 모델로 가면 이 비율은 훨씬 더 FFN 쪽이 많아지게 됩니다. 그래서 parameter는 attention에 생각보다 많지 않다. 우리가 Transformer 하면 attention이 핵심이라고 생각하지만, 핵심인 것도 맞고요. 그런데 Transformer에서 가장 중요한 연산은 이 두 개라고 볼 수 있고요.
Transformer의 핵심 연산 attention과 FFN 17:57
이진원 그래서 그걸 조금 더 볼 건데, 그걸 보기 전에 도대체 우리가 이 Transformer에 입력으로 넣어 주는 것과 출력으로 나오는 것의 차원을 볼 필요가 있어요. 차원은 3차원입니다. 첫 번째 차원은 batch, 여러 개의 request가 오면 그걸 동시에 처리할 때의 batch고요. 그다음은 token의 개수예요. 그러니까 아까 제가 “Is tomato a fruit?”라고 물어봤을 때 4개의 token이 있었죠. 그 4개의 token, 그리고 한 token을 몇 차원의 vector로 표현할 건지, 그에 대한 3차원 입력이 들어가게 되고 출력도 사실은 3차원인데, 아까 보셨다시피 prefill에서는 사용자가 몇 단어, 몇 token짜리 입력을 줄지 모릅니다. 최대 100만 token까지도 줄 수 있게 되어 있죠. 그래서 이게 1보다 커지지만 결과로 나오는 건 한 token만 나오기 때문에 여기가 1이 됩니다. 그래서 이 1을 지우고 보면 사실상 2차원이라고 볼 수 있는 거죠. 그리고 decode에서는 항상 한 token이 들어가서 한 token이 나오는 구조이기 때문에 batch를 생각하지 않았을 때 이 prefill의 출력과 같은 형태의 데이터가 돌아다닌다고 이해하시면 될 것 같습니다.
노정석 저희가 PyTorch에서 항상 쓰던 batch, 그다음에 num_tokens가 sequence length인 거고 token dimension이 Transformer embedding의 dimension인 거죠?
최승준 맞습니다. 이게 좀 헷갈려요. 이 token이 처음에는 ID로, 정수나 자연수였다가 이제부터 얘기하면 vector인 거잖아요, 여기서는?
이진원 그게 여기 token dimension에서 vector로 바뀌는, 원래 여기가 scalar였다가 vector로 바뀌는 거고요. 그래서 attention 안을 보면 Query, Key, Value라고 하는 게 있고 아까 입력으로 들어왔던 이 token 하나당 여기 만약 embedding 차원을 10차원이라고 하면 10개의 숫자로 단어 하나를 표현, token 하나를 표현하는 거죠. 그 token embedding vector를 가져와서 여기에 어떤 weight parameter, 이게 model parameter죠. 그것들을 각각 곱해서 행렬 연산을 하는 거죠. 그래서 Query, Key, Value로 만듭니다. 그러면 여기서 의문이 드는 게 입력이 3차원인데 얘는 2차원이거든요. 이걸 어떻게 곱하나 생각하실 수 있는데, 쉽게 말씀드리면 B 곱하기 S를 그냥 flatten해서 예를 들어 여기 B가 5고, sequence가 2고 D가 10이었다면 5 곱하기 2 곱하기 10을 앞의 두 개를 곱해서 10, 10 곱하기 10의 행렬로 만든 다음에 연산한다고 생각하시면 쉬울 것 같아요. 그래서 이걸 곱해 QKV를 생성하고, 그다음에 Query, Key, Value끼리 연산합니다. 먼저 Query와 Key를 내적한 다음에 행렬 곱을 하고 softmax라는 걸 한 다음, 다시 Value를 곱해서 연산하는데, 이걸 self-attention이라고 부르고요.
QKV 연산과 self-attention 구조 20:50
이진원 그런데 이걸 head 여러 개로 나눠서 똑같은 연산을, 그러니까 여기서 생성된 QKV를 다 잘라서 head가 16개라면 16조각을 낸 다음에 그 조각난 것들끼리 self-attention을 하고 나중에 다시 하나로 합치는데, 그걸 head merge라고 합니다. 그래서 merge할 때는 이 결과들을 다 concatenation해서 붙인 다음에 또 여기에 어떤 weight parameter를 한 번 곱해서 결과를 뽑게 됩니다. 그러면 이 결과가 그 이후의 여러 연산, residual connection 같은 것들을 거쳐서 FFN으로 넘어가게 되고요. FFN은 크게 보면 두 개의 linear layer로 되어 있어요. 그냥 weight를 두 번 곱하는 거죠. 물론 여기에 gate라고 하는 게 최근에는 추가돼서 조금 복잡해졌지만, layer 두 개짜리 neural net이 있는 거라고 생각하시면 될 것 같아요. 그래서 여기에 연산을 위한 parameter가 많이 들어 있다는 얘기고요.
이걸 개념적으로 생각해 보면 attention이라고 하는 것은 이것들을 다 Query, Key, Value로 만든 다음에, 예를 들면 이것의 Query와 얘네의 Key, 얘의 Key, 모든 Key와 vector 내적을 하거든요. 그게 행렬 곱으로 나타나는 거고, 그래서 attention은 token들끼리의 관계를 학습하는 것이라고 보시면 되고, FFN에 들어가면 아까 제가 한 token을 몇 개의 숫자로 표현할 거냐, 10개라고 하면 10차원 vector로 표현한다고 했잖아요. 그 10차원 vector를 이루는 숫자들끼리 연산하는 게 FFN 쪽입니다. 그러니까 token들 간의 연산은 attention이고, token 하나 안에서 그 vector 차원들끼리 연산하는 게 FFN이라고 생각해 주시면 좋을 것 같아요.
이게 공교롭게도 예전 CNN 시절에 보면 depthwise convolution이라고 하는 게 있었는데, 그것도 똑같은 형태로 되어 있습니다. 한 번은 공간 방향으로, 가로세로 방향으로 연산하고 한 번은 channel 방향으로만 연산하게 돼 있거든요. 그래서 그것과 완전히 동일한 구조라고 보시면 되고, 이게 transformer가 조금 더 general한 아키텍처를 가졌다고 볼 수 있는 부분이에요.
CNN은 depthwise convolution이라는 비슷한 개념이지만, 공간 방향으로 볼 때 이렇게 3×3이라든지 정해진 영역만 봤다면 attention은 맨 처음 token부터 맨 끝의 token, 뒤쪽으로는 보지 않지만 맨 끝의 token이 맨 앞의 token까지 다 보고 무언가를 하기 때문에, global하게 다 보기 때문에 조금 더 general한 모델인 거죠. 저 같은 scalingist들이 믿는, 더 general한 알고리즘으로 scale을 키우면 성능이 좋아진다는 걸 보여주는 대표적인 사례라고도 할 수 있겠어요.
박종현 혹시 이걸 보시는 분들을 위해서 말씀드리면, 행렬 연산이라는 게 차원이 커지면 머릿속에 바로 안 들어오실 수가 있어서 3Blue1Brown 채널에 가시면 이걸 3D 그래픽으로 아주 예쁘게 그려 둔 영상들이 있거든요. 그래서 조금 더 깊게 지금 얘기한 걸 따라오고 싶으시면 거기를 참고하시면 도움이 많이 되실 것 같습니다.
최승준 gate만 몰라도 되는 게 아니고, 이걸 그냥 다 알아야 하는 건 아니죠, 사실?
이진원 그냥 이런 게 있구나 생각하시면 됩니다.
노정석 네, 사실 이게 한 step이잖아요. 이 transformer 논문을 이해하고, 이 안의 dimension들이 어떻게 돌아가는지 PyTorch 코드까지 하나하나 이해가 돼야 transformer가 그 뒤에 좀 자연스럽게 와닿는 건데, 그전에는 개념적으로 아무리 들여다봐도 이해하기 어려운 것은 어쩔 수 없는 사실입니다. 그러니까 그 부분에 대해서는 개념적으로 attention block이 있고, FFN block이 있고, compute가 어디에 많이 쓰이고, 무엇은 이런 거구나 하는 정도만 알고 계셔도 충분히 뒤에 있는 내용들을 따라오실 수 있습니다.
최승준 새로운 부분이 있는 것 같아요. channel-wise라는 걸 까먹고 있었어요.
이진원 그래서 아까 앞에서 attention 부분을 잘 보면 제가 token embedding vector들이 있을 때 그것으로 Query도 만들고 Key도 만들고 Value도 만든다고 말씀드렸는데, 그렇게 만들어진 것들이 있을 때 연산 과정을 표현한 거고요. Query와 Key를 곱하고 softmax라는 걸 한 다음에 다시 Value와 곱하는 과정을 거치는데, 이게 prefill에서 아까 제가 보여드렸던 예제에 나온 거고, 여기서 이 output을 가지고 마지막에 LM head 연산을 하면 ‘yes’라는 단어 token이 나오게 됩니다.
Decode에서 Key와 Value를 재사용하는 KV cache 26:32
이진원 그러면 decode phase에 오면 입력으로 ‘yes’가 들어오잖아요. 그럼 ‘yes’를 가지고 또 Query, Key, Value, 이 하늘색 부분을 만들게 됩니다. 그리고 연산할 때 Key와 Value는 앞에 있었던 token들의 Key, Value가 모두 필요하거든요. Query는 필요 없는데 Key, Value는 필요하게 됩니다. 그러니까 Key, Value가 개념적으로 앞의 context 정보를 담고 있다고 보는 거죠. 쉽게 얘기하면, 내가 ChatGPT와 대화했을 때 과거에 했던 대화의 기억을 가지고 있는 게 Key, Value라고 생각하시면 되는데, 이걸 처리하는 방법은 두 가지죠. 이때 이 token들의 Key, Value를 다시 계산할 수도 있고, 여기서 한 번 계산했으니까 이걸 메모리에 저장했다가 불러와도 되겠다고 생각할 수 있겠죠. 그래서 대부분의 경우 메모리에 저장했다가 다시 불러오는 게 유리하기 때문에, Key, Value는 처음 prompt phase 때 생성된 것을 저장하고, 지금 ‘yes’에서, 여기 제가 layer 하나로 다음 token이 나왔다고 했을 때 그다음 token이 다시 입력으로 들어갈 때 또 ‘yes’가 쓰이기 때문에 여기에 ‘yes’의 Key, Value도 이 step이 끝나면 저장해야 합니다.
노정석 그렇죠. 이게 저희가 항상 얘기하는 KV cache인 거죠. 앞에서 저희가 다른 데서 뉴스 기사를 가져와서 2천 자짜리를 넣어 prefill했다면, KV cache에 그 앞의 2천 자가 전부 들어 있는 거죠.
이진원 그걸 다 가지고 와야 합니다. 그래서 이 KV cache를 저장하는 메모리 공간이 많이 필요하게 되겠죠. 그래서 도대체 KV를 저장하는 데 token 하나당 얼마나 용량이 필요한지를 계산해 보면, 이건 Llama 3.1의 70B 모델을 가지고 계산한 겁니다. 여기서 2는 Key와 Value가 있으니까 두 개가 필요해서 2를 곱한 거고요. N은 layer의 수입니다. 모든 layer마다 attention을 해야 하기 때문에 layer 개수만큼 필요하고, 그다음에 Key, Value는 아까 그
Token당 320KB로 폭증하는 KV cache 용량과 GQA 28:15
노정석 multi-head attention.
이진원 multi-head attention이 기본인데, transformer 알고리즘에서는, Llama 3.1에서는 grouped-query attention을 사용합니다. Grouped-query attention은 뭐냐면, 여기 GQA라고 되어 있는데, 이건 head마다 원래는 Query 하나, Key 하나, Value 하나가 있어야 하는데, 예를 들어 head 여덟 개를 묶어서 여덟 개마다 Query는 여덟 개가 있지만 Key와 Value는 하나씩만, 여덟 개당 하나씩만 갖게 하는 것이라고 생각하시면 됩니다. 그다음에 head 개수를 곱하고, Key, Value 하나당 몇 byte로 저장할 거냐, 보통 BF16이나 FP16으로 저장하면 2byte가 되겠죠. 그래서 이걸 쭉 계산해 보면 대략 320KB, token당 320KB가 됩니다. 그래서 이걸 만약 128K, 12만 8천 token의 context를 Key, Value로 저장한다고 하면 40GB 정도의 용량이 필요해요. H100 한 장에 80GB의 메모리가 있으니까, 그것의 절반입니다. 한 사용자가 만약 128K context를 사용하면 40GB의 Key, Value가 필요합니다. 그것도 70B 모델에서 그런 겁니다. 만약 이게 1T 모델로 가면 엄청나게 커지겠죠.
그래서 생각보다 Key, Value의 용량이 크다는 걸 보여드리려고 다양한 open-source 모델에서 어떤 attention을 사용하고, 그에 따라 token당 Key, Value의 용량이 어떻게 되고 context가 늘어나면 얼마나 용량이 늘어나는지를 표로 정리한 건데요. 여기 보시면 최근에 나오는 중국산 open-source 모델들은 조금 작아진 걸 보실 수 있어요. 여기에는 attention 종류가 좀 다른 것들이 있잖아요. 그래서 이런 attention에서 Key, Value가 많이 생성되는 걸 압축하기 위한 여러 기법을 사용해서 이걸 많이 줄이려고 합니다. 줄이지 않으면 여기 보시는 모델을 저장하는 용량보다도 Key, Value를 저장해야 하는 메모리 용량이 더 많아질 수 있거든요. 그래서 이런 것들이 생기고 있습니다.
그리고 추가로 이걸 돌리려면 GPU가 몇 장 필요한지, batch를 32, 그러니까 32명에게 서비스할 거고 context가 평균적으로 128K라고 했을 때 얼마나 필요한지, GPU 개수를 여기에 쭉 써 놓은 건데요. 이런 H100 같은 경우에는 Llama 3.1 405B를 serving하려면 27개가 필요합니다. 이건 저장 공간으로만 나눈 거고, 실제로는 8의 배수로 써야 하니까 32개 정도 필요하게 되겠죠.
최승준 이 부분에서 조금 궁금해지는 게, 보면 이런 걸 모르고 사용하면 괜찮은데, 대강이라도 알고 사용하다 보면 이 KV cache가 시간이 지나면 날아갈 텐데 나는 아직 생각의 정리가 안 됐고 모델한테 일은 안 주는데 이게 시간이 지나면 날아가니까 그럴 때는 prefill을 한 번 또 하고 또 비용이 더 들겠지, 이런 걸 생각하게 되는데 그렇게까지 생각할 필요는 없는 거죠.
이진원 그렇죠. 그것까지 생각하면
이진원 피곤. 그런 건 inference engineering을 하는 엔지니어들한테 맡기시고 편하게 쓰시면 됩니다.
박종현 프론티어 모델들은 그래서 요금제에서 subscription 말고 API에 돈을 내고 쓰면 그 cache를 얼마나 유지하고 있고 내가 쓰던 prompt가 cache hit가 나면 가격이 한 10분의 1인가요? 엄청 싸게 깎아주잖아요. 그런 게 다 저 KV cache를 들고 있어서 가능한 가격 정책인 거죠. 일반 사용자는 신경 쓰지 않아도 그냥 cache가 다 유지되고 있다고 볼 수 있겠죠.
KV cache를 줄이는 양자화와 MLA 32:12
이진원 이런 용량이 문제가 되니까 그럼 용량 문제를 해결해 보자고 해서 나오는 방법 중 가장 직관적인 건 모델을 작게 하면 되겠죠. 작은 모델을 쓰면 용량을 좀 줄일 수 있고요. 그다음에는 quantization, 양자화를 하면 됩니다. 그래서 최근에는 8bit를 넘어서 4bit MXFP4나 NVFP4 같은 floating-point의 원래 표준에 등록되어 있지 않은 그런 format들을 사람들이 정의해서 쓰기 시작했고요. 그다음에 앞에서 말씀드렸지만 KV의 구조를 변경하는 겁니다. 그래서 아까 Grouped Query Attention도 원래는 head 하나마다 KV가 있어야 하는 걸 head 8개마다 KV 하나씩 이렇게 했다면 DeepSeek가 했던 MLA 같은 건 이걸 모든 query에 대해서 KV를 하나씩만 주는데 그것조차도 압축해서 latent vector로 만들어 메모리에 저장하는 방식을 쓰고 있고요.
그다음에는 sliding window attention이라고 해서 CNN과 비슷한 개념인데 내가 제일 앞에 있는 token까지 다 attention을 하는 게 아니고 내 주변에 있는 것 몇 개까지만 window size를 정해서 attention을 하는 방법입니다. 그런데 이것만 쓰면 성능이 좀 안 좋아질 수 있기 때문에 보통은 hybrid로 많이 사용합니다. 한 번은 전체를 다 보고 한 번은 sliding window로 보는 거죠.
그다음에 KV를 저장할 공간이 부족하니까 Mooncake 같은 데서 나오는 건 이걸 CPU에 있는 메모리로 옮기거나 아니면 SSD로 내려놨다가 필요할 때 다시 가져와서 쓰는 방법을 많이 이야기하고 있어요. 이건 agentic AI가 나오면서 KV가 생성되는 게 이전의 reasoning model과도 비교가 안 될 정도로 지금 더 많은 KV가 생성되고 있어서 도저히 이걸 메모리에 다 담을 수도 없고 뒤에서 말씀드리겠지만, 사람이 시켜놓고 딴짓하다가 agent가 오래 걸리니까 와서는 “다 끝났네.” 하고 그러잖아요. 그 기간 동안 서버가 이걸 비싼 HBM 메모리에 KV를 계속 담고 있을 수가 없어서 이렇게 다른 메모리로 옮겨 놓는 방법들도 많이 사용하고 있습니다.
최승준 inference 전용 chip으로 할 때 이런 식으로 KV를 다루는 아키텍처들이 계속 변화해도 이미 구운 반도체로 다 대응이 되는 거예요?
이진원 그건 상황에 따라 다를 수 있는 거죠. 그래서 보통은 고려가 안 되어 있을 가능성이 꽤 많고요. 왜냐하면 이렇게 공간이 넘친다는 생각을 예전에는 많이 못 했을 거라서요. 그런데 새롭게 나오는 것들은 그런 것들의 활용을 많이 고려해서 만들려고 하고 있습니다. 그다음에 용량에 대한 이야기를 넘어서 CPU든 GPU든 제가 그래서 XPU라고 했는데 XPU 성능을 정하는 건 단순하게 보면 두 가지예요. 하나는 어떤 연산에서 A와 B를 더한다고 했을 때 A도 B도 처음에는 메모리에 있겠죠. 그래서 A를 읽어오고 B를 읽어온 다음 그 결과를 더해서 그걸 C라고 하면 그 C를 다시 메모리에 저장하는 이런 단순한 연산이 있다고 했을 때 메모리에서 데이터를 읽어와야 하는 것과 그다음에 연산해야 하는 것, 이 두 가지 연산이 있는데 이 둘 중에 뭐가 더 빠르냐에 따라서 성능이 한쪽에서 병목을 겪게 됩니다. 왜 그러냐면 지금 제가 예를 든 건 A와 B를 읽어서 연산한 다음 그 결과를 메모리에 저장하는 직렬화된 연산으로 설명을 드렸지만 실제로는 이렇게 되는 게 아니고, A와 B를 읽어서 A 더하기 B를 하고 있는 동안 다음에 연산할 C와 D를 또 읽고 있거든요. 그래야 이 연산이 끝나자마자 다음 C와 D를 또 더할 수 있는 거죠. AI에서는 병렬 처리를 해야 하고 똑같은 연산을 굉장히 많이 해야 하다 보니까 이런 일이 자연스럽게 일어나게 되는데 GPU든 NPU든 이런 것들이 1초에 연산을 몇 개나 할 수 있느냐, 이것과 메모리에서 데이터를 얼마나 빨리 공급해 줄 수 있느냐, 이 두 가지에 따라 병목이 생기게 됩니다.
연산 병목과 메모리 병목의 구분 35:01
이진원 보통은 읽어오는 데이터에 비해 연산을 훨씬 많이 할 수 있게 되어 있어요. 예를 들어 H100 같은 경우를 보면 BF16 기준으로, 16bit 데이터 기준으로 1PFLOP/s 정도 연산할 수 있는데요. 1,000TFLOP/s 정도인데, 메모리에서 읽어오는 건 1초에 3.35TB를 읽을 수 있어요. 그러면 이게 실제로 BF16이면 이것의 절반만큼 데이터의 개수가 되겠죠. 왜냐하면 데이터 1개가 2byte니까요. 그러면 이 비율을 대략 따져보시면 그냥 나누면 300인데, 그래서 이 둘이 딱 균형을 이루는 시점, 연산과 메모리 중 어느 하나도 느리거나 빠르지 않고 균형을 이루는 시점을 계산해 보면 대략 300 정도 되는 겁니다. 이걸 ridge point라고 하고요. 예를 들어 이게 만약에 이건 하드웨어적인 수치고, 내가 어떤 AI 모델을 돌리는데 그 모델을 돌리는 kernel이라는 프로그램이 메모리에서 데이터를 한 번 읽었을 때 연산을 200번밖에 못 하게 되어 있다. 그러면 이건 메모리 쪽에 병목이 생기게 되는 거고, 이 모델은 데이터를 한 번 읽어오면 연산을 1,000번 할 수 있다. 그러면 데이터를 한 번 읽어서 1,000번 연산하려고 하는데 지금 300번밖에 연산하지 못하는 상황이잖아요. 그래서 연산기가 적어서 더 빨리 할 수 있는데도 연산기가 부족한 상황이 되니까 이럴 때는 compute-bound가 됩니다.
Arithmetic Intensity의 정의와 데이터 재활용 37:48
이진원 그래서 이 AI라는 게 Artificial Intelligence가 아니고 Arithmetic Intensity, 산술 강도라고 하는 건데 메모리에서 1byte의 데이터를 읽었을 때 얼마나 많은 연산을 할 수 있느냐, 그걸 이야기하게 됩니다. 이게 조금 어려운 개념일 수도 있는데 제가 예를 들어서 설명해 볼게요. 아까 처음에 예를 들었던, 이 4개의 “토마토가 과일이니?”라고 물어봤던 4개의 token이 이렇게 4차원의 vector로 표현됐다고 했을 때 어떤 weight를 곱해서 이런 연산을 많이 하게 되겠죠. query를 생성할 때도 이런 연산을 할 거고 FFN에 가도 이런 연산을 하게 될 텐데 물론 matrix 크기는 조금씩 다르겠지만 제가 간단하게 설명하기 위해서 그냥 4×4 matrix로 표현해 봤습니다. 그러면 이 weight parameter 입장에서 보면 이 W11이 곱셈에 몇 번 사용되는지를 보면 네 번 사용되겠죠. 이것과도 곱해질 거고, 저것과도 곱해질 거고, 그래서 이 데이터 W11은 하나를 읽어왔을 때 연산을 최대 몇 번 할 수 있느냐고 하면 네 번 할 수 있는 겁니다. 그게 Arithmetic Intensity예요. 정확하게 이야기하면 AI 반도체나 GPU에서는 곱셈을 한 번 하면 덧셈을 한 번 합니다. 왜냐하면 여기에서 이 vector와 이 vector를 내적하는 거라서 이것들끼리 결과를 다 더해야 하잖아요. 곱셈과 덧셈이 반드시 한 쌍으로 같이 일어나기 때문에 연산을 두 번으로 세기는 하는데 한 번이냐 두 번이냐가 중요한 게 아니고 지금 차수가 그렇게 된다는 겁니다.
결국 이 Arithmetic Intensity가 무엇에 영향을 받는지 딱 보시면 token의 개수에 영향을 받겠죠. 그리고 이 token의 개수는 아까 제가 맨 처음에 원래 입력은 3차원인데 입력으로 들어갈 때는 batch 곱하기 token sequence length를 합쳐서 하나로 만든다고 했잖아요. 그러니까 여기에 다른 batch의 데이터도 아래로 쌓여 있다면 그것까지 포함되는 겁니다. 그래서 batch 곱하기 sequence length만큼의 Arithmetic Intensity를 갖게 되겠죠. 예를 들어 batch가 1이라고 쉽게 가정해 보고 token을 100만 개 썼다고 하면 Arithmetic Intensity가 100만이 되는 겁니다. 반대로 decode에 오면 이게 하나잖아요. 그래서 W11이라고 하는 것은 한 번밖에 사용되지 않습니다. 그래서 이때는 Arithmetic Intensity가 1이에요. 그리고 이 Arithmetic Intensity라는 게 조금 다른 이야기인데, 반도체에서 굉장히 중요합니다. 왜냐하면 메모리에서 데이터를 한 번 읽어서 연산을 많이 한다는 건 많이 활용한다는 거잖아요. 반대로 이야기하면 같은 연산을 했을 때 메모리에서 읽는 횟수가 줄어든다는 뜻이겠죠.
이게 왜 중요하냐면, 여기 보시면 곱셈 한 번과 덧셈 한 번에 소모하는 에너지에 비해서 이 SRAM은 심지어 chip 안에 있는 메모리인데 SRAM이나 HBM이나 DDR에서 읽을 때 소모하는 에너지를 보시면 자릿수가 몇 개나 차이 나는 건가요? 엄청나게 차이 나죠. 자릿수가 네댓 개 차이 날 정도로 에너지를 많이 소모하기 때문에 우리가 저전력을 이야기할 때 가장 중요한 건 메모리에서 데이터를 얼마나 적게 읽고 적게 쓰느냐, 이게 굉장히 중요합니다. 그게 Arithmetic Intensity와도 연관되어 있는 거죠. 조금 다른 이야기였고요. 그래서 Roofline analysis라는 게 나오는데 이게 유명한 David Patterson을 비롯한 몇 분이 2009년에 논문으로 낸 건데 아까 ridge point라고 한 이건 하드웨어가 결정되면 그려지는 선이에요. 어떤 모델과 상관있는 선이 아니고 하드웨어의 성능을 표현해 주는 그래프인데요. 이 ridge point가 연산과 메모리 어느 쪽에도 병목이 없는 상태고요.
Roofline analysis로 읽는 compute-bound와 memory-bound 40:58
이진원 이걸 그리는 방법은, 여기 지금 평평한 이 선은 반도체가 낼 수 있는 최대의 연산 능력이에요. 아까 H100이 한 1PFLOPS 정도 연산을 할 수 있다고 얘기했는데 그게 여기입니다. 여기 y축을 따라가면 y축에 1천 TFLOPS 정도가 나오는 거고요. 그다음에 이 기울기는 로그-로그 스케일로 그리면 기울기가 1인데, 여기 y절편에 해당하는, y축과 만나는 점이 바로 bandwidth가 됩니다. 이게 기울기가 항상 1이기 때문에 bandwidth가 올라가면 이 경사면이 올라가겠죠. 그러면 ridge point가 왼쪽으로 옮겨가겠죠. 데이터를 더 빨리 공급해 주니까 arithmetic intensity가 더 낮은 지점에서 ridge point가 형성되는 거고, 반대로 bandwidth는 그대로 두고 compute를 올리면 이 수평선이 위로 올라가는 거라서 이런 식으로 올라가게 됩니다.
그래서 이 그래프를 보고 뭘 알 수 있냐면, ridge point보다 오른쪽에 있으면 compute-bound인 거고요. x축이 arithmetic intensity입니다. 어떤 모델을 돌리는데, 아까 제가 얘기한 것처럼 prefill에서 weight를 읽어왔는데 이 weight로 100만 번 연산을 할 수 있어요. 그러면 여기가 295니까 100만은 굉장히 오른쪽에 있겠죠. 그러니까 여기는 데이터를 한 번 읽어서 100만 번 연산할 수 있는데 연산기가 300번밖에 연산을 못 해주네. 그래서 이걸 300번씩 여러 번 수행해서 100만 번 할 때까지 기다려야 되는 상황이기 때문에 compute-bound인 거고, 반대로 왼쪽으로 가면, 아까 decode일 때는 메모리에서 데이터를 읽어서 연산을 한 번밖에 못 하니까요. 그런데 메모리에서 데이터가 300분의 1로 느린 속도로 오고 있잖아요. 그러니까 그만큼 성능이 굉장히 떨어지게 되는 거죠.
그래서 prefill은 우리가 그래도 연산기를 더 늘리려면 늘릴 수도 있는데, decode는 기본적으로 이 연산 자체가 이렇게 생겼기 때문에 토큰이 하나 들어가서 하나 나오고, 그래서 행렬 곱하기 행렬 연산이 아니라 벡터 곱하기 행렬 연산으로 되다 보니까 항상 arithmetic intensity가 아주 낮은 지점에 찍힐 수밖에 없어요. 그래서 이걸 오른쪽으로 보내야 이 그래프가 y축 방향으로 만나는 지점이 결국 성능을 나타내는 거거든요. 이걸 어떻게든 오른쪽으로 보내보자는 생각을 하는 거죠. 제일 쉬운 게 batch를 늘리는 겁니다. decode할 때도 내가 질문한 답에 대한 단어 하나, 토큰 하나, 두 번째 사용자에 대한 답변 토큰 하나, 세 번째 사용자, 네 번째 사용자, 이렇게 여러 명의 사용자에게서 나온 output token을 하나씩 다 모아서 행렬을 곱하면 그만큼 arithmetic intensity가 올라가겠죠. 아까 제가 3차원의 입력인데 sequence length가 1이라고 했잖아요. decode 때는 batch를 키우면 다시 2차원으로 만들 수 있으니까 그만큼 arithmetic intensity를 올릴 수 있습니다. 그래서 decode할 때는 batching을 최대한 활용해서 처리하려고 하고 있고요.
Batching으로 올리는 decode 효율과 attention의 한계 43:46
이진원 그런데 여기서 굉장히 심각한 문제가 생기는데, attention은 batching을 늘려도 arithmetic intensity가 올라가지 않습니다. 왜 그러냐면, 내가 질문한 것의 key-value와 다른 사람이 질문한 것의 key-value가 다르잖아요. 그래서 query와 key를 곱할 때 보면 query가 벡터였고 key가 행렬이었는데, 그 행렬을 공유하지 못하는 거죠. batch들끼리 앞에서 query를 생성하거나 key를 생성하거나 value를 생성할 때는 같은 weight를 곱하니까 서로 다른 사용자들의 토큰들을 모아서 연산할 수 있었지만, 이게 내 output token의 query라고 하면 이게 key-value들의 모음이라고 하면 다른 사용자는 이 key-value를 쓰면 안 되잖아요. 그래서 여기는 arithmetic intensity를 절대로 올리지 못하는 곳입니다. 여기는 여전히 1로 남아 있어야 하는 상황인 거죠. 그래서 attention에서 병목이 많이 생기고요. 특히 최근에는 콘텍스트 길이도 길어지다 보니까 이 부분이 굉장히 큰 병목이 되고 있어요.
그래서 사람들이 가만히 있지 않겠죠. attention에서도 arithmetic intensity를 올려보자는 게 앞에서 얘기했던 GQA 같은 걸 쓰면 8개당 key-value 하나니까 query 8개를 모아서 key matrix와 곱해주니까 8만큼 arithmetic intensity가 되겠죠. 원래 1에서 8로 올라가는 거고, MQA도 multi-query attention이라고 해서 query가 16개 있으면 16개 전체에 대해서 key와 value는 하나씩만 쓰는 거거든요. MLA도 똑같은데, MLA는 그 key-value마저 압축해서 쓰는 거고요. 그래서 이런 경우에는 몇 개의 query당 key-value 하나를 할당하느냐만큼 arithmetic intensity가 올라가게 되고요. 그다음에 우리가 프롬프트를 ChatGPT나 Claude한테 주면 우리한테는 보이지 않지만 그 앞에 system prompt라든지 여러 가지 tool에 대한 얘기라든지 주의사항 같은 것들이 들어가잖아요. 그 앞에 들어가는 부분은 항상 똑같이 들어가기 때문에 hidden prompt에 대한 key-value를 미리 계산해 놨다가 그건 공유해서 쓰자는 게 prefix caching 방법입니다. 이렇게 하면 그 부분에서 좀 이득이 있겠죠. 그리고 key-value 자체의 크기를 줄이면 같은 bandwidth에서 더 많은 key-value를 읽어올 수 있으니까 그것도 효과가 있겠죠. 그래서 사용하는 방법이 key-value를 8비트나 4비트로 양자화해서 가져오는 방법이고, 이런 것들을 attention에서도 arithmetic intensity를 올리는 방법으로 사용하고 있습니다.
박종현 들으시는 분들이 잘 이해하실 수 있게 제가 한 번만 풀어서 말해보고 싶은데, arithmetic intensity라는 것은 저희가 메모리에서 데이터를 읽어와서 그걸 몇 번 연산하느냐, 최대한 재활용을 많이 하면 많이 할수록 compute-bound가 되니까 GPU의 computing resource, CUDA core라고 하죠. core 수가 많으니까 그걸 활용할 수 있어서 prefill 같은 경우에는 가져온 weight를 모든 토큰에 대해서 한 번에 다 연산하니까 compute-bound라서 저쪽으로 갈 수 있는 반면에, decode 같은 경우는 기본적으로 Transformer가 한 토큰씩 연산을 꼭 해야 되니까 재활용할 수 없어서 memory-bound가 되는 거죠. 그래서 hardware 자체의 성능을 올리려고, 다음 페이지에 있는 y절편을 올리려고 memory-bound workload를 더 잘 수행하기 위해서 애초에 memory bandwidth가 높은 HBM 같은 걸 써서 저 곡선을 바꾸고 최대한 효율적으로 할 수 있게 하겠다는 데까지 이해했습니다.
이진원 맞습니다. 이게 왼쪽으로 가면 갈수록 compute-bound에 더 쉽게 들어오잖아요. 그래서 성능을 더 잘 뽑을 수 있는 거죠.
노정석 이 ridge point, 이 곡선 자체는 Transformer와 아무 상관없이 hardware가 정해지면 compute와 memory 때문에 생기는 어떤 최적의 선이고, 저 최적의 선 안에 저희가 Transformer를 우겨 넣어야 되는데 Transformer에서 prefill과 decode가 하는 연산의 성격이 워낙 다르다 보니 얘를 어떻게 최적화해서 집어넣어서 그 hardware가 가진 성능을 최대한 다 뽑아낼까 하는 것들이 저희가 앞으로 이야기할 최적화에 대한 내용인 거죠?
그리고 여기서 또 한 번 여러분께 위로를 드리고 넘어가면, 이것들이 머리에 지금 딱 박히지 않아도 괜찮습니다. 이것들을 다 이해하지 않으셔도 상관없고, 대략 이러한 것들이 inference의 economics, 추론의 경제학 안에서 이것들을 해석하기 위해 일어나는 생각의 틀이고 engineering의 최전선이라고 받아들여 주시면 괜찮습니다.
이진원 그래서 다음으로 할 얘기는, 그러면 우리가 예를 들어서 어떤 양자화 같은 걸 적용해서 메모리 공간도 조금 더 효율적으로 쓰고 같은 bandwidth에서 더 많은 데이터를 읽고 싶다고 했을 때 뭘 양자화하는 게 효과가 있는지 보려면 도대체 어떤 게 데이터 양이 더 많은지와 연관될 수밖에 없어요. 다시 앞의 용량 얘기로 돌아갈 수밖에 없는데, 이것도 앞에서 Llama 3.1 70B, BF16 기준으로 했을 때 가중치가 대략 141GB, weight가 그 정도 되는데 key-value가 더 많아지는 게 43만 1천 토큰을 쓰면 key-value가 더 많아지게 됩니다. 이게 batch 1일 때 기준이고요. batch가 늘어나면 늘어날수록 batch 곱하기 sequence length가 아까 그 arithmetic intensity에 해당하는 거고, 그만큼 key-value가 생성되다 보니까 batch가 늘어나면 늘어날수록 당연히 key-value의 양이 weight의 양을 추월하는 시점의 토큰 개수가 점점 줄어들게 되겠죠.
그리고 이게 128K에서 key-value의 용량이 얼마나 되는지를 계산한 건데, 보시면 512 batch에서 22TB 정도입니다. 그러니까 사실상 512명을 동시에 하나의 서버 혹은 한두 개의 서버에서 serving하는 건 불가능하다는 걸 여기서 보실 수 있을 거예요. 그래서 이건 양이 많다는 걸 보여드리려고 한 거고요.
노정석 여기서 B 곱하기 S, 이게 prefill의 arithmetic intensity를 결정하는 굉장히 중요한 숫자이긴 하잖아요. 그런데 이 batch가 Transformer를 공부하시는 분들이 많이 헷갈리는 게, Transformer를 training할 때 batch의 개념과 inference에서의 batch의 개념은 좀 다르잖아요. training할 때 batch는 저희가 동시에 몇 문장을 여기에 밀어 넣을 거냐고 얘기하는데, inference할 때 batch는 sequence length가 너무 제각각이기 때문에 이 batch가 사용자의 숫자, 사용자의 머릿수라고 생각하시면 딱 맞습니다. 이 부분은 혼동하시면 안 된다는 말씀을 드려야 될 것 같아요.
Interactivity와 throughput의 trade-off 51:33
이진원 맞습니다. 그리고 benchmark에 대한 얘기를 좀 해보려고 하는데요. 도대체 그러면 어떤 AI 반도체 혹은 어떤 GPU가 좋은 거냐? 이런 얘기를 저희도 많이 듣습니다. “너희 게 얼마나 좋아?” 이런 얘기를 듣지만, 이게 딱 하나의 숫자로 “우리가 어디보다 몇 퍼센트 좋습니다.” 이렇게 얘기하기가 굉장히 어렵습니다. 왜냐하면 조건들이 너무나 다양하기 때문인데요. 그래서 대표적인 게 한 사용자가 얼마나 빠르게 토큰을 받느냐, 사용자당 tokens per second죠. 1초에 몇 토큰을 서비스받는지, 이걸 interactivity라고 합니다. 그리고 서버 입장에서 나는 지금 여러 명에게 serving하고 있는데, 그 여러 명에게 serving하는 토큰 전체의 총합, 초당 전체 토큰 총합을 GPU 개수로 나눠서 GPU당 1초에 얼마나 많은 토큰을 생성하고 있는지, 이게 사용자 한 명에게 가는 건지 100명에게 가는 건지 상관없이 다 합친 걸 throughput이라고 부릅니다.
제가 오늘 아침에도 이걸 녹화하려고 회사에 오면서 배가 고파서 맥도날드에 가서 맥모닝을 시켰는데, 안에서 만드는 게 보이는데도 한참 기다려도 안 나오길래 봤더니 여러 명의 빵을 하나씩 탁탁탁탁 놓고 만드시더라고요. 그게 throughput을 늘리는 거고, 저는 제일 앞에 주문한 사람이었거든요. 그러니까 저의 interactivity는 굉장히 안 좋은 상황이 됐던 거죠. 그래서 지금 드리고 싶은 얘기는 throughput을 올리다 보면 interactivity를 어느 정도 희생할 수밖에 없다는 얘기를 드리고 싶어서, 오늘 아침에 문득 그걸 보니까 딱 이 생각이 나더라고요.
박종현 이게 지난번 고석현 대표님 편에서 말씀하셨던 한 명의 토큰 속도를 쭉 올리기 위해서는 다른 걸 희생해야 한다고 얘기했던 그 지점이었던 것 같습니다.
이진원 그리고 지금 대부분의 프론티어 랩들이 서비스할 때 fast mode 같은 것들이 있잖아요. 예를 들면 Anthropic도 2.5배 빨라지는데 돈을 6배 더 받는다는 얘기들이 있는데, 그게 여기서 나오는 겁니다. 사용자 한 명에게 더 빠른 서비스를 하려면 throughput이 줄어들기 때문에 돈을 더 많이 받아야 하는 거죠. 그래서 이게 SemiAnalysis에서 만든 벤치마크 그래프고요. 이게 한 숫자로 나오는 게 아니고 그래프로 나오게 되는데, x축이 interactivity고, 오른쪽으로 갈수록 더 빠른 겁니다. 사용자들이 더 많은 토큰을 1초에 받는 거고, y축이 throughput이에요. 그래서 이걸 굉장히 다양한 상황에 따라서 지표를 몇 개로 나눠서 하느냐, parallelism도 tensor parallel이 있고, expert parallel이 있고, pipeline parallel이 있고, data parallel 등 여러 가지 기법들이 있는데, 그런 것들을 모두 다른 옵션으로 해서 batch size가 몇일 때까지 전부 다르게 해서 점들을 하나하나 찍으면 이런 식으로 굉장히 많은 점들이 나오게 되고요. 이 점들 중 좀 진하게 칠해져 있는 제일 오른쪽 위의 점들끼리 연결해서 Pareto curve를 그리면 이런 식으로 나오는데, 이게 InferenceX의 핵심 그래프입니다. 그래서 이 곡선 위로는 절대 못 올라가는 거고, 오른쪽으로 갈수록 batch size가 작아지면서 동시에 서비스하는 사람 수가 적어지면서 속도가 빨라지고, 왼쪽으로 갈수록 서버 입장에서는, GPU 입장에서는 더 많은 토큰을 생성해 내지만 한 명 한 명은 속도가 느려지는 거죠.
SemiAnalysis InferenceX Pareto curve 읽는 법 54:26
이진원 이걸 직관적으로 생각해 보시면, 아까 제가 KV cache는 사용자가 늘어나면 늘어나는 만큼 계속 늘어난다고 했잖아요. 그래서 사용자 1명에게만 서비스할 때는 그 1명에 대한 KV cache만 읽어오면 되지만, 10명에게 서비스하면 KV cache도 10배의 데이터를 읽어와야 되고, 그걸 가지고 attention을 해서 10명에 대해 다 해줘야 다음 layer로 넘어가고, layer가 100개면 그걸 100번 반복해야 하는데, KV cache를 읽어오는 시간이 사용자가 늘어나는 만큼 오래 걸리기 때문에, 그리고 KV cache 양이 많다고 했잖아요. 그것 때문에 사용자 한 명이 느끼기에는 당연히 속도가 느려질 수밖에 없는 겁니다. 그래서 개념적으로 그렇게 생각하시면 되고요. 실제 그래프를 보여드리면 이런 식으로 되어 있습니다. 오른쪽에 보시면 각각의 GPU들, NVIDIA와 AMD GPU들이 있고요. 왼쪽에 있는 게 throughput이 높고 사용자 interactivity가 낮은 거고, 오른쪽이 빠른 거라고 생각하시면 돼요.
최승준 앞에서 이렇게 파레토 프론티어 그래프를 그렸을 때는 하나의 GPU를 상정한 거고, 여기서는 여러 개를 쓴다는 건가요?
노정석 그냥 GPU별로 그 curve가 어떻게 되는지를 지금 그린 거죠.
최승준 그러니까 앞의 것은 하나를 상정한 거고,
이진원 아니요. 여러 개를 가지고 하는데, 여기서는 GPU 수로 나눕니다. 그래서 100개를 써도 100으로 나누기 때문에 여기서는 모두 같은 축에서 비교가 됩니다.
최승준 브랜드 하나를, 그러니까 제품 하나를 가지고 plot을 하는 거냐는 거죠.
이진원 이것들을 모은 게 여기 있는 거죠. 그래서 사실 이 그래프 하나가 나오기까지 굉장히 많은 실험이 있어야 합니다.
노정석 그러니까 이게 사실상 어떤 hardware를 쓰느냐에 따라 달라지고, 어떤 모델을 쓰느냐에 따라 달라지고, 또 어떤 inference orchestration software를 쓰느냐에 따라 달라지는 거고, 그 기준들이 여기에 한 번에 다 보이는 거죠.
이진원 그래서 실제 사이트에 가셔서 여기에 마우스를 올려보시면 어떤 configuration인지, software까지 다 나오거든요. 여기에도 대충 있지만, vLLM을 썼느냐, SGLang 같은 걸 썼느냐에 따라서도 달라지고요. parallelism을 어떻게 가져갔는지에 따라서도 달라지고, 그러면 이걸 어떻게 비교하느냐? 보통 어떤 서비스가 있다고 하면 그 서비스에서 requirement가 정해져 있고, 우리는 사용자가 초당 무조건 100토큰 이상 받아야 한다고 하면, 여기 100토큰 지점에서 세로로 선을 그어서 throughput을 비교해 보면 어떤 게 더 성능이 좋은지를 거기서 볼 수 있습니다. 지금 이 그래프에서는 곡선들이 대부분 교차하지 않는데, 실제로 그려보면 교차하는 경우도 꽤 많이 생겨요. 그래서 throughput이 좋은 영역, batch가 많은 영역에서는 안 좋다가 batch가 작은 영역으로 가면서 이렇게 위로 올라가는 것들도 많이 볼 수 있습니다. 그래서 상황에 따라 달라지는데, 공교롭게도 이 그래프는 오른쪽에서 좋은 게 왼쪽에서도 항상 좋지만, 오른쪽과 왼쪽의 양상이 hardware나 software의 특성에 따라 달라질 수도 있다는 얘기를 드리고 싶고요.
최승준 그러면 이 그래프는 누구에게 도움이 되는 그래프인 거예요?
노정석 이 그래프는 실제로 모델을 가져와서 serving하는 서비스를 만들어야 하는 사업자 입장에서 어떤 stack을 선택하느냐에 따라 내가 돈을 버느냐 못 버느냐를 결정해 주는 거죠. 왜냐하면 여기에 빠져 있는 게 사용자들에게 얼마를 받을 것이냐는 부분인데,
이진원 그것도 사실 이 점 안의 configuration 하나로 들어가 있기는 해요. disaggregation이라는 걸 뒤에서 말씀드리겠지만, 하느냐 안 하느냐에 따라서도 굉장히 차이가 많이 납니다.
박종현 유저의 요구 사항인 토큰 수와 interactivity가 정해지면, 내가 어떤 GPU를 샀을 때 throughput이 얼마가 나오니까 수요를 채우면 얼마를 벌 수 있을지, 투자 회수를 계산하는 데나 모델링하는 데도 충분히 쓰일 수 있을 것 같습니다.
노정석 SemiAnalysis가 이걸 하는 이유가 정확하게 그거겠죠. 그래서 예를 들어 ChatGPT나 Anthropic이 어떤 기계를 사서 어떤 cloud를 만들어서 유저에게 얼마를 받고 있는데, 이들이 돈을 벌고 있느냐, 돈을 잃고 있느냐, 이런 것들이 이 그래프를 보면 대략 다 역산되겠죠.
이진원 그래서 이걸 가지고 그 회사의 매출도 예상하고, 굉장히 많은 데이터를 이용해서 SemiAnalysis는 그런 정보를 판매해 수익을 창출하는 비즈니스를 하고 있고요.
노정석 Anthropic의 토큰 마진율이 70~80% 된다는 것도 이런 해석에 기초해서 역산한 거겠죠.
이진원 그리고 올해 GTC도 보시면, Jensen Huang이 LPU 같은 걸 썼을 때 어떻게 좋아지는지를 모두 이 그래프로 보여주고 있거든요. 여기서 오른쪽으로 갔을 때 이렇게 많이 안 내려가고 쭉 유지된다. LPU를 쓰면 bandwidth가 굉장히 좋기 때문에 이렇게 batch가 작은 쪽에서 좋은 성능을 발휘할 수 있다. 이런 걸 보여주는 게 있는데, 이걸 개념적으로 ‘이렇구나’ 이 정도 이해하시면 그런 그래프가 나와도 ‘이게 뭘 말하는구나.’ 이해하실 수 있을 것 같아요.
최승준 SemiAnalysis의 위상이 굉장히 달라졌나 봐요. 이제는 여기저기서 다 인용하고 있어서요.
이진원 네, 굉장히 달라졌어요.
노정석 회사는 이미 엄청나게 수익성이 높고요. 투자도 한 번도 받지 않았고, 그다음에 이런 report를 프론티어 랩들의 economics가 어떻게 되고, 이 회사들이 투자하는 것 대비 2, 3년 내에 어떤 형태의 curve에 이르게 될지, 이런 것들을 전 세계 회사들에 report로 팔고 있는데, 알고 싶은 사람은 굉장히 많잖아요. 저희만 해도 이렇게 궁금한데, 이 엄청난 대기업들은 더 궁금하지 않겠습니까? 그래서 그들이 굉장히 많은 돈을 잘 내고 있는 걸로 알고 있습니다.
이진원 그때 저희가 ICML에 갔을 때 한 번 만나서, 저희도 그 이후에 온라인으로 여러 번 미팅했고요.
노정석 저희 AI Frontier와 SemiAnalysis가 지난 7월 ICML 기간에 파티를 했었죠. Lablup에서요. 그때 한국에 있는 많은 칩 회사와 대기업들, SemiAnalysis 사이의 교류를 저희가 한 번 주선한 적이 있습니다.
vLLM의 continuous batching과 PagedAttention 1:00:51
이진원 그리고 serving하는 vLLM의 feature들을 조금 설명드리려고 하는데, 실제로 그러면 사용자들의 request가 수시로 들어올 거잖아요. 이게 모두 같이 모여서 한 번에 짠 하고 들어오는 게 아니고, 굉장히 무작위로 들어올 텐데, 그걸 서버에서, 데이터센터에서 어떻게 받아서 serving할지가 굉장히 중요합니다. 그래서 vLLM이나 SGLang 같은 serving framework가 굉장히 유명해졌고, 사람들이 그걸 open source임에도 표준처럼 쓰고 있는 거죠.
과거에는 단순하게 생각해서, request가 예를 들어 4개 동시에 들어왔다고 했을 때, 앞의 파란색이 prefill이고 이 빨간색이 decode라고 했을 때, 이걸 묶어서 batching하는 걸 static batching이라고 하는데, static batching을 하면 이 batch가 완전히 다 끝날 때, 4개가 모두 다 끝날 때까지 다음 request가 못 들어오게 되어 있습니다. 그러면 당연히 제일 긴 것을 모두가 기다리는 상황이 되겠죠.
그런데 이러면 이 연한 부분이 낭비되니까, 이걸 막기 위해서 vLLM에서 처음 시작한 건 아니지만 여기 Orca라고 하는 서울대 전병곤 교수님 연구실에서 나온 논문이고, 지금 FriendliAI라고 하는 회사도 창업하셨는데 거기서 이야기한 게 이걸 요청 단위로 하지 말고 iteration 단위로 하자는 겁니다. 무슨 얘기냐면, token 하나가 생성될 때마다 scheduling을 새로 하자고 한 거예요. 그래서 prefill이 끝나고 한 번 보고, 또 decode에서 한 token을 생성한 다음에 보고, 얘네는 다 동시에 생성되니까요. 그래서 여기까지 생성했을 때 R2라고 하는 두 번째 요청이 끝났네. 얘는 그러면 이다음 iteration에서 다음 queue에 있는, 여기서는 R6라고 하는 얘를 받아 주는 겁니다. 그래서 얘가 prefill을 하게 되고, 어떤 step을 보면 prefill과 decode가 섞여서 들어가게 되는 거죠. 초록색이 prefill이라고 보시면 됩니다. 이렇게 하면 꽉 채워서 할 수 있어요.
그런데 prefill과 decode를 어떻게 같이 하지? 이렇게 생각하실 수 있는데, 잘 생각해 보시면 query, key, value를 생성하는 거나 FFN이나 다 똑같은 weight를 곱하는 것이기 때문에 prefill과 decode에 아무런 차이가 없습니다. 단지 차이가 나는 건 attention이죠. 그러니까 batch에 따라서 attention을 다 따로 해 줘야 하기 때문에 그것만 따로 분리할 수 있으면 같이 처리하는 게 아무 문제가 없고, 실제로 이 decode step에서도 이 4개의 batch, 혹은 이 prefill에서도 이 4개의 batch 간에는 attention을 다 따로 하기 때문에 여기서도 따로 하는 건 별로 문제가 되지 않습니다. 다만 다른 점이 있다면, 얘는 query가 하나일 거고 얘는 query가, prompt가 1,000개면 1,000개일 거고, 이렇게 되는 거죠.
여기서 시간 간격을 하나만 더 설명드리면, 시간 간격을 똑같이 표시했지만 이렇게 하면 여기 token 개수가 많으면 이게 좀 길어질 수 있어요. 얘네 decode는 좀 빨리 끝나고, 이렇게 될 수도 있기는 합니다.
노정석 이 부분에 대해 저희 청중에게 배경 설명을 드리면, 저희가 ChatGPT를 쓰는데 저희가 어떤 말을 할지 OpenAI는 알 방법이 없잖아요. 누구는 “안녕, 잘 있었어?”라고 하는 굉장히 짧은 대화를 산발적으로 이어가는 사람도 있고, 누구는 와서 Claude Code를 사용해 코드를 몇천 줄, 몇천 자씩 한 번에 딱 입력하는 사람도 있고, 어떠한 형태의 workload가 올지 서비스 제공자 측은 알 방법이 없거든요. 그런데 그걸 전통적인 방법으로 하면 이 요청 단위의 static batching에서 말씀하신 것처럼 어떤 token은, 그러니까 어떤 사용자는 완전히 비어 있고 어떤 사람은 꽉 차 있고, 그 사이의 빈 slot이 ChatGPT 입장에서 보면 다 돈 낭비이기 때문에 당연한 욕구가 들겠죠. 그 빈 공간을 다 채우자. 어떻게 채워야 할 것인가에 따라 굉장히 많은 최적화 방법이 있는데, 그런 이야기들을 CTO님이 해 주시고 계시는 거라고 이해하시면 되겠습니다.
최승준 패턴은 다 일관적인 거 아니에요? 전산에서 늘 하는 엔지니어링으로 amortize를 최대화하는.
노정석 그거죠. 그렇죠, 최적화죠. 어떻게 빈 버스로 출발하는 걸 줄이고, 사람들을 꽉꽉 채워서 보내느냐. 맥도날드 햄버거 예제와 고속터미널의 버스 예제와 KTX의 승객 예제, 이런 게 다 똑같은 최적화 문제이죠.
이진원 그다음에 PagedAttention이라고 하는 게 있는데, 이건 뭐냐면 우리가 아까 KV를 caching한다고 했잖아요. 그러면 KV를 메모리에 저장해야 하는데, 도대체 ChatGPT나 Claude나 Gemini가 몇 token, 몇 단어로 대답할지 우리는 모르는 상태잖아요. 몇 단어를 대답할지 알면 그만큼의 KV가 나온다는 걸 알고 그만큼 메모리를 미리 할당해 놓을 텐데, 그걸 모르니까 내가 낼 수 있는 worst case, 최대로 많이 냈을 때, 최대로 답을 길게 했을 때를 기준으로 메모리 공간을 잡고 있어야 합니다. 그 요청이 끝날 때까지는요. 그러다 보면 메모리가 실제로는 아까 말씀해 주신 것처럼 짧게 그냥 “안녕”에서 이렇게 짧은 대화를 하는 사람들은 몇 단어, 몇 token 안 하고 끝날 텐데, 그 남은 공간이 다 낭비되겠죠. 그래서 그 낭비를 줄이는 아이디어로, 이것도 굉장히 단순한데 동적으로 메모리를 할당하는 겁니다. page table 개념을 가져오는 거죠. 예를 들어 처음에 첫 번째 output 단어로 Alan이라는 단어가 나왔다고 하면, 그 Alan이라는 단어의 key와 value를 저장하기 위해 메모리 공간을 실제 physical memory의 block 7번에 할당합니다. 그런데 이 공간이 page라서, 예를 들어 4개 단어까지 저장할 수 있는 거예요. 처음에 Alan이 나왔으면 여기에 key와 value를 저장하고, 그다음에 Turing이 나오면 그 옆 칸이 남았으니까 계속 저장하는 거죠. a가 나올 때까지 저장한 다음에 computer라는 단어가 나오면 page가 꽉 찼잖아요. 그러면 그때 새로운 page를 할당하는 거죠. 그래서 여기 block 0번은 지금 physical block 7번과 연결되어 있다. 여기 block 1번은 실제 physical block 1번과 연결돼 있고, 여기 block 2번은 3번과 연결돼 있는데, 여기 filled slot은 지금 한 칸 차 있어. 그러니까 아직 세 칸이 비어 있다고 하는 정보를 알려 주는 거예요. 그래서 이렇게 동적으로 그때그때 메모리에 page를 새로 할당하면 내가 딱 필요한 만큼만 메모리를 쓸 수 있으니까 효율적으로 메모리를 쓸 수 있어서 더 많은 사용자에게 서비스를 제공할 수 있겠다는 개념인 거죠.
하지만 이것도 좋은 아이디어 같지만 단순하지는 않은 게, worst case로 정말 드물겠지만 모두가 다 worst case로 최대 길이의 output을 뱉어 내게 되면 문제가 생깁니다. 왜냐하면 이건 마치 그런 거죠. 은행에서 사람들이 예금을 인출하지 않으니까 지급준비율을 낮게 가져가는 것과 비슷하게, 메모리 공간을 원래는 worst case를 가정해서 전부 그만큼만 서비스해야 하는데 어차피 다 그만큼 쓰지 않을 테니까 추가로 사용자를 더 받아 주는 거거든요. 그런데 그러다가 모든 사용자가 다 최대의 output을 뱉어 내게 되면 메모리 공간이 부족해지겠죠. 그러면 그때 또 이 KV를 밖으로 쫓아내고 나중에 다시 불러오는 이런 작업들을 해 줘야 하기 때문에 소프트웨어적으로 아주 단순하지는 않습니다. 그런데 대부분의 경우에는 그런 일이 잘 일어나지 않기 때문에 유용하게 쓸 수 있는 거죠.
노정석 저런 부분들이 엔지니어링이 깊게 들어가는 부분이고, 저희가 NVIDIA GPU만 쓰고 오픈소스 모델을 올리면 누구나 장사할 수 있는 거 아니야라고 생각할 수 있지만, 그 안에서 어떤 식으로 최적화를 잘하느냐에 따라 정말 돈 단위가 몇 자리를 왔다 갔다 하거든요. 저희는 그 영역을 orchestration 소프트웨어 레이어라고 부르는데, 그 안에 vLLM이나 SGLang이라든지 Kubernetes라든지 굉장히 많은 것들이 들어가 있는데, 그 부분도 하드웨어뿐만 아니라 이 인프라 소프트웨어 영역도 저희가 굉장히 주목해서 봐야 할 산업 영역이라는 말씀도 꼭 한번 드리고 싶어요.
최승준 해 주고 있다는 거죠.
박종현 저 PagedAttention은 논문으로 나와서 그게 오픈소스가 되고 vLLM이 된 걸로 알고 있는데, 아마 거의 모든 inference serving framework에 다 적용되어 있을 겁니다. 지금은요.
노정석 서로가 서로를 모방해서 지금은 다 똑같아져 있습니다.
이진원 그리고 prefix caching도 어떤 요청이 들어오더라도 다 같이 쓰는 것이기 때문에 KV를 미리 계산해서 저장해 놨다가 그냥 가져와서 읽어 쓰자는 거고요.
Chunked prefill과 speculative decoding 1:09:37
이진원 그다음에 chunked prefill이라고 하는 게 있는데요. 중간에 prefill이 끼어들면 이것 때문에 decode가 느려질 수 있습니다. 원래 얘가 없었으면 빨리할 수 있는 걸 얘 때문에 8,192개 token짜리 prefill이 한 번에 들어오게 되면, 얘네 4개를 같이 묶어서 버스에 태우면 얘 때문에 느려지는 거죠. 아까 ridge point가 300밖에 안 됐으니까 이만큼을 처리하려면 굉장히 많은 iteration을 돌아야 하는 거고, 그만큼 얘네가 얘 없을 때에 비해 느려지게 됩니다.
그래서 이걸 어떻게 하느냐면, 그냥 같은 크기로 다 잘라 버리는 거죠. 이게 진짜 버스의 개념인데, 잘라서 이 prefill도 나눠서 집어넣는 겁니다. 그리고 이 chunked prefill을 할 때 우선순위가 있는데, 보통의 경우에는 decode에 무조건 우선권을 줍니다. decode가 있으면 decode를 먼저 태워 주는 거죠. 버스에요. 그다음은 prefill 중에 잘려서 앞의 prefill은 갔는데 버스를 못 탄 prefill들을 태워 주고, 마지막에 새로 들어온 애들, 그래도 자리가 남으면 새로 들어온 애들을 태워 주는 식으로 우선순위가 있고요. 그렇게 해야 서비스 품질을 가장 잘 만족시킬 수 있어서 보통은 그렇게 합니다.
그래서 여기 있듯이 TBT를 낮추고, TBT는 decode와 관련된 거죠. 처음에 이 AI 모델이 대답하기 시작해서 잘 대답하다가 갑자기 중간에 멈추거나 하는 상황이 이것 때문에 생기는 건데, 그걸 줄이고 대신 prefill의 첫 token이 나오는 시간은 조금 희생하겠다는 겁니다. 이렇게 해야 품질이 일정하게 유지되기 때문에 이 방법을 많이 쓰고 있고요.
그다음에 마지막으로 speculative decoding인데, 이건 지난번에 고석현 대표님도 많이 이야기하셨던 거고요. DeepSeek에서 DSpark라고 하는 좋은 방법을 내놓아서 속도를 굉장히 높이는 방법인데, 아이디어는 이것도 굉장히 단순합니다. 우리가 autoregressive하게 decode step에서 한 번에 한 token씩 생성하는 그걸 한 번에 여러 token을 생성하게 할 수 없을까 생각하는 거죠.
그러면 이게 무슨 얘기냐면, 쉽게 얘기하면 KV batch를 늘려서 우리가 decode에서 arithmetic intensity를 높이고 싶었는데 그러면 key-value가 같이 늘어나서 attention은 이득이 별로 없었잖아요. 그런데 그 batch를 안 늘리고도 arithmetic intensity를 높이는 방법이 한 번에 여러 token을 생성하는 거죠. 그런데 한 번에 여러 token을 생성하는 게 쉽지 않잖아요. 왜냐하면 다 dependency가 있는데 두 번째 token을 생성할 때 첫 번째 token을 안 보고 생성하면 당연히 정확도가 엄청나게 떨어지겠죠.
그래서 처음에 개념은 어떻게 시작했냐면 그렇게 하지 말고 작은 모델을 가져와서 대략 100분의 1 크기의 작은 모델을 가져와서 얘를 빠르게 순차적으로 돌리는데 빠르게 돌려서 얘가 예를 들어 이렇게 8개 token을 뽑아내게 한 다음에 이 8개 token을 큰 모델, 원래 모델로 가져와서 한 번에 검증하는 거예요.
그래서 어떻게 하냐면 이게 그냥 prompt prefill phase에 들어온 것처럼 검증하는 겁니다. 이 앞에 물론 더 단어들이 있었을, token들이 있었을 수 있지만 그것까지, 그다음에 원래는 하나만 가지고 하던 것을 다 가져와서 한꺼번에 하는 거죠.
그럼 prefill처럼 다 똑같이 한 다음에 마지막에 다음 token을 생성할 때 원래 prefill에서는 이 마지막 단어에서 다음 단어를 뽑는 것만 했는데 그렇게 하는 게 아니고 얘에서도 다음 단어를 뽑고 얘는 이거 2개를 보고 다음 단어를 뽑고 얘는 이거 3개까지 본 것을 가지고 다음 단어를 뽑고 얘도 다음 단어를 뽑고, 다음 단어를 뽑아서 the 다음에 cat이 나오는지를 보는 거고요. 얘는 the까지 맞았다고 하고, the cat까지 맞았다고 하고 그다음에 sat이 나오는지를 보는 거고 이렇게 검증하는 겁니다.
그러니까 모든 건 다 병렬로 진행하고 마지막에 LM head만 순차적으로 처리하면 이거를 굉장히 빠르게 한꺼번에 다 볼 수 있겠죠. 그래서 가다가 the cat, sat on 하다가 여기 the가 아니었다, 아니야, mat이 틀렸다고 하면 이게 mat이 아니고 bench였다고 하면 bench까지 맞았구나 하고 다시 이 작은 모델, 이걸 draft model이라고 하는데 draft model한테 보내는 거죠. 그러면 draft model은 그 bench 다음에 또 8개 단어를 쭉 빠르게 뽑고 그걸 가져와서 한 번에 큰 모델이 검증하고 이거를 계속 반복하면 serving 속도를 굉장히 빠르게 할 수 있겠죠. 이게 speculative decoding이고요.
이게 단점이 있다면 모델 2개를 써야 되니까 계속 작은 모델 한 번, 큰 모델 한 번 이렇게 왔다 갔다 하면서 돌려야 하는 어려움이 있어서 같은 모델 안에서 draft model처럼 동작하게도 하고 그다음에 검증을 다시 하고 이렇게 하는 연구들도 있었습니다.
Meta에서 이런 논문이 있었어요. 우리가 layer가 100개짜리 모델인데 꼭 100개 layer까지 가야만 다음 token을 정확하게 예측할 수 있냐, 어떤 쉬운 단어는 10개 layer만 가도 예측할 수 있지 않을까 해서 그거를 모두 통계로 내본 거죠. 중간에 이 network를 잘라낸 다음에 예를 들면 100개 layer짜리를 50개 layer로 자른 다음에 거기다가 LM head를 붙여서 예측하고 얼마나 맞는지 검사해 본 거예요.
그래서 실제 정답을 몇 번째 layer에서 처음으로 맞히는지를 모두 통계로 낸 다음에 예를 들어 70개 layer까지 가면 거의 다 맞히네. 그런데 50개 layer까지 가도 70%는 맞히네. 그러면 그냥 50개 layer까지만 해서 빠르게 예측한 다음에 검증을 한 번 하고 이렇게 하면 같은 모델 안에서 예측을 빠르게 하고 검증도 하고 이렇게 할 수 있겠죠. 이런 형태로 하는 방법도 있고요.
DSpark는 또 조금 다른 방법으로 하긴 했는데 예를 들면 diffusion transformer 같은 형태를 사용해서, diffusion transformer는 autoregressive하게 token을 생성하는 게 아니고 한 번에 여러 token을 다 뽑아내게 되거든요. 그럼 그거를 draft model로 써서 검증은 원래 모델에서 하고 이런 방법도 사용할 수 있습니다.
최승준 DSpark 말고 EAGLE-3는 뭐예요? 여기에도 나오지만 종종 보이던데요.
이진원 EAGLE-3도 그냥 speculative decoding을 하는 모델이고요.
노정석 저희 청취자분들 입장에서는 그래서 도대체 이걸 왜 하느냐가 중요한 건데, 계속 prefill과 decode의 균형을 어떻게 맞춰서 단위 전기세, 단위 GPU당 생성해 내는 token 수를 높일 것이냐는 문제를 지금 다 풀고 있는 거고 이 speculative decoding을 하는 이유는 prefill이 decode보다 훨씬 싸다. 그래서 decode에 들어가는 노력이 너무 크니까 더 싼 모델이 decode를 빨리 돌게 하고 걔가 맞힌 정답지를 prefill에, 큰 모델의 prefill phase에 넣어서 맞는지 안 맞는지 한 번에 검증해서 그사이에 이득을 보겠다고 하는 시도라고 이해하시면 될 것 같습니다.
최승준 그리고 지금 관측된 ridge point가 300 언저리라고 해도, 그게 더 올라가더라도 이 체계는 유지되는 거죠?
노정석 이건 영원히 이렇게 갈 겁니다.
박종현 그리고 저도 이걸 보면서 드는 생각이 아까 PagedAttention도 그렇고 speculative decoding도 그렇고 어떤 연산을 compute-bound와 memory-bound 사이에서 전환시키는 알고리즘상의 방법들도 그렇고, 다 전통적으로 CPU나 OS 같은 CS 분야에서 하던 방법들이 LLM과 GPU에 맞게 넘어온 듯한 느낌이 들거든요. 최적화의 본질 같은 것은 계속해서 재활용되고 있다. 그러니까 옛날 것들을 잘 알고 있는 게 미래의 것들을 잘 아는 데도 다 도움이 되는 것 같다는 생각이 들었습니다.
이진원 그리고 제가 하나 첨언하고 싶은 것은 DSpark 같은 것을 보면 DeepSeek 친구들이 굉장히 잘하는 게, 이 검증도 사실 overhead가 될 수 있거든요. 왜냐하면 지금은 이 그림에서 4개만 맞고 4개가 틀렸는데 뒤로 갈수록 틀릴 가능성이 좀 더 높아질 거잖아요. 아무래도 이 뒤에 있는 것을 검증하느라 연산을 쓰는 게 아깝다. 그리고 지금 연산이 빡빡하게 돌아가고 있는데 얘가 들어와서 쓸모없는 연산을 하는 게 아깝기 때문에 현재 compute resource의 상태를 보고 몇 개까지 검증할까, 아예 compute가 빡빡하다면 예를 들어 얘가 8개를 생성했어도 뒤의 2개를 빼고 6개만 검증한다든지, 이런 식으로 상황에 맞춰 token을 몇 개 검증할 건지를 조절하는 것들이 구현돼 있어서 저는 보면서 꽤 놀랐던 것 같아요. ‘이런 것까지 최적화하는구나’라고요.
박종현 그리고 저 token을 예측하고 맞는지 검증하는 건데, 사실 token이라는 게 확률적으로 나오는 것이기 때문에 이 임곗값을 결정하면, 왜냐하면 token으로 A가 나와도, ‘안녕하세요’가 나와도 ‘안녕하십니까’가 나와도 둘 다 맞다고 볼 수도 있잖아요. 그래서 확률이 가장 높은 token이 아니더라도 꽤 괜찮은 확률의 token이면 그냥 맞다고 치고 넘어갈 수도 있는 거잖아요. 그것도 저희가 조절할 수 있는 거잖아요. 그러니까 품질을 티가 안 나는 선에서 희생하면서 token 수를 올리는 행위도 충분히 가능할 것 같고 실제로도 이미 많이 하고 있는 것으로 알고 있습니다.
Prefill pool과 decode pool을 나누는 PD disaggregation 1:18:53
이진원 넘어가겠습니다. disaggregation 얘기를 좀 하려고 합니다. 그런데 우리가 prefill이랑 decode가 너무 다르다는 얘기는 계속했고, arithmetic intensity가 sequence length 곱하기 batch에 영향을 받고 decode는 attention을 제외하면 batch에만 영향을 받는다, 이렇게 알고 있고요. 그래서 roofline에서 굉장히 멀리 떨어져 있는 것을 알 수 있었죠. 그래서 아까 말씀드렸다시피 chunked prefill을 한다고 하더라도 어쨌든 prefill이 들어오면 decode는 성격이 다르기 때문에 prefill이 많이 들어오면 decode에 영향을 주고 반대로 decode에만 우선순위를 주면 prefill의 TTFT가 안 좋아지기 때문에 간단하게 이걸 나눠서 하자. 그래야 요구되는 SLO를 만족하는 throughput, 그걸 goodput이라고 하는데 goodput을 늘릴 수 있겠다는 개념으로 시작한 겁니다.
그래서 prefill pool과 decode pool을 놓고 이걸 나눠서, 그러니까 Jensen Huang이 Token Factory라는 얘기를 많이 하잖아요. 저는 그게 이런 부분도 있다고 생각하는데 token을 많이 생성한다는 의미도 있겠지만 그것보다는 컨베이어 벨트에서 자동차를 만드는데 어떤 사람은 바퀴를 조립하고 어떤 사람은 문을 끼우고 이런 것처럼 하나하나의 단계에 따라서 그 하나만 하는 pool을 만드는 거죠. 그래서 prefill만 하는 prefill pool, decode만 하는 decode pool을 나눠서 이걸 PD, prefill-decode disaggregation이라고 부릅니다. 그래서 대신 이 prefill에서 만들어진 모든 key-value는 decode pool로 전송해 줘야겠죠. 그래서 disaggregation을 하면 이 사이의 네트워크 속도도 굉장히 중요합니다. 이거는 어느 정도 규모가 있지 않으면 별로 이득이 없어요. 규모가 있을 때 이득이 있는 거고요.
그래서 아까 말씀드린 것처럼 raw throughput 측면, 그러니까 token을 얼마나 생성해 내는지의 측면에서 보면 올라가지 않아요. utilization이 똑같다. 얘네들이 다 100%로 돌고 있다. 똑같은 GPU를 쓰더라도 보통 처음에는 Microsoft에서 나온 Splitwise라는 논문에서 처음으로 disaggregation 관련 얘기가 나왔는데 여기 보시면 똑같은 H100 GPU를 가지고 prefill의 개수를 다르게 합니다. 아무튼 개수를 다르게 해서 throughput을 맞춰주는데 이게 어느 정도 규모가 돼야 이득이 있고요. 그다음에 모두 100%로 돈다고 하면, GPU 100개를 어느 정도 비율로 나눴다고 하면 그 100개가 전부 돌고 있으면 생성하는 token은 다 똑같을 거고 해야 하는 연산량이 정해져 있으니까요.
하지만 좋아지는 것은 goodput이라고 해서 우리가 만족해야 하는, 초당 30개 token 이상 나와야 한다는 것을 만족할 수 있는 throughput, 그걸 만족하는 throughput이 올라가게 되는 겁니다. 이거는 굉장히 크게 올라가고요. 그래서 요즘은 다 이거를 굉장히 많이 쓰고 있습니다. 그래서 disaggregation 효과가 언제 크고 언제 작은가 보면, 효과가 크려면 입력이 길고 출력이 짧으면 prefill 비중이 커서 decode가 영향을 많이 받게 되는데 그때 쓸 수 있고요. 그다음에 SLO가 빡빡해서 굉장히 타이트하게 우리는 이것을 무조건 절대적으로 지켜야 한다, 이런 게 있으면 쓰면 좋고, 결국에는 고대역 interconnect가 있어야 되고, 규모가 큰 경우에는 요약하면 이렇게 되고요.
효과가 작은 경우, 반대로 좀 작은 사이즈에서는 그냥 chunked prefill 방법을 쓰는 게 사실상 더 이득이 있다고 볼 수 있습니다. 그리고 특히 interconnect의 영향을 많이 받고요. 그래서 NVLink 같은 굉장히 빠른 속도의 네트워크를 보유하고 있기 때문에 NVIDIA GPU는 이게 굉장히 잘 맞는데, 그것보다 훨씬 느린 인터페이스를 가지고 있는 AI 반도체가 있다고 하면 이 disaggregation의 이득이 생각보다 별로 없을 수도 있다, 이런 얘기를 드릴 수 있습니다. 여기까지 inference engineering에 대한 얘기를 다 드렸고요. 더 많지만, 제가 중요하게 생각하는 것들을 소개해 드렸습니다.
노정석 거의 inference engineering에서 필수적인 부분들은 오늘 다 다뤄주셨어요. 그 roofline에서 compute와 memory 사이에 어떤 최적점을 만들어야 하는지 말씀해 주셨고, 그 뒤에 interactivity와 throughput 사이의 trade-off에 대해 말씀해 주셨고, 그 뒤에 각종 기법들, 이 안에 들어가 있는 각종 기법들을 한 번 싹 다뤄주셨는데, 말씀해 주신 모든 게 지금 현존하는 production에 다 들어가 있는 거잖아요.
노정석 맞습니다. 그리고 오늘도 계속 발전하고 있고, 이런 것들을 다 알아야 칩도 만들 수 있다.
Agentic AI가 만드는 새로운 inference workload 1:23:33
이진원 그래서 이다음에는, 여기는 그냥 LLM을 우리가 챗봇처럼 쓰거나 혹은 reasoning 정도로 쓸 때의 얘기고, agentic AI, 저도 AI agent를 굉장히 많이 쓰고 있는데, agentic AI가 오면 조금 달라지는 얘기가 있어서 개념적으로만 이런 식으로 달라질 수 있겠구나. 그래서 요즘 AI agent의 workload를 분석한 논문들이 갑자기 많이 나오고 있어요. 최근에는 여기 아래 보시면, 8월에 Copilot의 26년 6월 한 달 동안의 trace를 다 분석해서 낸 논문도 있고, 그다음에 TraceLab이라고 하는 것도 있는데, 이런 논문들을 좀 참조했고요.
용어를 좀 정리하기 위해서 session, request, 그다음에 step, 이렇게 보면 session은 뭐냐 하면, 우리가 AI agent를 시작해서 agent가 완전히 종료될 때까지를 session이라고 생각하시면 되고, request는 그 안에서 사람이 prompt를 주고 AI agent가 loop를 돌겠죠. LLM도 call하고 tool도 call하면서 loop를 돌아서 결과를 내놓을 때까지가 한 번의 request입니다. 그러면 그것을 사람이 다시 보고 feedback을 주고 다른 일을 또 시키겠죠. 그다음 일이 request인 거고요. 그래서 request의 시작은 항상 사람의 prompt로 시작한다는 것, 그다음에 request 안에서 LLM도 수행되고 또 tool도 수행되고, 이렇게 LLM이나 tool을 한 번 call하는 것을 step이라고 보시면 되고요.
그래서 통계를 보니까 session은 평균 62.6분이고, request가 session 하나당 9.2개 정도 있고요. request 하나 안에는 step이 9번 정도 있어서, 대략 session 하나에 계산하면 100번 정도의 step이 들어간다고 보시면 될 것 같습니다. 당연하지만 실제로 LLM을 call하는 것의 대부분, 그러니까 90% 정도, 이 두 개의 빨간색 90%는 AI가 호출하더라. 그러니까 AI를 사람보다 AI가 더 많이 쓰는 거죠. 사람은 prompt를 넣어줬을 때 그때 한 번만 사람에 의해 LLM이 call되는 거고, agent가 loop를 도는 동안은 계속 agent가 LLM을 호출하니까요.
그리고 이게 굉장히 많은 interaction을 거치고, 중간에 reasoning하는 과정도 있고요. 우리가 챗봇으로 쓰다가 reasoning으로 가면서 생각하는 thinking token들을 굉장히 많이 내놓게 됐잖아요. 그래서 길이가 길어졌고, 그만큼 앞에서 얘기했던 KV cache 공간도 많아졌는데, 이제는 reasoning하는 LLM 호출이 이 agent의 아까 step 한 번에 들어가 버리는 거예요. 그러면 거기에 다시 몇 배가 되겠죠. 이 LLM이 수행될 때 보면 그 앞에 쌓여 있던 KV cache를 읽어오는 게 거의 대부분이고, 11만 9천 개의 token은 prefix에서, 그러니까 예전에 계산했던 KV cache를 읽어오는 거고, 새로 추가된 것은 875개고, 그로 인해 나오는 output token은 214개다. 100분의 1 수준이잖아요. 그래서 그 정도로 다시 읽어오는 게 굉장히 중요해졌다.
그리고 또 중요한 게, 이 모든 workload가 heavy-tail입니다. 우리가 long-tail인데, 그 tail이 굉장히 영향을 많이 주는 heavy-tail인 거죠. 그래서 worst case를 무시하면 agent 서비스는 망합니다. 그래서 worst case를 항상 고려해야 되고, 이것을 잘 알 수 있는 게 중앙값과 평균의 skew가 거의 15배나 벌어질 정도예요. 평일 사용과 주말 사용 같은 것들도 분석해 놓은 게 있는데, 평일에는 당연히 사용량이 훨씬 많고요. session 같은 것의 개수가 많은데, 주말은 그 개수가 적은 대신, session당 iteration이 훨씬 많이 돕니다. 그래서 당연히 사람들이 더 복잡한 job을 주말에 돌려놓고 집에 가거나 하기 때문에 그럴 거라고 예상할 수 있고요.
사람이 만드는 대기 시간과 KV cache 골든타임 1:27:22
이진원 그 session 하나 안을 분석해 보면 request와 request 사이에 사람이 판단해서 AI가 내어 준 결과를 이해하고 다시 다음 요청을 보낼 때까지 시간이 있겠죠. 보통 저 같은 경우도 agent에게 일을 시켜놓고 다른 agent를 이용하거나 다른 일을 하다가 와 보면, 다 돼 있네 하고 확인하기 때문에 사람이 AI가 계속하는 것을 보고 있는 건 아니잖아요. 대부분 다른 일을 하다가 오니까 그 시간이 많이 낭비되고요. 그래서 session 전체의 약 92%를 사람이 잡고 있는 거고, tool이 call하는 건 4.8%, LLM은 3.3%여서 거의 1 대 1이라고 보면, 실제 얘네들이 쓰는 건 8%고 사람이 92%의 시간을 쓰더라. 사람이 병목이라는 얘기죠.
그런데 이게 단순히 사람이 병목이라는 의미만 있는 게 아니고, 그러면 얘네들이 앞에서 tool이나 LLM으로 만들어낸 KV cache를 사람이 언제 올지 모르는 상황에서 HBM이라는 비싼 memory에 계속 잡고 있어야 하느냐, 그에 대한 문제가 있습니다. 그래서 session 안에 있는 request와 request 사이에 사람이 대기하는 시간의 중앙값이 25분이에요. 25분 동안 이 KV cache를 잡고 있으면 굉장히 낭비거든요. 그리고 그동안 자리를 지켜 그 공간을 차지하고 있는 KV cache 용량의 중앙값은 대략 40GB 정도 됩니다.
그래서 대부분 25분 정도 되면 지금은 다 쫓아내고요. storage 같은 곳으로 보내고, 5분에서 10분이 골든타임입니다. 현재 분석된 것으로는 그 정도까지는 갖고 있되, 그 이상이 되면 이것을 또 예측합니다. 이것은 굉장히 가벼운 machine learning 모델을 사용해서 이 사람이 10분 안에 돌아올지 안 돌아올지 예측해서, 안 돌아올 것 같으면 빨리 내보내는 방법도 쓰는데, 정확도가 생각보다 높다고 해요.
최승준 사용자별로 학습시키는 거예요?
이진원 사용자별로 하는지, 그냥 어떤 내용을 보고 하는지.
박종현 쉽게 상상해 보면, 자기 전에는 엄청 길게 돌려놓고 자러 가서 아침에 일어날 때까지 시간이 엄청 길잖아요. 그러니까 몇 시에 돌렸느냐도 영향을 줄 것 같고, 어떤 과제를 시켰느냐도 영향을 줄 것 같고, 그런 것들을 가볍게 분류해서 하는 것만으로도 정확도가 엄청 올라갈 것 같긴 합니다.
이진원 그 논문에 따르면, 몇 분 후에 돌아올지를 예측하는 것은 좀 쉽지 않은데, 빨리 돌아올지 빨리 안 돌아올지는 그래도 예측이 잘되는 편이다.
노정석 agent workload는 compute-bound가 아니라 어마어마하게 다 memory-bound네요. bound라는 표현이 무색하게 그냥 memory work네요. 들고 있기 게임이네.
이진원 그래서 결국 다시 읽어오는 데도 비용이 많이 든다. 이것을 또 계산해 보면, 여기 cloud에서 서비스를 빌려 쓰는 것을 기준으로 계산해 보면, 60%가 prefix를 읽을 때 사용하는 비용이 된다. 그다음에 이것을 쫓아냈을 때, 그러면 이것을 아예 삭제한 다음에 다시 사용자가 돌아왔을 때 KV cache를 다시 계산할 수도 있잖아요. 아니면 CPU의 DRAM이나 혹은 storage에 보낸 다음, 그것을 다시 읽어오는 방법이 있을 거고요. 그 두 개를 비교했을 때 어떤 게 더 좋냐고 하면, 거의 대부분의 경우 멀리라도 갖다 놓았다가 읽어오는 게 좋다는 얘기입니다. 다시 계산하려면 시간도 오래 걸리고 비용도 많이 드는데, 이것을 읽어오는 것은 시간이 좀 걸리더라도 그보다는 훨씬 짧기 때문에 이게 더 유리해서 이쪽으로 많이 가고 있습니다.
재계산 대신 다시 읽어오는 KV cache와 계층형 메모리 1:30:10
이진원 그리고 이것을 읽어오는 동안 어떤 연산을 할 수 있으면 이게 아예 가려질 수 있어서 더 좋다, 이런 얘기인 거고요. 이제 memory도 hierarchical하게 써야 되고, SRAM, HBM, DDR, SSD 혹은 high-bandwidth flash 같은 것도 요새 많이 얘기하고 있는데, 이런 것까지 다 역할을 잘 나눠서 KV cache의 중간 결과물들을 어떻게 scheduling해서 언제 어디로 보내고, 언제 다시 가져올지를 잘하는 게 agentic AI에서 새롭게 떠오르는 굉장히 중요한 것이다. 그러면 이것을 또 잘해주는 open-source, 아까 vLLM이나 SGLang 같은 소프트웨어들이 앞으로 많이 생겨나겠죠. 그래서 병목은 compute에 있다가 memory에 있다가 power가 됐다가 이렇게 계속 왔다 갔다 하는 거고, 그때마다 답이 달라지고, 사람들은 한쪽에 병목이 있으면 어떤 방법으로든 해결하려고 한다는 얘기를 오늘 드리고 싶었습니다.
노정석 사람들이 어마어마하게 일을 많이 시키는데, 그 일은 대부분 cloud 입장에서 봤을 때는 기억하고 있기 게임이지, 계산량은 굉장히 적다는 말씀을 하셔서, 그러면 거기에서 저희 앞으로 메모리 회사들에 대한 수요는 한참은 더 늘어갈 거라는 말씀도 드리고, 또 그 안에서 이들이 최적화도 많이 할 것이기 때문에 이런 inference work을 제공하는 회사들의 마진은 상당 부분 계속 높게 유지될 가능성이 높을 것 같아요.
Anthropic과 OpenAI는 수익성이 계속 좋아질 것 같습니다.
최승준 예를 들어서 context agent workflow를 하다가 context가 압축됐어요. 그러면 압축된 최종 KV만 들고 있겠다는 거죠. 그전 것은 남길 이유가 없는 거죠.
이진원 압축된 KV만 들고 있게 되고요. 그게 압축되면서 깨지는 것들도 생길 수가 있어요. 그래서 그때는 다시 연산을 해야 되는 경우도 생깁니다.
노정석 그런데 compacting은 모델이 정해 놓은 한계 때문에 어쩔 수 없이 생기는 거니까, 중요한 것은 cloud마다 제공하는 max 콘텍스트 길이가 지금 다르잖아요. 어떤 것은 Opus 1M, 1M, 100만 토큰을 콘텍스트 길이로 제공하지만 어떤 것은 27만 토큰만 제공하는 게 있으니까, 그런 것은 완전히 farm을 다르게 쓰고 있다는 얘기니 그에 따라 charging하는 금액들이 완전히 다르게 책정되어 있겠죠.
박종현 HyperAccel이라는 회사 입장에서 어떤 전망이나 미래 같은 것을 어떻게 바라보고 계신지 궁금합니다. 왜냐하면 HyperAccel도 컴퓨트, 메모리, 파워라는 모든 인프라에 필요한 새로운 칩을 만들고 계시고, 칩이랑 computing platform 자체를 만들고 계신 거니까요. 그런데 HyperAccel 말고도 당연히 엄청나게 많은 팀이 그런 것을 다 해결하려고 하고 있잖아요. 그러면 inference hardware라는 시장 자체가 앞으로 계속 커질 것이고, NVIDIA GPU가 지금 inference 시장에서도 가장 많이 쓰이고 있는데, 결국에는 Groq을 포함해서 Groq이든 Cerebras든 TPU든 여러 칩이 다 들어오게 되어서 많은 부분을 대체할 것 같아요. 최근에 들은 소식으로는 뭐였죠? GLM-5.3 Flash, 그것도 완전히 중국산 칩으로 inference했다고 제가 들었거든요. 그렇게 발표했던 것 같아요. 앞으로 그 시장은 어떤 식으로 지형이 변할 것 같으신지 궁금합니다.
GPU와 LPU가 결합하는 heterogeneous computing의 미래 1:34:21
이진원 굉장히 좋은 질문이고, NVIDIA가 Groq을 인수한 이유가 아까 roofline 그래프를 굉장히 다양한 AI 반도체와 GPU를 포함해서 하드웨어들의 그래프라고 했으니까 그려 본 건데요. 여기 제가 진하게 해 놓은 Vera Rubin이 이렇게 생겼고, Groq은 이렇게 생겼거든요. 아까 아래로 내려 보면 얘가 훨씬 더 bandwidth가 높다는 것을 위로 올라가 있으니까 알 수가 있겠죠. 그래서 아까 제가 prefill-decode disaggregation을 말씀드렸는데, 이 Vera Rubin 패밀리에서는 그걸 LPX라고 부르죠. LPX가 하는 역할은 disaggregation에서도 prefill은 다 Rubin GPU로 하고, decode도 다 Rubin GPU로 하되 attention까지는 하고, FFN만 Groq의 LPX를 가지고 하는 거거든요. 그런데 얘는 arithmetic intensity의 ridge point가 여기에는 8이라고 나와 있네요. 한 자릿수인 거죠. 그래서 이 파란색보다 이 빨간색 그래프가 위에 있는, arithmetic intensity가 상대적으로 그렇게 높지 않은 영역에서 Groq의 LPU가 이득이 있는 겁니다. 그래서 아까 InferenceX도 오른쪽에 그 영역이 배치되는 거고요.
그런데 Groq은 SRAM만 쓰고요. 500MB 정도 되는데, 이번에 이 Rubin 패밀리에 들어간 칩이 그러면 500MB는 굉장히 작은 크기잖아요. 그래서 여기에 앞에서 얘기했던 그런 KV들을 다 담을 수가 없겠죠. 당연히 담으려면 엄청나게 많은 칩을 써야겠죠. 그러다 보니까 FFN에는 KV가 없잖아요. 그래서 거기에 적합하다는 것이 하나 있고, 또 하나는 그래도 FFN은 아까 batch를 늘리면 batch를 늘리는 만큼 arithmetic intensity를 높일 수 있는 영역이니까 거기는 적합하지 않은 것 아니냐고 생각하실 수 있는데, MoE가 오면서 expert들마다 batch가 나뉘어 들어가게 되잖아요. 그래서 expert 하나의 입장에서 볼 때는 상대적으로 batch size가 작아지게 됩니다. 그래서 거기는 arithmetic intensity가 여전히 낮게 되고요. 그래서 거기에 아주 적합한 solution이 되는 거죠. 서로 KV를 전달할 필요도 없고, 그 데이터를 GPU랑 LPU 사이에서 전송할 필요가 거의 없고, 이 토큰들만 왔다 갔다 하면 되기 때문에 굉장히 현명한 solution입니다.
그래서 확실하게 좋은 특성이 있으면 그게 이 inference pipeline, serving pipeline 안에 들어갈 수 있는데, 예를 들면 앞으로 agentic AI의 특성에 따라 우리는 외부 메모리에서 데이터를 굉장히 빨리 읽어 올 수 있다든지, 외부에 엄청나게 큰 메모리가 이 칩 가까이에 붙어 있다든지, 이런 식의 특성이 있으면 KV를 그쪽으로 보내서 일종의 일부 연산도 하면서 저장 공간으로 쓰거나 할 수도 있잖아요. 그런 식으로 어떤 특성이 있으면 그게 이 pipeline에 잘 들어맞을 때 굉장히 heterogeneous하게 동작하는 그런 세상이 올 겁니다. homogeneous한 computing은 거의 끝나 가고, 뭐가 됐든 잘하는 것을 찾아서 끼워 넣는 작업들이 앞으로 이루어질 겁니다. 그래서 저희 HyperAccel도 첫 번째 제품은 가격과 전력이 굉장히 병목이라고 생각해서 그것에 초점을 맞췄다면, 지금 다음번 제품을 준비하고 있는데요. agentic AI의 특성에 잘 들어맞는 방향으로 준비하고 있습니다.
AI가 바꾸는 반도체 설계와 검증 1:37:54
최승준 저는 이번 Jalapeño도 그렇고, 다른 것에도 그런 뉘앙스들이 있는데, 칩 디자인에서의 RL 과제가 verifiable한 영역으로 가고 있는지가 궁금하거든요.
이진원 그것도 굉장히 흥미롭고, 저도 제일 관심 있는 부분 중 하나예요. 왜냐하면 저도 입버릇처럼 한 3년 지나면 저는 이 일을 못할 것 같다는 얘기를 많이 하고 다니는데, AI가 저보다 훨씬 더 잘할 거라고 믿기 때문입니다. 그래서 그나마 어느 정도 다행인 것은 FPGA에서 만들어서 논문도 내고 하셨던 것 같은데, 생각보다 굉장히 잘 되고요. verifiable한 영역들도 꽤 많이 있습니다. 전체가 다 한 번에 들어오기는 쉽지 않지만, 이미 설계 일부, 그리고 특히 검증하는 것, 내가 설계한 게 제대로 동작하는지 검증하는 것은 완전히 software 영역이거든요. 그런데 설계는 hardware를 고려해서 RTL, Verilog 같은 language로 coding하는 건데, hardware-aware하게 coding해야 되기 때문에 고려할 것들이 있지만, 결과가 좋은 건지, 잘 만든 건지 못 만든 건지도 평가하는 기준이 경우에 따라서 많이 달라질 수 있어서 어려운 부분이 있기는 하지만, 어쨌든 metric이 없지는 않기 때문에 verifiable하다고 생각하고 있고, 저는 이게 시간문제라고 생각하는데, 결국에는 설계만 잘하면 되느냐, 검증만 잘하면 되느냐의 영역이 아니고, 그걸 바탕으로 physically하게 transistor level로 layout, P&R, place and route도 잘해야 되고, 굉장히 복잡한 문제들이 많이 있거든요.
그래서 그런 것들이 다 합쳐져서 좋은 반도체가 나오고, 제대로 동작하는 반도체가 나오는 거라서 시간이 조금 걸릴 거라고 생각하지만, 얼마 남지 않았다고 생각하기도 합니다. 그래서 OpenAI도 보면 software 같은 것, 특히 CUDA 얘기도 많이 하면서 CUDA와 관련된 것들을 자기들이 Codex를 이용해서 금방 다 만들었다고 했습니다. 예를 들면 MLA 같은 것은 kernel이 없었는데, 자기들이 DeepSeek을 올리기 위해서 Codex가 뚝딱해서 다 만들었다, 이런 얘기도 했었는데, 그런 것을 보면 머지않은 것 같아요.
특수 목적 AI 칩의 춘추전국시대 1:40:08
박종현 저도 이야기를 듣고 생각이 드는 게, 원래 hardware를 찍어 낸다는 것 자체가 한 번 찍으면 비용이 엄청 커서 tape-out하기 전에 verification하는 simulation software라든가 이런 것이 엄청 잘되어 있잖아요. 그래서 AI가 verification을 돌릴 수 있는 도구들이 software상에 잘 준비되어 있어서 그런 것들을 잘 만들어 낼 수 있을 것 같고, 진원님께서 설명해 주신 대로 hardware가 어떤 trade-off를 가지고 있어서 Groq처럼 저렇게 특별한 목적을 위한 hardware들이 잇달아 나오게 되고, LLM이라는 하나의 과제 안에서도 분리해서 trade-off에 맞게 일을 떼어서 이건 Groq에, 이건 GPU에, 이건 Cerebras에, 이건 무슨 hardware에 이렇게 나눌 수 있으니까 hardware도 더 빨리 나오고, 다양하게 더 빨리 나올 수 있고, 일도 떼어 낼 수 있고, 이런 춘추전국시대라고 해야 될까요? 하나의 GPU가 모든 일을 다 하는 게 아니라, 마치 CPU만 있다가 GPU가 게임을 위해 나온 것과 비슷하다고 생각되네요. 특수 목적의 hardware들이 주르륵 나오는 시대가 되지 않을까, 저도 질문과 답변을 들으면서 너무 잘 들었습니다.
최승준 네, 재미있었습니다. 아는 수준에서도 재미있는 게 있었고, 또 새로 배우는
노정석 것들이 있었고요. 그리고 가르쳐 주신 이 요소들이 오늘도 끊임없이 프론티어를 향해 나아가고 있는 거죠. 모델만 프론티어로 가는 게 아니라, 이 인프라도 끊임없이 프론티어로, 프론티어로 가고 있다고 보면 되겠죠.
최승준 우리나라 업체인 HyperAccel을 포함해서 이런 쪽에서도 계속 달려 주시는 게 반갑고 좋은 소식인 것 같습니다.
마무리 인사와 AI 인프라 산업화의 가속 1:41:42
노정석 이런 내용들은 앞으로도 새로운 칩이 나온다든지, 아니면 Jensen도 나올 때마다 AI factory 얘기를 하면서 그 구성을 끊임없이 바꿔 가고 있잖아요. 그리고 NVIDIA가 가지고 있었던 우위가 방금 진원님이 말씀해 주신 것처럼 요소별로 수많은 업체가 와서 다 공격해서 뜯어 가고 있는 듯한 이미지도 있거든요. 그래서 앞으로 또 1년은 어떻게 바뀔지 정말 재미있을 것 같습니다. 저희가 딱 1년 전만 생각하더라도 이런 inference 얘기가 아니라, 그냥 새로운 모델이 나왔습니다, 그런 얘기를 하고 있었거든요. training은 어떻게 했을까, 이건 어떻게 만들었을까. 추론 모델 얘기하던 게 불과 1년 반 전입니다. 그런데 지금은 그런 것들은 다 떠나서 이게 산업화가 완전히 된 거죠. 어떻게 해야 이익을 보는 클라우드를 만들어서 장사를 할 수 있느냐, 이런 단계까지 와 있는 게 격세지감인 것 같고, 또 이 변화의 속도는 한 달 단위로 더 빨라질 거니까 정신 바짝 차리고 따라가야 할 것 같습니다.
최승준 이번 주도 여러 소식이 있긴 있었는데 Cursor랑 OpenAI가 싸우는 일도 있고, NVIDIA랑 OpenAI가 싸우는 일도 있고, 다양한 소식들이 있더라고요. 엄청난 경쟁 상황인 거죠.
노정석 그런데 제가 요새 심심치 않게 요청을 받고 있는 건데, research나 model engineering을 하는 목적이 아니라 단순히 투자 목적이라든지, 아니면 이 변화를 더 잘 이해하고 싶어서 저희가 얘기하는 Transformer라든지, 아니면 오늘 진원 CTO님이 가르쳐 주신 inference token economics라든지, 이런 것들에 대해 좀 더 깊게 배우고 이해하고 싶다는 그런 수요자분들이 있으세요. 그래서 그런 수요자분들이 얼마나 되는지 알 수가 없고, 단 몇 분을 위해서 제가 그런 이벤트를 만들 수는 없어서 오늘 여기까지 들으신 분들 중에 ‘나는 좀 더 깊게 이런 것들을 공부해 보고 싶다’는 그런 분들이 계시면 댓글로 의사 표현을 해 주시면 감사드리겠습니다. 그러면 또 깊이 감사드립니다.
이진원 잘 들어 주셔서 감사합니다.
박종현 너무 잘 들었습니다.
노정석 그럼 오늘은 여기에서 마무리하도록 하겠습니다. 감사합니다.
이진원 네, 감사합니다.