Bonsai 2는 누구도 출시 예정이라고 발표하기 전에 Ollama에 등장했다

2026년 10월 17일 새벽 어느 시각, Ollama서비스하기 시작했다Bonsai 2 — 9개 태그로 이루어진 라이브러리 항목으로, Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B 및 Bonsai 2 27B를 아우르며, 각각 두 가지 패킹과 기본 별칭을 갖춘다. Prism ML은 이에 대해 아무 말도 하지 않았다. 벤더의 뉴스 페이지에는 게시물이 없고, 10월 15일 소형 모델 발표에도 언급이 없다 — 그 게시물은 런타임으로 llama.cpp와 MLX를, 데모로 호스팅 콘솔을 지목하며 Ollama는 전혀 언급하지 않는다. 이 목록은 그냥 존재하는데, 아홉 개 태그 모두 같은 몇 시간 전으로 찍혀 있어, 이는 새로 푸시한 모습이지 점진적 롤아웃의 모습이 아니다.

그래서 솔직한 구분은 이렇습니다. 지금 레지스트리와 파일에서 알 수 있는 것: 태그, 그 이름, 정확한 바이트 크기, 콘텐츠 다이제스트, 그리고 — Ollama가 GGUF를 제공하므로 — 가중치 자체 내부의 아키텍처와 메타데이터 문자열입니다. 확인되지 않은 것: 누가 이들을 패키징했는지, 벤더의 발표에서 플랫폼을 왜 생략했는지, 삼진 커널이 Ollama 자체 엔진의 업스트림인지 아니면 벤더링된 것인지, 그리고 벤더의 수치 중 무엇인가가 그 과정을 거쳐도 살아남는지입니다. 이는 별개의 질문이며 이 글은 그것들을 분리해 둡니다.

선반 위에 실제로 무엇이 있는가

태그 9개, 크기 4개, 동일한 가중치의 패킹 3개. Ollama의 라이브러리 페이지에는 각 크기별 기본 별칭과 -q2_0 변형이 각 크기별로 나열되어 있습니다:

• bonsai-2:latest — 3.2 GB, 9B(다이제스트 c8b5462f8688)로 확인됨

• bonsai-2:2b 및 bonsai-2:2b-q2_0 — 911 MB, 동일한 digest de2ccb4e7328

• bonsai-2:4b 및 bonsai-2:4b-q2_0 — 1.6 GB, 동일한 다이제스트 93edd652c932

• bonsai-2:9b 및 bonsai-2:9b-q2_0 — 3.2 GB, 동일한 다이제스트 c8b5462f8688

• bonsai-2:27b 및 bonsai-2:27b-q2_0 — 8.3 GB, 동일한 다이제스트 f3c4f4208659

이름은 겉보기보다 더 많은 일을 하고 있다. 크기마다 두 개의 태그가 다이제스트를 공유하는 것은 중복이 아니다 — 그것은 Ollama가 어떤 패킹을 골랐는지에 대한 진술이다. bonsai-2:9b의 매니페스트를 가져오면 모델 레이어는 2.557 GB다. 그것은 Ternary Bonsai 2 9B의 Q2_0 파일이며, Hugging Face에서 바이트 단위까지 정확히 2.557 GB로 측정된다. PQ2_0 팩은 2.417 GB이고, PTQ1_0 팩 — 1.997 GB로 가장 작은 — 은 여기에 아예 없다.

그 선택에는 분명히 짚고 넘어갈 만한 결과가 따른다. 그런 일은 십상 지원 스레드로 번지기 때문이다. 벤더의 모델 카드에 따르면, 업스트림 llama.cpp는 세 가지 패킹 중 정확히 하나만 실행한다. 바로 Q2_0, 즉 "Hadamard 활성화 런타임이 포함된 최신 master"다. 그것은 PQ2_0과 PTQ1_0을 알 수 없는 유형으로 거부한다. 왜냐하면 그것들은 Prism ML llama.cpp 포크가 필요하기 때문이다. Ollama는 자체 엔진을 제공한다. Q2_0은 순정 GGUF 소비자가 그럭저럭 로드할 수 있는 팩이며, Q2_0은 바로 Ollama가 출시한 팩이다. Ollama가 자체 삼진 커널을 키웠는지, 아니면 벤더링된 빌드로 라우팅하는지는 레지스트리가 알려주지 않는다. 레지스트리가 알려주는 것은, 그들이 로드할 수 없는 파일을 출시하지는 않았다는 사실이다.

GGUF 메타데이터는 페이지가 알려주는 것보다 더 많은 것을 알려줍니다.

Ollama의 페이지는 태그마다 네 가지 사실을 보고한다: 바이트 크기, "256K" 컨텍스트 배지, 텍스트+이미지 입력 유형, 상대적 타임스탬프. 나머지 모든 것은 파일 안에 있다. 각 모델 계층의 GGUF 헤더를 읽으면 다음을 알 수 있으며, 여기에는 특별한 이유로 읽을 가치가 있다: 이것은 이 이야기에서 누군가의 마케팅 주장이 아닌 유일한 부분이다.

• general.architecture — 네 가지 크기 모두에서 qwen35

• general.name — 소형 3종에서는 Ternary-Bonsai-2-2B, -4B, -9B; 27B 레이어는 general.basename = folded와 함께 일반 문자열 Hf를 보고합니다

• general.file_type — 네 개 모두에서 41, general.quantization_version = 2와 함께

• general.size_label — 2B, 4B, 9B, 27B, 태그 이름과 일치

• 텐서 수 — 2B는 320개, 4B는 426개, 9B는 427개, 27B는 851개

아키텍처 문자열이 흥미로운 부분이다. qwen35는 Qwen3.5 하이브리드 어텐션 백본이며, 모델 카드가 산문으로 말하는 내용을 아티팩트 자체에서 확인해 준다: 작은 세 개는 Qwen3.5-2B, -4B, -9B이고 아키텍처는 그대로이며 가중치만 교체되었다. 또한 벤더 자체의 릴리스 노트가 덮어 숨기는 이름 짓기 이음새를 드러낸다. 10월 15일 글에서는 새 모델들이 "Qwen3.5에 기반한다"고 말한다. 27B는 완전히 다른 기반이다 — 9월 17일에 발표된 Qwen3.8-27B. 네 가지 크기, 하나의 제품군 이름, 두 개의 기반 모델. 27B에서 측정된 "Bonsai 2" 동작에 대해 읽은 내용은 9B로 자동으로 전이되지 않으며, 그 이유는 GGUF 헤더에서 볼 수 있다.

27B의 메타데이터 또한 나머지보다 눈에 띄게 덜 정돈되어 있습니다. general.name = Hf, general.basename = folded, general.version = v5, 그리고 작은 세 모델에는 없는 추가 샘플링 키가 하나 있습니다. 그것은 변환 파이프라인의 중간 출력이 최종 이름 변경 단계 없이 푸시될 때 보이는 모습입니다. 그것은 결함이 아닙니다 — 텐서는 텐서일 뿐입니다 — 하지만 일종의 지문이며, 27B 태그가 작은 세 모델과는 다른 경로를 통해 들어왔음을 시사합니다.

Ollama 숫자가 의미하지 않는 것

여기가 대부분의 라이브러리 목록 보도가 잘못되는 지점이므로, 잠시 속도를 늦출 가치가 있습니다. Ollama 페이지의 바이트 크기는 컨테이너 크기이며, 모든 크기에서 내부 모델 파일보다 더 큽니다. 2B 태그는 0.547GB 모델 레이어와 0.365GB 비전 프로젝터에 비해 911MB로 표시됩니다. 27B 태그는 7.626GB 모델 레이어와 0.629GB 프로젝터에 비해 8.3GB로 표시됩니다. 라이선스와 파라미터 블롭을 더하면 계산이 맞아떨어집니다: Ollama는 비전 타워까지 포함해 내려받은 전체 아티팩트를 제시하고 있는 것입니다.

즉, Ollama 페이지에서 9B에 대해 표시된 3.2GB는 같은 모델에 대한 벤더의 "2GB" 수치와 비교할 수 있는 것이 아니며, 그 격차는 보고해야 할 불일치가 아니라 서로 다른 두 가지에 대한 서로 다른 두 측정값입니다. Prism ML의 0.43GB / 0.95GB / 2GB는 언어 모델만의 수치입니다. 비전 타워는 오프로드되어 실제로 이미지가 들어올 때만 로드되므로, 텍스트 전용 배포에서는 그 비용을 전혀 치르지 않지만 ollama pull은 치릅니다. 벤더의 수치에 맞춰 기기를 사이징한 뒤 Ollama에서 풀한다면, 무엇이든 실행하기도 전에 예산이 0.5~1GB 초과됩니다.

같은 주의가 "256K" 배지에도 적용된다. 그 기저의 컨텍스트는 Qwen3.5 백본에서 물려받은 262,144 토큰이며 — 9B에서 24개의 선형 어텐션과 8개의 전체 어텐션 레이어 — Ollama의 배지는 표시를 위해 이를 내림한다. 컨텍스트는 실제이며, Ollama가 추가한 것이 아니라 물려받은 것이다. 무엇이 명시되지 않은 것, 즉 페이지 어디에도 나와 있지 않은 것은 긴 컨텍스트가 메모리를 얼마나 소모하는지이며, 일부 레이어에 전체 어텐션 캐시가 있는 하이브리드 어텐션 모델에서는 그것이 작은 숫자가 아니다. Ollama 페이지 어디에도 262K가 실제로 실행하려는 곳에 들어가는지 알려주지 않는다.

누가 이걸 패키징했으며, 그게 중요할까요?

답변되지 않음, 그리고 추측하기보다는 답변되지 않음으로 표시해야 합니다. 세 가지 가능성이 있습니다: Prism ML이 푸시했거나, Ollama가 자체 카탈로그 작업의 일부로 공급업체의 공개 GGUF 저장소에서 가져왔거나, 제3자가 그렇게 했을 수 있습니다. 레지스트리는 어느 것인지 알 수 없습니다.

확인할 수 있는 것은 아티팩트의 출처이며, 이는 서로 맞아떨어진다. Ollama 자체의 모델 설명에는 "Prism ML의 Bonsai 2는 삼진 가중치(−1, 0 또는 +1)를 위해 구축된 비전 모델 제품군으로, 표준 4비트 모델의 약 절반 크기이면서 거의 전체 정밀도에 가까운 품질입니다"라고 되어 있고, 벤더의 Hugging Face 조직, Bonsai 2 27B 백서, Apache 2.0을 링크한다. 네 가지 크기 매니페스트 각각에 내장된 라이선스 블롭은 그대로의 Apache 2.0 텍스트이다. 2B, 4B, 9B의 파라미터 블롭은 {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95}로 되어 있는데, 이는 벤더가 권장하는 사고 모드 샘플링 레시피이며, 27B 카드에서 GGUF 파일이 min_p를 생략한다고 말하는 그대로 min_p가 생략되어 있다. 그것은 누군가가 한 추측이 아니다. 그것은 카드를 읽은 변환이다.

이는 안심이 되지만, 당신의 경험을 실제로 좌우하는 것, 즉 실행 중인 엔진에 ternary 커널이 들어 있는지에 대해서는 여전히 아무것도 알려주지 않습니다. 정직한 입장은 성공적인 pull이 파일이 올바른 형식의 GGUF임을 증명할 뿐, 그 이상은 아니라는 것입니다. 이것을 토대로 삼기 전에 자신의 하드웨어에서 검증하세요.

공급업체의 주장 및 확인된 사항

이 패밀리에 붙은 모든 품질 수치는 Prism ML에서, Prism ML 자체 하네스에서 나온 것이며, 그중 어느 것도 독립적으로 재현되지 않았다. 이는 이 단계에서는 정상이며, 암시하기보다 분명히 말해야 한다. 10월 15일 게시물은 소형 모델에 대해 여섯 가지 기술 영역에 걸친 19개 벤치마크를 보고하며, 전체 정밀도 Qwen3.5 기준선 대비 유지율을 제시한다:

• 2B — 에이전트 95.5%, 수학 107.8%, 지시 따르기 121.5%, 코딩 115.0%, 지식 82.9%, 비전 89.0%

• 4B — 90.0% / 99.3% / 106.0% / 100.7% / 90.9% / 91.3%

• 9B — 92.4% / 98.2% / 100.0% / 100.1% / 93.0% / 92.5%

그중 여러 수치가 100%를 넘는데, 이는 오타도 반올림 오차도 아니다 — 해당 범주에서 삼진 모델이 자신이 파생된 전체 정밀도 모델보다 더 높은 점수를 받았다는 뜻이다. 2B의 명령 수행 능력 121.5%가 가장 두드러지는 예다. 이는 마땅히 의심스럽게 봐야 한다: 압축된 모델이 공급업체가 고른 벤치마크에서 자기 기준선을 능가했다는 것은 최소한 표현 자체에 관한 것만큼이나 학습과 평가 하네스에 관한 진술이며, 소형 모델 범주 점수는 27B보다 훨씬 더 노이즈가 많다. 27B의 수치는 더 보수적이고 그 형태도 더 믿을 만하다 — FP16의 86.32에 맞선 84.78, 14개 사고 모드 벤치마크 전반에 걸친 98.2% 유지율, 수학은 96.57 대 97.06, 코딩 수준은 89.42 대 89.07이며, 손실은 지식/추론과 비전에 집중되어 있다. 어떤 패밀리가 1.7비트 표현 아래에서 능력을 포기할 때, 그것이 바로 예상할 수 있는 양상이다.

소형 모델 글에서 벤치마크가 아닌 단 하나의 주장이 가장 진지하게 받아들일 가치가 있는 주장이다: 9B는 "표준 지시 따르기와 일상 수학 작업에서 대략 40% 더 적은 토큰을 사용한다." 이것은 능력이 아니라 장황함에 관한 주장이며, 자신의 프롬프트로 오후 한나절이면 확인할 수 있는 종류의 것이다. 또한 이는 공급업체 자체의 모델 카드에 있는 경고와 맞물린다. 사고 모드는 사소한 질문에도 3,000개 이상의 토큰을 태울 수 있으므로 출력 토큰을 최소 8,192개로 설정하고, 사고 모드를 켠 채 그리디 디코딩을 실행하지 말라. 추론에 갇힐 수 있기 때문이다. 40% 덜 장황하면서도 여전히 8,192토큰 예산이 필요한 모델은 특정한 곳에서 장황하다고 말해 주는 것이다.

이 상황이 당신에게 의미하는 바

이미 Ollama를 실행 중이고 데이터센터 GPU 없이 노트북에서 27B급 모델을 시험해 보고 싶다면, 네 개의 태그가 지금 존재하는 가장 짧은 경로입니다: 한 번의 pull, 포크 없음, 커널 빌드 없음. 실제로 가장 작은 패킹이 필요하거나, 벤더가 4B와 9B용으로 제공하는 추측 디코딩 드래프터가 필요하다면, Ollama 목록에는 그것들이 없습니다 — 그것은 Hugging Face 다운로드와 Prism ML의 llama.cpp 빌드이며, 10월 15일부터 그랬습니다.

또 하나 알아둘 만한 점은, 로컬이 저비트 모델을 사용하는 유일한 방법이 아니며 항상 정답인 것도 아니라는 것입니다. OrcaRouter는 하나의 API로 200개 이상의 호스팅 모델을 0% 마크업으로 — 공급자 정가를 그대로 전달하며 — 제공하고, 공급자 간 자동 페일오버까지 지원합니다. 따라서 어떤 모델이 노트북에 자리를 차지할 자격이 있는지 결정하기 전에 실제 워크로드에서 그 모델을 평가해 볼 수 있습니다. 현재 OrcaRouter를 통해 제공되는 Bonsai 2 크기는 없으며, 이 글도 그렇다고 주장하지 않습니다. 이 제품군은 직접 실행하는 다운로드이며, 벤더가 엔드포인트를 공개할 때까지 그대로 유지됩니다. 라우팅 계층이 여러분에게 주는 것은 결정의 나머지 절반입니다. 즉, 하나의 키 뒤에서 비교하게 될 호스팅 모델들이며, 단일 모델로 충분하지 않을 때 활용할 수 있는 모델 퓨전과 라우팅 DSL도 함께 제공됩니다.

판도를 얼마나 바꿀지 순서대로 주목할 것: Ollama 태그가 ptq1_0 형제를 얻는 것 — 이는 dense-trit 커널이 업스트림에 들어갔다는 뜻이다; 플랫폼을 인정하는 벤더 게시물 — 이는 출처 문제에 답할 것이다; 그리고 9B 또는 27B에 대한 독립적인 벤치마크 — 이것만이 리텐션 수치를 벤더 보고 열에서 벗어나게 할 유일한 것이다. 그중 하나가 나오기 전까지, 이 리스팅은 새로운 모델이 아니라 전달 메커니즘이다 — 그리고 그것이 전달하는 모델은 10월 15일부터 공개되어 왔다.

그중 어느 것도 가정이 아닙니다: 이번과 같은 릴리스의 배경이 된 문서화된 AI 실패와 에이전트 사고는 OrcaRouter AI Incident Archive에 수집되어 있으며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급, 분쟁 플래그가 함께 제공됩니다.