MiniCPM-V 4.7 mieści 35B model wizyjny w 3 GB: rozwikłanie twierdzenia o 100 tok/s

Model z 35 miliardami parametrów nie zmieści się w trzech gigabajtach. MiniCPM-V 4.7 35B-A3B i tak działa w około trzech gigabajtach — i oba te stwierdzenia są prawdziwe. Na tym polega cały trik i dlatego warto na chwilę przystopować przy liczbach krążących wokół tej premiery. Model jest pierwszym w linii MiniCPM-V wpisem OpenBMB opartym na rzadkiej mieszance ekspertów: 35,2 mld zapisanych parametrów, około 3 mld aktywnych na token, licencja Apache-2.0, wagi na Hugging Face. Odczytuje obrazy, zestawy wielu obrazów i wideo, a odpowiada tekstem. Od 10 października działa także w upstreamowym llama.cpp, gdzie większość ludzi się z nim zetknęła. Poniżej rozdzielamy trzy liczby, które wszyscy powtarzają — 3 GB, 35B oraz wartość 100 tok/s — i pokazujemy, które z nich OpenBMB faktycznie opublikowało. Ponad 200 modeli hostowanych, jeden klucz, cena katalogowa dostawcy przekazywana bez marży (0%). Zobacz, co routuje OrcaRouter Checkpoint z otwartymi wagami zostaje na Twoim sprzęcie; hostowana furtka awaryjna to jeden endpoint. Udokumentowane awarie AI i incydenty z agentami stojące za takimi premierami jak ta są zebrane w Archiwum Incydentów AI OrcaRouter gdzie każdy wpis ma własne źródła, poziom dotkliwości, ocenę pewności i oznaczenie przypadku spornego.

Trzy gigabajty, trzydzieści pięć miliardów parametrów i żadnej sprzeczności

Ta arytmetyka wydaje się niemożliwa tylko wtedy, gdy założysz, że „w pamięci” oznacza „całość”. MiniCPM-V 4.7 35B-A3B utrzymuje na stałe w pamięci około 3 miliardów parametrów, a pozostałych ekspertów wczytuje strumieniowo, gdy router o nich poprosi — sama karta modelu określa to mianem Lookahead Expert Scheduling: międzywarstwowego predyktora routingu, który wstępnie pobiera ekspertów prawdopodobnie potrzebnych następnej warstwie, nakładając to wczytywanie na już trwające obliczenia. Karta starannie zaznacza, że predykcja jedynie napędza wstępne pobieranie i planowanie; tokeny nadal podążają za rzeczywistym routingiem modelu, a ekspert pominięty przez predyktor jest wczytywany i obliczany tak jak każdy inny.

To rozróżnienie ma mierzalne konsekwencje. Repozytorium GGUF publikuje cały model w każdej popularnej kwantyzacji, a żaden z tych plików nie ma trzech gigabajtów:

• Q4_K_M — 21,2 GB na dysku.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Projektor wizyjny — 0,9 GB przy kompresji 4x, 1,1 GB przy f16.

Zatem „3 GB” to wartość pamięci rezydentnej przy streamingu eksperckim na telefonie, a nie rozmiar pobierania ani wymaganie dotyczące VRAM dla komputera stacjonarnego. Jeśli planujesz wdrożenie, liczbą, która określa miejsce na dysku i pierwsze wczytanie, jest 21,2 GB przy Q4_K_M, a liczbą, która określa stały ślad na telefonie, jest ok. 3 GB podawane przez producenta. Obie wartości są w wydaniu. Odpowiadają na różne pytania, a większość relacji sprowadziła je do jednej.

Skąd bierze się 100 tok/s, a skąd nie

Oto część, w której warto mówić bez ogródek. OpenBMB nie publikuje wartości 100 tok/s dla MiniCPM-V 4.7. Liczba na karcie modelu to 13+ tokenów/s, na iPhone 17 Pro Max, przy około 3 GB pamięci. To jedyne twierdzenie dotyczące przepustowości na urządzeniu, jakie zawiera wydanie, i zostało zmierzone przez dostawcę na sprzęcie, którego nikt spoza laboratorium nie odtworzył.

Wyższe liczby jednak istnieją i pochodzą z innego artefaktu. Fork llama.cpp-omni firmy OpenBMB — repozytorium zawierające optymalizacje na urządzeniu — publikuje własną tabelę dla celu 35B-A3B, zestawioną według tego, które optymalizacje są włączone:

• iPhone 18 Pro Max, 12 GB — 3,38 tok/s jako wartość bazowa, 11,34 z Lookahead Expert Scheduling, 17,16 po dodaniu mieszanej precyzji, 20,51 także z głowicą draft DSpark.

• iPad Pro 11 cali M4, 16 GB — 2,97 tok/s w trybie bazowym, 9,81 z LES, 14,92 z mieszaną precyzją, 17,39 z DSpark.

To najwyższe publikowane wyniki na urządzeniu dla tego modelu, a szczyt drabiny to 20,51 tok/s — jedna piąta ze 100. Ta różnica ma znaczenie, bo zmienia przeznaczenie modelu. Przy 13 tok/s aplikacja na telefon odpowiada na pytanie o zdjęcie w kilka sekund. Przy 100 tok/s rozważałbyś ją jako strumieniowego czytnika pierwszego przebiegu do wideo. Pierwsze to realny produkt. Drugie to nie to, co trafiło do sprzedaży, a każdy, kto planuje budżet według liczby z tweeta, przeliczy się pięciokrotnie.

Uczciwa interpretacja twierdzenia o 100 tok/s jest taka, że stanowi ono kompresję trzech odrębnych faktów — 3 GB, działa lokalnie, znacznie szybciej niż poprzednia generacja — w jedną liczbę, której nie zawiera żadne ze źródeł. Poprawa z generacji na generację jest realna i duża: z 3,38 do 20,51 tok/s to 6-krotny skok na tej samej klasie urządzenia, osiągnięty przez połączenie trzech technik, a nie przez większy układ.

Wydanie nie było jednodniowe, a daty mają znaczenie.

MiniCPM-V 4.7 pojawił się tak, jak obecnie wygląda to w przypadku wielu wydań z otwartymi wagami: najpierw pliki, później wyjaśnienie, a wsparcie frameworków gdzieś pomiędzy.

• 6 października, 17:40 UTC — model 1B oraz jego warianty AWQ, GPTQ i int4 pojawiają się na Hugging Face, a także kompilacje GGUF o 18:05.

• 7 października, 07:07 UTC — repozytorium 35B-A3B pojawia się. Wciąż brak karty modelu.

• 8 października — głowice dekodowania spekulatywnego DSpark dla obu rozmiarów oraz wersja FP8 modelu 35B.

• 10 października, 18:42 UTC — llama.cpp dodaje obsługę modelu.

• 12 października — OpenBMB zatwierdza kartę modelu, deklaruje licencję Apache-2.0 i ogłasza wydanie jako udokumentowany produkt.

• 15 października — głowy DSpark są podlinkowane z głównej karty, wraz z wersjami roboczymi GGUF dla obu modeli docelowych.

Ta kolejność wyjaśnia wiele zamieszania w relacjach wtórnych. Ktoś, kto zetknął się z modelem za pośrednictwem llama.cpp w drugim tygodniu października, uruchamiał wydanie, które oficjalnie jeszcze nie istniało — bez znacznika licencji i bez wykresu benchmarków — a jego liczby przepustowości odzwierciedlają własne wybory kwantyzacji frameworka, a nie cokolwiek, co OpenBMB poddało benchmarkom.

Obsługa llama.cpp: scalona, ale jeszcze nie do końca ukończona

Upstreamowy pull request, który dodał MiniCPM-V 4.7, nietypowo jasno opisuje, co się zmieniło, a odpowiedź brzmi: pod względem architektury prawie nic. Model jest niemal identyczny z MiniCPM-V 4.6; różnicą jest 3D RoPE — trójwartościowa pozycja na token (czas, wiersz, kolumna) zamiast pojedynczego skalaru używanego przez większość modeli językowo-wizyjnych. Obsługa rozszerza istniejącą ścieżkę 4.6, aby przenosić ten dodatkowy wymiar. W PR zauważono również, że model jest „nadchodzący”, gdy otwarto go 25 września, co jest dobrą wskazówką, jak wcześnie wagi były w obiegu.

Warto znać ten pozostały problem, zanim zbudujesz na nim funkcję opartą na groundingu. Od czasu tego scalenia upstream llama.cpp przypisuje tokenom znaczników obrazu niewłaściwe pozycje w promptach MiniCPM-V 4.7: same tokeny obrazu trafiają poprawnie, ale <slice>, </slice> i znaczniki końca wiersza są numerowane jak zwykły tekst, zamiast otrzymywać współrzędne narożników kafli, tak jak robi to referencyjna implementacja get_rope_index. Widocznym objawem jest to, że zwracane współrzędne są systematycznie za niskie, gdy pytasz, gdzie coś znajduje się na obrazie. Poprawka wraz z testem jednostkowym istnieje jako otwarty pull request z 14 października i według stanu na 20 października nadal jest otwarty. Jeśli Twoje zadanie to „opisz to”, nie zauważysz. Jeśli to „podaj mi bounding box”, zauważysz, i powinieneś albo poczekać na scalenie, albo użyć forka, który zawiera poprawioną ścieżkę.

Jeszcze jedna rzecz przetrwa konwersję w obie strony: w przypadku modelu 1B projektor wizyjny jest większym plikiem do pobrania. Wagi Q4_K_M mają 672 MB; projektor f16 ma 1,11 GB. Najmniejsze użyteczne wdrożenie 1B to zatem około 1,8 GB plików, z których większość stanowią oczy, a nie język — szczegół, który obala każde oczekiwanie, że „1B oznacza 1 GB”.

Co uruchomić i na czym

Jeśli celem jest wypróbowanie tego w tym tygodniu, najmniej problematyczną ścieżką jest llama.cpp lub Ollama w oparciu o repozytoria GGUF, wskazując klientowi multimodalnemu pasujący plik mmproj. Na GPU z 24 GB Q4_K_M przy 21,2 GB pozostawia bardzo mało zapasu na kontekst — okno 8K tokenów plus kafelki obrazu nie zmieszczą się komfortowo, więc jeśli chcesz też długi prompt, planuj Q4_K_S lub mniejszą kwantyzację. Na Macu z 32 GB lub więcej Q8_0 jest realne i najbliższe zachowaniu referencyjnemu. Na telefonie tylko własne aplikacje dostawcy i fork llama.cpp-omni realizują prace nad harmonogramowaniem ekspertów; standardowy llama.cpp zapewnia poprawność, ale nie 20 tok/s.

Miejsce, w którym warstwa routingu zdobywa tu swoje uzasadnienie, to druga strona lokalnego wywołania. Model z 3B aktywnych parametrów na telefonie świetnie radzi sobie z rutynowym ujęciem — przeczytaj ten paragon, czy ta półka wygląda na zapełnioną, co mówi ten znak — i od czasu do czasu natrafi na stronę, której nie potrafi dokończyć. OrcaRouter udostępnia ponad 200 modeli hostowanych za jednym kluczem i przekazuje cennik katalogowy każdego dostawcy bez marży (0%), dzięki czemu zmiana ceny u dostawcy jest widoczna tego samego dnia, a w razie degradacji upstreamu następuje automatyczne przełączenie awaryjne. Skuteczny wzorzec to podejście lokalne z awaryjnym wyjściem do modeli hostowanych, a nie wyłącznie lokalne. Checkpoint z otwartymi wagami pozostaje w Twoich rękach do hostowania; router obsługuje wszystko, co telefon przekazuje dalej.

MiniCPM-V 4.7 nie jest udostępniany przez OrcaRouter i nie zamierzamy sugerować inaczej. To checkpoint, który uruchamiasz samodzielnie.

Co miałoby rozstrzygnąć te trzy liczby

Niezależny pomiar modelu 35B na wskazanym telefonie, z podaniem aplikacji i kwantyzacji, rozstrzygnąłby kwestię przepustowości — w tym to, czy 20,51 tok/s przetrwa czyjś stoper. Opublikowana definicja wartości 3 GB — zbiór rezydentny, szczytowa alokacja czy coś innego — rozstrzygnęłaby kwestię pamięci. A tabela wyników poszczególnych benchmarków z rzeczywistymi ocenami, zamiast pięciu podlinkowanych wykresów, które karta obecnie zawiera, pozwoliłaby sprawdzić twierdzenie „lepszy niż Qwen3.6 35B-A3B w krótszym czasie” względem sposobu ważenia wybranego przez OpenBMB. Żadne z nich jeszcze nie istnieje. Dopóki tak się nie stanie, trafnym zdaniem jest to nudne: model rzadki 35B, który działa na telefonie przy raportowanych ponad 13 tokenach na sekundę w około 3 GB, z pobieraniem 21 GB i scaloną ścieżką frameworka, która wciąż ma jeden otwarty błąd współrzędnych.