코딩 에이전트 얘기만 나오면 선택지가 둘 같았습니다. 비싸고 느리지만 잘하는 초대형 모델, 아니면 빠르고 싸지만 저장소 일은 버거운 소형 모델.

JetBrains가 10월 8일 내놓은 Mellum 2.1은 세 번째 길을 보여줍니다. 크기는 그대로 두고, 훈련의 무게중심을 강화학습으로 옮겨 저장소 안에서 탐색하고 고치고 확인하는 능력을 키운 겁니다. Apache 2.0 라이선스라 직접 들고 들어가서 돌릴 수 있습니다.

스펙부터: 12B인데 한 번에 2.5B만 쓴다

아키텍처는 전작 Mellum 2와 같습니다. post-training만 갈아엎었습니다.

구조: Mixture-of-Experts (MoE)
전체 파라미터: 12B
토큰당 활성 파라미터: 2.5B (64개 expert 중 8개만 동작)
레이어: 28 / 컨텍스트: 131,072 토큰
라이선스: Apache 2.0 (Hugging Face에서 가중치 공개)

MoE를 쉽게 말하면 전문가 64명을 대기시켜두고, 토큰마다 필요한 8명만 깨우는 방식입니다. 방 전체를 켜는 게 아니라 필요한 자리만 켜니, 토큰당 계산량은 2.5B짜리 dense 모델 수준인데 지식의 폭은 12B에서 가져옵니다. JetBrains 표현을 빌리면 단일 H100 같은 현실적인 장비에서 돌리기 위한 설계입니다.

이번 릴리스에서 달라진 건 전부 pre-training 이후입니다.

- 강화학습이 마지막 짧은 단계에서 훈련의 본편으로 승격
- 수학·경쟁 프로그래밍·과학·도구 사용·소프트웨어 공학 과제를 새로 추가
- 공개 RL 데이터는 깨진 테스트·검증 불가 답을 걸러내고 투입
- 수천 개 RL 환경을 직접 구축, 수백만 개 샌드박스 실행

결과적으로 모델이 할 수 있게 된 일이 바뀌었습니다. 코드베이스를 탐색하고, 파일을 고치고, 자기 변경을 스스로 확인합니다. 실패한 테스트의 원인을 찾고 수정안을 초안으로 쓰고 검증하는, 에이전트 계획의 한 조각을 맡을 수 있는 수준입니다.

벤치마크는 어떻게 읽어야 할까

공식 발표는 Mellum 2.1과 Mellum 2, 그리고 비슷한 체급의 공개 모델 Qwen3.5-9B, Gemma 4 E4B를 같은 평가 설정으로 비교했습니다. 차트는 LiveCodeBench, AIME, GPQA, BFCL, IFEval, SWE-verified 카드로 나뉘어 공개됐습니다.

핵심만 뽑으면 이렇습니다.

가장 큰 개선: agentic coding (전작 대비 상승폭이 가장 큼)
전반: 코딩·경쟁 프로그래밍·수학·도구 호출·일반 지식 전부 상승
주장: 어려운 문제와 일상 문제 모두에서 유지된다

여기서 잠깐 멈추고 읽어야 합니다. 이 수치는 JetBrains 자체 측정입니다. 같은 설정으로 네 모델을 돌렸다는 점은 공정해 보이지만, 공급사가 고른 태스크와 설정이라는 점은 그대로입니다. 특히 일부 서드파티 요약에서 SWE-Bench 47% 같은 숫자가 도는데, 공식 본문 수치와 Hugging Face 모델 카드의 평가 항목을 직접 대조하기 전에는 인용을 유보하는 게 맞습니다.

속도 수치도 같은 태도로 봅니다. 공식 발표의 표현은 이렇습니다.

단일 요청: MTP(멀티토큰 예측) 적용 시 약 1.6배 빠름 (동일 H200 환경)
고부하: 그룹 내 가장 빠름, Qwen3.5-9B 대비 토큰 처리량 약 2배 수준
전제: post-training이 아키텍처를 건드리지 않아 Mellum 2와 속도 동일

빠르다는 건 분명 좋아 보입니다. 다만 내 저장소, 내 하드웨어, 내 동시성에서의 수치가 필요합니다. 속도는 공식 차트가 아니라 내 워크로드에서 확정됩니다.

그래서 어디에 쓰나: 거대한 두뇌 옆의 빠른 손

Mellum 2.1의 자리는 "전부 다 하는 모델"이 아니라 "에이전트 안에서 맡은 조각을 해내는 일꾼"입니다.

① 에이전트 시스템 안의 작업자:
   실패 테스트 원인 파악 → 수정 초안 → 자기 검증
   큰 모델이 계획을 짜고, Mellum이 중간 작업을 해치운다

② 코딩 밖의 일반 어시스턴트:
   일상 질문과 수학·추론 문제를 단계별로 처리

③ 프라이빗 자체 호스팅:
   로컬·자체 인프라에서 돌려 코드와 데이터를 통제

코딩 에이전트의 위임 글에서 다룬 흐름과 정확히 맞물립니다. 에이전트가 다른 에이전트에게 일을 넘기는 시대라면, 넘겨받은 일을 싸고 빠르게 해치우는 모델이 필요합니다. 모델보다 하네스 글의 교훈도 같습니다. 승패는 모델 한 방이 아니라 검증 루프에서 갈립니다.

로컬에서 돌리는 맛보기는 익숙한 도구들로 열려 있습니다. Hugging Face 컬렉션에서 가중치를 받고, vLLM으로는 OpenAI 호환 API처럼 띄울 수 있습니다. GGUF 빌드와 Ollama·LM Studio 지원, vLLM용 MTP 헤드는 곧 제공될 예정이라고 밝혔습니다.

# 도구 호출 없이 띄우기 (공식 안내 기준)
vllm serve JetBrains/Mellum2-12B-A2.5B-Thinking \
  --max-model-len 131072 \
  --reasoning-parser qwen3

# 도구 호출을 쓸 때 (공식 안내 기준)
vllm serve JetBrains/Mellum2-12B-A2.5B-Thinking \
  --max-model-len 131072 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

CodeBridge Mini Lab: 세 가지를 나눠서 재보세요

공급사 수치를 내 수치로 바꾸는 가장 빠른 방법입니다.

① 저장소 탐색: 이슈 5개 주고 관련 파일 top-k를 맞히는지
② 오류 수정: 실패 테스트 5개 주고 패치 성공률과 회귀 여부
③ 테스트 통과율: 수정 후 전체 스위트 통과까지 걸린 시간

함께 기록: 실행 시간, GPU 메모리 사용량, 동시성 조건
비교 대상: 지금 쓰는 대형 모델 1개와 같은 태스크로

"수정 성공률" 하나만 보지 마세요. 탐색 정확도·수정 성공·회귀 없음이 따로 놀 때가 많고, 그 셋을 묶는 게 하네스의 일입니다.

결론: 큰 모델 하나보다 역할 분담이 먼저다

한 줄로 정리합니다.

모든 일을 거대 모델에 맡기지 말고, 빠른 일꾼에게 나눠주는 구조부터 설계하세요.

Mellum 2.1은 그 일꾼의 유력한 후보입니다. 12B를 통째로 켜지 않고, 저장소 안에서 탐색·수정·확인을 돌리고, Apache 2.0이라 내 인프라에 둘 수 있습니다. 다만 속도 1.6배 같은 숫자는 출발선일 뿐입니다. 내 저장소에서의 탐색·수정·테스트 통과율을 직접 재는 것, 그게 이 발표를 내 것으로 만드는 유일한 방법입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

큰 모델과 작은 모델의 역할 분담, 실행과 검증을 반복하는 에이전트 루프를 직접 설계해보고 싶다면, 하네스·루프·그래프 구조를 단계적으로 쌓는 과정이 이 글의 일꾼 모델 이야기와 바로 이어집니다.