MiniCPM-V 4.7 1B na codziennym iPhonie: co właściwie oznacza „wykracza poza Pro Max”

MiniCPM-V 4.7 1B to model językowo-wizualny o 1,55 mld parametrów, który OpenBMB przesłało na Hugging Face 6 października 2026 r. i opatrzyło datą 12 października w swoich notatkach wydania. Ma kartę modelu, jedenaście skwantyzowanych wariantów, tag Ollama i demonstracyjną aplikację działającą na urządzeniu. Nie ma natomiast takiej wersji tej opowieści, która się broni, gdy wycenisz sprzęt. Krążąca w kręgach deweloperskich teza — że model działa teraz w aplikacji OnDeviceLLM na zwykłych iPhone'ach, nie tylko na 12 GB Pro Max — to część warta dokładnego zbadania, ponieważ „działa na telefonie” i „działa na twoim telefonie” dzieli około 3 GB zapasu pamięci, którego większość iPhone'ów nie ma. Udokumentowane awarie AI i incydenty z udziałem agentów związane z wydaniami takimi jak to są gromadzone w OrcaRouter AI Incident Archive, gdzie każdy wpis zawiera własne źródła, poziom dotkliwości, ocenę pewności i znacznik sporności.

Oto aktualny stan rzeczy — ze szwami na wierzchu. Wszystko poniżej pochodzi albo bezpośrednio z plików wag, albo z dokumentacji OpenBMB, albo z opublikowanych specyfikacji Apple. Jeśli jakaś liczba pochodzi z wpisu dewelopera, a nie z odtwarzalnego artefaktu, artykuł wyraźnie to zaznacza.

Co jest faktycznie wiadome, a co jest jedynie twierdzone

Model jest prawdziwy i można go pobrać. Checkpoint BF16 ma 1 554 476 272 parametrów, co daje około 3,1 GB na dysku. Repozytorium zawiera pełną kartę modelu — rzadkość w najnowszej historii tej rodziny — wymieniającą szkielet tekstowy Qwen3.5, wieżę wizyjną SigLIP2 z 27 warstwami przy szerokości ukrytej 1152, kafelki wejściowe o rozmiarze 980 pikseli, okno kontekstu 262 144 tokenów i licencję Apache 2.0. Wpis w README samego OpenBMB datuje wydanie na 2026-10-12; repozytorium Hugging Face utworzono 2026-10-06. Sześciodniowa różnica to opóźnienie między przesłaniem a ogłoszeniem, z którego słynie ta rodzina, i to dlatego październikowy artykuł wciąż może nazwać sześciodniowe repozytorium cichym wypuszczeniem.

To, czego nie potwierdza żaden artefakt, to konkretne twierdzenie, że model 1B działa w OnDeviceLLM na „zwykłych iPhone’ach poza 12GB Pro Max”. Źródłem tego ujęcia jest post dewelopera. Publiczne repozytorium projektu OnDeviceLLM — będące zestawem startowym do aplikacji do czatu offline i tłumaczenia, a nie produktem dostępnym w App Store — ma zero gwiazdek, a ostatni push miał w nim miejsce 27 lipca 2026 r. Jest o dziesięć tygodni starsze niż wagi MiniCPM-V 4.7, więc jakiekolwiek wsparcie dla tego modelu w nim jest świeże i nieudokumentowane. Traktuj „już działa w OnDeviceLLM” jako relację kogoś, kto to zrobił, a nie jako wspieraną przez dostawcę ścieżkę wdrożenia.

To rozróżnienie ma znaczenie, ponieważ własne wyniki dostawcy dotyczące pracy na urządzeniu wcale nie odnoszą się do modelu 1B.

Liczba 3 GB dotyczy 35B, a nie 1B

Nagłówek reklamowy OpenBMB — „13+ tokenów/s przy zaledwie 3 GB pamięci na iPhone 17 Pro Max” — dotyczy 35B-A3B wariantu Mixture-of-Experts, działającego na największym iPhone, jaki Apple sprzedaje. Stojąca za tym technika, Lookahead Expert Scheduling, utrzymuje większość wag ekspertów na SSD i pobiera z wyprzedzeniem te, których prawdopodobnie będzie potrzebować następna warstwa. To imponujący kawałek inżynierii systemowej i to dlatego nazwa 35B wciąż pojawia się w materiałach dotyczących telefonów.

Model 1B nie potrzebuje niczego z tego. To gęsty model, który w całości mieści się w pamięci. Na papierze czyni go to bardziej demokratycznym z tych dwóch, i dlatego argument o „codziennym iPhonie” ma podstawy. Ale arytmetyka jest mniej przychylna, niż sugeruje to ujęcie:

• Wagi BF16 — 3,1 GB na dysku i mniej więcej tyle samo w pamięci po załadowaniu, przed uwzględnieniem jakiegokolwiek KV cache lub aktywacji wizyjnych • Q8_0 GGUF — 1,08 GB wag plus 0,90 GB projektora wizyjnego przy ustawieniu kompresji 4× lub 1,11 GB przy 16× • Q4_K_M GGUF — 0,67 GB wag, z tym samym narzutem projektora • Projektor wizyjny — to część, o której ludzie zapominają; nie zmniejsza się wraz z kwantyzacją modelu językowego i jest liczony raz na każdy załadowany model • Kontekst — do 262 144 tokenów na papierze; każdy token KV cache to dodatkowa pamięć, której karta modelu nie uwzględnia

Wersja Q4 z projektorem 16× daje około 1,8 GB wag. Dodaj działający cache KV dla kilku tysięcy tokenów rozmowy i placeholderów obrazów, a prosisz aplikację o coś w zakresie 2,2–2,8 GB. Na 12 GB Pro Max to komfortowa sytuacja. Na iPhonie z 8 GB, gdzie system operacyjny i każda inna uruchomiona aplikacja już rywalizują o tę samą pulę pamięci, aplikacja prosząca o 2,5 GB prosi o dużą część tego, co zostało. iOS albo to przyzna, albo pod presją uśmierci aplikację mechanizmem jetsam.

Dlaczego wiersz dotyczący RAM-u w iPhone'ie to prawdziwa specyfikacja

Apple nie publikuje informacji o RAM iPhone’a w swoich materiałach marketingowych i nigdy nie zachęcał deweloperów, by traktowali telefon jako komputer z adresowalną pamięcią. To jest ograniczenie, na które natrafia twierdzenie „beyond the 12GB Pro Max”. Poziom Pro Max od kilku generacji ma więcej pamięci niż modele standardowe, a różnica między „telefonem z filmu recenzyjnego” a „telefonem w kieszeni czytelnika” to dokładnie ta różnica, od której zależy opowieść tego modelu o działaniu na urządzeniu.

Uczciwa wersja tego twierdzenia jest węższa i wciąż interesująca: model wizyjny o 1 mld parametrów, który kiedyś wymagał laptopa lub flagowego telefonu, teraz mieści się w budżecie pamięci telefonu średniej klasy, jeśli użyjesz 4-bitowej kwantyzacji i zaakceptujesz krótszy kontekst. To prawdziwy krok w dół, jeśli chodzi o klasę sprzętu. To nie to samo co „działa na każdym iPhonie”, a różnica jest warta jasnego zaznaczenia, ponieważ decyduje o tym, czy czytelnik może to wdrożyć.

Karta modelu tego nie rozstrzyga. Dokumentuje wsparcie dla iOS, Androida i HarmonyOS, wsparcie dla układów od dnia zero od Rockchip, Houmo, Intel, AMD i Arm oraz linki do repozytorium wdrożeń brzegowych z aplikacjami i kodem źródłowym. Nigdzie nie podaje minimalnej pamięci urządzenia, matrycy przetestowanych urządzeń ani wskaźnika tokenów na urządzenie dla modelu 1B. Jedynym urządzeniem wymienionym we własnych zasobach demonstracyjnych modelu 1B jest iPhone 17 Pro Max — to samo urządzenie co w nagłówku dotyczącym 35B.

W czym model jest naprawdę dobry przy 1B

Powód, dla którego ta arytmetyka pamięci jest warta zachodu, jest taki, że model 1B wykonujący rozumienie dokumentów i ekranu na telefonie to inna kategoria produktu niż chatbot. Oznacza to, że paragon, formularz, menu, etykieta lub zrzut ekranu mogą zostać przekształcone w ustrukturyzowany tekst bez rundy przez sieć — bez przesyłania, bez kosztu za obraz, bez minimalnego opóźnienia narzucanego przez wieżę komórkową.

OpenBMB opublikowało wyniki dla modelu 1B — wszystkie raportowane przez dostawcę i żaden nie został niezależnie odtworzony w momencie pisania tego tekstu — które wskazują OCRBench na poziomie 86,1, MathVista na 74,3, CharXiv Reasoning na 48,8, LongVideoBench na 53,4, a MotionBench na 54,55. Głównym porównaniem przygotowanym przez dostawcę jest zestawienie z Qwen3.5 0.8B — model ma według niego wygrywać zarówno w ogólnym wyniku, jak i w wydajności wnioskowania — oraz z MiniCPM-V 4.6, w przypadku którego ma poprawiać podstawowe możliwości. Są to wyłącznie benchmarki samego dostawcy, przeprowadzone przez dostawcę, a karta modelu przedstawia je w formie wykresów, a nie tabeli ze szczegółami dotyczącymi harnessu.

Dla każdego, kto faktycznie to wdraża, dwa szczegóły architektoniczne mają większe znaczenie niż wyniki:

• Mieszana kompresja tokenów wizualnych 4×/16× — wywołujący wybiera przy każdym żądaniu, czy obraz stanie się szczegółową sekwencją tokenów, czy tanią, dzięki czemu skan paragonu i miniatura mogą współdzielić jedno wdrożenie • Wczesna kompresja wewnątrz ViT, zapożyczona z LLaVA-UHD v4 — tokeny wizualne są przycinane wewnątrz enkodera wizji, a nie po nim, co właśnie sprawia, że ścieżka 4× jest w ogóle opłacalna • Dzielenie na kafelki — obrazy o wysokiej rozdzielczości są dzielone na kafelki 448×448 oraz przegląd w niskiej rozdzielczości, a liczba kafelków jest parametrem czasu wykonania (karta zaleca 36 dla obrazów, 1 dla wideo) • Próbkowanie wideo — max_num_frames domyślnie wynosi 128, a stack_frames łączy podklatki w siatkę, dzięki czemu telefon radzi sobie z nagraniem ekranu bez trzymania każdej klatki w pamięci

Dla przypadku użycia z paragonem, o którym mowa w prompcie, potok przetwarzania wygląda tak: przechwycenie, skalowanie w dół do około 980 pikseli na dłuższej krawędzi, uruchomienie w trybie 4× z dużą liczbą slice'ów i zażądanie danych wyjściowych w formie strukturalnej. Ścieżka 4× przy 36 slice'ach to kosztowne ustawienie; ścieżka 16× zużywa około jednej czwartej tokenów i to przy niej telefon pozostaje responsywny. To, czy 16× wystarcza do odczytania paragonu termicznego, jest pytaniem, na które odpowiedź mogą dać tylko Twoje własne obrazy, a żaden opublikowany benchmark w karcie nie podaje dokładności OCR według trybu skalowania w dół.

Przepaść między „demo” a „app”

Trzy rzeczy stoją między działającym demo a gotową do wydania aplikacją iOS — i żadna z nich nie jest wagami modelu.

Pierwsza kwestia to pakowanie. Model jest dostarczany w formatach Transformers, GGUF, AWQ, GPTQ i int4. Tylko GGUF ma dojrzały runner uruchamiany na urządzeniu w systemie iOS — llama.cpp i pokrewne — i tylko repozytorium GGUF zawiera osobny plik projektora wizyjnego (mmproj), którego wymaga ścieżka multimodalna. Jeśli zaczniesz od checkpointu BF16, oczekując pojedynczego pliku gotowego do użycia, odkryjesz, że projektor to drugi artefakt o własnym rozmiarze.

Drugi czynnik to budżet termiczny. Model 1B generujący kilkaset tokenów to obciążenie typu burst; model 1B wykonujący OCR strony pociętej na 36 fragmentów to obciążenie ciągłe. Demonstracyjny GIF dostawcy to nagranie ekranu, a nie zapis termiczny. Żadna opublikowana w karcie wartość nie podaje utrzymywanej liczby tokenów na sekundę na jakimkolwiek telefonie, a to właśnie ta liczba decyduje o tym, czy aplikacja do skanowania wydaje się natychmiastowa przy trzecim dokumencie, czy też przy trzydziestym.

Trzeci element to reszta Twojego stosu. Wnioskowanie na urządzeniu obsługuje obraz. Nie obsługuje jednak tej części, w której uzgadniasz wyodrębniony paragon z księgą, eskalujesz niejednoznaczną pozycję do większego modelu albo przechodzisz do trybu awaryjnego, gdy telefon jest tak stary, że aplikacja odmawia załadowania wag. To jest granica, na której router zyskuje swoje miejsce, zamiast cokolwiek zastępować: OrcaRouter umieszcza ponad 200 modeli hostowanych za jednym punktem końcowym zgodnym z OpenAI przy 0% marży, przepuszczając cennik każdego dostawcy bez zmian, z automatycznym przełączaniem awaryjnym i DSL routingu do konfiguracji podstawowej i zapasowej. Ekstraktor po stronie telefonu może przekazać swoje niepewne przypadki hostowanemu modelowi wizyjnemu, a ten sam klucz obsługuje obie ścieżki. Sam MiniCPM-V 4.7 1B nie znajduje się w tym katalogu — to checkpoint, który uruchamiasz samodzielnie — więc router jest ścieżką eskalacji, a nie sposobem wywoływania tego modelu.

Wzorzec cichego wydania — i dlaczego wciąż wywołuje to zamieszanie

MiniCPM-V 4.7 pojawił się bez wydarzenia premierowego. Repozytorium 35B-A3B ukazało się 6 października 2026 r. całkowicie bez karty modelu — karta pojawiła się sześć dni później wraz z datowaną notą wydania. Model 1B poszedł tą samą drogą: najpierw repozytorium, potem dokumentacja, a przez cały czas społeczność odkrywała go sama. W tej luce relacje uzupełniane są na podstawie tego, co istnieje, dlatego wczesne artykuły opisywały model 35B MoE, a potem trzeba je było zrewidować, gdy pojawił się 1B i jego karta.

To nie jest krytyka inżynierii OpenBMB. To opis sposobu, w jaki informacje o tym modelu się rozprzestrzeniają, i dlatego twierdzenie takie jak „działa na zwykłych iPhone’ach” może rozprzestrzeniać się szybciej niż liczby dotyczące pamięci, które je uściślają. Repozytorium jest źródłem pierwotnym. Karta modelu jest źródłem pierwotnym. Zrzut ekranu aplikacji działającej na telefonie dewelopera to pojedynczy punkt danych, a nie specyfikacja.

Co konkretnie z tym zrobić

Jeśli masz Pro Maxa lub iPada. Pobierz Q8_0 GGUF oraz projektor 16×, uruchom go przez llama.cpp lub Ollama i przetestuj własne dokumenty przy obu ustawieniach downsamplingu. W ciągu jednego popołudnia uzyskasz działającą lokalną ścieżkę OCR i image-QA, a model 1B jest wystarczająco mały, by trzymać go w pamięci równolegle z innymi aplikacjami.

Jeśli masz standardowego iPhone'a. Zacznij od Q4_K_M i projektora 16×, ustaw limit liczby slice'ów na umiarkowanym poziomie i dokonuj pomiarów. Arytmetyka pamięci mówi, że powinno się zmieścić; zachowanie termiczne i jetsam przy dłuższym użytkowaniu to część, której nikt nie opublikował. Testuj na najstarszym urządzeniu, które zamierzasz obsługiwać, nie na najnowszym.

Jeśli budujesz produkt, traktuj model działający na urządzeniu jako ścieżkę szybką, a model hostowany jako ścieżkę poprawności. Eskalacja to decyzja o routingu, a wbudowanie jej od pierwszego dnia jest tańsze niż dodawanie jej po pierwszym zgłoszeniu do supportu dotyczącym paragonu, który telefon błędnie odczytał.

Twierdzenie, od którego zaczął się ten artykuł — że model multimodalny 1B działa teraz na telefonach poniżej klasy Pro Max — jest wiarygodne pod względem arytmetyki pamięci, ale niepotwierdzone w opublikowanych materiałach. To normalny stan dla tak młodego modelu i powód, by testować, a nie czekać. Wagi są objęte licencją Apache 2.0, kwantyzacje istnieją, a jedyną rzeczą, która dzieli cię od odpowiedzi, jest popołudnie z własnym sprzętem.

Najważniejsze: MiniCPM-V 4.7 1B to prawdziwy, udokumentowany model wizyjny na licencji Apache-2.0, który w wersji Q4 wraz z projektorem wizyjnym zajmuje około 1,8 GB — na tyle mało, że średniej klasy telefony są realnym celem, a nie tylko 12-gigabajtowy Pro Max. Producent nie opublikował matrycy urządzeń ani minimalnego zapotrzebowania na pamięć, a twierdzenie o „codziennym iPhonie” pochodzi z raportu dewelopera, a nie z karty modelu. Przetestuj go na własnym urządzeniu, zanim zaczniesz na nim planować.