macOS에서 로컬 코딩 에이전트 설정하는 방법

벤치마크 프롬프트가 “unified diff를 파싱해 변경된 파일 경로를 반환하는 간결한 Python 함수를 작성하고, 엣지 케이스 두 가지를 설명하라”였고, 각 벤치마크가 약 128토큰을 생성했다면 좋은 결과를 얻기엔 128토큰이 너무 적어 보임
MTP 가속은 예측 토큰이 얼마나 자주 채택되는지에 달려 있는데, 경험상 출력 초반부는 채택률이 더 높아서 짧은 테스트가 거짓 양성 가속을 만들 수 있음
llama.cpp에는 서버를 재시작하고 프롬프트를 보낼 필요 없이 인자를 훑어주는 벤치마크 전용 도구가 있음: https://github.com/ggml-org/llama.cpp/blob/master/tools/llam...
모델 다운로드 섹션도 llama.cpp의 -hf 인자가 모델을 대신 내려받아 준다는 점을 언급했어야 함. 작성자가 경험을 공유한 건 고맙지만, 초보자에게는 최선의 가이드가 아닐 수 있음

제대로 된 개발자 가이드로 쓴 글은 아니었음. 화면 녹화가 즐겨찾기를 많이 받고 설정 방법을 묻는 메시지가 오기 시작해서, 이 테스트를 어떻게 구성했는지 빠르게 정리한 것임
Unclothe의 “속도 2배” 발표를 보고 “이 정도면 실제로 쓸 만큼 빨라질까?” 싶어서 직접 설정해 봤음
작년에도 Devstral 같은 걸로 테스트했지만 너무 느리고 멍청해서 계속 써 볼 마음이 안 들었고, 이번에는 드디어 속도와 지능 모두에서 쓸 만하다는 느낌에 도달함

현실적으로는 임의의 사용자 프롬프트에 더해 충분한 시스템 프롬프트까지 넣고 실험해야 함. 최소 1000토큰 이상, 실제로는 3000토큰 정도가 좋아 보임
llama.cpp에는 이를 위한 도구가 있고, 제대로 측정하려면 토큰 생성 전에 프리필(prefill) 을 넣어야 함. 점점 32k나 64k 같은 긴 문맥에서의 토큰 생성 속도 측정도 중요해지고 있음

128토큰이면 오페라가 아니라 서곡만 벤치마크하는 셈임

실제 문제를 살피지 않고 “내 컴퓨터에서는 돌아감”이라고 말하는 것과 비슷함. 128토큰은 정말 아무것도 아니고, 짧은 인사 응답보다 조금 긴 수준임

llama.cpp만 쓴다면 무언가를 다운로드하려고 huggingface-cli가 꼭 필요하진 않아 보임. -hf ...를 넘기면 모델을 내려받아 줌
다운로드 위치를 바꾸려면 LLAMA_CACHE를 설정하면 됨: LLAMA_CACHE="models" ./llama-server \ -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \ ...

드래프트 모델에는 -hfd를 쓰면 됨

통합 메모리 RAM은 크지만 테라플롭스와 대역폭 GB/s가 중간 이하라면 보통 MoE가 가장 희망적임. 내 환경인 M2 Max 96GB에서 (지능, tok/s, 문맥 깊이) 기준 현재 1위는 DeepSeek-V4-Flash REAP25 <65gb gguf + ds4-server + pi agent임
물론 클라우드 API보다 낫진 않지만, 필요하다면 감수하고 쓸 만큼은 됨. 인터넷 없는 4시간 비행에서도 로컬 LLM이 60W를 먹는데 배터리가 충분히 버텼음
REAP을 지원하는 ds4 브랜치는 여기 있음: https://github.com/ljubomirj/ds4/tree/reap-compact-support
DS4F가 784K 문맥에서야 10 tok/s 미만의 사용 불가 수준으로 떨어지는 점이 큰 차이를 만듦

이런 로컬 모델이 특정 프로그래밍 언어에 전문가가 아닌 사용자에게도 정말 문제를 해결해 줄 수 있을지 궁금함
인라인 자동완성이나 단위 구현을 넘어서, 실제로 작동하는 기술 명세를 설계하고 조합할 수 있는지 확신이 안 듦

그걸 일상용으로 쓰고 있나? Claude Code의 프롬프트가 엄청 커서 로컬 모델에서는 프롬프트 처리에 아주 오래 걸리고, 얼마 지나지 않아 문맥도 다 써버리게 됨

omlx.ai로 내 하드웨어에 맞는 여러 MLX 모델을 다운로드하고, 그 모델로 오픈소스와 폐쇄형 하네스(Claude Code, Codex)를 자동 실행하는 데 꽤 성공적으로 썼음
웹 또는 데스크톱 UI에서 모두 가능해서, 개인적으로는 omlx를 쓰면 블로그 글을 따라 할 필요가 없음

64GB M1 Max에서 oMLX나 MLX가 llama.cpp의 GGUF보다 특별히 유리한 점은 못 봤음
지금까지 찾은 Gemma 4 MLX 빌드는 같은 양자화에서 더 느렸고, MTP에서는 훨씬 느렸음
모델을 고른 뒤에는 llama.cpp의 내장 웹 UI가 꽤 좋고, 이것저것 만져볼 때는 LM Studio도 괜찮음
Gemma-4와 Qwen 3.6은 일반적인 opencode 시스템 프롬프트의 큰 덩어리가 전혀 필요 없으며, 빼는 편이 더 나음

Mac에서 로컬 추론을 위한 최첨단이라고 봄. 회귀가 생겨도 개발자들이 엄청 빠르게 대응하고, 최근 본 오픈소스 프로젝트 중 가장 인상적임

antirez의 ds4로 돌리는 DeepSeek v4 Flash가 꽤 인상적이었음
“저장된 지식” 측면에서는 GPT-4급 모델처럼 느껴지지만, 긴 흐름의 도구 호출은 GPT-4급 모델들보다 더 잘함
128GB MBP M4 Max에서 생성은 약 24 t/s, 프리필은 약 200 t/s가 나옴. 느릴 줄 알았고 코드 생성 같은 작업에서는 실제로 느리지만, 간단한 작업을 위한 머신 오케스트레이터로는 놀랄 만큼 유용함
에이전트형이 아닌 용도에서는 대화하기에 충분히 괜찮은 모델이고, 완전히 자체 구동·비공개라는 장점도 있음
[0]https://github.com/antirez/ds4

매우 게으르게 하고 싶다면 터미널에서 Claude Code를 열고, 이 글을 가리킨 다음 그냥 “해줘”라고 시키면 됨

이제 Google 검색을 거의 안 하게 됨. 10번 중 9번은 정보 품질이 형편없고, 주변의 스팸 속에서 필요한 내용을 가려내기 어렵기 때문임
반면 Claude는 한 번에 처리하거나 아주 조금만 다듬으면 바로 해줌
지식과 실행으로 가는 관문은 이제 LLM이고, Google Search는 공룡처럼 느껴짐
스마트폰보다도 더 멋질 정도로, 한 세기쯤 미래에 와 있는 느낌임