# M4 24GB 메모리에서 로컬 모델 실행하기
> Clean Markdown view of GeekNews topic #29385. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=29385](https://news.hada.io/topic?id=29385)
- GeekNews Markdown: [https://news.hada.io/topic/29385.md](https://news.hada.io/topic/29385.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-11T20:35:09+09:00
- Updated: 2026-05-11T20:35:09+09:00
- Original source: [jola.dev](https://jola.dev/posts/running-local-models-on-m4)
- Points: 1
- Comments: 1
## Topic Body
- **M4 MacBook Pro 24GB**에서도 기본 작업·조사·계획용 로컬 모델 구성이 가능함
- **Qwen 3.5-9B Q4**는 약 40토큰/초, 사고 모드, 도구 사용, 128K 컨텍스트를 만족함
- 최고 수준 모델처럼 복잡한 문제를 오래 독립 해결하진 못해 **단계별 지시**가 필요함
- Elixir Credo 경고는 고쳤지만, **rebase 충돌** 해결은 파일 수정 없이 실패함
- 로컬 모델은 오프라인·구독 불필요가 장점이지만, 성능과 설정에 **트레이드오프**가 큼
---
### 로컬 모델 실행 환경과 선택 기준
- M4 MacBook Pro 24GB 메모리 환경에서 로컬 모델 실행 설정을 실험했고, 최고 수준 모델(SOTA) 출력과는 다르지만 기본 작업, 조사, 계획을 인터넷 연결 없이 처리할 수 있는 구성이 가능했음
- 로컬 실행 도구로는 [Ollama](https://ollama.com/), [llama.cpp](https://github.com/ggml-org/llama.cpp), [LM Studio](https://lmstudio.ai/)가 있으며, 각각 제약과 제공 모델이 다름
- 모델 선택에서는 메모리에 들어가면서도 일반적인 Electron 앱을 함께 실행할 여유가 있어야 했고, 최소 64K, 이상적으로는 128K 이상의 컨텍스트 창이 필요했음
- 최근 시도한 Qwen 3.6 Q3, GPT-OSS 20B, Devstral Small 24B는 메모리에는 들어갔지만 실제 사용은 어려웠고, Gemma 4B는 잘 실행됐지만 도구 사용에서 어려움을 보임
- 설정 항목은 temperature처럼 잘 알려진 값부터 K Cache Quantization Type 같은 특수 옵션까지 다양하며, 사고(thinking) 활성화 여부에 따라 적절한 값이 달라질 수 있음
### Qwen 3.5-9B 4비트 양자화 구성
- [qwen3.5-9b@q4_k_s](https://huggingface.co/unsloth/Qwen3.5-9B-GGUF)는 LM Studio에서 실행했을 때 약 40토큰/초, 사고 활성화, 성공적인 도구 사용, 128K 컨텍스트 창을 함께 만족한 가장 나은 모델이었음
- 최고 수준 모델보다 쉽게 산만해지고, 가끔 루프에 빠지며, 요청을 잘못 해석하기도 하지만 24GB MacBook Pro에서 다른 작업 공간을 남기고 실행되는 모델로는 상당히 괜찮았음
- 사고 모드와 코딩 작업을 위한 권장 설정은 다음과 같았음
```text
temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
```
- 사고를 활성화하려면 LM Studio에서 모델을 선택한 뒤 configuration으로 이동하고, Inference 탭 하단의 Prompt Template에 다음 값을 추가해야 함
```text
{%- set enable_thinking = true %}
```
- 이 모델은 [pi](https://pi.dev/)와 [OpenCode](https://opencode.ai/) 양쪽에서 사용됐으며, pi는 더 빠릿하게 느껴졌지만 하네스(harness)를 직접 구축하고 커스터마이즈할 수 있다는 장점과 별개로 합리적인 기본값이 부족했음
- pi 설정을 맞추는 데 실제 프로젝트보다 더 많은 시간을 쓰게 될 수 있었음
### pi 설정
- `~/.pi/agent/models.json`에는 LM Studio의 OpenAI 호환 엔드포인트와 `qwen3.5-9b@q4_k_s` 모델을 등록함
```json
{
"providers": {
"lmstudio": {
"baseUrl": "http://localhost:1234/v1",
"api": "openai-completions",
"apiKey": "lm-studio",
"models": [
{
"id": "qwen3.5-9b@q4_k_s",
"reasoning": true,
"compat": { "thinkingFormat": "qwen-chat-template" }
}
]
}
}
}
```
- 산만한 사고 블록을 숨기려면 `~/.pi/agent/settings.json`에 `"hideThinkingBlock": true`를 추가함
### OpenCode 설정
- `~/.config/opencode/opencode.json`에는 LM Studio를 로컬 OpenAI 호환 provider로 등록하고, 도구 사용과 131072 컨텍스트 길이, 32768 최대 토큰을 설정함
```json
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"lmstudio": {
"npm": "@ai-sdk/openai-compatible",
"name": "LM Studio (local)",
"options": {
"baseURL": "http://127.0.0.1:1234/v1"
},
"models": {
"qwen3.5-9b@q4_k_s": {
"name": "Qwen 3.5 9B Q4_K_S",
"tools": true,
"context_length": 131072,
"max_tokens": 32768
}
}
}
},
"model": "lmstudio/qwen3.5-9b@q4_k_s"
}
```
### 최고 수준 모델과의 차이
- Qwen 3.5 9B Q4 같은 모델은 최고 수준 모델처럼 긴 시간 동안 복잡한 문제를 독립적으로 해결할 수 있는 수준은 아니었음
- 전체 앱을 한 번에 만들라고 요청하는 방식은 적합하지 않았고, 결과 없이 노트북만 뜨거워질 수 있음
- 더 잘 맞는 방식은 단계별로 명확히 소통하고, 많은 지침을 주는 상호작용형 워크플로였음
- 로컬 모델을 쓸 때는 사용자가 더 많은 사고와 계획을 직접 맡고 더 구체적으로 지시해야 하지만, 조사 보조자, 러버덕, 프로그래밍 언어 세부사항과 명령줄 호출을 즉시 떠올리는 보조자로는 쓸모가 있었음
- 대형 AI 회사들이 홍보하는 10배 생산성 향상은 아니지만, 의미 있는 도움과 흥미로운 사용감을 줌
### 작동한 작업과 실패한 작업
- ## Elixir Credo 경고 수정
- Elixir linter `credo`를 최신 버전으로 올린 뒤 코드에서 경고가 발생했고, Qwen에게 `mix credo --strict`를 실행해 해결 방법을 제안하되 편집하지 말라고 요청함
- Qwen은 테스트 파일 4곳에서 리스트가 비어 있지 않은지 확인하기 위해 `length/1`을 쓰는 문제를 찾아냈고, `length(list) > 0` 대신 `list != []`를 쓰라고 제안함
- 이후 편집을 요청하자 Qwen은 4개의 병렬 편집을 깔끔하게 수행함
- 이 작업은 터미널과 에디터를 오가며 직접 할 수도 있는 단순 작업이었지만, 편리한 보조 역할을 해줌
- ## Dependabot PR의 rebase 충돌 처리
- 의존성 업데이트 뒤 Dependabot PR에 git 충돌이 있었고, Dependabot이 rebase를 거부해 직접 내려받아 rebase한 뒤 Qwen에게 확인을 요청함
- 충돌은 각 의존성의 더 최신 버전을 선택하면 되는 단순한 형태였고, Qwen은 `sentry`는 `13.0.1`, `tailwind`는 `0.4.1`을 유지하는 선택지를 권장함
- 하지만 실제 변경을 요청하자 Qwen은 파일을 수정하지 않은 채 충돌 마커가 남아 있는 상태로 `git add mix.lock && git rebase --continue`를 실행하려 했음
- `git rebase --continue`가 에디터를 여는 동작도 인식하지 못했고, OpenCode가 멈췄으며 이 현상은 일회성일 가능성도 있었음
### 로컬 모델의 장점과 한계
- 로컬 모델에는 큰 트레이드오프가 있지만, 인터넷 연결 없이 비행기에서도 작업할 수 있다는 장점이 있음
- 컴퓨터를 어차피 구매한다고 가정하면 비용은 사용 전력으로 제한되고, 구독이 필요하지 않음
- 모델 학습에는 여전히 큰 환경 비용이 있지만, 오픈 모델 회사들은 환경 영향 상위권과는 거리가 있고, 개인 하드웨어를 쓰면 데이터센터 의존이 줄어듦
- 직접 조정하고 실험하는 재미가 있음
- LLM은 이미 큰 영향을 미쳤고 부정적인 면도 많지만 계속 남을 기술로 보이며, 로컬 모델 실험은 이 기술과 더 지속 가능하고 긍정적으로 상호작용하는 방식처럼 느껴졌음
## Comments
### Comment 57235
- Author: neo
- Created: 2026-05-11T20:35:10+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48089091)
- 로컬에서 **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 모델로 기울고 있고, 상당수는 초당 토큰 수는 괜찮지만 첫 토큰까지 걸리는 시간이 끔찍함
- 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라면 더 큰 모델도 돌릴 수 있으니, 모델 지능이 유용성을 높이는 핵심이라면 더 큰 모델을 쓰는 편이 맞을 수 있음
- 같은 사양에서 **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에 수천 달러를 쓰는 쪽이 낫다고 봄
**로컬 모델**은 프라이버시 유출 걱정 없이 언제 어디서든 일을 할 수 있게 해줌