# Qwen3.6-27B: 270억 dense 모델에서 플래그십급 코딩 성능 > Clean Markdown view of GeekNews topic #28797. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28797](https://news.hada.io/topic?id=28797) - GeekNews Markdown: [https://news.hada.io/topic/28797.md](https://news.hada.io/topic/28797.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-23T09:54:47+09:00 - Updated: 2026-04-23T09:54:47+09:00 - Original source: [qwen.ai](https://qwen.ai/blog?id=qwen3.6-27b) - Points: 5 - Comments: 3 ## Topic Body - **270억 파라미터 dense 멀티모달 모델**로 공개, 하나의 통합 체크포인트에서 **thinking·non-thinking 모드**와 이미지·비디오 처리를 함께 지원 - **agentic coding 성능**이 주요 코딩 벤치마크 전반에서 이전 세대 오픈소스 플래그십 **Qwen3.5-397B-A17B**를 상회하며, 총 파라미터 수가 최대 15배 큰 모델들까지 능가함 - SWE-bench Verified **77.2**, SWE-bench Pro **53.5**, Terminal-Bench 2.0 **59.3**, SkillsBench **48.2**를 기록했고, GPQA Diamond **87.8**, AIME26 **94.1** 등 텍스트 추론과 STEM 평가 수치도 함께 공개 - **dense 아키텍처** 채택으로 MoE 라우팅 복잡성이 없고 배포가 단순하며, **open weights**, API, Qwen Studio 즉시 사용 경로와 OpenClaw·Qwen Code·Claude Code 통합 지원 제공 - 잘 학습된 **dense 모델**이 개발자 핵심 작업에서 훨씬 더 큰 이전 세대를 넘어설 수 있음을 보여주며, Qwen3.6 계열의 **agentic coding 확대**로도 이어짐 --- ### 개요 - **Qwen3.6-27B**는 270억 파라미터의 **dense 멀티모달 모델**로 공개됐으며, 멀티모달 thinking 모드와 non-thinking 모드를 함께 지원 - **agentic coding 성능**에서 이전 세대 오픈소스 플래그십인 **Qwen3.5-397B-A17B**를 주요 코딩 벤치마크 전반에서 상회 - MoE 라우팅 복잡성이 없는 **dense 아키텍처** 채택으로 배포가 단순하며, 실용적이고 널리 배포 가능한 규모에서 상위권 코딩 성능 제공 - **Qwen Studio**에서 즉시 사용 가능하며, 커뮤니티용 **open weights**와 API 접근 경로도 함께 제공 - 핵심 특성으로 **플래그십급 agentic coding**, 강한 텍스트 추론, 멀티모달 추론 역량 포함 ### 성능 - Qwen3.6-27B는 dense와 MoE 기준 모델들을 상대로 종합 평가가 제시됐으며, **agentic coding 벤치마크**에서 큰 폭의 향상 기록 - 총 파라미터 수가 최대 **15배 큰 모델들**까지 능가했다고 명시 - 평가 항목은 언어, 지식, STEM 및 추론, 비전-언어, 문서 이해, 비디오 이해, visual agent 등으로 구성 - ## 언어 - 270억 파라미터만으로 주요 코딩 벤치마크 전부에서 **Qwen3.5-397B-A17B**를 상회 - SWE-bench Verified **77.2 대 76.2** - SWE-bench Pro **53.5 대 50.9** - Terminal-Bench 2.0 **59.3 대 52.5** - SkillsBench **48.2 대 30.0** - 동급 규모의 다른 **dense 모델들**도 큰 차이로 앞섬 - 추론 과제에서는 **GPQA Diamond 87.8점** 기록, 자사보다 몇 배 큰 모델들과 경쟁 가능한 수치 - 세부 표에는 Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B, Qwen3.6-27B 비교 포함 - Coding Agent 항목 주요 수치 - SWE-bench Multilingual **71.3** - QwenWebBench **1487** - NL2Repo **36.2** - Claw-Eval Avg **72.4** - Claw-Eval Pass^3 **60.6** - QwenClawBench **53.4** - Knowledge 항목 주요 수치 - MMLU-Pro **86.2** - MMLU-Redux **93.5** - SuperGPQA **66.0** - C-Eval **91.4** - STEM 및 추론 항목 주요 수치 - HLE **24.0** - LiveCodeBench v6 **83.9** - HMMT Feb 25 **93.8** - HMMT Nov 25 **90.7** - HMMT Feb 26 **84.3** - IMOAnswerBench **80.8** - AIME26 **94.1** - ## 언어 평가 설정 - **SWE-Bench Series**는 내부 agent scaffold와 bash, file-edit 도구 사용, temp 1.0, top_p 0.95, 200K context window 기준 - 공개 SWE-bench Pro 세트의 일부 문제성 태스크를 수정한 refined benchmark에서 모든 기준 모델 평가 - **Terminal-Bench 2.0**는 Harbor 또는 Terminus-2 harness 사용 - 3시간 timeout, 32 CPU, 48 GB RAM - temp 1.0, top_p 0.95, top_k 20, max_tokens 80K, 256K ctx - 5회 실행 평균 - **SkillsBench**는 OpenCode로 78개 태스크 평가 - API 의존 태스크 제외된 self-contained subset - 5회 실행 평균 - **NL2Repo**의 다른 모델 평가는 Claude Code 사용 - temp 1.0, top_p 0.95, max_turns 900 - **QwenClawBench**는 실제 사용자 분포 기반 Claw agent 벤치마크 - temp 0.6, 256K ctx - **QwenWebBench**는 내부 프런트엔드 코드 생성 벤치마크 - EN과 CN 이중언어 구성 - Web Design, Web Apps, Games, SVG, Data Visualization, Animation, 3D의 7개 카테고리 - auto-render와 멀티모달 judge로 코드와 시각 정합성 평가 - BT 또는 Elo rating system 사용 - **AIME 26**은 AIME 2026 I과 II 전체 사용 - 점수는 Qwen 3.5 노트와 다를 수 있다고 명시 - ## 비전 언어 - **Qwen3.6-27B**는 단일 통합 체크포인트에서 비전-언어 thinking과 non-thinking 모드를 함께 지원 - 텍스트와 함께 **이미지 및 비디오** 처리 가능 - 멀티모달 추론, 문서 이해, 시각 질의응답 작업 지원 - 비교 표는 Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B, Qwen3.6-27B 기준으로 제시 - ### STEM 및 퍼즐 - MMMU **82.9** - MMMU-Pro **75.8** - MathVista mini **87.4** - DynaMath **85.6** - VlmsAreBlind **97.0** - ### 일반 VQA - RealWorldQA **84.1** - MMStar **81.4** - MMBench EN-DEV-v1.1 **92.3** - SimpleVQA **56.1** - ### 문서 이해 - CharXiv RQ **78.4** - CC-OCR **81.2** - OCRBench **89.4** - ### 공간 지능 - ERQA **62.5** - CountBench **97.8** - RefCOCO avg **92.5** - EmbSpatialBench **84.6** - RefSpatialBench **70.0** - ### 비디오 이해 - VideoMME(w sub.) **87.7** - VideoMMMU **84.4** - MLVU **86.6** - MVBench **75.5** - ### Visual Agent - V* **94.7** - AndroidWorld **70.3** - ### 비고 - 표의 **빈 칸(--)** 은 점수가 아직 없거나 해당되지 않음을 의미 ### Qwen3.6-27B 활용 - **Alibaba Cloud Model Studio** 지원은 곧 제공 예정이라고 명시 - **Hugging Face**와 **ModelScope**에서 open weights 제공, self-hosting 가능 - **Alibaba Cloud Model Studio API**를 통한 사용 경로와 **Qwen Studio**에서의 즉시 체험 경로 제공 - **OpenClaw**, **Claude Code**, **Qwen Code** 같은 서드파티 코딩 도우미와의 통합 지원 - 개발 워크플로 간소화와 **context-aware coding experience** 지원 언급 - ## API 사용 - 이번 릴리스는 **`preserve_thinking` 기능** 지원 - 메시지의 모든 이전 턴에서 생성된 thinking 콘텐츠를 보존하는 기능이며, **agentic task**에 권장된다고 명시 - ## Alibaba Cloud Model Studio - **OpenAI 규격과 호환되는 chat completions 및 responses API** 지원 - **Anthropic 호환 API 인터페이스**도 함께 지원 - 공식 문서 기준 환경 변수 예시 제공 - `DASHSCOPE_API_KEY` - `DASHSCOPE_BASE_URL` - `DASHSCOPE_MODEL` - Base URL 예시 지역도 함께 제시 - Beijing `https://dashscope.aliyuncs.com/compatible-mode/v1` - Singapore `https://dashscope-intl.aliyuncs.com/compatible-mode/v1` - US Virginia `https://dashscope-us.aliyuncs.com/compatible-mode/v1` - 예제 코드에서는 기본 모델 이름으로 **`qwen3.6-27b`** 사용 - `extra_body`에 `enable_thinking: True` 포함 - `preserve_thinking: True`는 주석 형태로 표시 - 스트리밍 응답에서 **reasoning_content**와 **answer content**를 분리 수집하는 예시 포함 - 추가 정보는 **API doc** 링크 참조 안내 - ## Coding & Agents - **Qwen3.6-27B**는 agentic coding 역량을 갖추고 있으며 OpenClaw, Claude Code, Qwen Code와 매끄럽게 통합 가능 - ### OpenClaw - **OpenClaw**는 self-hosted 오픈소스 AI coding agent이며, 이전 명칭은 Moltbot 또는 Clawdbot - **Model Studio**와 연결해 터미널에서 전체 agentic coding 경험 제공 - 시작 스크립트에 Node.js 22+, 설치 스크립트 실행, `DASHSCOPE_API_KEY` 설정, `openclaw dashboard` 또는 `openclaw tui` 실행 절차 포함 - 최초 사용 시 `~/.openclaw/openclaw.json` 수정 필요 - 전체 파일 덮어쓰기 금지 명시 - 기존 설정 보존을 위해 필요한 필드만 병합 - 예시 설정에는 `modelstudio` provider와 `qwen3.6-27b` 모델 등록 포함 - `api`는 `openai-completions` - `reasoning` 값은 true - 입력 유형은 `text`, `image` - `contextWindow`는 **131072** - `maxTokens`는 **16384** - 기본 primary 모델은 `modelstudio/qwen3.6-27b` - ### Qwen Code - **Qwen Code**는 터미널용 오픈소스 AI agent이며 Qwen Series에 깊게 최적화된 도구 - 시작 스크립트에 Node.js 20+, `@qwen-code/qwen-code@latest` 설치, `qwen` 실행 절차 포함 - 세션 안에서 `/help`, `/auth` 명령 사용 예시 제공 - 최초 사용 시 로그인 프롬프트가 표시되며, `/auth`로 인증 방식 전환 가능 - ### Claude Code - **Qwen APIs**는 Anthropic API protocol도 지원 - **Claude Code** 같은 도구와 함께 사용할 수 있다고 명시 - 설정 예시에는 다음 환경 변수 포함 - `ANTHROPIC_MODEL="qwen3.6-27b"` - `ANTHROPIC_SMALL_FAST_MODEL="qwen3.6-27b"` - `ANTHROPIC_BASE_URL=https://dashscope-intl.aliyuncs.com/apps/anthropic` - `ANTHROPIC_AUTH_TOKEN=` - 실행 명령은 `claude` ### 마무리 - **잘 학습된 dense 모델**이 개발자에게 중요한 과제에서 훨씬 더 큰 이전 세대를 능가할 수 있음을 Qwen3.6-27B가 입증함 - 270억 파라미터 규모이면서 **Qwen3.5-397B-A17B**를 주요 agentic coding 벤치마크 전부에서 상회 - 배포와 서비스가 단순한 구조이며, **Qwen3.6 오픈소스 계열**은 Qwen3.6-27B 추가로 더 넓은 범위의 모델 구성을 갖추게 됨 ## Comments ### Comment 56152 - Author: kaydash - Created: 2026-04-23T19:12:32+09:00 - Points: 1 a3b여야 그나마 조금 로컬에서돌리죠 ㅎㅎ ### Comment 56124 - Author: kirinonakar - Created: 2026-04-23T12:47:59+09:00 - Points: 1 벤치는 좋다고 하는데 실사용에서는 아직 코딩 에이전트로 쓸만한 수준이 아닌 것 같던데요. ### Comment 56103 - Author: neo - Created: 2026-04-23T09:54:48+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47863217) - 내 기준에선 16.8GB로 양자화한 로컬 모델치고 **pelican** 결과가 정말 훌륭했음. [https://simonwillison.net/2026/Apr/22/qwen36-27b/](https://simonwillison.net/2026/Apr/22/qwen36-27b/) 에 정리해뒀고, M5 Pro 128GB RAM에서 돌렸지만 실제 필요 메모리는 약 20GB 정도라서 32GB 머신에서도 무난히 돌 것 같은 예상임. 읽기는 20토큰을 0.4초에 처리해 54.32 tokens/s였고, 생성은 4,444토큰을 2분 53초에 생성해 25.57 tokens/s였음. 며칠 전 Opus 4.7로 만든 pelican보다 이번 결과가 더 마음에 들었음. [https://simonwillison.net/2026/Apr/16/qwen-beats-opus/](https://simonwillison.net/2026/Apr/16/qwen-beats-opus/) - 이번 건 너무 잘 나와서 오히려 **학습 데이터**에 들어 있었던 게 아닌가 싶은 느낌임. 다른 테스트들도 돌려서 차이가 어떤지 보고 싶음 - 언젠가는 모델 제공사들이 Simon의 영향력 있는 **pelican riding a bicycle** 테스트에 맞춰 최적화하기 시작할 시점이 오지 않을까 싶은 농담 섞인 생각임 - Qwen Flamingo에 달린 **나비넥타이**도 정말 절묘하다는 느낌임 - 내가 기억하기로는 pelican 테스트에 대해 이렇게까지 **excellent**라는 표현을 쓰는 걸 거의 못 들었는데, 이번 건 정말 그럴 만해 보임. 한동안은 MoE 쪽으로 흐름이 갔는데 이번엔 다시 dense 모델이 주목받는 점도 흥미로움. 비공개 모델들도 빠른 라인업은 MoE, pro 라인업은 dense로 가는지 궁금함 - 이제쯤이면 LLM들이 자전거 몸체가 사실상 반으로 나뉜 **마름모**라는 걸 파악했을 법하다는 생각임 → ◿◸. 이 말을 해버려서 테스트를 망치는 건 아니길 바람 - Gemma 4가 지난 Easter 무렵 나온 뒤로 **self hosting** 모델과 Claude의 격차가 꽤 줄었다고 느끼는 편임. 물론 차이는 아직 크지만, 그전 로컬 모델들이 워낙 경쟁력이 없었기에 지금은 상황이 훨씬 나아졌음. 그리고 Qwen 3.6이 Gemma 4보다 한 단계 더 올라온 거라면 꽤 신나는 일임. 그래도 로컬 모델은 여전히 엉뚱한 방향으로 새거나 실패할 때가 있어서 Opus는 늘 가까이 두고 있음. 그럼에도 로컬 모델이 나를 한번씩 제대로 도와줄 때마다 코딩은 여전히 **자유로워야 함**이라는 감각에 더 가까워짐. 무료라는 의미도 있고, 자유라는 의미도 있음. 내 셋업은 RTX 5090이 달린 별도 Ubuntu 머신이고, 지금 이 순간 Qwen 3.6 27B는 VRAM 32GB 중 29GB를 쓰고 있음. Ollama는 root가 아닌 podman 인스턴스에서 돌리고, 에디터에는 OpenCode를 ACP Service로 붙여서 쓰고 있는데 강력 추천함. ACP는 Agent Client Protocol인데, 내가 보기엔 세상이 이 방향으로 가야 함. 그리고 Qwen 팀이 Sam Altman들로 가득한 세상에서 세상을 더 낫게 만들어준 점에 감사하는 마음임 - 내 M5 MBP에서 로컬로 돌려본 모델들 중에선 **Gemma4**가 가장 Claude 같은 느낌이었음 - 나도 free와 local이라는 이상에는 공감하지만, 결국 중요한 건 **지속 가능한 경쟁**이라고 봄. 월 200달러짜리 비용을 훨씬 낮은 수준으로 끌어내리는 압력이 생긴다는 점만으로도 만족스러움 - 27B 모델이 실제로 어느 정도의 **프로그래밍 작업**까지 감당 가능한지 궁금함. Claude조차 가끔 아쉬운데 27B가 얼마나 실전적인지 상상이 잘 안 됨 - RTX 5090에서는 **tokens/s**가 얼마나 나오는지 궁금함 - 모델 발표를 할 때마다 지금 당장 어떤 **consumer hardware**에서 돌릴 수 있는지, 비용이 얼마인지, tok/s가 어느 정도인지 같이 보여줬으면 하는 바람임 - 이들이 직접 배포한 27B 모델을 16-bit로 네이티브 실행하려면 **상당한 하드웨어**가 필요함. Mac이나 Strix Halo 128GB 시스템, 고용량 소비자 GPU 여러 장, 혹은 RTX 6000급 워크스테이션 카드가 필요함. 그래서 어떤 소비자 하드웨어에서 돌아가는지 적극적으로 홍보하지 않는 것 같음. 그 결과를 내는 원본 릴리스는 일반적인 소비자 시스템에 잘 안 들어가기 때문임. 대부분은 원본 대신 더 적은 비트를 쓰는 양자화 버전을 돌림. 다만 양자화에는 분명한 트레이드오프가 있어서, 광고된 결과와 완전히 같은 품질은 기대하기 어려움. 이전 Qwen3.5 27B는 품질 저하를 어디까지 허용하느냐에 따라 Q5나 Q4까지는 꽤 쓸 만했고, 통합 메모리 시스템에서는 추가 RAM 32GB가 필요해서 대체로 64GB Mac 정도가 적당했음. NVIDIA 5090 32GB나 16GB 또는 24GB GPU 두 장으로도 가능했지만 분산 때문에 속도는 더 느렸음. iPhone이나 더 작은 시스템에서 돌렸다는 주장들은 조심해서 봐야 한다는 생각임. 극단적인 양자화와 여러 꼼수로 실행 자체는 가능해도 출력 품질은 실사용이 안 되는 경우가 많음. SNS 과시용으로 작은 하드웨어에서 돌렸다는 저장소들이 종종 올라오지만, 결과물이 실제로 좋지는 않은 경우가 많음 - 나는 M4 32GB RAM에서 **~5 tokens/s** 정도 나왔음. `unsloth/Qwen3.6-27B-GGUF:Q4_K_M`를 `llama-server`로 돌렸고, 35B-A3B 모델은 약 25 t/s였음. 비교하자면 A100에서는 각각 41 t/s와 97 t/s 정도였음. 27B는 아직 길게 테스트하진 않았지만, 35B-A3B는 컨텍스트가 15k~20k 토큰을 넘기면 자주 탈선했음. 기본적인 작업은 안정적으로 시킬 수 있지만, 이걸 frontier 모델 수준이라고 보긴 어렵다는 판단임 - 로컬 LLM을 돌릴 수 있는 **CPU/GPU 조합**은 사실상 무한대라서, 대부분은 예산과 목표에 맞는 시스템을 고른 뒤 모델 크기와 양자화를 보고 VRAM 사용량을 대략 가늠하는 식임. 더 자세한 분석이 필요하면 온라인 VRAM 계산기를 쓰면 되고, 예로 [https://smcleod.net/vram-estimator/](https://smcleod.net/vram-estimator/) 가 있음. huggingface 계정이 있으면 시스템 구성을 넣고 각 quant 옆에 맞을 가능성을 색으로 확인할 수도 있음. 그리고 t/s는 컨텍스트 크기를 포함해 변수에 크게 좌우돼서, 잘해야 추정치 정도만 가능함. 지금 로컬 LLM은 말 그대로 모든 지점에 **트레이드오프**가 있어서 작업별로 무엇을 최적화할지 계속 선택해야 하는 상황임 - Qwen3.5-27B는 **4bit quant** 기준으로 24GB 카드에서 무리 없이 돌아감. 나는 Nvidia L4 두 장과 몇 가지 vllm 플래그를 써서 개발자 10명에게 20~25 tok/s로 서비스 중이고, 한산할 때는 40 tok/s 정도까지 나옴. 개발자들은 이 성능에도 만족하지만 처리량을 더 늘리려고 GPU 추가를 요청하긴 했음 - 나는 RTX 4090D에서 **30 t/s** 정도 나오고, VRAM은 48GB 중 42GB를 사용 중임. 양자화는 UD-Q6_K_XL이고 관련 논의는 [https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7](https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7) 에 있음 - Qwen이나 Minimax 같은 곳이 OpenAI나 Anthropic보다 약간 낮긴 해도 비슷한 벤치마크 결과를 내는 **오픈소스 모델**을 공개하는데, OpenAI나 Anthropic이 지금 갖는 경쟁 우위가 정확히 뭔지 궁금함. 게다가 이런 오픈 모델들의 토큰 가격은 Anthropic Opus 4.6의 일부 수준이기도 함. [https://artificialanalysis.ai/models/#pricing](https://artificialanalysis.ai/models/#pricing) - 코딩에서는 마지막 몇 퍼센트의 **품질 차이**가 프리미엄을 감수할 만큼 중요하다고 봄. 대량의 스팸 메일이나 HN 댓글을 찍어내는 일과는 다름. 평균 엔지니어와 P99 엔지니어의 보상 차이가 큰 이유도 여기에 있다고 생각함. 또 frontier 업체들이 현재 시점에서 높은 R&D 비용을 감수하면서도 경쟁력을 유지하는 건, 더 나은 제품과 더 많은 부가가치를 만들도록 강제한다는 점에서 장기적으로 이득임. 특히 Anthropic은 더 **신뢰 가능한 공급자** 포지션을 노리는 것 같음. Ali조차 유료 frontier 모델을 호스팅하지만, 중국 기업이 아니라면 생산용 코드 개발 워크로드를 중국 호스팅 사업자에 올리겠느냐는 의문이 있음. OpenAI도 찜찜한 면이 있지만, 그래도 영업비밀을 통째로 캐간다고는 덜 의심하게 됨. Anthropic은 그보다 약간 더 신뢰함. 그래서 프리미엄이 붙는다고 봄. 중국 호스팅 회사가 가능한 경쟁 우위를 총동원하고 정부나 타 기업과 공유할 수 있다는 역사적 전례가 너무 강해서, 사람들은 그 리스크를 가격에 반영한다는 생각임 - 나는 Opus와 Qwen 둘 다 쓰는데, 실제 체감상 둘의 **격차**는 벤치마크 차트보다 훨씬 큼. 호스팅 모델과 비교하려면 지금은 GLM 쪽을 보는 게 더 적절하다고 봄. 대형 플레이어들과 가장 가까운 편이고, 예전에는 아주 낮은 가격에 팔았지만 최근엔 가격을 올리기 시작했음 - 만약 이런 결과가 **vampire attacks** 때문이라면, 비공개 모델들이 답을 빨아가는 경로를 오염시키는 법을 익히는 순간 성능이 지금처럼 좋지 않을 수도 있다는 생각임. 그리고 일상적인 워크플로에서 써보면 그렇게까지 동급은 아님. 얕은 추론은 괜찮을 수 있어도 코딩이나 더 어려운 작업은 여전히 차이가 큼. 적어도 내가 써본 오픈 모델 중에는 비공개 모델만큼 좋은 건 아직 못 찾았음. 혹시 좋은 설정이 있다면 공유받고 싶은 마음임 - 지금 이 순간엔 **경쟁 우위**가 없다고 봄. 다만 어느 한 생태계가 통합되기 시작하면 그때부터는 우위가 생길 것 같음 - Opus의 높은 **토큰 가격**은 오히려 사람들이 그만큼 더 좋은 모델에 기꺼이 돈을 낸다는 증거라고 봄. 새 OpenAI와 Anthropic 모델은 오픈소스보다 눈에 띄게 낫고, 오픈소스가 못 쓸 정도는 아니지만 frontier가 확실히 더 좋으며 당분간 그럴 가능성이 큼. SWE 시간이 분당 1달러를 넘는다면, 대화 한 번에 10달러가 들어도 10분을 아껴주면 충분히 값어치가 있음. 특히 코드 작업에서는 미묘한 품질 향상이 절약 시간으로 크게 이어진다는 판단임 - 나는 M4 MBP에서 Qwen 3.6 35B와 Gemma 4 26B를 쓰고 있는데, 비록 Opus 급은 아니어도 내가 필요한 일의 **95%** 는 해내고 있고, 이 모든 게 완전 로컬로 돌아간다는 점이 이미 놀라운 수준임 - 어떤 종류의 **작업**을 하는지, 그리고 Qwen이나 Gemma를 어떤 하네스나 접근 방식으로 연결해 쓰는지 궁금함. 다시 말해 워크플로와 소프트웨어 스택이 어떤 모습인지 알고 싶음 - 지금은 충분히 쓸 만해서 Codex가 자기 일을 스스로 줄이듯, 더 많은 작업을 이 로컬 모델에게 **위임**하게 됐음. 그리고 내 M4에서는 dense 27B보다 122B 버전이 처리량이 훨씬 좋아서 그쪽도 매우 기대 중임 - 이걸 **Ollama**로 쓰는지, 아니면 다른 걸 쓰는지 궁금함 - 95%라는 표현이 정확히 무슨 뜻인지 더 듣고 싶음. 내가 궁금한 건 두 가지임. 첫째, 출력 품질 기준으로 Opus 4.5나 4.6의 **정확도** 95% 수준이라는 뜻인지 여부임. 둘째, 도구 호출이나 agentic 작업, 예를 들어 여행 계획 같은 일에서 Opus 대비 95% 수준의 수행력을 뜻하는지 궁금함 - 나는 로컬 LLM이 아직 익숙하지 않아서 어제 Qwen3.6-35B-A3B 모델 몇 개를 셋업하고 테스트하는 데 시간을 좀 썼음. mlx 4b와 8b, gguf Q4_K_M과 Q4_K_XL 정도였던 것 같음. 내 64GB M4에서 돌아가는 모습은 꽤 인상적이었음. 다만 이번 새 모델은 TFA의 표를 보면 약간 더 **똑똑**해 보이는 대신 VRAM을 더 먹는 듯한데, 핵심 차이가 dense라는 점인지 궁금함. 그리고 27B가 35B보다 작으니, 조만간 VRAM 요구량을 더 낮춰주는 양자화 모델들도 나올지 기대하게 됨 - 그 핵심은 단순히 파라미터 수 비교가 아님. 35B-A3B는 **Mixture of Experts** 모델이라 한 번에 활성화되는 파라미터가 대략 3B 정도뿐임. 그래서 실제 계산 요구량은 35B가 아니라 이 3B에 가깝게 스케일함. 물론 전체 35B 레이어에 대한 고대역폭 접근은 여전히 필요함. 반면 이번 모델은 dense 모델이라 Mac에서는 훨씬 느릴 가능성이 큼. 예를 들어 내 M4 Pro에서는 Q6 gguf 기준 약 9 tok/s였고, 35-A3B는 Q4에 mlx라 공정 비교는 아니지만 약 70 tok/s였음. 일반적으로 이런 dense 모델은 전용 GPU에서 더 잘 돌고, VRAM이 충분해 모델 전체를 상주시킬 수 있으면 판단이 쉬워짐. 이 모델은 대략 **24GB VRAM** 이상이면 괜찮을 것 같고, NVIDIA 3090이나 4090, 5090 계열이면 무난할 거라는 예상임 - llama server에서 Q4_K_M으로 돌리면 24GB 기준 **91k context** 정도가 나오고, 계산해보면 KV-Cache가 컨텍스트 1K당 약 70MB 수준임. Q5로 갔으면 아마 30K 토큰 정도 공간이 남았을 것 같은데, 이 정도면 꽤 인상적이라는 생각임 - 나는 **SVG**로 자전거 타는 pelican을 생성해봤고 결과는 [https://codepen.io/chdskndyq11546/pen/yyaWGJx](https://codepen.io/chdskndyq11546/pen/yyaWGJx) 임. 또 자동차를 운전하면서 핫도그를 먹는 드래곤도 만들어봤고 결과는 [https://codepen.io/chdskndyq11546/pen/xbENmgK](https://codepen.io/chdskndyq11546/pen/xbENmgK) 임. 완벽하진 않지만, 이런 결과만 봐도 모델들이 얼마나 강력해졌는지 잘 드러난다는 느낌임 - 드래곤 이미지는 외눈이나 이상한 꼬리 같은 문제가 있지만, pelican 쪽은 내가 본 것 중 **최고**라고 느껴질 정도로 거의 완벽했음 - 이게 너무 유명한 **benchmark**가 되어버려서, 모델들이 이미 이 테스트에 맞춰 학습된 건 아닌지 궁금해짐 - 지금까지의 로컬 추론 경험만 보면 아직은 크게 인상적이지 않았음. M5 Pro 128GB RAM에서 omlx로 11 tokens/s 정도가 나와서, 결국 몇백 줄짜리 작동하지 않는 코드를 쓰는 데 한 시간이 걸렸음. 같은 작업을 Opus와 Sonnet은 CC에서 몇 분 만에 성공적으로 끝냈음. 어제 Ollama에서 돌린 3.6 35b 모델은 그럭저럭 괜찮아 보였음. Claude Code 말고 다른 **하네스**도 시험해볼 생각이지만, 현재 로컬 모델들은 너무 느리다는 체감임 - 이건 **dense model**이라 Mac에서 느린 게 자연스러운 편임. Mac이라면 Qwen3.6의 Mixture of Experts 릴리스인 Qwen3.6-35B-A3B를 시도해보는 게 좋겠음. 내 M4 Pro에서는 약 70 tok/s가 나왔음. 만약 이보다 훨씬 느리다면 실수로 GGUF 포맷을 쓰고 있을 가능성이 있음. Mac에서는 Apple 전용 포맷인 MLX가 더 빠른 경우가 많음 - 나는 M2 Max MacBook에서 MLX 8-bit quant 버전으로 생성 속도 **7 tokens/sec** 정도가 나왔음 - OpenCode가 Claude보다 로컬 모델 활용을 **더 잘함**처럼 느껴졌음 - M4 Pro에 RAM 48GB가 있을 때 뭘 돌릴 수 있는지 궁금함 - 이런 경우엔 더 성긴 구조의 **Qwen3.6 35B A3B**가 가장 좋은 선택일 가능성이 큼. 자세한 내용은 [https://qwen.ai/blog?id=qwen3.6-35b-a3b](https://qwen.ai/blog?id=qwen3.6-35b-a3b) 에 있음