AI를 붙여야 하는데, 비싸면 안 되고, 외부로 데이터를 보내기도 어렵고, 응답도 꾸준히 빨라야 한다. 이때 가장 헷갈리는 선택이 바로 이런 겁니다. 3B 모델은 영리한 최적화일까, 아니면 결국 다시 큰 모델로 돌아가게 만드는 값싼 우회로일까.
Granite 4.1 3B는 이 질문을 꽤 진지하게 만들었습니다. IBM은 Granite 4.1 계열을 3B·8B·30B로 공개했고, 3B는 엣지·경량 배치를 겨냥한 모델로 설명합니다.1 Simon Willison도 이 3B 모델로 SVG 펠리컨 갤러리를 만들어 보며, "작은 오픈 모델이 어디까지 실용적인가"라는 관점을 던졌습니다.2 중요한 건 벤치마크 점수보다, 이 정도 크기의 모델이 실제 제품에서 언제 더 나은 선택이 되느냐입니다.
3B를 고르는 기준은 "똑똑함"이 아니라 배포 현실이다
Granite 4.1 3B를 "3B치고 괜찮은가"로 보면 판단이 흐려집니다. 더 좋은 질문은 이겁니다. 내 워크플로에 필요한 건 최고 성능인가, 아니면 충분히 괜찮은 성능을 더 싸고, 더 통제 가능하게, 더 많이 동시에 돌리는 것인가.
확인된 사실부터 보면, Granite 4.1은 Apache 2.0 라이선스로 공개됐고, 툴 호출, JSON 출력, RAG, 다국어, 코딩 작업을 주요 활용처로 내세웁니다.13 3B instruct의 공개 수치도 아주 약하진 않습니다. MMLU 67.02, HumanEval 79.27, GSM8K 86.88, BFCL V3 툴콜링 60.8 수준입니다.4 절대 성능은 8B나 30B보다 낮지만, "간단한 업무 자동화에 못 쓸 정도"는 아니라는 뜻입니다.
실무적으로는 이런 경우가 3B의 스위트 스폿입니다. 사내 문서 검색 챗봇, 정해진 스키마로 뽑는 정보 추출, IT 티켓 분류, 짧은 코드 보조, 도구 호출 중심 에이전트 같은 작업입니다. 정답의 대부분이 이미 문서, 규칙, 툴 결과 안에 있고 모델은 이를 연결만 잘하면 되는 경우죠. 이런 문제에서 더 큰 모델의 추가 지능은 생각보다 제품 품질로 잘 환산되지 않습니다.
반대로 애매한 요구를 해석해야 하거나, 계획을 세워야 하거나, 맥락 없이 처음부터 그럴듯한 결과를 만들어야 하는 일은 3B가 조용히 무너지는 구간입니다. IBM도 30B를 "복잡한 추론과 특수 작업"용으로 위치시킵니다.1 즉 3B는 작은 범용 두뇌라기보다, 제약이 잘 걸린 업무 엔진에 가깝습니다.
Granite 4.1 3B가 잘하는 일과, 기대를 낮춰야 하는 일
이 모델 계열의 강점은 훈련 방향에서도 드러납니다. Granite 4.1은 약 15조 토큰으로 학습됐고, 이후 410만 개 수준의 정제된 SFT 샘플과 RL 단계를 거쳤습니다.5 특히 IBM은 RAG, 툴 사용, 다국어 대화, 구조화 출력 같은 실제 업무 패턴을 염두에 두고 데이터 품질 관리와 평가를 했다고 설명합니다.5
그래서 Granite 4.1 3B는 "자유 서술형 천재"보다 "형식과 절차를 잘 따르는 작은 모델"에 가깝게 보는 편이 맞습니다. GitHub 예제도 툴 호출과 JSON 출력에 꽤 공을 들여 보여줍니다.6 이건 실무에서 중요합니다. 많은 팀이 원하는 건 감탄할 답변이 아니라, 실패했을 때 원인을 추적할 수 있는 답변이기 때문입니다.
다만 한계도 분명합니다. 외부 분석 글들과 IBM 자료를 종합하면 Granite 4.1은 전반적으로 추론 특화 모델이 아니고, 긴 숙고를 전제로 한 reasoning 스타일과는 결이 다릅니다.47 또 긴 컨텍스트도 3B는 8B·30B와 다르게 128K 수준으로 보는 편이 안전합니다.4 "512K 지원"이라는 계열 전체 메시지를 그대로 3B에 투사하면 과대평가가 됩니다.
요약하면 이렇습니다. 문서 기반 질의응답, 제한된 함수 호출, 분류·추출·변환은 기대해볼 만합니다. 하지만 전략 수립, 복합 의사결정, 빈 화면에서의 고품질 생성, 높은 책임이 따르는 답변은 더 큰 모델이나 외부 API가 아직 유리합니다.
벤치마크보다 중요한 비교: 로컬 3B vs 큰 로컬 모델 vs API
여기서 진짜 비교는 모델 대 모델이 아니라 시스템 대 시스템입니다.
로컬 3B의 장점은 명확합니다. 지연시간이 짧고, 비용 예측이 쉽고, 개인정보 통제가 좋고, 동시성 설계가 편합니다. 같은 하드웨어에서 더 많은 세션을 감당할 수 있다는 건 체감 품질에 직접 연결됩니다. "한 번의 답변 품질"만 보면 큰 모델이 낫더라도, "하루 5천 건의 반복 업무"에서는 작은 모델이 더 좋은 제품이 될 수 있습니다.
큰 로컬 모델은 품질을 올려주지만 운영 부담이 커집니다. 더 많은 VRAM, 더 적은 동시 처리, 더 긴 응답시간을 감수해야 합니다. 외부 API는 최고 성능을 쉽게 쓰게 해주지만, 비용, 데이터 경계, 공급자 의존, 응답 지연을 함께 가져옵니다.
그래서 판단 기준은 단순합니다. 모델이 스스로 많이 생각해야 하는가? 그렇다면 8B 이상이나 API를 보세요. 반대로 검색, 규칙, 도구, 검증기로 모델의 자유도를 줄일 수 있는가? 그렇다면 Granite 4.1 3B 같은 작은 오픈 모델이 의외로 가장 현실적입니다. 작은 모델+RAG+엄격한 출력 스키마 조합이, 큰 모델 단독보다 운영 품질이 더 좋은 경우가 실제로 많습니다.
다음 주에 바로 파일럿한다면, 가장 안전한 시작점
Granite 4.1 3B를 처음 써본다면 "생성"보다 "변환" 파일럿이 안전합니다. 예를 들면 사내 문의를 JSON으로 구조화하기, 문서에서 필드 추출하기, 정해진 툴 목록 안에서만 함수 호출하기, 팀 위키 기반 RAG 응답 만들기입니다.
가드레일은 세 가지면 충분합니다. 출력 스키마 강제, 검색 근거 없는 답변 금지, 저신뢰 응답의 인간 검토 전환입니다. 성공 지표도 정밀하게 잡아야 합니다. "모델이 똑똑해 보였는가"보다 재처리율, 사람이 고친 비율, 응답시간, 건당 비용을 보세요.
Granite 4.1 3B는 모든 것을 해결하는 작은 만능 모델은 아닙니다. 하지만 AI를 실제 워크플로에 넣어야 하는 팀, 특히 개인정보와 비용, 지연시간에 민감한 팀에게는 꽤 설득력 있는 선택지입니다. 지금 신경 써야 할 사람은 "최고 모델"을 찾는 팀이 아니라, "굳이 거대한 모델이 없어도 되는 문제"를 가진 팀입니다. 그 문제를 정확히 정의할 수 있다면, 3B는 절약이 아니라 아키텍처 선택이 됩니다.
참고
2Granite 4.1 3B SVG Pelican Gallery
4IBM Granite 4.1 Complete Guide -- The 8B Model That Beats 32B (2026)
5Granite 4.1 LLMs: How They're Built
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.