llmspeed: GPU를 사기 전에 로컬 LLM 속도를 '느껴보는' 도구

10월 17일 Hacker News에 소개된 도구가 하나 있습니다. 이름은 llmspeed. 한 줄 소개가 정확합니다. "하드웨어를 사기 전에 로컬 LLM이 얼마나 빠른지 느껴보라."

방식이 재미있습니다. GPU나 Mac을 고르고 모델을 고르면, 그 예상 속도로 텍스트가 화면에 실제로 흘러나옵니다. 첫 토큰이 나오기까지의 대기 시간까지 포함해서요. 벤치마크 표의 숫자를 읽는 것과, 그 속도로 답이 타이핑되는 것을 보는 것은 체감이 다릅니다.

카탈로그도 넓습니다. RTX 3090·4090·5090, RTX PRO 6000, Mac Studio와 MacBook 시리즈, DGX Spark, Strix Halo, AMD·Intel GPU, CPU-only 구성까지 30개 하드웨어와 15개 인기 모델을 다룹니다. CUDA, Metal, ROCm, Vulkan, CPU 백엔드를 모두 포함합니다.

무엇을 보여주나

기능을 정리하면 이렇습니다.

llmspeed (llmspeed.dev, MIT 오픈소스)

- 실시간 시뮬레이션 : 프롬프트 길이에 맞는 첫 토큰 대기 후,
                      예측된 tok/s로 텍스트가 실제로 스트리밍됨
- 레이스 모드       : 두 구성을 나란히 (예: 5090 vs Mac Studio)
- 메모리 적합성     : 양자화별로
                      [적합] / [부분 오프로드] / [실행 불가]를 표시
- 공유 링크         : 어떤 구성·레이스든 URL로 공유
- 규모             : GPU·Mac·CPU 30종 × 인기 모델 15종
- 스택             : Vite + Preact + TypeScript, 정적 사이트(GitHub Pages)

숫자 감각을 잡기 위해 몇 가지 예를 보겠습니다. 모두 llmspeed가 제시한 값입니다.

여기서 바로 이 도구의 가치가 드러납니다. 가장 빠른 소비자용 GPU인 RTX 5090은 35B급 MoE 모델에서는 압도적이지만, 748B 규모 모델은 아예 담지 못합니다. 반대로 Mac Studio M5 Ultra 512GB는 그 큰 모델을 78 tok/s로 돌립니다. 순위가 아니라 "무엇을 돌리려는가"가 먼저라는 사실을 한 화면에서 보여줍니다.

전: 숫자는 어디서 오나, 얼마나 믿을까

이 도구를 제대로 쓰려면 숫자의 출처를 알아야 합니다. llmspeed는 모든 추정에 신뢰 라벨을 붙입니다.

[신뢰 라벨]
Measured  : 바로 그 하드웨어·모델·양자화로 측정된 벤치마크
Derived   : 비슷한 구성의 측정값에서 보간(interpolate)
Projected : (미출시 하드웨어 등) 하드웨어 스펙에서 계산

벤치마크 소스: r/LocalLLaMA, localscore.ai, llama.cpp 논의 등
              커뮤니티 측정값을 수집·검증

측정값이 없는 조합에서는 제1원리로 계산합니다. 이 부분이 오히려 교육적입니다.

[폴백 계산 모델]
- 생성 속도는 메모리 대역폭에 묶인다
  : 토큰 하나마다 활성 가중치를 한 번 읽는다
  : MoE 모델은 '활성 파라미터'만 센다
- 프롬프트 처리(prefill)는 연산(FP16 TFLOPS)에 묶인다
- 둘 다 백엔드별 효율 계수를 측정값에 맞춰 보정하고,
  컨텍스트가 길어질수록 느려지는 항을 더한다
- 부분 오프로드는 하이브리드 모델
  : GPU에 남은 부분은 GPU 대역폭으로, 넘친 부분은
    시스템 RAM 유효 대역폭으로 스트리밍
- 메모리 적합성 계산
  : Mac 통합 메모리의 약 75%, 개별 GPU VRAM의 약 93%를 사용 가능으로 간주
    (가중치 + KV 캐시 + 런타임 오버헤드 합산)

여기서 두 가지 개념이 중요합니다. 첫째, 생성 속도의 병목은 연산이 아니라 메모리 대역폭입니다. 모델 가중치를 메모리에서 읽어오는 속도가 초당 토큰 수를 결정합니다. 그래서 RTX 5090(대역폭 약 1,790GB/s)이 Qwen 27B 같은 dense 모델에서 46 tok/s에 그치는 반면, 활성 파라미터가 적은 MoE 모델에서는 훨씬 빠릅니다. 둘째, MoE는 전체가 아니라 활성 파라미터만 읽으므로 "파라미터 수"가 곧 속도가 아닙니다. 이 배경은 MoE의 활성 파라미터 이해에 정리해 두었습니다.

한계도 분명히 밝힙니다.

[llmspeed가 명시한 한계]
- 단일 디바이스만 지원. 텐서·레이어 분할 멀티 GPU는 아직 미지원
- 추정이지 보장이 아니다. 드라이버, 엔진 버전, flash attention,
  전력 제한, 발열로 실제 값이 10~30% 움직일 수 있다
- 미출시 하드웨어의 Projected 값은 측정값이 생기면 교체될 예정

전: 두 축으로 하드웨어를 본다

llmspeed가 결국 보여주는 것은 두 축입니다.

[축 1] 용량  — 이 모델이 메모리에 들어가는가 (fit / offload / won't run)
[축 2] 속도  — 들어간다면 얼마나 빠른가 (대역폭이 결정)

이 두 축은 다르게 움직인다.
- RTX 5090 : 속도는 최강, 용량은 32GB까지
- Mac Studio M5 Ultra : 용량은 거대, 속도는 대역폭만큼
- DGX Spark : 큰 모델을 담지만 dense 모델에서는 느리다
              (예: Llama 3.1 70B 약 4.4 tok/s)

구매 결정에서 흔한 실수는 속도만 보고 카드를 고르는 것입니다. 내가 돌리려는 모델이 그 메모리에 들어가지 않으면 속도는 의미가 없습니다. 반대로 큰 모델을 담을 수 있어도, 그 속도가 내 워크로드에서 쓸 만한지도 따로 봐야 합니다. 예를 들어 12 tok/s는 사람이 읽으며 쓰기엔 괜찮지만, 에이전트 루프처럼 초당 여러 번 호출하는 작업엔 병목입니다.

결론: 구매 전 체크리스트

브리핑의 액션을 그대로 옮기면 이렇습니다.

[로컬 LLM 하드웨어 구매 전 체크리스트]

1. 후보 모델과 양자화의 메모리 요구량을 계산한다
   [ ] 전체 파라미터 + KV 캐시 + 런타임 오버헤드
   [ ] MoE면 활성 파라미터도 함께 확인 (속도에 영향)

2. 용량과 속도를 분리해 본다
   [ ] VRAM(개별 GPU) vs 통합 메모리(Mac)의 trade-off
   [ ] 첫 토큰 지연시간(TTFT) vs 생성 처리량(tok/s)
       — 긴 프롬프트를 쓰면 TTFT가 체감을 좌우한다

3. llmspeed에서 라벨을 확인한다
   [ ] 이 셀이 Measured인가, Derived/Projected인가
   [ ] Projected만 있으면 결정을 보류하고 실측을 기다린다

4. 레이스 모드로 후보 두 개를 나란히 본다
   [ ] 같은 모델, 같은 양자화에서 어느 쪽이 내 체감에 맞는가

5. 마지막은 실측으로 확인한다
   [ ] llama-bench -m 모델.gguf -p 512 -n 128
   [ ] 결과를 PR로 제보하면 다음 사람의 추정이 정확해진다

한 줄로 요약하면 이렇습니다.

로컬 LLM의 성능은 '모델이 똑똑한가'가 아니라
'메모리에 들어가고, 대역폭이 받쳐주는가'로 먼저 결정된다.

llmspeed가 흥미로운 이유는 이 원리를 표가 아니라 체험으로 보여준다는 데 있습니다. 하드웨어를 사기 전에, 그리고 사고 난 뒤에도, 이 감각을 갖고 있으면 시행착오의 비용이 크게 줄어듭니다. 로컬 하드웨어 경제성에 대한 배경은 DGX Spark 64GB의 로컬 AI 경제성과 AI 모델 속도와 지연시간 가이드에서 이어 볼 수 있습니다.

함께 읽으면 좋은 글

• DGX Spark 64GB: 로컬 AI 경제성 뜯어보기
• AI 모델 속도와 지연시간, 무엇을 봐야 하나
• MoE의 '활성 파라미터'란 무엇인가

참고 자료

• llmspeed 공식 사이트
• llmspeed GitHub 저장소 (MIT)
• r/LocalLLaMA (커뮤니티 측정 출처)
• llama.cpp (llama-bench 도구 포함)

이 주제를 직접 따라가며 배우고 싶다면

로컬 모델을 돌릴 수 있게 되면 다음 질문은 "그 모델에게 무엇을 읽히고, 무엇을 답하게 할 것인가"입니다. 검색(RAG) 설계가 그다음 병목이 되고, 여기서 하드웨어 감각이 실전으로 이어집니다.

• 실무 RAG 설계 강의 보기