일본 시간 6월 1일에 시작된 NVIDIA GTC Taipei 2026 기조연설에서, 로컬 실행을 전제로 한 하드웨어가 두 가지 발표되었다. 노트북용 SoC인 「RTX Spark」와 Windows 데스크톱 기기인 「DGX Station」이다.

• RTX Spark: 1 Petaflops의 Blackwell GPU + 20코어의 Grace CPU (Arm 기반), 128GB의 유니파이드 메모리 (Unified Memory). 탑재 노트북은 2026년 가을.
• DGX Station: Blackwell Ultra (GB300) + 72코어의 Grace CPU, 메모리 최대 748GB, FP4에서 20 Petaflops, 최대 1조 개의 파라미터 모델 실행 가능. 2026년 4분기.

뉴스에서는 「드디어 내 손안에서 대형 모델이 돌아간다」라는 성능 이야기로 다뤄지기 쉽다. 하지만 구현하는 입장에서 읽어보면, 여기서 정말로 효과를 발휘하는 것은 FLOPS가 아니라 메모리 쪽이라고 생각한다. 128GB나 748GB라는 숫자가 주인공이며, Petaflops는 조연처럼 보인다.

왜 그렇게 말할 수 있는가. 이전에 「LLM 추론은 왜 막히는가」라는 기사에서 메모리 병목 (Memory Bound) 이야기를 썼는데, 이번 두 제품은 바로 그 제약을 정면으로 해소하러 온 제품이라고 느꼈다. 이번에는 그 후속편으로서, 이 발표를 「추론의 물리 (Physics of Inference)」 관점에서 다시 읽어보고자 한다.

우선, LLM 추론은 왜 메모리 병목인가

추론에는 prefill (프롬프트를 한꺼번에 읽어들이는 단계)과 decode (1 토큰씩 내뱉는 단계)가 있으며, 그 성질이 완전히 다르다. 체감 속도를 지배하는 것은 decode 쪽이다.

decode의 까다로운 점은, 1 토큰을 생성할 때마다 모델의 모든 파라미터를 메모리에서 읽어내야 한다는 점에 있다. 70B 모델이라면, 토큰 1개를 내뱉기 위해 수십 GB 분량의 가중치 (Weights)를 매번 스트리밍해야 한다. 반면 1 토큰당 필요한 연산량은 그 가중치를 한 번씩 곱하기만 하면 되므로 상대적으로 매우 적다.

이 「읽어오는 바이트 수에 비해 계산량이 적은」 상태를 산술 강도 (Arithmetic Intensity)가 낮다고 한다. decode의 산술 강도는 대략 1~2 FLOP/byte 정도밖에 되지 않는다. 즉, GPU의 연산기가 아무리 빨라도 메모리에서 데이터가 도착하기를 기다리는 시간이 더 길다. 1 Petaflops의 연산 성능은 decode의 대부분의 시간 동안 놀고 있는 셈이다.

따라서 실효적인 생성 속도는 대략 다음과 같이 근사할 수 있다.

tok/s ≒ 메모리 대역폭 (Memory Bandwidth, byte/s) ÷ 1 토큰 생성 시 읽어야 하는 모델의 바이트 수

이것이 이 기사의 출발점이다. 추론의 병목은 FLOPS가 아니라 메모리 대역폭 (GB/s)이며, 그다음으로 중요한 것이 메모리 용량 (GB)이라는 순서다.

용량이 효과적인 이유 (1): 가중치가 올라가는가

먼저 용량 이야기다. 모델의 가중치가 메모리에 올라가지 않는다면, 애초에 쾌적한 추론은 시작되지 않는다. 디스크나 CPU 메모리로 넘쳐나는 순간 tok/s는 자릿수 단위로 떨어진다.

가중치의 메모리 사용량은 단순하게 「파라미터 수 × 1 파라미터당 바이트 수」로 결정된다. 양자화 (Quantization) 정밀도에 따른 필요량을 나열하면 다음과 같다.

모델 규모	FP16 (2byte)	INT8 (1byte)	4bit (0.5byte)
70B	약 140GB	약 70GB	약 35GB
...
이 표를 바탕으로 하면 발표된 숫자의 의미가 명확해진다.

DGX Station의 748GB는, 1조 개의 파라미터를 4bit 양자화했을 때의 약 500GB에, 후술할 KV 캐시 (KV Cache)와 작업 영역을 더해도 충분히 수용할 수 있는 용량이다. 「최대 1조 파라미터 실행 가능」이라는 공칭은, 20 Petaflops의 FP4 성능보다도, 우선 748GB라는 용량이 있어야 비로소 성립한다.

128GB의 RTX Spark도 같은 방식으로 해석할 수 있다. 70B를 4bit로 올리면 35GB이므로 여유가 있다. 120B라도 4bit라면 60GB 안에 들어온다. 클라우드의 H100이 1장당 80GB라는 점을 생각하면, 노트북 한 대로 그 정도 규모를 감당할 수 있다는 것은 연산 성능이 아니라 용량의 진보다.

용량이 효과적인 이유 (2): 가중치보다 오히려 KV 캐시

여기서부터가 이번에 가장 전달하고 싶은 핵심이다. 128GB나 748GB라는 용량은 사실 가중치 때문이라기보다, KV 캐시를 위해 효과를 발휘한다.

KV 캐시는 이미 생성한 토큰의 Key/Value를 저장해 두는 영역이다. 이것이 없으면 매 토큰마다 전체 문장을 재계산해야 하므로, 장문 생성에서는 필수적이다. 문제는 그 크기인데, 대략 다음과 같이 쓸 수 있다.

KV 캐시 = 2 × 계층 수 × KV 헤드 수 × 헤드 차원 × 토큰 수 × 배치 크기 × 바이트 수

70B급 모델에서 GQA(KV 헤드 8)・FP16을 가정하여 계산해 보겠습니다. 1토큰당 KV는 2 × 80계층 × 8 × 128 × 2바이트 ≈ 0.3MB입니다.

여기에 문맥 길이를 곱하면, 32k 토큰으로 1요청당 약 10GB가 됩니다. 동시에 8개 요청을 처리하려면, KV 캐시만으로 약 80GB가 필요합니다.

가중치(weight)가 35GB(4bit의 70B)라고 가정하면, KV는 그 두 배 이상을 차지하게 됩니다. 게다가 이 KV는 가중치와 별도로, 생성이 끝날 때까지 계속 메모리를 점유하고 있습니다.

즉, 메모리 용량을 결정하는 것은 단순히 '얼마나 큰 모델을 올릴 수 있는가'에만 국한되지 않습니다. '얼마나 긴 문맥을, 몇 개를 병렬로 처리할 수 있는가'라는 동시 실행 성능 그 자체입니다. 128GB라는 숫자는 70B 모델을 올린 상태에서 장문 및 다중 배치 처리를 위한 여유 공간으로 해석하는 것이 정확하다고 생각합니다.

용량만 있어도, 대역폭이 없으면 빠르지 않다

여기서 첫 번째 공식으로 돌아가 보겠습니다. 용량은 어디까지 '올릴 수 있는가'의 문제이고, '빠른가'를 결정하는 것은 대역폭입니다.

tok/s ≈ 대역폭 ÷ 모델 크기

따라서 예를 들어 4bit화된 70B(약 35GB)를 가상의 대역폭 1TB/s 메모리로 구동하면, 이론적 상한은 약 1000 ÷ 35 ≈ 28 tok/s입니다. 이는 오직 대역폭만으로 계산한 상한이며, 실제는 더 낮습니다. 대역폭이 두 배가 되면 상한도 두 배가 된다는 비례 관계가 핵심입니다.

주의할 점은 RTX Spark와 DGX Station 모두 이번 발표에서 메모리 대역폭의 구체적인 수치가 명시되지 않았다는 것입니다. 여기는 추측이지만, 유니파이드 메모리(LPDDR 계열)와 HBM에서는 대역폭이 한 자릿수 차이가 날 때가 있습니다. 같은 '128GB 탑재'라도, 유니파이드 메모리 기기와 HBM 기기에서는 tok/s 체감이 완전히 다를 것이므로, 선택할 때 정말 봐야 할 것은 GB/s 쪽이라고 생각합니다. 용량은 '작동 여부'를, 대역폭은 '쓸모 있는지 여부'를 결정합니다.

구현 측면의 방안

메모리가 병목 현상(bottleneck)임을 알게 되면, 로컬 추론에서 할 수 있는 것은 자연스럽게 좁혀집니다. 읽는 바이트 수를 줄이거나, 불필요한 읽기를 줄이는 둘 중 하나입니다.

• 가중치 양자화: 4bit(GPTQ/AWQ 계열)로 읽는 바이트 수를 1/4로 줄입니다. tok/s에 거의 그대로 영향을 미치는 가장 직관적인 방법입니다.
• KV 캐시 양자화: KV를 INT8이나 4bit로 낮춥니다. 장문 및 다중 배치에서 메모리가 먼저 고갈되는 경우에 효과적입니다.
• 연속 배치 처리(continuous batching)와 PagedAttention: KV를 조각내지 않고 채워, 같은 용량으로 더 많은 병렬 요청을 통과시킵니다. vLLM 계열이 구현하고 있는 방식입니다.
• speculative decoding: 작은 드래프트 모델로 미리 읽어보고, 큰 모델에서 한 번에 검증합니다. 1회 가중치 읽기로 여러 토큰을 진행할 수 있어, 대역폭당 효율이 높아집니다.
• MoE(Mixture of Experts): 전체 파라미터 중 실제로 읽는 것은 active한 일부만입니다. 총 용량은 필요하지만, 1토큰으로 읽는 바이트 수를 줄일 수 있습니다. 용량은 충분하지만 대역폭이 아쉬운 로컬 기기와 궁합이 좋습니다.

이 모든 것이 'FLOPS를 더하는' 이야기가 아니라 '메모리 사용 방식을 바꾸는' 이야기라는 점이, 메모리 병목이라는 전제에서 납득이 됩니다.

전망

마지막으로, 앞으로 어떻게 흘러갈지 두 가지 예측을 해보겠습니다.

첫째. 로컬 AI의 스펙 선정 축이 FLOPS에서 GB(용량)와 GB/s(대역폭)로 이동할 것입니다. 지금까지는 '몇 TFLOPS가 나오는지'로 액셀러레이터를 이야기해 왔지만, 추론 중심 시대에는 '몇 GB가 탑재되고, 몇 GB/s로 읽을 수 있는지'가 체감을 설명합니다. RTX Spark와 DGX Station이 용량 숫자를 전면에 내세운 것은 그 전환의 발현이라고 생각합니다.

둘째. 다음 경쟁 축은 유니파이드 메모리의 대역폭이 될 것입니다. 용량은 LPDDR을 탑재하면 늘릴 수 있지만, 그것만으로는 tok/s가 늘지 않습니다. 용량을 확보한 상태에서 대역폭을 어디까지 끌어올릴 수 있는지가 로컬 추론기의 우열을 가를 것입니다. 반대로 말하면, 용량 숫자만 보고 구매했다가는 '탑재는 되지만 느린' 제품에 당할 수 있습니다.

로컬에서 LLM을 구동하는 설계를 한다면, 먼저 '탑재 가능한가(용량)'를 확인하고, 다음으로 '읽을 수 있는가(대역폭)'로 속도를 추정해야 합니다. 이번 두 제품은 그 두 가지 제약을 하드웨어 측면에서 확장해 온 제품이라고 읽는 것이 구현에 가장 도움이 되는 시각이라고 생각합니다.

Sources

• 드디어 NVIDIA가 노트북용 SoC 「NVIDIA RTX Spark」를 발표(GIGAZINE): https://gigazine.net/news/20260601-nvidia-rtx-spark/
• NVIDIA가 GB300을 내장한 괴물급 Windows 데스크톱 PC 「DGX Station」을 발표(GIGAZINE): https://gigazine.net/news/20260601-nvidia-dgx-station/
• 본인의 글 LLM 추론은 왜 막히는가: 메모리 병목 (Memory Bound)과 KV 캐시 (KV Cache)를 구현 관점에서: https://zenn.dev/hironakamura_ai/articles/46598fcac2bcce

Discussion