로컬에서 대형언어모델(LLM)을 돌리려는 사람에게 가장 큰 고민은 "내 하드웨어에서 과연 쓸 만한 속도가 나올까"이다. 모델 가중치를 내려받아 실행하는 것 자체는 어렵지 않지만, 체감 속도는 전혀 다른 문제다. GPU의 메모리 대역폭, VRAM 용량, 모델의 파라미터 수와 양자화 수준에 따라 초당 생성 토큰 수가 크게 갈리기 때문이다. 문제는 이 수치를 직접 확인하려면 이미 수백만 원짜리 장비를 사거나 빌려서 돌려봐야 한다는 점이다. Llmspeed는 바로 이 '구매 전 체감'의 공백을 메우려는 웹 도구다.
무엇을 하는 도구인가
Llmspeed(llmspeed.dev)는 사용자가 하드웨어와 모델을 고르면 해당 조합에서 기대되는 초당 토큰 생성 속도(tokens/sec)와 첫 토큰이 나오기까지의 지연, 즉 time-to-first-token을 시뮬레이션해 보여준다. 대상 하드웨어는 엔비디아 등 GPU뿐 아니라 애플 실리콘 기반 맥까지 포함한다. 단순히 숫자를 표로 나열하는 데 그치지 않고, 실제 생성 속도가 어떤 식으로 느껴지는지를 '체감'하게 해준다는 점을 내세운다. 결과는 짧은 프롬프트를 단일 장비에서 돌렸을 때를 기준으로 한 추정치다. 프로젝트는 오픈소스로 깃허브에 공개돼 있다.
이 도구가 흥미로운 지점은 수치의 출처를 솔직하게 구분해 밝힌다는 데 있다. 일부 값은 r/LocalLLaMA 서브레딧, localscore.ai 같은 커뮤니티 벤치마크에서 수집한 실측치다. 반면 측정 데이터가 없는 조합은 비슷한 구성에서 유추하거나 하드웨어 사양으로부터 추정한 값이다. 즉 화면에 뜨는 모든 숫자가 동일한 신뢰도를 갖는 것은 아니며, 실측과 추정이 섞여 있다는 사실을 전제로 봐야 한다.
왜 이런 도구가 필요한가
로컬 LLM 생태계는 지난 몇 년간 빠르게 커졌지만, 하드웨어 선택에 대한 정보는 여전히 파편화돼 있다. 같은 모델이라도 양자화 방식과 추론 엔진, 컨텍스트 길이에 따라 성능이 달라지고, 벤치마크는 여러 커뮤니티에 흩어져 있어 비교가 까다롭다. 초당 20토큰과 초당 60토큰은 숫자로는 세 배 차이지만, 실제로 대화형 응답을 기다릴 때의 답답함은 직접 겪어보기 전엔 가늠하기 어렵다. Llmspeed가 '숫자'가 아니라 '체감'을 강조하는 이유가 여기에 있다. 구매 의사결정에서 가장 중요한 것은 결국 그 속도로 내 작업 흐름이 견딜 만한가이기 때문이다.
실무적으로 보면 이 도구의 쓰임새는 분명하다. 사내에서 코드 어시스턴트나 문서 요약용으로 로컬 모델을 검토하는 엔지니어라면, 어떤 GPU를 몇 장 구성해야 목표 모델이 쾌적하게 돌아갈지를 발주 전에 미리 좁혀볼 수 있다. 맥 스튜디오처럼 통합 메모리 구조를 가진 장비와 전용 GPU를 같은 선상에서 비교해볼 수 있다는 점도, 두 진영을 저울질하는 개인 사용자에게는 실질적인 참고가 된다. 장비 구매라는 비가역적 지출을 앞두고 감이 아니라 근거에 가까운 추정을 손에 쥘 수 있다는 것이 핵심 가치다.
한계는 분명히 인식해야 한다
다만 추정은 추정일 뿐이라는 점을 잊어선 안 된다. 제공되는 값은 '짧은 프롬프트, 단일 장비'를 가정한 수치다. 긴 컨텍스트를 넣거나 여러 사용자의 요청을 동시에 처리하는 배치 추론, 여러 장비를 묶는 분산 구성에서는 결과가 달라질 수 있다. 추론 엔진과 드라이버 버전, 양자화 설정, 발열에 따른 클럭 변동 같은 변수도 실제 성능을 좌우한다. 커뮤니티 벤치마크 자체가 측정 환경이 제각각이라, 실측치라 해도 재현성에는 한계가 있다.
결국 Llmspeed는 구매 결정을 대신해주는 도구가 아니라, 후보군을 빠르게 추려주는 출발점으로 보는 편이 적절하다. 특히 실측 데이터가 없는 조합의 숫자는 참고용 지표 이상으로 신뢰하지 않는 것이 안전하다. 그럼에도 흩어진 벤치마크를 한곳에 모아 하드웨어와 모델을 나란히 비교하고, 추정의 근거를 투명하게 드러낸다는 점에서, 로컬 LLM 도입을 고민하는 실무자에게는 충분히 열어볼 만한 도구다. 오픈소스로 공개돼 있는 만큼 데이터가 쌓이고 커뮤니티 기여가 늘어난다면 추정의 정확도도 점차 다듬어질 여지가 있다.