MiniCPM-V 4.7, 35B 비전 모델을 3GB에 담다: 100 tok/s 주장을 파헤치다

350억 개 파라미터 모델은 3기가바이트에 담을 수 없다. 그런데도 MiniCPM-V 4.7 35B-A3B는 약 3기가바이트에서 동작하며, 두 진술 모두 사실이다. 바로 이것이 이 모델의 핵심 묘기이며, 이번 릴리스에 대해 떠도는 숫자들을 곰곰이 따져볼 만한 이유이기도 하다. 이 모델은 OpenBMB가 MiniCPM-V 계열에서 처음 선보인 희소 전문가 혼합(MoE) 모델이다. 저장된 파라미터는 352억 개, 토큰당 활성 파라미터는 약 30억 개이며, Apache-2.0 라이선스로 가중치가 Hugging Face에 공개되어 있다. 이미지, 다중 이미지 세트, 영상을 읽고 텍스트로 답한다. 10월 10일부터는 업스트림 llama.cpp에서도 동작하며, 대부분의 사람들이 바로 이 경로로 이 모델을 접했다. 이하에서는 모두가 되풀이하는 세 가지 숫자, 즉 3GB, 35B, 100 tok/s를 각각 분리해 살펴보고, 그중 무엇을 OpenBMB가 실제로 발표했는지 보여준다. 200개 이상의 호스팅 모델, 하나의 키, 제공업체 정가를 0% 마크업으로 그대로 전달합니다. OrcaRouter가 라우팅하는 대상 확인하기 오픈 가중치 체크포인트는 사용자의 하드웨어에 그대로 두고, 호스팅 대안은 엔드포인트 하나로 해결합니다. 이와 같은 릴리스의 배경이 된, 기록으로 남은 AI 실패 사례와 에이전트 사고들은 다음에 모여 있습니다. OrcaRouter AI 사고 아카이브 각 항목에는 출처, 심각도, 신뢰도 등급, 이견 표시가 함께 제공됩니다.

3기가바이트, 350억 개의 매개변수, 그리고 모순 없음

산술이 불가능해 보이는 것은 "메모리 내"가 "전부"를 뜻한다고 가정할 때뿐입니다. MiniCPM-V 4.7 35B-A3B는 약 30억 개 파라미터를 상주시키고, 라우터가 요청할 때 나머지 전문가들을 스트리밍으로 불러옵니다. 모델 카드 자체의 표현은 Lookahead Expert Scheduling으로, 다음 레이어가 필요로 할 가능성이 높은 전문가를 미리 가져오는 교차 레이어 라우팅 예측기이며, 해당 로드가 이미 진행 중인 연산과 겹쳐지도록 합니다. 모델 카드는 예측이 사전 가져오기와 스케줄링만 구동한다고 명확히 밝힙니다. 토큰은 여전히 모델의 실제 라우팅을 따르며, 예측기가 놓친 전문가는 다른 전문가와 똑같이 로드되고 평가됩니다.

그 구분은 측정 가능한 결과를 낳는다. GGUF 저장소는 모든 일반적인 양자화 버전으로 전체 모델을 공개하며, 그 파일 중 어느 것도 3기가바이트가 아니다:

• Q4_K_M — 디스크에서 21.2 GB.

• Q8_0 — 36.9GB.

• F16 — 69.4 GB.

• 비전 프로젝터 — 4배 압축 시 0.9GB, f16 시 1.1GB.

따라서 "3 GB"는 휴대폰에서 expert streaming을 사용할 때의 상주 메모리 수치이며, 다운로드 크기도 아니고 데스크톱용 VRAM 요구 사항도 아닙니다. 배포를 계획 중이라면 디스크와 최초 로드에 영향을 주는 수치는 Q4_K_M 기준 21.2 GB이고, 휴대폰에서 안정 상태의 메모리 사용량을 좌우하는 수치는 공급업체가 제시한 ~3 GB입니다. 둘 다 릴리스에 포함되어 있습니다. 둘은 서로 다른 질문에 답하며, 대부분의 보도는 이 둘을 하나로 뭉뚱그렸습니다.

100 tok/s가 어디서 나오고, 어디서 나오지 않는가

여기서는 솔직하게 짚고 넘어갈 부분이 있다. OpenBMB는 MiniCPM-V 4.7에 대해 100 tok/s라는 수치를 공개하지 않는다. 모델 카드에 적힌 숫자는 iPhone 17 Pro Max에서 약 3GB 메모리로 13+ tokens/s다. 이는 이번 릴리스가 내세우는 유일한 온디바이스 처리량 주장이며, 연구소 밖에서는 아무도 재현하지 못한 하드웨어에서 벤더가 측정한 값이다.

더 높은 수치도 존재하며, 그것들은 다른 아티팩트에서 나옵니다. 온디바이스 최적화를 담고 있는 저장소인 OpenBMB의 llama.cpp-omni 포크는 35B-A3B 대상에 대해 자체 표를 공개하는데, 이 표는 어떤 최적화가 켜져 있는지에 따라 구성됩니다:

• iPhone 18 Pro Max, 12 GB — 기준 3.38 tok/s, Lookahead Expert Scheduling 적용 시 11.34, 혼합 정밀도 추가 시 17.16, DSpark 드래프트 헤드까지 더하면 20.51.

• iPad Pro 11인치 M4, 16GB — 기준 2.97 tok/s, LES 적용 시 9.81, 혼합 정밀도 적용 시 14.92, DSpark 적용 시 17.39.

그것들은 이 모델에 대해 공개된 온디바이스 수치 중 가장 높은 것들이며, 그 사다리의 꼭대기는 20.51 tok/s입니다 — 100의 5분의 1입니다. 이 격차는 중요합니다. 모델의 용도가 달라지기 때문입니다. 13 tok/s에서는 휴대폰 앱이 사진에 관한 질문에 몇 초 만에 답합니다. 100 tok/s라면 비디오용 스트리밍 1차 판독기로 고려하게 될 것입니다. 첫 번째는 실제 제품입니다. 두 번째는 출시된 것이 아니며, 트윗의 수치를 기준으로 예산을 잡는 사람은 다섯 배 차이에 실망하게 될 것입니다.

100 tok/s라는 주장을 정직하게 해석하면, 그것은 세 가지 별개의 사실 — 3 GB, 로컬에서 실행, 지난 세대보다 훨씬 빠름 — 을 어느 출처에도 없는 하나의 숫자로 압축한 것이다. 세대 대비 개선은 실제로 크다: 3.38에서 20.51 tok/s로의 변화는 같은 등급의 기기에서 6배 향상이며, 더 큰 칩이 아니라 세 가지 기법을 쌓아 달성한 것이다.

출시는 하루 만에 끝난 것이 아니었고, 날짜가 중요합니다

MiniCPM-V 4.7은 요즘 많은 오픈 웨이트 공개가 그러하듯 등장했습니다. 파일이 먼저, 설명은 나중에, 프레임워크 지원은 그 중간 어딘가에 있었죠.

• 10월 6일 17:40 UTC — 1B 모델과 AWQ, GPTQ, int4 변형이 Hugging Face에 등장하며, GGUF 빌드는 18:05에 공개됩니다.

• 10월 7일 07:07 UTC — 35B-A3B 저장소가 공개되었습니다. 아직 모델 카드는 없습니다.

• 10월 8일 — 두 크기 모두를 위한 DSpark 추측 디코딩 헤드, 그리고 35B의 FP8 빌드.

• 10월 10일, 18:42 UTC — llama.cpp가 모델 지원을 병합했습니다.

• 10월 12일 — OpenBMB가 모델 카드를 커밋하고 Apache-2.0을 선언하며, 문서화된 제품으로서의 릴리스를 발표한다.

• 10월 15일 — DSpark 헤드는 메인 카드에서 링크되어 있으며, 두 대상 모두에 대한 GGUF 드래프트가 함께 제공됩니다.

그 순서는 2차 보도에서 나타난 많은 혼란을 잘 설명해 준다. 10월 둘째 주에 llama.cpp를 통해 이 모델을 접한 사람은 공식적으로는 아직 존재하지도 않았던 릴리스를 실행하고 있었던 것이다. 라이선스 태그도, 벤치마크 차트도 없이 말이다. 그리고 그들의 처리량 수치는 OpenBMB가 벤치마킹한 어떤 것이라기보다는 해당 프레임워크 자체의 양자화 선택을 반영한 것이었다.

llama.cpp 지원: 병합되었지만, 아직 완전히 끝나지 않았습니다

MiniCPM-V 4.7을 추가한 업스트림 풀 리퀘스트는 무엇이 바뀌었는지에 대해 유난히 알기 쉽게 설명하며, 그 답은 아키텍처적으로 거의 아무것도 바뀌지 않았다는 것이다. 이 모델은 MiniCPM-V 4.6과 거의 동일하다. 차이는 3D RoPE, 즉 대부분의 비전-언어 모델이 사용하는 단일 스칼라 대신 토큰당 세 가지 값(시간, 행, 열)으로 된 위치다. 지원은 기존 4.6 경로를 확장해 그 추가 차원을 전달한다. 이 PR은 9월 25일에 열렸을 때 모델을 "출시 예정"으로 표시하기도 했는데, 이는 가중치가 얼마나 일찍 유통되고 있었는지에 대한 적절한 힌트다.

이 잔여 문제는 그 위에 그라운딩 기능을 구축하기 전에 알아둘 가치가 있습니다. 그 병합 이후, 업스트림 llama.cpp는 MiniCPM-V 4.7 프롬프트에서 이미지 마커 토큰에 잘못된 위치를 할당합니다. 이미지 토큰 자체는 올바르게 배치되지만, <slice>, </slice> 및 행 끝 마커는 참조 get_rope_index 구현이 수행하는 것처럼 타일 모서리 좌표를 부여받는 대신 일반 텍스트처럼 번호가 매겨집니다. 눈에 보이는 증상은 사진에서 무언가가 어디에 있는지 물을 때 반환된 좌표가 체계적으로 낮게 나온다는 것입니다. 단위 테스트가 포함된 수정 사항이 10월 14일자 열린 풀 리퀘스트로 존재하며, 10월 20일 현재 여전히 열려 있습니다. 작업 부하가 "이것을 설명해 줘"라면 알아차리지 못할 것입니다. "바운딩 박스를 알려 줘"라면 알아차리게 될 것이며, 병합을 기다리거나 수정된 경로를 포함한 포크를 사용해야 합니다.

왕복 과정에서 한 가지가 더 살아남습니다: {{1}}1B 모델에서는 비전 프로젝터가 더 큰 다운로드 항목입니다{{/1}}. Q4_K_M 가중치는 672MB이고, {{2}}f16 프로젝터는 1.11GB입니다{{/2}}. 따라서 가장 작은 실용적 1B 배포는 약 1.8GB의 파일이며, 그 대부분은 언어가 아니라 눈입니다 — "1B는 1GB를 의미한다"는 기대가 틀리는 세부 사항입니다.

무엇을 실행할지, 그리고 무엇에서 실행할지

이번 주에 시험해 보는 것이 목표라면 가장 마찰이 적은 경로는 GGUF 저장소를 대상으로 llama.cpp나 Ollama를 사용하고, 멀티모달 클라이언트가 일치하는 mmproj 파일을 가리키도록 하는 것입니다. 24GB GPU에서 21.2GB의 Q4_K_M은 컨텍스트를 위한 여유 공간을 거의 남기지 않습니다. 8K 토큰 창에 이미지 타일까지 더하면 편안하게 들어가지 않으므로, 긴 프롬프트도 원한다면 Q4_K_S나 더 작은 양자화를 계획하세요. 32GB 이상의 Mac에서는 Q8_0이 실행 가능하며 참조 동작에 가장 가깝습니다. 휴대폰에서는 벤더 자체 앱과 llama.cpp-omni 포크만이 전문가 스케줄링 작업을 수행합니다. 기본 llama.cpp는 정확성을 제공하지만 20 tok/s는 아닙니다.

이때 라우팅 계층이 제 역할을 하는 지점은 로컬 호출의 반대편이다. 휴대폰에서 동작하는 3B 활성 모델은 일상적인 프레임 — 이 영수증을 읽어줘, 이 선반에 물건이 채워져 있는지 봐줘, 이 표지판이 뭐라고 쓰여 있지 — 에는 탁월하지만, 가끔 끝까지 처리하지 못하는 페이지를 만난다. OrcaRouter는 200개 이상의 호스팅 모델을 하나의 키 뒤에 두고, 각 제공업체의 정가를 0% 마진으로 그대로 전달하므로 공급업체의 가격 변경이 당일 반영되며, 업스트림 성능이 저하되면 자동으로 페일오버한다. 효과적인 패턴은 로컬 전용이 아니라 로컬 우선에 호스팅 이스케이프 해치를 두는 것이다. 오픈 웨이트 체크포인트는 직접 호스팅할 몫으로 남고, 라우터는 휴대폰이 넘겨주는 모든 것을 처리한다.

MiniCPM-V 4.7은 OrcaRouter에서 제공되지 않으며, 우리는 그런 식으로 암시하지 않을 것입니다. 이는 직접 실행하는 체크포인트입니다.

세 숫자를 확정하려면 무엇이 필요할까요?

특정 휴대폰에서 앱과 양자화 방식을 명시한 채 {{1}}35B 모델{{/1}}을 독립적으로 측정하면 처리량 문제가 확정될 것이다 — 20.51 tok/s가 다른 사람의 스톱워치에서도 살아남는지까지 포함해서. {{2}}3 GB{{/2}} 수치에 대한 공개된 정의 — 상주 세트, 최대 할당, 아니면 다른 무엇인가 — 가 있으면 메모리 문제도 확정될 것이다. 그리고 카드가 현재 제공하는 다섯 개의 링크된 차트 대신 실제 점수가 담긴 벤치마크별 표가 있으면, "더 적은 시간에 Qwen3.6 35B-A3B보다 더 낫다"는 주장을 OpenBMB가 선택한 가중치와 대조해 검증할 수 있을 것이다. 그중 어느 것도 아직 존재하지 않는다. 그것들이 마련되기 전까지, 정확한 문장은 지루한 쪽이다: {{3}}35B 희소 모델{{/3}}이 보고된 바에 따르면 약 {{4}}3 GB{{/4}}에서 초당 13개 이상의 토큰으로 휴대폰에서 실행되며, {{5}}21 GB{{/5}} 다운로드와 여전히 해결되지 않은 좌표 버그가 하나 있는 병합된 프레임워크 경로를 갖는다.