Ask HN: 일상적인 코딩에서 Claude/GPT를 로컬 모델로 대체한 사람이 있나요?

 (news.ycombinator.com)
9P by GN⁺ | ★ favorite | 댓글 3개
  • 데이터 프라이버시와 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·하니스 구성의 구체적 명시 요구

함께 보면 좋은 글 β

kirinonakar   [-]

요즘 minimax m3도 괜찮은 것 같습니다. 코딩은 deepseek 4 flash 보다 낫고 무료로도 많이 푸는 것 같고요.

답변달기
b89kim   [-]

Pi-coding-agent+Qwen3.6-27B-MTP-GGUF 썼을때 Sonnet 4.5 정도의 성능이었습니다. 간단한 앱 만드는데 충분하고 필요할 경우 무료 API(GLM5.1 등) 가끔 붙여 썼습니다. 4090/5090급 GPU 소비전력이 크긴한데 제대로 짠 agent면 시간 단위로 돌릴 일은 많지 않더라구요.

답변달기
GN⁺   [-]
Hacker News 의견들

  • Greenpants: 데이터 프라이버시와 무료 LLM이 중요해서 Pi 코딩 하네스를 컨테이너·샌드박스에 넣고 완전 오프라인으로 씀
    Mac Studio 128GB나 MacBook 36GB에서 Qwen3.6 35B를 쓰며, 활성 파라미터가 3B라 꽤 빠름. Django + Wagtail로 홈페이지와 블로그를 전면 재설계했는데, Wagtail은 덜 알려져 있어서 인터넷 없이 에이전트가 항상 잘 알지는 못함
    복잡한 일에는 Qwen3.5 122B도 썼지만 활성 10B라 훨씬 느림. Claude 같은 대형 모델과 비교하면 질문을 아주 정확히 해야 하고, 비워둔 가정은 보통 쉬운 길로 처리해 CSS를 HTML에 넣는 식의 아키텍처상 아쉬운 선택을 함
    편집 도구 호출도 자주 틀리고 루프에 빠짐. Qwen3.6 35B는 전반 지식은 있지만 계속 이끌어줘야 하는 주니어, Claude Opus는 아키텍처를 같이 고민하는 시니어에 가까움. Opus가 15배 가속이라면 완전 오프라인 Qwen은 5배 가속 정도지만, 무료라는 점을 생각하면 여전히 놀라움

    • lambda: 비슷하게 Pi를 컨테이너에서 돌리고, 다른 컨테이너의 llama.cpp와 연결해 씀
      네트워크 접근은 허용하지만 자격 증명은 막고, 작업 디렉터리와 ~/.pi만 접근하게 함. Strix Halo 128GiB 통합 메모리 노트북을 쓰며, 독점 도구로 프로그래밍하는 걸 선호하지 않아 프런티어 모델과 본격 비교는 못 함
      아직 AI 회의론자라 실제 사용보다 모델을 깨보고 강약점을 살피는 시간이 많지만, 에이전트 코딩에는 Qwen 3.6 35B-A3B를 가장 자주 고름. 일반 채팅·번역은 Gemma 4 31B, 오디오는 Gemma 4 12B를 자주 씀
      Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7, GPT-OSS 120B도 보관하지만, 이런 구성에서 코딩에는 Qwen 3.6 35B-A3B가 현재 sweet spot에 가까움
    • geophile: 거의 같은 경험임. 계획을 매우 조심스럽게 세우고, 작은 독립 단계로 쪼개야 하며, 설계도 사람이 명확히 써줘야 함
      세부를 qwen이 알아서 채우게 두면 작성 직전 루프에 빠짐. 편집을 못 하는 문제도 이상해서 AGENTS.md에 재작성보다 편집을 제한하도록 바꿨고, 조금 도움이 됨
    • adyavanapalli: 편집 도구에는 각 코드 줄을 해시하고 치환 시 그 해시로 참조하는 해시 기반 방식을 고려할 만함
      접근법은 https://blog.can.ac/2026/02/12/the-harness-problem/에서 볼 수 있음. 제대로 벤치마크하진 않았지만 체감상 편집 오류가 줄었고, 환경에 따라 다를 수 있음

  • horsawlarway: 개인 용도로는 Claude 월 100달러 구독을 끊고, unsloth studio를 가리키는 pi harness와 Qwen·Gemma 모델로 대체함
    약 5년 전 만든 듀얼 RTX3090 머신에서 unsloth/Qwen3.6-35B-A3B-MTP-GGUF와 unsloth/gemma-4-26B-A4B-it-GGUF를 UD-Q4_K_XL 양자화로 돌리며, 둘 다 약 150tok/s와 300k 전체 문맥을 VRAM 안에서 처리함
    Claude만큼 좋지는 않지만 무료이고, 개인 용도에서는 그 차이가 크게 문제 되지 않음. 같은 추론 서버에 OpenClaw도 붙여 쓰는데 로컬 모델에 꽤 잘 맞는 사용처임
    예로 Android TV 대체 런처, k8s 서비스용 관리자 포털, Home Assistant 통합·자동화, 장보기·식단 관리, ComfyUI 3D 에셋 생성 워크플로 등을 만듦. 돈 버는 소프트웨어라면 여전히 유료 제공자를 추천하겠지만, 로컬 모델도 꽤 멋진 일을 할 수 있음

    • rootlocus: RTX3090 두 장은 약 4,400달러라서, 전기요금과 다른 부품을 빼도 Claude 월 100달러 기준 3.6년치임
    • kpw94: gemma를 UD-Q4_K_XL로 양자화해 돌린다면 unsloth/gemma-4-26B-A4B-it-qat-GGUF 같은 QAT 모델도 확인해볼 만함
      https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF와 https://blog.google/innovation-and-ai/technology/developers-... 참고. 6월 9일 업데이트로 MTP 지원도 추가됨
    • twothreeone: 같은 unsloth/Qwen3.6-35B-A3B-MTP-GGUF를 단일 3090, 128k 문맥, Q4_K 양자화로 돌려봤고 40~60tok/s 정도 나옴
      가장 거슬린 건 중간 정도 복잡도의 실제 코딩 작업에서 출력 품질이었음. “프롬프트로 밀기”와 “직접 구현” 사이를 계속 전환해야 해 인지 전환 부담이 컸고, 내가 잘못 시키는 건지 모델이 부족한 건지 몇 분마다 판단해야 했음
      낮은 수준 구현 세부에서 높은 수준 설계로 넘어가는 것도 잘 못해 표 같은 것도 쉽게 렌더링하지 못함. Claude에서는 이런 문제가 없어 지금은 대체재로 보기 어렵고, 몇 달 뒤에는 가능해지길 바람. aider로 Claude CLI를 대체했는데 이 선택도 최적은 아닐 수 있음

  • bluejay2387: 코딩의 약 90%를 Qwen 3.6 27B와 Open Code, 커스텀 스킬, Semble로 처리함
    CC나 Codex만큼 똑똑하진 않지만 대부분의 일은 끝낼 수 있음. RTX 6000이 있어서 TPS는 충분히 빠르고, 원래 이 GPU는 다른 작업용이었음
    프런티어 모델에 얼마나 가까이 갈 수 있는지 실험해본 건데 충분히 좋아 계속 쓰게 됨. 정말 복잡한 일이나 UI 다듬기는 여전히 Codex로 돌아가며, Qwen에서 UI가 가장 약해 보임
    추천은 아님. RTX 6000이 있는 사람이 많지 않고, 비용은 MAX CC나 Codex 구독 여러 해치가 됨. 그래도 가능성은 보이며 몇 년 뒤엔 실용적일 수도 있음
    256k 문맥에서 compact target을 75%로 맞췄고, 대화가 100k를 넘으면 품질과 속도가 떨어지기 시작하며 150k 이후엔 매우 문제가 됨. Qwen 3.5 122B도 써봤지만 3.6 27B보다 코딩이 훨씬 못했음. Gemma 4 31B는 다른 작업에 좋지만 코딩은 Qwen이 앞서고, Nemotron Super 120B도 코딩은 Qwen보다 못해 의외였음

    • heipei: RTX 5090에서 llama.cpp로 Qwen 3.6 27B Q6를 돌리고, 이제 pi agent만 씀
      로컬이라 토큰 가격, 할당량, 시간대, 데이터 민감도를 전혀 신경 쓰지 않아도 됨. GPU 전력을 600W에서 450W로 제한했더니 추론 중에도 아주 조용함
      코딩뿐 아니라 일상 잡무에도 많이 쓰게 됨. 브랜치에 커밋하고 PR 만들기, Stripe CLI로 미수·연체 인보이스 받아 은행 CSV와 대조하기, Elasticsearch 자격 증명으로 현재 부하 원인 요약하기, 코드베이스가 X를 지원하는지와 구현 위치 찾기 같은 일을 시킴
    • bo1024: Qwen3.5-122B는 실제로 Qwen3.5-122B-A10B임
      A10B는 전문가 혼합 모델이라 한 번에 10B 파라미터만 활성화되고, Qwen3.6-27B는 모든 27B 파라미터가 항상 활성화되는 밀집 모델임. 그래서 많은 작업에서 27B 밀집 모델이 122B-A10B보다 나을 수 있음
    • user43928: 직장에서 Qwen 3.6 27B를 강제로 쓰는데 거의 쓸모없다고 느낌
      직접 하는 편이 낫고, 구현은 엉망으로 만들거나 디버깅을 완전히 틀림. 더 똑똑한 검색 기능 정도를 빼면 Sonnet 미만은 시간 낭비처럼 느껴짐
      Codex를 UI 다듬기에 쓴다는 것도 이상함. Codex는 UI가 나쁘기로 유명하고 Claude Opus보다 한참 뒤처짐. Altman도 다음 모델에서 이 부분을 개선 중이라고 올렸음

  • pierotofy: Llama.cpp + Qwen3.6-35B(MTP) + OpenCode 조합은 단일 RTX 3090에서 꽤 유능하고, 대부분의 클라우드 모델보다 빠름
    품질은 8~12개월 전 엣지 모델을 쓰는 느낌임. 설정은 https://github.com/pierotofy/LocalCodingLLM/에 정리함

    • jacobgold: “8~12개월 전 엣지 모델 품질”이면 취미 용도로는 훌륭하지만, 전문 개발자가 코딩 에이전트의 주력으로 쓰기엔 Opus 4.6이 나온 6개월 전쯤이 임계점이었다고 봄
    • trueno: 128GB M4 Max MacBook Pro가 있어서 이걸 만져보고 싶은데 시간이 잘 안 남
      비슷한 구성을 쓰는 Mac 사용자 경험이 궁금함. 로컬 쪽 논쟁은 많이 보지만 기준점이 계속 바뀌고 용어도 익숙하지 않음. 로컬로 가며 무엇을 잃고 얻는지 객관적으로 느낀 점을 알고 싶음
    • atomicnumber3: 이제 Claude를 쓸 마음이 전혀 없음

  • codinhood: 이 질문에는 “진짜” 답이 많이 안 나올 것 같음. 지금은 최신·최고 모델을 안 쓰는 기회비용이 너무 큼
    매달 조사해도 결론은 같음. 로컬 모델과 주변 코딩 도구를 Claude Code의 Sonnet/Opus에 가깝게 만들 시간·노력·비용이 아직은 가치가 없음
    가치가 있었다면 이미 뉴스가 될 만큼 파괴적이었을 것임. 누군가 해결했을 가능성을 부정하는 건 아니지만, 깊은 토끼굴에 빠지지 않으려는 오컴의 면도날에 가까움

    • pyeri: 그 기회비용 FOMO 열차에도 포화점이 올 것이고, 이미 지났다고 봄
      Mythos급 모델은 추론 최첨단이지만 대부분 개발자가 풀려는 문제 영역에는 별 쓸모가 크지 않음. 현재 Sonnet/Opus 계열 4.8 전후가 결국 기업에서 널리 쓰이는 수준이 될 가능성이 큼
      로컬 모델은 아직 거기까지는 아니지만 DeepSeek, Kimi, GPT, MiniMax 계열을 NVIDIA, OpenRouter, Groq 같은 API로 저렴하게 쓸 수 있고, 이들은 꽤 Sonnet급임
    • mark_l_watson: 같은 결론이 맞아 보임. 로컬, OpenCode + DeepSeek v4 flash 같은 상용 API, DeepSeek v4 Pro로 이어지는 계층형 시스템으로 옮기려 함
      이렇게 하면 필요한 일은 계속 처리하면서 점진적으로 더 많이 로컬로 옮길 수 있음. 같은 하드웨어에서도 로컬 설정이 2개월 전보다 훨씬 좋아졌고, 6개월 전과 비교하면 극적으로 나아짐
    • gunapologist99: 오컴보다 파레토를 생각해볼 만함
      몇 년 안에 도달할 거라고 정말 믿는다면 지금부터 만져보는 게 낫고, 특히 짧거나 작은 프로젝트, 잘 모듈화된 큰 프로젝트에서는 꽤 놀랄 수 있음

  • sosodev: 이 질문은 능력과 기대치의 범위가 너무 넓음. 8B 모델만 돌리면서 바이브 코딩이나 원샷을 기대하면 힘듦
    약 30B급 모델을 돌릴 수 있다면, 범위가 적절하고 정의가 잘 된 작업에서는 꽤 잘함. 현재 이 범위에서는 Gemma4-31B와 Qwen3.6-27B가 가장 좋아 보임
    더 빠른 추론을 원하면 MoE 모델로 바꿀 수 있지만 대부분 작업에서 눈에 띄게 떨어짐. 작은 범위 작업은 원샷·바이브 코딩도 가능하지만 여전히 안내가 있으면 훨씬 낫다
    프런티어급 능력을 원하면 적어도 128GB 메모리와 큰 연산량 또는 많은 인내심이 필요함. 대부분은 돈이나 인내심이 부족함. 로컬 모델의 인내심은 토큰 기다리기만이 아니라, 자신의 워크플로와 하드웨어에 맞게 설정하고 제대로 돌리는 노력까지 포함됨

    • argee: M4 Pro, 48GB RAM MacBook에서 Gemma 4 26B A4B로 Rust 공부와 여러 질문을 처리함
      IDE나 하네스에서 아주 사소한 변경 말고 원샷을 잘할 거라고 믿지는 않음. 그래도 사람이 운전대를 잡고 도로를 보며 제한속도 아래로 달리는 조건이라면, 작은~중간 문맥 작업의 코파일럿으로는 빠르고 충분히 좋음
      몇 년 전과 비교하면 놀랍고, 이게 아니었다면 AI로 코딩을 거의 안 했을 것 같음. 인터넷 연결이 끊겼다고 둔해지거나 막히는 느낌은 싫음
    • user43928: 작은 모델, 특히 GPT 5.4 Mini로 10~20줄 코드 변경을 다른 파일로 옮기게 했는데 두 번째 시도에도 코드를 바꾸고 버그를 넣음
      완벽한 신뢰성은 기대하지 않았지만, 차이를 짚어주면 적어도 두 번째에는 맞출 줄 알았음. 실제로는 코드가 같아졌다고 자신 있게 말하면서 또 다른 미묘한 버그를 추가함
      이런 쓰레기급 모델이 충분한 작업이 무엇인지 모르겠음. 몇 분간은 유능한 척할 수 있지만 결과는 결국 맞지 않음. 기껏해야 더 똑똑한 검색이나 자동완성 정도에 적합하다고 봄

  • mgsram: 1년 정도 로컬 LLM을 쓰다가 이제 Mac Studio 512GB RAM에서 Qwen3.6 27B 밀집 GGUF, OpenCode, llmster(LM Studio) 조합에 정착함
    Qwen 3.6 35B-A3B도 써봤지만 밀집 모델의 정확도가 한 단계 높고, 대신 토큰/초를 희생함. Qwen3.6 27B는 보통 25~40tok/s 정도 나옴
    처음엔 간단한 도구에 썼지만 최근 3~4개월은 C/C++ 자동차 소프트웨어 스택과 Python 도구에서 프로덕션급 코딩에 실제로 사용 중임. 속도가 낮은 것도 오히려 적절한 속도로 진행하게 해줌
    신규 개발·재작성은 Sonnet과 설계·아키텍처·추론·상세 실행 계획을 함께 만든 뒤, 이를 조각내서 정밀하게 프롬프트로 넣음. 기존 코드 작업은 판단이 필요하고, 로컬 모델의 한계를 느끼면 Claude Code로 돌아감
    최근 Qwen 3.6으로 기존 C++ 코드를 참고한 C 기반 전원 관리 서비스 전체 재작성, 복잡한 Excel 명세 파서, CJK 내용을 영어로 번역해 KG에 넣는 도구를 만들었음

  • 3abiton: 다들 Qwen을 언급했으니 나도 Qwen 3.6 35B Q8(MTP) 를 Strix Halo와 llama.cpp로 돌림
    40~50t/s 정도 나오고 성능이 정말 좋음. zsh에서 forge-code와 직접 써봤고, 긴 문맥 150k 이상에서는 품질이 떨어지고 잊기 시작함

  • wsintra2022: 여기 댓글을 읽다 보면 AI 제공업체 편에서 로컬을 말리려는 봇인지, 실제로 로컬 AI 모델에서 안 좋은 경험을 한 사람인지 구분이 안 됨
    Mac Studio 64GB에서 Qwen 3.6 27B 8k 양자화를 돌리는 건 프런티어급 만능 초능력은 아니고 그냥 좋음. 무료이고 사적이며, 숙련 엔지니어를 게으름에서 더 게으름으로 보내주는 게 마법임
    llama.cpp와 opencode를 쓰며 코드 변경을 계획하고 실행시킨 뒤, 해먹에 눕거나 설거지하거나 다른 일을 함. tmux와 ssh로 들어가 확인함. 이 지점이 진짜 놀라운 부분임

    • epolanski: 소프트웨어 “엔지니어링” 업계에는 MIT Leetcode 닌자가 React+Tailwind로 메모리 새는 못 쓰는 슬롭을 쓰는 경우가 많아서, 기준선이 매우 낮음

  • garethsprice: Ada 4000 20GB VRAM에서 OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM을 쓰고, 생성은 55tok/s 정도 나옴
    OpenCode가 문맥을 많이 붙이기 때문에 체감은 숫자보다 느림. Pi도 많이 언급돼서 곧 살펴볼 예정임
    Opus로 계획을 만들고 로컬 에이전트가 따르게 한 뒤, Opus로 검증함. 100% 로컬은 아니지만 이 모델들이 점점 프로덕션 워크플로 일부가 되고 있음
    아직은 취미로 시간과 돈을 들여 만지는 걸 좋아하는 사람이 아니면 할 만하지 않을 수 있음. Opus나 다른 프런티어 모델만큼 좋지는 않지만 반복 작업이 늘어나는 범위에서는 “충분히 좋음”
    Rolls Royce가 없어도 중고 Corolla로 슈퍼마켓은 갈 수 있음. 프런티어 LLM으로는 비용이 부담되는 새 워크플로도 가능해짐. 밤새 Chrome devtools MCP로 사용자처럼 퍼즈 테스트를 돌리고, 멀티모달로 스크린샷까지 확인하게 했는데 Claude+스크린샷 비용을 생각하면 놀라움
    “프런티어보다 12~18개월 뒤”라는 말이 맞아 보임. 12~18개월 뒤에는 5천 달러 미만으로 로컬 Opus급 모델을 돌릴 수 있을 듯하지만, 프런티어 모델도 더 앞서 있을 것임

  • arjie: 로컬도 아니고 대화형 코딩도 아니지만, RTX Pro 6000 Blackwell 두 장으로 DeepSeek V4 Flash를 돌림
    원시 속도는 160tok/s지만 추론 모델임. 내 용도는 코드 자동 작성과 다른 시스템의 자동 리뷰임. Pi로 가끔 코드를 쓰게 하면 매우 빠르지만, 습관 때문에 주로 CC와 Codex를 계속 씀

    • akersten: RTX Pro 6000 Blackwell을 어디서 구했는지 궁금함
      찾은 사이트들은 전부 품절이거나 기업에만 팔거나, 수상해 보였음
    • leptons: 이 장비의 전력 소비량을 측정해봤는지 궁금함. 월 비용이 얼마나 나올지 신경 쓰임

  • stymaar: Qwen3.6-35B-A3B를 Strix Halo 128GB Bosgame M5에서 돌림
    이 모델에 비해 VRAM은 너무 많지만 Qwen이 내 하드웨어에 가장 맞을 122B 버전 Qwen3.6을 내놓지 않았음. 대신 전기요금은 거의 무시할 수준임. 원래 노트북 칩이라 유휴 시 거의 안 먹고, 프롬프트 처리 중에도 120W 조금 넘는 정도임
    Qwen3.6은 의외로 효과적이어서 Claude는 가끔, 전체 필요의 10% 정도만 씀. 가장 저렴한 플랜으로도 할당량 아래에 머무를 수 있음. 속도는 프롬프트 처리 약 800tps, 토큰 생성 50tps이며 추측 디코딩은 쓰지 않음

    • manmal: 27B 밀집 버전도 써봤는지 궁금함. 코딩에는 훨씬 좋음

  • Kostic: 개인 용도로 VSCode와 llama.cpp를 연결해 Qwen 3.6 27B나 Gemma 4 31B를 돌리는데, 클라우드 구독을 끊을 만큼 충분함
    Qwen은 첫 번째 GPU에서 q4@176k 문맥, MTP로 70~50tok/s 정도라 코딩에 꽤 좋음. Gemma는 두 GPU를 모두 쓰며 q8@64k 문맥으로 문서 감성 분석, 요약, 교정, 번역을 25tok/s로 처리함
    배치 워크플로에는 조금 느리지만 쓸 만함. llama.cpp가 tensor split 모드에서 MTP를 지원하면 더 늘릴 수 있을 듯함
    직장에서는 비용을 내가 내지 않으니 여전히 프런티어 LLM을 쓰고, 당연히 더 좋음. 1년쯤 뒤에는 Sonnet 4.6/Opus 4.5 수준의 30B 모델이 나오길 바람
    프롬프트 처리는 800t/s에서 시작해 400t/s까지 떨어짐. 보통 시작 프롬프트가 16k~24k 토큰이라 처리에 60~90초가 걸리며, 좋진 않지만 받아들일 만함

  • jodoherty: RTX Pro 6000 Blackwell에서 Gemma 4 31B를 Pi로 돌려 모든 에이전트 코딩에 씀
    유용하다고 느끼며, 이 사이드 프로젝트가 직장에서 프로젝트를 범위 잡고 처리하는 방식과 비슷함: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    신중한 아키텍처와 TDD를 많이 적용해야 함. 어려운 부분을 초기에 처리해 단순하고 쓰기 쉬운 인터페이스로 감싸 기술 리스크를 제거함
    어떤 프로젝트는 직접 작성할 때보다 2~3배 빠르고, 지루하거나 범위가 넓은 프로젝트에서는 아이디어를 빠르게 모으고 시도하게 해 5~10배 시간을 줄여줌
    설정은 nvidia/Gemma-4-31B-IT-NVFP4를 쓰는 vLLM과, MTP가 있는 unsloth/gemma-4-31B-it-qat-GGUF를 쓰는 llama.cpp를 오감. GPU 전력은 400W로 제한함. 현재 llama.cpp 구성은 MTP draft 수락률에 따라 60~150t/s, prefill은 문맥 길이·깊이에 따라 1500~4000t/s 나옴

  • jborak: RTX 5070 네 장과 1세대 AMD Threadripper 1950X로 Qwen3.6 27B MTP Q6_K를 llama.cpp에서 돌리고, Pi 일상 드라이버로 잘 씀
    속도는 50~60tok/s 정도임. OpenWeb UI 같은 다른 앱도 연결하고, 최근엔 LLM 게이트웨이 Bifrost를 모델 접근의 기본 진입점으로 설정함
    Qwen3.6 35B A3B도 써봤지만 코딩은 27B가 더 잘 맞음. 밀집 모델이라 느리지만 품질이 훨씬 좋아 보임. 35B A3B는 non-MTP로 130~140tok/s라 미친 듯이 빠름
    Qwen3.6 27B를 돌리는 데 5070 네 장이 꼭 필요한 건 아니고 세 장, 어쩌면 두 장도 가능함. 다만 27B를 빠르게 하려고 MTP를 쓰면 draft 모델이 자체 문맥을 요구해서 메모리를 더 먹음
    도구의 시스템 프롬프트도 각 대화마다 모델에 로드된다는 점을 기억해야 함. Pi를 켜면 시작은 매우 반응이 빠르지만 Hermes CLI로 상호작용하면 각 프롬프트가 skills, tools 등을 많이 문맥에 싣고 대화 끝까지 남아 훨씬 느림
    프라이버시도 좋지만 할당량이 없고 사용량을 걱정하지 않아도 되는 점도 좋음. 미래가 “루프 엔지니어링”이라면 클라우드 모델로는 토큰과 돈을 태우게 됨. 내 시스템은 유휴 시 200W, 추론 부하가 높을 때 350~450W이며, 디코딩은 그리 효율적이지 않아 GPU가 생각보다 자주 논다는 점도 있음. 확산 같은 발전이 디코딩을 빠르게 하고 유휴 GPU 활용도를 높일 수도 있음

    • zakisaad: 4장 구성에 왜 5070을 골랐는지 궁금함
      처음 생각엔 연산 성능 쪽으로 치우치고 VRAM은 부족해 게이머에겐 좋지만 LLM 실행에는 별로 좋아 보이지 않음. 내 데스크톱에도 5070을 씀

  • cuttysnark: 로컬 모델은 여러 에이전트를 워크플로로 연결해 어느 정도 성공함
    각 에이전트는 역할에 따라 다른 프롬프트와 다른 ollama 모델을 씀. 프로젝트 매니저나 스키마 에이전트(qwen3:14b)는 코딩 에이전트(qwen2.5-coder:7b)와 같은 모델을 쓰지 않음
    각 단계 사이에는 오케스트레이터와 Playwright 작업이 있고, 이전 코드 블록을 만든 에이전트에게 오류를 드러내려 함. 오류 없는 블록만 다음 단계로 넘어감
    가장 큰 개선은 backend-for-agents 서비스 정의를 넣어 스키마 에이전트가 작업 기반 manifest만 만들고 다음 에이전트로 넘기게 한 것임. 요약하면 워크플로를 정의해 에이전트가 아주 특정한 일만 하게 쪼개고, 다음 단계로 넘기게 함. 이렇게 하면 기반을 잃지 않고, 25%나 90% 성공한 흐름에 사람이 끼어들 지점도 생김

    • pianopatrick: 이런 워크플로 벤치마크와 대회가 있으면 무엇이 잘 되는지 알 수 있을 것 같음
      “이 소비자용 GPU만 사용하고, 원하는 모델과 워크플로를 써서 xyz 벤치마크를 얼마나 잘 푸는지” 같은 방식임. 참가자에게 최대 1시간을 주고 답한 비율, 정답률, 전체 시간을 점수화하는 “The Local AI challenge” 같은 형태가 좋겠음
    • sowbug: 에이전트끼리 경쟁시키는 걸 해봤는지 궁금함
      예를 들어 같은 코딩 작업을 두 모델이나 같은 모델의 다른 시드에 주고, 리뷰어가 더 나은 결과를 고르는 방식임. 인간 뇌도 상황을 조금씩 다르게 보는 수천 개의 미니 피질 칼럼이 다수결로 투표하는 식으로 작동한다고 보는 견해가 있음

  • HappySweeney: Optane과 많은 RAM이 있어서 0.7t/s 정도로 전체 모델에 가까운 모델을 밤새 함수 작성에 써봤음
    현재 테스트는 스칼라 함수를 AVX512를 쓰는 비트 행렬 전치 함수로 바꾸는 것임. 클라우드 모델들은 쉽게 처리하지만 Kimi 2.6과 GLM 5.1은 처참히 실패함

  • etoxin: 아직 대체하진 못함. 직장 프로젝트에서는 openspec을 쓰고, 큰돈을 쓰지 않고 로컬 장비를 흉내 내려 최신 인기 로컬 모델의 호스팅 버전을 유료로 사용함
    대부분의 작은 로컬 모델은 도구 호출을 제대로 못 하지만, 더 큰 모델들은 이제 제대로 하는 편임. 로컬 쪽에서 아직 고려하지 못한 점은 생산적인 엔지니어들이 보통 git worktree와 함께 여러 CLI 채팅을 동시에 돌린다는 것임. 나는 보통 3개의 worktree와 CLI 채팅을 오감

  • blurbleblurble: 지금 한계는 모델 자체보다, 큐 관리·중단·서브에이전트·목표 같은 기능이 이상하게 빠진 대체 하네스의 사용성에 있다고 봄

    • coder543: 완전히 동의함. OpenCode가 로컬 LLM을 제대로 지원하려고 하지 않는 것도 짜증남
      OpenCode를 동작시키는 건 가능하지만 설정이 매우 수동적이고 투박함. llama-server 설정을 OpenCode 설정으로 자동 변환하는 스크립트를 만들었고 도움이 되지만 이상적이진 않음
      여가 시간에 또 하나의 코딩 하네스를 만들까 진지하게 고민했음. 더 좋게 만들 아이디어가 몇 가지 있음
    • horsawlarway: Pi는 괜찮음
      Claude, Cursor, Pi의 CLI 에이전트와 직접 만든 커스텀 하네스들, gastown까지 써봤는데 Pi는 그냥 충분함. 필요한 일을 하고, 기본 도구가 괜찮고, 다른 도구와 잘 통합되며, 신경을 덜 쓰게 해줌
      30B 안팎 모델을 괜찮은 속도로 돌릴 수 있다면 Pi와 함께 꽤 놀랄 사람이 많을 것임. https://pi.dev/packages/pi-mcp-adapter?name=mcp와 https://pi.dev/packages/pi-web-access?name=search 같은 확장을 붙이면 웹 도구, perplexity 검색, Chrome 제어용 https://browsermcp.io/, Firefox용 https://github.com/mozilla/firefox-devtools-mcp 같은 MCP 접근도 얻음
      보조금이 붙은 최상위 모델만큼 좋지는 않지만 무료이고 여전히 유능함. 개인적으로는 https://pi.dev/docs/latest/sdk도 아주 재미있게 쓰고 있는데, 다른 제공자들은 이런 API 접근에 월 수천 달러를 받음
    • Insanity: pi.dev에 대한 좋은 얘기를 들었지만 아직 써보진 않았음. 언급한 빠진 기능 일부를 해결해줄 수도 있음

  • _bobm: Claude/GPT 모델이라고 할 때 그 “모델”이 실제로 무엇인지 생각해야 함
    GPT가 어떻게 생각 부분을 하나씩 보내고, 생각 블록 자체의 Markdown 헤더 요약을 붙일 수 있는지 떠올려보면 됨. API 엔드포인트와 출력 동작을 관찰하면, 이른바 SOTA 모델은 보이는 그대로가 아니며 인프라 측면에서 로컬 모델과 전혀 비교 대상이 아님
    이 규모의 운영에는 엄청난 오케스트레이션이 있고, 그 제약이 말해지지 않는 혁신으로 이어짐. 따라잡을 수 없다고 보진 않지만 llama나 vLLM으로 로컬 모델을 서빙하는 건 알파벳 A, B, C 수준일 뿐임
    실제로 필요한 건 위에서 암시한 오케스트레이션의 복제라고 봄. SOTA “모델”은 하나의 단일 모델이 아니라 여러 모델이 함께 작동하는 깊은 오케스트레이션임. 따라서 단일 모델은 학습과 아키텍처에서 이 오케스트레이션을 복제하기 전까지 따라잡지 못함
    일반 소비자에게 제공되는 이 오케스트레이션 구성의 한 모델 자체는 Qwen 3.6보다 훨씬 더 뛰어나진 않을 거라고 봄. 관점을 바꾸면 “마법”의 규모가 보이기 시작함

    • XCSme: 왜 SOTA 모델이 여러 모델의 깊은 오케스트레이션이라고 생각하는지 이해가 안 됨
      GPT가 생각 부분을 Markdown 헤더 요약과 함께 보낸다는 예시도 구체적으로 보고 싶음

  • cheekygeeky: 우리 소프트웨어 개발자는 내가 만난 가장 똑똑한 사람인데, OpenCode와 Tmux를 오픈소스 모델과 함께 씀
    코딩에는 DeepSeek을 가장 선호하고 “꽤 좋다”고 부름. i9, 128GB RAM, 3090 두 장에서 돌림. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: 이런 워크플로를 위한 벤치마크와 대회가 있으면 무엇이 잘 되는지 알 수 있을 것 같음
    “이 소비자용 GPU만 쓰고, 원하는 모델과 워크플로로 xyz 벤치마크를 얼마나 잘 푸는지” 같은 방식임. 참가자는 최대 1시간을 받고, 답변 비율·정답률·완료 시간으로 점수화하는 “The Local AI challenge” 같은 대회를 보고 싶음

  • bravetraveler: 거의 “자연식”으로 쓰며, 적은 LLM 사용도 모두 로컬임
    128GB Strix 시스템에서 덜 밀집된 Qwen이나 Gemma 변형은 출력 50~80tok/s가 나옴. Anthropic/OpenAI 등을 구독할 생각은 없고, 설령 이게 마지막 로컬 모델이라 해도 필요하지 않음. 모델 내 도구 사용이 최신성 걱정을 커버해줌

  • GodelNumbering: 하루 종일 LLM과 대화하는 입장에서, 오픈소스 프런티어 모델 + 좋은 하네스 조합은 이미 충분하다고 봄
    로컬 배포는 완전히 옮겨가기까지 하드웨어 한두 세대가 더 필요함. 다만 하드웨어 회사들이 데이터센터 부문을 강하게 우선시해서 그 시기가 빨리 오지 않을 수도 있음

  • milchek: 36GB MacBook Pro에서 시도했지만 아주 기본 작업을 넘어서면 큰 성공은 없었음
    작은 모델을 써도 문맥이 빨리 고갈되고 느린 게 문제였음. 어느 정도 괜찮은 성능을 내려면 128GB 메모리가 필요해 보이고, 하드웨어 비용이 크게 올라감
    결국 프런티어 모델 구독을 쓸지, 그 돈을 장비에 묻을지의 문제임. 물론 프라이버시가 중요하다면 고급 장비에 돈을 쓰는 것 말고 선택지가 거의 없음

  • acc_297: 중간 크기 모델에 매 프롬프트마다 RLHF를 일상적으로 적용해 개인 사용 습관에 맞게 미세조정하면 도움이 될지 궁금함
    모델을 수동으로 미세조정하는 게 망칠지 개선할지 모르겠음. 성실하게 피드백하면 과도한 아첨, 장황함, 비유로 설명하려는 성가신 습관 같은 범용 모델의 틱을 줄일 수 있으면 좋겠지만, 개인 한 명의 프롬프트 피드백만으로 충분할지는 모르겠음
    내부 문서로 미세조정한 사내 에이전트도 이상한 행동을 보이며 표준 모델보다 꼭 더 유용하진 않다는 얘기를 들음. 에이전트의 모든 응답을 편집하고, 원본과 편집본 차이로 미세조정할 수 있으면 좋겠음
    개인적으로는 형용사를 많이 제거하고 핵심 응답으로 정제하겠지만, Owain Evans 같은 정렬 연구자들의 작업을 보면 이런 조정이 예측하기 어려운 성향으로 밀어낼 수도 있어 걱정됨

    • htrp: Cursor가 그런 걸 하고 있음. 아마 Fireworks를 제공자로 쓰는 듯함: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: 비슷한 걸 OpenClaw 에이전트에 시도해보고 싶음
      Owain Evans 작업은 SFT였던 것 같음. Twitter에서 누군가 RL은 그가 보여준 현상에 덜 취약하다고 하던데, 직접 실험해보고 싶음

  • heisenbit: 설정 작업은 필요하지만 그 과정에서 많이 배우고 있음
    48GB M4 MBP에서 주로 qwen/qwen3.6-35b-a3b mlx를 쓰며, Docker dev-container와 기본 작업을 위한 여유가 간신히 남음. LM Studio로 실행하고 VSCode에서 사용함
    시스템 프롬프트를 바꿔 도구 통합을 개선한 것이 큰 차이를 만들었음. 그전에는 변경을 적용하기보다 코드를 재생성해서 도움이 되기보다 망치는 경우가 많았음
    소음과 발열을 피하려고 전원 연결 중에도 대부분 저전력 모드로 씀. 최대 성능은 속도가 두 배쯤 되지만 전력은 두 배 이상 먹음
    가능한 일은 페이지의 간단한 재구성 정도였고, Pinia store 분리는 실패했음. GPT-5.4는 이 작업을 문제없이 처리함. 도구 사용 가이드와 주변 지원 도구를 더 조정하면 성능이 더 올라갈 수 있다고 봄

  • nfrankel: 시도해봤고 이론상 동작함: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    결과는 모델에 따라 다르고, 결국 컴퓨터가 한계임. 내 장비는 아쉽게도 감당하지 못했음

  • K0balt: qwen 3.6 27b dense로 꽤 좋은 결과를 얻음
    작업에 따라 Claude Haiku 4.5와 비슷하고, 어쩌면 Sonnet급일 때도 있음

    • kadoban: 어떤 도구로 작업을 구동하는지 궁금함
    • kandros: 코딩 작업에는 Haiku보다 차라리 정육점 주인에게 묻겠음

  • jderekw: 일상 장비로 AMD Lemonade를 씀
    Ollama로 시작해 LMStudio로 갔다가, 지금은 cRAM, CPU, GPU, gRAM 모니터링에 도움이 되는 AMD Lemonade로 표준화함. Lemonade의 멀티 모델 기능 덕분에 LLM, 음성-텍스트, NPU, 이미지 생성 스택을 쉽게 돌릴 수 있음
    플랫폼은 Nvidia, Apple, Intel, AMD 칩셋에서도 동작함

  • redox99: 집에서 돌릴 수 있는 Qwen 35B 같은 모델은 Opus나 GPT 5.5에 전혀 가깝지 않음
    그 근처의 오픈 모델은 1T 파라미터쯤이라 집에서 돌리는 건 잊어야 함. 낡은 똥차를 모는 것과 비슷해서 A에서 B로 갈 때는 많고 괜찮다고 설득하는 사람도 있겠지만, 괜찮지 않음
    프라이버시가 절대적으로 필요하거나, 재미로 하거나, 비행기 같은 특수한 경우가 아니면 논리적 이유가 없음. Codex에 보조금이 엄청 붙은 20달러도 못 쓰겠다면, 중국 모델 API를 쓰는 편이 이런 작은 모델들을 압도함

    • pbasista: “Qwen 35B 같은 집에서 돌릴 수 있는 모델이 Opus나 GPT 5.5에 전혀 가깝지 않다”는 평가는 어떤 객관적 사실이나 벤치마크에 근거한 것인지 궁금함
    • xgulfie: 출근하는 데 Ferrari가 필요하진 않음

  • sj_tech: Mac Mini 128GB에서 GitHub Copilot Extension for VSCode로 Qwen 3.6 35B A3B를 에이전트 코딩에 씀
    모델 크기 대비 괜찮지만 문제가 너무 커지면 루프에 빠지는 걸 봄. 자신이 할 줄 아는 일을 시켜 시간을 줄이는 용도로 쓰면 좋음

  • julianlam: Framework 13 32GB 메모리에서 Qwen 3.6 35B-A3B를 llama.cpp로 돌리며 15tok/s가 나옴
    코드와 텍스트를 내가 읽는 속도보다 빠르게 출력함

  • moezd: 아직은 아님. 순수 Apple 게임이나 괜찮은 GPU가 없으면 RAM과 스레드가 많아도 30~50tok/s 정도가 전부이고, 그것도 thinking을 끈 상태임
    이런 최적화가 없으면 모델이 MCP, skills, 에이전트 설명을 마음껏 먹고 첫 출력 토큰을 보기 전에 페인트 마르는 걸 보게 됨
    로컬 모델 서빙은 문맥 창의 모든 토큰을 아껴야 하는데, Claude/GPT/Copilot이 업계를 밀어가는 방향과는 정반대임

    • amarshall: thinking은 출력 속도를 바꾸지 않음. Anthropic 모델의 중앙값 출력 속도는 대략 40~60t/s임

  • mitchell_h: 시도했지만 문맥 창이 충분히 크지 않았음

    • coder543: Qwen3.6-27B는 100만 토큰 문맥 창을 지원함
      물론 그런 문맥 창으로 돌릴 수 있는 하드웨어가 필요하고, 내 DGX Spark에서는 q4_k_xl 모델에 f16 KV cache 전체를 쓰면 약 100GB 메모리가 필요함
    • lysace: 비슷한 결과였음. 내 RTX 4070은 12GB뿐이라, 24/32GB가 실제로 유용할 만큼 개선되는지 궁금함
    • deadbabe: 열린 질문으로 던지기보다 더 직접적으로 프롬프트하면 됨

  • drnick1: 고급 소비자용 GPU에서 돌릴 수 있는 현재 최고의 코딩 모델이 무엇인지 궁금함
    RTX 3090/4090이 있다고 가정하면 어떤 스택을 추천하는지도 궁금함. Llama.cpp + OpenCode 같은 조합인지 알고 싶음

  • bijowo1676: 비싼 프런티어 모델로 앱의 사양, 제품 요구사항, 아키텍처 같은 Markdown 문서를 쓰고 갱신한 뒤, 저렴하거나 로컬 모델로 그 사양을 구현하게 하는 구성이 흥미로웠음
    Markdown은 수백 개의 소스 파일보다 정보를 더 잘 압축해 문맥 창에 잘 들어가지만, 거친 부분을 다듬으려면 2차·3차 패스가 필요함. 이런 방식으로 해본 사람이 있는지 궁금함

  • grmnygrmny2: OpenAI나 Anthropic 제품 사용에 윤리적 거부감이 있어 LLM 도입 자체도 꺼렸음
    로컬 모델은 도덕적 거부감의 대부분을 해결해줘서 한 달 정도 업무와 개인 프로젝트에 쓰고 있음. 가진 하드웨어는 32GB Mac들과 10GB 3080 게이밍 PC라 여러 양자화의 Qwen3.6-35B-A3B 정도가 한계지만, 충분함
    200~400 PP, 20~30 TG 정도이며, 잘 쓰는 법을 익히는 데 시간이 좀 걸렸음. 어떤 일은 돌봐주거나 방향을 잡아줘야 하지만 꽤 유용함
    CC는 써본 적 없어 비교할 수 없지만, 임베디드 C++부터 Vue까지 좋은 조수나 페어 프로그래머 역할을 함. 27B를 돌릴 수 있으면 좋겠고, 가끔 이 모델이 뭔가를 거의 이해할 듯하다가 못 하는 순간이 있지만 드묾
    많은 작업에서 큰 시간 절약이 되고, 꽤 모호한 지시만으로도 버그를 파고들어 고치는 능력이 좋았음. 하네스는 Pi를 씀

답변달기