복셀 탑, 10% 더 적은 토큰, 그리고 OpenBMB가 실제로 지지하는 한 문장

이번 주 MiniCPM-V 4.7 35B-A3B에 대해 가장 많이 인용된 문장은 그 모델 카드에 있지 않다. 그것은 2026년 10월 13일에 게시된 트윗으로, 다음과 같다: "MiniCPM-V 4.7 35B-A3B는 더 적은 토큰을 사용했을 뿐만 아니라 Qwen 3.6 35B-A3보다 더 나은 복셀 파고다를 만들어냈다." 그것이 가리키는 데모는 두 언어 모델이 각각 3D 복셀 일본식 파고다의 코드를 작성하고 나란히 렌더링한 영상이다. 이것은 정말 흥미로운 결과물이다. 이미지 프롬프트로부터 지어진 구조물을 3차원으로 재현하는 비전-언어 모델을 보여주는데, 이는 이미지에 캡션을 다는 것보다 더 어려운 작업이다. 하지만 그 트윗이 무엇인지와 무엇이 아닌지를 구분할 가치가 있다. 왜냐하면 서로 다른 세 가지 주장이 한 줄에 융합되어 있고, 그것들은 서로 다른 세 가지 수준의 뒷받침을 갖기 때문이다. MiniCPM-V 4.7 35B-A3B는 OpenBMB의 실제 체크포인트이며 대략 일주일 된 것이다. Qwen3.6-35B-A3B는 9개월 된 오픈 웨이트 경쟁자로, 역시 Apache-2.0이고, 역시 같은 대표 크기의 희소 전문가 혼합 모델이다. 아래의 모든 내용은 그들 주변의 효율성 주장 중 어느 것이 검증 가능하고, 어느 것이 차트를 찍은 JPEG인지에 관한 것이다.

하나의 문장을 뒤집어쓴 세 가지 주장

그 트윗은 분리 가능한 세 가지를 한데 묶고 있는데, 그중 하나만 문서화되어 있으므로 이들은 분리할 가치가 있다.

• "토큰을 더 적게 사용함" — 이는 하나의 작업에 대한 토큰 소비량에 관한 측정 가능한 진술입니다. 데모와 함께 회자되는 수치는 Qwen3.6 35B-A3B보다 토큰을 10% 더 적게 사용했다는 것입니다. 그 수치는 비교를 진행한 서드파티 제작자로부터 나온 것이지 OpenBMB의 평가에서 나온 것이 아니며, 단일 프롬프트 쌍에 대한 것이지 벤치마크가 아닙니다.

• "더 나은 복셀 탑을 만들어냈다" — 이것은 렌더링된 두 탑을 보고 내린 판단이다. 채점 기준도, 점수 산정 도구도, 독립적인 제3자도 없다. 이것은 인간이라면 3초 만에 내리지만 벤치마크는 전혀 내릴 수 없는 종류의 주장이다. "더 나은 탑"에는 정답이 없기 때문이다.

• "효율성에 품질을 더한 것이 진짜 승부처다" — 그 부분은 하나의 논지이며, 공교롭게도 OpenBMB가 모델 카드에서 숫자를 붙여 실제로 글로 논증하는 논지다. 다만 널리 퍼진 문장은 그것이 아니었을 뿐이다.

이것이 중요한 이유는 처음 두 주장은 기억에 남는 주장이고, 세 번째 주장은 방어할 수 있는 주장이기 때문입니다. 체크포인트 하나에 70 GB의 다운로드를 쓸지 결정하고 있다면, 당신이 원하는 것은 세 번째입니다.

OpenBMB가 실제로 무엇을 썼는지, 그리고 언제 썼는지

타임라인을 먼저 보자. 여러 번 다시 이야기되면서 압축되어버렸기 때문이다. 가중치는 조용히 올라갔다: openbmb/MiniCPM-V-4.7-1B는 2026년 10월 6일 17:40 UTC에 생성되었고,openbmb/MiniCPM-V-4.7-35B-A3B는 10월 7일 07:07 UTC에 생성되었다. 그 시점에 둘 다 모델 카드도, 라이선스 태그도, 벤치마크도 갖추지 않았다 — 이 점은 당시 이곳에서 다루어졌으며, 350억 매개변수 업로드로서는 이상한 상황이었다. 6일 뒤인 2026년 10월 12일, OpenBMB는 문서를 한 번에 커밋했다: 모델 카드, Apache-2.0 라이선스, 평가 차트, 새 시리즈를 앞세운 재작성된 저장소 README, 그리고 발표문. 그날 매개변수는 바뀌지 않았다. 설명이 바뀌었을 뿐이다.

그러니까 솔직한 표현은 "MiniCPM-V 4.7 35B-A3B가 이번 주에 출시되었다"가 아니다. "MiniCPM-V 4.7 35B-A3B가 이번 주에 비로소 읽을 수 있게 되었다"이다. 이제 인용할 수 있는 그에 관한 모든 것은 6일과 7일에 업로드되었지만 문서화되지 않았거나, 12일에 작성된 벤더의 주장이다.

모델 카드가 실제로 제기하는 주장

다음은 카드에서 그대로 가져온 문장이며, 트윗보다 범위가 좁다: Instruct 모드에서 35B-A3B 변형은 "Qwen3.6 35B-A3B보다 더 적은 추론 시간에 더 높은 전체 점수를 달성한다." 그게 전부다. 토큰 수, 우위 폭, 벤치마크별 세부 결과를 산문으로 밝히지 않는다. 그 배경 근거는 산점도다 — 세로축은 평균 평가 점수, 가로축은 로그 스케일의 초 단위 추론 시간 — 이며, 여기서 MiniCPM-V 4.7 35B-A3B는 Qwen3.6-35B-A3B보다 위쪽이면서 왼쪽에 있다. 차트 자체의 각주에서는 평균을 다섯 개 벤치마크, 즉 MMStar, MMMU-Pro, CharXiv reasoning, BLINK, MathVista의 평균값으로 정의한다. 원은 Instruct 모드를, 다이아몬드는 Thinking 모드를 나타낸다.

그것은 2차원 트레이드오프에 관한 실질적이고 구체적인 주장이며, 이번 릴리스에서 가장 강력한 내용입니다. 또한 차트가 알려주지 못하는 점도 짚어둘 가치가 있습니다. 표시된 점들에는 숫자 레이블이 없어서 점수나 시간을 읽어낼 수 없고, 방향만 확인할 수 있습니다. 그려진 대로의 방향은 두 축 모두에서 동시에 MiniCPM에 유리합니다.

그리고 그것은 공급업체가 측정한 것이었다. 이 카드의 평가 수치에는 “결과는 공개 보고서와 공식 체크포인트를 사용한 당사 로컬 평가에서 나온 것입니다.”라는 문구가 함께 적혀 있다. 로컬 평가란 OpenBMB의 하드웨어, OpenBMB의 하네스, OpenBMB의 모드 선택을 의미한다. 그것은 모델 카드가 하기에는 정상적인 일이고, 사실로 세탁하기에는 비정상적인 일이다. 어떤 독립적인 주체도 이 두 체크포인트를 공통 하네스로 실행한 적이 없다. 어떤 리더보드도 두 결과 중 어느 것도 색인하지 않았다. 이 글을 작성하는 시점에서 이 주장에는 정확히 하나의 출처가 있을 뿐이며, 그 출처는 해당 모델을 판매한다.

토큰 효율성이 어디서 나와야 하는지

효율성 논거는 벤치마크 차트에 달려 있지 않습니다. 그것은 세 가지 엔지니어링 선택에 달려 있으며, 그 선택들은 이점이 여러분의 하드웨어에서도 그대로 이어지는지를 결정하기 때문에 이해할 가치가 있습니다.

• Lookahead Expert Scheduling(LES) — 대표적인 기법이다. 희소 전문가 혼합은 토큰당 활성화하는 것보다 훨씬 더 많은 매개변수를 저장하며, 모든 전문가를 메모리에 보관할 수 없는 기기에서는 가중치가 페이지 인/아웃되고 디코딩이 지연된다. LES는 계층 간 라우팅 예측을 사용하여 다음 계층에서 필요할 가능성이 높은 전문가를 미리 로드하고, 실제 라우터가 실제로 선택한 전문가 중 이미 로드된 전문가에 대한 연산을 우선시한다. OpenBMB는 예측이 프리페칭과 스케줄링만을 구동한다는 점을 신중히 밝힌다; 모델의 토큰 수준 라우팅은 변경되지 않으며, 예측기가 놓친 전문가도 여전히 로드되고 평가된다. 이 카드는 이를 통해 실제 기기에서 5배 속도 향상을 달성하며 성능 손실이 없다고 주장한다.

• 세밀한 계층별 양자화 — 전문가 가중치 풋프린트와 메모리 트래픽을 줄이며, 이는 온디바이스 로드 패턴을 맞추는 나머지 절반을 담당한다.

• DSpark 추측 샘플링 — 별도로 openbmb/MiniCPM-V-4.7-35B-A3B-DSpark로 공개된 페어링된 드래프트 모델 경로이며, 스케줄링 및 양자화 작업과 함께 통합되었습니다.

이것들을 겹겹이 쌓으면 이번 릴리스의 대표 수치가 나온다: iPhone 17 Pro Max에서 약 3GB의 메모리를 사용해 초당 13개 이상의 토큰. 이는 벤더가 제시한 수치이며, 벤더 하드웨어에서 벤더 소프트웨어로 — OpenBMB가 만든 앱을 통해 나온 것이다. 이는 제품의 전부가 되거나 아니면 전혀 아무것도 아니게 되는 종류의 주장이며, 현재로서는 회사 외부의 누구도 이를 확인할 방법이 없다. 왜냐하면 이를 재현하려면 휴대폰 데모가 구동하는 온디바이스 스택이 필요하기 때문이다.

토큰 효율성은 분명 실재하지만, 여기서 그것은 스칼라가 아니라 행렬입니다.

이 릴리스에는 모든 요약본에서 납작하게 눌려 사라져 버린 세부 사항이 하나 있는데, 실은 바로 그것이 토큰 이코노미를 실제로 좌우하는 요소입니다.

• MiniCPM-V 4.7 35B-A3B는 요청별로 선택할 수 있는 4x 및 16x 시각 토큰 압축을 함께 지원합니다. 16x 설정은 속도를 위해 시각 토큰을 병합하고, 4x는 세부 정보를 위해 네 배 더 많은 토큰을 유지합니다. 이 카드의 기본값은 16x이며, 매개변수를 채팅 템플릿과 generate 호출 모두에 전달해야 합니다. 그렇지 않으면 플레이스홀더 수와 비전 인코더가 서로 맞지 않습니다.

• 공급업체 자체의 비전-언어 비교 표에는 각 모델 행에 사용된 압축 설정이 기록되어 있다. 그 표에서 MiniCPM-V 4.7 35B-A3B 행은 4x — 디테일 보존 설정, 즉 비용이 더 드는 설정 — 이고, Qwen3.6 35B-A3B 행은 16x이다. 31B Gemma 4 행은 9x로 기재되어 있으며, 두 개의 27B Qwen 행은 4x이다.

• 각주에는 MiniCPM-V 4.7이 두 설정을 모두 지원하는 반면, 표의 다른 모델들은 고정된 압축률만 지원한다고 분명히 명시되어 있습니다.

그걸 함께 읽으면 그림이 달라진다. MiniCPM 행이 토큰을 많이 먹는 설정에서 시각-언어 점수를 뽑고 있는데 Qwen 행은 토큰을 아끼는 설정에서 점수를 뽑고 있다면, 두 열은 서로 다른 양의 시각적 세부 정보를 비교하는 셈이고, 효율성 이야기는 "같은 입력, 더 적은 토큰"이 아니라 "조정 가능한 입력, 그리고 품질에서 이기는 열은 이것"이다. 그것은 트윗의 주장보다 더 흥미롭고 더 정직한 주장이며, OpenBMB는 그것을 앞세우기보다 각주에 실었다.

이것은 또한 당신이 실제로 중요하게 여기는 수치 — 시각적 세부 단위당 토큰 — 를 이 표에서 전혀 읽어낼 수 없다는 뜻이기도 합니다. 그 수치는 두 모델을 동일한 설정에서 실행해야만 얻을 수 있는데, 아무도 그 결과를 공개하지 않았습니다.

첨부된 주의사항이 있는 표

이 카드에는 두 개의 벤더 표가 포함되어 있습니다. 하나는 비전-언어용이고 다른 하나는 언어용이며, 둘 다 Instruct 모드이고, 둘 다 35B-A3B급 Qwen 모델 두 개, 31B Gemma 하나, 27B Qwen 두 개가 포함된 모델군을 대상으로 합니다. 아래 수치들은 벤더 자체의 PNG 차트에서 읽어낸 것이며, 주의할 점은 구조적입니다: 숫자들은 해당 차트에서 픽셀로만 존재하고 표로는 존재하지 않으므로, 다음 내용은 기계 판독으로 추출되었고 작은 전사 오류가 있을 수 있습니다.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91.20, Qwen3.6 35B-A3B 90.40과 비교. 벤더 자체 실행에서 0.8점 차이다.

• OmniDocBench v1.6 — MiniCPM은 약 98.2, Qwen 모델은 약 93.3으로, 이는 표에서 가장 큰 단일 격차이며, 재현된다면 가장 중요하게 작용할 항목입니다. 문서 파싱이 보통 토큰 예산이 소비되는 곳이기 때문입니다.

• MMMU — 약 80.2 대 80.0, 차트 이미지의 해상도에서는 막상막하입니다.

• MMMU-Pro — 약 69.7 대 67.7, 27B Qwen이 둘 모두보다 더 높은 위치에 있는 행에서.

• 언어 표 — 같은 형태지만, 지시 따르기와 코드에서 더 눈에 띄는 칸들. IFBench는 47.7 대 35.3으로, LiveCodeBench-v6는 97.0 대 54.3으로 기재되어 있다. 이 두 수치는 충분히 커서, 다른 누군가가 재현하기 전까지는 이번 공개에서 가장 신뢰하기 어려운 칸으로 취급해야 한다: 규모가 비슷한 두 오픈 MoE 모델 사이에서 코드 벤치마크상 43점 차이가 두 당사자 중 한쪽에 의해 측정된 것은, 제2의 측정 도구가 필요한 주장이다.

벤더 보고, 벤더 하네스, 미재현. 그게 전부다. 이 수치가 독립 하네스에서도 견딘다면, 파레토 프런티어 주장은 옳고 탑 영상은 각주에 불과하다. 그렇지 않다면, 탑 영상이 전부다.

도입 수치가 말해 주는 것은 품질과는 아무 상관이 없다.

이 비교에서 누구도 이의를 제기하지 않는 숫자가 하나 있는데, 그것은 벤치마크가 아니다. 2026년 10월 13일에 확인한 Hugging Face 다운로드 카운터는 openbmb/MiniCPM-V-4.7-35B-A3B의 경우 630을 보여주며, 반면 대략 360만을 기록한 Qwen/Qwen3.6-35B-A3B는 2026년 4월 15일에 만들어진 저장소로, 따라서 채택 곡선상 약 9개월 더 앞서 있다. 그 격차는 시간을 측정하는 것이지 우수성을 측정하는 것이 아니며, 효율성 질문이 애초에 이 방향으로 제기되는 이유이기도 하다: 신참은 기본값이 될 9개월을 갖지 못했기 때문에 바로 토큰당 기준으로 논쟁해야 한다.

또한 이 목록에는 짚고 넘어갈 만한 작은 내부 모순이 하나 있습니다. 이 저장소에는 같은 패밀리의 나머지에서 물려받은 "On-Device Model" 태그가 붙어 있는데, 70.4GB의 BF16 가중치로 이루어진 352억 매개변수 희소 MoE는 다운로드하는 사람이 인식할 만한 어떤 의미에서도 온디바이스가 아닙니다. 온디바이스 이야기는 실제로 존재하지만, 그것은 체크포인트를 통해서가 아니라 체크포인트 위에 양자화와 전문가 스트리밍을 얹어서 실현됩니다. 예산은 태그가 아니라 양자화된 빌드와 앱을 기준으로 산정하세요.

이번 주에 그것에 대해 무엇을 해야 할까

실용적인 입장은 좁고 명확하다. 효율성 주장이 검증되기를 원한다면, 아직 검증할 것은 없다 — 그것은 한 벤더의 차트이고, 작업별 수치가 붙은 유일한 숫자(토큰 10% 감소, pagoda 하나)는 제3자의 단일 데모에서 나온 것이다. 모델을 실행하고 싶다면, 가중치는 Apache-2.0이고, 아키텍처는 문서화되어 있으며, 다운샘플링 설정은 당신이 선택할 수 있다. 이는 진정한, 그리고 과소평가된 레버다: 처리량이 중요할 때는 16x, 차트가 당신에게 문서를 보여줄 때는 4x.

이 비교의 한쪽은 오늘날 호스팅 API를 통해 접근할 수 있고 다른 쪽은 그렇지 않으며, 어느 쪽이 어느 쪽인지 정확히 밝히는 것이 좋습니다. qwen/qwen3.6-35b-a3b는 OrcaRouter의 호스팅 모델입니다 — 하나의 키 뒤에 있는 카탈로그에 있으며, Qwen 자체 정가에 아무것도 더 붙지 않은 가격입니다, 고정한 제공자가 아니라 상태가 정상인 제공자로 디스패치합니다. MiniCPM-V 4.7은 우리가 호스팅하지 않습니다. 직접 서빙하는 오픈 웨이트 체크포인트입니다. 이 비대칭성이 바로 여기서 유용한 점입니다. 이 비교의 Qwen 쪽을 오늘 오후에 베이스라인에 넣고, OpenBMB의 하네스를 자체 데이터에 대해 실행해 그것과 비교하고, 벤더의 차트가 답이 아니라 가설이 되게 할 수 있습니다.

이는, 논쟁 전체가 당신의 하드웨어에서의 효율성에 관한 것이었던 만큼, 그 문제를 결판낼 수 있었던 유일한 측정치입니다.