IBM이 Granite 4.1 언어 모델을 공개했다. 3B, 8B, 30B 크기의 장문맥 인스트럭트 모델이며, 4.0에서 강조했던 기업용 방향성을 유지하면서 후처리 파이프라인을 손봐 툴 호출, 지시 이행, 채팅 성능을 끌어올렸다고 설명한다.12
지금 이게 중요한 이유는 단순하다. 많은 팀에게 필요한 건 "가장 똑똑한 모델"이 아니라 "로컬이나 제한된 인프라에서, 싸고, 예측 가능하게, 꽤 잘 도는 모델"이기 때문이다. Granite 4.1은 바로 그 질문에 답하려는 계열이다. 그래서 평가는 "벤치마크 최고냐"보다 "우리 업무를 안정적으로 자동화하느냐"로 옮겨가야 한다.
Granite 4.1을 볼 때 먼저 바꿔야 할 질문
Granite 4.1 8B는 131K 컨텍스트를 지원하는 dense transformer 기반 모델이다. GQA, RoPE, SwiGLU, RMSNorm 같은 현재 표준에 가까운 구성 위에, SFT와 RL 기반 정렬을 더해 인스트럭트 모델을 만들었다.2 지원 언어도 영어 중심이지만 독일어, 스페인어, 프랑스어, 일본어, 포르투갈어, 아랍어, 중국어 등으로 넓혀 놓았다.2
여기서 핵심은 "어떤 종류의 작음인가"다. Granite 4.0은 하이브리드 Mamba/Transformer 계열까지 포함하며 메모리 효율을 강하게 밀었지만,34 4.1의 공개 모델 카드에서 확인되는 3B·8B·30B 라인은 dense transformer다.2 즉, 4.1은 "기묘한 신아키텍처 실험"이라기보다, 기업이 다루기 쉬운 범용 LLM을 더 잘 다듬은 쪽에 가깝다. 이 차이는 중요하다. 배포와 호환성 면에서는 오히려 장점일 수 있다.
잘 맞는 일도 비교적 분명하다. 문서 요약, 분류, 정보 추출, RAG, JSON 출력, 함수 호출, 내부 업무용 보조 챗봇 같은 작업이다.12 반대로 자유로운 창작 대화, 미묘한 감정 톤 조절, 폭넓은 세계지식 기반 추론에서 최고 수준을 기대하면 실망할 수 있다. 8B 모델의 MMLU는 73.84, BFCL v3는 68.27로 작지 않은 수치지만, "최상급 범용 모델"의 체감과는 다를 가능성이 높다.2
실무적으로는 이렇다. 출력 형식이 중요하고 실패 패턴을 읽기 쉬워야 하며, 데이터가 사내에 머물러야 하는 팀이라면 Granite 4.1은 꽤 합리적이다. 하지만 고객-facing 프리미엄 대화 UX나 고난도 추론이 핵심이면 처음부터 더 큰 모델이나 상용 API를 함께 비교해야 한다.
화려한 모델과 비교할 때, Granite 4.1의 진짜 경쟁력
수치만 보면 상용 API 모델이 더 강한 경우가 많다. 예를 들어 비교 사이트 기준으로 GPT-4.1 mini는 Granite 4.0 Tiny Preview보다 IFEval, MMLU, 컨텍스트 윈도에서 크게 앞선다.5 이 사실 자체는 놀랍지 않다. 돈을 내고 쓰는 최신 폐쇄형 모델이 대체로 더 좋다.
그런데 현업의 비교 기준은 종종 다른 곳에 있다.
첫째, 총소유비용이다. Granite 계열은 Apache 2.0으로 공개돼 상업 사용이 자유롭고, 로컬 배포 경로도 비교적 단순하다.16 "모델 사용료"가 아니라 "내 장비에서 얼마나 안정적으로 돌릴 수 있나"가 관건인 조직에선 이게 매우 크다.
둘째, 운영 예측 가능성이다. IBM은 Granite를 구조화된 JSON 출력, RAG, 툴 사용에 맞춰 다듬어 왔다.17 이런 모델은 자유 대화에선 덜 매끄러워 보여도, 티켓 분류나 필드 추출처럼 정답 형태가 분명한 작업에서는 오히려 다루기 쉽다.
셋째, 실패 분석 가능성이다. 작은 모델은 틀릴 때 이유가 비교적 빨리 드러난다. 프롬프트 문제인지, 검색 문서 품질 문제인지, 스키마 설계 문제인지 분해하기 쉽다. 큰 모델은 더 자주 맞히지만, 틀릴 때 왜 틀렸는지 운영팀이 읽어내기 어려운 경우도 많다. 이건 벤치마크에 잘 안 잡히는 ROI다.
물론 반론도 있다. "그럴 거면 그냥 더 좋은 API 모델을 쓰면 되지 않나?" 맞는 말이다. 사용량이 낮고, 데이터 반출 제약이 약하고, 최고 성능이 가장 중요하면 그 선택이 더 효율적일 수 있다. Granite 4.1의 가치는 모델 IQ 자체보다, 성능·비용·배포 통제권의 균형에서 나온다.
배포 전에 30분만 해보면 되는 Granite 4.1 판별 테스트
벤치마크 대신, 자기 데이터로 다섯 가지만 보자.
첫 번째는 구조화 추출이다. 실제 계약서, 티켓, 보고서 10개를 넣고 JSON 스키마를 강제해 필드 누락률과 타입 오류를 본다. Granite 계열은 원래 이 지점이 강점으로 설계됐다.17 여기서 흔들리면 초반부터 재고해야 한다.
두 번째는 RAG 충실도다. 사내 문서를 붙여 질문했을 때, 답변에 문서 근거가 실제로 반영되는지 본다. Granite 4.0 계열은 RAG 성능을 강하게 밀었고,4 4.1도 RAG를 핵심 용도로 제시한다.2 답변이 그럴듯한데 근거 문장을 잘못 잇는다면 경고 신호다.
세 번째는 툴 호출 안정성이다. 함수 3~5개만 열어 두고, 호출해야 할 때와 호출하면 안 될 때를 섞어 테스트한다. 4.1은 OpenAI 함수 스키마 호환 예시까지 제공할 정도로 이 사용례를 밀고 있다.2 좋은 모델은 "툴이 없으면 없다"고 말하고, 나쁜 모델은 없는 도구를 지어낸다.
네 번째는 다국어 일관성이다. 지원 언어 목록은 넓지만,2 실제 품질은 업무 언어마다 차이가 날 수 있다. 영어로는 맞고 일본어·한국어 입력에서 형식 준수가 무너지는지 꼭 봐야 한다. 특히 한국어는 공식 지원 언어 목록에 명시돼 있지 않으므로 더더욱 사전 검증이 필요하다.2
다섯 번째는 긴 문서 지구력이다. 50~100페이지 문서를 넣고 후반부 사실을 제대로 끌어오는지 확인하자. 131K 컨텍스트는 "넣을 수 있다"는 뜻이지, 언제나 "잘 쓴다"는 뜻은 아니다.2 긴 컨텍스트에선 검색 품질과 청크 전략이 모델 자체만큼 중요하다.
결국 누가 Granite 4.1을 진지하게 봐야 하나
Granite 4.1은 "작지만 의외로 센 모델"이라기보다, "기업이 통제 가능한 방식으로 AI를 운영하려 할 때 맞닥뜨리는 제약에 최적화된 모델"에 가깝다. 오픈 가중치, Apache 2.0, 비교적 명확한 툴 호출/구조화 출력 지향, 그리고 3B·8B·30B로 이어지는 현실적인 크기 선택지가 그 성격을 만든다.12
그래서 신경 써야 할 사람은 모델 데모보다 운영을 걱정하는 팀이다. 보안, 지연시간, 비용, 온프레미스, 장애 분석, 출력 형식 준수. 이 여섯 가지가 중요하다면 Granite 4.1은 후보에 올릴 가치가 있다. 반대로 "가장 똑똑한 챗봇"을 찾고 있다면, 처음부터 다른 리그와 비교해야 시간을 아낄 수 있다.
참고
1Granite 4.1 LLMs: How They're Built
2ibm-granite/granite-4.1-8b · Hugging Face
3Granite 4: IBM introduces a line of small but fast LLMs
4'Western Qwen': IBM wows with Granite 4 LLM launch and hybrid Mamba/Transformer architecture
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.