로컬에서 LLM을 돌리는 건 재미있고 강력하지만, 실제로 일을 끝내려면 꽤 골치 아픔
미리 계획하고 명세를 만들고 준비해야 하는 반면, OpenAI나 Claude의 큰 모델들은 몇 문장만 던져도 바로 알아듣는 편임
맞음. 특히 지난 6개월 사이 많은 사람에게 프런티어 모델 구독료는 업무 비용이 되어버렸음
이미 큰 모델로 진지한 일을 하고 있다면 그냥 계속 쓰면 됨
다만 비전/OCR 작업은 다르게 봄. 소형·중형 공개 가중치 모델도 최신 수준과 비슷하고, 큰 배치 작업에서 프리필 토큰 비용은 꽤 아까움
또 작은 LLM이라도 안정적인 개인 서비스처럼 쓰려면 16~24GB의 RAM/VRAM을 따로 비워두고 계속 실행해야 한다는 점을 자주 잊음
이제는 오프라인 용도로 집에서 큰 모델을 돌리는 게 기술적으로는 쉬워졌음. 최고급 모델을 공개하는 중국 쪽 덕이 큼
핵심 문제는 결국 돈임
거의 쓸 만한 수준까지 왔다고 봄 Gemma 4 31B는 로컬 모델의 새 기준선처럼 느껴짐. 프런티어 모델보다는 당연히 떨어지지만, 지금까지 돌려본 로컬 모델들, GPT OSS 120B나 Nemotron Super 120B보다 과학 실험 느낌이 덜함
M5 Max 128GB RAM에서 256K 전체 컨텍스트 창을 쓰면 RAM 사용량이 약 70GB까지 치솟고, 시스템 오버헤드가 14GB 정도 보임
64GB Panther Lake에 전체 Arc B390을 단 머신이나 48GB Snapdragon X2 Elite 머신이면 128K~256K 컨텍스트 창으로 돌릴 수 있을 것 같고, 32GB에서는 32K 컨텍스트 창으로 억지로 가능할지도 모름
작년만 해도 이런 성능을 메인스트림에 가까운 고급 구성에서 보는 건 헛된 꿈처럼 느껴졌음
Gemma 4는 정말 좋음. Opus 4.7이 놓친 걸 맞힌 적도 있고, 거친 부분은 있지만 사실상 동등하게 쓸 수 있는 용도를 꾸준히 찾고 있음
결국 기준은 “이 모델에게 무엇을 안정적으로 맡길 수 있나”임. Opus는 확실히 더 많은 걸 알고 더 복잡한 작업도 할 수 있지만, 컨텍스트를 잘 넣어주면 Gemma는 놀라울 정도로 좋음
두 모델에 맡겨도 된다고 믿는 작업 범위 차이가 의외로 작음. 개인 도구와 여러 프로젝트에서 최근 매우 좋은 결과를 냈고, 사소하지 않은 프로젝트에서 에이전트 모드로 기능 구현을 믿고 맡길 수 있었던 첫 로컬 모델임 https://thot-experiment.github.io/gradient-gemma4-31b/
이건 OpenCode 안에서 Gemma 4가 거의 전부 만든 비교적 복잡한 도구이고, 몇 시간 동안 수동 개입은 4번 정도뿐이었음
Q6_K_XL, 128K 컨텍스트 @ q8로 읽기 약 800tok/s, 쓰기 16tok/s 정도
llama.cpp의 turboquant와 MTP를 기다리는 중인데, 소문이 맞다면 256K와 25~30tok/s까지 갈 수 있을 듯함
작은 Qwen 3.6 모델들이 컨텍스트 처리는 Gemma 4보다 조금 낫지만, 특히 Gemma 4 26B는 해당 체급에서 아주 작고 효율적인 해법을 내놓는 점이 똑똑함
출시 직후 벤치마크 성능이 인상적이라 관련 글도 썼음 [0]. 다만 더 긴 컨텍스트의 에이전트 코딩 환경에서 돌리면서 순위표 위치는 이후 조금 내려감
[0] https://gertlabs.com/blog/gemma-4-economics
편집 작업 대부분에는 더 작은 Gemma E2B를 쓰는데 의외로 잘 동작함
최신 모델로 계획을 세우고 작은 모델로 실행하는 흐름임. 제대로 계획해서 작은 모델이 해석할 모호함을 남기지 않으면 잘 작동함
첫 토큰까지 걸리는 시간과 초당 토큰 수를 공유해주면 좋겠음
체감상 Gemma가 qwen3보다 더 잘 동작하는지 궁금함
주말 내내 같은 결론에 도달하기 전에 이 글을 봤으면 좋았을 것 같음
같은 노트북에서 작은 바이브 코딩 C++ 저장소의 린트 오류 50개 정도를 고치게 하는 인위적인 테스트를 했음. 작은 작업들을 많이 처리하면서 너무 자주 막히지 않기를 기대했음 GPT OSS 20B는 쓸 수는 있었지만 느렸고, 불필요한 문장을 추가하거나 중복하고, 코드를 수정하지 않고도 고쳤다고 나열하는 실수를 자주 했음
Opencode와 함께 쓴 Qwen 3.5 9B는 훨씬 빨랐고, 압축을 거치는 중에도 린트 경고 대부분을 막히지 않고 처리했으며 모든 경고를 올바른 수정으로 고쳤음
Qwen 3.5 9B의 4비트 MLX 양자화도 시도했지만 결국 메모리 부족으로 크래시가 났고, llama.cpp로 돌리는 GGUF로 바꾸니 크래시 없이 실행됨
프런티어 모델과는 전혀 비교할 수 없음. 훨씬 느리고 기본 정보도 틀리며, 사소하지 않은 작업을 한 번에 처리하지 못함
프로젝트 아키텍처 요약을 시켰더니 저장소 어디에도 없는 라이브러리를 쓴다고 주장했음. 사람마다 다르겠지만 그래도 쓸 만한 면은 있고, 시간이 지나면서 적당한 하드웨어에서도 로컬 LLM 환경이 훨씬 좋아지길 바람
“프런티어 모델과 전혀 비교할 수 없다”는 말은 충분히 자주 나오지 않음
로컬 LLM은 훌륭하지만, 관련 글을 많이 읽다 보면 Opus 4.7에 거의 근접한 것처럼 느껴질 수 있음
HN에는 로컬 LLM의 능력을 크게 과장하는 아주 작고 시끄럽고 열정적인 집단이 있음
qwen3.5 9b 말고 qwen3.6.35 a3b를 써보는 게 좋음. 완전히 다름
GPT OSS 20B가 Mac 하드웨어에서 느리게 돈다는 게 꽤 의외임
같은 크기 모델 중 로컬 GPU에서 돌려본 것 중 가장 빠른 축이었는데, Nvidia 카드에서만 시험해봤음
나중에 보니 MoE이고 활성 파라미터가 3.6B뿐이라 많은 게 설명됨
로컬 모델, 특히 글쓴이가 쓰는 9B처럼 작은 모델로 무엇을 할 수 있는지 현실적으로 보는 게 유용함
9B 모델은 Sonnet 3.6 정도 수준이라 자동완성과 작은 함수는 할 수 있지만, 큰 문제를 이해하려고 하면 흐름을 놓침
그래도 흥미롭고 가지고 놀기 재미있음. 주로 재미로 로컬 에이전트 하네스 등을 많이 만들고 있음
현재 프로젝트는 무설치 에이전트임: https://gemma-agent-explainer.nicklothian.com/
Python, SQL, React가 모두 브라우저 안에서 완전히 실행됨. 가장 좋은 경험을 위해서는 Gemma E4B를 추천함
아직 활발히 개발 중이고, HTML5 Filesystem API와 LiteRT 지원 때문에 Chrome이 필요함. 다만 대부분의 Chromium 기반 브라우저도 동작하게 만들 수 있음
대부분의 에이전트와 다른 점은 무설치라는 것임. 모델은 LiteRT/LiteLLM으로 브라우저 안에서 실행되고, Transformers.js보다 성능이 좋음. Filesystem API로 선택적으로 샌드박스 디렉터리 읽기 접근도 가능함
자체 문서화되어 있어서 실시간 도움말 패널에서 “시스템 프롬프트가 어떻게 쓰이나” 같은 질문을 하면 자기 소스 코드에 접근해 답할 수 있음
“Tour”를 누르면 전체를 볼 수 있고, 다음 주에 오픈소스로 공개할 예정임
Sonnet 3.5로는 자동완성과 작은 함수보다 훨씬 많은 일을 하고 있었음
꼬집자는 건 아니지만, 많은 4~12B 모델은 GPT-3.5와 GPT-4o-mini 사이 어딘가에 있음
다만 사람들이 모델을 평가하는 벤치마크가 너무 자주 바뀌어서 좋은 비교를 찾기 어렵긴 함. 참고로 Sonnet 3.6은 GPT-3.5보다 약 1년 뒤에 나왔음
비판적으로 보면 이 모델들이 복잡한 코딩 작업에서 최신 최고 수준과 동급이 아니라는 건 맞음
하지만 사무직 업무의 상당 부분은 Excel 처리, 파일 이동, 딱딱한 법률 문서 번역, 이메일 초안, PPT 잡무 같은 일임
이런 작업은 30~35B 이상 모델로 충분히 가능하고, 회사 데이터를 비공개로 유지할 수 있다는 장점도 있음
결론이 좀 잘못된 것 같음. qwen3.5 9b가 최신 모델과 거리가 먼 건 당연함. 9B이고 1년 전 모델 아닌가?
로컬 모델을 이야기하는 사람들이 기대하는 건 올해 4월에 나온 모델들임. Qwen 3.6 27B와 GPU가 약하면 qwen 35b a3b가 대상임
이 모델들은 진지하게 최신 수준 모델과 비교할 만함
오히려 Excel과 법률은 코드보다 훨씬 나쁠 수 있음. 실수를 잡아내기가 더 어려울 수 있기 때문임
대표적으로 JPMorgan의 London Whale 사건은 Excel 오류로 60억 달러 손실이 났음
M5 Pro 18/20코어 MacBook 64GB RAM을 고려 중인데, 실제 모델 벤치마크를 찾기가 매우 어려움
예를 들어 Qwen 3.6 35B/A3B의 Q4와 Q6 양자화에서 초당 토큰 수가 어느 정도인지 누가 알려주면 좋겠음
초당 토큰 수만 보지 말고 첫 토큰까지 걸리는 시간도 같이 봐야 함
로컬 추론 쪽은 MoE 모델로 기울고 있고, 상당수는 초당 토큰 수는 괜찮지만 첫 토큰까지 걸리는 시간이 끔찍함
M4 Pro 48GB에서 qwen 3.6 9b 양자화 모델을 돌리고 있는데, 기본적인 pi.dev/cc 기반 개발에 겨우 쓸 만한 정도임
실제로 의미 있는 일을 하려면 128GB 데스크톱이 sweet spot인 것 같음. 다만 지금은 그런 머신을 구하기가 어려움
로컬 실행이 재미있긴 하지만 자기 시간도 공짜가 아니라는 점을 잊으면 안 됨
개인 프로젝트에서는 점점 OpenRouter로 옮기고 있고, 가장 큰 qwen 모델을 진지하게 써도 하루 2~3달러 미만으로 돌림
그렇게 작은 모델을 고른 이유가 높은 초당 토큰 수 때문이었는지 궁금함
M4 Pro 48GB라면 더 큰 모델도 돌릴 수 있으니, 모델 지능이 유용성을 높이는 핵심이라면 더 큰 모델을 쓰는 편이 맞을 수 있음
같은 사양에서 30B MoE 모델을 65K 토큰으로 도구를 가진 하위 에이전트로 쓰고 있는데, 꽤 괜찮은 코드를 씀
밀집형 9B가 별로라는 데는 동의함
로컬 모델이 Opus 4.7 같은 것보다 낫다는 식의 온라인 헛소리가 너무 많음. 일반 사용자에게는 사실이 아님
최신 M5 MacBook Pro 최고 사양을 쓰고 로컬 모델도 시험해봤지만, 거의 겨우 동작하는 수준임
OpenRouter 버전은 ChatGPT 5.5나 Claude Opus 4.6과 비교하면 어떤지 궁금함
4090 24GB에서 최근의 turboquant/rotorquant 활성값 메모리 최적화를 활용해 qwen3.6:27B를 약 128K 컨텍스트로 돌리고 있음
그 정도 모델로 올려보는 걸 강력히 추천함. q4_xl+rotorquant 조합이 꽤 좋음
에이전트에게 던져볼 참고 코드도 있음 https://github.com/rapatel0/rq-models
API 구독보다 Mac에 수천 달러를 쓰는 쪽이 낫다고 봄 로컬 모델은 프라이버시 유출 걱정 없이 언제 어디서든 일을 할 수 있게 해줌
Hacker News 의견들
로컬에서 LLM을 돌리는 건 재미있고 강력하지만, 실제로 일을 끝내려면 꽤 골치 아픔
미리 계획하고 명세를 만들고 준비해야 하는 반면, OpenAI나 Claude의 큰 모델들은 몇 문장만 던져도 바로 알아듣는 편임
이미 큰 모델로 진지한 일을 하고 있다면 그냥 계속 쓰면 됨
다만 비전/OCR 작업은 다르게 봄. 소형·중형 공개 가중치 모델도 최신 수준과 비슷하고, 큰 배치 작업에서 프리필 토큰 비용은 꽤 아까움
또 작은 LLM이라도 안정적인 개인 서비스처럼 쓰려면 16~24GB의 RAM/VRAM을 따로 비워두고 계속 실행해야 한다는 점을 자주 잊음
핵심 문제는 결국 돈임
거의 쓸 만한 수준까지 왔다고 봄
Gemma 4 31B는 로컬 모델의 새 기준선처럼 느껴짐. 프런티어 모델보다는 당연히 떨어지지만, 지금까지 돌려본 로컬 모델들, GPT OSS 120B나 Nemotron Super 120B보다 과학 실험 느낌이 덜함
M5 Max 128GB RAM에서 256K 전체 컨텍스트 창을 쓰면 RAM 사용량이 약 70GB까지 치솟고, 시스템 오버헤드가 14GB 정도 보임
64GB Panther Lake에 전체 Arc B390을 단 머신이나 48GB Snapdragon X2 Elite 머신이면 128K~256K 컨텍스트 창으로 돌릴 수 있을 것 같고, 32GB에서는 32K 컨텍스트 창으로 억지로 가능할지도 모름
작년만 해도 이런 성능을 메인스트림에 가까운 고급 구성에서 보는 건 헛된 꿈처럼 느껴졌음
결국 기준은 “이 모델에게 무엇을 안정적으로 맡길 수 있나”임. Opus는 확실히 더 많은 걸 알고 더 복잡한 작업도 할 수 있지만, 컨텍스트를 잘 넣어주면 Gemma는 놀라울 정도로 좋음
두 모델에 맡겨도 된다고 믿는 작업 범위 차이가 의외로 작음. 개인 도구와 여러 프로젝트에서 최근 매우 좋은 결과를 냈고, 사소하지 않은 프로젝트에서 에이전트 모드로 기능 구현을 믿고 맡길 수 있었던 첫 로컬 모델임
https://thot-experiment.github.io/gradient-gemma4-31b/
이건 OpenCode 안에서 Gemma 4가 거의 전부 만든 비교적 복잡한 도구이고, 몇 시간 동안 수동 개입은 4번 정도뿐이었음
Q6_K_XL, 128K 컨텍스트 @ q8로 읽기 약 800tok/s, 쓰기 16tok/s 정도
llama.cpp의 turboquant와 MTP를 기다리는 중인데, 소문이 맞다면 256K와 25~30tok/s까지 갈 수 있을 듯함
출시 직후 벤치마크 성능이 인상적이라 관련 글도 썼음 [0]. 다만 더 긴 컨텍스트의 에이전트 코딩 환경에서 돌리면서 순위표 위치는 이후 조금 내려감
[0] https://gertlabs.com/blog/gemma-4-economics
최신 모델로 계획을 세우고 작은 모델로 실행하는 흐름임. 제대로 계획해서 작은 모델이 해석할 모호함을 남기지 않으면 잘 작동함
주말 내내 같은 결론에 도달하기 전에 이 글을 봤으면 좋았을 것 같음
같은 노트북에서 작은 바이브 코딩 C++ 저장소의 린트 오류 50개 정도를 고치게 하는 인위적인 테스트를 했음. 작은 작업들을 많이 처리하면서 너무 자주 막히지 않기를 기대했음
GPT OSS 20B는 쓸 수는 있었지만 느렸고, 불필요한 문장을 추가하거나 중복하고, 코드를 수정하지 않고도 고쳤다고 나열하는 실수를 자주 했음
Opencode와 함께 쓴 Qwen 3.5 9B는 훨씬 빨랐고, 압축을 거치는 중에도 린트 경고 대부분을 막히지 않고 처리했으며 모든 경고를 올바른 수정으로 고쳤음
Qwen 3.5 9B의 4비트 MLX 양자화도 시도했지만 결국 메모리 부족으로 크래시가 났고, llama.cpp로 돌리는 GGUF로 바꾸니 크래시 없이 실행됨
프런티어 모델과는 전혀 비교할 수 없음. 훨씬 느리고 기본 정보도 틀리며, 사소하지 않은 작업을 한 번에 처리하지 못함
프로젝트 아키텍처 요약을 시켰더니 저장소 어디에도 없는 라이브러리를 쓴다고 주장했음. 사람마다 다르겠지만 그래도 쓸 만한 면은 있고, 시간이 지나면서 적당한 하드웨어에서도 로컬 LLM 환경이 훨씬 좋아지길 바람
로컬 LLM은 훌륭하지만, 관련 글을 많이 읽다 보면 Opus 4.7에 거의 근접한 것처럼 느껴질 수 있음
HN에는 로컬 LLM의 능력을 크게 과장하는 아주 작고 시끄럽고 열정적인 집단이 있음
같은 크기 모델 중 로컬 GPU에서 돌려본 것 중 가장 빠른 축이었는데, Nvidia 카드에서만 시험해봤음
나중에 보니 MoE이고 활성 파라미터가 3.6B뿐이라 많은 게 설명됨
로컬 모델, 특히 글쓴이가 쓰는 9B처럼 작은 모델로 무엇을 할 수 있는지 현실적으로 보는 게 유용함
9B 모델은 Sonnet 3.6 정도 수준이라 자동완성과 작은 함수는 할 수 있지만, 큰 문제를 이해하려고 하면 흐름을 놓침
그래도 흥미롭고 가지고 놀기 재미있음. 주로 재미로 로컬 에이전트 하네스 등을 많이 만들고 있음
현재 프로젝트는 무설치 에이전트임: https://gemma-agent-explainer.nicklothian.com/
Python, SQL, React가 모두 브라우저 안에서 완전히 실행됨. 가장 좋은 경험을 위해서는 Gemma E4B를 추천함
아직 활발히 개발 중이고, HTML5 Filesystem API와 LiteRT 지원 때문에 Chrome이 필요함. 다만 대부분의 Chromium 기반 브라우저도 동작하게 만들 수 있음
대부분의 에이전트와 다른 점은 무설치라는 것임. 모델은 LiteRT/LiteLLM으로 브라우저 안에서 실행되고, Transformers.js보다 성능이 좋음. Filesystem API로 선택적으로 샌드박스 디렉터리 읽기 접근도 가능함
자체 문서화되어 있어서 실시간 도움말 패널에서 “시스템 프롬프트가 어떻게 쓰이나” 같은 질문을 하면 자기 소스 코드에 접근해 답할 수 있음
“Tour”를 누르면 전체를 볼 수 있고, 다음 주에 오픈소스로 공개할 예정임
다만 사람들이 모델을 평가하는 벤치마크가 너무 자주 바뀌어서 좋은 비교를 찾기 어렵긴 함. 참고로 Sonnet 3.6은 GPT-3.5보다 약 1년 뒤에 나왔음
비판적으로 보면 이 모델들이 복잡한 코딩 작업에서 최신 최고 수준과 동급이 아니라는 건 맞음
하지만 사무직 업무의 상당 부분은 Excel 처리, 파일 이동, 딱딱한 법률 문서 번역, 이메일 초안, PPT 잡무 같은 일임
이런 작업은 30~35B 이상 모델로 충분히 가능하고, 회사 데이터를 비공개로 유지할 수 있다는 장점도 있음
로컬 모델을 이야기하는 사람들이 기대하는 건 올해 4월에 나온 모델들임. Qwen 3.6 27B와 GPU가 약하면 qwen 35b a3b가 대상임
이 모델들은 진지하게 최신 수준 모델과 비교할 만함
대표적으로 JPMorgan의 London Whale 사건은 Excel 오류로 60억 달러 손실이 났음
M5 Pro 18/20코어 MacBook 64GB RAM을 고려 중인데, 실제 모델 벤치마크를 찾기가 매우 어려움
예를 들어 Qwen 3.6 35B/A3B의 Q4와 Q6 양자화에서 초당 토큰 수가 어느 정도인지 누가 알려주면 좋겠음
로컬 추론 쪽은 MoE 모델로 기울고 있고, 상당수는 초당 토큰 수는 괜찮지만 첫 토큰까지 걸리는 시간이 끔찍함
32GB M2 Studio에서 쓰는 임의의 설정을 Bluesky에 적어봤고 피드백을 받고 싶음
직접 보지 않으면 잘 못하는 타입이라 도움을 바라며 공유함
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
M4 Pro 48GB에서 qwen 3.6 9b 양자화 모델을 돌리고 있는데, 기본적인 pi.dev/cc 기반 개발에 겨우 쓸 만한 정도임
실제로 의미 있는 일을 하려면 128GB 데스크톱이 sweet spot인 것 같음. 다만 지금은 그런 머신을 구하기가 어려움
로컬 실행이 재미있긴 하지만 자기 시간도 공짜가 아니라는 점을 잊으면 안 됨
개인 프로젝트에서는 점점 OpenRouter로 옮기고 있고, 가장 큰 qwen 모델을 진지하게 써도 하루 2~3달러 미만으로 돌림
M4 Pro 48GB라면 더 큰 모델도 돌릴 수 있으니, 모델 지능이 유용성을 높이는 핵심이라면 더 큰 모델을 쓰는 편이 맞을 수 있음
밀집형 9B가 별로라는 데는 동의함
최신 M5 MacBook Pro 최고 사양을 쓰고 로컬 모델도 시험해봤지만, 거의 겨우 동작하는 수준임
4090 24GB에서 최근의 turboquant/rotorquant 활성값 메모리 최적화를 활용해 qwen3.6:27B를 약 128K 컨텍스트로 돌리고 있음
그 정도 모델로 올려보는 걸 강력히 추천함. q4_xl+rotorquant 조합이 꽤 좋음
에이전트에게 던져볼 참고 코드도 있음
https://github.com/rapatel0/rq-models
API 구독보다 Mac에 수천 달러를 쓰는 쪽이 낫다고 봄
로컬 모델은 프라이버시 유출 걱정 없이 언제 어디서든 일을 할 수 있게 해줌