MiniCPM-V 4.7-35B-A3B-DSpark: 389M Draft od OpenBMB debiutuje z kartą, której nigdy nie otrzymał jego model bazowy

MiniCPM-V-4.7-35B-A3B-DSpark to model roboczy o 389 223 169 parametrach. Nie odpowiada na pytania, nie widzi obrazów, a sam w sobie jest bezużyteczny. Jego całym zadaniem jest odgadywanie kolejnych piętnastu tokenów, aby MiniCPM-V-4.7-35B-A3B mógł zweryfikować cały blok w jednym przebiegu w przód, zamiast generować po jednym tokenie naraz. To dekodowanie spekulatywne, a OpenBMB udostępniło model roboczy dla swojego nowego 35B modelu wizyjno-językowego jedenaście dni temu, nie mówiąc o tym publicznie ani słowa.

To, co czyni go wartym artykułu, to nie sam model roboczy. To dokumentacja, która przyszła razem z nim. Checkpoint DSpark ma kartę modelu: licencję, tabelę specyfikacji, przepis treningowy i tabelę długości akceptacji dla siedmiu kategorii zadań. Jego nadrzędny model z 35 miliardami parametrów nie miał niczego takiego, gdy się pojawił. Tak więc po raz pierwszy do wydania MiniCPM-V 4.7 dołączono rzeczywiste liczby — i są to liczby dotyczące modelu nadrzędnego, zmierzone pośrednio przez plik o rozmiarze 0,78 GB, którego deklarowanym celem jest sprawić, by działał szybciej.

Wszystko poniżej rozdziela to, co znajduje się na karcie, od tego, czego karta nie ustala. Dane akceptacyjne pochodzą od samego OpenBMB i nikt spoza laboratorium ich nie odtworzył. Tabela wyników benchmarku modelu bazowego nadal nie istnieje.

Czym tak naprawdę jest punkt kontrolny DSpark

Repozytorium openbmb/MiniCPM-V-4.7-35B-A3B-DSpark pochodzi z 8 października 2026 r. To jednoplikowy checkpoint — model.safetensors, a także config.json i README — na licencji Apache-2.0, oznaczony tagami dla języka angielskiego i chińskiego. Drugi szkic, openbmb/MiniCPM-V-4.7-1B-DSpark, utworzono o jedną sekundę wcześniej, więc oba zostały wypchnięte do huba w tej samej partii, a nie odkryte jedno po drugim.

Każdy draft znajduje się przed jednym modelem docelowym i tylko przed nim. Karta mówi to wprost: ten checkpoint jest „trenowany do dokładnego parowania z MiniCPM-V-4.7-35B-A3B i jego tokenizatorem”. Słownik należy do modelu nadrzędnego — wszystkie 248 144 tokeny — co jest wymogiem, a nie optymalizacją; model draftujący, którego tokeny nie mapują się jeden do jednego na tokeny modelu docelowego, nie może zaproponować niczego, co model docelowy mógłby zaakceptować. To samo ograniczenie jest powodem, dla którego siostrzany draft istnieje osobno, zamiast jednego modelu draftującego obsługującego całą rodzinę.

Architektura nie jest mniejszą kopią modelu nadrzędnego. To pięciowarstwowy stos uwagi, szerokość ukryta 2048, 8 głowic zapytań względem 2 głowic klucza/wartości, rozmiar pośredni 6144 oraz RoPE z wartością theta równą 10 000 000. Polearchitectures zawiera Qwen3DSparkModel — ten sam szkielet z rodziny Qwen3, z którego pochodzi stos językowy modelu nadrzędnego, zredukowany do zaślepki.

Najciekawsze jest to, jak stub komunikuje się z targetem. Nie czyta końcowej warstwy targetu. Pobiera stany ukryte z pięciu pośrednich warstw — [3, 11, 19, 27, 35] z 40 warstw rodzica — i rzutuje je przez dspark-owy projektor. Pobieranie ze środka stosu, a nie z końca, jest celowe: stany ze środka sieci są tańsze w dopasowaniu i niosą informacje, które końcowa warstwa już skompresowała do logitów następnego tokenu. Konfiguracja uzbraja też głowicę pewności ze składnikiem Markowa rzędu 256, czyli mechanizm z artykułu DSpark służący do decydowania, jak duża część proponowanego bloku jest warta weryfikacji.

Tabela akceptacji to karta, a nie pomiar.

Oto wszystkie dane liczbowe, które OpenBMB opublikowało na temat tego, jak dobrze działa ta para, wyrażone jako akceptowane tokeny na krok weryfikacji, z naturalnym zakończeniem EOS i max_new_tokens=8192:

• Vision, MMMU — 5,098 akceptowanych tokenów na krok.

• Vision, MathVista — 6,126.

• Vision, rozumowanie CharXiv (walidacja) — 5.479.

• Wizja, OCRBench — 5,407.

• Tekst, Matematyka — 6,687.

• Tekst, Kod — 7.387.

• Tekst, ogólne — 3.501.

Trzy rzeczy w tej tabeli warto powiedzieć wprost. Po pierwsze, jest ona samodzielnie raportowana. Nikt spoza OpenBMB nie uruchomił tego checkpointu i nie podał liczby, a przy jednym odnotowanym pobraniu w repozytorium nikt spoza OpenBMB nie uruchomił go w ogóle. Po drugie, długość akceptacji jest właściwością pary, a nie modelu — mierzy ona, jak przewidywalne są wyniki MiniCPM-V-4.7-35B-A3B, a nie jak dobre są te wyniki. Model docelowy, który się powtarza, daje modelowi draftującemu łatwe zwycięstwo. Po trzecie, istotą jest rozrzut: 7,387 dla kodu wobec 3,501 dla tekstu ogólnego to dwukrotna różnica między najlepszą i najgorszą kategorią, a fakt, że kod jest najłatwiejszy, odzwierciedla jego niskoentropijną, wysoce powtarzalną powierzchnię bardziej niż jakąkolwiek siłę samych modeli.

Jest też czysto arytmetyczna interpretacja, którą karta pozostawia w domyśle. Model szkicujący, który proponuje 15 tokenów, a od 5 do 7 z nich zostaje zaakceptowanych, wciąż przesuwa kilka tokenów na każde przejście w przód modelu docelowego, więc górna granica to tutaj duży wzrost przepustowości — ale to nie jest naiwne twierdzenie o „5× szybciej”, ponieważ weryfikacja bloku 15 tokenów kosztuje więcej niż wygenerowanie jednego tokena, a za odrzucone propozycje się płaci i wyrzuca się je. Ta luka jest dokładnie tym, o czym jest artykuł DSpark, i dlatego konfiguracja udostępnia przełącznik do wyłączenia adaptacyjnej weryfikacji.

Co szkic przypadkowo mówi nam o modelu bazowym

MiniCPM-V 4.7 określił swoje wydanie jako cicho wypuszczone — wagi, bez wpisu premierowego. To się teraz zmieniło, w niewielki, ale realny sposób. Repozytorium nadrzędne pod adresem openbmb/MiniCPM-V-4.7-35B-A3B zostało utworzone 7 października 2026. Do 12 października zawierało pełną kartę modelu z README, stroną wydania w stylu Hugging Face, listą deklaracji, sekcją dotyczącą działania na urządzeniu i tabelą wag. Od tego czasu repozytorium rozrosło się o rodzinę kwantyzacji — wersje FP8, int4, AWQ, GPTQ i GGUF, każda we własnym repozytorium, wszystkie dotknięte 12 października — oraz 27 polubień przy 166 pobraniach.

Więc dokładny obraz to wydanie dwuetapowe, a nie ciche. Wagi pojawiły się 6 i 7 października. Wersje robocze checkpointów przyszły 8 października. Dokumentacja, wersje skwantyzowane i historia działania na urządzeniu dotarły do 12 października. OpenBMB nadal nie opublikowało wpisu na blogu ani raportu technicznego dla tej rodziny, a na karcie nadrzędnej nadal nie ma tabeli wyników — twierdzenia o wydajności znajdują się w podlinkowanych obrazach wykresów, a nie jako tekst, który czytelnik mógłby zacytować.

Twierdzenie, które rzeczywiście pojawia się w tekście, jest tym głównym: dzięki Lookahead Expert Scheduling, kwantyzacji warstwowej i „integracji próbkowania spekulacyjnego DSpark” model 35B-A3B jest opisywany jako pierwszy model MoE typu open source, który działa płynnie na urządzeniu, z szybkością ponad 13 tokenów na sekundę na iPhone 17 Pro Max. Ta liczba została podana przez producenta, nie została odtworzona i nie jest poparta żadnymi szczegółami — brak formatu kwantyzacji, brak buildu, brak promptu, brak metody pomiaru. Checkpoint DSpark to jedna z trzech technik, na których opiera się to twierdzenie, co sprawia, że jest to jedyna z trzech, którą można pobrać i sprawdzić. Jest to również ta, której dowodem jest pojedynczy nieodczytany wiersz benchmarku na zadanie.

Uruchom to, jeśli chcesz.

Karta zawiera jeden przepis i jest to polecenie vLLM, a nie ogólniki. Uruchamia model docelowy z rozmiarem tensor-parallel równym 2, maksymalną długością modelu 40 960, FLASH_ATTN w backendach uwagi zarówno języka, jak i enkodera multimodalnego, trybem podpróbkowania wizualnego 4x, enable_thinkingustawionym na false oraz konfiguracją spekulatywną wskazującą na checkpoint DSpark z 15 tokenami spekulatywnymi i wyłączoną weryfikacją adaptacyjną. Dwa szczegóły w tej linii zasługują na osobną uwagę: --max-num-seqs 1 oznacza, że opublikowana konfiguracja obsługuje jedną sekwencję naraz, a --disable-custom-all-reduce z wyłączonym przebiegiem fuzji all-reduce oznacza, że to konfiguracja dostrojona tak, by działać, a nie by być maksymalnie szybka. Traktuj przepis jako punkt wyjścia, który OpenBMB uruchomił, a nie jako deklarację przepustowości.

Ograniczenia sprzętowe są prawdziwą barierą. Celem jest około 70 GB wag BF16 przed pamięcią podręczną KV, a draft dokłada do tego około 0,78 GB. Dwa akceleratory to podane minimum, co znacznie wykracza poza możliwości telefonu, na którym opiera się marketing rodziny — wdrożenie na urządzeniu dla modelu 35B-A3B oznacza agresywną kwantyzację i offloading, do czego właśnie służą prace nad LES i kwantyzacją warstwową, a ani LES, ani kwantyzacji warstwowej nie ma w powyższym przepisie vLLM.

Ta asymetria jest praktyczną decyzją dla większości zespołów. Uruchamianie MiniCPM-V 4.7 kosztuje dwa GPU, które posiadasz; wywoływanie porównywalnego hostowanego multimodalnego MoE nie kosztuje nic z góry. Qwen3.6 35B A3B to najbliższe bezpośrednie porównanie — ten sam kształt 35B łącznie i 3B aktywnych, ten sam kontekst 262K, wejście obrazu i wideo — i jest udostępniany przez OrcaRouter od 0,248 USD za milion tokenów wejściowych i 1,485 USD za milion tokenów wyjściowych, w zależności od trasy dostawcy, z automatycznym przełączaniem awaryjnym, jeśli jedna z tych tras ulegnie degradacji. MiniCPM-V 4.7 nie jest modelem hostowanym w OrcaRouter i ten artykuł nie zamierza udawać inaczej; uczciwe ujęcie jest takie, że oba rozwiązania to alternatywy w punkcie decyzyjnym, a to hostowane jest tym, które możesz zmierzyć dziś po południu.

Co uczyniłoby to sprawdzalnym?

Checkpoint DSpark jest na licencji Apache-2.0, zajmuje mniej niż gigabajt i jest dostarczany z poleceniem serwowania, które osoba z dwiema GPU mogłaby dziś wkleić do terminala. Ta kombinacja czyni go najtańszą drogą do niezależnego wyniku dla MiniCPM-V 4.7 — nie wyniku benchmarku, lecz czegoś niemal równie przydatnego: odtworzonej długości akceptacji. Jeśli podmiot zewnętrzny dorówna wartości 5,1 w MMMU i 3,5 w tekście ogólnym, karta będzie wiarygodna, a historia efektywności tej rodziny zyska swój pierwszy zewnętrzny punkt danych. Jeśli długość akceptacji okaże się istotnie niższa, opublikowana tabela została zmierzona w warunkach, których przepis nie odtwarza, a twierdzenie o 13 tokenach na sekundę odziedziczy tę wątpliwość.

Nadal brakuje tego, do czego zwykle służy karta modelu. Nie ma wyniku MMMU, wyniku OCRBench, rezultatu rozumienia dokumentów, liczby dotyczącej grounding ani wskaźnika opóźnienia dla samego MiniCPM-V 4.7 — niczego, co odpowiada na pytanie, czy ten model jest dobry. Tabela modelu szkicowego nie może tego zastąpić, a odczytywanie wysokiej długości akceptacji jako sygnału jakości to dokładnie błąd, do którego zachęcają te liczby. Przewidywanie w stylu ChatGPT jest łatwe dla modelu szkicującego i nic nie mówi o tym, czy przewidywanie było trafne.

A więc: prawdziwy artefakt, prawdziwa licencja, jeden prawdziwie nowy opublikowany dowód dotyczący modelu, który nie miał żadnego — i luka w ocenie dokładnie tak szeroka, jak była 7 października. Następnym plikiem do odświeżenia wciąż pozostaje karta modelu nadrzędnego.