Bonsai 27B: Bonsai 패밀리의 27B 모델, 해설

Bonsai 27B는 PrismML의 Bonsai 제품군에 속한 270억 개 매개변수 모델이며, 사람들이 "bonsai 27b"를 입력할 때 의미하는 바로 그 모델입니다. 하지만 이름만으로는 거기에 도달할 수 없습니다. 그와 비슷한 이름으로 불리는 서로 다른 세 가지 대상이 있기 때문입니다. Bonsai 27B는 Qwen3.6-27B를 저비트로 재구축한 모델로, 공급업체 자체 발표에 따르면 날짜는 2026년 7월 14일이며, 동일한 모델의 두 가지 팩으로 제공됩니다. 하나는 약 3.9GB에 이진 {−1, +1} 가중치를 저장하는 1비트 Bonsai 27B이고, 다른 하나는 가중치당 유효 1.71비트로 삼진 {−1, 0, +1} 가중치를 저장하는 Ternary Bonsai 27B입니다. 공급업체의 대표 수치로는 5.9GB이지만, 실제 출시되는 팩 기준으로는 7.165GB입니다. 이는 Qwen3.8-27B 기반으로 별도 이름이 붙은 2세대 모델인 Ternary Bonsai 2 27B가 아니며, PrismML이 스냅드래곤 AR1 Gen 1 스마트 안경용으로 만든 20억 개 매개변수 비전-언어 모델도 아닙니다. Bonsai 27B의 두 팩 모두 262,000 토큰 컨텍스트, 콤팩트한 4비트 비전 타워, Apache 2.0 라이선스를 갖추고 있습니다. 모델은 Bonsai 27B이며, 그다음의 결정은 두 팩 중 어느 것이 당신의 메모리 예산에 맞는가입니다.

이 페이지는 그 모델에 대한 레퍼런스입니다. 이것은 공지가 아닙니다. Bonsai 27B는 2026년 7월부터 제공되어 왔으며, 이제 이에 대해 답할 가치가 있는 질문은 독자가 이 글을 찾아올 때 이미 품고 있는 질문들입니다 — 그것이 정확히 무엇인지, 그 이름이 무엇을 구분하는지, 그리고 실제로 그것을 실행하는 데 드는 비용은 얼마인지.

어느 것이 27B인가요?

여기서의 혼동 가능성은 실재하며, 무엇보다 먼저 해결할 가치가 있습니다. 잘못 추측하면 20억 매개변수 모델로 보내지거나, 올바른 모델의 잘못된 세대로 보내지기 때문입니다.

• Bonsai — 제품군 이름이자 벤더가 붙인 이름입니다. 그 자체만으로는 다운로드할 수 있는 어떤 것도 특정하지 못합니다. PrismML은 Bonsai 1.7B, Bonsai 4B, Bonsai 8B, Bonsai 27B와 Bonsai Image, 그리고 20억 개 매개변수 안경 모델을 출시했으며, 더 작은 라인을 위한 2026년 4월의 이전 릴리스인 Ternary Bonsai도 내놓았습니다. 이 단어만으로 검색하면 그 집합 중 하나로 무작위로 연결됩니다.

• Bonsai 27B — 이 페이지의 주제입니다. 27B 라인의 1세대이며, Qwen3.6-27B에서 파생되었고, 2026년 7월 14일자입니다. 페이지에서 다른 수식어 없이 "2" 없이 "Bonsai 27B"라고 하면, 이것이 의미하는 모델이며, 이것이 사용해야 할 이름입니다.

• Ternary Bonsai 27B — 다른 모델이 아닙니다. 이것은 Bonsai 27B의 품질 지향 팩입니다: 동일한 27B 모델, 동일한 아키텍처와 동일한 베이스에 이진 가중치 대신 삼진 가중치를 사용합니다. 저장소 이름은 Ternary-Bonsai-27B-gguf이며, 모델 카드에는 바이너리 카드와 똑같이 Qwen3.6-27B를 베이스로 명시합니다. 여기서 "Ternary"는 버전이 아니라 가중치 형식입니다.

• Ternary Bonsai 2 27B — 정말로 다른 모델입니다. 27B 라인의 2세대로, Qwen3.8-27B를 기반으로 하며 2026년 9월 17일에 발표되었고, 파라미터 분할 방식과 품질 주장이 다릅니다. "2"가 모든 차별점을 담고 있습니다.

• 1-bit Bonsai 2B — 다른 규모의 다른 패밀리 구성원: 어떤 정밀도에서든 27B 모델이 아니라 안경급 하드웨어를 위한 20억 매개변수 비전-언어 모델입니다.

그래서 이들 중 어느 것이 27B 모델인지 결론내리려고 여기 오셨다면, 답은 위의 세 번째와 네 번째 줄이 두 가지 가중치 형식으로 된 같은 모델이고, 다섯 번째는 27B 모델이 아니라는 것입니다. 실용적으로는 그것을 Bonsai 27B라고 부르고, 중요한 때에는 팩을 추가하세요.

모델 카드에서 가져온 명세

이 섹션의 모든 수치는 두 팩에 대해 PrismML이 공개한 모델 카드에서 가져온 것이며, 이는 벤더가 자사 모델에 관해 한 진술입니다. 어떤 숫자가 측정값이 아니라 주장인 경우, 그렇게 표시되어 있습니다.

• 파라미터 — 총 약 27.3B이며, "27B"는 그 전체를 가리킵니다. 이 분할은 메모리 동작을 설명하기 때문에 알아둘 가치가 있습니다: 약 24.8B는 64개 블록에 걸친 언어 백본에 있고, 약 2.5B는 임베딩과 LM 헤드에 있으며, 약 0.46B는 27개 블록의 비전 타워에 있습니다. 저비트 표현은 엔드 투 엔드로 적용됩니다 — 임베딩, 어텐션, MLP 및 LM 헤드 — 언어 네트워크 어디에도 더 높은 정밀도의 탈출구가 없습니다.

• 컨텍스트 — 무려 262,000 토큰이며, 롱 컨텍스트 변형도, 축소된 컨텍스트 빌드도 없습니다. 그 윈도우의 비용은 전액 지불되기보다 관리됩니다. 백본이 하이브리드라서 64개 레이어 중 16개만 전체 어텐션 캐시를 유지하고, 그 캐시는 거의 무손실에 가까운 4비트 형태로 저장됩니다. 전체 262K 윈도우에서 압축된 캐시 덕분에 모델은 바이너리 팩에서 대략 9.4GB, 터너리 팩에서 12.8GB 이내에 머뭅니다.

• 모달리티 — 텍스트와 이미지, 두 팩 모두입니다. 비전 타워는 컴팩트한 4비트 형식(0.63GB)으로 제공되며, 그와 함께 BF16 복사본(0.93GB)도 제공됩니다. 비전은 또한 압축 비용이 가장 많이 드는 부분이며, 이는 아래에서 다룹니다.

• 가중치 형식 및 크기 — 1-bit Bonsai 27B는 FP16 그룹별 스케일링과 함께 이진 {−1, +1} 가중치를 사용하며, 실제 가중치당 유효 1.125비트인 GGUF Q1_0_g128로 패킹됩니다. 제공되는 파일은 3.803 GB이고, 카드에서는 배포된 설치 공간을 약 3.9 GB로 반올림합니다. Ternary Bonsai 27B는 동일한 그룹별 스케일링과 함께 삼진 {−1, 0, +1} 가중치를 사용합니다. 삼진 값은 log₂3 ≈ 1.585비트의 정보를 담으므로 이 표현의 하한은 가중치당 약 1.71비트이며, 이는 이상적으로 5.9 GB에 해당합니다. 공개된 삼진 팩은 그 이상치보다 더 큽니다. 왜냐하면 오늘날의 커널은 각 삼진 값을 2비트 슬롯에 저장하기 때문입니다 — 배포 시 가중치당 2.125비트 — 그리고 제공되는 파일은 7.165 GB입니다. PrismML은 좋게 보이는 수치만이 아니라 두 수치를 모두 제시하며, 두 수치 사이의 격차는 모델링 선택이 아니라 커널 한계입니다.

• 라이선스 — 두 팩 모두 Apache 2.0이며, 두 저장소와 공급업체의 발표문에 명시되어 있습니다. 이는 사용 분야 제한이 없는 허용적 라이선스로, 이런 가중치 규모에서는 대부분의 경우보다 더 중요합니다.

• 기본 모델 — 두 경우 모두 Qwen3.6-27B입니다. 이는 처음부터 학습한 모델이 아니라 다른 누군가의 모델을 재압축한 것이며, 그 결과 Bonsai 27B의 성능 상한과 갱신 주기는 모두 PrismML의 것이 아니라 업스트림 27B 라인을 따릅니다.

삼항 관계, 한 번 진술하면

두 팩은 하나의 모델이며, 솔직히 요약하자면 삼진(ternary)은 품질을 얻고 이진(binary)은 용량을 얻는 선택인데, 둘 사이의 격차는 3.9GB 대 7.2GB라는 크기 차이가 시사하는 것보다 작다.

PrismML 자체의 15개 벤치마크 사고 모드 스위트에서 FP16 Qwen3.6-27B 베이스라인은 85.07점을 기록한다. Ternary Bonsai 27B는 80.49점으로 94.6% 유지율을 보이며, 공급업체는 이를 약 95%로 반올림한다. 1-bit Bonsai 27B는 76.11점으로 89.5%, 반올림하면 약 90%다. 따라서 품질 지향 팩은 이진 팩과 완전 정밀도 사이 거리의 약 절반을 회복하는 대신 약 3.3GB를 더 쓰며, 12GB 휴대폰에 들어가는 쪽은 이진 팩이다. 같은 스위트에서 동일 베이스라인의 4비트 Q4_K_XL 빌드는 17.6GB에서 84.99점, 즉 99.9% 유지율을 기록하는데, 이 비교가 두 저비트 팩이 애초에 존재하는 이유를 설명해 준다. 품질에서는 이들보다 앞서지만, 모델에 내줄 메모리가 18GB 미만인 모든 기기에서는 밀리기 때문이다.

바이너리 팩이 성능을 내주는 지점은 일정하지 않으며, 범주 분할이 유용한 부분이다. FP16 기준선과 비교하면 수학에서는 95.33에서 91.66으로, 코딩에서는 88.74에서 81.88로 떨어지지만, 지시 따르기에서는 78.47에서 65.74로, 에이전트 및 도구 호출 작업에서는 80.00에서 66.03으로, 비전에서는 72.61에서 59.57로 떨어진다. 워크로드가 산술이나 코드 완성이라면 3.9 GB는 거의 공짜에 가깝다. 도구 호출 에이전트나 이미지 이해라면, 바로 그 부분에서 압축 비용을 실제로 치르는 셈이다.

모델 카드는 또한 intelligence density라고 부르는 파생 수치를 공개한다 — 기가바이트당 집계 점수로, 완벽한 점수가 무한대에 가까워지도록 정규화된 값이다. 이 기준에서 1-bit Bonsai 27B는 0.530에 도달하고 Ternary Bonsai 27B는 0.400인 반면, 같은 베이스라인의 2-bit IQ2_XXS 빌드는 0.199, 4-bit Q4_K_XL 빌드는 0.155, FP16 모델은 0.051이다. 그 목록에서 흥미로운 숫자는 첫 번째 비교다: 바이너리 팩은 절반도 안 되는 풋프린트로 집계 품질에서 기존 2-bit 빌드를 앞서며, 이는 이 제품군의 전체 논지를 한 줄로 보여준다.

두 팩 간의 전체 맞대결과 각 팩의 수치가 어디에서 나오는지는 이 블로그의 Bonsai vs Bonsai 27B 페이지에, 같은 패밀리 이름을 공유하는 20억 매개변수 모델과 함께 정리되어 있습니다.

이 모델과 함께 떠오르는 한 가지 질문에는 사실에 근거한 답변만이 어울립니다. 이 팩들은 재학습된 변형이 아니라 동일한 기반 모델을 저비트로 인코딩한 것이며, 저장소들은 그 옆에 별도로 튜닝되었거나 검열되지 않은 체크포인트를 공개하지 않습니다 — 제공되는 유일한 전체 정밀도 산출물은 동일한 가중치를 언팩한 FP16 변환본이며, 이는 기본 제공 도구에서 압축 팩을 자체 베이스라인과 비교할 수 있도록 공개된 것입니다.

리포지토리에서 가져온 가중치 및 라이선스

Bonsai 27B의 가중치는 Hugging Face의 prism-ml 조직 아래에 공개되어 있으며, 파일 목록은 이번 릴리스에서 가장 구체적인 부분이다. 바이너리 팩의 저장소에는 모델 자체가 3.803 GB로, 비교용으로 같은 모델의 FP16 GGUF가 53.808 GB로, DSpark 추측 디코딩 드래프터가 4비트에서 1.787 GB, BF16에서 7.292 GB로, 그리고 비전 타워가 0.931 GB와 0.629 GB로 실려 있다. ternary 저장소에는 자체 7.165 GB 팩과 함께 7.585 GB의 두 번째 패킹이 들어 있는데, 이는 group-128이 아니라 group-64이며 최적이 아니라 업스트림 호환이다. 또한 동일한 드래프터와 비전 파일도 있다. 두 저장소 모두 Apache 2.0이며, 둘 다 Qwen3.6-27B를 베이스로 명시한다.

그 목록에서 두 가지가 따라온다. 첫째는 53.808 GB 대 3.803 GB가 모델 카드가 앞세우는 14.2배 비율이며, 이는 주장된 것이 아니라 확인 가능하다는 점이다 — 전체 정밀도 파일이 바로 거기에 있다. 둘째는 이 릴리스가 모델보다 더 무겁다는 점이다. 멀티모달 경로가 요구하는 드래프터와 비전 타워까지 포함하면, 3.9 GB 모델 위에 대략 2.4 GB를 더하게 된다. 3.9 GB라는 대표 수치는 언어 가중치일 뿐 배포 전체가 아니다.

다운로드는 품질 지향 팩이 앞서는 유일한 지점이다. 2026년 10월 기준으로 ternary GGUF 리포지토리는 다운로드 59만 건을 넘어선 반면, 바이너리 팩은 40만 건을 조금 넘는 수준이며, 두 팩의 MLX 컨테이너는 각각 100만 건을 넘는다. 이런 양상은 이 모델의 대부분이 서버가 아니라 Apple 하드웨어에서 실행되고 있으며, 다운로드하는 사람들이 가능한 한 가장 작은 파일이 아니라 추가된 리텐션 5포인트를 선택하고 있음을 시사한다. 이는 대략 벤더가 이 두 팩을 설계한 의도와 맞아떨어진다.

그것을 실행하기

현재 얻을 수 있는 것은 팩당 네 가지 종류의 아티팩트이며, 어떤 것을 원할지는 품질이 아니라 런타임에 의해 결정됩니다.

• llama.cpp용 GGUF — 주요 경로이자, 저비트 커널이 작성된 대상입니다. 두 팩 모두 CUDA, Metal, CPU용 llama.cpp 빌드이지만, 1비트 및 삼진 커널은 업스트림이 아니라 PrismML 자체 포크에 있으므로 현재 순정 llama.cpp에서는 이를 올바르게 로드하지 못합니다. group-64 삼진 패킹은 업스트림 호환성이 필요하고, 그 대가로 7.165GB 대신 7.585GB를 감수할 의향이 있는 경우를 위해 정확히 존재합니다.

• Apple silicon용 MLX — 바이너리 팩용 5.129 GB, 삼진 팩용 8.491 GB로 별도 제공되는 컨테이너입니다. MLX 바이너리 컨테이너는 GGUF 바이너리 팩보다 큰데, 이는 모델이 달라서가 아니라 컨테이너 오버헤드 차이 때문입니다.

• 서버 프레임워크용 AWQ 4비트 — AWQ 체크포인트를 요구하는 서빙 프레임워크를 위한 각 모델의 4비트 빌드로, 총 18.70 GB에 달하는 9개 샤드로 구성되어 있으며 멀티 GPU 레시피도 포함합니다. 이것은 저비트 아티팩트가 아닙니다. 랙에서 합리적인 정밀도로 만든 동일한 모델이며, 모델이 존재하는 이유 전체를 맞바꾸는 것입니다.

• Unpacked FP16 safetensors — 약 54GB에 달하는 전체 모델을 Hugging Face 순정 형식으로 제공하는 아티팩트로, 1비트 가중치를 아직 네이티브로 지원하지 않는 프레임워크를 위해 명시적으로 공개되었습니다. 벤더는 저비트 커널이 업스트림에 반영되면 이 아티팩트는 폐기될 것이라고 밝혔습니다.

바이너리 팩에서 측정된 디코드 처리량은 모델 카드 자체의 표에 따르면 M5 Max에서 초당 66.4토큰, M5 Pro에서 44.2, M4 Pro에서 26.0, H100에서 104.8이며, 프리필은 각각 초당 874, 421, 133, 2,755토큰입니다. 발표 페이지에는 더 높은 최고치가 제시되어 있습니다 — M5 Max에서 최대 초당 87토큰, RTX 5090에서 163토큰 — 이는 표의 수치가 아니라 벤더 자체의 최상 조건 구성에서 나온 값입니다. 두 수치 집합을 모순이 아니라 서로 다른 측정 조건으로 취급하고, 둘 다 벤더가 보고한 값으로 취급하십시오. 최대 메모리는 다시 카드 기준으로 바이너리 팩에서 4K 컨텍스트일 때 5.2GB, 10K일 때 5.6GB, 100K일 때 11.6GB이고, ternary 팩에서는 8.4, 8.7, 14.7GB입니다 — 다만 이 수치들은 4비트 KV 캐시 이전의 것이며, 4비트 KV 캐시가 바로 전체 262K 윈도우를 한 자릿수 GB로 낮추는 요소라는 점을 유의하십시오.

DSpark 드래프터는 선택 사항이며, 활성화하기 전에 이해해 둘 가치가 있습니다. 출력에는 아무것도 바뀌지 않기 때문입니다. 이는 다섯 개의 균등 간격 대상 레이어에서 추출한 은닉 상태를 조건으로 하는 6계층 블록 병렬 트랜스포머이고, 서빙 정밀도에서 약 0.5GB를 추가하며, 자체적으로 샘플링하는 대신 대상 모델에 대해 검증합니다. 그렇기 때문에 벤더는 품질 수치를 건드리지 않고도 CUDA에서 1.37배 속도 향상을 제시할 수 있습니다. Apple silicon에서는 기본적으로 활성화되지 않습니다.

로컬 모델이 한계에 부딪히는 지점은 흥미로운 엔지니어링 질문이며, 이는 모델 질문이라기보다 라우팅 질문입니다. 노트북 위의 3.9GB 모델은 컨텍스트에 들어맞는 것을 처리하고, 나머지는 모두 어딘가로 가야 하는데, 그 어딘가는 API 뒤에 있는 호스팅 모델입니다. OrcaRouter는 바로 그 계층입니다 — 200개 이상의 호스팅 모델을 아우르는 단일 엔드포인트 제공업체 정가에 0% 마크업, 제공업체 전반에 걸친 자동 페일오버, 그리고 로컬 티어에서 호스팅 티어로의 에스컬레이션 규칙을 수작업으로 조립하는 대신 구성으로 표현합니다. 이는 로컬 모델을 대체하는 것이 아니라 그 위에 있는 계층입니다.

비교 지수

Bonsai 27B는 각 이웃이 서로 다른 질문에 답하는 패밀리에 속해 있으며, 이 페이지들은 각각의 질문을 하나씩 다룹니다 — 그중 어느 것도 여기서 다시 논증되지는 않습니다.

• Bonsai vs Bonsai 27B — 20억 매개변수 안경 모델과 이 모델의 맞대결: 매개변수는 16배, 컨텍스트는 256배이며, 왜 패밀리 이름만으로는 여러분이 무엇을 다운로드하는지에 대한 정보를 전혀 알 수 없는지. 이 페이지는 여기 있는 블로그 글이지 호스팅된 모델이 아니며, 이는 이 패밀리에서 제대로 구분해 둘 만한 차이다.

• Bonsai 27B 대 Qwen3.8-27B — 이 모델과 이 모델이 사용하지 않는 더 새로운 베이스 간의 맞대결입니다. 이 배치의 전용 페이지가 그 비교를 담고 있으며, 두 모델이 비슷한 이름으로 불리고 한 세대 차이가 나기 때문에, 이 사양서의 연장선으로 보기보다는 그 자체의 관점에서 읽을 가치가 있습니다.

• Bonsai vs Ternary Bonsai 2 27B — 세대 간 도약, 그리고 두 릴리스가 서로 다른 두 잣대에 비추어 품질을 보고한다는 사실: 한쪽은 베이스라인 유지, 다른 쪽은 비교 우위 주장.

• Ternary Bonsai 2 27B — Qwen3.8-27B 기반의 독립형 2세대로, 이 모델보다 더 새로운 모델을 원하기로 결정한 독자를 위한 것입니다.

무엇이 아직 해결되지 않았나요?

이 페이지의 모든 품질 수치는 PrismML의 것이며, PrismML 자체의 15개 벤치마크 모음에서 측정된 것이고, 회사 외부의 누구도 이에 대한 재현을 발표하지 않았습니다. 이것이 Bonsai 27B에 대해 알려진 것에서 가장 큰 공백입니다: 압축 주장은 유난히 구체적이고 유난히 검증 가능하며, 제3자에 의해 검증되지 않은 상태로 남아 있습니다. 벤더는 또한 에이전트형 코딩 — 장기적이고 여러 파일에 걸친, 실행 후 수정 워크플로 — 이 이번 릴리스의 강한 목표가 아니며, 이를 위해 튜닝된 변형이 로드맵의 다음 항목이라고 명시하고 있는데, 이는 위의 범주별 분할에서 나타난 도구 호출 및 지시 따르기 손실과 일치합니다. 독립적인 평가가 존재하기 전까지는, 보존 수치와 밀도 순위 모두 확립된 결과라기보다는 벤더의 입장으로 읽어야 합니다.

확정된 사실은 더 작고 더 유용하다: 가중치는 존재하고, 크기는 파일 목록과 대조해 확인할 수 있으며, 라이선스는 Apache 2.0이고, 두 팩은 약 3.3GB 차이가 나는 대신 대략 5포인트의 품질 보존이 달라진다. 그것만으로 둘 중 하나를 고르기에 충분하다. 어느 쪽이 당신에게 맞는지는 당신의 워크로드가 산술에 더 가까운지 도구 호출에 더 가까운지에 달려 있으며, 위의 범주별 수치는 오늘 그 결정을 내리는 데 이용할 수 있는 최선의 증거다.