▲

Qwen3-Coder-Next 모델 공개

 (qwen.ai)
5P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • Qwen3-Coder-Next는 코드 작성 에이전트와 로컬 개발 환경을 위해 설계된 오픈 가중치 언어 모델로, 하이브리드 어텐션과 MoE 구조를 기반으로 함
  • 대규모 실행 가능한 작업 합성과 환경 상호작용, 강화학습을 통해 훈련되어, 낮은 추론 비용으로도 강력한 코딩 및 에이전트 능력을 보유
  • 단순한 파라미터 확장 대신 에이전트 훈련 신호의 확장에 초점을 맞추며, 검증 가능한 코딩 과제와 실행 환경을 활용해 직접 피드백을 학습
  • SWE-Bench Verified에서 70% 이상을 달성하고, SWE-Bench Pro 및 다국어 환경에서도 대형 모델과 경쟁 가능한 성능을 보임
  • 소형 모델임에도 효율성과 성능의 파레토 균형을 달성해, 비용 효율적인 에이전트 배포에 중요한 의미를 가짐

Qwen3-Coder-Next 개요

  • Qwen3-Coder-Next는 Qwen3-Next-80B-A3B-Base를 기반으로 한 오픈 가중치 언어 모델
    • 하이브리드 어텐션과 Mixture of Experts(MoE) 구조를 채택
    • 대규모 실행 가능한 작업 합성, 환경 상호작용, 강화학습을 통해 훈련
  • 목표는 코딩 에이전트와 로컬 개발 환경에서의 효율적 활용
    • 낮은 추론 비용으로도 강력한 추론 능력과 코딩 성능을 제공

에이전트 훈련 확장 방식

  • 모델은 파라미터 수 확장보다 에이전트 훈련 신호 확장에 집중
    • 검증 가능한 코딩 과제와 실행 가능한 환경을 결합해, 환경 피드백으로부터 직접 학습
  • 주요 훈련 단계
    • 코드 및 에이전트 중심 데이터로 지속적 사전학습
    • 고품질 에이전트 경로 데이터를 활용한 지도 미세조정
    • 소프트웨어 엔지니어링, QA, 웹/UX 등 도메인별 전문 훈련
    • 여러 전문가 모델을 단일 배포형 모델로 증류
  • 이러한 접근은 장기 추론, 도구 사용, 실행 실패 복구 능력을 강화

코딩 에이전트 벤치마크 성능

  • SWE-Bench (Verified, Multilingual, Pro) , TerminalBench 2.0, Aider 등 다양한 벤치마크에서 평가
    • SWE-Bench Verified에서 70% 이상 달성
    • SWE-Bench Pro 및 다국어 환경에서도 경쟁력 유지
    • 작은 활성 파라미터 수에도 불구하고, 더 큰 오픈소스 모델과 동등하거나 우수한 성능
  • 멀티턴 에이전트 작업에서 에이전트 턴 수를 늘릴수록 장기 추론 능력이 강화됨을 확인

효율성과 성능의 균형

  • Qwen3-Coder-Next (3B active) 는 10~20배 더 큰 모델과 유사한 SWE-Bench-Pro 성능을 달성
  • 전체 어텐션 기반 독점 모델이 절대 성능에서는 앞서지만, Qwen3-Coder-Next는 비용 대비 효율성에서 우수한 파레토 프런티어에 위치
  • 이는 비용 효율적 에이전트 배포에 적합한 모델임을 보여줌

데모 및 적용 예시

  • 소형·고속 코더 모델로 다양한 응용 환경에 통합 가능
    • OpenClaw, Qwen Code, Claude Code, Web Dev, Browser Use, Cline 등에서 시연
    • coder.qwen.ai를 통해 웹 기반 사용 가능

요약 및 향후 계획

  • Qwen3-Coder-Next는 코딩 에이전트 벤치마크에서 우수한 속도와 추론 능력을 입증
  • 대형 오픈소스 모델과 비교해도 경쟁력 있는 성능을 보이지만, 여전히 개선 여지가 있음
  • 향후에는 도구 활용 능력, 복잡한 문제 해결, 의사결정 능력을 강화하고
    • 더 많은 작업 지원 및 사용자 피드백 기반의 빠른 업데이트를 계획
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 이 GGUF 모델은 48.4GB 크기로, 고사양 노트북에서도 실행 가능함
    아직까지는 내 64GB MacBook Pro에서 Codex CLI나 Claude Code 수준의 코딩 에이전트를 제대로 돌릴 수 있는 로컬 모델을 못 봤음
    혹시 이번엔 다를까 싶음. Unsloth 가이드를 보면 가능성이 있어 보임

    • “로컬 모델”이라는 표현 대신 “내 컴퓨터 모델” 같은 새로운 용어가 필요하다고 생각함
      단순히 같은 머신에서 llama.cpp로 연결된 걸 로컬이라 부르기엔 부족함. 내가 말하는 로컬은 LAN 모델, 즉 내가 직접 제어하는 하드웨어에서 inference를 ‘공짜로’ 돌릴 수 있는 수준을 의미함
      예를 들어 5090 + Threadripper + 256GB RAM 구성은 약 1만 달러 정도, MLX 경로는 6천 달러 정도임
      모델의 내부 구조와 양자화 방식이 실제 메모리 사용량에 큰 영향을 주므로, 단순히 파라미터 수로 비교하는 건 점점 의미가 줄어듦
      따라서 표준화된 하드웨어 기준으로 toolcalling, 코드 생성, 문서 처리 같은 실제 작업을 벤치마크하는 시스템이 필요하다고 봄
    • 나는 Qwen3-Coder-30B-A3B-Instruct gguf를 13GB RAM VM과 6GB RTX 2060 GPU에서 돌리고 있음
      오래된 Razer Blade 노트북인데도 64k 컨텍스트까지는 꽤 안정적으로 작동함
      작은 프로젝트나 버그 수정, UI 개선 같은 작업에는 충분히 쓸 만함
      다만 “usable”의 기준은 사람마다 다르다고 생각함. 어떤 작업을 시도했는지에 따라 평가가 달라질 것임
    • 나는 GPT-OSS-120b (MXFP4) 를 Codex와 함께 써봤는데, 약 66GB VRAM을 사용함
      120b 모델의 좋은 실행 로그를 모아 20b 버전을 후속 학습(fine-tuning) 하면 꽤 유용할 것 같음
      reasoning_effort를 높이면 꽤 괜찮은 결과를 내지만, 64GB 메모리 한계 때문에 20b 개선이 현실적임
    • Claude Code를 로컬 모델(ollama run glm-4.7-flash)로 설정해 32GB M2Pro Mac mini에서 돌려봤음
      오래된 git 프로젝트 코드 정리, 문서화, 테스트 추가 등에는 충분히 쓸 만했음
      내 기준이 낮을 수도 있지만, 로컬 코딩 보조로는 꽤 만족스러움
    • 앞으로 5년쯤 뒤면 대부분의 모델이 로컬 실행 가능해질 것 같음
      고성능 GPU와 메모리 생산이 늘고, 모델 최적화가 진행되면 중급 하드웨어에서도 충분히 좋은 성능을 낼 수 있을 것임

  • 로컬 배포용 Dynamic Unsloth GGUF를 Hugging Face에 올렸고,
    Claude Code / Codex를 로컬에서 사용하는 가이드도 작성했음

    • 내 시스템에서 약 39 tok/s, GPU 사용률 60% 수준으로 동작함
      Radeon RX 7900 XTX 기반 환경에서 llama.cpp 서버를 실행했고, ctx-size 32768 설정으로 안정적으로 작동함
    • Framework Desktop에서 내 모델을 사용 중이라는 피드백을 받음
      왜 Qwen3의 기본 GGUF 대신 Unsloth 버전을 써야 하는지 궁금하다는 질문이 있었음
    • IQuest-Coder도 같은 방식으로 배포되길 바란다는 요청이 있었음
    • UD 버전과 일반 버전의 차이를 묻는 질문이 있었음
    • “이걸 이렇게 빨리 만들 수 있었던 이유가 뭐냐”는 놀라움 섞인 반응도 있었음

  • Homebrew로 llama.cpp를 설치해 Unsloth 양자화 모델을 로컬에서 실행했음
    CLI 인터페이스와 OpenAI 호환 API 서버를 동시에 띄울 수 있었고, 약 28GB RAM을 사용함

    • 누군가는 토큰 속도(token/s)가 얼마나 되는지 물었음
    • 또 다른 사람은 전반적인 인상(impression)이 어떤지 궁금해했음

  • 이 모델이 정말로 주장대로라면 3B 활성 파라미터로 Sonnet 4.5 수준의 코딩 성능을 낸다는 건 엄청난 일임

    • Q2, Q4 양자화 버전을 테스트해봤는데, 로컬에서 돌아가는 건 놀랍지만 Sonnet 4.5 수준은 아님
      간단한 문제에서도 오류가 있었고, thinking loop에 빠지는 경우도 있었음
      초기 구현 버그일 수도 있지만, 현재로선 과장된 성능 주장으로 보임
    • 내 체감상 Haiku 수준에 더 가까움
    • “너무 좋아 보이면 진짜가 아닐 가능성이 높다”는 말이 떠오름

  • Qwen3 Coder 30B를 Mac M4 Max(36GB)에서 로컬로 돌려봤음
    느리긴 했지만 작동했고, 꽤 괜찮은 결과를 냈음
    시연 영상과 설정 방법 블로그를 공유함

  • 6GB VRAM 노트북에서 17 tok/s, 최대 100k 컨텍스트까지 가능했음
    놀랍긴 하지만 속도가 느려서 결국 클라우드 inference를 계속 쓸 예정임
    [docker-compose 설정 예시]를 공유함

  • DGX Spark + vLLM 0.15.1 환경에서 FP8 모델을 벤치마크함
    단일 요청 기준 약 43 tok/s, 병렬 요청에서는 최대 62 tok/s까지 도달함

    • FP8 모델을 vLLM에서 돌려봤는데, 실행 중 BF16으로 디퀀타이즈되어 메모리 스왑이 발생함
      llama.cpp의 4-bit 양자화 버전은 약 30~35 tok/s, 200k 컨텍스트에서도 50GB RAM만 사용함

  • 3B 활성 파라미터로 GLM 4.7보다 약간 낮은 성능을 보이지만, 효율은 놀라움
    빠르지만 단순한 코딩 에이전트를 오케스트레이터와 함께 쓰면 전체 속도는 더 빨라질 수도 있다고 생각함

    • 나는 Claude의 sub-agent 기능을 활용해 Mastra 기반 TypeScript 에이전트들을 CLI로 돌리고 있음
      코드 스캔, 라이브러리 검색, SourceGraph 탐색 같은 반복 작업을 자동화함
      Mastra의 Workspace 기능 덕분에 더 강력한 에이전트형 개발이 가능해졌음
    • 결국 이 모든 게 더 널리 쓰이려면 대형 AI 기업들이 가격을 올릴 때가 될 것 같음

  • lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0을 Strix Halo에서 돌려봤는데,
    32 tok/s, 128k 컨텍스트까지 가능했음. MiniMax M2.1 Q6보다 약간 약하지만 인상적임

    • Strix Halo가 어떤지 궁금하다는 질문이 있었음. 양자화 없이 로컬 추론이 가능한 머신을 원한다는 의견도 있었음
    • NVIDIA Spark에서 비슷한 수치를 얻었고, Q4_K_XL 버전으로 테스트 중임
      FP8은 110GB를 사용해 16k 컨텍스트밖에 안 됐음
      Rust 코드 생성에 써봤는데 꽤 유능했음. 속도만 개선되면 실제로 쓸 수 있을 듯함
      조만간 API 제공자들이 저렴하게 이 모델을 서비스할 것 같음

  • 로컬 모델 랭킹을 신뢰할 수 있는 곳이 어디인지 궁금함
    벤치마크가 너무 조작된 느낌이라, 개인 리뷰가 더 의미 있다고 생각함
    코드, 음성, 이미지, 요약, 음악 등 도메인별 우수 모델을 정리한 곳이 있는지 알고 싶음

답변달기