아래의 Upstream Status 섹션은 https://github.com/PrismML-Eng/Bonsai-demo 에서 가져왔습니다.

Upstream Status
Binary Q1_0에 대한 지원은 많은 백엔드(CPU (generic, NEON, 및 최적화된 x86), Metal, CUDA, Vulkan)에 걸쳐 upstream llama.cpp에서 즉시 사용 가능합니다.

Runtime Status
llama.cpp (CPU, Metal, CUDA, Vulkan) ✅ upstream에 병합되었으며, 즉시 사용 가능
MLX (1-bit) ⏳ upstream 병합 대기 중: mlx#3161 ; 병합될 때까지 PrismML-Eng/mlx를 사용하세요 (prism 브랜치, setup.sh에 의해 자동 빌드됨)

Ternary에 대한 Upstream Status
Ternary 지원은 현재 llama.cpp 메인라인으로 마이그레이션되는 과정 중에 있습니다: 백엔드들이 하나씩 반영되고 있으므로, 현재는 메인라인과 당사의 fork가 혼합된 상태입니다. 실질적인 결과는 다음과 같습니다: 현재 세 가지 ternary GGUF 변형을 제공하며, 각 변형은 적절한 환경에서 실행되어야 합니다.

백엔드별 마이그레이션 상태:

위의 Vulkan PR은 승인되었으며✅ 곧/오늘 업무 종료 전까지 병합되기를 기다리고 있습니다.

llama.cpp에서 병합될 예정인 다른 오픈 PR(Bonsai 관련):

• cuda: extract Q1_0 elements via __byte_perm #25628 ( t/s +5-10% & pp +1-2.5% )
• ggml-cpu: ARM Repack kernels for Q1_0 #23492 (내부 t/s 벤치마크 확인 필요)
• ggml-cpu: Optimized Arm NEON cpu q1_0 dot (with plain/DP/I8MM) #23358 (내부 t/s 벤치마크 확인 필요)

Bonsai 및 Ternary-Bonsai 모델의 최적화에 관한 더 많은 PR이 나오기를 기대합니다. 어제 (다른 Bonsai 스레드에서) 몇몇 분들이 이 모델들이 에이전트 코딩 (Agentic coding)과 같은 작업을 잘 수행하지 못한다고 언급하는 것을 보았습니다. 제 생각에 이는 1-bit 버전 모델에 대한 기대치가 너무 높은 것 같습니다. 하지만 모델 제작자들은 모델 카드(model cards)에 관련 노트를 명시했습니다. 아래에 공유합니다.

Bonsai-27B 한계점 (Limitations)

• 품질-용량 트레이드오프 (The quality–footprint trade-off): 이 이진 (binary) 모델은 전체 정밀도 (full-precision) 평균의 89.5%를 유지하며, 그 격차는 완만하고 예측 가능합니다. 추론 핵심 영역(수학, 코딩)은 베이스라인과 몇 포인트 차이 이내를 유지하며, 차이는 가장 까다로운 카테고리에 집중되어 있습니다. 만약 품질이 우선순위라면, ternary GGUF 빌드(94.6%)를 고려하십시오.
• 에이전트 코딩 (Agentic coding, 장기적 관점, 다중 파일, 실행-테스트-수정 워크플로)은 아직 이번 릴리스의 강력한 타겟이 아닙니다. 에이전트 코딩에 맞춰 튜닝된 Bonsai 27B 변형 모델이 로드맵의 다음 단계에 있습니다.
• KV 압축 여유 공간 (KV compression headroom): 이번 릴리스는 4-bit KV 캐시 (KV cache)를 표준으로 합니다. KV 캐시 오류에 대한 Bonsai의 허용치는 컨텍스트 길이 (context length)에 따라 증가하며, 초기 결과에 따르면 키 캐시 (key cache)를 2-bit 미만 영역까지 밀어붙일 수 있음을 보여줍니다. 이는 고정된 장치 메모리 예산 내에서 더 긴 컨텍스트를 확보할 수 있는 경로입니다.

Ternary-Bonsai-27B 한계점 (Limitations)

• 품질-용량 트레이드오프 (The quality–footprint trade-off): ternary 모델은 전체 정밀도 (full-precision) 평균의 94.6%를 유지하며, 그 격차는 완만하고 예측 가능합니다. 추론 핵심 영역(수학, 코딩)은 베이스라인과 몇 포인트 차이 이내를 유지하며, 차이는 가장 까다로운 카테고리에 집중되어 있습니다.
• 휴대폰에 적합하지 않음: 약 7.2 GB인 ternary 빌드는 iOS의 앱당 메모리 예산인 약 6 GB를 초과합니다. 휴대폰 배포를 위해서는 MLX Swift를 통해 1-bit 컴패니언을 사용하십시오.
• 현재 2-bit 슬롯에서 제공됨:

배포된 푸트프린트 (deployed footprint, ~7.2 GB)는 표현 방식의 네이티브 타겟인 ~5.9 GB를 초과합니다. 네이티브 ternary 커널 (native ternary kernels)은 현재 활발히 진행 중인 엔지니어링 목표이며, 이를 통해 남은 대역폭과 푸트프린트 이점을 지연 시간(latency) 및 에너지 효율 개선으로 직접 환원할 수 있을 것입니다. 에이전틱 코딩 (Agentic coding, 장기적 관점, 다중 파일, 실행-테스트-수정 워크플로우)은 이번 릴리스의 주요 목표가 아닙니다. 에이전틱 코딩에 최적화된 Bonsai 27B 변형 모델이 다음 로드맵에 예정되어 있습니다. KV 압축 여유 공간 (KV compression headroom): 이번 릴리스는 4-bit KV 캐시 (KV cache)를 표준으로 합니다. 초기 결과에 따르면 키 캐시 (key cache)를 2-bit 미만 영역까지 밀어붙일 수 있으며, 이는 고정된 장치 메모리 예산 내에서 더 긴 컨텍스트 (context)를 확보할 수 있는 경로입니다. 다음부터는 (위의 제한 사항이 없는) 최상의 극도로 최적화된 모델을 그들로부터 받을 수 있기를 바랍니다. 저는 방금 아무런 파라미터 없이 Bonsai-27B를 llama-bench로 테스트했습니다. 제 노트북 GPU 4060 (8GB VRAM)에서 pp - 600 t/s 및 tg - 30 t/s를 기록했습니다. 이 모델에 엄청난 기적을 기대하지는 않지만, 제 작은 VRAM에서 실행할 수 있게 되어 기쁩니다. 채팅과 글쓰기에 이 모델을 사용할 예정입니다. 최고의 성능을 내기 위해 Bonsai 팀과 llama.cpp 개발자들의 후속 최적화를 기다리고 있습니다. 여러분은 몇 t/s가 나오나요? 코딩, 글쓰기 및 기타 용도로 사용해 보신 분 계신가요? 또한 휴대폰에서 실행해 보신 분 계신가요? 제 8GB RAM 휴대폰에는 로드할 수 없는데, 너무 느릴 것 같아서요. 이 모델의 성능에 대한 피드백을 공유해 주세요. /u/pmttyji 제출 [링크] [댓글]