27B 모델이 3.9GB로 축소, 스마트폰 온디바이스 추론 경쟁 가열
Original: Bonsai squeezes a 27B model into 3.9GB for phones View original →
27B 모델이 휴대폰으로 내려온 이유
27B급 언어 모델은 보통 서버 GPU, 메모리 대역폭, 배터리 걱정을 함께 부르는 규모다. RunAnywhere가 공개한 Bonsai 데모는 이 전제를 정면으로 건드린다. 회사는 X에서 “1-bit weights, 27B params in just 3.9GB, ~90% of full precision quality”라고 썼고, 이 모델군이 iPhone, Android, Mac에서 실행된다고 설명했다.
핵심은 1-bit 가중치와 기기별 런타임이다. 게시물에 따르면 iOS와 Mac에서는 llama.cpp와 Apple MLX를 거치고, Android에서는 llama.cpp와 Qualcomm Hexagon NPU용 자체 런타임 QHexRT를 쓴다. RunAnywhere는 1-bit 추론을 NPU에서 가능하게 하기 위해 커스텀 실리콘 커널을 만들었다고 주장했다. 수치만 보면 27B 파라미터 모델이 3.9GB에 들어가며, 회사 자체 평가 기준으로 전체 정밀도 품질의 약 90%를 유지한다.
RunAnywhere는 Y Combinator W26 배치로 소개되는 온디바이스 AI 스타트업이다. 이 계정은 주로 모바일과 데스크톱에서 로컬 모델을 실행하는 방법을 홍보해 왔고, 이번 글도 RunAnywhere 앱 배포와 연결된다. 다만 외부 벤치마크가 아니라 회사 자체 평가라는 점은 분명히 봐야 한다. 특히 1-bit 모델은 작업별 품질 저하가 크게 달라질 수 있어, 채팅 체감과 도구 호출, 장문 추론, 한국어·일본어 같은 다국어 성능을 따로 검증해야 한다.
다음 관전점은 세 가지다. Bonsai 27B가 공개 벤치마크에서 같은 크기의 2-bit·4-bit 모델과 얼마나 경쟁하는지, Qualcomm NPU 경로가 실제 Android 기기에서 얼마나 넓게 작동하는지, 그리고 앱스토어 배포 모델이 개발자에게 로컬 추론 API로 열릴지다. 원문 트윗은 여기에서 확인할 수 있다.
Related Articles
r/LocalLLaMA의 반응은 PrismML Bonsai 발표가 단순한 compression headline 이상으로 받아들여지고 있음을 보여 준다. 회사가 내세운 end-to-end 1-bit 설계와, 실제 사용자가 체감한 사용성 개선이 함께 이야기되고 있다.
Google의 새 on-device 최적화는 모델을 다시 학습하지 않고도 속도를 끌어올리는 방식이다. Pixel 9·10의 Gemini Nano v3에 frozen Multi-Token Prediction을 붙여 token 생성 50% 이상, standalone drafter 대비 130MB 절감을 제시했다.
HN의 논점은 “느리지만 된다”가 아니라 비용과 제어권이었다. 오래된 dual Xeon E5-2690 v2가 ik_llama.cpp 패치로 Gemma 4 26B-A4B를 CPU-only로 돌리며 local inference의 현실선을 다시 그었다.