Bonsai 27B
PrismML의 Qwen3.6-27B 기반 극한 양자화(1-bit / Ternary) 오픈 웨이트 모델
•
Hugging Face (GGUF): https://huggingface.co/prism-ml/Bonsai-27B-gguf
•
라이선스: Apache 2.0
•
출시: 2026년 7월 14일
한줄 요약
•
베이스: Alibaba Qwen3.6-27B (아키텍처 변경 없는 재양자화, 신규 프리트레인 아님)
•
Ternary(~5.9GB) / 1-bit(~3.9GB) 두 고정 빌드만 제공
•
폰(iPhone 17 Pro급)에서 27B급 모델을 돌린 첫 사례로 홍보
•
수학·코딩은 거의 유지, 툴콜·인스트럭션·비전은 비트 수에 따라 더 크게 떨어짐
Qwen과의 관계
•
Qwen3.6-27B의 하이브리드 어텐션(~75% linear / ~25% full) 백본을 그대로 사용
•
파라미터: 약 27.3B 언어 웨이트 + 약 0.46B 비전 타워
•
컨텍스트: 262K 토큰 (온디바이스에서도 하이브리드 어텐션 + 4-bit KV로 실용화)
•
비전 타워: HQQ 4-bit, 이미지 입력 시에만 로드(약 0.63GB mmproj)
양자화 스펙
변형 | 웨이트 스킴 | 유효 bits/weight | 배포 크기 | FP16 대비 유지율(공식) |
Ternary | {−1, 0, +1} + FP16 group scaling | 1.71 | ~5.9 GB | ~95% |
1-bit | {−1, +1} + group scaling | 1.125 | ~3.9 GB | ~90% |
•
임베딩·어텐션·MLP·LM head까지 저비트로 커버 (고비트 escape hatch 없음)
•
KV cache: near-lossless 4-bit 양자화
•
하이브리드 백본 덕분에 full-attention 캐시는 64층 중 16층만 성장 → 롱컨텍스트 메모리 부담 감소
•
백엔드: llama.cpp (CUDA/Metal/CPU), Apple MLX, NVIDIA 커스텀 low-bit 커널
•
speculative decoding(DSpark) 지원
성능 (Thinking Mode, 15-벤치 스위트)
카테고리 | Qwen3.6-27B | Ternary | 1-bit |
Math | 95.3 | 93.4 | 91.7 |
Coding | 88.7 | 86.0 | 81.9 |
Agentic / Tool-calling | 80.0 | 74.0 | 66.0 |
Instruction following | 78.4 | 71.8 | 65.8 |
Knowledge / STEM | 83.1 | 77.0 | 73.4 |
Vision | 72.6 | 65.2 | 59.6 |
Overall | 85.0 | 80.5 | 76.1 |
•
핵심 관찰: 툴콜 저하(80→66 at 1-bit)가 수학 저하보다 훨씬 큼
•
에이전트·툴 워크로드 → Ternary 권장
•
채팅·요약·가벼운 로컬 사용 → 1-bit도 가능
속도 / 하드웨어 감각
•
RTX 5090: 1-bit 최대 ~163 tok/s, Ternary ~134 tok/s
•
M5 Max: 1-bit ~87 tok/s, Ternary ~58 tok/s
•
iPhone 17 Pro: 약 11 tok/s (1-bit, 폰 메모리 예산 안에서 동작)
•
FP16 27B(~54GB) / 일반 4-bit(~18GB)는 폰·대부분 노트북에 비현실적 → Bonsai가 그 갭을 메움
어디에 쓰면 좋은가
•
프라이버시·오프라인 로컬 에이전트 (파일·화면이 디바이스에 남는 루프)
•
하이브리드 배포: 쉬운/민감 단계는 Bonsai, 어려운 단계는 클라우드 프론티어
•
Ternary = 노트북급 품질, 1-bit = 폰급 풋프린트
주의
•
표준 GGUF Q2_K~Q8 래더가 아니라 고정 2빌드 제품
•
벤치 수치는 PrismML 자체 스위트 중심 — 독립 리더보드 검증은 시점별로 확인 필요
Gemma 4 31B
Google DeepMind의 Gemma 4 시리즈 Dense 플래그십 오픈 웨이트 모델
•
기술 보고서: https://arxiv.org/abs/2607.02770
•
라이선스: Apache 2.0
•
출시: 2026년 4월 (이후 2026년 7월 웨이트/커널 업데이트)
한줄 요약
•
Dense 31B 파라미터, 네이티브 멀티모달(이미지·비디오) + Thinking Mode
•
Arena AI 텍스트 리더보드 오픈 모델 기준 상위권(#3 수준, 발표 시점)
•
Gemma 3 27B 대비 STEM·멀티모달·롱컨텍스트에서 전반적 성능 도약
•
bf16은 H100 80GB 단일 GPU에 적합, 양자화 버전은 소비자 GPU에서 로컬 추론 가능
Gemma 4 패밀리에서의 위치
•
E2B / E4B — 온디바이스·엣지용 Effective 파라미터 모델
•
26B MoE — 추론 시 약 3.8B 활성, 지연시간 중심
•
31B Dense — 품질·파인튜닝 기반용 플래그십
성능이 올라간 핵심 포인트
•
Gemma 3 27B와 크기가 가장 가까운 후속작으로, 벤치마크 전반에서 유의미한 향상
•
Thinking Mode: 응답 전 reasoning trace 생성으로 정확도 개선
•
에이전틱 워크플로: function calling, structured JSON, system instruction 네이티브 지원
•
컨텍스트: 대형 모델 최대 256K (엣지 모델은 128K)
•
140+ 언어 네이티브 학습
•
인간 평가(Arena Elo)에서 Dense 오픈 모델 카테고리 최상위권, 훨씬 큰 오픈 모델과 동급 수준으로 평가
2026년 7월 스텔스 업데이트 (버전 bump 없음)
•
Flash Attention 4(FA4) — NVIDIA Hopper(H100 등)에서 프롬프트 처리 처리량 +25~70%, TTFT 최대 −31%
•
툴콜링 버그 수정 및 일관성 개선
•
비전 처리 일관성 개선
•
에이전틱 벤치 예시 개선폭 (업데이트 전→후 게인)
◦
Tau2 Telecom: +10.1%p
◦
Tau2 Retail: +3.1%p
◦
Tau2 Airline: +2.0%p
◦
BFCL(Tools): +0.4%p
◦
TB2(Agents): +4.5%p
실행 / 배포
•
다운로드: Hugging Face, Kaggle, Ollama
•
런타임: Transformers, vLLM, llama.cpp, MLX, SGLang, NVIDIA NIM/NeMo 등 day-one 지원
•
실험: Google AI Studio (31B / 26B MoE)
•
양자화 QAT 버전으로 소비자 GPU·IDE·코딩 에이전트 로컬 구동 가능
어디에 쓰면 좋은가
•
로컬/온프레미스 코딩 어시스턴트·에이전트 파이프라인
•
파인튜닝 베이스 (품질 우선 Dense)
•
툴콜·멀티스텝 플래닝이 필요한 워크로드 (7월 업데이트 이후 특히)
참고
•
26B MoE는 속도, 31B Dense는 품질·튜닝용으로 역할이 갈림
•
엣지 자동화는 E4B, 품질 바운드 작업은 31B/12B 계열이 더 적합하다는 실무 가이드가 많음
Inkling (Thinking Machines Lab)
Mira Murati의 Thinking Machines Lab이 공개한 첫 오픈 웨이트 멀티모달 MoE
•
Hugging Face 블로그: https://huggingface.co/blog/thinkingmachines-inkling
•
라이선스: Apache 2.0
•
출시: 2026년 7월 15일
한줄 요약
•
총 975B / 활성 41B MoE, 컨텍스트 최대 1M 토큰
•
텍스트·이미지·오디오 네이티브 입력 → 텍스트 출력
•
45T 토큰(텍스트·이미지·오디오·비디오) 프리트레인
•
“최고 점수 모델”보다 파인튜닝·커스터마이즈용 균형형 제너럴리스트로 포지셔닝
아키텍처
•
Decoder-only transformer, 66층
•
Sparse MoE FFN: 토큰당 256 experts 중 6개 + shared expert 2개
•
Hybrid local/global attention
•
이미지: hierarchical patch encoder / 오디오: discrete token encoding → 공유 hidden space
•
Controllable thinking effort (약 0.2~0.99)로 추론 예산 조절
•
체크포인트: BF16, MXFP8, NVFP4 (+ speculative MTP 레이어)
파라미터 / 변형
모델 | Total | Active | 비고 |
Inkling | 975B | 41B | 메인 릴리스 |
Inkling-Small (preview) | 276B | 12B | 비용·지연 우선, 다수 벤치에서 큰 형제에 근접 |
성능 하이라이트 (effort=0.99, 모델 카드 기준)
•
SWE-Bench Verified: 77.6% (Nemotron 3 Ultra 70.7% 대비 우위)
•
Terminal Bench 2.1: 63.8%
•
AIME 2026: 97.1%
•
GPQA Diamond: 87.2%
•
IFBench: 79.8%
•
VoiceBench: 91.4%
•
MMMU Pro: 73.5%
•
전반적으로 오픈 웨이트 상위권이지만, Claude Fable / GPT 5.6 Sol 등 클로즈드 프론티어에는 못 미치는 구간이 많음
•
동일 성능에 Nemotron 3 Ultra 대비 약 1/3 토큰만 쓴다는 효율 주장
PC / 클러스터 자원 (공식 요구사항)
공식 체크포인트
포맷 | 최소 VRAM | 예시 구성 |
BF16 | ≥ 2 TB 집계 | 8× B300 또는 16× H200 |
NVFP4 | ≥ 600 GB 집계 | W4A4: 4× B300 (SM100+), W4A16: 8× H200 |
•
추론 프레임워크: SGLang, vLLM, TokenSpeed, Unsloth, Hugging Face Transformers
•
일반 소비자 PC(단일 4090/5090 등)로는 원본 BF16/NVFP4 직접 구동 비현실적
로컬·경량 경로
•
Unsloth 등 GGUF 양자화(1-bit까지): 합산 RAM+VRAM ~280GB대부터 시도 가능하다는 보고
•
서버리스 Inference Providers / Tinker API로 먼저 실험하는 편이 현실적
•
Tinker: 64K / 256K 컨텍스트 옵션, 출시 직후 할인 제공
배포 경로
•
웨이트: Hugging Face (thinkingmachines/Inkling, thinkingmachines/Inkling-NVFP4)
•
API/파인튜닝: Thinking Machines Tinker
•
Day-0: transformers, SGLang, llama.cpp, Unsloth 등
어디에 쓰면 좋은가
•
멀티모달(이미지·오디오 포함) 에이전트·코딩 어시스턴트 베이스
•
도메인 파인튜닝 / 합성 데이터 생성 (Inkling-Small도 후보)
•
검열·거부에 덜 민감한 오픈 웨이트 스택을 원할 때 (단, 다운스트림 가드 권장)
주의 / 한계
•
환각·롱멀티턴 저하·데이터 바이어스 등 일반 LLM 한계 존재
•
의료·법률·안전 크리티컬은 추가 검증·휴먼 오버사이트 필수
•
오픈 웨이트이므로 Llama Guard 등 앱 레이어 모더레이션을 defense-in-depth로 권장
MobileWan
Qualcomm AI Research의 모바일용 5B급 비디오 디퓨전 시스템 (Wan2.2 기반)
•
Hugging Face: https://huggingface.co/Qualcomm-AI-Research/mobilewan
•
개발: Qualcomm AI Research (Amsterdam Generative Vision)
한줄 요약
•
“모바일 = 작은 모델(0.4–1.8B)” 가정을 깨고, 서버급 5B Wan2.2를 상용 폰에 올림
•
5초 480×832 @ 16 FPS 영상을 종단 약 20초에 생성
•
VBench 83.79 — 모바일 비디오 생성 SOTA급
•
Snapdragon 8 Gen 계열 NPU 타깃
문제 의식
•
최근 비디오 디퓨전은 트랜스포머를 수십억 파라미터로 키우며 품질이 급상승
•
기존 모바일 모델은 메모리·이차 어텐션·디코더·지연 때문에 소형 백본에 머물러 품질 갭이 큼
•
MobileWan은 작게 만들기보다, 큰 모델을 recurrent 재구성 + 구조적 압축으로 올리는 전략
베이스 모델
•
Wan-AI / Wan2.2-TI2V-5B (텍스트→비디오 DiT)
•
DiT만 약 5B 파라미터
•
원본은 A100 80GB급 서버 GPU 가정 → MobileWan은 폰 NPU에서 네이티브 실행
핵심 기술
1. Recurrent distillation
•
비디오 생성을 chunk-wise autoregressive 프로세스로 변환
•
어텐션을 상수 메모리에 가깝게 유지
•
Causal linear attention과 결합 → 추론 시 RNN처럼 동작하면서 청크 간 시간적 일관성 유지
2. Learnable attention head pruning
•
헤드별 binary gate를 end-to-end 학습
•
Noise-biased sparsity objective + distillation finetuning
•
Heuristic pruning보다 공격적 압축에서도 품질 유지에 유리
3. Sampling-step distillation
•
디퓨전 스텝 수를 줄여 모바일 지연시간 예산 맞춤
4. Memory-optimized VAE decoding
•
디코더 피크 메모리·지연 최적화
•
(HF 체크포인트 기준) 최적화된 디코더는 미공개일 수 있어, 샘플링 코드가 원본 Wan2.2 디코더를 쓰는 경우 있음
생성 스펙 / 성능
항목 | 값 |
해상도 | 480 × 832 |
길이 | 5초 (81프레임 @ 16 FPS) |
종단 지연 | ~20초 |
VBench | 83.79 |
유저 스터디 | Neodragon 대비 MobileWan 선호 ~80% |
•
“모바일에서 5B급을 돌린 첫 사례”로 포지셔닝
•
서버급 Wan과 competitive한 품질을 목표로 품질 갭을 좁힘
한계 (논문 자체 기술)
•
중거리 인물 얼굴 등 일부 장면 품질이 약함
•
스텝 증류 방식에 따라 과포화·모션 감소 가능
•
RNN 재구성으로 간헐적 temporal discontinuity
•
스텝 증류 + 최적 디코더 조합에서 플리커 가능
관련 자료
•
모델·트레이닝 레시피 공개 예정/진행 (논문·HF·GitHub 확인)
•
인용 키: ghafoorian2026mobilewan (arXiv:2607.06173)
어디에 쓰면 좋은가
•
온디바이스 크리에이티브·데모 (클라우드 업로드 없이 짧은 생성)
•
모바일 NPU 최적화·디퓨전 압축 연구 베이스라인
•
Wan2.2 생태계를 엣지로 확장하는 레퍼런스 시스템
Wan-Streamer
Alibaba Wan Team의 실시간 풀듀플렉스 오디오·비주얼 대화용 네이티브 스트리밍 파운데이션 모델
•
v0.1 논문: https://arxiv.org/html/2606.25041
•
v0.3 논문 (World + Event Stream): https://arxiv.org/abs/2607.15038
한줄 요약
•
언어·오디오·비디오를 입출력 모두 하나의 Transformer로 모델링
•
별도 VAD/ASR/LLM/TTS/아바타/비디오생성 파이프라인에 의존하지 않음
•
모델측 응답 지연 ~200ms, 네트워크 350ms 가정 시 총 상호작용 ~550ms
•
v0.2/v0.3 운영점: 640×368 @ 25 FPS, 스트리밍 유닛 160ms
왜 나왔는가
•
기존 시스템은 “이해 모델 + 생성 모델”을 캐스케이드로 붙여 모듈 경계에서 대기·오류 누적
•
실시간 대화는 풀듀플렉스: 사용자가 말할 때도 경청 동작, 에이전트가 말할 때도 인터럽트 인지 필요
•
Streamability를 서빙 최적화가 아니라 모델링 제약으로 설계
버전 흐름
버전 | 핵심 |
v0.1 | Native-streaming end-to-end 상호작용 베이스라인 확립 |
v0.2 | 출력 해상도 192×336 → 640×368, 지연은 유지 |
v0.3 | 개념 재구성: Video = World + Event Stream, 운영점은 v0.2 유지 |
아키텍처 요지
•
단일 causal Transformer + block-causal attention
•
시퀀스: interleaved visual/audio/text 입력 토큰 + visual/audio/text 출력 토큰
•
Strictly causal audio/video VAE, causal encoder/decoder
•
언어: next-token CE / 오디오·비디오: conditional flow matching (연속 latent)
•
생성 유닛 latent는 history에 commit되어 다음 유닛의 컨텍스트가 됨
추론 시스템: Thinker–Performer
•
학습은 end-to-end 단일 모델, 배포는 thinker / performer로 분리해 오버랩 극대화
•
Thinker: causal AV 인코더, 짧은 token-causal Transformer(언어·상태), KV, causal 디코더
•
Performer: latent generation(flow-matching) 경로 전담
•
KV-cache 교환으로 통일된 causal state 유지
•
CUDA graph·컴파일·커널 최적화와 함께 ~200ms model-side latency
v0.3 관점: World + Event Stream
•
World: 환경·장면·주체·앰비언트 음향·보이스 특성 등 상대적으로 안정적인 맥락
•
Event stream: 장면 변화·행동·발화·기타 소리 등 시간에 따라 변하는 것
•
프리트레인 과제: world + 들어오는 입력 → 세계가 실시간으로 어떻게 움직이고 반응하는지 예측
•
다운스트림: 풀듀플렉스 AV 상호작용에서 event stream = 에이전트 발화 + free-form behavior
•
이해를 VLA-like로 해석: 멀티모달 입력 → 언어 형태의 speech/behavior action → 동기화 AV 출력
학습 단계 (v0.1 기준)
1.
Independent-task pretraining — 이해·생성 태스크 혼합, LM 초기화(Qwen 계열)
2.
End-to-end interaction training — duplex 데이터로 타이밍·경청·인터럽트·롱컨텍스트 학습
3.
Distillation — CFG·스텝 많은 teacher → 저지연 student, rolling/self-forcing로 장기 품질 유지
운영 스펙 (v0.2 / v0.3)
항목 | 값 |
비디오 | 640 × 368, 25 FPS |
Streaming unit | 160 ms |
Model-side latency | ~200 ms |
Total interaction latency | ~550 ms (양방향 네트워크 350 ms 가정) |
v0.2 해상도 업 | Performer를 multi-GPU Ulysses-style context-parallel로 확장해 latency-critical thinker 경로 유지 |
어디에 쓰면 좋은가
•
실시간 디지털 휴먼 / 라이브 방송 상호작용
•
Embodied assistant, 인터랙티브 엔터테인먼트
•
월드모델·온라인 제어가 필요한 풀듀플렉스 AV 에이전트 연구
캐스케이드 대비 이점
•
파이프라인 경계 대기 제거
•
인식·동기화 오류 누적 감소
•
응답 타이밍·턴 관리·교차모달 동기화를 하나의 행동으로 공동 학습
안녕하세요
•
관련 기술 문의와 R&D 공동 연구 사업 관련 문의는 “glory@keti.re.kr”로 연락 부탁드립니다.
Hello
•
For technical and business inquiries, please contact me at “glory@keti.re.kr”
