Bonsai 2 27B: 6GB라는 숫자보다 먼저 볼 것

Bonsai 2 27B는 Qwen3.8-27B를 바탕으로 가중치 대부분을 −1, 0, +1로 표현해요. 128개 단위 그룹과 Hadamard 회전을 써서 비트를 줄이면서 정확도를 유지하려는 설계예요. 모델 전체는 27.36B 매개변수로 언어 백본 24.35B, 임베딩·출력 헤드 2.54B, 비전 타워 0.46B로 구성돼요.

가장 작은 PTQ1_0 언어 가중치는 5.95GB이고 공식 데모 기본 PQ2_0은 7.21GB예요. MLX 묶음은 0.92GB 비전 타워를 포함해 8.60GB이고, GGUF⁴ 비전 프로젝터는 약 0.63GB 별도 파일이에요. 이 용량은 각 파일 또는 묶음의 저장 크기이지 전체 런타임 메모리가 아니에요.

질문을 보내면 문맥을 유지하는 KV 캐시가 늘고, Apple Silicon은 모델 버퍼와 운영체제도 통합 메모리⁵를 함께 써요. 따라서 8GB 장비의 SSD⁶에 모델 파일이 들어간다는 사실만으로 안정적인 대화가 가능하다고 볼 수 없어요. 이미지 작업에는 언어 파일 외에 비전 구성요소와 이를 연결하는 런타임도 필요해요.

Bonsai 2는 선형층에 들어가기 전 활성값을 Hadamard 회전하는 연산을 사용해요. 실행 엔진이 이 변환과 압축 가중치를 함께 처리해야 정상 출력이 나와요. 따라서 이름에 Q2가 붙은 일반 GGUF 파일을 어느 Q2 로더에서나 열 수 있는 방식이 아니에요.

공식 데모 설치 스크립트는 이 지원을 포함한 패치 llama.cpp를 준비해요. 기본 llama.cpp는 파일을 거부하거나, 로딩은 되더라도 문장이 깨질 수 있어요. MLX도 일반 로더가 아니라 Bonsai 변환을 이해하는 전용 로더가 필요해요. 파일을 다시 받거나 GPU⁷를 바꾸기 전에 체크포인트⁸와 실행 엔진이 지원 조합인지 먼저 확인해요.

처음에는 짧은 텍스트 질문으로 답이 정상인지 확인하고, 그 다음 긴 문서나 이미지 입력을 추가해요. 텍스트부터 통과시키면 이후 실패가 메모리 문제인지 비전 구성이나 런타임 불일치인지 구분하기 쉬워요.

PrismML은 PQ2_0, batch 1 기준으로 128토큰⁹ 생성 속도와 512토큰 입력 처리 속도를 따로 공개했어요. 생성 tok/s는 첫 토큰이 나오기까지의 시간과 다르므로, 두 측정치를 함께 봐야 질문 제출부터 응답 완료까지의 지연을 가늠할 수 있어요.

이 표는 비전 타워를 제외한 제작사 측정이에요. 운영체제, 동시 요청, 실제 프롬프트¹⁰와 모델 구성에 따라 개인 환경 결과는 달라져요. 평소 쓰는 짧은 질문과 긴 문서를 따로 보내 첫 토큰 대기와 완료 시간을 구분해 확인해요. 4K 토큰 이상 입력에서는 체감 속도 표시가 범위를 넓혀 보여요.

PTQ1_0은 1.75 bits/weight, 5.95GB이고 PQ2_0은 2.13 bits/weight, 7.21GB예요. 파일 차이는 1.26GB지만 더 작은 파일이 항상 디코드¹¹도 빠르다는 뜻은 아니에요.

공개 장치 측정에서 PTQ1_0은 생성 속도가 비슷하거나 조금 빨랐지만, 프롬프트는 비교한 모든 장치에서 PQ2_0이 더 빠르게 처리했어요. 여유 메모리가 8GB를 넘는다면 PQ2_0부터 시작하고, 메모리가 빠듯하거나 파일을 더 줄여야 할 때 PTQ1_0을 같은 질문으로 비교해요.

PrismML은 사고형 14개 평가 평균으로 PQ2_0 Bonsai 2 84.78점, FP16¹² Qwen3.8-27B 86.32점을 공개하고 평균 점수 비율 98.2%를 주장해요. 이는 제작사 평가이지 모든 질문에서 98.2% 품질을 보장하지 않아요. 팀이 자주 하는 코드 리뷰·버그 수정이나 평소 길이의 문서를 같은 조건으로 비교하고, 답 정확성·누락·일관성·첫 토큰 대기·완료 시간을 기록해요.

공식 데모의 PQ2_0과 패치 런타임이 현재 컴퓨터에서 정상 작동하고 실제 입력에 충분한 답을 내면 그 구성을 계속 쓸 수 있어요. 메모리가 실제 병목일 때 PTQ1_0을 같은 질문 10개로 시험해 답변 품질과 공간 절약을 비교해요. 이미지 작업은 비전 프로젝터까지 포함해 따로 검증해야 해요.