"AI 를 로컬에서 돌린다" 고 할 때 실제로는 성격이 다른 두 가지가 섞여 있다.
| 하는 일 | 자원 요구 |
|---|---|
| 에이전트 · 오케스트레이션 — 명령을 해석해 도구를 부르고 결과를 엮는다 | 가볍다. CPU 몇 %, 메모리 수백 MB |
| 추론(inference) — 모델이 직접 토큰을 생성한다 | 무겁다. 메모리 대역폭에 달려 있다 |
에이전트 프레임워크(OpenClaw · n8n · LangChain 류)를 돌리면서 추론은 외부 API 에 맡기는 구성이라면 저전력 미니 PC 로 충분하다. 병목은 전적으로 API 응답 시간이다.
반대로 추론까지 그 장비에서 하려 하면 이야기가 완전히 달라진다.
토큰 하나를 만들 때마다 모델 가중치 전체를 메모리에서 읽어야 한다. 그래서 CPU 추론의 속도 상한은 코어 수나 클럭이 아니라 메모리 대역폭이 정한다. 거칠게는 이렇게 어림한다.
초당 토큰 수 ≈ 유효 메모리 대역폭(GB/s) ÷ 모델 크기(GB)
이 어림으로 대략의 기대치를 미리 계산할 수 있다.
| 구성 | 대역폭(이론) | 7B Q4 (약 4.5GB) 기대치 |
|---|---|---|
| 싱글 채널 DDR5-4800 (저전력 미니 PC) | 약 38GB/s | 유효 대역폭을 절반으로 잡으면 초당 몇 토큰 수준 |
| 듀얼 채널 DDR5-5600 (데스크톱) | 약 90GB/s | 위의 두 배가량 |
| 통합 메모리 (Apple Silicon 상위) | 200~800GB/s | 훨씬 빠르다 |
| GPU VRAM (GDDR6 · HBM) | 300GB/s~ | 자릿수가 다르다 |
저전력 미니 PC 계열 CPU 는 메모리 채널이 하나인 경우가 많다. 코어를 늘리거나 램을 32GB 로 키워도 채널이 하나면 속도는 그대로다. 램 용량은 "그 모델이 올라가느냐" 를 정하고, 대역폭은 "얼마나 빨리 나오느냐" 를 정한다. 둘은 다른 문제다.
양자화는 가중치의 비트 수를 줄여 모델 크기를 줄인다. 크기가 줄면 읽어야 할 바이트가 줄고, 그만큼 빨라진다.
| 양자화 | 7B 모델 대략 크기 | 품질 |
|---|---|---|
| FP16 | 약 14GB | 원본 |
| Q8_0 | 약 7.5GB | 차이를 느끼기 어렵다 |
| Q5_K_M | 약 5GB | 대부분의 용도에 충분 |
| Q4_K_M | 약 4.5GB | 실용적인 하한. 일반적인 선택 |
| Q3 이하 | 더 작다 | 품질 저하가 눈에 띈다 |
Q4 아래로 내려가는 것보다, 더 작은 모델의 높은 양자화를 쓰는 편이 대개 낫다. 13B Q3 보다 7B Q5 가 쓸 만한 경우가 많다.
대역폭이 두 배가 되므로 7B 급이 실용 범위에 들어온다. 동시 사용자가 없다면 쓸 만하다.
VRAM 에 모델이 통째로 올라가면 자릿수가 달라진다. 7B Q4 는 8GB VRAM 에 들어간다. 로컬 추론을 진지하게 하려면 여기가 출발선이다. VRAM 에 다 안 올라가 일부가 시스템 메모리로 넘어가면(오프로딩) 속도가 급격히 떨어진다.
위 표는 어림이다. 실제 장비에서 재는 것이 언제나 낫다. llama.cpp 계열은 벤치마크 도구를 함께 제공한다.
# ollama
ollama run llama3.2:3b --verbose
# 응답 끝에 eval rate (tokens/s) 가 찍힌다
# llama.cpp
llama-bench -m model-Q4_K_M.gguf -p 512 -n 128
prompt eval(입력 처리)과 eval(생성)을 따로 본다. 입력 처리는 연산 중심이라 코어 수의 영향을 받고, 생성은 대역폭 중심이다. 긴 문서를 넣는 용도라면 입력 처리 속도가 더 중요할 수 있다.