LLM WikiAccess-protected knowledge portal
← 스터디 홈
154편 · 약 20분

Qwen3-Coder-Next: 코딩 에이전트를 위한 초희소 MoE 아키텍처

코딩 에이전트가 실용적으로 쓰이려면 두 가지가 동시에 필요하다. 충분히 큰 컨텍스트와 충분히 낮은 추론 비용. Qwen3-Coder-Next(2026년 2월 공개)는 80B 파라미터이지만 추론 시 3B만 활성화하는 초희소 MoE 구조로 이 두 조건을 정면으로 공략한다.

왜 코딩 에이전트는 다른 모델 설계를 요구하는가

일반 LLM 벤치마크는 단발 응답을 평가한다. 코딩 에이전트는 다르다.

  • 툴 루프: bash, read_file, edit, test를 수백 회 반복한다.
  • 긴 컨텍스트: 전체 저장소 또는 멀티-파일 패치가 컨텍스트에 들어온다.
  • 검증 가능한 보상: 테스트 통과/실패가 명확한 RL 신호를 준다.
  • 비용 민감도: 한 이슈 해결에 수백 회 LLM 호출이 발생하므로 토큰당 비용이 결정적이다.

Dense 모델은 컨텍스트 길이를 늘릴수록 KV 캐시 메모리와 prefill 비용이 선형·초선형으로 오른다. MoE는 전체 파라미터 중 일부만 활성화하므로 같은 추론 FLOP에 더 많은 지식을 담을 수 있다. 그러나 기존 Top-K MoE에는 두 가지 약점이 있다: 라우팅 불안정(expert collapse)과 긴 시퀀스에서의 어텐션 메모리 폭발. Qwen3-Coder-Next는 두 문제를 구조적으로 다룬다.

아키텍처: 하이브리드 Gated DeltaNet + Gated Attention

블록 반복 ×12
Gated DeltaNet-MoE 레이어 #1
512 전문가 / 10 활성화
↓
Gated DeltaNet-MoE 레이어 #2
↓
Gated DeltaNet-MoE 레이어 #3
↓
Gated Attention-MoE 레이어 #4
글로벌 어텐션 (전체 시퀀스)
각 MoE 레이어 내부
입력 토큰 임베딩
↓
라우터: softmax → Top-10 선택
512개 전문가 중 10개만 활성화
↓
선택된 전문가 FFN × 10
↓
가중합 → 출력
DeltaNet 메모리 메커니즘
선형 어텐션 상태 S
O(1) 메모리로 무한 컨텍스트 근사
↓
델타 규칙: S ← S − β·k·(Sk)ᵀ + β·k·v ᵀ
↓
Gated: 게이트로 상태 리셋 제어
모델 블록 구조 (12블록 × 4레이어 = 48레이어)

Gated DeltaNet-MoE

DeltaNet은 선형 어텐션의 한 변형이다. 표준 소프트맥스 어텐션이 O(L²) 메모리를 쓰는 것과 달리 고정 크기의 연속 상태를 유지하면서 토큰을 처리한다.

델타 업데이트 규칙:

S_t = S_{t-1} - β_t · k_t (k_tᵀ S_{t-1}) + β_t · k_t v_tᵀ

"게이트"는 이 상태를 얼마나 유지하고 얼마나 리셋할지를 제어한다. 코드 파싱처럼 구조가 급격히 바뀌는 시점(예: 함수 경계, 클래스 시작)에서 상태를 부분적으로 지울 수 있다.

각 DeltaNet 레이어에 MoE FFN을 결합하여 토큰당 활성화 파라미터를 늘리지 않고 지식 용량을 극대화한다.

Gated Attention-MoE (4번째 레이어마다)

순수 선형 어텐션은 장거리 의존성 추적에 약점이 있다. 블록마다 한 번씩 삽입되는 전역 소프트맥스 어텐션 레이어가 이를 보완한다. 이 레이어도 MoE FFN과 결합된다.

결과적으로 48레이어 중 36레이어는 O(L) 메모리, 12레이어는 O(L²) 어텐션을 쓰는 하이브리드 구조가 된다.

숫자로 보는 희소성

항목값
총 파라미터~80B
추론 시 활성화 파라미터~3B
전문가 수512
활성화 전문가10
컨텍스트 길이256K 토큰
추론 메모리(BF16)~46 GB

활성화 파라미터 3B는 Qwen2.5-3B와 추론 비용이 비슷하지만, 전체 80B의 지식 용량을 활용한다.

훈련: 검증 가능한 코드 RL

일반 RLHF는 인간 선호 레이블에 의존하므로 확장이 어렵다. 코드는 다르다. 테스트를 돌리면 통과/실패가 즉시 나온다.

코드 문제 샘플링
SWE-bench, CodeForces, 내부 저장소
↓
모델이 툴 호출 시퀀스 생성
read / edit / bash / test
↓
샌드박스 실행 → 테스트 결과
↓
보상: 테스트 통과 수 / 전체
부분 보상으로 조기 포기 방지
↓
GRPO / PPO로 모델 업데이트
에이전트 훈련 루프

훈련 단계

  1. SFT (지도 미세조정): 고품질 코드 솔루션 + 툴 호출 궤적.
  2. Long-Context Annealing: 256K 컨텍스트에서의 문서-코드 혼합 학습.
  3. Agentic RL: 검증 가능한 태스크(테스트 패스)에서 GRPO로 정책 최적화.

아키텍처 논문(arXiv:2603.00729)에 따르면 에이전트 RL 단계가 SWE-bench 성능에 가장 큰 기여를 했다. 특히 여러 단계에 걸친 툴 호출 체인 최적화는 단순 코드 생성 SFT로는 얻을 수 없다.

벤치마크: SWE-bench 결과

Qwen3-Coder-Next + 에이전트 프레임워크
SWE-Agent: 70.6%
MiniSWE-Agent: 71.3%
OpenHands: 70.8%
SWE-bench Pro (어려운 실제 이슈)
44.3%
비교군 (공개 기준치)
Claude 3.7 Sonnet + SWE-Agent: ~62%
GPT-4o + SWE-Agent: ~48%
Qwen2.5-Coder-32B: ~43%
SWE-bench Verified 성능 비교 (2026-02 기준)

SWE-bench Verified 71%대는 2026년 2월 공개 시점에서 공개 모델 최고 수준이었다. 중요한 맥락:

  • SWE-bench Verified 기준 숫자는 에이전트 프레임워크에 따라 달라진다. 모델 단독이 아니라 모델 + 프레임워크 조합의 결과다.
  • SWE-bench Pro는 Verified보다 훨씬 어려운 실제 저장소 이슈로 구성된다. 44.3%는 여전히 미해결 과제가 많음을 의미한다.
  • HumanEval, MBPP 같은 단발 코드 생성 벤치마크와는 측정 대상이 다르다.

배포: vLLM과 SGLang에서의 운영

vLLM 서빙

# BF16, tensor parallel 4 (80GB A100 × 4)
vllm serve Qwen/Qwen3-Coder-Next-Instruct \
  --tensor-parallel-size 4 \
  --max-model-len 65536 \
  --enable-chunked-prefill \
  --gpu-memory-utilization 0.90

Qwen3-Coder-Next는 512 전문가 중 10개만 활성화하므로 expert offloading이 실용적이다. 자주 사용되는 전문가를 GPU에 두고 나머지를 CPU에 두면 GPU 메모리를 절반 이하로 줄일 수 있다. vLLM 0.9+에서 --enable-expert-offload 플래그로 활성화한다.

# Expert offloading 활성화 (메모리 절약, 지연 증가 트레이드오프)
vllm serve Qwen/Qwen3-Coder-Next-Instruct \
  --tensor-parallel-size 2 \
  --enable-expert-offload \
  --max-model-len 32768

SGLang 서빙

python -m sglang.launch_server \
  --model-path Qwen/Qwen3-Coder-Next-Instruct \
  --tp 4 \
  --context-length 65536 \
  --chunked-prefill-size 4096

SGLang의 RadixAttention은 코딩 에이전트처럼 시스템 프롬프트와 저장소 컨텍스트를 반복 재사용하는 패턴에서 KV 캐시 히트율을 높인다. 동일 이슈에서 여러 번 LLM을 호출하는 SWE-Agent 스타일 루프에서 실질적인 처리량 향상이 나온다.

컨텍스트 길이와 실제 운영

256K 토큰 컨텍스트를 그대로 쓰면 prefill 비용이 높다. 실제 운영에서는 단계별 컨텍스트 전략이 필요하다.

단계컨텍스트 구성
초기 탐색저장소 구조, README, 관련 파일 목록 (~8K)
파일 분석타겟 파일 + 주변 파일 전체 (~32K)
패치 생성수정 대상 파일 + 테스트 + 에러 로그 (~16K)
검증 루프패치 diff + 테스트 결과 (~4K)

코딩 에이전트 통합 패턴

OpenHands (오픈소스 코딩 에이전트)

# OpenHands config.toml
[llm]
model = "openai/Qwen3-Coder-Next-Instruct"
base_url = "http://localhost:8000/v1"
api_key = "token"
max_message_chars = 100000

OpenHands는 자체 샌드박스(Docker)에서 bash, 파일 시스템, 브라우저를 실행한다. Qwen3-Coder-Next와 같이 에이전트 RL로 훈련된 모델은 OpenHands의 툴 호출 형식을 잘 따른다.

SWE-Agent

sweagent run \
  --model-name "Qwen3-Coder-Next" \
  --model-base-url "http://localhost:8000/v1" \
  --instance-id "django__django-15902" \
  --max-steps 50

Thinking 모드 제어

Qwen3-Coder-Next는 enable_thinking 옵션을 지원한다. 단순한 코드 완성에서는 끄고(/no_think), 복잡한 아키텍처 설계 단계에서는 켜는 방식으로 비용을 조절할 수 있다.

# Thinking 모드 비활성화 (빠른 툴 호출)
messages = [
    {"role": "system", "content": "You are a coding assistant. /no_think"},
    {"role": "user", "content": "Fix the failing test in test_auth.py"}
]

운영 체크리스트

메모리 계획

  • [ ] BF16 기준 46GB: A100 80GB × 1 또는 A100 40GB × 2 (TP=2)
  • [ ] Expert offloading 활성화 시 ~28GB GPU, ~60GB CPU RAM 필요
  • [ ] 256K 컨텍스트 전체 사용 시 KV 캐시 추가 메모리 계산 필요

성능 튜닝

  • [ ] Chunked prefill 활성화 (긴 입력 시 첫 토큰 지연 감소)
  • [ ] SGLang RadixAttention 사용 시 캐시 히트율 모니터링
  • [ ] 에이전트 루프 내 불필요한 컨텍스트 제거 (비용 절감)

에이전트 통합

  • [ ] 툴 호출 형식이 OpenAI Function Calling 또는 Qwen 기본 형식인지 확인
  • [ ] 최대 스텝 수 설정 (무한 루프 방지)
  • [ ] 샌드박스 타임아웃 설정 (bash 실행 시 행 방지)
  • [ ] Thinking 모드를 단계별로 선택적으로 활성화

모니터링

  • [ ] 전문가별 활성화 분포 (expert collapse 징후 탐지)
  • [ ] 컨텍스트 길이별 처리량/지연 측정
  • [ ] 에이전트 루프 단계별 성공률 로깅

요약

Qwen3-Coder-Next는 코딩 에이전트의 비용-성능 트레이드오프를 새로운 방식으로 공략한다. 512개 전문가 중 10개만 활성화하는 초희소 MoE로 3B 수준의 추론 비용에 80B 수준의 지식 용량을 제공하고, Gated DeltaNet을 통해 긴 컨텍스트를 O(1) 메모리로 처리한다. SWE-bench Verified 71%대는 에이전트 RL 훈련의 직접적인 결과다. 실용적인 운영에서는 expert offloading, chunked prefill, 단계별 컨텍스트 전략을 조합하면 단일 80GB GPU에서도 실용적인 코딩 에이전트를 구축할 수 있다.

References

  • https://arxiv.org/abs/2603.00729
  • https://github.com/QwenLM/Qwen3-Coder
  • https://huggingface.co/Qwen/Qwen3-Coder-Next-Instruct
  • https://qwenlm.github.io/blog/qwen3-coder/
  • https://github.com/SWE-agent/SWE-agent
  • https://github.com/All-Hands-AI/OpenHands