LLM 추론 토큰 가격의 비밀 : MoE의 시대, 엔비디아 NVL72가 중요한 이유

LLM을 서비스하는 단계에 들어오면 가장 중요한 변수가 있습니다. 한 번에 몇 개의 요청을 묶어서 처리하느냐입니다. 이것을 batch size라고 부릅니다. ​ AI 모델은 요청을 두 가지 방식으로 처리할 수 있습니다. 방식 A. 한 사람의 질문이 들어오면 바로 그것만 처리한다. 방식 B. 비슷한 시점에 들어온 여러 요청을 일정 단위로 묶어서 한꺼번에 처리한다. ​ 이때 한 번에 묶어서 처리하는 요청의 개수가 batch size입니다. ​ 비유하자면 택시와 버스의 차이입니다. 한 명만 태우고 바로 출발하는 택시가 batch size 1이라면, 50명이 모이면 출발하는 버스는 batch size 50입니다. 어느 쪽이 좋은가는 상황에 따라 다릅니다. 이 설정값이 AI 서비스의 두 가지 요소를 결정합니다. ​ 지연시간(latency) : 사용자가 답변을 받기까지 걸리는 시간

토큰당 추론 비용 : 모델이 토큰 하나를 생성하는 데 드는 비용 ​ batch size 설정 #1 - 작으면, 빠르지만 비싸진다 batch size가 작다는 것은 사용자의 요청을 거의 즉시 처리한다는 뜻입니다. 사용자 입장에서는 매우 빠르게 응답을 받는다는 뜻이며 이를 바꿔서 설명하면 'latency가 낮다'입니다. 하지만 GPU는 비효율이 커집니다. ​ 왜 그런가 하면, Transformer 아키텍처의 LLM은 토큰 하나를 생성할 때마다 모델 전체의 가중치를 메모리에서 전부 읽어와야 하기 때문에(model weight fetch) 그렇습니다. batch size가 1이라고 하면 거대한 백과사전을 매 단어를 쓸 때마다 처음부터 다시 펼쳐보고 닫고 하는 식입니다. 그러면 이 무거운 백과사전을 펼치는 데 드는 비용 전체를 한 사람의 요청 하나가 떠안습니다. ​ batch size 설정 #2 - 크면, 저렴해지지만 느려진다

batch size를 키우면 여러 사용자의 요청을 한 번에 묶어서 처리한다는 의미입니다. 같은 가중치를 한 번 읽어서 여러 요청에 동시에 적용할 수 있으니 토큰당 비용이 크게 낮아집니다. 한 번 백과사전을 펼친 다음에 거기서 읽은 내용을 바탕으로 100명에게 동시에 답하는 것과도 같습니다. ​ batch size 1이면 모델 가중치를 읽는 비용을 1명이 부담하는 것이고, batch size 100이면 모델 가중치를 읽는 비용을 100명이 나눠 부담하는 것입니다. ​ 그러나 여기서 생기는 병목도 있습니다: ​ 총 연산량이 늘어납니다. batch size가 늘면 메모리를 불러오는 건 줄지만 GPU가 해야 할 계산이 늡니다. KV cache가 더 많이 필요해집니다. KV cache는 각 사용자들의 컨텍스트를 담은 것인데, 동시에 처리한 요청이 많을수록 KV cache가 매우 크게 필요합니다.

latency를 희생합니다. 요청을 어느 정도 이상 모아야 처리할 수 있으니, 먼저 도착한 사용자는 다른 요청이 올 때까지 기다려야 합니다. ​ 추론 시간은 두 가지로 쪼갤 수 있다: ⓐmemory fetch ⓑcompute 위의 내용까지가 batch size의 기본이고, 더 들어가봅니다. ​ LLM의 추론 시간은 두 가지로 단순화할 수 있습니다. ​ Memory fetch : 토큰을 생성하려면 GPU가 메모리에서 모델 가중치와 KV cache를 읽어와야 합니다. Compute time : GPU가 실제로 행렬곱 연산을 수행하는 데 걸리는 시간입니다. 모델의 활성 파라미터 수가 많고 batch size가 커질수록 필요한 연산량도 증가합니다. ​ 결과적으로 추론 시 latency의 하한은 ①과 ②중 더 오래 걸리는 시간에 의해 결정됩니다. 메모리에서 데이터를 빨리 가져오지 못하면 연산을 하려고 해도 데이터가 느리니 데이터 속도에 제한될 것이고, 연산이 충분히 빠르지 못하면 데이터는 도착해있는데 토큰 생성까지 필요한 연산 성능이 충분히 안나와주니 연산이 병목이 됩니다.

​ 이건 모델/워크로드 관점이라면, 하드웨어 관점에서 보면: ​ 얼마나 시간당 많은 계산을 할 수 있는가 → peak FLOPS 메모리에서 얼마나 빨리 데이터를 가져올 수 있는가 → memory bandwidth가 있고, ​ 작업의 성격에 따라서, ​ 계산량이 많아서 FLOPS가 부족하면 → compute-bound 데이터를 읽는 시간이 더 오래 걸리면 → memory-bound입니다. ​ 모델 내부의 메모리는 두 가지로 나뉜다: ⓐWeights ⓑKV Cache 아예 깊게 내려가는 게 이번 자료의 핵심이니, 더 밑으로 들어가봅니다. LLM을 서빙함에 있어서 메모리를 필요로 하는 건 두 가지입니다. ​ 모델 가중치(Model weights) : LLM은 본질적으로 거대한 가중치 덩어리입니다. 다음 토큰을 예측할 때마다 이 가중치를 통과하면서 계산이 일어납니다.

모델이 클수록 매번 읽어야 하는 가중치도 큽니다. KV cache : LLM은 이전에 입력된 문장과 지금까지 생성한 토큰들을 참고해서 다음 토큰을 만듭니다. 이때 과거 토큰들의 key와 value 정보를 저장해두는 공간이 KV cache입니다. 연산을 그때그때 하지 않아도 되게끔 보관해주는 것입니다. ​ KV cache는 두 가지 상황에서 빠르게 커집니다. 컨텍스트 윈도우가 길어질수록(incl. Chain-of-Thought용 토큰) → 한 사용자의 KV cache가 커집니다. 동시에 처리하는 사용자가 많아질수록(batch size 키울수록) → 전체 KV cache가 커집니다. ​ Compute time은 batch size에 비례하여 증가한다 transformer 구조가 토큰을 생성할 때 핵심 연산은 각 레이어마다 가중치 행렬을 곱하는 것입니다. 이걸 batch에 있는 모든 요청에 대해서 수행하는데, 식으로 바꾸면 이렇습니다.

Compute 시간 ≈ (batch size X 활성 파라미터 수) ÷ 하드웨어 연산 처리량 batch size : 동시에 요청하는 수 활성 파라미터 수 : 실제 연산에 쓰이는 파라미터 수 (MoE라고 하면 total이 아닌 active가 기준) 하드웨어의 throughput : GPU 노드의 컴퓨팅 총량 ​ 그렇기에 batch size를 키우면 총 연산량은 늘어납니다. 하나의 요청으로 놓고 보자면 latency가 길어지는 이유이기도 합니다. 반면, batch size를 키울 때의 이점은 위에 전해드린 것처럼 모델 가중치를 불러오는 비용을 batch size의 크기만큼으로 나눠서 부담할 수 있기 때문에 좋습니다. ​ batch size가 작으면, latency는 낮으니 빨리 응답받아 좋은데 토큰당 비용은 비쌉니다. batch size가 크면, 토큰당 비용은 싼데 latency는 높으니 늦게 응답받아서 사용자 경험을 희생합니다.

그렇기에 좋은 시스템은 UX를 너무 해치지 않는 선까지 batch size를 효율적으로 키우는 것입니다. ​ batch size가 작으면, 모델 가중치를 가져와서 나눌 요청이 없으니 모델 가중치 영향을 많이 받습니다. batch size가 크면, KV cache는 컨텍스트 윈도우의 영향을 받기에 KV cache 영향을 많이 받습니다. ​ 사용자가 긴 문서를 넣거나, 에이전트가 긴 작업 이력을 계속 들고 가면 KV cache가 커집니다. 이 KV cache는 사용자의 이전 토큰 정보를 담고 있기 때문에 다음 토큰을 생성할 때 계속 읽어야 합니다. 컨텍스트 윈도우를 키우면 키울수록 KV cache를 가져오는 시간(KV fetch time)이 계속 증가하고, 어느 정도 이상으로 컨텍스트 윈도우를 키우기 시작하면 시스템이 연산에 의해 제약을 받는 게 아니라 메모리에 의해 제약을 받는 구조가 됩니다.

latency를 희생합니다. 요청을 어느 정도 이상 모아야 처리할 수 있으니, 먼저 도착한 사용자는 다른 요청이 올 때까지 기다려야 합니다. ​ 추론 시간은 두 가지로 쪼갤 수 있다: ⓐmemory fetch ⓑcompute 위의 내용까지가 batch size의 기본이고, 더 들어가봅니다. ​ LLM의 추론 시간은 두 가지로 단순화할 수 있습니다. ​ Memory fetch : 토큰을 생성하려면 GPU가 메모리에서 모델 가중치와 KV cache를 읽어와야 합니다. Compute time : GPU가 실제로 행렬곱 연산을 수행하는 데 걸리는 시간입니다. 모델의 활성 파라미터 수가 많고 batch size가 커질수록 필요한 연산량도 증가합니다. ​ 결과적으로 추론 시 latency의 하한은 ①과 ②중 더 오래 걸리는 시간에 의해 결정됩니다. 메모리에서 데이터를 빨리 가져오지 못하면 연산을 하려고 해도 데이터가 느리니 데이터 속도에 제한될 것이고, 연산이 충분히 빠르지 못하면 데이터는 도착해있는데 토큰 생성까지 필요한 연산 성능이 충분히 안나와주니 연산이 병목이 됩니다.

​ 이건 모델/워크로드 관점이라면, 하드웨어 관점에서 보면: ​ 얼마나 시간당 많은 계산을 할 수 있는가 → peak FLOPS 메모리에서 얼마나 빨리 데이터를 가져올 수 있는가 → memory bandwidth가 있고, ​ 작업의 성격에 따라서, ​ 계산량이 많아서 FLOPS가 부족하면 → compute-bound 데이터를 읽는 시간이 더 오래 걸리면 → memory-bound입니다. ​ 모델 내부의 메모리는 두 가지로 나뉜다: ⓐWeights ⓑKV Cache 아예 깊게 내려가는 게 이번 자료의 핵심이니, 더 밑으로 들어가봅니다. LLM을 서빙함에 있어서 메모리를 필요로 하는 건 두 가지입니다. ​ 모델 가중치(Model weights) : LLM은 본질적으로 거대한 가중치 덩어리입니다. 다음 토큰을 예측할 때마다 이 가중치를 통과하면서 계산이 일어납니다.

모델이 클수록 매번 읽어야 하는 가중치도 큽니다. KV cache : LLM은 이전에 입력된 문장과 지금까지 생성한 토큰들을 참고해서 다음 토큰을 만듭니다. 이때 과거 토큰들의 key와 value 정보를 저장해두는 공간이 KV cache입니다. 연산을 그때그때 하지 않아도 되게끔 보관해주는 것입니다. ​ KV cache는 두 가지 상황에서 빠르게 커집니다. 컨텍스트 윈도우가 길어질수록(incl. Chain-of-Thought용 토큰) → 한 사용자의 KV cache가 커집니다. 동시에 처리하는 사용자가 많아질수록(batch size 키울수록) → 전체 KV cache가 커집니다. ​ Compute time은 batch size에 비례하여 증가한다 transformer 구조가 토큰을 생성할 때 핵심 연산은 각 레이어마다 가중치 행렬을 곱하는 것입니다. 이걸 batch에 있는 모든 요청에 대해서 수행하는데, 식으로 바꾸면 이렇습니다.

Compute 시간 ≈ (batch size X 활성 파라미터 수) ÷ 하드웨어 연산 처리량 batch size : 동시에 요청하는 수 활성 파라미터 수 : 실제 연산에 쓰이는 파라미터 수 (MoE라고 하면 total이 아닌 active가 기준) 하드웨어의 throughput : GPU 노드의 컴퓨팅 총량 ​ 그렇기에 batch size를 키우면 총 연산량은 늘어납니다. 하나의 요청으로 놓고 보자면 latency가 길어지는 이유이기도 합니다. 반면, batch size를 키울 때의 이점은 위에 전해드린 것처럼 모델 가중치를 불러오는 비용을 batch size의 크기만큼으로 나눠서 부담할 수 있기 때문에 좋습니다. ​ batch size가 작으면, latency는 낮으니 빨리 응답받아 좋은데 토큰당 비용은 비쌉니다. batch size가 크면, 토큰당 비용은 싼데 latency는 높으니 늦게 응답받아서 사용자 경험을 희생합니다.

그렇기에 좋은 시스템은 UX를 너무 해치지 않는 선까지 batch size를 효율적으로 키우는 것입니다. ​ batch size가 작으면, 모델 가중치를 가져와서 나눌 요청이 없으니 모델 가중치 영향을 많이 받습니다. batch size가 크면, KV cache는 컨텍스트 윈도우의 영향을 받기에 KV cache 영향을 많이 받습니다. ​ 사용자가 긴 문서를 넣거나, 에이전트가 긴 작업 이력을 계속 들고 가면 KV cache가 커집니다. 이 KV cache는 사용자의 이전 토큰 정보를 담고 있기 때문에 다음 토큰을 생성할 때 계속 읽어야 합니다. 컨텍스트 윈도우를 키우면 키울수록 KV cache를 가져오는 시간(KV fetch time)이 계속 증가하고, 어느 정도 이상으로 컨텍스트 윈도우를 키우기 시작하면 시스템이 연산에 의해 제약을 받는 게 아니라 메모리에 의해 제약을 받는 구조가 됩니다.

MoE란 무엇인가 More sparsity you have, less compute you need ​ 시작하기 전에... 앞선 내용은 batch size가 AI 추론 비용을 결정하는 데 핵심 요소라는 것을 정리했습니다. 결론은 두 가지입니다. ​ LLM decode는 대부분 memory-bound이고, batch size를 키워야 weights fetch 비용을 여러 요청에 분산시켜서 훨씬 값싸게 동시에 여러 사용자에게 서빙할 수 있다. batch size를 충분히 키우면 어느 순간부터는 compute가 병목이 된다. ​ 그렇다면, batch size가 커져서 compute가 병목이 되면 어떻게 해결하는가를 정리할 때 가장 중요한 변수가 sparsity(희소성)입니다. 그리고 그 sparsity를 실제로 구현하는 가장 대표적인 방식이 MoE(Mixture of Experts)입니다.

​ Sparsity란? : Total Parameter vs Active Parameter 전체 파라미터 수 (Total Parameter) : 모델이 갖고 있는 모든 가중치의 개수 활성 파라미터 수 (Active Parameter) : 한 번의 토큰 생성에서 실제 연산에 참여하는 가중치의 개수 ​ Mixtuer of Experts : 전문가 라우팅이란 발상 MoE 모델은 하나의 토큰을 생성할 때 Dense 모델처럼 전체의 파라미터를 모두 활성화하는 것이 아니라, 토큰마다 관련이 높은 일부 전문가(experts)만 활성화하는 모델입니다. 전체 모델 크기는 크지만 실제로 계산해야 하는 활성 파라미터의 수는 드라마틱하게 줄일 수 있습니다. ​ MoE 아이디어 자체는 단순합니다. 모델 안에 여러 개의 전문가를 두고, 입력 토큰마다 그중 일부만 골라서 쓰는 것입니다.

예를 들어서, 전체 전문가가 256개이고 매 토큰마다 그중 32개의 전문가만 사용하는 모델이 있다고 쳐봅니다. 그러면 매 토큰이 들어올 때마다 라우터가 토큰마다 32개의 전문가만 생성에 참여시키고 나머지 224개의 전문가는 토큰 생성에 참여하지 않습니다. ​ 모든 AI Labs는 시간이 갈수록 더 모델을 sparse하게 만들고 있습니다: ​ 예를 들어서, 2024년 12월 27일에 출시된 DeepSeek-V3는 전체 파라미터는 671B인데 활성 파라미터는 37B이고, 전문가 수는 공유 전문가가 1개 + 라우팅에 참여하는 전문가가 256개로 총 257개이며 토큰당은 공유 전문가 1개 + 라우팅 전문가 8개가 활성화돼서 답변하는 구조였습니다. 2026년 4월 24일에 출시된 DeepSeek-V4-Pro 모델은 전체 파라미터는 1.6T인데 활성 파라미터는 49B입니다. 약 3% 정도만 활성화하는 것이자 마치 1.6T 거대모델에 준하는 지능의 토큰을 출력하지만 실제 추론 비용은 49B급 소형모델 추론에 드는 비용 정도만 부담합니다.

​ 얼마나 더 적게 활성 파라미터로 쓰느냐에 따라서 더 희소한(sparse) 모델이라고 부릅니다. ​ Sparsity는 왜 compute를 아낄 수 있는가? 앞의 Compute 시간 공식을 다시 가져오자면, Compute 시간 ≈ (batch size X 활성 파라미터 수) ÷ 하드웨어 연산 처리량 여기서의 핵심은 Compute 시간이 전체 파라미터가 아닌 활성 파라미터 수에 비례한다는 것입니다. 즉, batch size를 키워서 weight fetch를 더 많이 분산하여 토큰당 추론비용을 크게 낮출 수 있다면 반작용으로 연산이 상당히 많이 필요한 게 병목이 되는데 → 이것을 해소해주는 것이 활성 파라미터의 수를 드라마틱하게 줄이는 것이고, 모델을 더 sparse하게 만드는 일입니다. ​ 토큰의 품질이 떨어지는 것은, 경험적으로 확인해야 한다 활성 파라미터를 줄이면 compute 총량은 줄어드는데, 만약 모델 품질이 그 이상으로 망가진다면 그것도 문제입니다.

근데 이건 공식은 없고 실험을 통해서만 경험적으로 확인할 수 있는 부분인지라 수많은 실험을 통해서 AI Labs들이 다양한 버전별로 체크포인트 모델을 만들고 토큰당 지능을 비교해보는 수밖에 없습니다. ​ 다만, 여기에도 경험적으로 통용되는 법칙이 하나 있습니다. <Unified Scaling Laws for Routed Language Models, 2022>입니다. 논문의 가정은 활성 파라미터 수를 고정하고 전문가의 수만 계속 늘리면 모델 품질은 어떻게 변하는가?였고 → 그 결과를 한 문장으로 요약하면 '활성 파라미터를 그대로 두고 전문가의 수를 늘리면 품질은 계속해서 좋아진다'였습니다. ​ 예시로 나온 건, ​ Dense 모델 - 전체 및 활성 파라미터 1.3B (Dense는 하나를 통째로 돌리는 것) MoE 모델 - 활성 파라미터 370M / 전문가 64개 (=전체 파라미터는 23.7B)입니다.

​ 이 둘의 품질이 비슷하게 나옵니다. 그러면 활성 파라미터는 4분의 1 크기이니 다른 변수들이 같다고 볼 때 연산은 4분의 1만 하는데 토큰의 지능 수준은 같게 나온 것입니다. ​ 다만, 여기서 생각해봐야 할 것은 ⓐ활성 파라미터는 1.3B에 비해서 370M이니 4분의 1로 줄었지만 ⓑ전체 파라미터의 규모는 1.3B와 23.7B를 비교해야 하니 18배 이상 증가했다는 것입니다. 컴퓨팅을 4배 줄이는 대가​로 전체 파라미터는 18배 늘린 것입니다. ​ 결과적으로 batch size를 키울 수 있냐가 중요하다 그렇다면 이 조합은 좋은 Trade-off냐 아니냐를 구분해야 할텐데, 추론 비용 관점에서 보자면 사용자만 많다면 거의 일방적인 이득입니다. sparse를 키울 때의 단점은 전체 파라미터의 규모가 수십배 커진다는 것이지만, batch size를 충분히 키울수만 있다면 이건 아까 말씀드린 것처럼 weight fetch를 N분의 1로 나눠버리면 되기 때문에 금방 극복할 수 있기 때문입니다.

​ 결과적으로 보자면 모델을 더 sparse하게 만드는 것과 사용자를 더 많이 모아서 충분히 높은 batch size에서 서빙할 수 있는 것은 같은 방향의 최적화입니다. ​ 규모의 경제 효과가 있다 투자 관점에서는 엄청나게 많은 사용자에게 서비스할 수 있는 플랫폼일수록 규모의 경제를 얻는 효과가 생기는 것과도 같습니다. 사용자가 적은 서비스는 batch size를 충분히 크게 만들기 어렵고, 그러면 늘어난 weight fetch 비용을 충분히 나눌 수 없기 때문입니다. 전 세계적으로 막대한 요청이 들어오는 서비스들만 batch size를 크게 유지해서 더 추론비용을 낮게 서비스할 수 있습니다. ​ 하지만 이는 더 많은 메모리를 필요로 한다 sparse 모델은 필요한 연산력은 충분히 줄일 수 있지만 또 다른 종류의 비용을 높입니다. ​ 더 많은 메모리 용량을 필요로 합니다.

예를 들어서 전문가가 64개라면 그 64개를 다 GPU에 얹어야 합니다. 토큰당 4개씩만 라우팅해서 답한다고 하더라도 들어오는 토큰당 어느 전문가가 활성화될지 모르니 모두 메모리에 올려놓아야 합니다. 그리고 sparse를 통한 이득을 보려면 batch size도 같이 키워야 weights fetch 비용을 분산할 수 있다고 전해드렸었는데, batch size가 커지면 KV cache도 같이 커집니다. ​ 정리하면, 이렇습니다. ​ compute를 아끼고 싶다 → sparsity를 늘린다(= 더 많은 experts를 추가한다) → 늘어난 weight fetch 비용을 낮추려면 batch size를 키워야 한다 → 그러면 KV cache도 같이 증가한다 → 이를 상쇄하려면 메모리 용량이 더 많이 필요하다. ​ 추론에서 HBM 용량이 중요한 이유이기도 하고, 세대를 거듭할 때마다 HBM 용량과 대역폭이 함께 증가하는 이유입니다.

얼마나 많은 전체 파라미터와 KV cache까지를 메모리에 올려둘 수 있느냐가 어디까지 sparsity를 밀어붙여서 compute 비용을 아낄 것인가로 수렴하기 때문입니다. 엔비디아의 NVL72가 중요한 이유 MoE 모델은 실제 GPU에 어떻게 올라가는가? ​ MoE 모델을 서빙하기 위한 하드웨어적 특징 이제는 MoE 모델을 GPU 위에 어떻게 올릴 것인가를 정리해봅니다. 이게 단순하지 않은 이유는 MoE 모델을 어떻게 GPU 위에 올릴 수 있느냐가 Sparsity를 어디까지 밀어붙일 수 있느냐의 물리적인 한계를 결정하기 때문입니다. 결론부터 미리 정리드리면, 아래 설명드릴 내용이 엔비디아의 NVLink(NVLink Fusion) 등 Switched Scale-up Network가 MoE 모델의 추론에 가장 적합한 이유에 대해서 자세히 정리하는 것이기도 합니다.

근데 이건 공식은 없고 실험을 통해서만 경험적으로 확인할 수 있는 부분인지라 수많은 실험을 통해서 AI Labs들이 다양한 버전별로 체크포인트 모델을 만들고 토큰당 지능을 비교해보는 수밖에 없습니다. ​ 다만, 여기에도 경험적으로 통용되는 법칙이 하나 있습니다. <Unified Scaling Laws for Routed Language Models, 2022>입니다. 논문의 가정은 활성 파라미터 수를 고정하고 전문가의 수만 계속 늘리면 모델 품질은 어떻게 변하는가?였고 → 그 결과를 한 문장으로 요약하면 '활성 파라미터를 그대로 두고 전문가의 수를 늘리면 품질은 계속해서 좋아진다'였습니다. ​ 예시로 나온 건, ​ Dense 모델 - 전체 및 활성 파라미터 1.3B (Dense는 하나를 통째로 돌리는 것) MoE 모델 - 활성 파라미터 370M / 전문가 64개 (=전체 파라미터는 23.7B)입니다.

​ 이 둘의 품질이 비슷하게 나옵니다. 그러면 활성 파라미터는 4분의 1 크기이니 다른 변수들이 같다고 볼 때 연산은 4분의 1만 하는데 토큰의 지능 수준은 같게 나온 것입니다. ​ 다만, 여기서 생각해봐야 할 것은 ⓐ활성 파라미터는 1.3B에 비해서 370M이니 4분의 1로 줄었지만 ⓑ전체 파라미터의 규모는 1.3B와 23.7B를 비교해야 하니 18배 이상 증가했다는 것입니다. 컴퓨팅을 4배 줄이는 대가​로 전체 파라미터는 18배 늘린 것입니다. ​ 결과적으로 batch size를 키울 수 있냐가 중요하다 그렇다면 이 조합은 좋은 Trade-off냐 아니냐를 구분해야 할텐데, 추론 비용 관점에서 보자면 사용자만 많다면 거의 일방적인 이득입니다. sparse를 키울 때의 단점은 전체 파라미터의 규모가 수십배 커진다는 것이지만, batch size를 충분히 키울수만 있다면 이건 아까 말씀드린 것처럼 weight fetch를 N분의 1로 나눠버리면 되기 때문에 금방 극복할 수 있기 때문입니다.

​ *숫자들을 신경쓰시기 보다는, 대략의 라우터 → GPU에 전문가 배치 → 랙스케일 내 GPU-to-GPU 통신 정도의 흐름만 눈으로 익히시면 좋습니다. 설명은 아래에 이어갈 예정입니다. ​ Expert Parallelism : 전문가를 여러 GPU에 나눠담는 것 가장 표준이자 가장 좋은 해법이 Expert Parallelism입니다. 말그대로 서로 다른 전문가를 서로 다른 GPU에 배치하는 것입니다. 예를 들자면, DeepSeek-V3는 256개의 전문가를 갖고 있습니다. 이를 GB200 NVL72에 올린다고 가정합니다. 256개를 72개의 GPU에 나누는 건 딱 떨어지지 않으니 대략 64개 GPU만 쓰고 나머지 8개 노드는 놀려둔다고 가정하면 GPU 1개당 전문가 4개가 들어갑니다. ​ 순서대로 보자면: input 토큰이 들어옵니다.

라우터가(모든 GPU에 복제되어 있음) 각 토큰을 어떤 전문가에 보낼지 결정합니다. 토큰이 해당 전문가가 있는 GPU로 전송됩니다. 각 GPU에서 전문가들의 연산이 수행됩니다. 결과들을 다시 원래의 토큰 위치로 돌려보내서 합산하여 output 토큰을 내보냅니다. ​ 여기서의 핵심은 3번과 5번입니다. ​ 토큰이 GPU와 GPU 사이를 왔다갔다 해야 합니다. 연산은 줄이지만 통신 병목이 크다​는 의미입니다. ​ All-to-All이 중요한 이유 : MoE의 통신 패턴 이 통신은 어떤 패턴으로 일어나느냐를 살펴봅니다. 라우터의 결정은 어떤 데이터가 들어오느냐에 따라 다릅니다. 전체 랙의 GPU가 72개인데 어떤 토큰은 3번 GPU로, 어떤 토큰은 47번 GPU로 향할 수 있습니다. GPU-to-GPU를 오가며 토큰이 흘러다닙니다. 이러한 통신 패턴을 All-to-All이라 부릅니다.

모든 GPU가 모든 다른 GPU와 잠재적으로 상시 통신한다는 의미입니다. 이것이 MoE의 통신 패턴입니다. ​ 이 특이한 패턴 덕분에, MoE 모델의 추론 성능에 매우 중요한 것이 있습니다. GPU 간 통신이 매우 빨라야 한다는 것입니다. 통신이 느리면 sparsity를 열심히 깎아서 compute를 아껴봐야 통신 대기시간 때문에 전체 추론이 느려집니다. 시간당 몇 십~몇 백만 개의 토큰을 생산하느냐가 곧 백만 토큰당 추론 비용을 결정하는 구조이므로, 이것은 곧 토큰 추론비용이 비싸진다는 말과도 같습니다. ​ 그런데, 이 All-to-All 연결을 하려면 하드웨어의 세계를 다시 봐야 합니다. ​ 랙(Rack) 랙의 크기는 대략 2.2m 정도로 결정됩니다. 그 안에 지금의 기술력으로는 GPU 혹은 XPU가 대략 64~72개 탑재되어 있습니다.

그리고 그 옆에 다른 랙들을 쭉 줄지어서 데이터센터를 구성하는 식입니다. ​ 모두가 다르게 설계하지만 랙의 크기가 마치 표준 스펙이 있는 듯이 정해지는 이유는, 물리적인 제약 때문입니다. ​ 전력(Power) : 하나의 랙에 얼마나 많은 전기를 끌어다 쓸 수 있는가 냉각(Cooling) : 그만큼의 열을 어떻게 빼낼 것인가 무게(Weight) : 무너지지 않을 정도의 무게인가 ​ 두 가지 종류의 네트워크: Scale-up, Scale-out GPU 클러스터에는 두 가지 통신 네트워크가 존재합니다. ​ Scale-up 네트워크 : 매우 빠릅니다. 같은 랙 안의 GPU들을 연결하는 네트워크입니다. NVLink, ESUN, UALink, NVLink Fusion 등이 있습니다. Scale-out 네트워크 : 상대적으로는 Scale-up에 비해서 대략 8배 느립니다.

랙을 벗어나서 다른 랙의 GPU와 연결하는 네트워크입니다. ​ MoE 추론 그자체를 위한 엔비디아의 NVLink Scale-up Network 엔비디아의 경우 NVL랙에서 어떤 GPU와 다른 어떤 GPU도 단 2 hop으로 통신할 수 있게 만들었습니다. 자기 자신 GPU → NVSwitch → 목적지 GPU입니다. 이를 통해 엔비디아 랙 구조 자체가 MoE의 all-to-all 통신 패턴에 완벽하게 특화됐습니다. ​ TPU v7에서는 hop이 많이 발생하고, TPU v8i에서 Boardfly + CAE 조합으로 이전에 비해서는 MoE 추론에서 생기는 hop을 극복하려 하지만 기본적으로 all-to-all 연결이 아니기에 hop에서 오는 latency는 생길 수밖에 없습니다. 이에 대해서는 <주간전략보고 : 투자의 생각 (12월 8일~12월 12일)>, <주간전략보고 : 투자의 생각 (4월 27일~5월 1일)>자료에서 전해드렸습니다.

​ ​ 만약, 랙 하나의 범위를 벗어나서 MoE 모델을 Expert Parallelism 해야 한다고 가정해봅니다. 어쩔 수 없이 랙 2개에 걸쳐서 전문가를 배치해야 할 겁니다. 그렇게 되면 통신 패턴상 Scale-out이 큰 병목이 됩니다. ​ 임의의 GPU에서 라우팅된 토큰의 목적지 GPU가 같은 랙 안에 있을 확률은 50%입니다. 다른 랙에 있을 확률도 50%입니다. 그럼 같은 랙 안이라면 Scale-up을 타고 매우 빠르게 이동하지만, 다른 랙이라면 대략 8배 느린 Scale-out을 타고 느리게 도착합니다. 문제는 all-to-all 통신 패턴이기 때문에 전체의 통신 속도는 가장 느린 경로에 의해서 결정됩니다. 절반의 토큰이 느린 길로 가야 하면, 전체 추론이 그 느린 속도에 발목잡히는 셈입니다. ​ 실질적으로 하나의 랙 크기가 실질적으로 MoE 레이어 하나의 최대 크기를 결정한다는 의미입니다.

이게 오늘날 ⓐScale-out의 속도도 이전보다 훨씬 더 높여서 인터커넥트 도메인을 더 크게 만들려는 이유 & ⓑ랙 하나에 더 많은 compute die를 탑재하려는 이유(GB200 NVL72 → VR200 NVL72(패키징당 compute die는 x2라서 예전엔 이걸 NVL144라고 칭했는데 CES 2026에서 '패키징' 기준으로 변경하며 72로 유지) → VR300 NVL144)이기도 합니다. ​ 광학이 주목받는 이유이자 인터커넥트 도메인 관점에 대해서는 광학 Primer인 <'빛💡'의 시대 : 광학 밸류체인 한 눈에 보기>를 참고하시면 도움이 되실 겁니다 ​ Scale-up 자체를 더 키우지 못하는 이유 그럼 Scale-up Network 자체를 더 크게 키우면 되지 않나 싶지만, 여기서 아까 정의드린 '랙'의 한계가 등장합니다.

냉각 : 늘어난 전력만큼의 열을 빼내야 하는 이슈 케이블 밀도 : 커넥터 밀도, 백플레인 밀도, 굽힘 반경 한계 ​ GPT-4 이후 3년의 시간은 어디로 갔을까? 흥미로운 포인트는 GPT-4가 2023년 초에 출시됐고 1T 파라미터를 돌파했는데, 그 후 거의 3년쯤 지나서야 의미 있는 더 큰 모델이 나오기 시작했다는 것입니다. 여기서 병목이었던 포인트는 충분한 큰 Scale-up 도메인이 없었다는 게 병목입니다. 쭉 정리해보면 이렇습니다. ​ 2023년 : Hopper 8-GPU (80GB * 8) → Scale-up 도메인 내 메모리 640GB 2025년 : Blackwell NVL72 (192*72 ~ 288*72) → Scale-up 도메인 내 메모리 13~20TB ​ 1T 파라미터 모델은 weights만 1TB가 필요합니다.

여기에 사용자별 KV cache 및 동시 처리하는 batch까지 얹으면 실제 필요 용량은 훨씬 더 큽니다. Hopper 8-GPU 구조에는 1T 모델조차 함께 올리기 빠듯합니다. 반면 GB200 NVL72는 13TB이니 5T 모델에 더해서 KV cache까지 충분히 얹을 수 있고, GB300 NVL72는 20TB이니 10T 모델까지도 KV cache를 넣어서 서빙할 수 있습니다. ​ 정리하자면 GPT-4 이후의 정체기는 모델 훈련의 이슈라기보다 그걸 서빙하기에 충분한 하드웨어가 없었던 시기입니다. 여기서 흥미로운 건 구글 TPU는 오래전부터 랙들을 Pod으로 연결하는 매우 큰 Scale-up 도메인을 갖고 있었기 때문에 다른 AI Labs들보다 한 단계씩 앞설 수 있었습니다. 이를 가장 잘 보여주는 것이 Gemini 2.5 Pro입니다.

당시 GPT 및 Claude와 비슷한 지능에 훨씬 저렴한 토큰 추론비용을 감당할 수 있었던 이유입니다. ​ Pipeline Parallelism : 하나의 랙에 안 들어가면 Layer를 여러 랙 나눠 담자 그러면 Scale-up 도메인 메모리 용량이 작아서 모델이 랙 하나에 안 들어가면 여러 랙에 나눠 담는 조합을 생각해볼 수 있습니다. 그게 Pipeline Parllelism입니다. 세레브라스 자료에서 한 번 전해드렸던 내용입니다. Layer별로 나눠서 계산 후 데이터만 다음 랙으로 보내는 것입니다. 훈련에서는 이미 Pipelining이 보편화 되어 있으므로 이건 제외하고 추론에서 사용하는 것만 의미합니다. 다만, 일리야 수츠케버가 얘기한 것처럼 사실상 Pipeline Parllelism은 임시방편으로 2024~2025년에 많이 쓰였지만 지금은 큰 의미가 없습니다.

​ 뭔가를 쪼개는 건 크게 세 가지 유형이 많습니다: Tensor Parllelism : 하나의 전문가를 쪼개서 연산 후 합쳐서 서빙하는 것 Expert Parllelism : 전문가를 GPU별로 나눠서 서빙하는 것 Pipeline Parllelism : 모델의 Layer들을 랙마다 나눠서 서빙하는 것 ​ 다만, HBM 용량 기준 H100은 640GB → H200은 1.13TB → GB200 NVL72는 13TB → GB300 NVL72는 20TB → VR200 NVL72는 20TB → VR300 NVL72는 150TB로 흘러감에 따라 랙 하나당 HBM 용량만 하더라도 10TB 수준으로 Scale-up 도메인 메모리 용량이 크게 증가한 이후로는 Pipeline Parllelism은 랙 간을 이동하는 통신이기도 하고 모델 아키텍처상 제약을 만들기에 선호받지 않고, Tensor Parllelism​도 모델을 더 sparse하게 만드는 방법이 더 효율적이기 때문에 하나의 전문가가 이미 작아지니 그걸 더 작게 잘라도 통신이 병목이 되는지라 선호받지 않고 있습니다.

그래서 현실적으로 지금 많이 쓰이는 건 Expert Parllelism으로 하나의 Scale-up 도메인에 하나의 모델을 탑재하는 방식만 주로 쓰이고 있습니다. ​ 메모리 용량은 어떻게 계산하는가? 메모리 용량 = (모델 weights의 크기) + (KV cahce의 크기) 간단한 버전 메모리 용량 = (N_total) + (Batch size x Context length x Bytes/token) 자세한 버전 ​ *N_total = 모델의 전체 파라미터 수 (MoE면 Total parameter) *Batch size x Context length x Bytes/token = 모든 사용자의 KV cache 총합 이 둘이 모두 어딘가에 저장되어 있어야 합니다. 모델은 사용자의 요청을 받기 전에 메모리에 올라가 있어야 하고, KV cache는 매 토큰을 만들 때마다 읽고 써야 합니다.

GPU당 필요 메모리 = [(N_total) + (Batch size x Context length x Bytes/token)] ÷ (E x P) GPU에 나눠서 서빙할 때, 각 GPU당 올라갈 수 있는 메모리의 양 ​ *E = Expert parllelism의 정도 (전문가를 몇 개의 GPU에 나눠 분산했는가) *P = Pipeline parllelism의 정도 (몇 개의 랙에 layer를 나눠 담았는가) 랙을 크게 만드는 이유는, 대역폭을 얻기 위해서이다 다시 정리하자면, Scale-up 도메인이 중요한 이유는 두 가지입니다. ​ 메모리 대역폭 (Memory Bandwidth) : 같은 Scale-up 도메인 내의 모든 GPU는 weights를 병렬로 읽어낼 수 있습니다.

다른 랙의 GPU는 불가능합니다. 그래서 실효 메모리 대역폭은 Scale-up의 가속기 수 x GPU당 대역폭으로 결정됩니다. 그런데, GPU 한 개당 대역폭은 한 세대당 대략 2배씩 늘어나는데 Scale-up의 가속기 수가 Hopper → Blackwell로 오면서 8배 늘었습니다. 이게 대역폭 측면으로 보자면 어마어마한 개선이었습니다. 지연시간 (Latency) : 랙을 넘어가는 hop마다 몇 ms씩 latency가 추가됩니다. decode는 순차적인 작업이므로 latency가 누적됩니다. 한 토큰이 20ms에 만들어진다고 보면, hop 몇 개가 끼면 30ms가 됩니다. 50% 느려지는 것입니다. Scale-up 안에서 all-to-all로 이를 해결할 수 있다면 이러한 hop으로 인한 latency가 모두 사라지는 효과입니다.

​ 여기까지 말씀드린 내용을 정리하면, ​ GPT-4 이후로 3년간 모델의 크기가 생각보다 커지지 않은 이유는 이렇습니다. 모델을 더 크게 훈련시키는 건 가능했습니다. 훈련에서는 당연히 클러스터 규모만 생각하더라도 여러 랙에 걸친 Pipeline이 보편화되어 있기 때문에 여러 랙에 걸쳐서 훈련합니다. 훈련의 제약은 아닙니다. 하지만 훈련시킨 모델을 추론으로 띄우는 게 문제입니다. 추론에서는 사용자가 받는 latency가 중요하고, 그 latency는 Scale-up 도메인 내에서만 패널티 없이 유지됩니다. latency는 곧 토큰당 추론 비용을 결정합니다. Hopper 시절에는 이것이 640GB로 너무 작았습니다. 거대한 모델을 띄우려 하면 여러 랙에 걸쳐야 했고 Pipeline Parllelism이 있지만 그러면 hop이 생기니 랙 간의 통신에서 발생하는 latency가 발목을 잡습니다.

GB200 NVL72이 양산되기 시작한 때가 2025년 3월부터입니다. 도메인이 8-GPU에서 72-GPU로 오다보니 소프트웨어와 네트워킹이 충분히 성숙하기까지 시간이 걸리긴 했는데 그렇게 성숙시키고난 뒤가 2025년 하반기쯤이었습니다. 이때부터는 이제 13TB였기에 5T 모델도 하나의 랙 안에서 서비스할 수 있었습니다. API 비용의 세 가지 요소 API 비용을 역으로 살펴보기 (컨텍스트, 입출력 토큰, Cache hit/miss) ​ LLM API 가격표에는 세 가지가 쓰여있다 GPT-5, Claude 4, Gemini 3의 내부 구조는 모르지만 API 가격표는 공개되어 있습니다. API 가격은 비용에 마진을 붙여서 책정되고, 비용은 물리학을 따릅니다.

즉, 가격표를 거꾸로 읽으면 모델의 구조를 추정할 수 있습니다. ​ 세 가지 단서가 있습니다: Gemini 3.1 Pro 기준 컨텍스트 윈도우가 200K 토큰을 넘기면 가격이 50% 비싸진다 출력 토큰 비용이 입력 토큰보다 5배 비싸다 Cache hit 비용이 그렇지 않은 것보다 10배 더 싸다 ​ 1. 컨텍스트 길이 컨텍스트 길이가 길어지면 memory fetch 시간이 선형적으로 증가하여, 비용이 높아집니다. API 제공자는 이러한 비용 증가분을 반영하여 특정 임계점(e.g. 200K 토큰)을 넘기면 가격을 인상하여 수익성을 확보합니다. ​ 2. 입력과 출력의 가격 차이 입력 토큰은 Prefill입니다.

여러 토큰을 병렬적으로 처리할 수 있으며 병렬로 처리할 수 있는 특징 덕에 토큰당 비용으로 보자면 매우 값싸게 서비스할 수 있습니다. 특히 시퀀스가 크면 메모리 대역폭 사용 효율이 커지니 토큰당 비용은 훨씬 더 드라마틱하게 저렴해집니다. ​ 출력 토큰은 Decode입니다. 한 번에 하나의 토큰씩 순차적으로 생성하니 메모리 대역폭의 제약을 받습니다. 단일 토큰을 생성할 때마다 전체 모델 가중치와 KV cache를 메모리로부터 가져와야 하니 메모리 대역폭이 병목을 일으키는 것입니다. 이 현상을 반영한 가격입니다. ​ 3. 메모리 계층과 cache hit/miss 비용 KV cache를 생성하는 방법은 두 가지입니다.

재연산 : 매번 KV cache를 다시 연산하여 생성하는 방식입니다. GPU 연산 시간을 꽤나 많이 쓰니 비용이 많이 들어갑니다. 메모리에 저장 : 이전에 계산했던 KV cache를 메모리에 저장해두고 필요할 때 다시 불러오는 것입니다. ​ 이 KV cache를 저장하는 메모리 계층을 어디에 둘 것이냐에 따라 용량별 비용과 접근속도가 달라집니다. HBM → DDR → NAND Flash/SSD → HDD입니다. ​ cache hit는 이전에 저장된 KV cache를 재사용하는 경우를 의미하며, cache miss보다 10배 저렴합니다. 이 덕에 AI Labs는 API 가격을 책정할 때부터 cache hit 시 비용을 크게 낮춰서 사용자가 cache를 효율적으로 사용하도록 유도합니다.

​ 그리고 저장 기간에 따른 가격도 차등화합니다. 5분 저장, 1시간 저장 등 시간마다 다른 가격을 책정합니다. SSD에 저장하게 할 것인지, HDD에 저장하게 할 것인지 등등 각각 다른 메모리 계층을 사용하는 것을 시사합니다. Memory Drain Time이라고 구분합니다. 어디에 저장할 것이냐에 따라서 메모리 계층의 데이터를 모두 읽어들이는 데 드는 시간이 차이가 큽니다. HBM의 drain time은 20ms > DDR은 수 초 > Flash/SSD는 1분 > HDD는 1시간 정도입니다. Memory hierarchy를 따라갑니다.