MiniCPM-V 4.7 Menempatkan Model Visi 35B dalam 3 GB: Mengurai Klaim 100 tok/s

Model dengan 35 miliar parameter tidak bisa muat ke dalam tiga gigabyte. MiniCPM-V 4.7 35B-A3B tetap berjalan dalam sekitar tiga gigabyte, dan kedua pernyataan itu benar — itulah inti triknya, dan alasan angka-angka yang beredar tentang rilis ini layak ditelusuri lebih saksama. Model ini adalah entri sparse mixture-of-experts pertama OpenBMB di lini MiniCPM-V: 35,2 miliar parameter tersimpan, sekitar 3 miliar aktif per token, Apache-2.0, bobot di Hugging Face. Model ini membaca gambar, kumpulan multi-gambar, dan video, serta menjawab dalam teks. Sejak 10 Oktober, model ini juga berjalan di llama.cpp upstream, tempat sebagian besar orang mengenalnya. Uraian berikut memisahkan tiga angka yang semua orang ulangi — 3 GB, 35B, dan angka 100 tok/s — dan menunjukkan mana di antaranya yang benar-benar diterbitkan OpenBMB. Lebih dari 200 model terkelola, satu kunci, harga daftar penyedia diteruskan dengan markup 0%. Lihat apa yang dirutekan OrcaRouter Checkpoint berbobot terbuka tetap di perangkat keras Anda; pintu darurat terkelola hanyalah satu endpoint. Kegagalan AI dan insiden agen yang terdokumentasi di balik rilis seperti ini dikumpulkan dalam Arsip Insiden AI OrcaRouter di mana setiap entri membawa sumbernya sendiri, tingkat keparahan, nilai keyakinan, dan penanda diperdebatkan.

Tiga gigabita, tiga puluh lima miliar parameter, dan tanpa kontradiksi

Aritmetika itu hanya tampak mustahil jika Anda menganggap "di memori" berarti "semuanya". MiniCPM-V 4.7 35B-A3B menjaga sekitar 3 miliar parameter tetap residen dan mengalirkan sisa expert saat router memintanya — kerangka yang digunakan kartu model itu sendiri adalah Lookahead Expert Scheduling, sebuah prediktor routing lintas lapisan yang melakukan prefetch expert yang kemungkinan dibutuhkan lapisan berikutnya, dan menumpangtindihkan pemuatan itu dengan komputasi yang sudah berlangsung. Kartu tersebut dengan cermat menyatakan bahwa prediksi hanya menggerakkan prefetch dan penjadwalan; token tetap mengikuti routing sebenarnya dari model, dan expert yang terlewat oleh prediktor dimuat dan dievaluasi seperti expert lainnya.

Perbedaan itu memiliki konsekuensi yang dapat diukur. Repositori GGUF menerbitkan seluruh model dalam setiap kuantisasi umum, dan tidak ada satu pun dari file-file itu yang berukuran tiga gigabyte:

• Q4_K_M — 21,2 GB di disk.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Proyektor visi — 0,9 GB pada kompresi 4x, 1,1 GB pada f16.

Jadi "3 GB" adalah angka memori residen dalam streaming expert di ponsel, bukan ukuran unduhan dan bukan kebutuhan VRAM untuk desktop. Jika Anda merencanakan penerapan, angka yang menentukan disk dan pemuatan pertama Anda adalah 21,2 GB pada Q4_K_M, dan angka yang menentukan jejak kondisi tunak di ponsel adalah ~3 GB dari vendor. Keduanya ada dalam rilis. Keduanya menjawab pertanyaan yang berbeda, dan sebagian besar liputan telah menggabungkannya menjadi satu.

Dari mana 100 tok/s berasal, dan dari mana tidak

Inilah bagian yang perlu disampaikan terus terang. OpenBMB tidak menerbitkan angka 100 tok/s untuk MiniCPM-V 4.7. Angka pada kartu model adalah 13+ tokens/s, di iPhone 17 Pro Max, dengan memori sekitar 3 GB. Itulah satu-satunya klaim throughput on-device yang dibuat dalam rilis ini, dan angka itu diukur oleh vendor pada perangkat keras yang belum pernah direproduksi oleh siapa pun di luar laboratorium.

Angka yang lebih tinggi memang ada, dan angka itu berasal dari artefak yang berbeda. Fork llama.cpp-omni milik OpenBMB — repositori yang membawa optimasi on-device — menerbitkan tabelnya sendiri untuk target 35B-A3B, disusun berdasarkan optimasi mana yang diaktifkan:

• iPhone 18 Pro Max, 12 GB — baseline 3,38 tok/s, 11,34 dengan Lookahead Expert Scheduling, 17,16 setelah ditambahkan presisi campuran, 20,51 juga dengan DSpark draft head.

• iPad Pro 11 inci M4, 16 GB — 2,97 tok/s baseline, 9,81 dengan LES, 14,92 dengan presisi campuran, 17,39 dengan DSpark.

Itu adalah angka on-device tertinggi yang dipublikasikan untuk model ini, dan puncak tanggaannya adalah 20,51 tok/s—seperlima dari 100. Kesenjangan itu penting karena mengubah untuk apa model ini digunakan. Pada 13 tok/s, aplikasi ponsel menjawab pertanyaan tentang sebuah foto dalam beberapa detik. Pada 100 tok/s, Anda akan mempertimbangkannya sebagai pembaca first-pass streaming untuk video. Yang pertama adalah produk nyata. Yang kedua bukanlah yang dikirim, dan siapa pun yang menyusun anggaran berdasarkan angka dalam tweet itu akan kecewa dengan faktor lima.

Pembacaan jujur atas klaim 100 tok/s adalah bahwa angka itu merupakan pemadatan tiga fakta terpisah — 3 GB, berjalan secara lokal, jauh lebih cepat daripada generasi sebelumnya — menjadi satu angka yang tidak dimuat oleh sumber mana pun. Peningkatan dari generasi ke generasi nyata dan besar: 3,38 menjadi 20,51 tok/s adalah peningkatan 6x pada perangkat kelas yang sama, yang dicapai dengan menumpuk tiga teknik alih-alih menggunakan chip yang lebih besar.

Perilisan itu bukan satu hari, dan tanggalnya penting.

MiniCPM-V 4.7 muncul seperti banyak rilis berbobot terbuka saat ini: berkas lebih dulu, penjelasan menyusul, dan dukungan kerangka kerja ada di antaranya.

• 6 Oktober, 17:40 UTC — model 1B dan varian AWQ, GPTQ, serta int4-nya muncul di Hugging Face, ditambah build GGUF pada 18:05.

• 7 Oktober, 07.07 UTC — repositori 35B-A3B muncul. Masih belum ada kartu model.

• 8 Oktober — head speculative-decoding DSpark untuk kedua ukuran, serta build FP8 untuk 35B.

• 10 Oktober, 18:42 UTC — llama.cpp menggabungkan dukungan model.

• 12 Oktober — OpenBMB melakukan commit pada model card, mendeklarasikan Apache-2.0, dan mengumumkan rilis sebagai produk yang terdokumentasi.

• {{1}}15 Oktober{{/1}} — head DSpark ditautkan dari kartu utama, dengan draf GGUF untuk kedua target.

Urutan itu menjelaskan banyak kebingungan dalam liputan sekunder. Seseorang yang mengenal model tersebut melalui llama.cpp pada minggu kedua Oktober menjalankan rilis yang secara resmi belum ada, tanpa label lisensi dan tanpa bagan benchmark, dan angka throughput mereka mencerminkan pilihan kuantisasi framework itu sendiri, bukan apa pun yang di-benchmark oleh OpenBMB.

Dukungan llama.cpp: telah digabungkan, dan belum sepenuhnya selesai

Pull request upstream yang menambahkan MiniCPM-V 4.7 luar biasa mudah dibaca mengenai apa yang berubah, dan jawabannya adalah: hampir tidak ada yang berubah secara arsitektural. Model ini hampir identik dengan MiniCPM-V 4.6; selisihnya adalah 3D RoPE, posisi tiga nilai per token — waktu, baris, kolom — alih-alih skalar tunggal yang digunakan sebagian besar model visi-bahasa. Dukungannya memperluas jalur 4.6 yang sudah ada untuk membawa dimensi ekstra tersebut. PR tersebut juga mencatat model itu sebagai "akan datang" saat dibuka pada 25 September, yang merupakan petunjuk wajar tentang seberapa awal bobot tersebut beredar.

Residu ini layak diketahui sebelum Anda membangun fitur grounding di atasnya. Sejak merge itu, llama.cpp hulu memberikan posisi yang salah pada token penanda gambar dalam prompt MiniCPM-V 4.7: token gambar itu sendiri ditempatkan dengan benar, tetapi <slice>, </slice>, dan penanda akhir baris diberi nomor seperti teks biasa alih-alih diberi koordinat sudut ubinnya sebagaimana implementasi referensi get_rope_index melakukannya. Gejala yang terlihat adalah koordinat yang dikembalikan secara sistematis terlalu rendah saat Anda menanyakan di mana sesuatu berada dalam sebuah gambar. Perbaikan dengan unit test tersedia sebagai pull request terbuka, bertanggal 14 Oktober, dan per 20 Oktober masih terbuka. Jika beban kerja Anda adalah "describe this", Anda tidak akan menyadarinya. Jika beban kerja Anda adalah "give me the bounding box", Anda akan menyadarinya, dan Anda sebaiknya menunggu merge tersebut atau menggunakan fork yang membawa jalur yang telah diperbaiki.

Satu hal lagi yang bertahan dari proses bolak-balik: untuk model 1B, proyektor visi adalah unduhan yang lebih besar. Bobot Q4_K_M berukuran 672 MB; proyektor f16 berukuran 1,11 GB. Oleh karena itu, deployment 1B terkecil yang berguna adalah sekitar 1,8 GB berkas, sebagian besarnya adalah "mata" alih-alih bahasa — detail yang membuat ekspektasi "1B berarti 1 GB" menjadi keliru.

Apa yang harus dijalankan, dan pada apa

Jika tujuannya adalah mencobanya minggu ini, jalur dengan hambatan paling rendah adalah llama.cpp atau Ollama terhadap repositori GGUF, dengan mengarahkan klien multimodal ke file mmproj yang cocok. Pada GPU 24 GB, Q4_K_M di 21,2 GB menyisakan sangat sedikit ruang untuk konteks — jendela 8K token ditambah ubin gambar tidak akan muat dengan nyaman, jadi rencanakan Q4_K_S atau kuantisasi yang lebih kecil jika Anda juga menginginkan prompt panjang. Pada Mac dengan 32 GB atau lebih, Q8_0 layak dipakai dan merupakan hal yang paling mendekati perilaku referensi. Di ponsel, hanya aplikasi milik vendor sendiri dan fork llama.cpp-omni yang membawa pekerjaan penjadwalan pakar; llama.cpp bawaan memberi Anda kebenaran, bukan 20 tok/s.

Di sinilah lapisan perutean berguna, yaitu pada tahap setelah panggilan lokal. Model dengan 3B parameter aktif di ponsel sangat baik untuk tugas rutin — baca struk ini, apakah rak ini terlihat terisi, apa yang tertulis di rambu ini — dan kadang akan menemui halaman yang tidak bisa diselesaikannya. OrcaRouter menempatkan lebih dari 200 model terhosting di balik satu kunci, meneruskan harga daftar tiap penyedia dengan markup 0% sehingga perubahan harga vendor langsung berlaku pada hari yang sama, dan melakukan failover otomatis saat upstream menurun. Pola yang berhasil adalah mengutamakan lokal dengan opsi cadangan terhosting, bukan hanya lokal. Checkpoint open-weight tetap menjadi milik Anda untuk dihosting; router menangani semua yang dialihkan ponsel.

MiniCPM-V 4.7 tidak dilayani oleh OrcaRouter, dan kami tidak akan menyiratkan sebaliknya. Ini adalah checkpoint yang Anda jalankan.

Apa yang akan menyelesaikan ketiga angka itu

Pengukuran independen atas model 35B pada ponsel yang disebutkan namanya, dengan aplikasi dan kuantisasi yang dinyatakan, akan menjawab pertanyaan throughput — termasuk apakah 20.51 tok/s bertahan terhadap stopwatch orang lain. Definisi yang dipublikasikan untuk angka 3 GB — resident set, alokasi puncak, atau hal lain — akan menjawab pertanyaan memori. Dan tabel per benchmark dengan skor nyata, alih-alih lima grafik tertaut yang saat ini disertakan kartu, akan memungkinkan klaim "lebih baik daripada Qwen3.6 35B-A3B dalam waktu lebih singkat" diperiksa terhadap pembobotan yang dipilih OpenBMB. Belum ada satu pun yang tersedia. Sampai itu ada, kalimat yang akurat adalah kalimat yang membosankan: model sparse 35B yang berjalan di ponsel pada kecepatan yang dilaporkan 13-plus token per detik dalam sekitar 3 GB, dengan unduhan 21 GB dan jalur framework tergabung yang masih memiliki satu bug koordinat terbuka.