로컬 모델 실행이 이제 좋아졌다
(vickiboykis.com)- 2022년형 M2 Mac 환경에서도 로컬 LLM이 개발 질문, 코드 작업, 문서 확인에 실용적으로 쓰일 만큼 성능이 좋아졌음
- 초기 로컬 모델은 느리고 쓰기 어렵고 프로그래밍 작업 정확도도 낮았지만, GPT-OSS 이후 API 모델로 재확인하는 빈도가 줄어듦
- Gemma 4 계열 최신 릴리스로 로컬 에이전트 코딩 루프가 프런티어 모델 대비 약 75% 정확도·속도로 동작함
- Pi와 LM Studio 조합은 로컬 추론 엔드포인트, 모델 아티팩트, Docker 격리 구성을 통해 에이전트 워크플로를 실행함
- 로컬 모델은 추론 지연, 작은 컨텍스트 창, 하드웨어 제약이 남아 있지만 토큰 처리, 시스템 프롬프트, 양자화, 하네스를 직접 관찰하고 바꿀 수 있음
로컬 모델의 현재 위치
- 초기 로컬 모델은 대부분의 프로그래밍 작업에서 느리고 쓰기 어렵고 정확하지 않았음
- 로컬 모델이 크게 뒤처져 있다는 판단은 개인 사용 기준에서 GPT-OSS 출시 전까지 대체로 맞았음
- “충분히 좋은 모델”의 개인 기준은 API 모델로 다시 확인해야 하는지였고, GPT-OSS는 그 확인 빈도를 크게 줄인 첫 모델이었음
- 로컬 모델은 최근까지 최신성이 필요 없는 개발 질문에 대한 빠르고 개인화된 Google처럼 주로 쓰였음
- Gemma 4 계열 최신 릴리스 이후 로컬에서 에이전트 코딩 루프가 프런티어 모델 대비 약 75% 정확도·속도로 동작함 {p:75}
사용한 모델과 실행 환경
- 2022년형 M2 Mac, 64GB RAM, 1TB 저장공간 환경에서 여러 로컬 모델을 돌렸음
- 사용 모델은 Mistral 7B, Gemma 3, OpenAI OSS-20B, Qwen 3 MOE, Qwen 2.5 Coder 등임
- 실행 구성은 raw llama.cpp와 Open WebUI, llama-cpp-python, Ollama, llamafiles, LM Studio를 거쳤음
- 기본 로컬 모델은 LM Studio의
gemma-4-26b-a4b구현으로 두고 사용했음
실제 로컬 에이전트 작업 사례
- 노트북이던 Python 스크립트를 5~6개 모듈의 저장소로 리팩터링했음
- 해당 모듈은 PEP 585 기준에 맞춰 제네릭 타입 힌트를 쓰도록 린트했음
- 블로그 글 교정, 단위 테스트 작성, 추천용 two-tower 모델 저장소 초기 구성에도 로컬 설정을 썼음
- 빈 상태에서 에이전트가 생성한 two-tower 모델 저장소는 기본적이었지만, 작년에는 가능하다고 생각한 범위를 넘어섰음
- 모든 에이전트 워크플로는 실행 접근 권한이 제한된 Docker 컨테이너 안에서 돌렸음
자원 사용과 최신 소형 모델
- 수행한 작업들은 획기적인 작업이라기보다 개인화된 Google 또는 문서 조회에 가까웠음
- 작업 중 GPU와 RAM 사용량이 커지고 K-V 캐시가 64GB RAM까지 커졌음
- 단순한 작업이라도 이런 종류의 로컬 모델 작업은 6개월 전만 해도 불가능했음
Gemma-4-12b-qat는 출시 직후부터 크기 대비 성능이 인상적이었음- 모델 아키텍처는 성능과 가격 제약이 있을 때 어떤 아키텍처상 절충이 필요한지 질문하게 만듦
로컬 에이전트 모델 실행 구성
- 로컬 에이전트 플로를 실행하려면 로컬 모델 추론 엔진, 에이전트 하네스, 로컬 모델 아티팩트가 필요함
- 하네스는 로컬 추론 엔드포인트를 바라보도록 설정해야 하며, 다운로드한 모델 아티팩트는 추론 엔진을 통해 제공해야 함
- 현재 로컬 구성은 Pi를 에이전트 하네스로, LM Studio를 추론 서버로 사용함
- Pi와 LM Studio로 Gemma 4 에이전트 코딩을 설정하는 글을 따라가되 몇 가지 설정을 바꿨음
- 모델은 글의
Gemma 26B A4B대신 더 최신이고 작고 빠른gemma-4-12b-qat를 사용했으며 정확도 손실은 크지 않았음 - 보안상 모든 Pi 세션은 Docker 컨테이너에서 실행하고 bash 권한만 부여해 Python 코드 실행과 웹 브라우징을 막았음
- 연구 작업용 별도 이미지에서는 curl 허용을 계획함
- Docker 안에서 실행하기 때문에 Pi의
models.json을 수정해 Pi가 모델과 통신하게 했음
- 모델은 글의
Docker 기반 격리 방식
- Pi 설정은
baseUrl을http://host.docker.internal:1234/v1로 두고, API는openai-completions로 설정했음 - Docker Compose 구성은
models.json, 작업 디렉터리, Pi 설정, 세션 디렉터리를 컨테이너에 마운트함 - 실행 스크립트는 현재 작업 디렉터리를 컨테이너의 워크스페이스로 연결하고, 필요하면 더 안전한 샌드박스 Compose 파일을 추가함
- Pi는 작업 중인 저장소에서 실행되며 Docker를 띄우기 때문에 물리 디스크의 파일이나 디렉터리를 직접 지우지 못함
- 커스텀 모델
json설정을 컨테이너 안으로 전달할 수 있어 실험 환경에서 비교적 잘 동작했음
남은 한계
- 로컬 모델은 아직 추론이 느릴 수 있고, 컨텍스트 창은 작으며, 사용 가능한 컨텍스트는 보유 하드웨어에 제한됨
- 생태계는 LM Studio와 Hugging Face의 Use This Model 버튼 같은 도구 덕분에 훨씬 쉬워졌음
- 초기 릴리스는 프롬프트 템플릿 불일치 문제를 겪지만, 이런 문제는 보통 매우 빠르게 패치됨
- 프로덕션 소프트웨어 개발에 바로 쓸 준비가 됐다고 확신하기는 아직 어려움
로컬 모델의 장점과 실험 가능성
- 로컬 모델은 거의 모든 것을 들여다볼 수 있으며, 토큰 추론 과정을 실시간으로 볼 수 있음
- 입력·출력 토큰 흐름을 직접 확인할 수 있음
- 로컬 컨텍스트 창을 바꾸며 성능이 좋아지거나 나빠지는 과정을 확인할 수 있음
- 토큰이 GPU에서 처리되는 방식을 파고들 수 있고, 시스템 프롬프트와 양자화 설정도 바꿀 수 있음
- 모델끼리 맞붙이거나 하네스 쪽 설정을 바꾸고 관찰할 수 있어 실험 가능성이 계속 넓어짐
댓글과 토론
Hacker News 의견들
-
좋은지 모르겠음. 로컬 모델을 많이 쓰지만 여전히 로컬 실행은 꽤 고통스럽다
Qwen 27B, Gemma 31B 같은 밀집 모델은 꽤 똑똑하지만 느리고, Gemma 26B, Qwen 35B, North Mini Code 30B 같은 전문가 혼합(MoE) 모델은 빠르지만 실수가 많음
제대로 돌리려면 메모리가 많이 필요하고, 양자화하면 도구 호출이 약해짐. 대부분 4비트 양자화로 돌려놓고 왜 별로인지 궁금해하는데, 사실상 모델을 뇌엽절제한 셈임. Unsloth 양자화를 추천하고, MoE는 6비트, 밀집 모델은 5비트를 권함
프리필을 빠르게 하려면 연산 성능이 필요하고, 디코드를 빠르게 하려면 대역폭이 필요하며, 전체를 담으려면 메모리도 많이 필요함. 게다가 노트북은 뜨겁고 시끄러운 기계가 되어 작업하기 불편함
그래서 좋은가? 별로는 아님. 작동은 함
덧붙이면 오픈 모델이 미래라고 생각하고 생태계에도 계속 기여 중임. 사람들이 이런 모델을 만져보고pi를 써서 동작 방식을 배우면 좋겠지만, 모델을 내려받기만 하면 바로 좋을 거라고 기대하면 안 됨. 대부분이 원하는 “코딩 에이전트”를 대체하려면 튜닝과 설정을 많이 해야 함- 내 경험도 거의 같음. 비교적 최신 고사양 데스크톱(Radeon 6900 XT 16GB VRAM, Ryzen 9 7900X 12코어, 시스템 RAM 64GB)에서 한두 달 전 ollama로 추천 모델들을 써봤음
코딩 특화가 아닌 모델은 실제 도구 호출을 하지 않고 “이런 행동을 하겠다”고 말만 하는 데서 자주 막혔고, 그 행동을 바꾸려면 뭘 설정해야 하는지 물어봐도 도움이 안 됐음. Qwen은 자신이 ollama에서 실행 중이라는 걸 믿지 않고 Alibaba 클라우드에서 돌고 있으며 로컬 시스템 접근 권한이 없다고 우겼음
코딩용 모델도 내가 타이핑하는 속도보다 겨우 빠르게 생각하는 수준이었고, 생각 과정을 보여줄 수 있는 경우도 제한적이었음
지금까지 찾은 최고의 “무료” 경험은 OpenCode + Big Pickle임. 아주 똑똑하진 않아서 첫 결과가 자주 틀리지만, 무료 티어가 넉넉해서 한 달가량 자주 몇 시간씩 써도 제한에 걸린 적은 두 번 정도뿐임. 진짜 로컬 실행이 목표라면 맞지 않지만, “구독이나 토큰 비용 없이 가장 나은 경험”이 목표라면 지금까지는 가장 덜 나쁜 선택임 - 로컬 모델을 “잘” 돌리려면 여전히 비싼 하드웨어 투자가 필요하다고 봄. 적절한 KV 캐시로 이런 모델을 돌리려면 최신 Blackwell 아키텍처에서 VRAM 96GB 정도는 원하게 됨
통합 메모리 Mac, AI Max AMD 프로세서, DGX Spark 비슷한 장비로 돌리려는 건 고생을 자초하는 쪽에 가까움. 프리필이 성능을 망침
알맞은 GPU를 투입하면 훨씬 나아지지만, 그래도 Sonnet이나 DeepSeek 4 Flash 수준에는 아직 못 미치고, Opus / DeepSeek Pro나 Mythos/Fable/GPT-5.5에는 더더욱 못 감
예산, 전력, 냉각이 충분하면 꽤 괜찮은 데이터 파이프라인은 돌릴 수 있지만, 코드에는 대부분 API 제공자에게 돈을 내는 편이 아직 합리적임 - 이런 모델을 열 제약이 큰 노트북에서 돌리면 안 될 수도 있고, 근접 최첨단 품질을 대형 클라우드 플랫폼 수준의 빠른 추론으로 기대해서도 안 됨
그래도 중앙화 서비스에 크게 의존하지 않기 위해 시도할 가치는 있음 - Gemma 4는 파이프라인/자동화 작업에 특히 좋음
내 경험으로는 규칙 준수나 자동화 스타일 작업에서 Qwen 모델들, 심지어 100B+도 능가함. 이미지 해석도 매우 좋고 벤치마크상 Opus보다 높게 나옴
Qwen은 지시를 무시하고, 토큰 생성 형식을 명시적으로 제한하지 않으면 잘못된 형식을 꾸준히 출력하는 경향이 있음
다만 DGX Spark에서 Gemma 31B Q4 + MTP는 약 20토큰/초, Gemma 26B A4B는 약 60토큰/초 정도라 여전히 꽤 느림. 고급 Nvidia 카드에서는 훨씬 빠르게 돌고 메모리에도 들어갈 것임
로컬 모델을 시작하는 사람에게는 RAM보다 메모리 대역폭에 집중하길 권함. 이제 100B 미만 모델도 자동화에는 충분하고 매우 유용함
코딩/창작 용도에서는 아직 로컬 모델을 써야 할 강한 이유가 없다는 데 동의함. 하지만 주식 목록을 훑고 뉴스 고역통과 필터링을 하거나, 로그 해석, 스크린샷 해석 같은 작업에는 이미 로컬 모델이 충분함 - 어딘가에 모델을 돌리는 머신을 두고 몇 명이 공유하는 편이 더 나을지 궁금함
M6 Mac Studio에 RAM 256GB 정도를 붙여서 몇 명이 합의한 모델 하나에 접근하게 하는 건 정당화할 수 있을 것 같음. 노트북은 이 용도로는 너무 뜨겁고 둔해 보임
- 내 경험도 거의 같음. 비교적 최신 고사양 데스크톱(Radeon 6900 XT 16GB VRAM, Ryzen 9 7900X 12코어, 시스템 RAM 64GB)에서 한두 달 전 ollama로 추천 모델들을 써봤음
-
몇 주 동안 Qwen3.6-27B를 만족스럽게 쓰다가 하드웨어에서 떨어져 있어 현재 Claude Sonnet 4.6을 써야 하는데, 엄청난 다운그레이드처럼 느껴짐
어떻게 이게 가능한지 모르겠음. 요청하지도 않은 강한 의견이 너무 많고, 말이 너무 많으며, 전반적으로 더 멍청하게 느껴짐
물론 훨씬 큰 모델이라 더 많은 지식을 인코딩하겠지만, 대화하기가 싫으면 도움이 안 됨. 게다가 대화할 때 실제 돈도 듦
왜 이렇게 싫은지 궁금함. 자신을 도구가 아니라 거의 동등한 존재로 보는 것 같아서일 수도 있음. 마치 자기 의견에 무게가 있는 것처럼 굴기 때문임
Qwen도 지나치게 의욕적인 인턴처럼 행동할 수 있지만, 바보라고 말해주면 그 자존심을 내려놓음. Claude는 내 경험상 그렇지 않았음
결론적으로 제목에는 전적으로 동의함- 클라우드 추론에는 한 푼도 써본 적이 없어 직접 비교는 못 하지만, Qwen3.6-27B가 코딩 작업에 매우 유능한 로컬 모델이라는 점은 확실히 말할 수 있음
지난 한 달 반 동안 M2 Ultra나 RTX 5090 머신에서 거의 매일 썼음. ggml-org [0]의 작고 평범한 작업에 쓰고 있고, 대단한 건 아니지만 메인테이너에게 확실히 도움이 되는 도구임
PR 리뷰에 시간을 많이 쓰지 않았다면 훨씬 더 많이 썼을 것 같음. 지금은 아주 가벼운 하네스를 쓰는데, 모든 걸 제거한 pi 에이전트(pi -nc --offline)와 내 스타일에 맞추기 위한 짧은 시스템 프롬프트 [1] 정도임
생성 속도는 RTX 5090에서 약 100~150토큰/초, Mac에서 약 40토큰/초임. 훨씬 빠르기 때문에 RTX 머신에서 돌리는 쪽을 확실히 선호하지만, 로컬 설정 테스트와 더 넓은 경험을 위해 Mac에서도 자주 돌림
[0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
[1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS... - Qwen3.6-27B를 매일, 업무에도 주력으로 쓰고 있고 출시 직후부터 거의 계속 사용해왔음. 실행할 수만 있다면 쓸 만한 유일한 소형 로컬 모델이라고 봄
Opus처럼 “큰 기능 X를 추가해줘”에는 덜 좋을 수 있지만, 나는 그런 걸 모델에게 원하지 않음. 내가 생각하고 모델은 타이핑해주길 바람. Qwen 3.6 27B는 그 용도로 완전히 충분함. 내 경험상 35A3B나 Gemma 계열은 상당한 다운그레이드였음
게다가 속도 제한, 할당량, 피크 시간 대기열 걱정이 없음. 전체 생각 과정을 항상 볼 수 있고, 데이터가 어디로 보내지는지 걱정하지 않아도 되며, 몰래 성능이 낮아질 일도 없음
2×3090에서 llama.cpp로 Q6_K_XL + MTP 설정을 쓰며, 프리필 500~1000토큰/초, 출력 60토큰/초, 문맥 창 22만 토큰으로 돌림. 16만 토큰을 넘기면 조금 멍청해지기 시작하고, KV 양자화는 쓰지 않음 - “말이 너무 많다”는 점이 정말 짜증남. 제발 좀 닥치고 간결하게 답했으면 좋겠음
이게 사고 기능의 부산물일 수도 있겠지만, 사고 과정을 훨씬 더 간단히 요약해줬으면 함. 한 문장 답이면 충분한 상황에서도 최첨단 모델들은 최소 5문단을 쓰고 새 방향을 3~5개씩 제안하려고 함
한 번에 한 단계만, 한 번에 하나의 선택지만, 앞으로의 방향을 적극적으로 제안하지 말라고 요청해도 프롬프트로 제대로 제어하기가 정말 어려움
그런데 방금 나도 내가 불평하던 걸 그대로 했네 - Sonnet에서의 경험만으로 일반화하진 않겠음. Claude 계열에서 Opus에 해당하는 플래그십 모델들은 훨씬 더 좋음
- 코딩 에이전트에도 성격이 있다는 게 웃김. 일을 꽤 잘한다는 걸 알아도 피하고 싶은 “그 동료” 같은 성격까지 있음
- 클라우드 추론에는 한 푼도 써본 적이 없어 직접 비교는 못 하지만, Qwen3.6-27B가 코딩 작업에 매우 유능한 로컬 모델이라는 점은 확실히 말할 수 있음
-
프로그래머는 도구에 돈을 내지 않는 데 익숙함. 기본 노트북(SSD, 멀티코어, RAM 16GB)도 C/C++/Rust, 심지어 Python 개발에는 엄청나게 강력함
그런데 갑자기 그걸로는 부족해지고, 다시 남의 컴퓨터를 쓰며 매일 도구를 빌리는 상황으로 돌아감. 더 나쁜 건 매일 다른 모델을 쓰게 되고, 어떤 날은 마피아 같은 세력이 제조사를 압박해서 좋은 도구를 빌릴 수도 없을 수 있다는 점임
다른 직종 대부분은 도구에 상당한 투자를 해야 함. 좋은 도구를 원한다면 GPU 메모리 64GB(예: 2×5090)와 RAM 96GB 정도가 필요함. 전문 엔지니어에게 20만 달러를 지불한다면 2년에 한 번 도구에 5만 달러를 쓰는 것도 꽤 합리적으로 보임 -
Anthropic 같은 회사들이 걱정해야 할 흐름임. 로컬 모델 실행이 쉬워질수록 그들이 받을 수 있는 가격 상한은 점점 낮아질 것임
월 $$$$$를 낼 사람이 아예 없어지진 않겠지만, 많은 사람이 월 요금에 12나 24를 곱해보고 “이 돈보다 싸게 로컬 모델을 구축해서 1~2년 안에 본전을 뽑을 수 있을까?”라고 따질 것임
고객의 상당수가 임대 대신 구매를 선택하면, 임대 중심 사업 모델의 회사들은 갑자기 고객 부족을 겪게 될 수 있음- 지난 20년 동안 클라우드 컴퓨팅에서는 정반대가 벌어졌음. AI 모델에서도 그런 변화는 일어나지 않을 것임
이제 미국식 비즈니스 모델에는 거의 각인되어 있음. 모든 걸 외주화함. 서버실을 직접 관리하고 싶어 하는 사람은 없고, 2~3배를 더 내더라도 그 골칫거리와 책임을 함께 외주화하려 함
AI도 마찬가지일 것임. 그 프리미엄을 Anthropic에 내든 AWS에 내든 같음
나는 비교적 작은 회사에 있는데, 최근 로컬 인프라 관련 장애가 있었음. 지난 5년간 내부 총 다운타임은 최근 대형 AWS 장애 하나보다도 훨씬 적었는데도, CEO는 이제 자체 인프라 호스팅은 신뢰할 수 없다는 압박을 줬음
모두가 잡일과 책임을 벗어던지고 싶어 함 - Netflix에 돈 내는 것과 토렌트로 받아 Plex를 돌리는 것의 차이와 비슷할 수 있다고 생각했음
보통의 주류 사용자는 이미 설정되어 있고 바로 쓸 수 있는 것에 돈을 낼 가능성이 높아 보임. 더 기술적이거나 의지가 강한 사람들은 직접 하겠지만, 두 집단의 비율이 어느 정도일지가 궁금함 - 코딩 비중이 큰 회사들이 언제쯤 온프레미스 AI 클러스터를 직접 돌리기 시작할지 궁금함
엔지니어링 팀이 어딘가 벽장에 넣어두고 원하는 모델을 돌릴 수 있는 4GPU 머신 같은 걸 파는 아이디어가 이미 있었는지 모르겠음
모두에게 매력적이진 않겠지만, 하이퍼스케일러들이 사람들의 데이터를 빨아들여 모델 학습에 쓴다는 신뢰 문제가 생긴 상황이라, 투명하게 통제할 수 있고 필요하면 직접 가서 플러그를 뽑을 수 있는 머신과 모델에 가치를 느끼는 곳도 있을 것임 - 이런 로컬 모델은 비최첨단 모델이 하는 일 일부는 할 수 있지만, 내게는 그 가치가 크지 않음
Sonnet 4.6만 써도 월 20달러 요금제로 거의 하루 종일 일할 수 있음. 그리고 Sonnet은 M2 Mac에서 자체 호스팅할 수 있는 모델보다 여전히 훨씬 강력함
모두가 토큰 사용량 과금으로 바뀌면 생각이 달라질지도 모르지만, 구독 기준으로는 재정적으로 맞지 않는다고 봄
재미는 있음. 하지만 경제적으로 타당하진 않음 - 그들은 로컬에서 아무것도 못 돌리게 만들려고 열심히 움직이고 있음
OpenAI가 현물 시장의 RAM을 전부 사들이면서 RAM/VRAM 가격이 6배 오르고, GPU와 괜찮은 컴퓨터가 대다수에게 닿기 어려워짐
부유한 일부는 512GB Mac Studio나 RTX Pro 6000 한 장을 1만3000달러에 사서 꽤 괜찮은 로컬 모델을 돌릴 수 있겠지만, 대다수는 API를 써야 할 것임
어느 순간 Nvidia가 “6000을 그렇게 많이 팔지 않으니, 데이터센터 전용 GPU에서 4배 이익을 낼 수 있으니 그냥 취소하자”고 할 수도 있음. 그러면 구할 수 없는 물건이 되고, 개인이 최첨단보다 약 1년 뒤처진 수준의 괜찮은 모델을 로컬에서 돌리는 일은 불가능해질 수 있음
- 지난 20년 동안 클라우드 컴퓨팅에서는 정반대가 벌어졌음. AI 모델에서도 그런 변화는 일어나지 않을 것임
-
그걸 써서 나온 코드를 보여줬으면 좋겠음. 로컬 모델을 쓰고 싶고 하드웨어도 있지만, GPT 5.5 xhigh나 Opus 같은 최첨단 모델 대체로 써보면 아직은 대체할 준비가 안 됐음
품질과 걸림돌 때문에 작업 흐름이 너무 느려지고, 도구 호출 문법까지 망칠 때가 있음
다만 더 작고 잘 정의된 흐름이나 “이 부분을 정확히 이렇게 바꿔라” 같은 편집에는 충분해 보임. 지금의 최첨단을 대체할 만큼 성숙해지길 기다리고 있고, 그때가 전환 시점이라고 봄
로컬 모델 얘기라면 DiffusionGemma, 그리고 확산 모델 전반을 로컬 사용에서 과소평가하면 안 됨. 보통 로컬의 문제는 LLM이 요청을 배치로 묶어 여러 개를 동시에 돌리지 않는 한 하드웨어를 효율적으로 못 쓴다는 점인데, 그러려면 접근 방식 자체가 달라져야 함. 반면 확산 모델은 단일 프롬프트에서 훨씬 빠르고, 그 차이가 작지 않음
오늘 마침 diffusiongemma-26B-A4B-it 지원을 Transformers에서 Candle로 포팅했고, 몇 가지 최적화까지 더해서 추론 중 Candle에서 약 450토큰/초(약 19반복/초)로 날아다니는 수준이 됨. HF Transformers 라이브러리에서는 약 180토큰/초(약 11반복/초)였음. 비슷한 크기의 LLM을 vLLM으로 돌려도 단일 프롬프트에서 250토큰/초를 넘긴 적은 없었던 것 같아, 로컬 모델로서는 흥미로운 일임- 확산 모델은 저~중간 크기 이상으로는 제대로 학습하기 어렵고, 같은 크기의 일반적인 한 토큰씩 생성하는 모델보다 품질이 낮음
-
2600달러면 카드당 RAM 32GB, 전력 약 285W인 AMD 9700 GPU 두 장을 살 수 있음. 비용과 전력 모두 5090보다 낮음
AITER 패치를 적용한 VLLM 빌드를 쓰면 Qwen3.6 27B FP8을 Opencode나 PI의 실제 코딩 세션에서 전체 문맥 창으로 약 45~50TPS 정도 돌릴 수 있음
30B급 밀집 모델이 더 많이 계속 나오길 정말 바라지만, Qwen3.6만으로도 에이전트 작업을 꽤 많이 처리할 수 있음
다만 ROCm 스택은 직접 파고들어 패치할 의지가 없는 사람에게는 맞지 않음 -
왜 사람마다 “좋은” 에이전트 코딩의 기준이 그렇게 크게 다른지 궁금함
한편으로는 “Apple Music에서 ‘Set a Timer’ 재생하기” 수준의 지능에서 튜링 테스트를 통과할 수도 있는 수준까지 온 건 정말 놀랍지만, 실용적으로 보면 작은 모델들은 기술 데모 이상을 “좋다”고 부르기엔 아직 멀었음
내게 7B 모델은 Wikipedia의 흐릿한 메아리일 뿐임. 4비트 Gemma 모델은 도구 호출용 JSON을 안정적으로 생성하거나 패치 적용을 위해 코드 한 줄을 복사하는 것조차 너무 서툼
Qwen은 파멸 루프에 빠지거나 맥락을 잃지 않게 하려면 너무 많은 세부 지시와 보살핌이 필요해서, 내가 줘야 하는 지시가 최종적으로 남기는 코드보다 더 길 때가 많음
내가 모르는 마법의 프롬프트가 있는 건가? 아니면 다른 사람들이 훨씬 인내심이 많거나 기대치가 훨씬 낮은 건가?- 나도 비슷한 의문이 있었음. 기대치가 다른 이유는 작업 부하가 다르기 때문이라고 봄
작은 스크립트, 글루 코드, 단순한 CRUD 변경에서는 Qwen3.6-27B 같은 작은 모델이 더 크고 지저분한 코드베이스에서보다 훨씬 잘 작동할 수 있음 - 기준이 낮은 면은 있고 시간이 갈수록 더 낮아지지만, 설명한 설정은 내 경험상 아직 너무 낮음
27/35B급 Qwen/Gemma를 FP8로 돌리면 gemini-2.5보다 낫지만 gemini-3.1보다는 못함. DS4-flash FP8은 DGX Spark 두 대에서 돌릴 수 있고, 상황은 계속 좋아지고 있음. DiffusionGemma는 최근 토큰 생성 속도가 4배로 나왔음
요약하면 써본 모델들이 너무 작거나 양자화가 과한 것으로 보임
- 나도 비슷한 의문이 있었음. 기대치가 다른 이유는 작업 부하가 다르기 때문이라고 봄
-
로컬에서 두 모델을 돌리는 걸 좋아함. qwen3.6 27B 8비트(밀집)와 qwen3.6 35B 4비트(전문가 혼합)임
27B가 더 똑똑하고 신뢰할 수 있지만 느림. 35B는 더 빠르고 여전히 매우 똑똑하지만 27B보다는 아래이며 조금 덜 안정적임. 이유는 전문가 혼합(MoE) 아키텍처라 일부 매개변수만 활성화해서 모델이 훨씬 빨라지기 때문임
27B는 MacBook Pro M5 Max + GPU 코어 40개 + RAM 128GB에서 돌림. 이 괴물에서는 27B와 35B를 동시에 메모리에 올리고도 다른 작업을 위한 여유가 있음. 하지만 노트북이라 로컬 LLM을 항상 돌리기는 불가능함. 너무 뜨겁고 시끄러워짐
더 흥미로운 건 MacMini M4 RAM 64GB에서 35B 모델을 돌리는 것임. 빠르고 많은 일을 처리함. 예를 들어 이메일을 스캔·추출·분류하고, 메일함을 계속 감시하며 작업함. 개인 Hermes 어시스턴트로도 써서 “다음 Starship 발사는 언제야?”, “오늘 월드컵에서 누가 경기해? 잡지식도 알려줘” 같은 걸 물어봄
다음 계획은 지하실에 둘 RTX Pro 6000 Blackwell 워크스테이션임. Qwen을 아주 빠르게, 여러 스레드/프롬프트/에이전트로 동시에 돌리고 싶음. 예산이 허락하면 2×RTX Pro 6000 구성으로 DeepSeek v4 flash를 돌려 연구에 쓰고 싶음- 그 “Hermes”용으로 Brave 검색 API 키 같은 걸 받은 건가?
- RTX 6000 Pro는 정말 갖고 싶지만, Claude Max 10년치 가격이면 어떻게 정당화할 수 있음?
-
일상적으로는 Qwen3.6:27b를 호스팅하지만, deepseekv4 flash를 정말 호스팅하고 싶음. 크기/속도/가격 대비 너무 “좋은” 모델임
회사들이 언제쯤 모든 개발자에게 구독료를 내는 대신, 일상 작업용 모델을 온프레미스로 호스팅하기 시작할지 궁금함. 충분히 좋고 비교적 저렴함 -
묻진 않았지만, 우리 중 누구도 코드 작성이나 거의 어떤 일에도 최신 최고 수준 모델을 써서는 안 된다고 생각함
대신 특정 작업용 오픈 모델을 개발하고, 뼈로 된 손가락과 살로 된 뇌로 코딩하고 글 쓰고 그림 그리는 법을 배워야 함
대기업과 연구시설은 출력이 맞는지 검증할 전문가들을 붙여 코드나 수학 등을 생성하는 데 쓸 수는 있겠지만, 그마저도 비용 대비 가치가 없을 수 있음. 예를 들어 OpenAI가 작년에 360억 달러 순손실을 냈고, 오픈 모델은 이미 꽤 근접했으며 AI 전체 계획은 더 이상 끌어낼 사기가 바닥나고 있음
아주 작은 모델로도 쓸 수 있는 일은 많고, 미친 수준의 연산력과 메모리가 필요하지 않은 작업도 많지만, 그런 쪽을 제대로 연구하는 사람이 너무 적음