내가 가진 노트북에서 로컬 LLM을 벤치마킹하다

제 지난 글은 기업들이 자신들의 AI 청구서를 발견하고 상한선을 설치하는 것에 관한 것이었습니다. 그 글에 대한 합리적인 반응은 올해 내내 local-LLM 커뮤니티가 보여온 반응과 같습니다. 토큰을 임대하지 말고, 오픈 모델들은 이제 충분히 좋으니 그냥 자신의 기기에서 실행하라는 것입니다.

하지만 이러한 조언의 근거가 되는 벤치마크에는 하드웨어 문제가 있습니다. 무언가를 측정하는 글들은 Mac Studio나 128GB M5 Max 노트북에서 실행되며, 헤드라인 뉴스는 더 심각합니다. DeepSeek V4 Flash는 MacBook이 약 $5,000짜리 128GB 빌드일 경우에만 “실행된다”고 합니다. Kimi K3은 로드를 위해 무려 H100 8개가 필요한 오픈 웨이트 모델입니다. 올여름의 한 가이드북은 말 그대로 “당신이 실행할 수 없는 오픈 웨이트(Open Weights)”라는 제목을 달았습니다.

제 노트북은 RAM 16GB를 탑재한 2021년 M1 Pro 모델입니다. 거의 5년 정도 되었고, 저는 이 기기가 그 어떤 벤치마크에 나온 장비보다 일반 개발자들의 평균적인 장비에 훨씬 가깝다고 생각합니다. 그래서 제가 실제로 무엇을 할 수 있는지 벤치마킹해 보았습니다.

설정⌗

저는 Ollama를 통해 가져온 다섯 가지 모델을 테스트했으며, 모두 16GB 메모리에 들어갈 수 있도록 선택했습니다:

qwen3.5:4b와 qwen3.5:9b: Alibaba의 현재 소형 모델로, 둘 다 기본적으로 답변하기 전에 생각하는 과정을 거칩니다.
gemma4:e4b-it-qat와 gemma4:12b-it-qat: Google의 현재 소형 계열 모델이며, 양자화 인식 빌드(quantization-aware builds)를 사용했습니다.
qwen2.5:7b: 2024년 후반 모델로, 이 크기에서 1년간의 발전이 나타나는지 여부를 확인하기 위한 기준선 역할을 했습니다.

현재 사람들이 실제로 이야기하는 최신 모델들은 목록에 포함되지 않았으며, 이것 자체가 하나의 발견입니다. glm-4.7-flash와 qwen3-coder 모두 작게 들리지만 다운로드 용량은 19GB에 달합니다. 제가 이 글을 작성한 주에 발표된 Qwen3.8-27B는 약 17GB가 필요하며, 심지어 그 가중치(weights)는 아직 다운로드가 불가능하고 이번 포스트가 올라가는 주에 제공될 예정이라고 합니다. RAM 16GB에서는 온라인 토론에서 제안하는 모델 목록보다 실제로 실행할 수 있는 모델의 목록이 훨씬 짧습니다.

이 과제들은 데이터 엔지니어의 한 주 동안 마주치는 종류의 21가지 문제로 구성되어 있으며, 여섯 가지 범주에 걸쳐 있습니다: 시드된(seeded) 데이터베이스를 대상으로 DuckDB SQL 작성하기, 테스트 스위트가 실패하는 버그가 있는 Python 파일 수정하기, Airflow 로그나 청구 이메일 같은 지저분한 텍스트에서 JSON 추출하기, 까다로운 Python 코드 조각이 무엇을 출력할지 예측하기, 평소에 구글링하던 간단한 질문에 답하기, 그리고 7,400 토큰 분량의 운영 매뉴얼(runbook)에 숨겨진 사실 찾기입니다. 모든 것은 제가 답변을 읽는 것이 아니라 코드로 평가됩니다: 생성된 SQL은 실행되어 참조 쿼리와 행별로 비교되고, 버그 수정은 pytest를 통과해야 하며, 추출 내용은 필드별로 확인됩니다. 각 모델에는 답변에 얼마나 많은 무작위성을 포함할지 제어하는 온도(temperature) 설정도 있습니다. 저는 이 값을 0으로 설정하고 모든 것을 두 번 실행했기 때문에, 각 모델은 총 42회의 실행을 거치게 됩니다.

통과한 항목⌗

두 번째 놀라움은 '총 경과 시간(wall-time)' 열입니다. 구형 qwen2.5는 전체 과제를 단 3분 만에 처리했습니다. 이를 능가한 모델들은 동일한 42회 실행을 위해 1~2시간이 필요했으며, 이 간극의 대부분은 추론 토큰(reasoning tokens) 때문입니다.

추론 비용 (The Reasoning Tax)⌗

현재 세대 모델들은 답변하기 전에 생각하며, 노트북에서 그 '생각하는 과정'에 가장 많은 시간이 소요됩니다.

첫 번째 실행에서 작업당 최대 토큰을 3,072개로 제한했는데, Claude가 단일 요청에 사용하는 토큰 수를 생각하면 그리 많은 양은 아닙니다. qwen3.5 모델은 84회 중 48회에서 이 한도에 도달하여 추론(reasoning)에 예산 전체를 소진하고 답변을 생성하지 못했습니다. 두 모델 모두 약 40~57%의 점수를 기록했습니다. 예산을 두 배로 늘려 8,192개로 다시 실행하자: 둘 다 정확히 열 번 더 통과했습니다. 능력은 있었지만, 답에 도달하려면 수천 개의 추가 토큰이 필요했던 것입니다. 일부 실행에서는 두 배로 늘린 예산마저 초과했습니다. qwen3.5:9b는 하나의 SQL 질문에 대해 8분 동안 34,000자의 사고 과정을 거쳤음에도 불구하고 여전히 공간 부족을 겪었습니다.

gemma 모델도 마찬가지입니다. 보통은 적지만 항상 그런 것은 아닙니다. 한 실행에서 gemma4:12b는 어떤 숫자 chmod 모드가 rwxr-xr–에 해당하는지 추론하는 데 14분을 사용했고, 19,000자의 사고 과정을 생성했으며, 750이라는 답변을 내놓았습니다. 정답은 754입니다.

API에서는 이러한 동일한 동작이 항목별로 나타나며, 추론 토큰(reasoning tokens)은 다른 모든 토큰처럼 청구됩니다. 로컬 환경에서는 기다리는 시간에 표시됩니다.

구글링을 멈출 수 있을까요?⌗

제가 실제로 궁금했던 속도 문제입니다: 간단한 사실 조회에 있어 로컬 모델이 검색 엔진보다 나은가요?

사고 과정이 없는(non-thinking) 모델의 경우, 적어도 지연 시간(latency) 면에서는 그렇습니다. 모델이 이미 로드된 상태에서

unstages. 잘못된 답변은 맞는 답변만큼 빠르고 자신감 있게 돌아왔다. 검색 결과 페이지는 Stack Overflow 투표 수와 교차 확인할 세 개의 경쟁 답변을 제공한다. 로컬 모델은 하나의 답변만 줄 뿐, 그것이 맞는지 아닌지 알 방법이 없다.

장문 문서 테스트⌗

7,400 토큰 분량의 런북을 붙여넣고 질문하는 곳에서 노트북 하드웨어의 실제 한계가 드러난다. 다섯 가지 모델 모두 심어 놓은 사실들, 심지어 맨 끝 근처에 묻힌 것까지 찾아냈다. 따라서 능력 자체가 문제는 아니다. 문제는 기다림이다: gemma4:e4b에서는 첫 번째 질문에 32초, qwen3.5:4b에서는 84초, gemma4:12b에서는 148초가 걸렸다. 나의 M1 Pro는 들어오는 프롬프트를 초당 130~330 토큰으로 처리하며, 이것이 아무도 코딩 에이전트를 노트북 모델에 적용하지 않는 이유다. Claude Code 스타일의 하네스는 요청마다 수만 개의 시스템 프롬프트와 컨텍스트를 전송한다. 노트북 속도로는 이는 답변이 시작되기까지 몇 분을 기다려야 함을 의미하며, 에이전트가 보내는 모든 요청에서 그렇다.

한 가지 기분 좋은 놀라움은 동일한 문서에 대한 후속 질문들이 17초에서 40초 사이로 빠르게 돌아왔다는 것이다. 이는 Ollama가 이미 처리된 문서를 메모리에 유지하기 때문이다. 하나의 긴 문서와 채팅하는 것은 로컬에서 작동하지만, 요청마다 새로운 컨텍스트를 보내는 것은 그렇지 않다.

비용⌗

이것이 내가 실제로 이 벤치마크를 위해 구축한 표이다. 전체 테스트 세트인 210회 실행은 162,000개의 입력 토큰과 412,000개의 출력 토큰을 사용했다. 현재 API 요금으로 책정하면, 모든 것을 합쳐서 비용은 다음과 같다:

따라서 일반 노트북에서 로컬 모델을 실행하는 진정한 이유는 돈이 아닙니다. API를 사용할 수 없는 상황, 즉 장비를 벗어날 수 없는 데이터, 오프라인으로 작업해야 할 때, 또는 API가 작동하지 않을 때입니다. 그리고 저는 예상치 못한 또 다른 이유를 발견했습니다. gemma4:e4b는 테스트 스위트의 모든 추출 작업을 정확하게 수행했으며, 몇 번을 하든 비용이 들지 않습니다. 이는 요청할 때마다 청구서에 추가되는 API 사용과 다르게 느껴집니다.

실제로 유지하고 싶은 것⌗

만약 이 장치에서 한 모델이 자리를 차지한다면 그것은 gemma4:e4b-it-qat입니다. 이 모델은 초당 30 토큰으로 스위트의 86%를 통과했고, 간단한 질문에 1초도 안 되어 답변했으며, 전체 벤치마크를 18분 만에 마쳤습니다. 반면 12B는 네 퍼센트 포인트가 더 높은 점수를 얻기 위해 두 시간을 필요로 했습니다. 이것만으로도 오프라인 백업 및 무료 JSON 추출 도구로 충분합니다.

나머지는 버릴 수 있습니다. 12B 모델은 이 하드웨어에서 기다리기에 너무 느리고, 추론 모델은 답변 가치보다 오래 걸리며, 2024년 기준점은 작고 작은 모델들이 1년 동안 얼마나 많이 개선되었는지(크기는 거의 같은데도 52%에서 90%로) 상기시켜주는 좋은 계기가 되었습니다.

결론적으로 포스트 초반의 조언으로 돌아가겠습니다. 로컬에서 모델을 실행하는 것은 제가 가진 노트북에서 예상보다 더 잘 작동합니다. 하지만 AI 청구서를 줄여주지는 못하며, 애초에 이 시도를 하게 만든 이유가 바로 그 청구서였기 때문입니다.