Pagoda Voxel, Token 10% Lebih Sedikit, dan Satu Kalimat yang Benar-Benar Didukung OpenBMB

Kalimat yang paling banyak dikutip tentang MiniCPM-V 4.7 35B-A3B minggu ini tidak ada di kartu modelnya. Itu adalah sebuah tweet, yang diunggah pada 13 Oktober 2026, yang berbunyi: "MiniCPM-V 4.7 35B-A3B tidak hanya menggunakan lebih sedikit token, tetapi juga menghasilkan pagoda voxel yang lebih baik daripada Qwen 3.6 35B-A3." Demonstrasi yang ditunjuknya adalah video dua model bahasa yang masing-masing menulis kode untuk pagoda Jepang voxel 3D, dirender berdampingan. Ini adalah artefak yang benar-benar menarik — ini menunjukkan model visi-bahasa mereproduksi struktur bangunan dalam tiga dimensi dari prompt gambar, yang merupakan tugas lebih sulit daripada membuat takarir untuk gambar. Tetapi ada baiknya memisahkan apa tweet itu dari apa yang bukan, karena tiga klaim berbeda telah digabungkan menjadi satu baris, dan ketiganya memiliki tingkat dukungan yang berbeda. MiniCPM-V 4.7 35B-A3B adalah checkpoint nyata dari OpenBMB dan usianya sekitar satu minggu; Qwen3.6-35B-A3B adalah pesaing bobot terbuka berusia sembilan bulan, juga Apache-2.0, juga sparse mixture-of-experts pada ukuran utama yang sama. Semua yang di bawah ini membahas klaim efisiensi mana di sekitar keduanya yang dapat diperiksa, dan mana yang hanya JPEG dari sebuah grafik.

Tiga klaim mengenakan satu kalimat

Tweet itu menggabungkan tiga hal yang dapat dipisahkan, dan ketiganya layak dipisahkan karena hanya satu di antaranya yang didokumentasikan.

• "Menggunakan lebih sedikit token" — ini adalah pernyataan yang dapat diukur tentang konsumsi token untuk satu tugas. Angka yang beredar bersama demo tersebut adalah 10% lebih sedikit token dibandingkan Qwen3.6 35B-A3B. Angka itu berasal dari kreator pihak ketiga yang menjalankan perbandingan, bukan dari evaluasi OpenBMB, dan itu adalah satu pasangan prompt, bukan benchmark.

• "Menghasilkan pagoda voxel yang lebih baik" — ini adalah penilaian, yang dibuat dengan melihat dua pagoda yang dirender. Tidak ada rubrik, tidak ada perangkat penilaian, dan tidak ada pihak independen. Ini adalah jenis klaim yang bisa dibuat manusia dalam tiga detik dan sama sekali tidak bisa dibuat oleh tolok ukur, karena "pagoda yang lebih baik" tidak memiliki kebenaran dasar.

• "Efisiensi plus kualitas adalah medan pertempuran yang sebenarnya" — bagian itu adalah tesis, dan kebetulan itulah yang memang diargumentasikan OpenBMB secara tertulis, lengkap dengan angka-angka, di kartu model. Hanya saja, bukan kalimat itu yang menyebar.

Ini penting karena dua klaim pertama adalah yang mudah diingat dan klaim ketiga adalah yang bisa dipertahankan. Jika Anda sedang memutuskan apakah akan menghabiskan 70 GB unduhan untuk sebuah checkpoint, Anda menginginkan klaim yang ketiga.

Apa yang sebenarnya ditulis OpenBMB, dan kapan

Linimasa dulu, karena telah dipadatkan oleh penceritaan ulang. Bobotnya naik secara diam-diam: openbmb/MiniCPM-V-4.7-1Bdibuat pada 6 Oktober 2026 pukul 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bpada 7 Oktober pukul 07:07 UTC. Saat itu, keduanya tidak menyertakan kartu model, tag lisensi, atau tolok ukur — hal ini dibahas di sini saat itu, dan itu keadaan yang aneh untuk unggahan berparameter 35 miliar. Enam hari kemudian, pada 12 Oktober 2026, OpenBMB meng-commit dokumentasinya dalam sekali duduk: kartu model, lisensi Apache-2.0, grafik evaluasi, README repositori yang ditulis ulang dan mengedepankan seri baru, serta sebuah pengumuman. Parameternya tidak berubah hari itu. Penjelasannya yang berubah.

Jadi, pembingkaian yang jujur bukanlah "MiniCPM-V 4.7 35B-A3B diluncurkan minggu ini." Melainkan "MiniCPM-V 4.7 35B-A3B menjadi terbaca minggu ini." Segala hal tentangnya yang kini dapat dikutip entah diunggah pada tanggal 6 dan 7 tetapi tidak terdokumentasi, atau ditulis pada tanggal 12 dan merupakan klaim vendor.

Klaim yang memang dibuat oleh kartu model

Berikut kalimatnya, persis dari kartu tersebut, dan cakupannya lebih sempit daripada tweet: dalam mode Instruct, varian 35B-A3B "mencapai skor keseluruhan yang lebih tinggi dalam waktu inferensi yang lebih singkat daripada Qwen3.6 35B-A3B." Itu saja. Tidak ada jumlah token, tidak ada selisih, tidak ada rincian per benchmark dalam bentuk prosa. Bukti di baliknya adalah diagram sebar — skor evaluasi rata-rata pada sumbu vertikal, waktu inferensi dalam detik pada skala log di sumbu horizontal — di mana MiniCPM-V 4.7 35B-A3B berada di atas dan di sebelah kiri Qwen3.6-35B-A3B. Catatan kaki grafik itu sendiri mendefinisikan rata-rata sebagai mean dari lima benchmark: MMStar, MMMU-Pro, CharXiv reasoning, BLINK, dan MathVista. Lingkaran menunjukkan mode Instruct, belah ketupat menunjukkan mode Thinking.

Itu adalah klaim yang nyata dan spesifik tentang trade-off dua dimensi, dan itu adalah hal terkuat dalam rilis ini. Perlu juga dicatat apa yang tidak dapat diberitahukan oleh bagan: tidak ada label numerik pada titik-titik yang diplot, jadi Anda tidak dapat membaca skor atau waktu, hanya arah. Arahnya, seperti yang digambar, menguntungkan MiniCPM pada kedua sumbu sekaligus.

Dan itu diukur oleh vendor. Angka evaluasi di kartu tersebut memuat baris "Hasil berasal dari laporan publik dan evaluasi lokal kami menggunakan checkpoint resmi." Evaluasi lokal berarti perangkat keras OpenBMB, harness OpenBMB, pemilihan mode OpenBMB. Itu hal yang normal dilakukan kartu model dan hal yang tidak normal untuk dicuci menjadi fakta. Tidak ada pihak independen yang menjalankan kedua checkpoint ini terhadap harness bersama. Tidak ada papan peringkat yang mengindeks salah satu hasil tersebut. Sampai tulisan ini dibuat, klaim itu hanya punya satu sumber, dan sumber itu menjual model tersebut.

Dari mana efisiensi token seharusnya berasal

Argumen efisiensi tidak bertumpu pada grafik benchmark. Argumen itu bertumpu pada tiga pilihan rekayasa, dan pilihan-pilihan itu layak dipahami karena menentukan apakah keunggulannya ikut terbawa ke perangkat keras Anda atau tidak.

• Lookahead Expert Scheduling (LES) — teknik utamanya. Sparse mixture-of-experts menyimpan jauh lebih banyak parameter daripada yang diaktifkan per token, dan pada perangkat yang tidak dapat menampung semua pakar di memori, bobot akan dipindahkan masuk dan keluar dan decoding menjadi macet. LES menggunakan prediksi perutean lintas lapisan untuk memuat lebih awal pakar yang kemungkinan dibutuhkan oleh lapisan berikutnya, dan memprioritaskan komputasi untuk pakar yang benar-benar dipilih oleh router asli yang kebetulan sudah dimuat. OpenBMB berhati-hati untuk menyatakan bahwa prediksi tersebut hanya menggerakkan prefetching dan penjadwalan; perutean tingkat token model tidak berubah, dan pakar yang terlewat oleh prediktor tetap dimuat dan dievaluasi. Kartu ini mengklaim percepatan 5× pada perangkat nyata dari hal ini, tanpa kehilangan kemampuan.

• Kuantisasi per-lapisan berbutir halus — memperkecil jejak bobot pakar dan lalu lintas memori, yang merupakan separuh lainnya untuk membuat pola pemuatan di perangkat dapat muat.

• DSpark speculative sampling — jalur model draf berpasangan, diterbitkan secara terpisah sebagai openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, dan diintegrasikan bersama pekerjaan penjadwalan dan kuantisasi.

Jika digabungkan, semua ini menghasilkan angka andalan rilis tersebut: lebih dari 13 token per detik dengan menggunakan memori sekitar 3 GB pada iPhone 17 Pro Max. Itu adalah angka dari vendor, pada perangkat keras vendor, dengan perangkat lunak vendor — sebuah aplikasi yang ditulis OpenBMB. Ini jenis klaim yang entah menjadi keseluruhan produk atau sama sekali tidak berarti, dan saat ini tidak ada cara bagi siapa pun di luar perusahaan untuk memeriksanya, karena untuk mereproduksinya diperlukan stack on-device yang dijalankan demo ponsel tersebut.

Efisiensi token itu nyata, tetapi di sini ini adalah matriks, bukan skalar

Ada satu detail dalam rilis ini yang telah dihilangkan dari setiap ringkasannya, dan justru itulah yang sebenarnya mengatur ekonomi token.

• MiniCPM-V 4.7 35B-A3B mendukung kompresi token visual campuran 4x dan 16x, yang dapat dipilih per permintaan. Pengaturan 16x menggabungkan token visual demi kecepatan; 4x mempertahankan empat kali lebih banyak, untuk detail. Default kartu ini adalah 16x, dan parameter tersebut harus diteruskan ke template chat dan juga panggilan generate, jika tidak jumlah placeholder dan encoder visi akan tidak cocok.

• Tabel perbandingan visi-bahasa milik vendor sendiri mencatat pengaturan kompresi yang digunakan untuk baris setiap model. Dalam tabel itu, baris MiniCPM-V 4.7 35B-A3B berada pada 4x — pengaturan yang mempertahankan detail, yaitu yang mahal — dan baris Qwen3.6 35B-A3B berada pada 16x. Baris Gemma 4 31B terdaftar pada 9x; dua baris Qwen 27B pada 4x.

• Sebuah catatan kaki menyatakan dengan jelas bahwa MiniCPM-V 4.7 mendukung kedua pengaturan tersebut, sedangkan model-model lain dalam tabel hanya mendukung rasio kompresi tetap.

Jika dibaca bersama-sama, gambarannya berubah. Jika baris MiniCPM mengambil skor visi-bahasanya pada setelan yang rakus token sementara baris Qwen mengambil skornya pada setelan yang hemat token, maka kedua kolom itu membandingkan jumlah detail visual yang berbeda, dan kisah efisiensinya bukanlah "input yang sama, token lebih sedikit" — melainkan "input yang dapat disesuaikan, dan inilah kolom yang menang dalam hal kualitas." Itu klaim yang lebih menarik dan lebih jujur daripada klaim dalam tweet itu, dan OpenBMB menerbitkannya dalam catatan kaki alih-alih mengutamakannya.

Ini juga berarti angka yang sebenarnya Anda pedulikan — token per unit detail visual — sama sekali tidak bisa dibaca dari tabel ini. Itu memerlukan menjalankan kedua model pada pengaturan yang sama, yang belum pernah dipublikasikan oleh siapa pun.

Tabel tersebut, dengan catatan yang dilampirkan.

Kartu ini menyertakan dua tabel vendor, satu untuk visi-bahasa dan satu untuk bahasa, keduanya dalam mode Instruct, keduanya dibandingkan dengan sekumpulan model yang mencakup dua model Qwen kelas 35B-A3B, satu Gemma 31B, dan dua Qwen 27B. Angka-angka di bawah ini dibaca dari diagram PNG milik vendor sendiri, dan peringatannya bersifat struktural: angka-angka itu hanya ada sebagai piksel dalam diagram tersebut, bukan sebagai tabel, sehingga apa yang berikut ini diekstrak melalui pembacaan mesin dan kesalahan transkripsi kecil mungkin saja terjadi.

OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 dibandingkan dengan Qwen3.6 35B-A3B pada 90,40. Selisih 0,8 poin, berdasarkan pengujian vendor sendiri.

• OmniDocBench v1.6 — sekitar 98,2 untuk MiniCPM dibandingkan sekitar 93,3 untuk model Qwen, yang merupakan selisih tunggal terbesar dalam tabel dan yang akan paling penting jika tereproduksi, karena penguraian dokumen adalah tempat anggaran token biasanya dihabiskan.

• MMMU — sekitar 80.2 berbanding 80.0, hasil yang sangat imbang pada resolusi gambar bagan.

• MMMU-Pro — sekitar 69,7 berbanding 67,7, pada baris di mana Qwen 27B berada lebih tinggi daripada keduanya.

• Tabel bahasa — bentuk yang sama, dengan sel yang lebih mencolok pada instruction-following dan kode. IFBench tercatat sekitar 47,7 berbanding 35,3, dan LiveCodeBench-v6 sekitar 97,0 berbanding 54,3. Kedua angka itu cukup besar sehingga harus diperlakukan sebagai sel yang paling tidak kredibel dalam rilis ini sampai pihak lain menjalankannya: selisih 43 poin pada benchmark kode antara dua model MoE terbuka berukuran serupa, yang diukur oleh salah satu dari dua pihak, adalah klaim yang membutuhkan instrumen kedua.

Dilaporkan vendor, diuji dengan harness vendor, tidak direproduksi. Itulah keseluruhannya. Jika angka-angka ini bertahan di bawah harness independen, klaim Pareto-frontier benar dan video pagoda hanyalah catatan kaki. Jika tidak, video pagoda itulah satu-satunya yang ada.

Apa yang dikatakan angka adopsi, yang sama sekali tidak berkaitan dengan kualitas

Satu angka dalam perbandingan ini tidak diperdebatkan oleh siapa pun, dan itu bukan tolok ukur. Penghitung unduhan Hugging Face, yang dibaca pada 13 Oktober 2026, menunjukkan 630 untuk openbmb/MiniCPM-V-4.7-35B-A3Bdibandingkan dengan sekitar 3,6 juta untukQwen/Qwen3.6-35B-A3B— sebuah repositori yang dibuat pada 15 April 2026 dan karenanya berada sekitar sembilan bulan lebih jauh di sepanjang kurva adopsi. Kesenjangan itu mengukur waktu, bukan nilai, dan itulah alasan pertanyaan tentang efisiensi bahkan diajukan ke arah ini: pendatang baru harus berargumen atas dasar per token justru karena ia belum memiliki waktu sembilan bulan untuk menjadi default.

Ada juga kontradiksi internal kecil dalam listing ini yang perlu diperhatikan. Repositori ini menyandang tag "On-Device Model" yang diwarisi dari bagian lain keluarga ini, dan sparse MoE dengan 35,2 miliar parameter dalam 70,4 GB bobot BF16 bukanlah model di perangkat dalam pengertian apa pun yang akan dikenali oleh pengunduh. Narasi di perangkat itu nyata, tetapi berjalan melalui kuantisasi dan streaming expert di atas checkpoint, bukan melalui checkpoint itu sendiri. Anggarkan berdasarkan build terkuantisasi dan aplikasinya, bukan berdasarkan tag tersebut.

Apa yang harus dilakukan tentang hal ini minggu ini

Posisi praktisnya sempit dan jelas. Jika Anda ingin klaim efisiensinya diverifikasi, belum ada yang bisa diverifikasi — itu bagan dari satu vendor, dan satu-satunya angka dengan figur per tugas yang terlampir (10% lebih sedikit token, satu pagoda) berasal dari satu demo pihak ketiga. Jika Anda ingin menjalankan modelnya, bobotnya Apache-2.0, arsitekturnya didokumentasikan, dan pengaturan downsampling bisa Anda pilih sendiri, yang merupakan pengungkit nyata dan kurang dihargai: 16x saat throughput penting, 4x saat bagan menunjukkan dokumen kepada Anda.

Separuh dari perbandingan ini dapat dijangkau melalui API yang dihosting saat ini dan separuh lainnya tidak, dan penting untuk bersikap tepat tentang mana yang mana. qwen/qwen3.6-35b-a3badalah model yang dihosting di OrcaRouter — model ini berada di katalog di balik satu kunci, pada harga daftar Qwen sendiri tanpa tambahan apa pun, mengarahkan ke penyedia mana pun yang sehat alih-alih ke penyedia yang Anda tentukan. MiniCPM-V 4.7 tidak dihosting oleh kami; ini adalah checkpoint dengan bobot terbuka yang Anda host sendiri. Asimetri itu adalah hal yang berguna di sini. Anda dapat memasukkan sisi Qwen dari perbandingan ini ke dalam baseline sore ini, menjalankan harness OpenBMB pada data Anda sendiri terhadapnya, dan biarkan bagan vendor menjadi hipotesisnya alih-alih jawabannya.

Yang, mengingat seluruh perdebatan ini adalah tentang efisiensi pada perangkat keras Anda, merupakan satu-satunya pengukuran yang memang akan mampu menyelesaikannya.