• 데이터 프라이버시와 LLM의 무료 사용을 이유로 클라우드 모델을 완전히 떠난 개발자들이 등장 중이며, 컨테이너화·샌드박스화된 오프라인 코딩 하니스로 외부 네트워크 호출 없이 작업 가능
  • 주력 모델은 Qwen3.6 35B-A3B(활성 파라미터 3b로 빠른 속도)와 27B 덴스 모델로, 코딩 정확도와 토큰 생성 속도 간 트레이드오프 존재
  • Pi 하니스와 llama.cpp가 가장 많이 언급되는 조합이며, 도구 호출(tool calling)이 로컬 모델에서 처음으로 일관되게 작동한 점이 사용 경험을 크게 개선
  • Claude Opus 대비 로컬 모델은 "가이드가 필요한 주니어 vs 함께 설계하는 시니어" 수준 차이로, 정밀한 프롬프트와 작업 분해가 필수
  • 현재 로컬 모델은 약 8~18개월 전 프론티어 수준으로 평가되나, 무료·프라이버시·할당량 걱정 없음이라는 실질적 이점 제공

로컬 모델 전환 사례와 하드웨어 구성

  • Qwen3.6 35B-A3B를 Mac Studio 128GB 또는 MacBook 36GB RAM에서 Pi 하니스로 구동, Django + Wagtail 기반 웹사이트 홈페이지·블로그 전체 재설계 완료
    • 인터넷 접근 없이 덜 알려진 Wagtail 개발 시 모델이 항상 방법을 알지는 못함
    • 복잡한 작업에는 Qwen3.5 122b 사용하나 활성 10b 파라미터로 상당히 느림
  • Strix Halo 128GB 통합 메모리 환경에서 Pi를 컨테이너로 격리, 자격증명 없이 작업 디렉토리만 접근 허용
    • 채팅·번역은 Gemma 4 31B, 오디오는 Gemma 4 12B 사용
    • Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, GPT-OSS 120B 등 다수 모델 보유하나 코딩은 35B-A3B가 최적
  • 5년 전 제작한 듀얼 RTX3090 머신에서 Qwen·Gemma 모델을 UD-Q4_K_XL 양자화로 ~150tok/s 달성, 300k 컨텍스트 전체를 VRAM 내 처리
    • $100/월 Claude 구독을 대체했고 개인 용도로는 무료가 우선
    • 안드로이드 TV 런처, k8s 관리 포털, 홈어시스턴트 통합, 식료품·식단 관리 등 다양한 프로젝트 수행
  • RTX 6000으로 Qwen 3.6 27b + Open Code 조합, 코딩 90% 처리하나 매우 복잡한 작업과 UI 폴리싱은 Codex로 회귀
    • 256k 컨텍스트에서 100k 초과 시 품질·속도 저하, 150k 이후 심각해짐
  • RTX 5090에서 Qwen 3.6 27b(Q6 양자화) + llama.cpp, GPU를 600W→450W로 제한해 정숙성 확보
    • 브랜치 커밋·PR 생성, Stripe CLI 인보이스 정산, Elasticsearch 부하 분석 등 일상 업무로 확장

모델 종류와 성능 특성

  • MoE vs 덴스 모델 구분이 코딩 품질에 직접 영향
    • Qwen3.5-122B는 실제로 122B-A10B로 10B만 활성화되는 MoE, Qwen3.6-27B는 27B 전체가 항상 활성화되는 덴스 모델
    • MoE 활성·전체 파라미터의 기하평균으로 덴스 등가 품질 근사 가능, sqrt(35×10)≈18.7
    • MoE는 같은 크기 대비 품질은 낮으나 속도가 빠르며, CPU RAM 오프로드로도 큰 MoE 구동 가능
  • 양자화 수준이 루프 발생과 정확도에 영향
    • Q8 양자화는 느리지만 루프를 줄여 전체 시간 절약
    • KV 캐시의 K 부분 양자화에 매우 민감, F16 K + Q8 V로 루프 대폭 감소
  • 듀얼 GPU 추가는 추론 속도가 아닌 VRAM 용량 확보가 목적
    • Gemma-4 31B 덴스와 26B MoE 모두 Q4 양자화 시 유사 품질이나 MoE가 ~3배 빠름(150tok/s vs 46tok/s)

로컬 모델의 한계와 대응 전략

  • 정밀한 프롬프트 필요

    • 가정을 열어두면 모델이 최단 경로(예: HTML 내 CSS)를 택해 아키텍처 측면에서 최선이 아닌 결과 산출
    • 아키텍처를 명시하지 않으면 빠르고 지저분한 수정을 하며, 디버그 문장 제거를 지시하지 않으면 남겨둠
    • Claude Opus는 사용자 의도를 추론하나 작은 Qwen 모델은 지시한 것만 수행, 설계 지식을 명시적으로 "활성화"해야 함

  • 루프 및 편집 도구 오류

    • 편집 도구 호출을 자주 틀리고, 재시도 대신 사고 토큰을 소모하며 파일을 재독해
    • 직접 재시도가 편집 호출을 고치는 경우가 많으나, 모델이 문제를 더 근본적이라 가정해 불필요한 토큰 소비
    • 해시 기반 편집 접근(각 코드 라인 해시 참조)으로 편집 오류 감소 가능하나, 컨텍스트 품질 소진 후 다른 방식으로 붕괴
    • AGENTS.md 규칙으로 재작성 대신 편집을 제한하면 부분적 개선

  • 컨텍스트 윈도우 관리

    • 65,000 윈도우는 코드 파일 구조 읽기만으로도 초과, 200k 이상 필요
    • Qwen3.6-35b는 256k 컨텍스트를 16gb VRAM에서 128k로 정상 처리
    • Qwen3.6-27B는 100만 토큰 컨텍스트 지원, DGX Spark에서 f16 KV 캐시로 약 100GB 메모리 소요

프롬프트 캐싱과 추론 보존 문제

  • Qwen 하이브리드 모델이 프롬프트 캐싱을 처리하지 못하고 매 턴 컨텍스트 전체를 재처리하는 문제 발생
    • 대부분의 로컬 모델은 턴 간 전체 추론 보존 학습이 안 되어, 긴 도구 호출 체인 후 추론이 제거된 채 재처리 필요
    • Qwen 3.6은 추론 보존을 학습해 chat-template-kwargs = {"preserve_thinking": true} 설정으로 캐시 재사용 개선
  • 현대 LLM은 풀 어텐션만 쓰지 않고 로컬 어텐션(슬라이딩 윈도우, Mamba-2 상태공간 모델) 사용
    • 풀 어텐션은 O(n²)로 비용이 크고 시간에 따라 값이 교체되는 추론에 약함
    • 로컬 어텐션은 스냅샷을 저장해 캐시 재계산 시 마지막 스냅샷부터 시작, 단 스냅샷이 크면 보관 한계 존재
    • Qwen 3.5 이상은 어텐션과 SSM 레이어를 교차하는 Gated DeltaNet 사용
  • Vulkan이 ROCm보다 역설적으로 빠르며 llama.cpp 최신 버전 유지가 재처리 문제 해결에 중요
  • 자기회귀 생성 토큰이 프리필 시 다르게 파싱되는 토크나이저 발산 문제는 해결이 어려움

비용·전력 경제성 논쟁

  • 2x RTX3090은 약 $4400으로 $100/월 Claude 기준 3.6년치, 전력·기타 부품 미포함
    • 3.6년 후에도 고용량 GPU 가격은 유지될 가능성 높음
    • 손익분기점이 약 1년인 고전력 비용 지역도 존재
  • 전력 소비는 예상보다 낮은 편
    • 1.2kw 풀가동 시 약 $0.12/시간, 솔라 연결 시 더 저렴
    • 추론 부하는 게임과 달라 전력 문제 미미, 시스템 유휴 200W·추론 350-450W 수준
  • 하드웨어 구매 시점 관련
    • 현재는 구매 적기 아니며 24-36개월 후가 다음 적기로 전망
    • 48gb 통합 RAM M4 Pro Mac mini ~$2k가 예산형 추론 장비로 추천, ~150tok/s로 향후 10년 사용 가능
    • AMD R9700 32gb VRAM ~$1200-1400이 2x 9070보다 AI 용도에 유리
  • 렌트(클라우드 구독)도 정당한 전략이며, 모두가 하드웨어에 큰돈을 투입할 수는 없음

프론티어 모델 대비 평가

  • 로컬 모델은 "8~12개월 전 엣지 모델 품질" 수준이라는 평가가 반복
    • 벤치마크상 Qwen 3.6 35B-A3B가 Claude 4 Opus를 능가하나, 일부 오픈소스 모델의 벤치맥싱 가능성 존재
    • 한 YouTube 브라우저 OS 테스트에서 Qwen 3.6이 Claude 4 Opus보다 더 많은 작동 기능 생성
    • 다만 1년 전 프론티어 모델 기준이며, 3B 활성 MoE는 최신 Opus·Sonnet과 비교 불가라는 반론도 강함
  • "Opus 급"의 정의 불일치가 논쟁의 핵심
    • 2024년 Claude 3 Opus부터 명칭 사용, Opus 4.8·4.6 최신 모델과는 여전히 격차
    • 작년 11월 Opus 4.5·GPT 5.2에서 프론티어 모델의 단계적 도약 발생, 통상 "Opus 급"은 4.5 이후를 의미
    • 가장 큰 오픈 가중치 모델은 8x H100 서버급 하드웨어 필요, 가정용 모델은 아직 미달
  • 일부는 로컬 모델을 Haiku 4.5~Sonnet 4.5 사이로 평가, 마이크로매니징 시 좋은 결과 산출
  • 프론티어와 로컬 간 격차는 항상 존재할 가능성, 단 많은 사용자에게 로컬은 이미 실용적 수준

하니스와 워크플로 전략

  • Pi 하니스가 가장 많이 추천되며 에이전트 개발 키트 성격, "Claude의 vscode에 대한 neovim" 비유
    • 기본 도구(파일 접근·편집·bash) 제공, MCP 어댑터·웹 검색 확장 추가 가능
    • /tree 명령으로 실패한 도구 호출 이전으로 컨텍스트 복귀, /new로 컨텍스트 초기화
  • 계층적·역할 분담 워크플로로 한계 보완
    • 프론티어 모델로 스펙·설계·실행 계획 작성, 로컬 모델로 구현하는 분업 구조
    • 에이전트를 역할별로 연결(프로젝트 매니저·스키마 에이전트·코딩 에이전트), 오케스트레이터와 Playwright로 오류만 다음 단계 전달
    • 작업을 원자적 TODO로 분해하고 참조 파일을 명시해 컨텍스트 절약
  • OpenCode는 매 턴 시스템 프롬프트를 변경해 KV 캐시와 호환 안 되는 경우 존재, 로컬 LLM 지원 설정이 수동적·복잡
  • Ollama는 클라우드 모델 추가와 수익화로 비판받으며 llama.cpp·llama-swap 권장, macOS는 llm-mlx가 10-15% 더 빠름

구체적 설정 공유 사례

  • AMD 7900xtx 24gb + 5950x + 64gb DDR4 환경에서 Qwen3.6-27B-MTP-UD-Q4_K_XL을 llama.cpp Vulkan으로 구동
    • 주요 플래그: -ngl 99(전 레이어 GPU 오프로드), -c 80000(80K 컨텍스트), --cache-type-k q8_0 --cache-type-v q8_0(8비트 KV 캐시), -fa on(플래시 어텐션), --spec-type draft-mtp(MTP 드래프트)
    • 샘플링: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0(Qwen 코딩 권장값)
    • 성능: 토큰 생성 ~65t/s, 프롬프트 처리 ~600t/s, 콜드 스타트 ~30초
    • Crush 하니스 + Headroom + Exa MCP 웹 검색 조합으로 개인 Claude Code 구독 해지
  • V100 32GB에서 Qwen3.6-27B-UD-Q4_K_XL + Pi, llama-cpp-turboquant 포크와 MTP 패치 적용
    • 200,000 컨텍스트, --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3로 45-60 t/s
  • Strix Halo 128GB에서 Qwen3.6-35B-A3B, 프롬프트 처리 ~800tps·토큰 생성 50tps, 유휴 시 전력 거의 소비 안 함
    • 122B 버전 미출시로 아쉬움, 통합 메모리 환경에서 덴스 모델은 메모리 대역폭 한계로 느림
  • 상세 정보 부족에 대한 불만도 제기되며, 양자화·파라미터·컨텍스트·GPU·VRAM·하니스 구성의 구체적 명시 요구