Qwen3.6-27B: 270억 dense 모델에서 플래그십급 코딩 성능

• 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=<your_api_key>
    • 실행 명령은 claude

마무리

• 잘 학습된 dense 모델이 개발자에게 중요한 과제에서 훨씬 더 큰 이전 세대를 능가할 수 있음을 Qwen3.6-27B가 입증함
• 270억 파라미터 규모이면서 Qwen3.5-397B-A17B를 주요 agentic coding 벤치마크 전부에서 상회
• 배포와 서비스가 단순한 구조이며, Qwen3.6 오픈소스 계열은 Qwen3.6-27B 추가로 더 넓은 범위의 모델 구성을 갖추게 됨

[kaydash]

a3b여야 그나마 조금 로컬에서돌리죠 ㅎㅎ

[kirinonakar]

벤치는 좋다고 하는데 실사용에서는 아직 코딩 에이전트로 쓸만한 수준이 아닌 것 같던데요.

[b89kim]

써봤지만 에이전틱 코딩에 큰 문제 없습니다. 다만, 말씀대로 실사용+일반 코딩은 param 큰 모델에 비해 떨어질수 밖에없습니다. 설정값들이 3.5랑 다르고 preserve_thinking 모드도 추가되었으니 참고바랍니다. 27B 4bitb양자화 정도면 로컬에서 사용하기에 문제 없었습니다.

[GN⁺]

Hacker News 의견들

• 내 기준에선 16.8GB로 양자화한 로컬 모델치고 pelican 결과가 정말 훌륭했음. 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/
  • 이번 건 너무 잘 나와서 오히려 학습 데이터에 들어 있었던 게 아닌가 싶은 느낌임. 다른 테스트들도 돌려서 차이가 어떤지 보고 싶음
  • 언젠가는 모델 제공사들이 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/ 가 있음. 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 에 있음
• Qwen이나 Minimax 같은 곳이 OpenAI나 Anthropic보다 약간 낮긴 해도 비슷한 벤치마크 결과를 내는 오픈소스 모델을 공개하는데, OpenAI나 Anthropic이 지금 갖는 경쟁 우위가 정확히 뭔지 궁금함. 게다가 이런 오픈 모델들의 토큰 가격은 Anthropic Opus 4.6의 일부 수준이기도 함. 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/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 에 있음