IBM 그래니트 4.2가 사고 모드를 달고 나왔다: 30B가 SWE-Bench Verified 57.00, 세 크기 전부 아파치 2.0

IBM이 2026년 8월 25일 공개한 그래니트 4.2는 3B와 8B와 30B 세 가지 크기로 나왔고 전부 아파치 2.0 라이선스로 허깅페이스에 올라갔다. 세 모델 모두 약 15조 토큰으로 처음부터 학습됐고, 명시적 사고 사슬을 켜고 끄는 사고/비사고 전환과 쉬운 질문에 짧은 추론 예산만 쓰는 저노력 사고 모드가 들어갔다. IBM이 공개한 수치에서 30B는 SWE-Bench Verified 57.00, AIME25 89.17, MMLU-Pro 77.60을 기록했고 한국어를 포함한 12개 언어를 지원한다. ASAP은 IBM 그래니트 팀이 허깅페이스에 올린 기술 문서를 1차 출처로 이 릴리스가 무엇을 바꿨는지와 점수를 어떻게 읽어야 하는지를 정리한다.

세 크기와 라이선스, 그리고 실제로 내려받는 것

그래니트 4.2는 granite-4.2-3b와 granite-4.2-8b와 granite-4.2-30b 세 모델로 구성되며 아파치 2.0 라이선스로 허깅페이스에 공개됐다. 아키텍처는 디코더 전용 밀집 트랜스포머이고, 어텐션 헤드 40개에 KV 헤드 8개를 쓰는 그룹 쿼리 어텐션과 RoPE 위치 인코딩, MLP 층의 SwiGLU 활성화, RMSNorm 정규화, bfloat16 정밀도를 조합했다.

컨텍스트 길이는 두 숫자를 구분해서 봐야 한다. 사전학습 5단계에서 컨텍스트를 512K 토큰까지 확장했다고 IBM은 설명하는데, 공개된 모델의 시퀀스 길이는 131,072 토큰이다. 배포 관점에서 의미가 있는 쪽은 후자다. 여기에 FP8과 FP4, GGUF 양자화 판본이 함께 제공되므로 자체 서버든 노트북이든 내려받아 바로 올릴 수 있는 형태가 갖춰져 있다.

지원 언어는 영어, 독일어, 스페인어, 프랑스어, 일본어, 포르투갈어, 아랍어, 체코어, 이탈리아어, 한국어, 네덜란드어, 중국어 12개다. 도구 호출은 OpenAI 호환 함수 호출 형식을 네이티브로 지원한다.

사고를 켜는 스위치가 세 단계인 이유

그래니트 4.2가 제공하는 추론 제어는 두 갈래가 아니라 세 갈래다. 사고 모드는 사고 사슬을 펼쳐 답하고, 비사고 모드는 곧장 답하며, 저노력 사고 모드는 쉬운 질문에 짧은 추론 예산만 소비한다.

이 구성은 추론 모델을 실제로 서비스에 붙여 본 팀이라면 익숙한 문제를 겨냥한다. 사고 모드를 켜면 어려운 문제의 정답률은 오르지만 쉬운 질문에도 같은 비용이 붙고, 응답 시간과 토큰 요금이 함께 늘어난다. 그래서 현장에서는 질문 난이도를 먼저 분류해 모델이나 모드를 갈라 태우는 라우팅 계층을 따로 만드는 일이 흔하다. 중간 단계를 모델 안에 넣어 두면 그 라우팅의 일부가 모델 쪽으로 넘어간다.

다만 이 스위치는 라우팅을 없애 주는 것이 아니라 라우팅의 선택지를 늘리는 것에 가깝다. 어떤 질문에 저노력을 쓸지 판단하는 일은 여전히 호출하는 쪽의 몫이며, 판단 기준을 잘못 잡으면 어려운 질문에 짧은 예산이 붙어 정답률만 깎이는 결과가 나온다. 세 단계가 실전에서 값을 하려면 난이도 분류의 정확도가 먼저 확보돼야 한다.

에이전트 강화학습이 8B부터 붙은 것의 의미

그래니트 4.2의 후학습은 지도 미세조정과 다단계 강화학습으로 이어지고, 이 가운데 에이전트 강화학습은 8B와 30B에만 적용됐다. 지도 미세조정에는 약 720만 샘플, 토큰으로는 1,000억 토큰이 쓰였고 이 중 에이전트 데이터가 31.6퍼센트, 비에이전트 데이터가 68.4퍼센트다. 강화학습은 비동기 GRPO 기반의 다단계 커리큘럼으로, 수학과 코딩과 STEM과 도구 호출에 검증 가능한 보상을 주는 기초 단계, 지시 따르기와 코드를 끌어올리는 스킬 부스터, SWE 에이전트와 터미널 조작과 웹 검색을 실제 샌드박스 환경에서 다루는 에이전트 단계, 마지막 RLHF 정렬 순서로 구성된다.

여기서 실무자가 읽어야 할 신호는 크기 선택 기준이다. 3B는 기초 강화학습과 RLHF까지만 받았고 실제 환경에서 도구를 쓰며 학습하는 단계를 거치지 않았다. 벤치마크 표에서 3B의 SWE-Bench 계열과 Terminal-Bench 2.1 점수가 아예 비어 있는 것도 같은 맥락으로 읽힌다. 즉 3B는 요약과 분류와 짧은 응답 같은 과제에 쓰는 모델이고, 장기 실행 에이전트를 태울 자리가 아니다.

반대로 30B가 SWE-Bench Verified 57.00과 SWE Bench Multilingual 41.89, SWE Bench Pro 33.29, Terminal-Bench 2.1 29.24를 기록한 것은 이 계열에서 에이전트 워크로드를 감당할 후보가 30B 하나라는 뜻이기도 하다. 8B는 각각 47.67과 30.78과 19.11과 20.56으로 30B와 상당한 간격이 있다.

크기가 커진다고 전부 오르지는 않았다

그래니트 4.2 벤치마크 표에서 가장 눈에 띄는 대목은 최고 점수가 아니라 크기 순서가 뒤집힌 두 지점이다. 도구 호출 벤치마크 BFCL v4에서 3B가 52.41로 8B의 50.29보다 높고, 지시 따르기 IFBench에서 8B가 79.33으로 30B의 77.17보다 높다.

두 역전은 모델 선택을 단순한 크기 비교로 하면 안 된다는 실질적인 근거가 된다. 도구 호출만 반복하는 파이프라인이라면 8B 대신 3B를 검토할 이유가 생기고, 형식 준수가 결정적인 문서 생성 워크플로라면 30B 대신 8B가 나을 수 있다. 벤더가 제시한 표 안에서도 최적 크기는 과제별로 달라진다.

다국어 지표에서는 반대로 계단이 하나 크게 벌어진다. MMLU-ProX lite에서 3B는 27.78인데 8B는 61.06으로 뛴다. 지원 언어 목록에 한국어가 들어 있다는 사실과 3B가 한국어 과제에서 쓸 만하다는 판단은 별개라는 뜻이며, 비영어 과제를 다룰 계획이라면 8B가 사실상 하한선에 가깝다.

장문맥도 같은 방식으로 읽어야 한다. RULER 64K에서 3B는 67.52, 8B는 80.99, 30B는 89.96인데 128K로 늘리면 55.30과 71.41과 81.38로 모두 내려간다. 131,072 토큰을 넣을 수 있다는 것과 그 길이에서 정확도가 유지된다는 것은 다른 이야기다.

한 가지 주의할 항목은 GDPval이다. 8B가 1189.00, 30B가 1225.00으로 표기돼 있는데 다른 항목과 척도가 달라 백분율 지표들과 같은 축에서 비교할 수 없다. 표를 옮길 때 이 숫자만 따로 떼어 쓰면 오해를 만들기 쉽다.

국내에서 이 모델이 실제로 걸리는 자리

아파치 2.0과 한국어 포함 12개 언어, 그리고 3B부터 30B까지의 크기 폭이라는 조합은 데이터 반출이 막힌 조직의 선택지를 넓힌다. 의료와 금융과 공공처럼 자체 호스팅이 사실상 강제되는 곳에서는 라이선스 조건이 성능만큼 중요한 변수인데, 아파치 2.0은 상용 배포와 파생 모델 제작에 별도 협상이 필요 없다.

현실적인 배치는 두 갈래로 갈린다. 사내 문서 검색과 분류, 요약처럼 짧은 입력을 대량으로 처리하는 자리에는 3B나 8B에 FP8 또는 GGUF 판본을 얹는 구성이 맞는다. 코드 수정과 터미널 작업, 다단계 도구 호출이 얽힌 에이전트 자리에는 30B가 사실상 유일한 후보이며, 이 경우 필요한 장비 등급이 한 단계 올라간다.

한국어 서비스를 염두에 둔다면 검증 순서를 뒤집는 편이 안전하다. 벤더 표의 영어 기준 점수를 먼저 보고 크기를 정하는 대신, 실제 한국어 데이터로 만든 자체 평가 세트를 먼저 돌려 3B와 8B의 간격을 직접 확인하는 것이 낫다. MMLU-ProX lite에서 나타난 33.28점 차이는 그 확인을 건너뛰면 안 되는 이유로 충분하다.

아직 확인되지 않은 것들

IBM이 공개한 문서에는 클로드나 GPT, 라마 같은 경쟁 모델과의 직접 비교가 들어 있지 않다. 표에 있는 값은 모두 자체 측정치이며, 에이전트 벤치마크는 어떤 하네스에서 돌렸는지에 따라 점수가 크게 달라지는 종류의 지표다. 다른 조직이 같은 조건에서 재현한 결과가 나오기 전까지는 비교 우위를 단정할 근거가 없다.

학습 데이터의 구성도 문서상으로는 총량과 단계 수 중심으로 서술돼 있다. 약 15조 토큰이라는 규모와 다섯 단계 전략은 밝혀져 있지만, 아파치 2.0 가중치 공개가 학습 데이터 공개를 뜻하지는 않는다. 데이터 출처 검증이 필요한 규제 산업에서는 이 구분이 도입 심사에서 실제로 걸리는 항목이다.

마지막으로 남는 질문은 사고 모드의 비용 곡선이다. 사고와 비사고와 저노력 세 단계가 각각 어느 정도의 토큰을 쓰고 어느 난이도 구간에서 손익이 갈리는지는 공개된 표만으로 알 수 없다. 도입을 검토하는 팀이라면 자체 워크로드에서 세 모드의 평균 출력 토큰과 정답률을 함께 측정하는 것이 첫 실험으로 적절하다.

출처: IBM Granite 팀, 'Granite 4.2 LLMs: How They're Built'(허깅페이스 블로그, 2026년 8월 25일) 기반 ASAP 정리.