MiniCPM LES wprowadza 35B MoE na telefony bez ograniczania ekspertów

MiniCPM twierdzi, że jego technologia harmonogramowania LES pomaga modelowi o 35 miliardach parametrów generować 20,51 tokena na sekundę na iPhone 18 Pro Max. MiniCPM LES rozwiązuje konkretną przeszkodę: wystarczająco szybkie przenoszenie wag modelu do pamięci bez ograniczania, które części modelu mogą uczestniczyć w działaniu.

To rozróżnienie ma znaczenie dla MoE, czyli mixture of experts — architektury, która aktywuje wybrane grupy parametrów zamiast wykorzystywać cały model dla każdego tokena. Oznaczenie 35B-A3B w MiniCPM-V 4.7 opisuje około 35 miliardów parametrów łącznie i 3 miliardy aktywnych parametrów. Mniejsza liczba aktywnych obliczeń nie eliminuje potrzeby przechowywania i dostępu do pozostałych wag.

Podstawowa rywalizacja toczy się między zachowaniem dynamicznego wyboru ekspertów a ograniczaniem opóźnień ładowania. Wcześniejsze badania Apple nad inferencją opartą na pamięci flash ustanowiły użyteczny punkt odniesienia: pamięć masowa może rozszerzać ograniczoną pamięć operacyjną, lecz przesyłanie danych wymaga starannego zarządzania. Wkład MiniCPM dotyczy harmonogramowania ekspertów w ramach tego szerszego problemu. Jego opublikowane wyniki również wymagają ostrożnego przypisania: najwyższa prędkość na telefonie łączy kilka optymalizacji, a „bezstratność” wymaga węższej interpretacji, niż sugeruje nagłówek.

MiniCPM LES zamienia ładowanie ekspertów w problem harmonogramowania

Istotna zmiana polega na próbie zachowania pierwotnych wyborów ekspertów przez model przy jednoczesnym skróceniu czasu oczekiwania na ich wagi.

Zespół w karcie modelu 35B opisuje podejście wdrożeniowe zachowujące routing na poziomie tokenów, czyli proces wybierający ekspertów dla każdego generowanego tokena. Raportuje również osobny wynik przekraczający 13 tokenów na sekundę na iPhone 17 Pro Max, przy wykorzystaniu około 3 GB pamięci.

Ten wcześniejszy wynik telefoniczny należy oddzielić od nowszego benchmarku iPhone 18 Pro Max. Dotyczą różnych urządzeń i udokumentowanych konfiguracji. Traktowanie ich jako wymiennych zacierałoby to, co faktycznie potwierdzają publicznie dostępne dowody.

LES oznacza Lookahead Expert Scheduling — system przewidujący, których ekspertów będzie potrzebować następna warstwa modelu. Jego celem jest wcześniejsze wykonanie pracy związanej z ładowaniem. Predykcja pomaga uporządkować obliczenia; nie zastępuje ostatecznego wyboru ekspertów przez model.

Rozważmy problem wdrożeniowy z perspektywy twórcy aplikacji. Asystent może mieć wystarczającą moc obliczeniową, aby wygenerować odpowiedź, a mimo to działać wolno, ponieważ do kolejnej operacji brakuje mu niezbędnych wag. Przyspieszenie arytmetyki niewiele zmienia, gdy arytmetyka czeka na dane.

Utrzymywanie wszystkich ekspertów w pamięci roboczej eliminuje to konkretne opóźnienie, ale wymaga większej pamięci. Przechowywanie wag w pamięci masowej ogranicza zajętość pamięci operacyjnej, lecz wprowadza pracę związaną z ładowaniem. Ograniczenie dostępnych ekspertów upraszcza dostęp, potencjalnie zmieniając jednak obliczenia prowadzące do odpowiedzi.

Proponowane przez MiniCPM rozwiązanie zachowuje dostęp do pełnej puli ekspertów i zarządza momentem dostarczania wag. Tworzy to inny cel inżynieryjny. Pytanie brzmi, czy wystarczająca ilość potrzebnych danych może dotrzeć podczas już trwających obliczeń.

Dlatego zapowiedź harmonogramowania zasługuje na uwagę wykraczającą poza nagłówek o rozmiarze modelu. Duża liczba parametrów w telefonie sama w sobie niewiele mówi o responsywności. Układ ładowania i wykonywania decyduje o tym, czy ta pojemność wspiera interaktywną aplikację.

Dla użytkowników różnica przejawia się jako ciągłość. Odpowiedź, która zaczyna generować tekst, a potem wielokrotnie się zatrzymuje, daje inne odczucie niż odpowiedź o bardziej równomiernym tempie. Średnia prędkość generowania oddaje część tego doświadczenia, ale znaczenie ma także sekwencja opóźnień.

Praktyczne znaczenie opiera się więc na środowisku wykonawczym, czyli oprogramowaniu odpowiedzialnym za uruchamianie modelu. Same wagi modelu nie mogą potwierdzić, że każda zgodna aplikacja odtworzy takie samo zachowanie. Istotne wdrożenie łączy model, układ pamięci masowej, implementację harmonogramowania i konfigurację numeryczną.

Ten połączony system jest faktycznym przedmiotem deklaracji. Dostarcza konkretnej podstawy do analizy, nie wymagając akceptacji każdego superlatywu przypisanego premierze.

Zachowanie wyboru ekspertów wywiera presję na mobilne skróty wdrożeniowe

Bezpośrednia presja dotyczy strategii wdrożeniowych, które zyskują szybkość przez zawężenie dostępnej puli ekspertów modelu.

Ograniczenie ekspertów może wydawać się atrakcyjne, gdy pamięć i czas ładowania dominują w budżecie aplikacji. Mniej dostępnych wag oznacza mniej możliwych wymagań dotyczących ładowania. Trudność polega na tym, że optymalizacja wpływająca na dostępność ekspertów może także zmienić zachowanie modelu.

Tworzy to decyzję, którą deweloperzy muszą podjąć świadomie. Czy optymalizują sposób wykonywania oryginalnego modelu, czy wdrażają zmodyfikowaną ścieżkę obliczeniową? Oba podejścia zasługują na ocenę, lecz ich deklaracje jakości wymagają innych dowodów.

System harmonogramowania obiecuje użyteczne rozdzielenie. Deweloperzy mogą badać wydajność wykonania, zachowując jednocześnie mechanizm wyboru modelu. Ułatwia to określenie, czy dana zmiana wpływa na szybkość, jakość odpowiedzi, czy na oba te aspekty.

Zmienia to również porównanie z mniejszymi modelami. Kompaktowy model, który pozostaje w pamięci, może zapewniać prostszą ścieżkę wdrożeniową. Większy model strumieniowany musi uzasadnić dodatkową złożoność pamięci masowej i środowiska wykonawczego lepszymi wynikami w istotnych zadaniach.

Żadna z tych dróg nie wygrywa wyłącznie liczbą parametrów. Aplikacja wydobywająca krótkie pole ze znanego dokumentu może bardziej skorzystać z przewidywalnego opóźnienia niż z szerszych możliwości rozumowania. System interpretujący nieznane diagramy może przywiązywać większą wagę do jakości odpowiedzi.

Są to scenariusze wdrożeniowe, a nie potwierdzone wyniki klientów MiniCPM. Pokazują, dlaczego ten sam benchmark może wspierać różne decyzje produktowe. Wartość zależy od tego, o co pytają użytkownicy i jakie błędy aplikacja może tolerować.

Porównanie historyczne również jest pouczające. Badania Apple nad inferencją opartą na pamięci flash analizowały uruchamianie modeli przekraczających dostępną pamięć roboczą poprzez selektywne ładowanie i wydajniejszy dostęp do pamięci masowej. Ich metody różnią się od LES, ale wspólnym ograniczeniem jest przesyłanie danych.

Ten precedens odpowiednio ogranicza deklarację nowości. Wykorzystanie pamięci flash do obsługi większych modeli ma ugruntowaną historię badawczą. Analizowany tu konkretny wkład dotyczy przewidywania zapotrzebowania ekspertów i koordynowania ich wykonania.

Dla zespołów tworzących sprzęt mobilny takie ujęcie kieruje uwagę na całą ścieżkę pamięci i pamięci masowej. Możliwości obliczeniowe pozostają istotne, ale wdrożenie może się zatrzymać przed osiągnięciem granic arytmetycznych. Ocena samego procesora pomija tę możliwość.

Dla zespołów aplikacyjnych rodzi to pytanie zakupowe. Urządzenie o atrakcyjnych specyfikacjach obliczeniowych nadal wymaga testów z zamierzonym środowiskiem wykonawczym i obciążeniem. Zachowanie pamięci masowej, dostępna pamięć i warunki pracy stają się częścią profilu wydajności aplikacji.

Implikacją konkurencyjną jest zatem wymóg inżynieryjny, a nie ogłoszone zwycięstwo rynkowe. Alternatywy muszą pokazać, jak równoważą jakość, responsywność i zużycie zasobów w porównywalnych warunkach. MiniCPM musi spełniać ten sam standard.

Jeśli podejście oparte na harmonogramowaniu będzie niezawodnie odtwarzalne, ograniczanie ekspertów trudniej będzie uzasadnić jako automatyczną konieczność. Pozostanie ono wyborem projektowym, którego koszt jakościowy i korzyść wydajnościowa powinny być widoczne.

Jak MiniCPM LES zachowuje routing, ukrywając opóźnienia ładowania

LES wykorzystuje predykcję do przygotowania obliczeń, podczas gdy faktyczny router nadal odpowiada za wybór ekspertów, którzy zostaną uruchomieni.

Oficjalna dokumentacja harmonogramowania ekspertów opisuje predykcję międzywarstwową, po której następuje prefetching, czyli ładowanie prawdopodobnie potrzebnych wag, zanim wykonanie do nich dotrze. Eksperci poprawnie przewidziani są uruchamiani jako pierwsi. Pozostali wymagani eksperci ładują się równolegle z tymi obliczeniami.

Błędna predykcja powoduje więc dodatkowe oczekiwanie, a nie pozwolenie na pominięcie wymaganego eksperta. To rozróżnienie wyjaśnia deklarację zespołu dotyczącą bezstratnego harmonogramowania. Dotyczy ona zachowania udziału ekspertów, zamiast zakładać, że predykcje zawsze odpowiadają ostatecznemu wyborowi.

Dokumentacja opisuje także ciągłe rozmieszczanie wag, ograniczanie rozproszonych odczytów oraz stosowanie mieszanej precyzji specyficznej dla warstw. Kwantyzacja, czyli reprezentowanie wag przy ograniczonej precyzji numerycznej, zmniejsza wymagania dotyczące pamięci masowej i transferu. Zmiany te dotyczą różnych części problemu ładowania.

Mechanizm sugeruje kilka użytecznych implikacji, choć wymagają one pomiaru w rzeczywistych wdrożeniach. Sama dokładność predykcji nie może określić całkowitej korzyści. Trafna predykcja, która nadejdzie zbyt późno, może skrócić czas oczekiwania tylko w niewielkim stopniu.

Podobnie wczesne załadowanie właściwych wag pomaga tylko wtedy, gdy urządzenie może nakładać użyteczną pracę. Jeśli ograniczeniem staje się inny zasób, ten sam harmonogramista może przynieść inną korzyść. Wydajność należy do całego środowiska wykonawczego.

Błędne predykcje również zasługują na uwagę. Prefetching czegoś niepotrzebnego zużywa zasoby, nawet jeśli nie zmienia wyboru ekspertów. Istotne pytanie brzmi, czy uniknięte opóźnienia przeważają nad tą dodatkową pracą w reprezentatywnych zapytaniach.

Czyni to dobór obciążeń kluczowym elementem oceny. Benchmark powinien ujawniać sytuacje, w których harmonogramowanie działa dobrze, oraz takie, w których napotyka trudności. Średnia bez tego rozkładu może ukrywać wzorce ważne dla niezawodności aplikacji.

Przykładowo asystent dokumentowy może podczas jednej sesji napotkać znane układy, a podczas innej nietypowe struktury wizualne. Osoby oceniające powinny sprawdzić, czy takie zmiany wpływają na responsywność. Mechanizm daje im powód, by o to zapytać; nie ustala odpowiedzi.

Podejście to rozdziela również dwie predykcje, które czytelnicy mogą łatwo pomylić. Prefetching ekspertów przewiduje, których wag będzie wymagać nadchodzące obliczenie. Dekodowanie spekulatywne, które przygotowuje kandydackie tokeny wyjściowe do późniejszej weryfikacji, dotyczy samego procesu generowania.

MiniCPM integruje DSpark jako komponent spekulatywny. Tworzy to kolejną możliwość zwiększenia przepustowości, ale zarazem zwiększa wagę właściwego przypisania. Przyspieszenie szeroko przypisywane LES może obejmować wkład harmonogramowania, dostępu do pamięci masowej, reprezentacji numerycznej i tworzenia tokenów.

Dla deweloperów przewaga koncepcyjna jest wystarczająco jasna, by ją testować. Zachowaj wymaganą pracę, a następnie przeorganizuj przygotowanie i wykonanie, aby ograniczyć czas bezczynności. Praktycznym wyzwaniem jest uczynienie tej reorganizacji korzystną w rzeczywistych ograniczeniach urządzenia.

To mocniejsza i bardziej konkretna propozycja niż twierdzenie, że duży model po prostu mieści się w niewielkim przydziale pamięci. Wskazuje czas oczekiwania, na który celuje implementacja, oraz zachowanie modelu, które według deklaracji zachowuje.

Wynik 20,51 tokena łączy kilka optymalizacji

Opublikowany wynik na telefonie należy przypisać całemu stosowi optymalizacji, a nie wyłącznie harmonogramowaniu lookahead.

Benchmarki na urządzeniach OpenBMB wymieniają iPhone’a 18 Pro Max z 12 GB pamięci urządzenia. Szczegółowe wyniki zaczynają się od 3,38 tokena na sekundę dla wartości bazowej. Harmonogramowanie lookahead osiąga 6,57; dodatkowe zmiany w harmonogramowaniu i ładowaniu podnoszą wynik do 11,34.

Kwantyzacja o mieszanej precyzji podnosi raportowany wynik do 17,16 tokena na sekundę. Dodanie DSpark zwiększa go do 20,51, czyli 6,07 raza względem wartości bazowej. Odpowiadający mu w pełni zoptymalizowany wynik dla iPad Pro M4 wynosi 17,39 tokena na sekundę.

Liczby te wspierają konkretną interpretację: na rezultat wpływa wiele etapów. Nie uzasadniają opisywania całego przyspieszenia jako odizolowanego efektu przewidywania ekspertów. Deweloperzy próbujący odtworzyć wynik z nagłówka potrzebują odpowiedniej konfiguracji dla każdego etapu.

Wartość bazowa zasługuje na równie wnikliwą analizę. Porównanie z implementacją bez tych optymalizacji pokazuje poprawę względem tej implementacji. Nie dowodzi automatycznie przewagi nad każdym alternatywnym środowiskiem uruchomieniowym czy sposobem wdrożenia.

To częsty problem interpretacyjny w benchmarkach systemowych. Duży względny wzrost może współistnieć z niewysokim punktem wyjścia. Czytelnicy potrzebują zarówno wyniku bezwzględnego, jak i jasnego opisu tego, co się zmieniło.

Całkowita pamięć telefonu odpowiada też na inne pytanie niż zgłoszone zużycie pamięci roboczej przez model. Pojemność urządzenia opisuje środowisko sprzętowe. Pamięć aplikacji opisuje zasoby zużywane w tym środowisku, zależnie od metody pomiaru.

Trwała pamięć masowa dodaje kolejny wymiar. Oficjalne skwantyzowane pliki modelu wskazują wariant Q4_K_M o rozmiarze 21,2 GB. To zestawienie pokazuje, dlaczego deklaracji o niewielkim zużyciu pamięci rezydentnej nie należy odczytywać jako równie małego pobrania.

Lista plików nie potwierdza, że dokładnie ten artefakt wygenerował każdy opublikowany benchmark. Nadal konieczne jest dopasowanie benchmarku do precyzyjnych plików wag. W przeciwnym razie deweloperzy ryzykują porównywanie różnych reprezentacji numerycznych pod tą samą nazwą modelu.

To rozróżnienie ma bezpośrednie konsekwencje produktowe. Aplikacja mobilna musi uwzględniać instalację, aktualizacje modelu, dostępną przestrzeń dyskową i zachowanie przy uruchamianiu. Konfiguracja, która sprawnie generuje odpowiedzi po przygotowaniu, nadal musi zapewniać akceptowalne doświadczenie przed rozpoczęciem generowania.

Szybkość dekodowania mierzy generowanie wyjścia, gdy dekodowanie już trwa. Nie należy traktować jej jako pełnego czasu między przesłaniem obrazu a otrzymaniem użytecznej odpowiedzi. Obsługa wejścia i przygotowanie wymagają własnych pomiarów.

Podobnie tokeny są jednostkami używanymi przez model, a nie stałą liczbą angielskich słów. Wartość przepustowości zapewnia porównanie techniczne w określonych warunkach. Nie przekłada się bezpośrednio na uniwersalne doświadczenie czytania lub mówienia.

Raportowany wynik jest zatem istotny, lecz ograniczony. Pokazuje, co według zespołu osiąga jego łączona implementacja na wskazanym sprzęcie. Niezależne testy powinny określić, na ile wynik ten przenosi się na realistyczne sesje aplikacji.

„Bezstratność” wymaga zdefiniowanego punktu odniesienia

Zachowanie routingu ekspertów wspiera wąskie twierdzenie techniczne; nie dowodzi identycznego zachowania przy każdym ustawieniu precyzji, zadaniu i urządzeniu.

Najsilniejsza interpretacja opisu harmonogramowania dotyczy wyboru. Wymagani eksperci pozostają dostępni, a błędna predykcja nie usuwa ich z obliczeń. Ta właściwość ogranicza konkretne ryzyko jakościowe wprowadzone przez zawężenie dostępnej puli ekspertów.

Kompletne wdrożenie mobilne rodzi dodatkowe pytania. Kwantyzacja zmienia reprezentację wag. Właściwe porównanie jakości musi więc wskazywać, który model referencyjny i która konfiguracja numeryczna definiują punkt odniesienia.

Twierdzenie o zachowaniu routingu nie powinno po cichu przekształcać się w twierdzenie o zgodności każdego wyniku z modelem o wyższej precyzji. Te stwierdzenia dotyczą różnych właściwości. Osoby oceniające potrzebują dowodów odpowiednich dla każdej z nich.

Podobnie zachowanie procedury generowania nie dowodzi, że jej odpowiedzi są poprawne. Model może działać zgodnie z założeniami, a mimo to błędnie odczytać wykres, nie zrozumieć prośby lub wymyślić szczegół. Wierność działania środowiska uruchomieniowego i trafność zadań wymagają osobnej oceny.

W źródłach przeanalizowanych na potrzeby tej analizy nie znaleziono niezależnego odtworzenia głównego benchmarku telefonu. To ograniczenie nie unieważnia raportowanego wyniku. Określa, z jaką pewnością czytelnicy powinni go uogólniać.

Ta sama ostrożność dotyczy określenia „pierwszy” użytego przez firmę. Ustalenie pierwszeństwa wymaga zdefiniowanego zbioru porównawczego i spójnych definicji. Terminy takie jak płynny, czasu rzeczywistego i bezstratny potrzebują mierzalnych granic, zanim będą mogły uzasadniać uniwersalny ranking.

Działanie w czasie rzeczywistym szczególnie zależy od aplikacji. Strumieniowana odpowiedź tekstowa może tolerować opóźnienia, które zakłóciłyby interakcję na żywo. Techniczny próg przepustowości nie może potwierdzić przydatności dla każdego interfejsu.

Dłuższe sesje wprowadzają kolejny ważny test. Osoby oceniające powinny mierzyć powtarzane żądania, zmieniające się warunki urządzenia i konkurencyjną aktywność aplikacji. Są to pytania o trwałość operacyjną, a nie dowody, że raportowana implementacja musi się pogarszać.

Testy jakości odpowiedzi powinny obejmować błędy rozpoznawalne dla użytkowników. W hipotetycznym procesie obsługi wydatków oznacza to sprawdzenie, czy wyodrębnione pozycje odpowiadają paragonowi. W analizie dokumentów oznacza to sprawdzenie, czy wyjaśnienia pozostają oparte na dostarczonej stronie.

Szerszy przepływ pracy z wiedzą dodaje wyszukiwanie, czyli proces wybierania istotnych zapisanych materiałów do odpowiedzi. Czytelnicy porównujący osobiste bazy wiedzy powinni oceniać tę warstwę niezależnie od szybkości generowania modelu. Szybsze wyjście nie zrekompensuje wyboru niewłaściwego dokumentu źródłowego.

Lokalne wykonywanie również wymaga ostrożnej interpretacji. Oferuje opcję wdrożenia do przetwarzania danych wejściowych na urządzeniu, ale nie opisuje każdego przepływu danych w gotowej aplikacji. Architektura aplikacji określa, co pozostaje lokalne.

Te rozróżnienia wzmacniają analizę, ponieważ czynią twierdzenia testowalnymi. Pytanie nie brzmi już, czy „bezstratna mobilna AI” wydaje się wiarygodna. Chodzi o to, które zachowanie pozostaje niezmienione, jakie zasoby zużywa system i które pomiary wykazują rezultat.

MiniCPM LES przedstawia deweloperom konkretną propozycję harmonogramowania do zbadania. Akceptacja powinna nastąpić po uzyskaniu odtwarzalnych wyników i sprawdzeniu jakości na poziomie aplikacji, przy czym każdy wniosek powinien być powiązany z faktycznie zmierzoną właściwością.

Trzy sygnały pokażą, czy podejście przenosi się do produktów

Kolejne dowody powinny łączyć odtwarzalność, długotrwałe użycie i dostępność implementacji — w tej kolejności.

Pierwszym sygnałem jest niezależne odtworzenie z możliwymi do zidentyfikowania artefaktami i ustawieniami. W ciągu najbliższych miesięcy użyteczny wynik powinien obejmować dokładne pliki modelu, rewizję środowiska uruchomieniowego, prompty i granice pomiaru. Te szczegóły pozwoliłyby innym deweloperom zbadać to samo twierdzenie.

Odtworzenie powinno raportować więcej niż najlepszy przebieg. Zmienność między żądaniami ma znaczenie, gdy zespoły planują interaktywną usługę. Spójne wyniki zwiększyłyby pewność, że opublikowana szybkość reprezentuje użyteczną konfigurację.

Niższy wynik wymagałby interpretacji, a nie natychmiastowego odrzucenia. Różne pliki wag lub ustawienia mogłyby wyjaśniać rozbieżność. Odtwarzalna niezgodność przy dopasowanych warunkach bardziej bezpośrednio podważałaby pierwotne twierdzenie dotyczące wydajności.

Drugim sygnałem są długotrwałe testy na reprezentatywnych obciążeniach. Osoby oceniające powinny śledzić kompletne żądania od przesłania wejścia do zakończenia odpowiedzi. Powinny też sprawdzać jakość obok responsywności, ponieważ szybsze niepoprawne wyniki mają niewielką wartość produktową.

To właśnie tutaj mobilne wnioskowanie MoE przechodzi od demonstracji technicznej do decyzji aplikacyjnej. Użyteczna ocena pokazałaby, czy korzyści utrzymują się podczas powtarzanych żądań dotyczących dokumentów lub obrazów. Wskazałaby również warunki, w których mniejszy model rezydentny pozostaje preferowany.

Wyniki między urządzeniami wyjaśniłyby zakres zastosowania. Podobne zachowanie na dodatkowym sprzęcie wspierałoby szerszą przydatność. Wyniki skupione na wąskiej konfiguracji wskazywałyby na bardziej wyspecjalizowaną możliwość wdrożenia.

Trzecim sygnałem jest dostępna integracja wymaganego stosu optymalizacji. Deweloperzy potrzebują jasnej ścieżki od opublikowanych wag do implementacji stojącej za benchmarkiem. Dokumentacja powinna jednoznacznie wskazywać konieczne wybory dotyczące środowiska uruchomieniowego i artefaktów.

Ta dostępność ma znaczenie, ponieważ kompatybilność i równoważna wydajność to odrębne osiągnięcia. Załadowanie obsługiwanego modelu nie gwarantuje, że aplikacja włącza każdą optymalizację harmonogramowania i pamięci masowej. Odtworzenie kompletnej konfiguracji jest właściwym kamieniem milowym.

Jasna integracja wzmocniłaby argument, że jest to infrastruktura wielokrotnego użytku dla aplikacji mobilnych. Rozproszone instrukcje lub wyniki zależne od konfiguracji utrudniłyby wdrożenie, nawet gdyby podstawowa technika pozostała solidna.

Dla zespołów rozważających pilotaż odpowiednim następnym krokiem jest ograniczona ocena z wykorzystaniem materiałów przypominających rzeczywiste żądania użytkowników. Uwzględnij trudne dokumenty i kłopotliwe obrazy, które pokażą, czy dodatkowa pojemność modelu poprawia odpowiedź. Mierz czas oczekiwania użytkowników, obok wykorzystania zasobów i poprawności. Zachowaj stałą konfigurację referencyjną podczas oceny każdej optymalizacji, aby ulepszenia pozostały możliwe do przypisania. MiniCPM LES zasługuje na uwagę, ponieważ oferuje konkretny sposób zachowania wyboru ekspertów przy ograniczeniu opóźnień ładowania. Przed budowaniem rozwiązania wokół szybkości z nagłówka zapytaj, czy ta sama konfiguracja zapewnia wiarygodne odpowiedzi w całym planowanym mobilnym przepływie pracy.