MiniCPM LES porta MoE da 35B sui telefoni senza limitare gli esperti

MiniCPM afferma che la sua tecnologia di pianificazione LES aiuta un modello da 35 miliardi di parametri a generare 20,51 token al secondo su un iPhone 18 Pro Max. MiniCPM LES affronta un ostacolo specifico: trasferire i pesi del modello in memoria abbastanza rapidamente senza limitare quali parti del modello possano partecipare.

Questa distinzione è importante per MoE, o mixture of experts, un'architettura che attiva gruppi selezionati di parametri invece di utilizzare l'intero modello per ogni token. La denominazione 35B-A3B di MiniCPM-V 4.7 descrive approssimativamente 35 miliardi di parametri totali e 3 miliardi di parametri attivi. Una minore computazione attiva non elimina la necessità di archiviare e accedere ai pesi rimanenti.

La sfida di fondo è tra preservare la selezione dinamica degli esperti e ridurre i ritardi di caricamento. La precedente ricerca di Apple sull'inferenza basata su flash ha stabilito un utile punto di riferimento: lo storage può estendere la memoria limitata, ma il movimento dei dati richiede una gestione attenta. Il contributo di MiniCPM riguarda la pianificazione degli esperti all'interno di questo problema più ampio. Anche i suoi risultati pubblicati richiedono un'attribuzione accurata: la massima velocità su telefono combina diverse ottimizzazioni, e “lossless” necessita di un'interpretazione più circoscritta di quanto suggerisca il titolo.

MiniCPM LES trasforma il caricamento degli esperti in un problema di pianificazione

Il cambiamento significativo è il tentativo di preservare le scelte originali degli esperti del modello riducendo al contempo il tempo trascorso ad attendere i relativi pesi.

La scheda del modello 35B del team descrive un approccio di deployment che mantiene il routing a livello di token, il processo che seleziona gli esperti per ciascun token generato. Riporta inoltre un risultato separato di oltre 13 token al secondo su un iPhone 17 Pro Max, utilizzando circa 3 GB di memoria.

Quel precedente risultato su telefono dovrebbe rimanere distinto dal benchmark più recente su iPhone 18 Pro Max. Riguardano dispositivi e configurazioni documentate differenti. Trattarli come intercambiabili oscurerebbe ciò che le evidenze pubbliche effettivamente dimostrano.

LES significa Lookahead Expert Scheduling, un sistema che anticipa quali esperti saranno necessari al livello successivo del modello. Il suo scopo è anticipare il lavoro di caricamento. La previsione aiuta a organizzare il calcolo; non sostituisce la selezione finale degli esperti effettuata dal modello.

Consideriamo il problema di deployment dalla prospettiva di uno sviluppatore di applicazioni. Un assistente può avere capacità computazionale sufficiente per generare una risposta e restare comunque lento perché la sua operazione successiva non dispone dei pesi necessari. Rendere più veloce l'aritmetica serve a poco quando l'aritmetica attende i dati.

Mantenere ogni esperto nella memoria di lavoro evita quel particolare ritardo, ma richiede più memoria. Conservare i pesi nello storage riduce l'impronta residente, ma introduce lavoro di caricamento. Limitare gli esperti disponibili semplifica l'accesso, modificando potenzialmente il calcolo che produce la risposta.

Il percorso proposto da MiniCPM preserva l'accesso all'intero pool di esperti e gestisce il momento in cui arrivano i pesi. Ciò crea un diverso obiettivo ingegneristico. La questione diventa se una quantità sufficiente di dati necessari possa arrivare durante il calcolo già in corso.

Ecco perché l'annuncio sulla pianificazione merita attenzione oltre il titolo sulla dimensione del modello. Un elevato numero di parametri su un telefono dice poco, da solo, sulla reattività. L'organizzazione di caricamento ed esecuzione determina se tale capacità supporta un'applicazione interattiva.

Per gli utenti, la distinzione si manifesta come continuità. Una risposta che inizia a produrre testo e poi si ferma ripetutamente appare diversa da una risposta con un output più costante. La velocità media di generazione coglie una parte di questa esperienza, ma conta anche la sequenza dei ritardi.

Il significato pratico si basa quindi sul runtime, il software responsabile dell'esecuzione del modello. I soli pesi del modello non possono dimostrare che ogni applicazione compatibile riproduca lo stesso comportamento. Il deployment rilevante combina il modello, l'organizzazione dello storage, l'implementazione della pianificazione e la configurazione numerica.

Questo sistema combinato è l'effettivo oggetto dell'affermazione. Fornisce una base concreta per l'indagine senza richiedere di accettare ogni superlativo associato al rilascio.

Preservare la scelta degli esperti mette sotto pressione le scorciatoie del deployment mobile

La pressione immediata ricade sulle strategie di deployment che guadagnano velocità restringendo il pool di esperti disponibili al modello.

Una restrizione degli esperti può apparire interessante quando memoria e tempi di caricamento dominano il budget di un'applicazione. Un minor numero di pesi disponibili implica meno possibili necessità di caricamento. La difficoltà è che un'ottimizzazione che influenza la disponibilità degli esperti può influenzare anche il comportamento del modello.

Questo crea una decisione che gli sviluppatori devono prendere esplicitamente. Stanno ottimizzando il modo in cui viene eseguito il modello originale o stanno distribuendo un percorso computazionale modificato? Entrambi gli approcci meritano valutazione, ma le loro affermazioni sulla qualità richiedono evidenze diverse.

Un sistema di pianificazione promette una separazione utile. Gli sviluppatori possono indagare l'efficienza di esecuzione mantenendo intatto il meccanismo di selezione del modello. Ciò rende più semplice individuare se una modifica influisce sulla velocità, sulla qualità delle risposte o su entrambe.

Cambia anche il confronto con modelli più piccoli. Un modello compatto che resta in memoria può offrire un percorso di deployment più semplice. Un modello più grande in streaming deve giustificare la maggiore complessità di storage e runtime attraverso risultati migliori su attività rilevanti.

Nessuno dei due percorsi vince in base al solo numero di parametri. Un'applicazione che estrae un breve campo da un documento familiare potrebbe trarre più vantaggio da una latenza prevedibile che da una maggiore capacità di ragionamento. Un sistema che interpreta diagrammi non familiari potrebbe attribuire maggior peso alla qualità delle risposte.

Si tratta di scenari di deployment, non di risultati verificati presso i clienti per MiniCPM. Illustrano perché lo stesso benchmark possa supportare decisioni di prodotto differenti. Il valore dipende da ciò che gli utenti chiedono e dai fallimenti che l'applicazione può tollerare.

Anche il confronto storico è istruttivo. La ricerca di Apple sull'inferenza basata su flash ha esaminato l'esecuzione di modelli oltre la memoria di lavoro disponibile mediante caricamento selettivo e accesso allo storage più efficiente. I suoi metodi differiscono da LES, ma il vincolo condiviso è il movimento dei dati.

Questo precedente circoscrive adeguatamente la pretesa di novità. L'uso dello storage flash per supportare modelli più grandi ha una storia di ricerca consolidata. Il contributo specifico in esame riguarda l'anticipazione dei requisiti degli esperti e il coordinamento della loro esecuzione.

Per i team che si occupano di hardware mobile, questa impostazione reindirizza l'attenzione verso l'intero percorso di memoria e storage. La capacità di calcolo resta rilevante, ma un deployment può bloccarsi prima di raggiungere i propri limiti aritmetici. Valutare il processore isolatamente trascura questa possibilità.

Per i team applicativi, pone una domanda di approvvigionamento. Un dispositivo con specifiche computazionali interessanti richiede comunque test rispetto al runtime e al carico di lavoro previsti. Il comportamento dello storage, la memoria disponibile e le condizioni operative diventano parte del profilo prestazionale dell'applicazione.

L'implicazione competitiva è quindi una richiesta ingegneristica, non una vittoria di mercato dichiarata. Le alternative devono mostrare come bilanciano qualità, reattività e uso delle risorse in condizioni comparabili. MiniCPM deve soddisfare lo stesso standard.

Se l'approccio di pianificazione si riproduce in modo affidabile, la restrizione degli esperti diventa più difficile da giustificare come necessità automatica. Resta una scelta progettuale il cui costo in termini di qualità e beneficio prestazionale dovrebbero essere visibili.

Come MiniCPM LES preserva il routing nascondendo i ritardi di caricamento

LES usa la previsione per preparare il calcolo, mentre il router effettivo resta responsabile della selezione degli esperti che vengono eseguiti.

La documentazione ufficiale sulla pianificazione degli esperti descrive una previsione cross-layer seguita dal prefetching, che carica i pesi probabilmente necessari prima che l'esecuzione li raggiunga. Gli esperti previsti correttamente vengono eseguiti per primi. Altri esperti richiesti vengono caricati parallelamente a quel calcolo.

Una previsione mancata crea quindi un'attesa aggiuntiva anziché l'autorizzazione a saltare un esperto necessario. Questa distinzione spiega l'affermazione del team sulla pianificazione lossless. Riguarda la preservazione della partecipazione degli esperti, anziché presumere che le previsioni corrispondano sempre alla selezione finale.

La documentazione descrive anche l'organizzazione contigua dei pesi, la riduzione delle letture disperse e l'applicazione di precisione mista specifica per livello. La quantizzazione, ovvero la rappresentazione dei pesi con precisione numerica ridotta, diminuisce le esigenze di storage e trasferimento. Queste modifiche affrontano parti diverse del problema di caricamento.

Il meccanismo suggerisce diverse implicazioni utili, sebbene richiedano misurazioni su deployment effettivi. La sola accuratezza della previsione non può determinare il beneficio totale. Una previsione corretta che arriva troppo tardi potrebbe far risparmiare poco tempo di attesa.

Allo stesso modo, caricare anticipatamente i pesi giusti aiuta solo se il dispositivo può sovrapporre lavoro utile. Se un'altra risorsa diventa il fattore limitante, lo stesso scheduler può produrre un guadagno diverso. Le prestazioni appartengono all'intero ambiente di esecuzione.

Anche le previsioni errate meritano attenzione. Il prefetching di qualcosa di non necessario consuma risorse, anche quando lascia invariata la selezione degli esperti. La domanda utile è se i ritardi evitati superino quel lavoro aggiuntivo su richieste rappresentative.

Questo rende la selezione del carico di lavoro centrale per la valutazione. Un benchmark dovrebbe esporre situazioni in cui la pianificazione funziona bene e situazioni in cui incontra difficoltà. Una media senza questa distribuzione può nascondere schemi rilevanti per l'affidabilità dell'applicazione.

Per esempio, un assistente documentale potrebbe incontrare layout familiari durante una sessione e strutture visive insolite durante un'altra. I valutatori dovrebbero verificare se tali cambiamenti alterino la reattività. Il meccanismo offre loro un motivo per chiederselo; non stabilisce la risposta.

L'approccio separa inoltre due previsioni che i lettori possono facilmente confondere. Il prefetching degli esperti anticipa quali pesi richiederà un calcolo imminente. La decodifica speculativa, che redige token di output candidati per una verifica successiva, riguarda invece il processo di generazione stesso.

MiniCPM integra DSpark come componente speculativo. Ciò crea un'ulteriore opportunità per migliorare il throughput, ma rende anche più importante l'attribuzione. Un'accelerazione attribuita genericamente a LES può includere contributi della pianificazione, dell'accesso allo storage, della rappresentazione numerica e della generazione preliminare di token.

Per gli sviluppatori, il vantaggio concettuale è abbastanza chiaro da poter essere testato. Preservare il lavoro necessario, quindi riorganizzare preparazione ed esecuzione per ridurre il tempo inattivo. La sfida pratica consiste nel rendere tale riorganizzazione vantaggiosa entro i vincoli reali del dispositivo.

Si tratta di una proposizione più solida e specifica rispetto ad affermare che un modello grande entri semplicemente in una piccola allocazione di memoria. Identifica il tempo di attesa che l'implementazione intende ridurre e il comportamento del modello che afferma di preservare.

Il risultato di 20,51 token combina diverse ottimizzazioni

Il risultato pubblicato su telefono appartiene all'intero stack di ottimizzazione, non alla sola pianificazione lookahead.

I benchmark on-device di OpenBMB on-device benchmarks indicano l’iPhone 18 Pro Max con 12 GB di memoria del dispositivo. I risultati dettagliati partono da 3,38 token al secondo per la configurazione di base. La pianificazione lookahead raggiunge 6,57; ulteriori modifiche alla pianificazione e al caricamento arrivano a 11,34.

La quantizzazione a precisione mista porta il risultato riportato a 17,16 token al secondo. L’aggiunta di DSpark lo eleva a 20,51, ossia 6,07 volte il valore di base. Il corrispondente risultato pienamente ottimizzato su iPad Pro M4 è di 17,39 token al secondo.

Questi dati consentono un’interpretazione concreta: più fasi contribuiscono al risultato. Non giustificano la descrizione dell’intera accelerazione come effetto isolato della previsione degli esperti. Gli sviluppatori che cercano di riprodurre il dato principale hanno bisogno della configurazione pertinente per ogni fase.

Anche la configurazione di base merita lo stesso livello di esame. Un confronto con un’implementazione priva di queste ottimizzazioni dimostra un miglioramento rispetto a quella specifica implementazione. Non stabilisce automaticamente una superiorità rispetto a ogni runtime o metodo di distribuzione alternativo.

Questo è un problema interpretativo comune nei benchmark di sistemi. Un forte guadagno relativo può coesistere con un punto di partenza modesto. I lettori hanno bisogno sia del risultato assoluto sia di una descrizione chiara di ciò che è cambiato.

La memoria totale del telefono risponde inoltre a una domanda diversa rispetto all’ingombro di memoria di lavoro riportato per il modello. La capacità del dispositivo descrive l’ambiente hardware. La memoria dell’applicazione descrive le risorse consumate all’interno di quell’ambiente, in base al metodo di misurazione.

Lo storage persistente aggiunge un’ulteriore dimensione. I file ufficiali del modello quantizzato quantized model files indicano la variante Q4_K_M a 21,2 GB. Questa voce mostra perché un’affermazione su una bassa memoria residente non debba mai essere interpretata come un download altrettanto ridotto.

L’elenco dei file non dimostra che questo esatto artefatto abbia prodotto ogni benchmark pubblicato. Rimane necessario associare il benchmark ai file di pesi precisi. Altrimenti, gli sviluppatori rischiano di confrontare rappresentazioni numeriche differenti con lo stesso nome del modello.

La distinzione ha conseguenze dirette sul prodotto. Un’applicazione mobile deve gestire installazione, aggiornamenti del modello, spazio disponibile e comportamento all’avvio. Una configurazione che genera in modo efficiente dopo la preparazione deve comunque offrire un’esperienza accettabile prima che la generazione inizi.

La velocità di decoding misura la generazione dell’output una volta avviata la decodifica. Non dovrebbe essere considerata l’intervallo completo tra l’invio di un’immagine e la ricezione di una risposta utile. La gestione dell’input e la preparazione richiedono misurazioni proprie.

Allo stesso modo, i token sono unità utilizzate dal modello, non un numero fisso di parole inglesi. Un dato di throughput offre un confronto tecnico in condizioni dichiarate. Non si traduce direttamente in un’esperienza universale di lettura o conversazione.

Il risultato riportato è quindi significativo, ma circoscritto. Mostra ciò che il team afferma di raggiungere con la propria implementazione combinata su hardware nominato. Test indipendenti dovrebbero determinare in che misura tale risultato si trasferisca a sessioni applicative realistiche.

“Senza perdite” Richiede un Punto di Riferimento Definito

La preservazione dell’instradamento degli esperti sostiene un’affermazione tecnica circoscritta; non dimostra un comportamento identico in ogni impostazione di precisione, attività e dispositivo.

L’interpretazione più solida della descrizione della pianificazione riguarda la selezione. Gli esperti necessari restano idonei e un errore di previsione non li esclude dal calcolo. Questa proprietà affronta uno specifico rischio di qualità introdotto dalla limitazione del pool di esperti disponibili.

La distribuzione mobile completa solleva ulteriori domande. La quantizzazione modifica la rappresentazione dei pesi. Il confronto di qualità appropriato deve quindi identificare quale modello di riferimento e quale configurazione numerica definiscano la base di confronto.

Un’affermazione sulla preservazione dell’instradamento non dovrebbe trasformarsi implicitamente in un’affermazione di corrispondenza con ogni output di un modello a precisione superiore. Queste dichiarazioni riguardano proprietà differenti. I valutatori necessitano di prove adeguate a ciascuna di esse.

Allo stesso modo, preservare una procedura di generazione non dimostra che le sue risposte siano corrette. Un modello può essere eseguito come previsto e tuttavia interpretare male un grafico, fraintendere una richiesta o inventare un dettaglio. La fedeltà del runtime e l’accuratezza nei compiti richiedono valutazioni separate.

Nessuna riproduzione indipendente del benchmark principale sul telefono è stata accertata attraverso le fonti esaminate per questa analisi. Questa limitazione non invalida il risultato riportato. Determina il grado di sicurezza con cui i lettori dovrebbero generalizzarlo.

La stessa cautela vale per la definizione di “primo” adottata dall’azienda. Stabilire la priorità richiede un insieme di confronto definito e definizioni coerenti. Termini come fluido, in tempo reale e senza perdite necessitano di confini misurabili prima di poter sostenere una classifica universale.

Il concetto di tempo reale dipende in particolare dall’applicazione. Una risposta scritta in streaming può tollerare ritardi che interromperebbero un’interazione dal vivo. Una soglia tecnica di throughput non può stabilire l’idoneità per ogni interfaccia.

Le sessioni più lunghe introducono un altro test importante. I valutatori dovrebbero misurare richieste ripetute, condizioni variabili del dispositivo e attività concorrenti delle applicazioni. Si tratta di questioni relative alla resilienza operativa, non di prove che l’implementazione riportata si deteriori necessariamente.

I test sulla qualità delle risposte dovrebbero includere errori riconoscibili dagli utenti. In un ipotetico flusso di lavoro per le spese, ciò significa verificare se le voci estratte corrispondono alla ricevuta. Nell’analisi dei documenti, significa controllare se le spiegazioni restano basate sulla pagina fornita.

Un flusso di lavoro di conoscenza più ampio aggiunge il recupero delle informazioni, ovvero il processo di selezione del materiale archiviato rilevante per una risposta. I lettori che confrontano le basi di conoscenza personali dovrebbero valutare questo livello separatamente dalla velocità di generazione del modello. Un output più rapido non può compensare la selezione del documento sorgente sbagliato.

Anche l’esecuzione locale necessita di un’interpretazione attenta. Offre un’opzione di distribuzione per elaborare gli input sul dispositivo, ma non descrive ogni flusso di dati in un’applicazione completata. L’architettura dell’applicazione determina ciò che rimane locale.

Queste distinzioni rafforzano l’analisi rendendo le affermazioni verificabili. La domanda non è più se “l’AI mobile senza perdite” sembri plausibile. È quale comportamento resti invariato, quali risorse consumi il sistema e quali misurazioni dimostrino il risultato.

MiniCPM LES offre agli sviluppatori una proposta di pianificazione specifica da analizzare. L’accettazione dovrebbe seguire risultati riproducibili e controlli di qualità a livello applicativo, con ogni conclusione collegata alla proprietà effettivamente misurata.

Tre Segnali Mostreranno se l’Approccio si Trasferisce ai Prodotti

Le prossime prove dovrebbero collegare riproducibilità, uso prolungato e disponibilità dell’implementazione, in quest’ordine.

Il primo segnale è una riproduzione indipendente con artefatti e impostazioni identificabili. Nei prossimi mesi, il risultato utile includerebbe file di modello esatti, revisione del runtime, prompt e confini di misurazione. Questi dettagli consentirebbero ad altri sviluppatori di esaminare la stessa affermazione.

Una riproduzione dovrebbe riportare più della sua esecuzione migliore. La variazione tra le richieste conta quando i team pianificano un servizio interattivo. Risultati coerenti rafforzerebbero la fiducia che la velocità pubblicata rappresenti una configurazione utilizzabile.

Un risultato inferiore richiederebbe un’interpretazione anziché un’immediata liquidazione. File di pesi o impostazioni differenti potrebbero spiegare un divario. Una discrepanza riproducibile in condizioni corrispondenti indebolirebbe più direttamente l’affermazione originale sulle prestazioni.

Il secondo segnale è un test prolungato su carichi di lavoro rappresentativi. I valutatori dovrebbero seguire richieste complete dall’invio dell’input fino al completamento della risposta. Dovrebbero inoltre verificare la qualità insieme alla reattività, perché un output errato più rapido crea poco valore per il prodotto.

È qui che l’inferenza MoE mobile passa da dimostrazione tecnica a decisione applicativa. Una valutazione utile mostrerebbe se i vantaggi persistono durante richieste ripetute di documenti o immagini. Identificherebbe inoltre le condizioni in cui un modello residente più piccolo resta preferibile.

I risultati su più dispositivi chiarirebbero l’ambito. Un comportamento simile su hardware aggiuntivo sosterrebbe un’applicabilità più ampia. Risultati concentrati su una configurazione ristretta indicherebbero un’opportunità di distribuzione più specializzata.

Il terzo segnale è l’integrazione accessibile dello stack di ottimizzazione richiesto. Gli sviluppatori hanno bisogno di un percorso chiaro dai pesi pubblicati all’implementazione alla base del benchmark. La documentazione dovrebbe rendere inequivocabili le scelte necessarie relative a runtime e artefatti.

Questa disponibilità è importante perché compatibilità e prestazioni equivalenti sono risultati distinti. Caricare un modello supportato non garantisce che un’applicazione abiliti ogni ottimizzazione di pianificazione e storage. Riprodurre la configurazione completa è il traguardo pertinente.

Un’integrazione chiara rafforzerebbe l’idea che si tratti di un’infrastruttura riutilizzabile per applicazioni mobili. Istruzioni frammentarie o risultati dipendenti dalla configurazione renderebbero l’adozione più difficile, anche se la tecnica sottostante resta valida.

Per i team che valutano un progetto pilota, il passo successivo appropriato è una valutazione circoscritta con materiale che assomigli alle richieste reali degli utenti. Includete i documenti difficili e le immagini problematiche che rivelano se la maggiore capacità del modello migliora la risposta. Misurate il tempo di attesa percepito dagli utenti, insieme all’uso delle risorse e alla correttezza. Mantenete fissa la configurazione di riferimento mentre valutate ogni ottimizzazione, affinché i miglioramenti restino attribuibili. MiniCPM LES merita attenzione perché offre un modo concreto per preservare la scelta degli esperti riducendo al contempo i ritardi di caricamento. Prima di costruire attorno alla velocità principale, chiedetevi se quella stessa configurazione fornisca risposte affidabili lungo l’intero flusso di lavoro mobile previsto.