책상 위에 비슷한 가격(약 2천 달러)의 컴퓨터 두 대를 놓아봅니다. 하나는 NVIDIA RTX 5090을 얹은 타워형 PC로, 32GB 메모리에 초당 1,792GB를 처리하는 소비자용 그래픽카드 중 가장 빠른 축입니다. 다른 하나는 문고본 크기의 미니PC, AMD Ryzen AI Max+ 395(코드명 “Strix Halo”)로 128GB 메모리를 갖췄지만 처리 속도는 초당 256GB에 불과합니다.

이 두 대에 700억 개 매개변수를 가진 70B 모델을 돌려보라고 하면 어떻게 될까요.

RTX 5090은 아예 실행조차 못 합니다. 70B 모델을 4비트로 압축해도 40GB가 필요한데, 32GB 메모리에는 들어가지 않기 때문입니다. 반면 작은 미니PC는 군말 없이 모델을 불러오고, 다만 느린 독자가 책 읽듯 답을 내놓습니다. 이 역설 하나가 미니PC라는 카테고리 전체를 설명합니다. 빠른 GPU가 담지 못하는 모델을 미니PC는 담을 수 있고, 그 대가로 속도를 치른다는 것이죠.

출처: Unified Memory, Explained: Why Mini PCs Can Run 70B Models a Big GPU Can’t (and Where They Slow Down) – Vetted Consumer

통합 메모리, VRAM과 시스템 RAM의 경계를 없애다

보통의 데스크톱에서는 CPU가 쓰는 시스템 RAM과 그래픽카드가 쓰는 VRAM이 따로 있고, 둘 사이 데이터는 PCIe 버스를 오갑니다. 모델이 GPU에서 돌아가려면 그 VRAM 안에 다 들어가야 하죠. 24GB 카드라면 시스템 RAM을 아무리 늘려도 24GB라는 벽은 그대로입니다.

통합 메모리 방식은 이 구분 자체를 없앱니다. CPU와 내장 GPU, NPU가 하나의 메모리 풀을 함께 씁니다. 별도의 VRAM이 없으니 그 풀 전체를 거의 다 모델에게 내줄 수 있습니다. 128GB 구성을 사면 웬만한 중급 그래픽카드 한 대 값으로 128GB짜리 “VRAM”을 손에 넣는 셈이죠. 애플은 이미 오래전부터 Mac을 이런 구조로 만들어왔고, AMD의 Strix Halo, NVIDIA의 DGX Spark, 인텔의 Core Ultra, 퀄컴의 Snapdragon X도 이제 같은 방식을 씁니다. 미니PC가 갑자기 로컬 LLM 이야기에 끼어든 이유는 바로 이 저렴한 대용량 때문입니다.

담을 수 있는가와 빠른가는 서로 다른 숫자다

로컬 LLM을 돌릴 때 헷갈리기 쉬운 두 가지 스펙이 있습니다. 하나는 용량으로, 메모리가 몇 GB인지가 모델이 아예 로드되는지를 결정합니다. 여기서는 통합 메모리 미니PC가 이깁니다. 다른 하나는 대역폭으로, 초당 몇 GB를 처리하는지가 모델이 로드된 뒤 얼마나 빨리 답을 내는지를 결정합니다. 여기서는 미니PC가 진짜 GPU에 크게 밀립니다.

미니PC 쪽은 용량이 128GB, 심지어 애플 M3 Ultra는 512GB까지 올라가지만 대역폭은 초당 120~270GB 선에 머뭅니다. GPU 쪽은 반대로 초당 900~1,800GB의 대역폭을 내면서도 용량은 8,500달러짜리 워크스테이션 카드에 이르러서야 겨우 24~32GB를 넘습니다. 미니PC와 중고 RTX 3090은 같은 척도 위의 두 지점이 아니라, 아예 정반대 방향을 향하고 있는 셈입니다.

왜 하필 대역폭이 속도를 정하나

빠른 GPU와 널찍한 미니PC가 이렇게 다르게 행동하는 이유는 루프라인 모델로 설명됩니다. 어떤 작업이든 칩의 연산 속도와 메모리에서 데이터를 옮기는 속도 중 먼저 바닥나는 쪽에 의해 성능이 제한된다는 이론입니다. 어느 쪽이 발목을 잡는지는 읽어온 바이트 하나당 얼마나 많은 연산을 하는지에 달려 있습니다.

텍스트 생성은 바이트당 연산량이 아주 적습니다. 토큰 하나를 만들려면 모델 전체를 사실상 한 번 메모리에서 읽어와야 하고, 그다음 약간의 계산만 하면 됩니다. 그러니 속도를 정하는 건 연산력이 아니라 메모리 대역폭입니다. 애플의 머신러닝 팀도 자사 MLX 관련 글에서 “이어지는 토큰 생성은 연산 능력이 아니라 메모리 대역폭에 의해 제한된다”고 밝힌 바 있습니다.

대략적인 계산식은 이렇습니다. 초당 생성 토큰 수는 대역폭을 토큰당 읽는 바이트 수로 나눈 값에 가깝습니다. 40GB를 읽어야 하는 70B 모델을 초당 256GB짜리 Strix Halo에서 돌리면 256을 40으로 나눈 값, 대략 초당 6개 토큰이 이론적 한계이고 실제로는 이보다 낮습니다. 초당 819GB인 M3 Ultra라면 20개 정도까지 올라가죠. 미니PC가 느린 건 드라이버 문제나 약한 칩 때문이 아니라, 순전히 대역폭 숫자가 만드는 산수의 결과입니다.

한 가지 예외가 있다면 미니PC가 가장 잘하는 재주인 전문가 혼합(MoE) 모델입니다. Qwen3-30B-A3B 같은 MoE 모델은 300억 개 매개변수를 갖고 있지만 토큰 하나당 실제로 활성화되는 건 약 30억 개뿐이라, 읽어야 할 데이터가 40GB가 아니라 2GB 정도에 그칩니다. 같은 Strix Halo 박스에서 밀집형 70B 모델은 초당 5개 토큰으로 기어가지만, 이 MoE 모델은 초당 72개까지 나온다는 실측 결과가 있습니다. 미니PC를 빠르게 느끼고 싶다면 MoE 모델을 돌리라는 이야기가 나오는 이유입니다.

아무도 안 알려주는 함정, 프롬프트를 읽는 시간

다들 토큰 생성 속도만 이야기하지만, 미니PC 경험을 실제로 망치는 건 다른 숫자입니다. 프롬프트 처리, 첫 단어가 나오기 전 입력을 읽어들이는 시간이죠.

이 과정은 디코드와 정반대로 움직입니다. 프롬프트 전체를 병렬로 훑기 때문에 연산력이 많이 필요하고, 그래서 대역폭이 아니라 칩의 연산 성능에 의해 제한됩니다. 미니PC의 내장 GPU는 개별 그래픽카드에 비해 연산력이 한참 부족하다 보니, 토큰 생성 속도는 그럭저럭 봐줄 만한데 프롬프트 처리에서 무너지는 경우가 흔합니다. 실측 자료를 보면 밀집형 70B 모델의 프롬프트 처리 속도는 초당 약 95개 토큰 정도인데, 이는 4천 토큰짜리 문서(긴 이메일 스레드나 코드 파일 몇 페이지 분량)를 넣으면 모델이 입도 떼기 전에 40초 가까이 기다려야 한다는 뜻입니다. 긴 문서나 큰 코드베이스를 다루는 용도라면, 초당 토큰 수가 아니라 바로 이 지점에서 벽에 부딪히게 됩니다.

NPU도 큰 도움은 안 됩니다. 이 칩들은 하나같이 큼직한 NPU 성능 수치를 내세우지만, 로컬 챗봇 용도에서는 별 의미가 없습니다. NPU도 결국 같은 메모리 풀을 공유하기 때문에 작업을 NPU로 옮긴다고 대역폭이라는 병목 자체가 사라지지 않고, 게다가 실제로 널리 쓰이는 llama.cpp나 Ollama 같은 소프트웨어가 NPU를 제대로 활용하지도 못하기 때문입니다.

결국 통합 메모리 미니PC는 속도를 위한 기계가 아니라 용량을 위한 기계입니다. 어떤 GPU에도 안 들어가는 크기의 모델을 저렴하게 담고 싶을 때, 배치 작업처럼 기다림을 감수할 수 있는 용도로 쓸 때 제 몫을 합니다. 반대로 빠른 응답이나 긴 프롬프트 처리가 중요하다면, 답은 미니PC가 아니라 여러 GPU를 꽂은 리그이거나 클라우드 GPU를 빌리는 쪽에 있습니다.