LLM 구동의 주요 스펙: 메모리 용량과 대역폭

연관 문서: 파라미터 착시: KV 캐시의 진실 — KV 캐시 수식과 대역폭 병목의 상세 배경

GPU를 두 배 비싼 걸로 바꾸면 응답이 두 배 빨라질까요. 그렇지 않아요. GPU 두 장을 사면 두 배가 될까요. 그것도 아니에요. 같은 70B 모델을 한쪽에선 12 tok/s로 굴리고 다른 쪽에선 60 tok/s로 굴리는 차이는, 흔히 생각하는 "코어 개수"나 "TFLOPS"와는 거의 무관한 곳에서 결정됩니다. 두 숫자가 결정해요 — 메모리 용량과 메모리 대역폭.

본문 §2에서 "모델 크기만 보고 GPU를 사지 말라"고 했던 실전 근거를 이 부록에 모아뒀어요. 어떤 모델이 어떤 하드웨어에 들어가는지, 같은 "30B급"이라도 속도가 왜 달라지는지, 2026년 4월 기준으로 구매할 수 있는 주요 플랫폼이 어떤 선택지를 주는지를 한 번에 비교합니다.

두 가지 질문

LLM을 로컬에서 돌리려면 두 질문에 순서대로 답해야 해요.

용량: 모델이 메모리에 올라가는가? (부족하면 실행 자체가 불가)
대역폭: 올라간다면 얼마나 빠르게 추론하는가?

용량이 먼저, 대역폭은 그 다음이에요. 한 가지만 보고 사면 둘 중 하나에서 막힙니다.

비유 하나 — 극장의 좌석 수와 출입문 폭

flowchart LR subgraph Capacity["용량(Capacity) — 극장 좌석 수"] C1["몇 명이 들어가는가? (How many people fit?)"] C2["모델이 메모리에 올라가는가? 가중치(weights) + KV 캐시(KV cache)"] C1 --> C2 end subgraph Bandwidth["대역폭(Bandwidth) — 출입문 폭"] B1["1초에 몇 명이 들어가는가? (How many enter per second?)"] B2["토큰/초(tokens/sec) = 메모리 대역폭(mem bandwidth) / 모델 크기(model size)"] B1 --> B2 end Capacity --> Bandwidth

좌석이 모자라면 관객은 들어가지 못해요 — 모델이 메모리에 올라가지 않으면 추론 자체가 시작되지 않는다는 것과 같아요. 좌석이 충분해도 출입문이 좁으면 만석까지 한참 걸리고요 — 메모리 대역폭이 좁으면 토큰 생성이 느립니다. 좌석을 두 배로 늘려도 출입문 폭이 그대로면 입장 속도는 그대로예요. RAM을 256 GB 꽂아도 채널 수가 2개면 대역폭은 그대로인 것과 같은 이치입니다(아래 §"RAM 많이 꽂으면 되지 않나"에서 다시 다뤄요).

비유의 한계: 사람은 입장을 마치면 그 자리에 머물지만, 토큰 생성에서는 GPU가 매 토큰마다 모델 가중치 전체를 다시 읽어요. 즉 출입문은 한 번이 아니라 매 스텝 통과합니다. 이 사실은 곧이어 나오는 "왜 대역폭이 그대로 처리량 상한이 되는가"의 핵심이에요.

어떤 표를 봐야 하나

상황별로 우선 봐야 할 섹션이 달라요. 본문 표가 많으므로 시작점만 미리 정해 두면 길을 덜 잃어요.

flowchart TD Q["무엇이 알고 싶은가? (What do I want to know?)"] Q1["내 박스에 올라가나? (Will it fit on my box?) 로컬 실행, 사용자 1명"] Q2["토큰당 얼마나 빠른가? (How fast per token?) 단일 사용자 레이턴시(latency)"] Q3["동시에 몇 명? (How many users at once?) 서빙(serving) 처리량"] Q4["지금 사서 수년간 쓸까? (Buy now, run for years?) 장기 운영"] A1["용량(Capacity) 표 먼저 가중치(weights) + KV"] A2["대역폭(Bandwidth) 표 먼저 B / M 공식"] A3["대역폭 + 배칭(batching) 노트 vLLM 섹션"] A4["둘 다 + GB당 비용($/GB) 요약 플랫폼 비교"] Q --> Q1 --> A1 Q --> Q2 --> A2 Q --> Q3 --> A3 Q --> Q4 --> A4

대부분의 사용자는 첫 두 줄(용량 → 대역폭) 순서로 충분해요. 서빙·운영 단계로 가면 아래 두 줄이 추가됩니다.

미리 알아둘 훅: 같은 Llama-70B가 RTX 4090에서 ~12 tok/s, H100 SXM에서 ~60 tok/s로 갈리는 차이의 정체는 코어 개수도, TFLOPS도 아니에요. 대역폭 / 모델 크기 한 줄 공식으로 그대로 설명됩니다(아래 §대역폭 참고).

용량 — 모델이 메모리에 들어가는가

가중치 크기 (양자화별)

모델 파일을 메모리에 올리는 데 필요한 최소 용량은 **파라미터 수 × 정밀도(바이트)**예요.

**양자화(quantization)**를 적용하면 정밀도를 낮춰 크기를 줄일 수 있어요. llama.cpp / Ollama에서 가장 널리 쓰이는 방식은 Q4_K_M — 파라미터 하나당 약 0.6 bytes를 사용하는 4비트 양자화입니다.

양자화 = 모델의 수치를 덜 정밀하게 저장해 용량을 줄이는 기법. 품질은 약간 저하되지만 실사용 차이는 모델·작업에 따라 다름.

비유 하나 더 — 양자화는 책을 PDF 원본으로 보관할 것이냐, 인쇄본으로 보관할 것이냐의 차이에 가까워요. PDF(BF16)는 모든 픽셀을 살리지만 부피가 커요. 인쇄본(Q4)은 글자 굵기·해상도가 약간 떨어져도 같은 책 한 권은 그대로 들어 있어요. 인쇄본은 가방에 넣고 다닐 수 있고, PDF는 노트북을 열어야 하는 차이예요.

다음 표가 답하는 질문: "내 GPU/Mac 메모리에 이 모델이 어떤 정밀도까지 들어가는가?"

소형 (~10B 이하) — 소비자 GPU 단일 카드 영역

모델	파라미터	BF16	Q8_0	Q4_K_M	Q3_K_M	Q2_K
Llama 3.2 3B	3.2B	6.4 GB	3.4 GB	2.0 GB	—	—
Phi-4-mini	3.8B	~7.6 GB	~4.1 GB	~2.5 GB	—	—
Qwen3 4B	4.0B	8.0 GB	4.3 GB	2.4 GB	—	—
Qwen3 8B	8.2B	16.4 GB	8.7 GB	5.0 GB	—	—
Qwen3.5 9B	9.0B	~18 GB	9.6 GB	5.9 GB	—	—

중형 (14B~35B) — 워크스테이션 단일 카드 또는 Mac Studio 영역

모델	파라미터	BF16	Q8_0	Q4_K_M	Q3_K_M	Q2_K
Phi-4 14B	14.0B	~29 GB	15.6 GB	9.1 GB	—	—
Qwen3 14B	14.8B	29.6 GB	15.7 GB	9.0 GB	—	—
Gemma4 26B-A4B (MoE)	25.2B (3.8B active)	50.5 GB	26.9 GB	17.0 GB	—	—
Qwen3.6 27B	27.0B	53.8 GB	28.7 GB	17.5 GB	—	—
Gemma4 31B	30.7B	61.4 GB	32.6 GB	19.6 GB	—	—
GLM-4.7-Flash (MoE)	30B (3B active)	~60 GB	~32 GB	~18.5 GB	—	—
Nemotron Cascade 2 (MoE)	30B (3B active)	63.2 GB	33.6 GB	24.7 GB	—	—
Nemotron 3 Nano (MoE)	31.6B (3.2B active)	63.2 GB	33.5 GB	24.7 GB	—	—
Qwen3 32B	32.8B	65.6 GB	34.9 GB	19.9 GB	—	—
Qwen3.6 35B-A3B (MoE)	35B (3B active)	69.4 GB	36.9 GB	21.4 GB	—	—

대형 (70B~120B) — 멀티 GPU 또는 Mac Studio Ultra 영역

모델	파라미터	BF16	Q8_0	Q4_K_M	Q3_K_M	Q2_K
Llama 3.3 70B	70.6B	141 GB	75 GB	42.5 GB	34.3 GB	26.4 GB
Qwen3-Coder-Next (MoE)	~80B (3B active)	~160 GB	84.8 GB	48.7 GB	—	—
Llama 4 Scout (MoE)	109B (17B active)	216 GB	115 GB	65.4 GB	51.8 GB	39.6 GB
Mistral Small 4 (MoE)	119B (6B active, 8B w/ embed)	238 GB	126 GB	73.8 GB	54.4 GB	40.2 GB
Nemotron 3 Super (MoE)	120B (12B active)	~240 GB	128.5 GB	87.0 GB	—	—
Qwen3.5 122B-A10B (MoE)	122B (10B active)	~244 GB	129.9 GB	75.0 GB	—	—

초대형 (200B+) — 데이터센터 GPU 클러스터 또는 클라우드 영역

모델	파라미터	BF16	Q8_0	Q4_K_M	Q3_K_M	Q2_K
MiniMax M2.7 (MoE)	230B (10B active)	460 GB	244 GB	140 GB	104 GB	80 GB
Qwen3-235B-A22B (MoE)	235B (22B active)	~470 GB	~250 GB	~142 GB	—	—
DeepSeek-V4-Flash (MoE)	284B (13B active)	~568 GB	~302 GB	~172 GB	—	—
Qwen3.5 397B-A17B (MoE)	397B (17B active)	~794 GB	~422 GB	~241 GB	~194 GB	~166 GB
Llama 4 Maverick (MoE)	402B (17B active)	801 GB	426 GB	243 GB	191 GB	146 GB
Llama 3.1 405B	405B	810 GB	430 GB	245 GB	198 GB	—
DeepSeek-V3.1 (MoE)	671B (37B active)	1,342 GB	713 GB	407 GB	328 GB	281 GB
DeepSeek-R1-0528 (MoE)	671B (37B active)	1,342 GB	713 GB	407 GB	328 GB	281 GB
GLM-5.1 (MoE)	744B (40B active)	~1,488 GB	~790 GB	~451 GB	~363 GB	~310 GB
Kimi K2 / K2.5 (MoE)	~1,000B (32B active)	~2,050 GB	~1,090 GB	~580 GB	~490 GB	~420 GB
Kimi K2.6 (MoE)	1T (32B active, 384 experts)	~2,050 GB	~1,090 GB	~580 GB	~490 GB	~420 GB
DeepSeek-V4-Pro (MoE)	1.6T (49B active)	~3,200 GB	~1,700 GB	~970 GB	~780 GB	~670 GB

MoE 모델의 파라미터 수는 총합이에요. 추론 시 활성화되는 파라미터는 훨씬 작지만(Llama 4 Scout ~17B, Mistral Small 4 ~6B per token (8B w/ embedding/output), Llama 4 Maverick ~17B, DeepSeek ~37B), 가중치 전체를 메모리에 올려야 하므로 총 파라미터 기준 용량이 필요해요.

Llama 70B 가 양자화를 거치면 어떻게 줄어드나

가중치가 작을수록 decode 한 스텝당 읽어야 할 데이터가 줄어들어 토큰/초가 올라가요.

Q4가 BF16의 약 1/3이에요. 이 절약은 흔히 "VRAM 절약"으로 소개되지만, 실제 가치의 큰 비중은 대역폭 절약이에요. 이유는 다음 §대역폭에서 등장합니다.

Q4_K_M과 Unsloth Dynamic은 무엇이 다른가

Q4_K_M과 UD는 둘 다 가중치 양자화(weight quantization, 모델 파일 안 숫자 정밀도를 낮춰 크기를 줄이는 방법)예요. 둘 다 "모델 파일을 얼마나 작게 만들 것인가"의 문제를 다루고, 추론 중 생기는 KV 캐시(KV cache, 긴 대화 중 이미 계산한 attention 중간 결과를 저장하는 작업 메모리)를 직접 줄이는 기술은 아니에요.

차이는 압축을 고르는 방식이에요. Q4_K_M은 llama.cpp/GGUF 생태계에서 널리 쓰는 표준 4비트 K-quant(K-quant, GGUF에서 블록 단위로 숫자를 묶어 압축하는 양자화 계열) 포맷입니다. 대체로 같은 규칙을 넓게 적용해 파일 크기와 품질의 균형을 맞춰요. UD는 Unsloth Dynamic(Unsloth가 모델별·레이어별로 압축 강도를 다르게 고르는 양자화 방식)이고, 파일명에는 보통 UD-Q4_K_XL, UD-IQ4_NL_XL처럼 붙습니다.

비유하면 Q4_K_M은 모든 짐을 같은 압축팩에 넣는 방식이고, UD는 깨지기 쉬운 그릇은 완충재를 넣고 옷은 더 세게 누르는 이삿짐 포장 방식에 가까워요.

구분	줄이는 대상	선택 방식	읽는 법
`Q4_K_M`	모델 가중치	표준 4비트 K-quant 균형안	"대부분 모델에서 무난한 Q4"
`UD-Q4_K_XL` 등	모델 가중치	텐서(tensor, 모델 내부 숫자 덩어리)별 민감도에 따라 더 보수적/공격적 혼합	"Q4급 크기에서 민감한 부분을 더 살린 변형"
`q8_0/q4_0` KV	KV 캐시	런타임 옵션으로 단기 기억을 8비트/4비트 저장	"긴 대화의 작업 메모리 절약"
TurboQuant	KV 캐시	vector quantization(vector quantization, 비슷한 숫자 벡터를 대표 코드로 바꿔 저장하는 압축 방법) 기반 런타임 압축	"KV를 더 강하게 줄이는 실험적 선택지"

그래서 Q4_K_M vs UD와 표준 KV 양자화 vs TurboQuant는 서로 다른 층의 비교예요. 앞의 비교는 모델 파일을 줄이는 문제이고, 뒤의 비교는 긴 컨텍스트가 쌓일 때 생기는 작업 메모리를 줄이는 문제입니다. 두 기술은 같이 쓸 수도 있어요. 예를 들어 가중치는 UD-Q4_K_XL로 올리고, KV 캐시는 q8_0로 저장하는 식이에요.

더 자세한 설명과 선택 기준은 양자화와 KV 압축에서 다뤄요. 출처 메모: UD 계열 표기는 Unsloth Dynamic 2.0 공식 문서와 Hugging Face 컬렉션을 기준으로 정리했어요.

KV 캐시

가중치를 올린 뒤, 추론 중 KV 캐시가 추가로 쌓여요. 수식과 메커니즘은 파라미터 착시: KV 캐시의 진실에서 다룹니다.

다음 표가 답하는 질문: "32K 컨텍스트로 이 모델을 돌리면 가중치 외에 얼마가 더 필요한가?"

컨텍스트 크기별 KV 캐시 크기 (BF16 기준; Q8 양자화 시 약 절반). 모델이 지원하지 않는 컨텍스트는 —로 표기:

모델	32K	64K	128K	256K	최대 컨텍스트
Llama 3.2 3B	1.2 GB	2.4 GB	4.8 GB	—	128K
Phi-4-mini	4.0 GB	8.0 GB	16.0 GB	—	128K
Qwen3 4B	4.5 GB	9.0 GB	18.0 GB	—	128K
Qwen3.5 9B	~4.5 GB	~9.0 GB	~18.0 GB	~36.0 GB	262K
Qwen3 8B	4.5 GB	9.0 GB	18.0 GB	—	128K
Phi-4 14B	6.3 GB	—	—	—	16K (RoPE 확장 시 ~32K)
Qwen3 14B	5.0 GB	10.0 GB	20.0 GB	—	128K
Qwen3.6 27B	~2.0 GB	~4.0 GB	~8.0 GB	~16.0 GB	262K (DeltaNet 하이브리드, 64레이어 중 16만 표준 어텐션)
Gemma4:31b	~3.3 GB	~5.8 GB	~10.8 GB	~20.8 GB	256K (SWA 50 + Global 10, Hybrid)
GLM-4.7-Flash (MoE)	~5.0 GB	~10.0 GB	~20.0 GB	—	128K
Nemotron Cascade 2 (Mamba hybrid)	—	—	—	—	262K (Mamba 레이어는 KV 캐시 없음)
Nemotron 3 Nano (Mamba hybrid)	—	—	—	—	1M (Mamba 레이어는 KV 캐시 없음)
Qwen3 32B	8.0 GB	16.0 GB	32.0 GB	—	128K
Qwen3.6 35B-A3B (MoE)	~0.6 GB	~1.3 GB	~2.5 GB	~5.0 GB	262K native (YaRN 확장 시 ~1M, 40레이어 중 10만 표준 KV 캐시)
Llama 3.3 70B	10.0 GB	20.0 GB	40.0 GB	—	128K
Llama 3.1 405B	15.8 GB	31.6 GB	63.2 GB	—	128K
DeepSeek-V3.1/R1-0528	~2.0 GB	~4.0 GB	~8.0 GB	—	128K (MLA 압축)
GLM-5.1 (744B MoE, MLA)	~3.0 GB	~6.0 GB	~12.0 GB	—	203K (MLA 압축)
Kimi K2 / K2.5 (MoE)	~10.0 GB	~20.0 GB	~40.0 GB	—	K2 128K / K2.5 256K
Kimi K2.6 (MoE, MLA)	~3.0 GB	~6.0 GB	~12.0 GB	~24.0 GB	256K (MLA 압축)
DeepSeek-V4-Pro (MoE, CSA+HCA)	~0.3 GB	~0.6 GB	~1.2 GB	~2.4 GB	1M (~9.6 GiB, V3.2 대비 10% KV 캐시)

llama.cpp에서 -ctk q8_0 옵션으로 KV 캐시에도 Q8 양자화를 적용할 수 있어요.

MLA (Multi-head Latent Attention): DeepSeek가 처음 실용화한 뒤 GLM-5.1 등이 채용. KV를 저차원 잠재 벡터로 압축해 캐시하므로 671B·744B 모델임에도 KV 캐시가 표준 구조 대비 수십배 작아져요. 흔히 인용되는 "60배"는 동일 파라미터 수의 표준 MHA(Multi-Head Attention) 가설치 대비 비교치이고, 실제 GQA와 비교하면 보통 5–15배 영역(아래 깜짝 사실의 12배 비교가 그 예). 정확한 비율은 헤드 수·시퀀스 길이·잠재 차원에 따라 달라집니다. 상세 수식은 KV 캐시의 진실 §MLA.

깜짝 사실 1: DeepSeek-V4-Pro 같은 1.6T 파라미터 모델이 1M 컨텍스트를 켜도 KV 캐시가 약 9.6 GiB예요(batch 1, BF16 cache 기준). 1M 토큰에서 표준 70B 어텐션 모델이 수백 GB급 KV 캐시를 요구할 수 있다는 점을 생각하면, 모델 본체는 훨씬 큰데 단기 기억은 훨씬 작아지는 역전 현상이에요. 이 역전이 CSA+HCA 같은 어텐션 압축 기법이 등장한 이유예요.

실제 필요 용량 = 가중치 + KV 캐시

예시 — Llama 3.3 70B Q4_K_M, 32K 컨텍스트, KV Q8:

가중치: 42.5 GB
KV 캐시: 5.0 GB
합계: ~47.5 GB → M4 Max 128 GB에 여유 있게 수용, RTX 5090(32 GB)은 초과

대역폭 — 얼마나 빠르게 추론하는가

Decode 단계(토큰을 한 개씩 생성하는 구간)에서 GPU는 매 스텝마다 모델 가중치 전체를 메모리에서 읽어야 해요. 연산 코어(CUDA core, GPU shader)는 수조 번의 곱셈을 1초에 처리할 수 있지만, 메모리에서 데이터를 꺼내오는 속도 — 대역폭 — 가 그만큼 빠르지 않아요. 짐을 나르는 길이 좁으면 코어는 데이터를 기다리며 놀게 됩니다.

이 비대칭은 Arithmetic Intensity(산술 강도, 한 바이트의 데이터를 메모리에서 읽어다가 그 위에서 수행하는 부동소수점 연산 횟수의 비)라는 개념으로 정량화돼요. Decode의 batch=1 추론은 가중치 한 바이트당 곱셈이 1회 수준으로 매우 낮아요. 산술 강도가 1 미만으로 떨어지면 GPU의 compute 코어는 데이터를 기다리며 놀게 되고, 처리량은 전적으로 메모리 대역폭에 의해 결정됩니다 — 이것이 LLM decode가 "memory-bound"라고 불리는 이유예요.

깜짝 사실 2: H100의 FP16 연산 능력은 약 1,000 TFLOPS, 메모리 대역폭은 3,350 GB/s예요. 70B Q4 모델 한 토큰을 만들 때 필요한 연산은 약 70 GFLOPS, 메모리 읽기는 42.5 GB. 즉 연산은 0.07 ms, 메모리 읽기는 12.7 ms가 필요해요. 180배 차이. compute 코어는 매 토큰의 99.4% 시간을 놀고 있어요. "GPU가 너무 비싼 이유"는 사실 그 비싼 코어가 거의 일을 안 한다는 데에 있어요 — 하지만 일하는 그 짧은 순간에는 다른 어떤 것도 못 따라오죠.

토큰/초 추정 공식

토큰 생성 속도의 이론적 상한:

tokens/sec ≈ Memory Bandwidth (GB/s) / Model Size (GB)

분자가 GPU가 1초에 끌어올 수 있는 데이터 양, 분모가 한 토큰 만들 때 끌어와야 하는 데이터 양이에요. 이 두 숫자만 알면 GPU 코어 개수, 클럭, TFLOPS와 무관하게 토큰 생성 속도의 상한이 나와요.

다음 표가 답하는 질문: "Gemma4 31B BF16을 이 하드웨어에서 돌리면 토큰/초 상한이 얼마인가?"

Gemma4:31b (BF16, ~61 GB) 기준:

하드웨어	대역폭	이론 tok/s
데스크톱 PC DDR5 dual-ch	~100 GB/s	~1.6
Mac Studio M4 Max (546 GB/s 구성)	546 GB/s	~8.9
MacBook Pro M5 Max (40-core GPU)	614 GB/s	~10.1
Mac Studio M3 Ultra (M3 Max × 2)	819 GB/s	~13.4
NVIDIA H100 SXM (HBM3)	3,350 GB/s	~54

워크스루 — 토큰/초 직접 계산해 보기

  +--------------------------------------------------------------------------+
  | INPUT                                                                    |
  |   Memory bandwidth (B):   GB/s                                           |
  |   Model size on disk (M): GB  (weights, post-quantization)               |
  |                                                                          |
  | UPPER BOUND (decode-only, batch=1):                                      |
  |     tokens/sec  =  B / M                                                 |
  |                                                                          |
  | EXAMPLE: Llama-70B Q4 (M = 42.5 GB) on H100 SXM (B = 3,350 GB/s)         |
  |     ceiling  =  3350 / 42.5  ~=  78.8 tok/s                              |
  |     measured ~ 50-65 tok/s   (kernel/launch overhead, KV reads)          |
  |                                                                          |
  | SAME MODEL on M3 Ultra (B = 819 GB/s):                                   |
  |     ceiling  =  819 / 42.5   ~=  19.3 tok/s                              |
  +--------------------------------------------------------------------------+

같은 모델, 같은 양자화, 사용자 1명 — H100이 M3 Ultra보다 약 4배 빨라요. 가격은 H100 한 장이 $35,000, M3 Ultra Mac Studio가 $8,400 수준. 절대 속도당 비용은 H100이 더 좋지만, 대형 모델을 데스크톱에 두고 24/7 굴리겠다면 — 이 4배가 9~~12 tok/s인지 50~~65 tok/s인지가 사용자 체감에선 갈림길이에요.

양자화의 진짜 가치는 대역폭 절약

위 공식을 다시 보면 분모가 모델 크기예요. Q4로 양자화해서 모델 크기를 1/4로 줄이면, 같은 GPU에서 토큰/초가 이론적으로 4배 늘어납니다. 흔히 "양자화 = VRAM 아끼는 트릭"으로만 소개되지만, 더 본질적으로는 decode마다 읽어야 하는 바이트 수가 줄어드는 것 — 즉 대역폭 절약이 본체예요. VRAM 절약은 그 부수 효과고요.

이 사실 때문에 양자화가 가장 가치 있는 곳은 GPU VRAM이 빡빡한 환경(RTX 4090으로 70B 굴리기)보다, VRAM은 충분한데 대역폭이 모자란 환경 — 즉 Mac Studio에서 더 큰 모델 굴리기 — 예요.

데스크톱 PC에 RAM을 많이 꽂으면 되지 않나

안 돼요. 꽂는 용량과 대역폭은 별개예요.

소비자용 데스크톱 플랫폼은 메모리 채널이 2개예요. DDR5-6400 듀얼 채널 기준 최대 대역폭은 약 102 GB/s. 슬롯 4개를 모두 채워서 128 GB, 256 GB를 만들어도 채널 수는 그대로라서 대역폭은 그대로 ~100 GB/s예요.

flowchart TD subgraph Desktop["소비자 데스크톱 플랫폼(Consumer desktop) — DDR5 듀얼 채널"] A["DIMM A 64 GB · ~32 GB/s"] B["DIMM B 64 GB · ~32 GB/s"] CPU["CPU 합계 ~100 GB/s — 채널 수가 한계(channel count is the limit)"] A --> CPU B --> CPU end

용량은 늘어났지만, 데이터를 나르는 "도로 수"는 늘지 않았어요. 도로 폭(채널 수)이 그대로면 차(데이터)가 아무리 많아도 통과 속도는 똑같아요.

더 큰 문제는 GPU와의 관계예요. CPU 메모리에 올라간 모델 가중치를 GPU가 연산하려면 PCIe 버스를 경유해야 해요.

flowchart LR A["CPU RAM (DDR5)"] B["PCIe 5.0 x16 단방향 ~64 GB/s 병목(bottleneck)"] C["GPU VRAM (GDDR6X / HBM)"] A --> B --> C

PCIe 5.0 x16의 최대 단방향 대역폭은 약 64 GB/s예요(양방향 동시 합산 ~128 GB/s). GPU VRAM이 부족해서 CPU RAM에 일부를 offload하면, 그 부분은 PCIe 속도로 제한됩니다.

깜짝 사실: PCIe 5.0 x16의 단방향 64 GB/s는 H100 HBM3의 3,350 GB/s 대비 약 1.9%. "70B가 VRAM에 안 들어가서 절반만 GPU에 올렸다" 시나리오에서 이 1.9%가 그대로 체감되어, 50 tok/s가 1~2 tok/s로 떨어져요. **CPU offload는 "조금 느려진다"가 아니라 "거의 못 쓴다"**에 가까워요.

워크스테이션·서버 플랫폼은 다르다

AMD EPYC(8채널), Intel Xeon(8채널) 같은 서버 CPU는 채널 수가 많아요.

플랫폼	채널 수	DDR5-6400 기준 대역폭
소비자 데스크톱	2채널	~100 GB/s
워크스테이션 (Threadripper)	4채널	~200 GB/s
서버 (AMD EPYC 9004)	12채널	~576 GB/s

그러나 서버 CPU의 메모리는 여전히 PCIe를 거쳐야 GPU에 도달해요. GPU VRAM에 담기지 않는 모델을 CPU RAM에 offload하는 방식(llama.cpp의 --n-gpu-layers 부분 오프로딩)은 대역폭 손실이 심각합니다.

Apple Silicon이 다른 이유 — 통합 메모리 아키텍처 (UMA)

Apple Silicon은 CPU, GPU, Neural Engine이 같은 물리 메모리 풀을 공유해요. 별도의 GPU VRAM이 없는 대신, SoC 패키지 위에 LPDDR5/LPDDR5X를 직접 붙여 모든 코어가 동일한 고대역폭 메모리에 접근합니다.

flowchart TB subgraph Discrete["분리형 GPU(Discrete GPU) — PC + RTX/H100"] DCPU["CPU"] DRAM["DDR5 ~100 GB/s"] DPCIE["PCIe 5.0 x16 단방향 ~64 GB/s 오프로드(offload) 시 병목(BOTTLENECK)"] DGPU["GPU cores"] DVRAM["VRAM GDDR / HBM 500–8000 GB/s"] DCPU <--> DRAM DCPU --> DPCIE DPCIE --> DGPU DGPU <--> DVRAM end subgraph UMA["Apple Silicon — 통합 메모리 아키텍처(Unified Memory Architecture)"] UCPU["CPU cores"] UGPU["GPU cores"] UNE["Neural Engine"] UMEM["LPDDR5X 120–819 GB/s 단일 버스(single bus), PCIe 없음"] UCPU <--> UMEM UGPU <--> UMEM UNE <--> UMEM end

PCIe 전송이 없어요. GPU 코어가 동일한 버스로 전체 메모리를 직접 읽어요. 128 GB를 탑재한 M4 Max는 그 128 GB를 최대 546 GB/s 대역폭으로 GPU가 바로 사용합니다.

이 문서가 비교군으로 M4 Max · M3 Ultra · M5 Max 셋을 함께 쓰는 이유: Apple Silicon은 폼팩터별로 SoC가 분리되어 있어 "현역 한 칩"으로 좁혀지지 않아요. 각 칩이 차지하는 위치가 명확히 달라요.

M4 Max — 현역 Mac Studio 단일 다이. 데스크톱 폼팩터의 "기본 옵션". 24/7 sustained workload 가능.

M3 Ultra — 현역 Mac Studio 듀얼 다이(M3 Max × 2 + UltraFusion). 256 GB까지 가능한 "최대 메모리" 구성. M4 Ultra는 개발 취소되어 데스크톱 듀얼 다이는 여전히 M3 세대.

M5 Max — 현역 MacBook Pro 단일 다이. 가장 새 세대지만 노트북 전용 (Mac Studio M5는 2026 H1~10월 예정). 발열·배터리 제약으로 24/7 서버 용도엔 부적합하지만, 출장·임시 워크로드에는 데스크톱급 대역폭(614 GB/s) 제공.

즉 "Mac에서 로컬 LLM 돌릴 때"는 데스크톱이면 M4 Max ↔ M3 Ultra, 노트북이면 M5 Max가 현재의 선택지예요. M5 Mac Studio가 출시되면 이 표가 다시 갱신됩니다.

Apple Silicon에서 LLM 실행: llama.cpp vs MLX

Apple Silicon에서 LLM을 로컬로 돌리는 주요 방법이 두 가지예요.

	llama.cpp / Ollama	MLX (Apple 공식 ML 프레임워크)
UMA 활용	Metal backend로 부분 활용	설계 단계부터 UMA 네이티브
추론 속도	Apple Silicon에서 양호	Apple Silicon에서 더 빠른 경향 (체감 10-30%)
파인튜닝	제한적	LoRA 네이티브 지원 (양자화 모델도 가능)
모델 포맷	GGUF	HuggingFace safetensors 직접 지원
양자화	Q4_K_M 등 GGUF K-quant	4-bit / 8-bit / FP8 / INT8 등 네이티브
특징	크로스 플랫폼, 광범위한 커뮤니티	Apple Silicon 전용, 메모리 효율 최적

MLX는 Apple이 직접 만든 오픈소스 프레임워크로, CPU와 GPU가 같은 메모리 버스를 공유하는 UMA 구조를 코드 레벨에서 네이티브로 활용해요. mlx-lm 패키지 하나로 HuggingFace 모델 실행·양자화·LoRA 파인튜닝이 모두 가능합니다.

MLX 사용 예시

pip install mlx-lm

# 추론 (HuggingFace에서 모델 자동 다운로드)
mlx_lm.generate --model mlx-community/Qwen3.6-27B-4bit \
    --prompt "Explain attention mechanism" --max-tokens 500

# 양자화 (safetensors → 4-bit MLX 포맷)
mlx_lm.convert --hf-path Qwen/Qwen3.6-27B -q --q-bits 4

# LoRA 파인튜닝 (양자화된 모델에도 가능)
mlx_lm.lora --model mlx-community/Qwen3.6-27B-4bit \
    --train --data ./dataset --iters 1000

mlx-community/ 네임스페이스에는 주요 모델의 MLX 포맷 변환본이 사전 업로드되어 있어 별도 변환 없이 바로 실행 가능해요.

llama.cpp Metal 백엔드

llama.cpp는 GGML_METAL=1 빌드 옵션으로 Metal GPU 가속을 활성화해요 (Homebrew/pip 빌드에서는 기본 활성화).

# 소스 빌드 시
cmake -B build -DGGML_METAL=1
cmake --build build --config Release

# 실행
./llama-cli -m qwen3.6-27b-q4_k_m.gguf -ngl 999 -p "Hello"

-ngl 999 (모든 레이어를 GPU로 오프로드) 옵션으로 UMA 메모리에 올려 GPU 연산을 수행해요. Ollama는 내부적으로 llama.cpp + Metal을 쓰므로 별도 설정 없이 자동 활용됩니다.

실측 성능 비교 (M4 Max 128GB 기준)

모델 (Q4/4bit)	llama.cpp Metal	MLX 4-bit	비고
Qwen3.6 27B	~32 tok/s	~40 tok/s	MLX가 20-25% 빠름
Gemma4 31B	~28 tok/s	~35 tok/s	MLX 유리
Llama 3.3 70B	~12 tok/s	~15 tok/s	둘 다 대역폭 병목

절대값은 컨텍스트 길이·배치·프롬프트에 따라 ±20% 변동. MLX가 빠른 이유는 unified memory 접근 최적화 + Apple 자체 Metal Performance Shaders 튜닝.

선택 기준

추론만 필요, 크로스 플랫폼 공유: llama.cpp / Ollama (GGUF 파일 하나로 Mac·Linux·Windows 공유)
속도 우선, Mac 전용 서빙: MLX
파인튜닝 포함: MLX (양자화 모델에 LoRA 네이티브 지원)
GUI 필요: LM Studio (내부적으로 llama.cpp + MLX 둘 다 지원, 최근엔 MLX 우선)

Apple Silicon M 시리즈 전체 라인업

선택 기준 한 줄: 세대보다 다이 등급(Pro/Max/Ultra)이 대역폭을 결정해요. M 숫자(2/3/4/5)는 같은 등급 안에서 ~10–30% 차이를 만들 뿐, 등급이 한 단계 올라가면 대역폭이 거의 두 배로 뜁니다.

다음 표가 답하는 질문: "어떤 M 시리즈 칩이 어느 세대인지, 메모리 상한과 대역폭은 어떻게 되는지 한눈에 보고 싶다."

칩	출시	최대 메모리	메모리 대역폭
M1	2020	16 GB	68 GB/s
M1 Pro	2021	32 GB	200 GB/s
M1 Max	2021	64 GB	400 GB/s
M1 Ultra (M1 Max × 2)	2022	128 GB	800 GB/s
M2	2022	24 GB	100 GB/s
M2 Pro	2023	32 GB	200 GB/s
M2 Max	2023	96 GB	400 GB/s
M2 Ultra (M2 Max × 2)	2023	192 GB	800 GB/s
M3	2023	24 GB	100 GB/s
M3 Pro	2023	36 GB	150 GB/s
M3 Max (30-core GPU)	2023	128 GB	300 GB/s
M3 Max (40-core GPU)	2023	128 GB	400 GB/s
M3 Ultra (M3 Max × 2)	2025	256 GB (현재) / 512 GB (단종)	819 GB/s
M4	2024	32 GB	120 GB/s
M4 Pro	2024	64 GB	273 GB/s
M4 Max (32-core GPU)	2024	128 GB	410 GB/s
M4 Max (40-core GPU)	2024	128 GB	546 GB/s
M4 Ultra	—	—	—
M5	2025	32 GB	153 GB/s
M5 Pro	2026	64 GB	307 GB/s
M5 Max (32-core GPU)	2026	128 GB	460 GB/s
M5 Max (40-core GPU)	2026	128 GB	614 GB/s
M5 Ultra	출시 예정	—	—

Ultra 칩은 두 개의 Max 다이를 Apple의 UltraFusion 인터커넥트로 연결한 구성이에요. M4 Ultra는 개발 취소됐고, M5 Ultra가 Mac Studio에 탑재될 예정이에요.

2026-03 라인업 변경: Apple은 글로벌 메모리 칩 부족(AI 수요 압박)을 이유로 Mac Studio M3 Ultra 512 GB 옵션을 단종했어요. 동시에 256 GB 업그레이드 가격을 +$400 인상. 현재 M3 Ultra 구성 가능 최대 메모리는 256 GB. 일부 128 GB·256 GB 구성은 4-5개월 배송 지연 중.

NVIDIA 소비자용 GPU 라인업 (RTX 40 / 50 시리즈)

선택 기준 한 줄: VRAM 32 GB 이하라는 천장이 선결 조건이에요. Q4 양자화 30B급까지가 자연스러운 운용 범위이고, 그 이상은 멀티 카드 또는 다른 플랫폼으로 넘어가야 해요.

소비자 GPU의 VRAM은 전용 GDDR 메모리예요. 시스템 RAM과 완전히 분리된 별도 칩으로, 용량은 작지만 대역폭은 높습니다.

다음 두 표가 답하는 질문: "RTX 카드들 중에서 VRAM과 대역폭 조합이 어떻게 되는가, 가격은 얼마인가?"

RTX 40 시리즈 (Ada Lovelace, 단종 → 재고 유통 중)

모델	VRAM	메모리 타입	대역폭	시장가 (USD)
RTX 4070	12 GB	GDDR6X	504 GB/s	~$600–700
RTX 4070 Ti Super	16 GB	GDDR6X	672 GB/s	~$800–900
RTX 4080 Super	16 GB	GDDR6X	736 GB/s	~$1,000–1,100
RTX 4090	24 GB	GDDR6X	1,008 GB/s	~$2,500–3,000

RTX 50 시리즈 (Blackwell, 2025 현행)

모델	VRAM	메모리 타입	대역폭	MSRP (USD)	실거래가 (USD, 2026-04)
RTX 5060 Ti (16 GB)	16 GB	GDDR7	448 GB/s	$429	~$379–$599
RTX 5070	12 GB	GDDR7	672 GB/s	$549	~$629–$699
RTX 5070 Ti	16 GB	GDDR7	896 GB/s	$749	~$999–$1,169
RTX 5080	16 GB	GDDR7	960 GB/s	$999	~$1,200–$1,300
RTX 5090	32 GB	GDDR7	1,792 GB/s	$1,999	~$3,699–$3,899

RTX 50 시리즈는 GDDR7 채용으로 대역폭이 전 세대 대비 50–80% 향상됐어요. 전반적으로 MSRP를 크게 웃도는 실거래가가 지속되고 있어요. RTX 5090은 GDDR7 공급 부족 영향으로 MSRP($1,999) 대비 실거래가가 2배 가까이 형성되어 있고요 (2026-04 Amazon $3,899, Newegg $3,699 기준).

소비자 GPU의 결정적 한계: VRAM 용량 상한이 32 GB(RTX 5090)예요. BF16 기준 30B 모델(~60 GB)도 들어가지 않아요. Q4 양자화해서 15–20 GB로 줄이거나, 모델 자체를 작게 써야 합니다.

NVIDIA 전문가용 GPU (RTX PRO / 구 Quadro 라인)

소비자용(최대 32 GB)과 데이터센터(HBM, $30,000+) 사이의 공백을 채우는 라인이에요. GDDR 메모리를 쓰지만 ECC 지원·대용량 VRAM으로 워크스테이션·온프레미스 추론 서버에 적합해요.

모델	VRAM	메모리 타입	대역폭	가격 (USD)
RTX 4500 Ada	24 GB	GDDR6 ECC	432 GB/s	~$2,000–2,500
RTX 6000 Ada	48 GB	GDDR6 ECC	960 GB/s	~$7,800–10,000
RTX PRO 6000 Blackwell	96 GB	GDDR7 ECC	1,792 GB/s	~$8,000–9,300

"Quadro"는 2021년 NVIDIA RTX (Professional)로 리브랜딩됐고, 2025년부터 "RTX PRO" 이름을 사용해요. RTX PRO 6000 Blackwell은 96 GB로 RTX 5090의 3배 VRAM을 제공하고, Blackwell 아키텍처의 NVFP4까지 지원합니다.

LLM 관점: RTX 6000 Ada(48 GB)는 BF16 기준 30B 모델을 단일 카드에 올릴 수 있어요. RTX PRO 6000 Blackwell(96 GB)은 BF16 70B 모델도 단일 카드에 수용 가능합니다.

NVIDIA 데이터센터 GPU (H / B 시리즈)

선택 기준 한 줄: HBM 대역폭과 NVLink 통합 메모리 풀이 본질이에요. 단일 노드 80–288 GB · 3,350–8,000 GB/s 영역으로, 단가도 GB당 $200–500 영역에 들어가요 — 다중 사용자 서빙에서만 정당화됩니다.

VRAM으로 HBM(High Bandwidth Memory)을 사용해요. GDDR 대비 대역폭이 3–8배 높고, 용량도 80–180 GB에 달합니다. 가격도 그에 비례해요.

모델	VRAM	메모리 타입	대역폭	단가 (USD)
A100 40GB (구세대)	40 GB	HBM2	1,600 GB/s	~$10,000–12,000
A100 80GB (구세대)	80 GB	HBM2e	2,000 GB/s	~$15,000–17,000
H100 PCIe	80 GB	HBM2e	2,000 GB/s	~$27,000–35,000
H100 SXM	80 GB	HBM3	3,350 GB/s	~$30,000–40,000
H200 SXM	141 GB	HBM3e	4,800 GB/s	~$30,000–40,000
B200	192 GB	HBM3e	8,000 GB/s	~$30,000–55,000
B300 (Blackwell Ultra)	288 GB	HBM3e+	8,000 GB/s	~$40,000–50,000+ (출하 초기·시장가 변동 큼, 참고치)

A100은 2020년 출시로 구세대지만 여전히 클라우드·사내 서버에서 광범위하게 운용돼요. H100은 현재 클라우드 AI 서비스의 사실상 표준이고, B200은 2025년 투입 중이에요. B300(Blackwell Ultra)은 2026년 출하 중이고, B200과 대역폭은 동일하지만 메모리 용량이 288 GB로 대폭 증가해 대형 모델 추론에 특화됩니다.

SXM 폼팩터는 NVLink 연결을 통해 여러 GPU를 하나의 메모리 풀처럼 사용할 수 있어 대형 모델 서빙에 유리해요. PCIe 폼팩터는 일반 서버에 꽂을 수 있지만 GPU 간 대역폭이 낮아요.

NVIDIA 추론 스택: TensorRT-LLM / vLLM / llama.cpp

NVIDIA GPU에서 LLM을 돌리는 방식은 목적에 따라 세 갈래로 나뉘어요. 각각 서로 다른 문제를 풀어요.

TensorRT-LLM — 저지연·프로덕션

NVIDIA의 LLM 추론 전용 컴파일러·런타임이에요. 모델을 GPU별로 AOT(ahead-of-time) 컴파일해 kernel fusion·메모리 레이아웃·양자화를 극단적으로 최적화해요. 단일 요청 지연(latency)이 가장 중요한 프로덕션 API에서 사실상 표준이에요.

# 예: Llama 3.3 70B를 H100 2장에 맞춰 FP8 엔진으로 컴파일
trtllm-build --checkpoint_dir ./llama33_fp8_ckpt \
    --output_dir ./engines/llama33_fp8 \
    --gemm_plugin fp8 --use_paged_context_fmha enable \
    --max_batch_size 32 --max_input_len 8192

# 실행 (Triton Inference Server 또는 trtllm-serve 래퍼)
trtllm-serve --engine_dir ./engines/llama33_fp8

양자화 포맷별 대상 GPU:

포맷	비트	대상 GPU	특징
INT8	8비트 정수	모든 NVIDIA GPU	기준 양자화, 정확도·속도 균형
FP8	8비트 부동소수점	H100, RTX 4090+	정확도 손실 최소, H100에서 FP16 대비 ~2× 처리량
INT4 AWQ	4비트 정수 (블록 단위)	RTX 소비자 GPU 포함	소형 배치에서 FP8보다 낮은 지연, VRAM 절반
NVFP4	4비트 부동소수점 (NVIDIA 독자)	Blackwell (B200/B300)	FP8 대비 수학 처리량 ~2×, 메모리 절반

메모리 대역폭 관점: FP4는 같은 VRAM에서 FP16 대비 4배 많은 파라미터를 유효하게 처리해요. B300의 288 GB HBM3e + NVFP4 조합이 이전 세대 FP16 대비 모델 용량·처리량 모두 8× 이상 향상되는 이유예요.

vLLM — 고처리량·멀티 요청

UC Berkeley 출신 오픈소스 엔진. 동시 다수 요청 처리량(throughput) 최적화에 특화됐어요. 두 가지 핵심 기법이 있어요.

PagedAttention: KV 캐시를 OS 가상 메모리처럼 고정 크기 페이지로 쪼개 관리. 요청별로 다른 길이의 KV를 파편화 없이 메모리에 채워 넣어, 동일 VRAM에서 2-4배 많은 동시 요청을 담을 수 있어요.
Continuous Batching (연속 배칭): 기존엔 "배치 하나 끝날 때까지 대기"였다면, vLLM은 요청 단위로 매 스텝마다 배치를 재구성해요. 짧은 요청이 먼저 끝나고 빈 슬롯에 새 요청이 바로 들어갑니다.

pip install vllm

# 실행 (OpenAI 호환 API 서버)
vllm serve Qwen/Qwen3.6-27B --dtype bfloat16 \
    --tensor-parallel-size 2 --max-num-seqs 64

# 클라이언트 (OpenAI SDK 그대로 사용)
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen3.6-27B", "messages": [...]}'

vLLM은 같은 H100 한 장에서 TensorRT-LLM 대비 단일 요청 지연은 약간 높지만, 동시 요청 10개 이상일 때 전체 tokens/sec 처리량은 30-50% 높은 경향이 있어요. SaaS API 서비스, 챗봇 백엔드, 배치 추론에 적합합니다.

여기서 한 가지 더 — 대역폭 공식 tokens/sec = B / M은 batch=1 기준이었어요. 배치 N으로 동시 요청을 처리하면 가중치 한 번 읽기로 N개 요청에 대해 곱셈을 수행하므로 전체 throughput이 거의 N배까지 늘어나요 — arithmetic intensity가 1 → N으로 올라가면서 GPU compute 코어가 비로소 일하기 시작합니다. SaaS API가 유저당 비용을 낮출 수 있는 본질적 이유예요.

llama.cpp / Ollama — 로컬·개발

크로스 플랫폼 C++ 추론 엔진이에요. NVIDIA CUDA 빌드(GGML_CUDA=1)로 GPU 가속을 써요. 위 두 스택 대비 최적화는 낮지만 설치·실행 간편성, 모델 포맷(GGUF) 단일성이 강점이에요. Ollama는 llama.cpp 위에 관리 레이어를 얹은 구조예요.

선택 기준

목적	권장 스택	이유
단일 요청 저지연 (프로덕션 API)	TensorRT-LLM	kernel fusion으로 가장 낮은 latency
동시 다수 요청 (챗봇·SaaS)	vLLM	PagedAttention + continuous batching
로컬 개발·실험	llama.cpp / Ollama	설치 한 줄, GGUF 하나로 이동 가능
파인튜닝 + 추론 혼합	vLLM + PEFT (LoRA 지원)	HuggingFace 생태계 호환
Blackwell NVFP4 활용	TensorRT-LLM	NVFP4는 TRT-LLM에서만 full 지원

주의: TensorRT-LLM은 모델·GPU 조합마다 엔진을 다시 컴파일해야 해요. 모델 변경이 잦은 개발 단계에는 vLLM이 훨씬 편하고요. 프로덕션으로 굳어지면 TRT-LLM으로 전환해 지연을 줄이는 게 일반적인 패턴이에요.

기타 플랫폼 선택지

AMD ROCm

선택 기준 한 줄: VRAM당 가격이 NVIDIA 동급의 절반 수준이지만 추론 스택 성숙도는 1–2년 뒤처져 있어 — TensorRT-LLM 같은 NVIDIA 전용 기능이 필요 없는 경우에 한해 유효해요.

AMD GPU(RDNA 3 / CDNA 시리즈)에서 LLM을 구동하는 오픈소스 스택이에요. **ROCm (Radeon Open Compute)**은 NVIDIA의 CUDA에 대응하는 AMD의 GPU 컴퓨팅 플랫폼이고요. 가성비 면에서 강점(W7900이 RTX 6000 Ada 대비 VRAM 동급이지만 가격 절반)이지만, 생태계 성숙도는 CUDA 대비 1-2년 뒤처져 있어요.

AMD 전문가용 GPU 라인업 (Radeon Pro)

모델	VRAM	메모리 타입	대역폭	가격 (USD)
Radeon Pro W7800	32 GB	GDDR6 ECC	576 GB/s	~$2,500
Radeon Pro W7900	48 GB	GDDR6 ECC	864 GB/s	~$3,499
Radeon AI PRO R9700	32 GB	GDDR6	640 GB/s	~$1,299

Radeon Pro W7900은 48 GB ECC GDDR6로 RTX 6000 Ada와 동급 VRAM이지만 가격이 절반 수준이에요. Radeon AI PRO R9700은 2025-07 출시된 RDNA4 기반 AI 특화 모델로 MSRP $1,299에 책정됐고, 32 GB VRAM과 W7800 수준 대역폭을 절반 이하 가격에 제공해요.

ROCm 지원 추론 스택 현황 (2026-04):

llama.cpp HIP 백엔드: 가장 성숙. GGML_HIPBLAS=1로 빌드. GGUF 포맷 그대로 사용. 실측 성능은 같은 대역폭의 NVIDIA GPU 대비 70-85% 수준.
vLLM ROCm: 공식 지원. RDNA3/CDNA2 이상. MI300X(192 GB HBM3) 기준 H100 대비 동급 처리량 보고 사례 있음. 단, 양자화 포맷 일부 제한 (AWQ 일부 미지원).
PyTorch ROCm: 2.5+에서 안정화. HuggingFace Transformers 대부분 그대로 동작하지만 FlashAttention 같은 일부 커널은 CUDA 전용.
TensorRT-LLM: 미지원 (NVIDIA 독점).

W7900 실측 (Qwen3.6 27B Q4, llama.cpp HIP): ~25-30 tok/s. 같은 모델이 RTX 4090(대역폭 1,008 GB/s)에서 ~35-40 tok/s, RTX 5090(1,792 GB/s)에서 ~60 tok/s 수준.

Intel OpenVINO + NPU

OpenVINO: Intel이 만든 "CPU·iGPU·NPU 통합 추론 런타임"이에요. ONNX 또는 PyTorch 모델을 OpenVINO IR(중간 표현)로 변환해 Intel 칩에 최적화된 커널로 실행해요.

Intel Core Ultra (Meteor Lake / Lunar Lake / Arrow Lake) 프로세서에 내장된 **NPU(Neural Processing Unit)**는 별도 전력 라인을 쓰고, CPU/GPU를 쉬게 하면서 AI 추론을 저전력으로 수행해요. OpenVINO 2026은 7B 이하 모델에서 attention 레이어를 NPU로 오프로드해 GPU 단독 대비 최대 3.8× 처리량 보고가 있고요.

pip install openvino-genai

# HuggingFace 모델을 OpenVINO IR로 변환
optimum-cli export openvino --model Qwen/Qwen3-8B \
    --weight-format int4 ./qwen3-8b-ov

# 실행 (자동으로 가용한 NPU/GPU/CPU 선택)
python -c "
from openvino_genai import LLMPipeline
pipe = LLMPipeline('./qwen3-8b-ov', 'NPU')  # 또는 'GPU', 'CPU', 'AUTO'
print(pipe.generate('What is attention?', max_new_tokens=200))
"

대형 모델(30B+)은 NPU로 올리기엔 용량 부족이에요. 노트북/미니 PC의 엣지 LLM 시나리오(개인 비서, 로컬 RAG)에 적합해요. 최근 Copilot+ PC의 로컬 AI 기능 대부분이 이 스택 기반이에요.

모바일·엣지 NPU (Qualcomm / Samsung / MediaTek)

ARM ISA 기반 모바일 SoC들은 대부분 유사한 전략을 써요 — CPU + GPU + 전용 NPU를 한 칩에 통합해 AI 추론을 저전력으로 처리. LLM 관점에서는 세 제조사가 사실상 같은 카테고리예요.

제조사	대표 칩	NPU 성능	주요 시장
Qualcomm	Snapdragon X2 Elite (PC), 8 Gen 4 (모바일)	75-85 TOPS	AI PC, Android 플래그십
Samsung	Exynos 2500	~60 TOPS	갤럭시 일부 지역
MediaTek	Dimensity 9400	~50 TOPS	중국·동남아 Android 주력

추론 스택 현황:

Qualcomm QNN SDK (AI Engine Direct): Qualcomm 독자 런타임. PyTorch/ONNX → QNN 변환. 가장 성숙한 모바일 LLM 스택.
MediaTek NeuroPilot: MediaTek 독자 SDK. 자체 변환 툴체인.
Samsung Exynos NPU SDK: 상대적으로 오픈 생태계 빈약. 갤럭시 자체 기능에 주로 쓰임.
llama.cpp 모바일 포팅 (LLMfarm, ChatterUI 등): 세 제조사 모두에서 CPU+GPU 경로로 실행 가능하지만, NPU 가속은 제한적. 대부분 CPU/GPU에서 Q4_0 기준 실행.

실측 (Q4, 7B 이하):

Snapdragon X Elite + Llama 3.2 3B (Q4): ~15-20 tok/s, 배터리 구동 가능
Dimensity 9400 + Qwen3 4B (Q4): ~10-15 tok/s
Exynos 2500 + 유사 모델: ~8-12 tok/s

데이터센터·워크스테이션과는 맥락이 다르지만, 배터리 구동 AI PC·스마트폰에서 LLM을 돌리는 현실적 선택지예요. 2026년 기준 아이폰·갤럭시 최신 플래그십도 유사한 NPU 가속 구조로 3-7B 모델의 온디바이스 실행이 표준이 되는 중이에요.

서버용 ARM (NVIDIA Grace, Ampere Altra, AWS Graviton): ARM ISA 기반 서버 CPU. 주로 일반 컴퓨팅·클라우드 인프라 용도이고, LLM 추론은 여전히 같은 시스템에 연결된 GPU가 담당. 이 노트의 범위(로컬 LLM 구동)에서는 우선순위 낮음.

플랫폼별 추천 추론 스택 요약

하드웨어	최적 스택	비고
Apple Silicon (Mac)	MLX (속도) 또는 llama.cpp (호환성)	UMA 덕분에 128GB까지 단일 노드 가능
NVIDIA H100/B200 (데이터센터)	TensorRT-LLM (지연) + vLLM (처리량)	양자화는 FP8/NVFP4
NVIDIA RTX 소비자 GPU	vLLM (소규모 서빙) / llama.cpp (개발)	RTX 5090 32GB 이하는 양자화 필수
AMD Radeon Pro	llama.cpp HIP, vLLM ROCm	CUDA 전용 기능 불가 확인 필요
Intel Core Ultra NPU (Lunar Lake 48 TOPS / Panther Lake)	OpenVINO 2026.1 GenAI (NPU speculative decoding · llama.cpp backend)	엣지·노트북 7B 이하, NPU에 MiniCPM-o-2.6 / Qwen2.5-1.5B / Qwen3-Embedding
Qualcomm Snapdragon X2 Elite/Extreme (Hexagon NPU 80 TOPS, FP8/BF16)	QNN SDK · QNN Execution Provider (ONNX Runtime)	AI PC, 30B+ 가능. 18-core Oryon CPU, 192-bit/228 GB/s 메모리
Samsung/MediaTek 모바일 NPU	NeuroPilot / llama.cpp 포팅	모바일·엣지, 7B 이하

플랫폼 종합 비교 — 대역폭 · 용량 · 가격

다음 표가 답하는 질문: "예산 X 달러로 살 수 있는 후보들의 메모리·대역폭·GB당 비용은 각각 어떤가?"

하드웨어	GPU 메모리	대역폭	가격 (USD)	$/GB
Mac mini M4 (32 GB)	32 GB UMA	120 GB/s	~$1,099	~$34
Mac Studio M4 Max (128 GB, 1TB SSD)¹	128 GB UMA	546 GB/s	~$3,499	~$27
MacBook Pro M5 Max (128 GB)	128 GB UMA	614 GB/s	~$3,999	~$31
Mac Studio M3 Ultra (96 GB base, 1TB SSD)	96 GB UMA	819 GB/s	$3,999	~$42
Mac Studio M3 Ultra (256 GB max, 1TB SSD)²	256 GB UMA	819 GB/s	~$8,400	~$33
~~Mac Studio M3 Ultra (512 GB)~~	—	—	— (단종)	2026-03 단종
RTX 5060 Ti (16 GB)	16 GB GDDR7	448 GB/s	~$450 실거래	~$28
RTX 5070 Ti	16 GB GDDR7	896 GB/s	~$1,080 실거래	~$68
RTX 5080	16 GB GDDR7	960 GB/s	~$1,250 실거래	~$78
RTX 5090	32 GB GDDR7	1,792 GB/s	~$3,800 실거래	~$119
AMD Radeon AI PRO R9700	32 GB GDDR6	640 GB/s	~$1,299	~$41
AMD Radeon Pro W7900	48 GB GDDR6 ECC	864 GB/s	~$3,499	~$73
RTX 6000 Ada	48 GB GDDR6 ECC	960 GB/s	~$7,800	~$163
RTX PRO 6000 Blackwell	96 GB GDDR7 ECC	1,792 GB/s	~$8,500	~$89
NVIDIA H100 SXM	80 GB HBM3	3,350 GB/s	~$35,000	~$437
NVIDIA H200 SXM	141 GB HBM3e	4,800 GB/s	~$42,000	~$298
NVIDIA B200	192 GB HBM3e	8,000 GB/s	~$45,000+	~$234

¹ M4 Max 128GB 1TB SSD 구성 가격은 Apple Store 직접 확인이 차단되어 retailer 인용가 기준의 추정. CDW·Best Buy·Micro Center 모두 공시 가격 미게재 상태. ² M3 Ultra 256GB 가격은 base $3,999 + 28→32-core CPU/60→80-core GPU 업그레이드 + 96→256GB RAM 업그레이드(2026-03 +$400 인상 반영)로 산정한 추정. Apple Store 직접 확인 차단.

읽는 법:

대역폭 → 같은 모델 크기 기준 토큰 생성 속도에 비례
용량 → 얼마나 큰 모델을 올릴 수 있는가의 상한
$/GB → 메모리 용량당 비용 (낮을수록 저렴)

Apple Silicon의 강점은 용량 대비 가격이에요. H100 대비 GB당 비용이 10–15배 저렴하고, PCIe 병목이 없어요. 단, 절대 대역폭은 H100의 약 1/6 수준이에요.

RTX 5090은 $/GB 기준으로 가장 비싸지만 32 GB에 1,792 GB/s라는 조합이 소형 모델의 빠른 추론에 최적이에요. 문제는 32 GB를 넘는 모델을 올릴 수 없다는 점이고요.

실무 시사점 — 모델 크기에 따른 하드웨어 선택

다음 표가 답하는 질문: "내가 굴리려는 모델 크기에 맞는 하드웨어 후보가 어디까지인가?"

운용 모델 크기	권장 하드웨어 (데스크톱)	권장 하드웨어 (노트북)	이유
~20 GB 이하 (Q4 30B급)	RTX 5090 (~$2,000 MSRP / 실거래 ~$3,800)	MacBook Pro M5 Max 64 GB	VRAM에 딱 들어감, 대역폭 충분
~60 GB (BF16 30B급)	Mac Studio M4 Max 128GB (~$3,500)	MacBook Pro M5 Max 128GB (~$4,000)	UMA 덕분에 PCIe 병목 없음
~140 GB (BF16 70B급)	Mac Studio M3 Ultra 256GB (~$8,400, 2026-03 단종 후 최대)	(불가, 노트북 메모리 상한)	RTX 단일 카드로는 불가, M3 Ultra만 수용
~400 GB+ (대형 MoE)	H100 80GB × 다중 / B200	(불가)	소비자 장비로는 수용 불가

하드웨어별 포지셔닝 요약:

RTX 5090: 소형 모델 빠른 추론에 최적이에요. 32 GB 상한이 아킬레스건이고요.
Apple M4 Max / M3 Ultra (Mac Studio): 큰 모델을 데스크톱에서 24/7 돌리는 현실적 소비자 선택지예요. 속도는 H100의 1/6이지만 가격은 1/10.
Apple M5 Max (MacBook Pro): 가장 새 세대 단일 다이지만 노트북 한정이에요. 발열·배터리 제약으로 24/7 sustained 워크로드엔 부적합 — 출장·임시 추론에 한정.
NVIDIA H100/H200/B200: 속도·용량 모두 압도적. 비용도 압도적이에요. 클라우드 API 서비스 제공자 또는 연구소 수준의 선택지예요.

사내 온프레미스 추론 서버를 구성한다면, 현실적 선택지는 (노트북은 서버 부적합으로 제외):

소규모: Mac Studio M4 Max (128 GB, ~$3,500) × N대 병렬
중규모: Mac Studio M3 Ultra (256 GB max, ~$8,400) — 2026-03 512GB 단종 이후 단일 노드 최대 용량
대규모: NVIDIA H100 클러스터 (예산 ×10–100)

소형 모델의 instruction following 한계

모델 크기는 "VRAM에 올라가는가"만의 문제가 아니에요. 지시를 실제로 따르는가도 선택 기준이에요.

작은 모델에서 자주 나타나는 패턴이에요.

지시 무시: 시스템 프롬프트의 제약 조건을 넘어 엉뚱한 출력을 냄
컨텍스트 희석: 대화가 길어질수록 앞의 지시에 대한 attention이 약해져 초기 설정을 잊음
형식 민감도: 프롬프트 형식이 학습 패턴과 조금만 달라도 지시를 일반 텍스트로 처리

원인은 pre-training 용량 부족, RLHF 보상 신호 약함, attention 희석이 겹친 결과예요.

작업 유형	최소 권장 크기
단순 Q&A, 요약	7B 이상
역할·형식·제약이 있는 지시	14B 이상
도구 호출·멀티스텝 에이전트	30B 이상

관련 — 경량 모델의 빠른 발전: 위 한계가 완화되는 추세도 있어요. 2026년 현재 경량 모델이 벤치마크 점수 기준으로 과거 대형 모델을 따라잡는 현상이 뚜렷해요. 자세한 내용은 397B를 이긴 27B: 경량 모델이 대형 모델을 따라잡는 이유 참조.