와트당 지능 — 로컬 AI 추론 효율을 측정하는 법 | 기술노트

로컬에서 언어 모델을 돌릴 때 성능을 말하는 방식은 대개 "초당 몇 토큰"이다. 하지만 이 숫자 하나로는 비교가 안 된다. 입력 길이, 배치 크기, 양자화 수준, 컨텍스트 길이에 따라 몇 배씩 달라지기 때문이다. 게다가 노트북·휴대폰·엣지 기기에서는 전력이라는 제약이 함께 걸린다.

그래서 필요한 게 와트당 지능(intelligence per watt)이라는 관점이다. 같은 전력으로 얼마나 쓸 만한 출력을 내는가. 이 관점으로 보면 하드웨어 선택과 모델 선택의 기준이 달라진다.

노트북에서 로컬 모델을 처음 돌렸을 때 나는 토큰 생성 속도만 봤다. 그런데 30분쯤 쓰다 보니 팬이 최대로 돌고 배터리가 급격히 줄었다. 성능은 나쁘지 않은데 실사용이 불가능했다. 그때 깨달았다. 온디바이스 추론의 실제 제약은 속도가 아니라 지속 가능한 전력 범위 안에서의 속도다.

프리필과 디코드는 완전히 다른 작업

추론은 두 단계로 나뉘고, 각 단계의 병목이 다르다. 이 구분을 모르면 측정도 최적화도 방향을 잃는다.

단계	하는 일	병목	특성
프리필(prefill)	입력 프롬프트를 한 번에 처리	연산(compute)	병렬화가 잘 됨, 배치 효과 큼
디코드(decode)	토큰을 하나씩 생성	메모리 대역폭	순차적, 가중치를 매 토큰마다 읽음

왜 대역폭이 병목인가 디코드 단계에서는 토큰 하나를 만들 때마다 모델 가중치 전체를 읽어야 한다. 7B 모델을 4비트로 양자화하면 약 4GB이고, 초당 20토큰을 내려면 초당 80GB를 읽어야 한다. 이것이 대부분의 소비자 하드웨어에서 속도 상한을 결정한다.

# 이론적 상한 추정 (디코드)
#   최대 토큰/초 ≈ 메모리 대역폭 / 모델 크기
#
#   예) 대역폭 200GB/s, 4비트 7B 모델(약 4GB)
#       → 200 / 4 = 초당 최대 50토큰 (이론치)
#       실제로는 KV 캐시 읽기·쓰기, 오버헤드로 이보다 낮다
#
# 이 계산이 의미하는 것:
#   - 연산 성능(TFLOPS)을 올려도 디코드는 거의 안 빨라진다
#   - 모델을 작게(양자화) 만들면 비례해 빨라진다
#   - 배치를 키우면 같은 가중치 읽기로 여러 요청을 처리해 효율이 오른다

무엇을 측정할 것인가

최소한 함께 기록할 지표

✓첫 토큰까지 시간(TTFT) — 프리필 성능. 대화형 UX에서 체감이 가장 큰 값

✓토큰 생성 속도(TPS) — 디코드 성능. 평균과 함께 변동 폭도 기록

✓입력 길이와 출력 길이 — 이걸 안 적으면 비교가 불가능하다

✓배치 크기 — 서버와 온디바이스는 여기서 갈린다

✓평균 소비 전력(W)과 최대 온도 — 지속 성능을 좌우

✓메모리 사용량 — 가중치 + KV 캐시 + 활성값

✓양자화 수준과 사용 커널 — 같은 모델도 구현에 따라 다르다

# 비교 가능한 형태로 남기는 기록 예시
model: qwen-7b-instruct
quant: Q4_K_M
runtime: llama.cpp b4xxx (Metal)
device: MacBook Air M-series 16GB
prompt_tokens: 1024
gen_tokens: 256
batch: 1
ttft_ms: 820
tps: 23.4
avg_power_w: 18.2
peak_temp_c: 82
mem_peak_gb: 5.8
tokens_per_joule: 1.29      # = tps / avg_power_w

# tokens_per_joule 이 와트당 지능의 조야한 대리 지표다.
# "같은 배터리로 몇 토큰을 만들 수 있나"에 직접 대응한다.

지속 성능 — 벤치마크가 숨기는 것

짧은 벤치마크는 기기가 부스트 상태일 때의 숫자를 보여 준다. 실사용에서는 몇 분 뒤 열 제한(thermal throttling)이 걸리며 속도가 내려간다. 노트북과 휴대폰에서 이 격차는 크다.

워밍업 구간 제외

첫 수십 토큰은 캐시·컴파일 효과로 빠르거나 느리다.

최소 5분 이상 연속 실행

열이 쌓이고 클럭이 안정되는 구간까지 간다.

구간별 TPS 기록

1분 단위로 나눠 기록하면 하락 곡선이 보인다.

전원 연결 여부 구분

배터리 모드에서는 전력 상한이 낮아 성능이 다르다.

백그라운드 부하 통제

다른 앱이 돌면 결과가 흔들린다.

결과를 보면 "최고 속도 35토큰/초"가 실제로는 "5분 뒤 22토큰/초"인 경우가 흔하다. 어느 숫자를 제품 설계 기준으로 삼을 것인가가 중요하다. 답은 당연히 후자다.

효율을 올리는 수단들

수단	효과	비용
양자화(4비트 등)	가중치 크기 감소 → 디코드 속도·전력 개선	품질 저하(작업별로 다름)
KV 캐시 양자화	긴 컨텍스트에서 메모리·대역폭 절감	긴 대화에서 품질 영향 가능
스페큘러티브 디코딩	작은 모델로 초안, 큰 모델로 검증	메모리 추가 사용, 수용률 의존
배치 처리	같은 가중치 읽기로 여러 요청 처리	지연 증가, 온디바이스에서는 기회 적음
프롬프트 캐싱	반복되는 접두 프롬프트의 프리필 생략	캐시 메모리 사용
더 작은 모델	모든 지표 개선	능력 저하 — 작업 적합성 검증 필요

마지막 항목이 종종 가장 좋은 답이다. 3B 모델로 충분한 작업에 7B를 쓰는 경우가 많다. 분류·추출·요약 같은 작업은 작은 모델로도 잘 되며, 속도·전력·메모리가 전부 좋아진다. 모델 크기를 줄이는 것이 가장 강력한 최적화인 경우가 흔하다.

하드웨어 선택 기준

로컬 추론용 하드웨어를 고를 때 흔히 연산 성능을 본다. 하지만 디코드가 대역폭 병목이라면 우선순위가 달라진다.

메모리 용량 — 모델이 안 올라가면 나머지는 의미 없다. 가중치 + KV 캐시 + 여유를 계산한다.
메모리 대역폭 — 디코드 속도의 상한을 결정한다. 통합 메모리 구조에서는 이 값이 특히 중요하다.
전력 예산과 냉각 — 지속 성능을 좌우한다. 얇은 기기는 부스트가 짧다.
연산 성능 — 프리필과 큰 배치에서 의미가 있다. 긴 문서를 자주 처리한다면 중요도가 올라간다.
소프트웨어 지원 — 최적화 커널이 없으면 하드웨어 스펙은 종이일 뿐이다.

실무 조언 스펙표 비교보다 실제 모델로 5분 돌려 보는 것이 훨씬 정확하다. 가능하면 구매 전에 같은 모델·같은 양자화로 벤치마크를 구해 비교하고, 그 벤치마크가 지속 실행 조건에서 측정된 것인지 확인하자.

자주 묻는 질문

로컬 추론 속도는 무엇이 결정하나요?

토큰을 생성하는 디코드 단계는 메모리 대역폭이, 프롬프트를 처리하는 프리필 단계는 연산 성능이 주된 병목입니다. 대화형 사용에서는 디코드가 지배적이므로 대역폭과 모델 크기가 속도를 좌우합니다.

토큰/초만 보면 안 되는 이유는 무엇인가요?

입력 길이, 출력 길이, 배치 크기, 양자화 수준, 측정 시간에 따라 크게 달라지기 때문입니다. 또한 짧은 측정은 열 제한이 걸리기 전의 값이라 실사용 성능을 과대평가합니다. 조건을 함께 기록해야 비교가 성립합니다.

와트당 지능은 어떻게 계산하나요?

간단한 대리 지표로 토큰 생성 속도를 평균 소비 전력으로 나눈 값(토큰/줄)을 쓸 수 있습니다. 여기에 작업 성공률 같은 품질 지표를 곱해 보정하면, 같은 전력으로 얻는 실제 가치를 비교할 수 있습니다.

양자화하면 품질이 얼마나 떨어지나요?

작업에 따라 다릅니다. 분류·추출·요약은 4비트에서도 실용적인 경우가 많지만, 복잡한 추론이나 코드 생성은 저하가 눈에 띌 수 있습니다. 자체 골든 세트로 비교 측정해 허용 범위를 직접 정하세요.

긴 컨텍스트를 쓰면 왜 느려지나요?

KV 캐시가 커지면서 메모리 사용과 읽기 양이 함께 늘기 때문입니다. 컨텍스트가 길어질수록 KV 캐시가 가중치보다 큰 비중을 차지할 수 있으므로, KV 캐시 양자화나 컨텍스트 관리 전략을 함께 검토해야 합니다.

어떤 하드웨어를 골라야 하나요?

먼저 모델이 올라갈 메모리 용량을 확보하고, 그다음 메모리 대역폭을 봅니다. 노트북·휴대폰처럼 전력과 냉각이 제한된 기기라면 지속 성능이 중요하므로, 5분 이상 연속 실행한 벤치마크로 비교하는 것이 실제 체감과 가깝습니다.