IBM 그래닛 4.2, 8B·30B에만 도구 쓰는 법 가르쳤다

세 모델은 같은 트랜스포머 구조와 같은 학습 순서 — 사전학습부터 지도 미세조정(SFT), 다단계 강화학습까지 — 를 밟지만, 실제로 손에 쥐어지는 능력은 크기마다 갈려요. 도구를 실제로 다루는 에이전트 훈련은 8B와 30B에만 들어가고 3B는 건너뛰었거든요. 셋 다 생각은 하지만, 손발을 쓸 줄 아는지는 다른 셈이에요.

15조 토큰, 5단계로 쌓은 기초

Granite 4.2는 처음부터 새로 학습한 모델이에요. 약 15조 토큰을 5단계로 나눠 학습했는데, 12단계는 기초 사전학습이고 34단계는 점점 고품질 데이터로 좁혀가는 중간학습, 5단계는 컨텍스트 윈도우를 512K 토큰까지 늘리는 장문 학습이에요. 512K 토큰이면 두꺼운 책 여러 권 분량의 문서를 한 번에 넣고 읽게 할 수 있는 크기예요.

이후 SFT 단계에서 모델을 실제로 쓸 수 있는 어시스턴트로 다듬었어요. SFT 데이터는 약 720만 개 샘플, 대략 1000억 토큰(실제 학습에 반영되는 건 약 650억 토큰) 규모인데, 에이전트 데이터가 31.6%, 일반 지시·추론 데이터가 68.4%를 차지해요.

에이전트 데이터 세부 영역	비중
소프트웨어 엔지니어링(SWE)	69.0%
도구 호출	12.1%
터미널 사용	8.0%
수학	3.5%
웹 검색	0.8%
액션	0.2%

에이전트 데이터는 OpenHands를 비롯해 OpenCode, Terminus-2, SWE-agent, Gemini CLI, 헤르메스(Hermes), 코덱스(Codex), 구스(Goose) 등 다양한 에이전트 하네스로 만들어졌고, 여기에 IBM이 자체로 만든 강화학습 환경 데이터를 더했어요. 품질 검증에는 오픈AI의 오픈웨이트 모델 gpt-oss-120b와 구글 딥마인드의 Gemma 4를 심사 모델로 붙여, 환각이 섞인 답변이나 정의되지 않은 함수를 부르는 도구 호출을 걸러냈어요. 중복 제거는 도구 목록과 대화 내용을 합친 값의 SHA-256 해시로 처리했고요.

8B·30B는 도구를 쓰는 법까지 배웠다

SFT 다음은 다단계 강화학습이에요. 수학·코드·과학·지시 따르기·도구 사용·구조화된 출력을 검증 가능한 보상으로 훈련하는 RLVR 단계를 먼저 거치고, 그다음 소프트웨어 엔지니어링(SWE) → 터미널 사용 → 웹 검색 순서로 이어지는 에이전트 RL 블록을 통과해요. 마지막은 사람의 선호와 안전성을 반영하는 RLHF고요.

각 단계는 이전 단계의 체크포인트에서 이어받는 별도의 GRPO(그룹상대정책최적화) 실행이에요. RLVR 첫 라운드는 256개 프롬프트마다 16개씩 응답을 뽑아 4096개짜리 배치로 학습하는 방식인데, 이 라운드를 3B·8B는 두 번, 30B는 세 번 반복해요.

모델	파라미터	에이전트 RL(SWE→터미널→검색)	추가 SFT
Granite 4.2 3B	30억	없음	없음
Granite 4.2 8B	80억	있음	없음
Granite 4.2 30B	300억	있음	에이전틱 코딩 2차 SFT(약 1 epoch, 학습률 3.0e-6)

3B는 기초 RL과 정렬 단계까지만 거치고 에이전트 블록은 건너뛰어요. 반면 30B는 SFT를 한 번 더 거치는데, 이때 SWE·코딩 데이터 비중을 끌어올리고 원래 SFT 데이터의 16%를 리플레이로 남겨 기존 능력을 잃지 않도록 했어요.

생각을 켜고 끄는 스위치, 그리고 도구 호출

세 모델 모두 생각 모드(thinking)와 비생각 모드(non-thinking)를 오갈 수 있고, 둘 사이에 쉬운 질문에 짧은 추론 예산만 쓰는 저노력(low-effort) 모드도 있어요. 도구 호출은 오픈AI의 함수 호출 형식을 그대로 따라서, vLLM 같은 오픈AI 호환 엔드포인트로 서빙하면 별도 변환 없이 기존 에이전트 하네스에 바로 꽂을 수 있어요. SGLang 쿠크북에도 바로 서빙할 수 있는 레시피가 올라와 있고요.

어떻게 써보나

Granite 4.2는 github.com/ibm-granite/granite-4.2-language-models 저장소에서 3B·8B·30B 가중치를 전부 내려받을 수 있고, 세 모델 모두 Apache 2.0 라이선스라 상업적으로 고쳐 써도 제약이 없어요. vLLM이나 SGLang으로 서빙하면 오픈AI 함수 호출 형식으로 도구 호출이 그대로 나오기 때문에, 이미 오픈AI 모델용으로 짜둔 에이전트 코드에 모델만 바꿔 끼우는 식으로 옮길 수 있어요.

실무에서 갈리는 지점은 크기 선택이에요. 도구 없이 끝나는 채팅·요약 작업이면 3B로도 충분하지만, 코드를 고치고 터미널을 돌리고 웹을 검색하는 실제 에이전트 워크플로우를 맡기려면 에이전트 RL을 거친 8B 이상을 골라야 해요. 30B는 여기에 더해 소프트웨어 엔지니어링 작업에 특화된 2차 SFT까지 받았기 때문에, 코드 저장소를 직접 고치는 코딩 에이전트로 쓰기에 가장 적합해요.

에디터의 시선

IBM이 지시 따르기에 강점을 뒀던 그래닛 라인에 추론을 넣은 건 시기가 절묘해요. 딥시크발 오픈 추론모델 경쟁이 한 해 내내 이어졌고, 최근엔 메타가 30B급 밀집 모델 Muse Glimmer를 로컬 에이전트용으로 내놨어요. IBM이 같은 30B 체급에서 에이전틱 코딩용 2차 SFT까지 얹은 건, 채팅 품질 경쟁이 아니라 기업 내부에서 코드를 직접 고치는 에이전트 시장을 정조준했다는 뜻으로 읽혀요.

3B에서 에이전트 RL을 뺀 선택도 눈여겨볼 대목이에요. 이건 성능을 아낀 게 아니라 용도를 나눈 거예요. 3B는 온디바이스나 저비용 API로 돌리는 지시 따르기 어시스턴트 자리에 그대로 남겨두고, 8B와 30B에만 도구 조작 능력을 몰아준 거죠. 예전 오픈 모델들은 크기별로 같은 능력을 축소·확대해 배포하는 경우가 많았는데, 이번처럼 특정 능력 자체를 특정 체급에서 빼는 방식은 실무 배포를 더 명확하게 만들어요 — 3B를 골랐다면 애초에 에이전트 작업을 기대하면 안 된다는 신호니까요.

국내에서 온프레미스로 에이전트 파이프라인을 굴리려는 팀이라면, Apache 2.0 라이선스와 오픈AI 호환 함수 호출 형식의 조합이 실질적인 이점이에요. 이미 오픈AI나 다른 벤더용으로 짜둔 도구 정의·하네스 코드를 그대로 두고 모델만 바꿔 끼울 수 있거든요. 다만 8B와 30B 중 어느 쪽을 쓸지는 GPU 예산과 작업 난이도를 먼저 재보고 정할 문제예요 — 단순 도구 호출이면 8B로 충분할 수 있고, 저장소 전체를 고치는 작업이면 2차 SFT를 받은 30B 쪽이 안정적일 가능성이 높아요.

앞으로 몇 주 안에는 이 모델의 에이전틱 코딩 벤치마크 점수가 다른 30B급 오픈 모델과 나란히 비교되는 자료가 나올 거예요. 그 비교에서 IBM이 강조한 SWE 특화 2차 SFT가 실제로 코드 수정 성공률 차이로 이어지는지가, 8B·30B에만 도구를 쥐어준 이번 선택이 옳았는지를 가르는 첫 시험대가 될 거예요.