Kolibri vs Granite 4.2 3B: 78B 희소성 베팅, 그리고 같은 게임을 하기를 거부하는 3B 모델

를 나란히 놓고 보면, 가장 먼저 떠오르는 솔직한 관찰은 이것이 공정한 싸움이 아니라는 것 — 그리고 그 불공정함은 당신이 짐작할 법한 방향이 아니라는 것이다. Kolibri와 Granite 4.2 3BKolibri는 Aleph Alpha의 781억 파라미터 규모 전문가 혼합(mixture-of-experts) 모델로, 2026년 10월 3일에 공개되었고 토큰당 34억 6천만 개의 파라미터를 활성화한다. Granite 4.2 3B는 IBM의 약 30억 파라미터 규모 밀집(dense) 추론 모델로, 가중치는 2026년 8월 7일 Hugging Face에 공개되었으며 모델 카드와 기술 블로그는 8월 25일에 뒤따랐다. 총 파라미터 기준으로 하나는 다른 하나의 26배다. 이 둘이 같은 결정 안에서 함께 검토되는 이유는 둘 다 Apache 2.0이고, 둘 다 텍스트 전용이며, 둘 다 설계상 자체 호스팅을 전제로 하고, 둘 다 같은 구매자, 즉 자기가 통제하는 하드웨어에서 문서 인텔리전스를 구현하되 조달 심사를 통과할 만한 출처 이력을 갖추려는 팀을 겨냥했기 때문이다. 흥미로운 질문은 어느 쪽이 더 나은가가 아니다. 26배의 파라미터 예산이 실제로 무엇을 사 주는지, 그리고 그것을 감당하는 데 무엇이 드는가이다.

불일치, 간단히 말하면

Granite 4.2 3B는 Granite-4.1-3B-Base에서 사후 학습된 독립형 dense 모델로, IBM이 8월까지 출시한 Granite 4.2 패밀리의 일부입니다. 이 모델은 그룹화된 쿼리 어텐션을 갖춘 40개 레이어, IBM이 다섯 번째 사전 학습 단계에서 512K로 확장하는 128K 네이티브 컨텍스트, 그리고 쿼리별 세 가지 사고 모드(기본적으로 전체 사고, 저노력 경로, 비사고 경로)를 갖추고 있습니다. IBM의 카드는 3B가 아닌 것에 대해 이례적으로 솔직합니다. 8B 및 30B 형제 모델과 달리, 이 모델은 SWE-agent, 터미널 및 검색 환경에서 훈련된 특화된 에이전트 강화 학습 블록을 의도적으로 건너뛰었습니다. 그렇기 때문에 IBM은 이 모델에 대한 SWE-bench 수치를 전혀 제시하지 않으며, 이 모델을 에이전트가 아닌 추론 전문가로 규정합니다.

Kolibri는 모든 축에서 정반대 방향으로 갑니다. 50개 레이어, 그 모두가 mixture-of-experts이며, 레이어당 expert 384개로 하나는 shared, 여섯 개는 routed이고, 희소성 비율은 약 22.6 대 1입니다. 컨텍스트는 기본적으로 262,144 토큰이고, 1,048,576까지 검증되었으며, 모델 카드에서는 지연에 민감한 작업의 경우 262,144 이하를 유지하도록 권장합니다. reasoning effort 수준은 네 가지입니다. Hermes 스타일 도구 호출 기능과, 가중치와 같은 저장소에 함께 제공되는 vLLM 파서를 갖추고 있습니다. 그리고 FP8 기준 약 78 GB의 풋프린트를 가지며, 모델 카드의 최소 구성은 A100 80 GB 카드 2장, H100 SXM5 2장, H200 1장, B200 1장 또는 B300 1장입니다.

• 매개변수 — Kolibri: 총 78,103,074,560개, 토큰당 활성 3,457,573,120개. Granite 4.2 3B: 약 3B 덴스, 모든 매개변수가 모든 토큰에서 활성화됩니다.

• 컨텍스트 — Kolibri: 16,384 훈련, 65,536 중간 훈련, 262,144 네이티브, 1,048,576 검증. Granite 4.2 3B: 128K 네이티브, 512K까지 확장.

• 사고 모드 — Kolibri: 없음, 낮음, 중간, 높음, 채팅 템플릿을 통해 설정. Granite 4.2 3B: 전체, 저노력, 비사고, 쿼리별로.

• 도구 호출 — Kolibri: Hermes 스타일이며, 파서가 함께 제공됨. Granite 4.2 3B: 그렇지만 더 큰 형제 모델들이 받은 에이전틱 RL 학습 경로는 아님.

• 언어 — Kolibri: 설계상 독일어와 영어뿐, 그 외에는 없습니다. Granite 4.2 3B: 영어 우선이며, 그 배경에는 IBM의 더 폭넓은 다국어 훈련이 있습니다.

• 풋프린트 — Kolibri: FP8 기준 약 78 GB, GPU 최소 2개. Granite 4.2 3B: bfloat16 기준 대략 6–8 GB, 양자화 시 2 GB 미만, 노트북급.

• 라이선스 — 둘 모두 Apache 2.0이며, 둘 모두 허용 사용 부속 조항이나 월간 활성 사용자 임계값이 없습니다.

• 서빙 — Kolibri: aleph-alpha-inference vLLM 플러그인 또는 게시된 컨테이너 이미지. Granite 4.2 3B: granite4.2:3b 아래의 vLLM, SGLang, Transformers, GGUF 및 Ollama.

추가된 750억 개의 파라미터가 무엇을 가져오는가

세 가지가 있는데, 그중 어느 것이 확립된 것이고 어느 것이 주장된 것인지 정확히 따지는 것이 좋습니다.

첫 번째는 독일어입니다. 이것은 두 모델 사이의 가장 뚜렷한 실제 차이이며, 벤치마크 항목이 아닙니다. Aleph Alpha는 Kolibri를 독일어-영어 이중 언어 코퍼스를 중심으로 구축했으며, 20조 토큰 규모의 사전 학습 실행에서 약 20퍼센트를 독일어로 목표했고, 결과적으로 2.4조 토큰의 독일어 풀을 확보했는데 그중 80퍼센트는 연구소가 직접 선별하거나 생성한 것이었습니다. 모델 카드는 그것이 왜 수고를 필요로 했는지 설명합니다. 중복 제거된 공개 독일어 데이터셋은 3900억 토큰만 제공했고, 이는 10배나 부족한 양이었습니다. 그래서 연구소는 Common Crawl 필터를 독일어에 맞게 재조정하고 기존 독일어 문서를 백과사전 항목, 대화, 구절로 바꾸어 표현했습니다. 기억해야 할 것은 필터의 세부 사항입니다. 표준 언어 데이터 파이프라인은 너무 긴 단어가 많은 문서를 버리는데, 독일어 행정 문체는 평균 단어 길이에 대한 영어 기준을 일상적으로 초과합니다 — 그래서 기본 설정은 공공 행정이 사용하는 문체를 조용히 삭제합니다. IBM은 그 코퍼스를 위해 Granite를 구축하지 않았습니다. Granite 4.2 3B는 독일어를 처리할 것입니다. 그것은 독일어 법률 및 행정 문체를 중심으로 설계되지 않았으며, 어떤 리더보드도 그 차이를 알려주지 않을 것입니다.

두 번째는 실제 문서에서도 살아남는 장문 컨텍스트입니다. Granite의 512K 상한은 정말로 크지만, 두 모델이 거기에 도달한 방식은 서로 다르며 Kolibri의 위치 설계는 더 전통적인 장문 컨텍스트 논거입니다. IBM의 RULER 수치 — 4.2 패밀리의 공개 자료에서 64K에서 67.52, 128K에서 55.30 — 를 128K까지 검색 품질이 얼마나 저하되는지에 대한 솔직한 공개로 받아들이고, Kolibri에는 이에 상응하는 공개된 성능 저하 곡선이 전혀 없다는 점을 기억하세요.

세 번째는 순수한 추론 여유분인데, 여기서 솔직한 답은 "파라미터 비율이 시사하는 만큼은 아니다"입니다. Kolibri의 학습 파이프라인은 21일 동안 768대의 NVIDIA B200에서 20조 토큰 사전 학습을 진행할 수 있게 해 주었고, Aleph Alpha 자체 비교표에서 Kolibri를 추론 노력 high로 설정하면 14개 모델 비교의 영어 평균에서 75.5, 독일어 평균에서 70.8을 기록합니다. 여기서 Kolibri는 대부분의 행에서 Alibaba의 270억 파라미터 dense 모델에 뒤처집니다. Granite 4.2 3B의 대표 주장은 자체 보고입니다. AIME 2025 78.33, GPQA 54.80, LiveCodeBench v6 69.71, MMLU-Pro 67.84이며, 모두 IBM이 보고했고 재현되지 않았습니다. 서로 다른 스위트, 서로 다른 하네스, 서로 다른 벤더입니다. 이 조합에 대한 동일 하네스 수치는 어디에도 없으며, 우리가 만들어 낼 생각도 없습니다.

각각이 실제로 우위를 차지하는 지점

제약이 머신이라면 Granite 4.2 3B를 실행하세요. bfloat16으로는 6~8GB, 양자화하면 2GB 미만으로, 노트북, 단일 워크스테이션 GPU, 또는 두 대의 H100을 결코 보지 못할 에어갭 엣지 박스에 들어맞습니다. Ollama와 GGUF를 포함한 다섯 가지 런타임을 통해 서빙되며, 이는 배포 대상이 자신의 랙이 아니라 다른 사람의 노트북일 때 중요합니다. 그리고 그 모델 카드는 IBM이 무엇을 빼놓았는지 적어 두었기 때문에 유난히 신뢰할 수 있습니다. 3B 모델의 SWE-bench 결과를 내세우지 않는 벤더는 그 모델의 한계가 어디인지 알려주는 것입니다.

코퍼스가 핵심이고 하드웨어가 갖춰져 있다면 Kolibri를 실행하십시오. 독일어 계약서, 기술 문서 또는 행정 제출 서류를 다루고, 기존 2-GPU 노드를 보유하며, 가중치가 절대 건물 밖으로 나가지 않아야 한다는 요건이 있는 팀이야말로 이 릴리스가 설계된 대상입니다. 262,144토큰 네이티브 윈도, FP8 KV 캐시, 네 가지 노력 수준, Hermes 도구 호출 경로는 모두 채팅이 아니라 문서 워크플로를 가리킵니다. 이중 언어 토크나이저도 같은 논거의 일부입니다. Aleph Alpha는 독일어 웹 텍스트에서 토큰당 평균 4.90바이트를 보고했으며, 이는 GPT-5의 4.35, Kimi K3의 3.28과 대비됩니다. 모두 각 벤더가 자사 코퍼스에서 측정한 수치이며, 토큰당 문자가 더 많다는 것은 점수가 아니라 직접적인 추론 비용 효과입니다. 이것이 사실로 확인되면, 처리하는 모든 페이지에서 효과가 누적됩니다.

아무도 광고하지 않는 비대칭성은 데이터다. IBM은 Granite 4.2 3B의 가중치와 그 모델이 어떻게 만들어졌는지에 관한 상세한 기술 설명을 공개했지만, 학습 데이터는 공개하지 않았다. Aleph Alpha는 Kolibri의 가중치와 함께 파이프라인, 데이터 출처, 에너지 수치를 공개했다 — 사전 학습 토큰 20조 개, 데이터센터 오버헤드를 포함하고 지도 미세 조정과 강화 학습은 제외한 9.5×10² MWh. "이 모델의 텍스트는 어디에서 왔는가"라는 질문에 답해야 하는 팀에게 그 차이는 겉치레가 아니다.

두 경우 모두의 라우팅 현실

현재 어느 모델도 호스팅 카탈로그에 올라와 있지 않습니다. Kolibri는 벤더 API SKU가 전혀 없으며 — 이번 릴리스는 가중치와 기술 보고서로 구성됩니다 — Granite 4.2 3B는 IBM의 호스팅 엔드포인트 없이 다섯 개 런타임 스택용 가중치로 제공됩니다. 둘 다 셀프 호스팅 제안이며, 대부분의 팀에게 실질적인 질문은 어느 것을 도입할지가 아니라 해당 워크로드가 둘 중 하나를 직접 운영할 만한 가치가 있는지입니다.

바로 그 지점에서 라우팅 계층은, 자신이 취급하지 않는 모델에 대해서도 제 역할을 합니다. 우리는 OrcaRouter 카탈로그를 두 모델 이름의 모든 표기로 샅샅이 살펴보았고, Kolibri도 Granite 4.2 3B도 그곳에 없습니다. 그러니 아닌 척하지 않겠습니다. OrcaRouter가 실제로 제공하는 것은, 하드웨어 결정을 내리기 전에 그것이 정당한지 값싸게 알아내는 방법입니다: 테스트 경로를 이미 라우팅된 소규모 MoE(mixture-of-experts) 계층 — 백만 입력 토큰당 $0.06, 백만 출력 토큰당 $0.33, 262,144토큰 창을 갖춘 Gemma 4 26B-A4B 변형 — 으로 돌리고, 독일어 문서 워크로드가 Kolibri가 제공하는 것을 실제로 필요로 하는지 확인해 보십시오, 하나의 OpenAI 호환 키로, 제공자의 정가로 아무것도 추가하지 않고. 필요로 한다면, 감이 아니라 증거를 가지고 GPU를 구매하는 것입니다. 필요로 하지 않는다면, 하드웨어 주문을 아낀 셈입니다.

평결, 그리고 그것을 바꿀 수 있는 것

이것은 승자가 정해지는 맞대결이 아니다. Kolibri와 Granite 4.2 3B는 서로 다른 가격대에서 서로 다른 질문에 답하며, 유일하게 정직한 순위는 제약 조건에 따른 것이다: 제약이 하드웨어라면 Granite 4.2 3B가 둘 중 유일하게 조건을 충족한다. 제약이 온프레미스에서의 독일어 규제 문체 문서 작업이라면 Granite 4.2 3B는 애초에 후보에 오른 적이 없고, Kolibri가 더 흥미로운 결과물이다 — 정당한 78B 오픈 웨이트 릴리스이자 Apache 2.0이며, 데이터 파이프라인과 토크나이저가 가중치와 함께 공개되었다.

두 가지가 그 비교를 매듭지어 줄 것입니다. 독일어 문서 QA 작업에서 Kolibri를 독립적으로 실행해 보면, 이 릴리스가 실제로 내세우려고 만들어진 주장을 검증할 수 있습니다. 현재 이를 측정하는 리더보드는 없으니까요. 그리고 Granite 4.2 3B의 추론 수치를 독립적으로 재현해 보면, 애초에 780억 개 매개변수가 필요 없었던 여러분의 워크로드 하위 집합에서 노트북급 장비가 제 몫을 할 수 있는지 알 수 있을 것입니다. 그중 하나가 나오기 전까지는 매개변수 수가 아니라 제약 조건을 기준으로 구매하세요.