27B급 모델이 아이폰에서 돌아간다: Bonsai 27B, 3.9GB로 압축해 토큰 요금 없이 로컬에서

54GB짜리 모델을 3.9GB로 눌러 담고도 성능을 90~95% 지켰다면 믿을까. PrismML이 7월 14일 공개한 Bonsai 27B가 그 수치를 내걸었다. Qwen3.6 27B를 기반으로 파라미터 정밀도를 16비트에서 1비트까지 깎아낸 결과다. 아이폰 17 프로에서 초당 11토큰을 뽑는다.

한눈에 보기

공개일	2026년 7월 14일
1비트 압축 버전 용량	3.9GB (FP16 원본은 약 54GB)
벤치마크 성능 유지율	90~95%
컨텍스트 길이	262,000토큰
아이폰 17 프로 추론 속도	초당 11토큰
라이선스	Apache 2.0 (무료)

왜 27B가 마지노선이었나

지금까지 폰에서 돌아가는 로컬 모델은 대개 3B에서 8B급에 묶여 있었다. 요약이나 짧은 챗봇 응답 정도는 처리했지만 코드 리팩터링이나 여러 단계를 거치는 추론에는 힘이 부쳤다는 뜻이다. Bonsai 27B는 그 벽을 넘어 멀티스텝 추론과 구조화된 도구 호출까지 폰 안에서 처리한다고 밝혔다. 텍스트뿐 아니라 이미지도 함께 받는 멀티모달이라 문서 스캔이나 화면 캡처를 그대로 입력에 넣을 수 있다.

압축 기법은 단순 양자화가 아니다. 1비트 이진 버전과 1.58비트 삼진(ternary) 버전 두 갈래로 내놨고 하이브리드 어텐션 구조에 맞춘 저비트 커널을 따로 짰다. FP16 원본 54GB를 3.9GB까지 줄이는 건 압축률로 따지면 약 14분의 1이다. 보통 이 정도로 눌러 담으면 성능이 절반 밑으로 떨어지는 경우가 흔한데 PrismML이 밝힌 90~95% 유지율이 맞다면 압축 기법 자체가 이번 발표의 핵심이라 봐도 된다. 맥·아이폰·아이패드는 MLX로, NVIDIA GPU는 CUDA로 각각 최적화해 특정 하드웨어에 종속되지 않는 배포 전략도 같이 짰다.

기반 모델로 Qwen3.6 27B를 골랐다는 점도 눈여겨볼 대목이다. 자체 프리트레이닝 대신 이미 검증된 오픈 가중치 모델을 압축 대상으로 삼은 것인데 학습 비용을 줄이는 동시에 커뮤니티가 이미 튜닝해둔 성능을 그대로 물려받는 전략이다. 처음부터 모델을 새로 학습시키려면 수천만 달러 단위의 컴퓨팅 비용과 수개월의 시간이 든다. 검증된 모델을 가져와 압축 기술만 얹으면 그 비용과 시간을 크게 줄이면서도 27B급 성능은 그대로 가져올 수 있다. 훈련은 구글의 v5 TPU에서 이뤄졌다고 밝혔는데 정작 결과물은 구글 클라우드가 아니라 손안의 기기에서 도는 아이러니도 있다. 클라우드에서 학습시킨 지능을 클라우드 밖에서 공짜로 돌리는 흐름 자체가 이번 발표의 진짜 메시지에 가깝다.

토큰 요금이 사라진 자리

API 기반 모델을 쓰면 요청마다 비용이 붙는다. 262,000토큰짜리 컨텍스트를 매번 채워 넣는 작업, 예를 들어 긴 계약서를 반복해서 검토하거나 대용량 로그를 분석하는 작업이라면 청구서가 자릿수 단위로 뛴다. 하루에 이런 요청을 수백 건 처리하는 서비스라면 월 단위 API 비용이 금세 수백 달러를 넘긴다. Bonsai 27B는 한 번 내려받으면 그 이후 추론 비용이 전기요금 말고는 없다. 인디 메이커가 오프라인 문서 분석 도구를 만든다면 고객 데이터가 서버로 한 번도 안 나가는 구조를 3.9GB짜리 파일 하나로 짤 수 있다는 뜻이다.

물론 90~95%는 100%가 아니다. 벤치마크는 수학·코딩·추론·비전 영역을 평균한 수치라 특정 작업에서는 격차가 더 벌어질 수 있다. 법률·의료처럼 정확도가 생명인 영역에는 아직 클라우드 프론티어 모델을 붙이는 게 안전하다. 반대로 초안 작성, 1차 분류, 내부 검색처럼 사람이 최종 검수를 거치는 작업이라면 90%대 성능으로도 충분히 실전에 쓸 수 있다.

비용 구조를 숫자로 바꿔보면 체감이 다르다. 클라우드 API로 하루 500건씩 긴 문서를 처리하는 서비스를 운영한다고 하면 요청당 컨텍스트가 클수록 청구서는 기하급수로 불어난다. 같은 작업량을 로컬 모델로 옮기면 초기 다운로드 이후 추가 비용이 없으니 사용량이 늘어도 한계비용이 그대로 0에 머문다. 트래픽이 몰리는 성수기에 오히려 API 기반 경쟁자보다 원가 구조가 유리해지는 역전이 일어난다.

실제로 뭘 만들 수 있나

콘텐츠 크리에이터라면 촬영 현장에서 인터넷 없이 인터뷰 녹취를 요약하는 앱을 상상할 수 있다. 1인 회계 소프트웨어를 만드는 개발자라면 영수증 사진을 스캔해 항목을 분류하는 기능을 서버 비용 없이 앱에 내장할 수 있다. 프리랜서 법률 문서 검토 도구를 만드는 팀이라면 262,000토큰 컨텍스트로 계약서 전문을 한 번에 넣고 조항을 대조하는 작업까지 폰 위에서 끝낼 수 있다. 공통점은 셋 다 인터넷 연결이나 API 계약 없이 다운로드 한 번으로 기능이 완성된다는 점이다.

동네 공방이나 작은 매장을 운영하는 자영업자에게도 응용 지점이 있다. 와이파이가 불안정한 매장 안에서 재고 사진을 찍어 바로 분류하거나 손글씨 주문서를 텍스트로 옮기는 작업을 별도 서버 없이 태블릿 한 대로 처리할 수 있다. 클라우드 구독료를 감당하기 부담스러운 소규모 매장일수록 이런 일회성 다운로드형 도구의 매력이 크다.

일본과 동남아시아처럼 통신 인프라가 균일하지 않은 지역을 타깃으로 하는 AI 에이전시라면 이 지점이 더 크게 다가온다. 4G나 와이파이가 끊기는 현장에서도 작동해야 하는 서비스를 설계할 때 로컬 모델은 선택이 아니라 필수 조건이 된다. Bonsai 27B처럼 성능과 크기를 동시에 잡은 모델이 나올수록 "오프라인에서도 되는가"가 제품 스펙 문서의 첫 줄로 올라올 가능성이 크다.

anyAX 관점

1인 SaaS 개발자가 만드는 앱에 "AI 기능"을 넣는 순간 가장 먼저 부딪히는 질문은 성능이 아니라 데이터가 어디로 가느냐다. 병원 예약 앱이나 회계 자동화 툴을 만드는 팀이라면 고객 문서를 외부 API로 보내는 것 자체가 계약 위반이 되는 경우가 많다. 3.9GB짜리 모델을 앱에 내장하면 그 질문 자체가 사라진다. 데이터는 기기를 떠나지 않고 요금 청구서도 없다. 클라우드 API가 못 파고드는 자리, 즉 규제와 프라이버시가 걸린 니치를 1인 팀이 먼저 채울 수 있는 창이 열린 셈이다. 대형 SaaS 회사는 보안 인증과 법무 검토를 거치느라 이런 틈새 진입이 늦지만, 혼자 만드는 개발자는 다운로드 링크 하나로 오늘 당장 그 자리를 채울 수 있다.