128GB 통합 메모리 미니PC 비교 — AI Max+ 395(스트릭스 헤일로)·DGX Spark·맥 스튜디오

CanRun 계산으로는 128GB 기기 세 대에 기본 양자화로 올라가는 큰 모델이 똑같습니다. 세 기기는 스트릭스 헤일로 PC, 128GB NVIDIA DGX Spark, M4 Max를 단 2025년 맥 스튜디오입니다. 스트릭스 헤일로는 Ryzen AI Max+ 395가 속한 AMD 플랫폼의 코드명입니다. 셋 다 128GB 구성이면 gpt-oss-120b가 GPU에 전부 올라갑니다. 차이는 글이 나오는 속도를 정하는 메모리 대역폭과, 128GB 가운데 GPU가 쓸 수 있는 몫에서 납니다. 이 차이는 dense 모델에서 잘 드러납니다. CanRun 추정으로 Gemma 4 31B는 DGX Spark에서 겨우 돌아가지만, 대역폭이 두 배인 M4 Max에서는 원활하게 돌아갑니다.

128GB 통합 메모리에 들어가는 모델

세 기기 모두 CPU와 GPU가 메모리 하나를 나눠 씁니다. 이런 구조를 통합 메모리라고 부릅니다. 따로 달린 VRAM이 없으니, 모델은 이 메모리 가운데 GPU가 쓸 수 있는 몫에 들어가야 합니다. CanRun은 GGUF 파일 전체에 KV 캐시와 연산 버퍼를 더해 필요량을 구합니다. KV 캐시는 지금까지의 대화를 담는 메모리이고, 연산 버퍼는 계산에 쓰는 작업 공간입니다. 스트릭스 헤일로와 맥은 이 필요량을 통합 메모리의 약 70%와 비교합니다. 128GB 기기라면 GPU 몫은 89.6GB입니다. DGX Spark는 공개된 부팅 기록을 바탕으로, Linux와 데스크톱이 쓰고 남은 116.9GB를 GPU 몫으로 봅니다. 두 값의 근거와 기기별 실제 한도는 다음 절에서 설명합니다.

아래 표는 CanRun 카탈로그에서 가장 큰 축에 드는 모델들의 필요량입니다. 8k 컨텍스트와 f16(양자화하지 않은 16비트) KV 캐시를 기준으로 했습니다. 양자화는 모델마다 기본값을 썼습니다. 대부분은 CanRun의 기준인 4비트 Q4_K_M이고, gpt-oss는 원래 배포 형식인 MXFP4입니다. Solar Open 2 250B는 CanRun 데이터에 Q4_K_M 파일이 없어 IQ4_XS로 계산했습니다.

Llama 3.3 70B와 gpt-oss-120b는 세 기기 모두 GPU 몫 안에 들어갑니다. 업스테이지의 Solar Open 100B도 마찬가지입니다. 앞의 세 모델보다 큰 Qwen3.5 122B-A10B도 들어갑니다. 이 모델은 세 기기 모두에서 128k 컨텍스트를 f16 KV 캐시로 잡아도 GPU 몫을 넘지 않습니다. 반면 Solar Open 2 250B는 IQ4_XS로도 137.2GB가 필요합니다. 128GB를 통째로 써도 운영체제 몫이 남지 않는 크기라, 세 기기 어디에도 들어가지 않습니다.

다음 표는 카탈로그의 모든 모델을 칩과 메모리 구성마다 판정하고, 판정별로 몇 개인지 센 것입니다. 칩은 스트릭스 헤일로, DGX Spark, 40코어 GPU M4 Max, 그리고 맥 스튜디오의 M5 Ultra·M3 Ultra·M2 Ultra입니다.

표에서 128GB 구성은 스트릭스 헤일로·DGX Spark·M4 Max·M2 Ultra의 네 줄입니다. 이 가운데 DGX Spark 줄은 GPU 몫을 다르게 계산해서, GPU가 쓸 수 있는 메모리가 나머지 세 줄보다 많습니다(다음 절에서 설명합니다). DGX Spark에는 64GB 줄도 있습니다. NVIDIA의 협력 제조사가 파는 구성인데, 여기서는 gpt-oss-120b가 들어가지 않습니다. 그 밖에는 두 애플 칩이 스트릭스 헤일로·DGX Spark보다 쾌적하게 돌아가는 모델이 많습니다. 스트릭스 헤일로와 DGX Spark는 대역폭이 거의 같고, CanRun 추정에서 쾌적하게 돌아가는 모델 수도 비슷합니다. 반면 M2 Ultra는 대역폭이 M4 Max의 1.5배쯤인데도 쾌적하게 돌아가는 모델 수가 같습니다. CanRun이 Ultra 칩에 더 낮은 계수를 쓰기 때문입니다(‘이 숫자는 얼마나 확실한가’에서 설명합니다). 예를 들어 Qwen3 32B는 두 칩 모두에서 원활하게 돌아가고, 쾌적한 칩은 없습니다. 2026년 맥 스튜디오의 M5 Ultra는 대역폭이 M3 Ultra의 1.5배입니다. 그래서 가장 작은 96GB 구성에서도 쾌적하게 돌아가는 모델이 다른 칩의 어느 줄보다 많습니다. Qwen3 32B도 M5 Ultra에서는 쾌적하게 돌아갑니다.

맥 스튜디오(2025)에서 128GB 구성이 있는 칩은 40코어 GPU M4 Max뿐이고, M3 Ultra에는 128GB 구성이 없습니다. 애플은 2025년 3월 M3 Ultra를 96GB부터 512GB까지 고를 수 있게 내놓았습니다. 하지만 이 맥 스튜디오의 사양 페이지에는 지금 96GB부터 256GB까지만 나옵니다. 표의 512GB 줄은 이 구성이 빠지기 전에 512GB로 산 기기에 해당합니다. 2023년 맥 스튜디오의 M2 Ultra는 64GB·128GB·192GB 구성이었습니다.

2026년 9월부터는 M5 Max와 M5 Ultra를 쓰는 새 맥 스튜디오가 팔립니다. 여기서도 128GB 구성은 40코어 GPU M5 Max에만 있습니다. 같은 칩에 128GB를 단 MacBook Pro도 있습니다. CanRun 추정으로는 이 칩에서도 gpt-oss-120b가 쾌적하게 돌아갑니다. M5 Ultra는 96GB부터 고를 수 있고, 256GB 구성은 80코어 GPU 칩에만 있습니다. CanRun은 M5 Ultra를 지금 팔리는 96GB·256GB 구성으로 계산합니다.

128GB 가운데 GPU가 쓸 수 있는 양

CanRun은 맥과 스트릭스 헤일로에서 메모리의 약 70%를 GPU 몫으로 봅니다. 실제 한도는 운영체제와 설정에 따라 다르고, 세 회사가 다루는 방식도 다릅니다. DGX Spark에는 공개된 부팅 기록에서 구한 값을 씁니다. 이 값은 아래에서 설명합니다.

맥 스튜디오

macOS는 GPU가 가져갈 수 있는 통합 메모리에 한도를 둡니다. llama.cpp 토론 #2182에 인용된 코드를 보면, 32GB보다 큰 맥은 약 4분의 1을 남겨 둡니다. 그래서 128GB 맥은 기본 설정에서 GPU가 약 4분의 3까지 쓸 수 있습니다. CanRun이 잡는 70%보다 많습니다. 한도는 macOS 터미널에서 sudo sysctl iogpu.wired_limit_mb= 뒤에 MB 단위 값을 붙여 올립니다. 기본값과 명령, macOS에 메모리를 너무 적게 남겼을 때의 위험은 ‘맥 미니·맥북·맥 스튜디오에서 로컬 LLM 돌리기 — M4·M5 통합 메모리는 얼마나 필요할까’에서 다룹니다.

스트릭스 헤일로

Windows에서는 AMD의 가변 그래픽 메모리(Variable Graphics Memory)를 씁니다. 시스템 RAM 일부를 그래픽 전용 메모리로 돌리는 기능입니다. 설정은 AMD Software: Adrenalin Edition에서 합니다. AMD FAQ에 따르면 128GB Ryzen AI Max+ 395 시스템은 최대 96GB를 그래픽 전용으로 돌릴 수 있습니다. 이렇게 설정하면 공유 메모리까지 합쳐 GPU가 112GB까지 쓸 수 있습니다. 다만 AMD는 작업을 96GB 안에서 돌릴 때 성능이 가장 좋다고 설명합니다.

Linux에서는 사정이 다릅니다. AMD ROCm 문서에 따르면 GPU가 기본으로 쓸 수 있는 공유 메모리는 시스템 RAM의 약 절반입니다. 이 한도를 GTT라고 부릅니다. 커널 드라이버가 정하는 한도라서, llama.cpp를 ROCm으로 돌리든 Vulkan으로 돌리든 똑같이 걸립니다. AMD는 BIOS의 전용 메모리 예약은 작게 두고, 공유 메모리 한도를 올리라고 권합니다. amd-debug-tools 패키지에 든 amd-ttm 도구로 지금 한도를 보고 새 한도를 정합니다. 바꾼 값은 재부팅한 뒤에 적용됩니다. amd-ttm의 GB는 1024 기준이라 CanRun 수치보다 7%쯤 작게 나옵니다. 128GB의 절반이면 gpt-oss-120b의 필요량 64.3GB를 넣고 남는 여유가 거의 없습니다. 이 모델을 불러오기 전에 한도부터 높여 두세요.

DGX Spark

NVIDIA는 DGX Spark의 메모리를 통합 시스템 메모리로만 적고, GPU 몫을 따로 밝히지 않습니다. 제품 페이지에는 이제 128GB와 함께 64GB 구성도 나옵니다. 64GB 구성은 협력 제조사만 팔고, 대역폭은 같습니다. NVIDIA의 알려진 문제(Known issues) 문서에는 메모리 표시에 관한 내용이 있습니다. GPU에 전용 프레임버퍼 메모리가 없어서, nvidia-smi는 전체 메모리 사용량을 Not Supported로 표시합니다. 프로세스별 GPU 메모리는 그대로 보여 줍니다. 같은 문서는 CUDA 프로그램이 읽는 남은 메모리가 실제로 할당할 수 있는 양보다 적게 나올 수 있다고 경고합니다.

Linux에서는 GPU도 다른 프로그램과 같은 메모리에서 몫을 받습니다. 그래서 CanRun은 시스템과 데스크톱이 쓰고 남은 양을 GPU 몫으로 봅니다. 사용자들이 NVIDIA 개발자 포럼에 올린 커널 부팅 로그를 보면, 부팅 뒤 남는 메모리는 DGX OS 7.5.0에서 가장 적습니다. 새 커널 기능이 이전 커널보다 몇 GB를 더 예약하기 때문입니다. 같은 글타래에는 이 문제를 고치는 업데이트가 배포되고 있다는 답이 달려 있습니다. CanRun은 이 가장 낮은 값에서 데스크톱이 가만히 있을 때 쓰는 메모리를 뺍니다. 데스크톱 사용량은 다른 사용자가 알린 값입니다. 그러면 128GB 구성에는 116.9GB가 남습니다. 64GB 구성은 아직 공개된 값이 없어서, 128GB에서 구한 고정 몫을 똑같이 빼 48.2GB로 봅니다. 한 대로 돌린 공개 결과도 이 값과 맞습니다. 한 사용자가 DGX Spark 한 대에 올린 DeepSeek V4 Flash 0731 파일 가운데 가장 큰 것은 짧은 컨텍스트에서 이 값 안에 들어갑니다. 그 사용자가 한 대에는 들어가지 않는다고 적은 한 단계 큰 파일은 이 값을 넘습니다.

CanRun의 값은 어디쯤인가

128GB 맥에서 CanRun의 70%는 macOS 기본 한도보다 낮습니다. 스트릭스 헤일로에서는 Linux 기본값과 Windows 최대치 사이에 있습니다. DGX Spark에서 CanRun의 값은 가장 낮은 부팅 기록에서 출발합니다. 그래서 이전 커널이나 문제가 고쳐진 커널을 쓰거나 데스크톱 없이 돌리면 여유가 조금 더 있습니다. 이 차이는 필요량이 그 사이에 걸리는 모델에서만 문제가 됩니다. 예를 들어 Solar Open 2 250B의 Q2_K 파일은 96.4GB가 필요합니다. Q2_K는 품질 손실이 큰 2비트 양자화입니다. 이 필요량은 70% 몫을 넘어서, 128GB 스트릭스 헤일로와 맥에서는 CPU 전용으로 계산됩니다. CPU 전용으로 계산하면 속도와 상관없이 판정이 겨우 돌아가는 단계에서 멈춥니다. 이 값은 이론 추정입니다. DGX Spark에서는 GPU 몫 안에 들어가 원활하게 돌아갑니다. 한도를 올리면 나머지 두 기기에서도 GPU에 들어갈 수 있습니다. 실제로 어디에 올라갔는지는 ollama ps나 llama.cpp 로딩 로그로 확인하세요.

생성 속도 — gpt-oss-120b 공개 벤치마크

토큰을 하나 만들 때마다 모델의 활성 가중치와 KV 캐시를 메모리에서 읽습니다. 그래서 CanRun은 메모리 대역폭으로 생성 속도를 추정합니다. 대역폭은 스트릭스 헤일로가 256 GB/s, DGX Spark가 273 GB/s입니다. 40코어 GPU M4 Max는 546 GB/s입니다. M3 Ultra는 819 GB/s, M2 Ultra는 800 GB/s입니다. 두 칩은 스트릭스 헤일로·DGX Spark의 약 세 배이고, M4 Max는 약 두 배입니다. M5 Ultra는 1,228 GB/s로 M3 Ultra의 1.5배입니다.

gpt-oss-120b는 MoE(전문가 혼합) 모델이라 토큰마다 전체 파라미터 가운데 일부만 씁니다. 그래서 같은 크기의 dense 모델보다 토큰마다 읽는 양이 훨씬 적습니다. 전체 파라미터와 활성 파라미터 수는 위 메모리 표에 있습니다. 이 글의 칩 가운데 세 곳에는 llama.cpp 공개 벤치마크 결과가 있습니다.

공개 벤치마크 결과로 보면 세 기기 모두 쾌적하게 돌아갑니다. 생각한 뒤 답하는 모델에 쓰는 더 엄격한 기준으로도 그렇습니다. M4 Max는 CanRun 데이터에 gpt-oss-120b 공개 결과가 없습니다. 보정된 추정으로는 여기서도 쾌적하게 돌아갑니다.

DGX Spark 결과는 어느 빌드로 잰 값인지 함께 봐야 합니다. CanRun 데이터의 이 값은 llama.cpp 개발진의 DGX Spark 결과 파일에서 가져왔고, 이 파일은 2026년 2월에 마지막으로 다시 쟀습니다. 2025년 10월에 열린 llama.cpp의 DGX Spark 토론을 보면 결과가 소프트웨어와 설정에 따라 달라져 왔습니다. 개발진이 처음 잰 gpt-oss-120b 생성 속도는 지금 파일의 3분의 2쯤이었습니다. 이 토론에서 한 참여자는 같은 llama.cpp 빌드로 DGX Spark와 스트릭스 헤일로를 함께 쟀습니다. 기본 설정에서는 두 기기의 생성 속도가 거의 같았습니다. mmap은 모델 파일을 읽어 들이지 않고 메모리에 매핑하는 방식입니다. 이 mmap을 끄자 DGX Spark만 빨라졌습니다. 스트릭스 헤일로보다 대화 첫머리에서 약 5분의 1, 32k 토큰이 쌓인 뒤에는 약 10분의 1 더 빨랐습니다. 새 Linux 커널은 모델을 불러오는 시간을 줄였을 뿐, 생성 속도는 거의 그대로였습니다. CanRun의 DGX Spark 추정은 개발진 결과 파일에 맞춘 것이고, 이 파일은 mmap을 끄고 잰 값입니다. 그러니 추정도 mmap을 끈 상태를 전제로 합니다. DGX Spark에서 llama.cpp를 쓴다면 mmap을 끄세요. 지금 빌드에서는 --load-mode none, 예전 빌드에서는 --no-mmap입니다. mmap을 켜 두면 생성 속도가 CanRun 추정보다 낮게 나올 것으로 예상합니다.

dense 모델에서 드러나는 대역폭 차이

아래 표는 모델 5개를 다섯 칩과 RTX 5090에서 8k 컨텍스트로 판정한 결과입니다. 통합 메모리 칸에는 그 칩에서 가장 좋은 판정이 나오는 가장 작은 메모리 구성이 적혀 있습니다. 그래서 128GB를 다루는 글인데도 ‘32GB 구성’, ‘48GB 구성’ 같은 작은 구성이 보입니다. 모델이 GPU에 다 들어가면, CanRun은 같은 칩의 더 큰 구성에도 같은 속도 추정을 냅니다. RTX 5090은 시스템 RAM 32GB를 기준으로 판정했습니다. 이 표의 모델은 모두 생각 모드가 있습니다. Gemma 4 31B는 기본으로 꺼져 있지만, CanRun은 모든 칸에 1.5배 엄격한 속도 기준을 적용합니다.

Qwen3.5 35B-A3B는 토큰마다 파라미터를 약 3B만 쓰는 MoE 모델이라, 여섯 기기 모두에서 쾌적하게 돌아갑니다.

dense 모델은 토큰마다 가중치를 전부 읽으므로 여기서 차이가 벌어집니다. Gemma 4 31B는 스트릭스 헤일로와 DGX Spark에서 겨우 돌아갑니다. M4 Max와 M3·M2 Ultra에서는 원활하게 돌아가고, RTX 5090에서는 쾌적하게 돌아갑니다. 표에 없는 M5 Ultra에서도 쾌적하게 돌아갑니다. DGX Spark 칸은 공개 벤치마크 결과이고, 나머지는 모두 보정된 추정입니다. 스트릭스 헤일로와 DGX Spark에서는 엄격한 기준이 결과를 가릅니다. 두 기기의 Gemma 4 31B 추정 속도는 ‘원활’ 기준선의 일반 값과 1.5배 값 사이에 있습니다. 비슷한 크기에 생각 모드가 없는 dense 모델 Gemma 3 27B는 두 기기 모두에서 원활하게 돌아갑니다.

표에는 없지만, 더 큰 dense 모델인 Llama 3.3 70B도 마찬가지입니다. Q4_K_M이면 128GB 기기 모두에서 GPU에 전부 올라갑니다. 스트릭스 헤일로와 DGX Spark에서는 겨우 돌아갑니다. M4 Max와 M3·M2 Ultra에서는 원활하게 돌아가고, 96GB M3 Ultra도 마찬가지입니다. 통합 메모리 기기 가운데 대역폭이 가장 큰 M5 Ultra에서도 원활하게 돌아가는 데 그칩니다. dense 70B 모델을 주로 돌리려 한다면, CanRun 추정으로는 이 글의 기기 가운데 빠르게 돌려 주는 것이 없습니다.

큰 MoE 모델 두 개는 칩마다 결과가 다르게 갈립니다. Qwen3.5 122B-A10B는 토큰마다 쓰는 파라미터가 gpt-oss-120b의 약 두 배입니다. 스트릭스 헤일로와 DGX Spark에서는 원활하게 돌아갑니다. M4 Max와 128GB M2 Ultra에서는 쾌적하게 돌아갑니다. M3 Ultra 칸에는 256GB 구성이 적혀 있습니다. 96GB 구성에서는 GPU 몫이 모자라 CPU 전용으로 계산되기 때문입니다. CPU 전용으로 계산하면 속도와 상관없이 판정이 겨우 돌아가는 단계에서 멈춥니다. 이 값은 이론 추정입니다.

Solar Open 2 250B는 128GB 기기에서 IQ4_XS로는 돌릴 수 없습니다. 표는 대신 Q2_K 파일을 제안합니다. 앞 절에서 본 대로 스트릭스 헤일로와 M4 Max에서는 CPU 전용으로, DGX Spark에서는 GPU에 전부 올려 계산합니다. 256GB M3 Ultra와 256GB M5 Ultra는 IQ4_XS 파일을 GPU에 다 올려 쾌적하게 돌립니다. 192GB M2 Ultra에서는 CanRun의 GPU 몫을 조금 넘어 CPU 전용으로 계산됩니다. 그래서 속도와 상관없이 CanRun은 겨우 돌아간다고 봅니다(이론 추정). 이 구성에서는 macOS 기본 한도가 CanRun의 값보다 높습니다. 포기하기 전에 ollama ps로 확인해 보세요.

긴 컨텍스트와 프롬프트 처리

gpt-oss-120b는 KV 캐시가 작습니다. 층의 절반은 최근 토큰만 담는 슬라이딩 윈도를 쓰고, 나머지 층도 담는 키·값이 작습니다. 128k 컨텍스트를 f16 KV 캐시로 잡아도 필요량은 69.9GB입니다. 128GB 기기 세 대 모두 GPU 몫 안에 들어갑니다.

이 표는 128GB 스트릭스 헤일로 기준입니다. 모든 컨텍스트에서 GPU 몫 안에 들어가지만, f16 캐시로 128k에서는 판정이 한 단계 내려갑니다. 토큰마다 KV 캐시 전체를 읽기 때문입니다. dense 모델은 메모리가 훨씬 빨리 찹니다. 128k·f16에서 Llama 3.3 70B의 KV 캐시는 42.9GB이고, gpt-oss-120b는 4.8GB입니다. 모델마다 KV 캐시 크기가 왜 다른지는 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’에서 설명합니다.

CanRun의 판정은 생성 속도를 봅니다. 그런데 첫 토큰이 나오기 전에 기기는 프롬프트 전체를 먼저 처리해야 합니다. 긴 문서나 코딩 에이전트처럼 프롬프트가 길면, 이 대기 시간이 생성 속도보다 더 중요할 수 있습니다. 프롬프트 처리 시간은 이 글의 표에 나오지 않습니다.

프롬프트 처리에서는 DGX Spark가 앞섭니다. 앞에서 말한 llama.cpp 토론의 같은 빌드 비교 결과를 보겠습니다. 대화 첫머리에서 DGX Spark는 gpt-oss-120b 프롬프트를 스트릭스 헤일로보다 두 배 가까이 빨리 처리했습니다. 32k 토큰이 쌓이면 두 기기 모두 느려지는데, 그때는 세 배 넘게 빨랐습니다. CanRun 데이터의 M2 Ultra 결과는 같은 llama-bench 프롬프트 시험으로 잰 것입니다(예전 빌드). 대화 첫머리에서는 스트릭스 헤일로보다 빠르고 DGX Spark보다 느렸습니다. 32k 토큰이 쌓인 뒤의 맥 결과는 없습니다.

그래픽카드 + 시스템 RAM과 비교하면

큰 모델을 돌리는 또 다른 흔한 방법은 그래픽카드를 단 데스크톱 PC입니다. RTX 5090은 VRAM이 32GB이고 대역폭이 1,792 GB/s입니다. 이 대역폭은 M3·M2 Ultra의 약 두 배, 스트릭스 헤일로·DGX Spark의 6~7배입니다. CanRun 추정으로는 VRAM에 들어가는 모델이라면 RTX 5090이 더 빠릅니다. Gemma 4 31B는 RTX 5090에서 쾌적하게 돌아갑니다. 표의 통합 메모리 기기보다 판정이 한 단계 이상 높습니다.

gpt-oss-120b는 카드에 다 들어가지 않아서, 들어가지 않는 전문가 층을 시스템 RAM에 둡니다. 시스템 RAM이 32GB면 그래도 들어가지 않습니다. 64GB면 원활하게 돌아갑니다. 이 값은 RAM 속도에 따라 달라지는 이론 추정(±30%)입니다. 스트릭스 헤일로와 DGX Spark는 같은 모델을 쾌적하게 돌리고, 공개 벤치마크 결과도 있습니다. 전문가를 나눠 두는 방식은 ‘그래픽카드보다 큰 MoE 모델 돌리기 — gpt-oss-120b와 시스템 RAM’에서 자세히 다룹니다.

카드보다 큰 dense 모델은 일부 층을 RAM에 두는 부분 오프로드로 넘어갑니다. Llama 3.3 70B는 RTX 5090에서 이렇게 겨우 돌아갑니다. 통합 메모리 기기와 판정은 같지만 이유가 다릅니다. 통합 메모리 기기는 대역폭 때문이고, RTX 5090은 RAM에 둔 층 때문입니다.

PC 쪽이 앞서는 것은 전체 메모리 크기입니다. 시스템 RAM이 128GB면 32GB 카드와 합쳐 Solar Open 2 250B를 IQ4_XS로 올릴 수 있습니다. 128GB 통합 메모리 기기로는 할 수 없는 일입니다. 다만 CanRun은 이 구성도 겨우 돌아간다고 봅니다(이론 추정).

이 글은 가격을 비교하지 않습니다. CanRun 데이터의 DGX Spark 가격은 NVIDIA가 처음 내놓은 128GB 제품의 출시가 US$3,999입니다. 협력 제조사 제품과 64GB 구성, 스트릭스 헤일로와 맥은 같은 칩이라도 제조사와 메모리 구성에 따라 값이 다릅니다. CanRun 데이터에는 이 기기들의 날짜가 붙은 실거래가도 없습니다.

더 볼 곳:

• 칩별로 모든 모델의 판정을 볼 수 있는 페이지: Ryzen AI Max+ 395 (Strix Halo), NVIDIA DGX Spark, Apple M4 Max (40-core GPU), Apple M5 Ultra, Apple M3 Ultra, Apple M2 Ultra
• ‘맥 미니·맥북·맥 스튜디오에서 로컬 LLM 돌리기 — M4·M5 통합 메모리는 얼마나 필요할까’: macOS의 GPU 메모리 한도와 더 작은 맥
• ‘그래픽카드보다 큰 MoE 모델 돌리기 — gpt-oss-120b와 시스템 RAM’: 그래픽카드와 시스템 RAM을 함께 쓰는 방법

이 숫자는 얼마나 확실한가

메모리 수치는 공식으로 계산합니다. 실제 GGUF 파일 크기에 모델 설정으로 구한 KV 캐시와 연산 버퍼를 더합니다. 어림한 부분은 GPU 몫입니다. 맥과 스트릭스 헤일로에는 70%를, DGX Spark에는 공개된 부팅 기록에서 구한 값을 씁니다. 기기별 실제 한도와 어떻게 다른지는 둘째 절에서 설명했습니다.

속도는 신뢰 라벨이 ‘실측’인 칸만 공개 벤치마크 결과입니다. 이 글에서 GPU에 전부 올라가는 나머지 칸은 ‘보정된 추정’이고, 오차 범위는 ±20%입니다. ±12%는 NVIDIA·AMD 그래픽카드의 dense 모델에만 씁니다. CPU 전용 칸과 전문가를 RAM에 둔 RTX 5090 칸은 ‘이론 추정(±30%)’입니다.

CanRun은 기기 종류마다 효율 계수로 대역폭을 속도로 바꿉니다. 계수는 공개 벤치마크 결과에 맞춰 정합니다. DGX Spark 계수는 llama.cpp 개발진의 결과 파일에서 나왔습니다. 같은 빌드로 다섯 모델을 대화 첫머리와 8k 토큰이 쌓인 뒤에 잰 결과이고, CanRun 추정은 그 결과 하나하나와 5분의 1 안쪽으로 맞습니다. 다만 모두 mmap을 끈 기기 한 대의 결과입니다. 스트릭스 헤일로 계수는 여러 기기에서 지금 llama.cpp 빌드의 Vulkan 백엔드로 잰 결과에 맞췄습니다. dense 모델 결과 6개는 CanRun 추정과 4% 안쪽으로, MoE 결과 7개는 10분의 1 안쪽으로 맞습니다. 이 계수로 보면 두 기기는 dense 모델에서 2% 안쪽으로 비슷하고, MoE 모델에서는 DGX Spark가 5~17% 빠릅니다. 두 기기의 계수가 서로 다른 공개 결과에서 나왔으니 차이의 크기는 조심해서 봐야 합니다. 애플 칩의 공개 결과를 보면 Ultra 칩은 Max 칩보다 대역폭을 속도로 덜 살립니다. 그래서 CanRun은 Ultra 칩에 더 낮은 계수를 씁니다. dense 모델용 애플 계수는 둘 다 지금 llama.cpp 빌드로 잰 결과에 맞췄습니다. llama.cpp 애플 토론의 요약 표는 아직 2023년 빌드로 잰 값인데, 같은 M2 Ultra에서 지금 빌드가 3분의 1쯤 빨랐습니다.

소프트웨어도 결과를 바꿉니다. 스트릭스 헤일로는 llama.cpp를 ROCm이나 Vulkan으로 돌립니다. 같은 기기·같은 빌드로 비교한 공개 결과에서 ROCm은 Vulkan보다 생성 속도가 3~12% 느렸습니다. ROCm을 쓴다면 CanRun 범위의 낮은 쪽을 예상하세요. DGX Spark 결과는 llama.cpp 빌드와 mmap 설정에 따라 달라졌습니다. 맥에서는 MLX 형식 모델도 돌릴 수 있습니다. CanRun의 추정은 llama.cpp에서 GGUF 파일을 돌리는 경우를 기준으로 합니다.

CanRun 계산에 넣지 않는 것도 있습니다.

• 프롬프트 처리 시간은 이 글의 판정에 들어가지 않습니다.
• 기기의 전력 모드는 따로 계산하지 않습니다.
• 사용자가 올린 GPU 메모리 한도는 반영하지 않습니다.
• 다른 프로그램이 쓰는 메모리는 따로 빼지 않습니다.
• 요청 여러 개를 동시에 처리하는 경우도 계산하지 않습니다.

내 기기에서 모델이 실제로 어떻게 올라갔는지는 ollama ps로 확인합니다. SIZE 열에서 차지한 메모리를, PROCESSOR 열에서 100% GPU인지를, CONTEXT 열에서 컨텍스트 길이를 봅니다. llama.cpp라면 모델을 불러올 때 나오는 로그를 봅니다. DGX Spark에서 nvidia-smi는 전체 메모리 사용량을 Not Supported로 표시하지만, 프로세스별 GPU 메모리는 보여 줍니다.

이 글에서 말하는 판정은 모두 8k 컨텍스트·f16 KV 기준입니다. 생각 모드가 있는 모델은 답하기 전에 토큰을 더 쓸 수 있습니다. 그래서 CanRun은 이런 모델의 속도 기준을 1.5배 엄격하게 잡습니다. Gemma 4 31B처럼 생각 모드가 기본으로 꺼져 있어도 마찬가지입니다. 아래 범례에는 이 점이 나오지 않습니다. 판정별 조건은 아래 표와 같습니다.

자주 묻는 질문

128GB 통합 메모리 기기로 70B 모델을 돌릴 수 있나요?

올릴 수는 있고, 속도는 대역폭에 달려 있습니다. Q4_K_M Llama 3.3 70B는 스트릭스 헤일로, DGX Spark, 128GB M4 Max에 전부 올라갑니다. CanRun 추정으로는 M4 Max와 M5·M3·M2 Ultra에서 원활하게 돌아갑니다. 스트릭스 헤일로와 DGX Spark에서는 겨우 돌아가고, 한 단계 낮은 IQ4_XS로 내려도 마찬가지입니다. 이 크기의 dense 모델은 메모리 용량이 아니라 대역폭에서 속도가 막힙니다. 같은 기기에서도 MoE 모델인 gpt-oss-120b는 쾌적하게 돌아갑니다.

스트릭스 헤일로와 DGX Spark 가운데 어느 쪽이 빠른가요?

답을 생성하는 속도는 큰 차이가 없습니다. 한 참여자가 같은 llama.cpp 빌드로 잰 결과에서, 기본 설정으로는 두 기기가 거의 같았습니다. DGX Spark에서 mmap을 끄자 대화 첫머리에서 약 5분의 1, 32k 토큰이 쌓인 뒤에는 약 10분의 1 더 빨랐습니다. DGX Spark가 크게 앞서는 것은 프롬프트 처리이고, 프롬프트가 길수록 차이가 커집니다. CanRun 추정으로는 dense 모델에서 두 기기가 2% 안쪽으로 비슷하고, MoE 모델에서는 DGX Spark가 빠르지만 그 차이는 대화 첫머리의 mmap을 끈 결과보다 작습니다. 두 기기의 계수가 서로 다른 공개 결과에서 나왔으니, 차이의 크기는 조심해서 봐야 합니다. 메모리는 둘 다 128GB입니다. 다만 CanRun은 공개된 부팅 기록을 바탕으로 DGX Spark의 GPU 몫을 스트릭스 헤일로의 70%보다 크게 계산합니다.

맥 스튜디오가 스트릭스 헤일로나 DGX Spark보다 빠른가요?

생성 속도는 CanRun 추정으로 더 빠릅니다. 대역폭이 M4 Max는 두 배쯤, M3·M2 Ultra는 세 배쯤, M5 Ultra는 네 배가 넘기 때문입니다. 차이는 위 판정표에서 볼 수 있고, dense 모델에서 가장 크게 벌어집니다. 프롬프트 처리는 CanRun 데이터의 M2 Ultra 결과가 대화 첫머리에서 스트릭스 헤일로와 DGX Spark 사이에 있습니다. 32k 토큰이 쌓인 뒤의 맥 결과는 없습니다.

128GB로 gpt-oss-120b를 긴 컨텍스트로 돌릴 수 있나요?

CanRun 계산으로는 돌릴 수 있습니다. 128k 컨텍스트를 f16 KV 캐시로 잡아도 필요량이 69.9GB라서, 128GB 기기의 GPU 몫 안에 들어갑니다. 다만 128k에서는 스트릭스 헤일로(위 표)와 DGX Spark 모두 판정이 한 단계 내려갑니다. Linux에서 스트릭스 헤일로를 쓴다면, 둘째 절에서 설명한 대로 GPU 메모리 한도부터 올리세요.

출처

• llama.cpp 토론 #16578: DGX Spark 성능: 2025년 10월부터 개발진이 다시 잰 결과의 이력, 한 참여자가 같은 빌드로 잰 DGX Spark·스트릭스 헤일로 결과(대화 첫머리와 32k), mmap을 끄고 다시 잰 결과, 새 커널에서 불러오는 시간만 줄고 생성 속도는 같았던 결과
• llama.cpp DGX Spark 결과 파일(2026년 2월): CanRun 데이터의 DGX Spark gpt-oss-120b 결과와 DGX Spark 효율 계수를 맞춘 다섯 결과(mmap 끔)
• llama.cpp 서버 README: 기본으로 mmap을 쓰고 none이면 mmap 없이 불러오는 --load-mode
• quozul.dev: Ryzen AI Max+ 395에서 gpt-oss-120b 돌리기: CanRun 데이터의 스트릭스 헤일로 결과(128GB Framework Desktop, ROCm)
• llama.cpp 토론 #10879: Vulkan 성능: 2026년 10월 빌드로 스트릭스 헤일로에서 Vulkan과 ROCm을 나란히 잰 결과. CanRun의 스트릭스 헤일로 계수를 맞춘 dense 모델 결과 중 하나
• llama.cpp 이슈 #24438: 스트릭스 헤일로의 ROCm과 Vulkan: 두 백엔드로 잰 MoE 모델 결과와, ROCm 생성 속도가 Vulkan보다 12%쯤 느리다는 AMD 엔지니어의 재측정
• llama.cpp 토론 #15396: llama.cpp로 gpt-oss 돌리기: M2 Ultra의 gpt-oss-120b 생성·프롬프트 처리 결과(192GB M2 Ultra에서 측정), 2025년 llama.cpp 빌드로 잰 M1·M4·Ultra 칩의 gpt-oss-20b 결과
• llama.cpp 토론 #4167: 애플 실리콘 성능: 애플 칩별 dense 모델 생성 속도, M2 Ultra 한 대의 llama.cpp 빌드별 결과, CanRun의 dense 모델용 애플 계수 근거(요약 표의 2023년 빌드 값이 아니라 지금 빌드로 잰 결과)
• llama.cpp 토론 #2182: 애플 실리콘의 VRAM/RAM 분할: macOS가 기본으로 남겨 두는 메모리, iogpu.wired_limit_mb
• AMD: 가변 그래픽 메모리 FAQ: 128GB Ryzen AI Max+ 395 시스템의 그래픽 전용 메모리 최대 96GB, 공유 메모리를 합친 112GB, Adrenalin 설정
• AMD ROCm 문서: RDNA3.5 시스템 최적화: 커널의 기본 GTT 한도(시스템 RAM의 약 절반), BIOS 예약을 작게 두는 설정, 1024 기준 GB로 표시하는 amd-ttm
• NVIDIA DGX Spark 제품 페이지: 대역폭이 같은 64GB·128GB 구성, 64GB 구성은 협력 제조사만 판다는 것
• NVIDIA DGX Spark 사용자 가이드: 하드웨어: 128GB 통합 시스템 메모리와 대역폭
• NVIDIA 개발자 포럼: DGX OS 7.5.0에서 부팅 뒤 남는 메모리가 줄어든 문제: 사용자들이 올린 커널별 부팅 로그(CanRun의 DGX Spark 값은 이 가운데 가장 낮은 값에서 출발한다)와 고치는 업데이트에 관한 답
• NVIDIA 개발자 포럼: DGX 시스템이 차지하는 메모리: CanRun이 빼는 데스크톱의 기본 메모리 사용량을 한 사용자가 잰 값, 대시보드에 더 크게 나오는 이유(파일 캐시)
• Classmethod: DGX Spark 한 대·두 대에서 DeepSeek V4 Flash 0731 돌리기: DGX Spark 한 대에 올라간 파일 크기와 올라가지 않은 파일 크기
• NVIDIA DGX Spark 사용자 가이드: 알려진 문제: nvidia-smi의 전체 메모리 사용량 Not Supported 표시와 프로세스별 GPU 메모리 표시, 할당 가능량보다 적게 나오는 남은 메모리
• Apple: 맥 스튜디오(2025) 기술 사양: M4 Max·M3 Ultra의 메모리 구성(M3 Ultra는 지금 256GB까지 나온다)과 대역폭
• Apple: 맥 스튜디오(M5 Max 또는 M5 Ultra) 기술 사양: M5 Max·M5 Ultra의 메모리 구성과 대역폭, 256GB 구성이 80코어 GPU M5 Ultra에만 있다는 것
• Apple 뉴스룸: M5 Max·M5 Ultra 맥 스튜디오 발표: 2026년 9월 판매 시작
• Apple 뉴스룸: M4 Max·M3 Ultra 맥 스튜디오 발표: 2025년 3월 출시 때 M3 Ultra를 512GB까지 구성할 수 있었다는 발표
• Apple: 맥 스튜디오(2023) 기술 사양: M2 Ultra의 메모리 구성과 대역폭
• Apple: MacBook Pro 16형(M5 Pro 또는 M5 Max) 기술 사양: 40코어 GPU M5 Max의 128GB 구성
• gpt-oss-120b 모델 카드: 전체·활성 파라미터 수