아이폰에 350억 파라미터 모델을 담아본 이야기

35B 모델이 GPU 없는 PC와 폰에서 도는 이유 — 온디바이스 추론은 왜 메모리 대역폭 문제인가

POCKET을 Bonsai와 같은 기계, 같은 표준 도구로 측정한 기록, 그리고 "더 큰 모델이 더 빠르다"는 역설을 뜯어봅니다.

온디바이스 LLM을 논할 때 우리는 흔히 파라미터 수를 크기의 지표로 씁니다. 그런데 GPU가 없는 기기에서 토큰을 생성하는 속도를 좌우하는 것은 연산량(FLOPs)이 아니라 메모리 대역폭입니다. 디코딩 단계에서는 토큰 하나를 만들 때마다 모델 가중치를 메모리에서 다시 읽어야 하고, 배치 병렬성이 거의 없는 단일 사용자 환경에서는 이 읽기 비용이 지배적입니다.

이 글은 한국의 딥테크 스타트업 비드래프트가 공개한 온디바이스 모델 POCKET을, 같은 분야에서 자주 인용되는 Bonsai(27B급, 패밀리 누적 200만+ 다운로드)와 동일 조건에서 측정한 결과를 다룹니다. 핵심 질문은 하나입니다 — 어떻게 35B 모델이 27B 모델보다 빠를 수 있는가.

1. 역설 — 더 큰 모델이 더 빠르다

POCKET은 35B, Bonsai는 27B로 소개됩니다. 총 파라미터로는 POCKET이 더 큽니다. 그런데 실제 생성 속도에서는 POCKET이 대부분의 환경에서 더 빠릅니다. 표를 먼저 보겠습니다. 모두 동일 하드웨어에서 stock llama.cpp로 측정한 값이며, 비교 대상은 POCKET-35B의 IQ1_M 양자화와 Bonsai-27B의 Q1_0입니다.

측정 항목 POCKET-35B Bonsai-27B 비율
CPU 생성 (Xeon, 16 threads)27.0 tok/s10.12.69×
GPU 생성 (H100)197 tok/s892.22×
Apple Metal 생성 (MacBook M3 Pro, 18GB)25.4 tok/s12.81.99×
노트북 CPU 생성 (8 threads)13.8 tok/s4.43.13×

생성 속도만 보면 POCKET이 CPU·GPU·애플 실리콘 전 축에서 앞섭니다. 그런데 여기서 멈추면 반쪽짜리입니다. 품질과, POCKET이 지는 항목까지 봐야 이 숫자들이 의미를 갖습니다.

2. 품질은 동급, 그리고 지는 항목의 공개

항목 POCKET Bonsai 판정
HellaSwag (400문항)61.0%60.0%동급 — 신뢰구간 겹침
프리필 / 프롬프트 처리 (H100)753 tok/s18160.41× — Bonsai 우위

품질은 우열을 가릴 수 없습니다. HellaSwag 61.0 대 60.0은 신뢰구간이 겹치므로 "동급"으로만 읽어야 하며, 어느 쪽도 품질 우위를 주장할 수치가 아닙니다.

그리고 마지막 행 — 서버 GPU(H100)에서 긴 프롬프트를 한꺼번에 처리하는 프리필 속도는 Bonsai가 약 2.4배 빠릅니다. 이 항목을 표에서 빼지 않고 그대로 둔 것이 오히려 나머지 수치의 신뢰를 만듭니다. 벤치마크에서 이기는 항목만 고르는 것은 흔한 관행이고, 지는 항목을 함께 공개하면 "유리한 조건만 골랐다"는 의심이 사라지기 때문입니다.

3. 왜 더 큰 모델이 더 빠른가 — 희소 MoE와 메모리 대역폭

답은 아키텍처에 있습니다. POCKET은 희소 전문가 혼합(sparse Mixture-of-Experts) 모델입니다. Bonsai가 한 명의 만능 네트워크가 모든 토큰을 처리하는 밀집(dense) 구조라면, POCKET은 다수의 전문가를 두고 토큰마다 그중 일부만 활성화합니다.

여기서 두 가지 파라미터를 구분해야 합니다. 총 파라미터는 모델 전체 크기이고, 활성 파라미터는 토큰 하나를 만들 때 실제로 계산에 참여하는 부분입니다. 밀집 27B는 매 토큰마다 27B를 전부 읽습니다. 희소 MoE는 총량이 35B라도 토큰당 읽는 가중치는 그 일부입니다.

디코딩이 메모리 대역폭에 묶여 있다는 사실을 여기 대입하면 결론이 나옵니다. 토큰당 메모리 트래픽이 곧 속도를 결정하는데, 희소 MoE는 그 트래픽이 밀집 모델보다 작습니다. 총 크기는 크지만 매 순간 실제로 읽는 양은 적기 때문에, 더 큰 모델이 더 빠른 현상이 성립합니다. 이 효과는 GPU가 없는 환경에서 특히 커집니다. 강력한 병렬 연산 자원이 없을수록 병목이 순수하게 메모리 읽기로 수렴하기 때문입니다.

4. 프리필 역전의 정체 — 연산 병목 대 대역폭 병목

그렇다면 왜 H100 프리필에서는 Bonsai가 이길까요. 이 지점이 이 비교에서 가장 흥미로운 대목입니다.

디코딩(생성)은 토큰을 하나씩 자기회귀로 만들기 때문에 배치 병렬성이 낮고, 병목이 메모리 대역폭입니다. 반면 프리필(프롬프트 처리)은 입력 토큰 전체를 한꺼번에 통과시키므로 병렬성이 높고, 병목이 연산량(FLOPs)으로 이동합니다.

프리필은 연산 병목이고, 디코딩은 대역폭 병목입니다. 희소 MoE의 이점은 대역폭 병목 구간에서 나옵니다.

H100처럼 연산 처리량이 압도적인 하드웨어에서는, 프리필의 연산 병목 구간에서 밀집 모델이 자신의 전체 가중치를 한 번에 다 활용해 오히려 앞설 수 있습니다. 즉 Bonsai가 H100 프리필에서 이기는 것은 연산 여유가 넘치는 서버 GPU라는 특수 조건 때문입니다.

그런데 온디바이스 타깃 — 노트북, 미니PC, 폰 — 에는 그 연산 여유가 없습니다. 병목이 프리필에서도 대역폭으로 되돌아오고, 그러면 희소성 이점이 프리필까지 확장됩니다. 실제 MacBook M3 Pro 측정에서 POCKET은 프롬프트 처리마저 앞섭니다.

프리필 (pp128) POCKET Bonsai 비율
Apple Metal240.7 tok/s73.43.28×
CPU45.5 tok/s9.64.75×

정리하면, Bonsai가 유일하게 앞서는 프리필 우위는 온디바이스 사용자가 쓰지 않는 하드웨어(서버 H100)에서만 성립합니다. 실제 배포 대상 기기에서는 생성과 프리필 양쪽 모두 POCKET이 앞섭니다.

5. 배포성 — 표준 도구에서 그대로 돈다

온디바이스 모델은 성능이 좋아도 설치 마찰이 크면 확산되지 못합니다. 전용 런타임을 직접 빌드하거나 별도 포크를 깔아야 한다면 그만큼 진입 장벽이 생깁니다.

구체적 대비가 있습니다. 동급 크기의 경쟁 모델 Ternary-Bonsai-27B-Q2_0(7.2GB)는 upstream llama.cpp에서 로드되지 않고 PrismML 포크가 필요합니다. 반면 POCKET은 stock llama.cpp에서 그대로 로드됩니다. 곧 LM Studio, Ollama 등 표준 생태계가 공개 첫날부터 동작한다는 뜻입니다. 애플 실리콘용으로는 iPhone·Mac을 겨냥한 네이티브 MLX 빌드가 별도로 제공됩니다.

양자화는 전용 포맷이 아니라 stock llama.cpp의 표준 GGUF 방식(Q4_K_MIQ1_M)을 씁니다. 속도는 희소 MoE 구조와 평범한 양자화의 조합에서 나오며, 같은 도구로 누구나 재현할 수 있습니다.

6. 양자화 메뉴

빌드 크기 대상
IQ1_M8.2 GB16GB RAM 미니PC — 최소 크기 풀 모델
Q2_K13 GB미니PC 상시 사용 (GPU 없음)
Q3_K_M16.8 GB품질 우선
Q4_K_M21.2 GB기준선 (한국어 Wikipedia PPL 5.79)

언어별·기기별로 나뉜 패밀리로 공개되어 있습니다 — PC·서버용 GGUF, 한국어 GGUF, 영어 GGUF, 애플 실리콘용 MLX, 그리고 GPU 없이 답하는 CPU 데모까지. 단일 모델이 아니라 실사용 환경별 온디바이스 모델 패밀리에 가깝습니다.

7. 솔직한 한계

  • 서버 GPU(H100) 프리필은 Bonsai가 앞섭니다(0.41×). 온디바이스 타깃에서는 역전되지만, 이 항목 자체는 사실대로 둡니다.
  • 품질은 HellaSwag 기준 동급이며, 어느 쪽도 우위를 주장할 수 없습니다. 단일 벤치 하나로 품질 전반을 일반화해서도 안 됩니다.
  • iPhone에서의 실측치는 아직 자체적으로 확보하지 않았습니다(커뮤니티 리포트 환영). 위 Metal 수치는 MacBook M3 Pro 측정값입니다.
  • 체감 성능은 RAM, 저장장치, 실행 도구, 양자화 레벨, 발열 상태에 따라 달라집니다.

중요한 것은 이 차이들을 표에서 숨기지 않았다는 점입니다. "모든 항목에서 이겼다"가 아니라 "같은 조건에서 재보니 이런 결과가 나왔다"는 방식이며, 그것이 기술 비교의 설득력을 만듭니다.


📦 POCKET 모델 컬렉션

https://huggingface.co/collections/FINAL-Bench/pocket-models-6a618ee5d23eafb7e185a5c6

🤗 POCKET-35B-GGUF (PC·서버, GPU 불필요)

https://huggingface.co/FINAL-Bench/POCKET-35B-GGUF

🖥️ CPU 라이브 데모 (GPU 없이 답변)

https://huggingface.co/spaces/FINAL-Bench/POCKET-35B-CPU

이 글은 공개된 모델 카드와 저장소 파일을 직접 확인해 정리했습니다. 모든 수치는 모델 카드에 보고된 측정값을 그대로 옮겼으며, 해석과 병목 분석은 글쓴이의 것입니다. POCKET은 비드래프트(VIDRAFT)가 Apache-2.0으로 공개한 온디바이스 모델 패밀리입니다. → https://vidraft.net

1개의 좋아요

직접하신건가요?

네. 직접 한거에요

1개의 좋아요