MacBook에서 발생하는 몇 가지 문제들을 해결하는 데 도움이 될 만한 정보를 공유합니다. 누군가에게 유용하기를 바랍니다. 저는 몇 주 동안 충돌, 형편없는 성능, 그리고 여러 문제들 때문에 머리를 쥐어뜯으며 고생했습니다. 게다가 문제를 해결하기 위해 Google의 힘을 빌리는 데 너무 고집을 피우기도 했죠. 로컬 AI (Local AI)를 구축하는 방법들을 찾는 데 즐거움을 느끼는 사람치고는, 일을 어렵게 처리하는 것을 선호한다는 점이 다소 아이러니하네요...

저는 64GB RAM을 탑재한 14인치 MBP M2 Max에서 Qwen3.6 35b A3B를 실행하고 있으며, 이는 현재 차트를 점령하고 있는 대부분의 로컬 모델들을 돌리기에 충분하다고 느껴집니다. 현재 131k 컨텍스트 (Context)를 사용 중이며, 거대한 컨텍스트로 세션을 다시 불러올 때 발생하는 1~2분의 긴 프롬프트 처리 시간 (Prompt processing time)을 감수할 수 있다면 더 높게 설정할 수도 있습니다. 그렇지 않은 경우, KV 캐시 (KV cache) 등의 덕분에 컨텍스트가 터무니없이 커져도 (예: 100k 이상) 프롬프트 처리는 보통 3초에서 40초 사이이며, 속도는 대부분 환상적입니다 (생성 속도 49 tokens/sec, 프롬프트 처리 400+ tokens/sec). (Qwen3.6 35b a3b)

제 설정은 미세 조정 (Fine-tune)을 거쳐 안정화하기까지 몇 주가 걸렸습니다. 그래서 MacBook에서 로컬 모델과 에이전틱 워크플로우 (Agentic workflows)를 실행하는 데 어려움을 겪는 분들에게 도움을 드리고자 이 내용을 공유하기로 했습니다. 동료, 친구, 그리고 제가 어떻게 Qwen3.6을 안정화하여 지금처럼 사용할 수 있었는지 묻는 분들로부터 엄청난 양의 메시지를 받았기 때문입니다. (저는 꽤 큰 프로젝트를 진행 중이며, Qwen3.6이 로그를 모니터링하고 자동으로 문제를 해결 및 수정하는 에이전트(Agents)를 운용하는 것까지 포함하여 프로젝트의 핵심 동력 역할을 하고 있습니다. 이는 다소 무서운 생각이기도 하네요...)

그럼, 간단한 요약부터 말씀드리고 아래에 더 자세한 설명을 적겠습니다...

• 디스플레이 재생률 (Display refresh rate)을 ProMotion에서 60Hz로 변경

• MLX가 아닌 GGUF 모델을 사용

• llama.cpp 또는 LM Studio (내부적으로 llama.cpp를 사용함)로 실행. Ollama는 느리고, 솔직히 말해서 형편없습니다.

• iogpu.wired_limit_m을 통해 메모리 와이어 제한 (Memory wire limit)을 높임. 제 64GB 노트북의 경우, 이 값을 61440으로 설정했습니다.

• Qwen3.6 35b A3B 모델을 사용하되, q4 또는 q6 양자화 (Quant) 버전을 사용하세요. 재미있게도 저는 q4가 때때로 정밀도 (Precision) 면에서 약간 더 나은 경우가 있다는 것을 발견했지만, 여전히 두 버전 사이에서 고민하고 있습니다. preserve_thinking이 활성화되어 있는지 반드시 확인하세요. 이것이 없으면 모델이 루프 (Loop)에 빠지거나, 도구 호출 (Tool calls)에 실패하며, 마치 술 취한 원숭이처럼 작동할 것입니다. MTP 버전은 사용하지 마세요. 당연히 사용해야 할 것처럼 보일 수 있지만, 실제로는 토큰 생성 속도를 높이는 것이 아니라 오히려 늦춥니다.

• OpenCode를 사용하세요. Claude Code가 아닙니다. OpenCode 내에서 모델의 제한 사항을 필요에 맞게 적절히 설정해야 합니다. 예를 들어, 출력 토큰 제한 (Output token limit)은 기본값이 낮게 설정되어 있어, 도구 호출을 위한 인자 (Arguments)가 잘려 나가면서 도구 호출 실패나 루프와 같은 현상이 발생할 수 있습니다.

• MCP를 통해 RAG 및 지속적 메모리 (Persistent memories)를 활용하세요. 저는 제가 직접 구축 중인 커스텀 솔루션으로 넘어갔지만, Serena MCP를 사용했었고 지금도 가끔 사용하는데, 믿을 수 없을 정도로 훌륭합니다.

• OpenCode의 SKILLS 기능을 활용하고, 복잡한 리팩토링 (Refactor) 및 기능 구현 시 메모리를 자동으로 사용하기 시작하는 커스텀 에이전트를 만드는 능력까지 활용해 보세요. 저는 이 개념 덕분에 단 64k의 컨텍스트 크기 (Context size)로 52k 라인의 코드베이스에서 놀라운 일들을 해낼 수 있었습니다.

결과: 저는 Qwen3.6 35b a3b를 사용하여 프롬프트 처리 (Prompt processing) 속도는 490 tok/s, 생성 (Generation) 속도는 49~65 tok/s로 실행하고 있습니다. 80k 이상의 토큰이 담긴 완전히 차가운 KV 캐시 (KV cache) 상태에서 이전 세션을 열면, 해당 프롬프트를 처리하는 데 약 1.5분이 소요됩니다. KV 캐시 히트 (Cache hits)가 발생하는 후속 프롬프트는 2초에서 30초 사이이며, 어떤 이유로든 캐시 재사용에 실패하는 극단적인 경우에는 약 50초가 걸립니다. 하지만 파일을 읽는 등의 작업 시에는 더 이상 전체 컨텍스트를 처리하지 않으며, 이 작업은 매우 빠르게 수행됩니다 (참고로 특정 프로젝트의 경우 제 시스템 프롬프트만 거의 50k 토큰에 달하므로, 결과는 상황에 따라 다를 수 있습니다). 종합적으로 볼 때, 저에게는 GHCP를 통한 Claude보다 실제로 더 빠르므로 성공적입니다.

이제, 더 자세한 분석을 살펴보겠습니다:

1. MLX - 저는 사용하지 않습니다. 불안정합니다. 특히 서멀 스로틀링 (Thermal Throttling)이 발생하는 14인치 MacBook에서는 더욱 그렇습니다. 저는 GGUF 모델을 고수하며, 여기에는 타당한 이유가 있습니다. GGUF는 모델과 KV 캐시 (KV Cache) 모두를 위해 메모리를 사전에 모두 할당 (Pre-allocate)하므로, 메모리 사용량을 확인했을 때 보이는 수치가 실제로 사용될 양입니다. 반면 MLX는 온디맨드 (On-demand) 방식으로 할당하며, 프롬프트 처리가 끝난 후 메모리 사용량이 떨어지는 것을 확인할 수 있습니다. 그러다 프리필 (Prefill) 및 토큰 생성 (Token Generation) 단계 동안 메모리 사용량이 다시 꾸준히 상승합니다. 이러한 대규모의 끊임없는 할당/해제/할당/해제 과정은 시스템이 캐시를 회수하는 과정에서 혼란을 야기하며, 이 시간 동안 GPU 코어의 속도를 저하시킵니다. WindowServer에는 GPU 코어에 신호를 보내는 "Interactivity Watchdog"가 포함되어 있는데, 만약 코어가 특정 밀리초 (ms) 내에 응답하지 않으면 커널 모듈 (Kernel Module)이 모델을 강제 종료하며 Interactivity Timeout에 관한 오류가 발생합니다. 이것이 일부 사용자들에게 MLX가 매우 불안정하게 느껴지는 이유입니다. 또한 14인치 모델은 서멀 스로틀링 (Thermal Throttling)이 시작되기 때문에, 코어가 작동하는 속도 자체가 감소하여 상황을 더욱 악화시킵니다. 그래서 저는 GGUF를 고수하며, 모델 충돌이 전혀 발생하지 않습니다 (적어도 더 이상은 말이죠).

2. 상호작용 와치독 (interactivity watchdog)은 단 한 가지 경우를 제외하고는 조정, 설정, 비활성화 또는 그 어떤 것도 할 수 없습니다. 바로 디스플레이가 없는 경우입니다. 만약 노트북을 닫고 디스플레이가 전혀 없는 클램쉘 모드 (clamshell mode)로만 실행하면서, 단순히 SSH로 접속하거나 그 위에서 실행 중인 API를 통해 모델에 접근한다면, 와치독 문제는 절대 발생하지 않을 것입니다. 디스플레이가 없다면 와치독은 디스플레이를 신경 쓰지 않기 때문입니다. 하지만 솔직히 말해서, 이는 대부분의 사용자에게 실용적이지 않습니다. 그렇다면 비결은 무엇일까요? 주사율 (refresh rate)을 ProMotion에서 60Hz로 변경하십시오. 이렇게 하면 두 가지 변화를 느낄 수 있습니다. 첫째, 프롬프트 처리 및 토큰 생성 속도가 급격히 상승합니다. 이는 GPU 메모리가 통합되어 있고, ProMotion은 초당 약 120번 디스플레이를 새로고침하기 때문입니다. 120Hz에서 60Hz로 낮추면 WindowServer가 사용하는 메모리 대역폭 (memory bandwidth)을 정확히 절반으로 줄일 수 있으며, 이렇게 절약된 대역폭은 이제 모델이 사용할 수 있게 됩니다. 또한 와치독의 응답 시간 임계값 (response time threshold)도 두 배로 늘어나, 8ms 대신 타임아웃이 16ms가 됩니다. 더 이상 상호작용 타임아웃 (interactivity timeouts)은 발생하지 않습니다.

이는 많은 요소 사이의 균형을 맞추는 작업이며, 제가 앞서 Qwen의 MTP 버전을 피하라고 말씀드린 이유이기도 합니다. 예를 들어, 토큰 처리 및 생성 속도의 저하는 GPU 코어를 그만큼 더 점유하게 만들며, 상호작용 와치독이 모델을 강제 종료하지 않기를 바라며 시간과의 싸움을 벌이는 한계 상황으로 당신을 몰아넣습니다.

3. 냉각 (Cooling). OS X의 기본 팬 임계값 (fan thresholds)은 형편없습니다. Mac Fans 앱을 사용하여 모든 GPU 클러스터 센서(제 모델은 2개의 클러스터가 있습니다)에 대해 팬의 사용자 정의 트리거를 설정하십시오. 낮은 온도는 50도, 높은 온도는 80도(°C)로 설정해야 합니다. 이렇게 하면 GPU 코어가 50°C에 도달하면 팬이 낮은 속도로 작동하고, 80°C에 도달하면 최대 속도로 작동하게 됩니다. 결과적으로 온도가 약 8182°C를 넘지 않고 대부분 7980°C 부근에서 유지될 것입니다. 더 이상의 서멀 스로틀링 (thermal throttling)은 없습니다.

4. 유선 메모리 제한 (wired memory limit)을 조정하세요. 기본적으로 Mac OS X는 통합 메모리 (unified memory)의 최대 85%까지만 GPU 사용을 위해 유선 메모리로 할당할 수 있도록 허용합니다. 모델 구동에는 문제가 없지만, WindowServer나 Chrome과 같이 GPU를 사용하는 다른 요소들도 존재합니다. sysctl iogpu.wired_limit_m을 통해 이 제한을 높일 수 있습니다. 시스템을 위해 최소 10GB는 남겨두라고들 하지만, 저는 약 8GB를 남겨두었으며 아무런 문제 없이 안정적으로 사용했습니다. 심지어 4GB까지 줄여보았으나 안정성 문제는 없었습니다만, 이는 개인차가 있습니다. 모델을 실행하는 동안 무엇을 함께 실행하고 있는지에 따라 달라집니다.

5. 러너 (runner)가 중요합니다. llama.cpp를 사용하거나, GUI를 원한다면 LM Studio를 사용하세요. LM Studio는 내부적으로 llama.cpp를 사용합니다. 유일한 차이점은 커맨드 라인 옵션 (command-line options)에 대한 세밀한 제어력이 훨씬 떨어진다는 점입니다. 예를 들어, 저희는 LM Studio에서 MTP를 사용할 수 있게 될 때까지 6시간을 기다려야 했습니다 (제 생각에 Qwen MoE 모델 같은 경우에는 무관한 기능이었습니다). ollama는 피하세요. 그냥 느립니다. 또한 모델을 조각난 레이어 (chunked sharded out layers) 형태로 다운로드하는데, 이는 다른 러너에서는 전혀 사용할 수 없는 방식이며 제 개인적인 의견으로는 매우 좋지 못한 방식입니다. 저는 제어권을 위해 개인적으로 llama.cpp를 사용하지만, 모델을 다운로드할 때는 시각적으로 깔끔한 레이아웃을 선호하기 때문에 LM Studio를 사용합니다. 하지만 솔직히 말해서, Qwen을 발견한 이후로는 어차피 다른 모델은 다운로드하지 않고 있습니다.

6. 모델별 특이사항: 만약 qwen3.6 35b a3b를 사용 중이라면: 사람들이 루핑 (looping) 문제나 도구 호출 (tool call) 문제 등에 대해 불평하는 것을 보았습니다. 이는 거의 전적으로 여러분의 설정 문제로 귀결됩니다. 우선, preserve_thinking이 활성화되어 있는지 확인하십시오. LM Studio를 사용 중이라면 추론 (inference) 탭 아래에 있습니다. 만약 llama.cpp를 사용하거나 Jinja 템플릿을 수동으로 지정해야 하는 다른 도구를 사용 중이라면, 템플릿에 set preserve_thinking = true를 추가하기만 하면 됩니다. 이는 에이전트 워크플로 (agentic workflows)에서 절대적으로 중요합니다. 이것이 설정되지 않으면 다른 모든 도구 호출을 망가뜨리고 처참하게 실패하게 만들 것입니다. 또한, 여러분의 하네스 (harness)가 문제인지도 확인하십시오. OpenCode는 기본적으로 최대 토큰 출력 제한 (max token output limit)이 설정되어 있으며, 이는 심각한 문제를 일으킵니다. 도구 호출의 인자 (arguments)가 잘려나가서 호출이 실패하고, 결과적으로 실패한 도구 호출이 반복적으로 루핑되는 것을 방지하려면 OpenCode 설정 (config)을 통해 제한 값을 높이고 미세 조정해야 합니다.

7. Claude Code를 Claude 모델이 아닌 다른 모델과 함께 사용하지 마십시오. 저는 그들이 여러분이 그렇게 시도하게 유도하여, 형편없는 경험을 하게 만든 뒤 다시 자신들의 모델로 돌아가게 만들려는 것이라고 확신합니다. 간단히 말해서, 그들의 모델 없이는 그렇게 잘 작동하도록 개발되거나 설계되지 않았습니다. 경험은 매우 저조할 것이며, 여러분은 로컬 LLM (local LLM)을 포기하고 싶어질 것입니다.

8. RAG 및 영구 메모리 (persistent memories)를 사용하세요. Serena MCP는 해당 분야를 시작할 수 있게 해주는 즉시 사용 가능한 (turnkey) 솔루션입니다. 이는 시맨틱 인덱싱 (semantic indexing), 검색, 읽기 및 쓰기 기능을 제공하여 컨텍스트 크기 (context size)를 대폭 줄여줄 뿐만 아니라, 모델이 필요한 정보를 훨씬 더 빠르게 찾을 수 있도록 도와줍니다. 영구 메모리는 다양한 방식으로 사용될 수 있는데, 제가 만든 에이전트 중에는 엄청나게 큰 코드베이스 (code-bases)를 다루는 것이 유일한 목적인 것들이 있습니다. 저는 이 에이전트들이 메모리를 활용하여 전체 프로젝트 계획, 하위 작업 (sub-tasks), 패치/디프 (patches/diffs)를 생성하고, 모든 것을 파악한 후 전체 계획을 실행하도록 합니다. 이를 통해 저는 52,000줄 규모의 코드베이스를 완전히 리팩터링 (refactor)할 수 있었고, 전체 코드베이스에 걸쳐 총 1,600줄에 달하는 기능을 추가했으며, 문자 그대로 아무런 문제 없이 즉시 모두 작동하게 만들었습니다. 64k 컨텍스트 (context) 환경에서도 말이죠 (개인적으로 저는 보통 131k를 사용합니다).

9. QWEN 모델과 KV 캐시 (KV cache)에 대하여: KV 캐시를 q8보다 더 작게 양자화 (quantize)하지 마세요. 만약 q4로 내려간다면, 모델은 지적 능력이 현저히 떨어지게 될 것입니다. 저는 q4_K_M과 같은 양자화된 모델을 말하는 것이 아닙니다. 그것은 아주 훌륭한 모델입니다. 저는 명시적으로 K/V 캐시 양자화 (KV cache quantization) 옵션에 대해 말하고 있는 것입니다. 가능하다면 그대로 두거나, 양자화하더라도 q8보다 낮추지 마세요. 모델은 q8 양자화에는 내성이 있어 정밀도 손실 (precision loss)이 최소화되지만, q4에서는 전혀 제대로 작동하지 않습니다. 양자화를 하면 메모리 사용량을 어느 정도 절약할 수 있다는 점은 염두에 두되, 정말로 메모리 사용량을 줄여야만 하는 상황에서만 이 작업을 수행하세요. 저는 64GB RAM 환경에서 131k 컨텍스트와 함께 모델의 q6 버전을 실행하고 있으며 (솔직히 말해서, 웃기게 들리겠지만 q4가 조금 더 "똑똑할" 수도 있다고 생각합니다), 메모리 사용량이 제가 인지할 수 없을 정도로 적습니다. 저는 여전히 10개 이상의 탭이 열려 있는 Chrome, Word, VS Code, 몇 개의 터미널, 메일 및 세상의 온갖 것들을 거의 문제없이 열어두고 사용하고 있습니다.

메모리 압력 (Memory pressure)이 나타나고 실제로 메모리가 부족한 상황이 아니라면, KV 캐시 (KV cache)를 양자화 (Quantize)할 이유는 없습니다. 그렇게 할 경우 오히려 더 많은 성능 문제를 일으킬 뿐입니다.