MiniCPM LES lleva MoE de 35B a los teléfonos sin restringir expertos

MiniCPM afirma que su tecnología de programación LES ayuda a un modelo de 35.000 millones de parámetros a generar 20,51 tokens por segundo en un iPhone 18 Pro Max. MiniCPM LES aborda un obstáculo específico: mover los pesos del modelo a la memoria con suficiente rapidez sin restringir qué partes del modelo pueden participar.

Esa distinción es importante para MoE, o mezcla de expertos, una arquitectura que activa grupos de parámetros seleccionados en lugar de usar todo el modelo para cada token. La denominación 35B-A3B de MiniCPM-V 4.7 describe aproximadamente 35.000 millones de parámetros totales y 3.000 millones de parámetros activos. Un menor cómputo activo no elimina la necesidad de almacenar y acceder a los pesos restantes.

La cuestión de fondo enfrenta la preservación de la selección dinámica de expertos con la reducción de los retrasos de carga. La investigación previa de Apple sobre inferencia basada en flash estableció un punto de referencia útil: el almacenamiento puede ampliar una memoria limitada, pero el movimiento de datos exige una gestión cuidadosa. La contribución de MiniCPM apunta a la programación de expertos dentro de ese problema más amplio. Sus resultados publicados también requieren una atribución cautelosa: la mayor velocidad en teléfono combina varias optimizaciones, y «sin pérdida» necesita una interpretación más acotada de lo que sugiere el titular.

MiniCPM LES convierte la carga de expertos en un problema de programación

El cambio relevante es un intento de preservar las elecciones originales de expertos del modelo y, a la vez, reducir el tiempo de espera por sus pesos.

La tarjeta del modelo de 35B del equipo describe un enfoque de despliegue que conserva el enrutamiento a nivel de token, el proceso que selecciona expertos para cada token generado. También informa de un resultado independiente de más de 13 tokens por segundo en un iPhone 17 Pro Max, usando aproximadamente 3 GB de memoria.

Ese resultado anterior en teléfono debe mantenerse separado del benchmark más reciente del iPhone 18 Pro Max. Se refieren a dispositivos y configuraciones documentadas diferentes. Tratarlos como intercambiables ocultaría lo que la evidencia pública establece realmente.

LES significa Lookahead Expert Scheduling, un sistema que anticipa qué expertos necesitará la siguiente capa del modelo. Su propósito es adelantar el trabajo de carga. La predicción ayuda a organizar el cálculo; no sustituye la selección final de expertos del modelo.

Considere el problema de despliegue desde la perspectiva de un desarrollador de aplicaciones. Un asistente puede tener suficiente capacidad de cálculo para generar una respuesta y, aun así, ser lento porque su siguiente operación carece de los pesos necesarios. Acelerar la aritmética sirve de poco cuando la aritmética espera datos.

Mantener a todos los expertos en la memoria de trabajo evita ese retraso concreto, pero exige más memoria. Mantener los pesos en almacenamiento reduce la huella residente, pero introduce trabajo de carga. Restringir los expertos disponibles simplifica el acceso y, al mismo tiempo, puede cambiar el cálculo que produce la respuesta.

La ruta propuesta por MiniCPM conserva el acceso al conjunto completo de expertos y gestiona cuándo llegan los pesos. Eso crea un objetivo de ingeniería distinto. La pregunta pasa a ser si puede llegar una cantidad suficiente de datos necesarios durante el cálculo que ya está en curso.

Por eso el anuncio de programación merece atención más allá de un titular sobre el tamaño del modelo. Un elevado número de parámetros en un teléfono dice poco por sí solo sobre la capacidad de respuesta. La disposición de la carga y la ejecución determina si esa capacidad puede sostener una aplicación interactiva.

Para los usuarios, la distinción se manifiesta como continuidad. Una respuesta que empieza a producir texto y luego se pausa repetidamente se siente diferente de una con una salida más estable. La velocidad media de generación captura parte de esa experiencia, pero también importa la secuencia de retrasos.

Por tanto, la relevancia práctica recae en el runtime, el software responsable de ejecutar el modelo. Los pesos del modelo por sí solos no pueden establecer que cada aplicación compatible reproduzca el mismo comportamiento. El despliegue pertinente combina el modelo, la disposición del almacenamiento, la implementación de la programación y la configuración numérica.

Ese sistema combinado es el objeto real de la afirmación. Proporciona una base concreta para investigarla sin exigir que se acepten todos los superlativos asociados al lanzamiento.

Preservar la elección de expertos presiona los atajos de despliegue móvil

La presión inmediata recae sobre las estrategias de despliegue que ganan velocidad al reducir el conjunto de expertos disponibles para el modelo.

Una restricción de expertos puede parecer atractiva cuando la memoria y el tiempo de carga dominan el presupuesto de una aplicación. Menos pesos disponibles implican menos requisitos de carga posibles. La dificultad es que una optimización que afecta la disponibilidad de expertos también puede afectar el comportamiento del modelo.

Esto crea una decisión que los desarrolladores deben tomar explícitamente. ¿Están optimizando cómo se ejecuta el modelo original o desplegando una ruta computacional modificada? Ambos enfoques merecen evaluación, pero sus afirmaciones de calidad requieren evidencias distintas.

Un sistema de programación promete una separación útil. Los desarrolladores pueden investigar la eficiencia de ejecución mientras mantienen intacto el mecanismo de selección del modelo. Esto facilita identificar si un cambio afecta la velocidad, la calidad de las respuestas o ambas.

También cambia la comparación con modelos más pequeños. Un modelo compacto que permanece en memoria puede ofrecer una ruta de despliegue más sencilla. Un modelo mayor transmitido desde almacenamiento debe justificar su complejidad adicional de almacenamiento y runtime mediante mejores resultados en tareas relevantes.

Ninguna de las dos rutas gana solo por el número de parámetros. Una aplicación que extrae un campo breve de un documento conocido podría beneficiarse más de una latencia predecible que de una capacidad de razonamiento más amplia. Un sistema que interpreta diagramas desconocidos podría dar mayor peso a la calidad de las respuestas.

Estos son escenarios de despliegue, no resultados verificados de clientes de MiniCPM. Ilustran por qué el mismo benchmark puede respaldar decisiones de producto distintas. El valor depende de lo que preguntan los usuarios y de los fallos que la aplicación puede tolerar.

La comparación histórica también es instructiva. La investigación de Apple sobre inferencia basada en flash examinó la ejecución de modelos más allá de la memoria de trabajo disponible mediante carga selectiva y acceso al almacenamiento más eficiente. Sus métodos difieren de LES, pero la restricción compartida es el movimiento de datos.

Ese precedente acota adecuadamente la afirmación de novedad. El uso de almacenamiento flash para admitir modelos más grandes tiene una trayectoria establecida en investigación. La contribución específica bajo examen se refiere a anticipar los requisitos de expertos y coordinar su ejecución.

Para los equipos de hardware móvil, este enfoque redirige la atención hacia toda la ruta de memoria y almacenamiento. La capacidad de cómputo sigue siendo relevante, pero un despliegue puede bloquearse antes de alcanzar sus límites aritméticos. Evaluar el procesador de forma aislada pasa por alto esa posibilidad.

Para los equipos de aplicaciones, plantea una cuestión de adquisición. Un dispositivo con especificaciones de cómputo atractivas aún necesita pruebas frente al runtime y la carga de trabajo previstos. El comportamiento del almacenamiento, la memoria disponible y las condiciones operativas pasan a formar parte del perfil de rendimiento de la aplicación.

Por tanto, la implicación competitiva es una exigencia de ingeniería, no una victoria de mercado declarada. Las alternativas deben mostrar cómo equilibran calidad, capacidad de respuesta y uso de recursos en condiciones comparables. MiniCPM debe cumplir ese mismo estándar.

Si el enfoque de programación se reproduce de forma fiable, restringir expertos se vuelve más difícil de justificar como una necesidad automática. Sigue siendo una elección de diseño cuyo coste de calidad y beneficio de rendimiento deberían ser visibles.

Cómo MiniCPM LES preserva el enrutamiento mientras oculta los retrasos de carga

LES usa predicción para preparar el cálculo, mientras el router real sigue siendo responsable de seleccionar los expertos que se ejecutan.

La documentación oficial sobre programación de expertos describe una predicción entre capas seguida de prefetching, que carga los pesos probablemente necesarios antes de que la ejecución los alcance. Los expertos anticipados correctamente se ejecutan primero. Otros expertos requeridos se cargan en paralelo con ese cálculo.

Por tanto, una predicción fallida genera espera adicional en lugar de permiso para omitir un experto necesario. Esta distinción explica la afirmación del equipo sobre programación sin pérdida. Se refiere a preservar la participación de expertos, en vez de asumir que las predicciones siempre coinciden con la selección final.

La documentación también describe organizar los pesos de forma contigua, reducir las lecturas dispersas y aplicar precisión mixta específica por capa. La cuantización, la representación de los pesos con menor precisión numérica, reduce las exigencias de almacenamiento y transferencia. Estos cambios abordan distintas partes del problema de carga.

El mecanismo sugiere varias implicaciones útiles, aunque requieren medición en despliegues reales. La precisión de la predicción por sí sola no puede determinar el beneficio total. Una predicción correcta que llega demasiado tarde podría ahorrar poco tiempo de espera.

Del mismo modo, cargar los pesos correctos con antelación solo ayuda si el dispositivo puede solapar trabajo útil. Si otro recurso se convierte en el factor limitante, el mismo programador puede producir una ganancia distinta. El rendimiento pertenece al entorno de ejecución completo.

Las predicciones incorrectas también merecen atención. Precargar algo innecesario consume recursos, incluso cuando deja intacta la selección de expertos. La pregunta útil es si los retrasos evitados compensan ese trabajo adicional en solicitudes representativas.

Esto convierte la selección de cargas de trabajo en un elemento central de la evaluación. Un benchmark debería exponer situaciones en las que la programación funciona bien y situaciones en las que tiene dificultades. Una media sin esa distribución puede ocultar patrones importantes para la fiabilidad de una aplicación.

Por ejemplo, un asistente documental podría encontrarse con diseños conocidos durante una sesión y estructuras visuales inusuales durante otra. Los evaluadores deberían investigar si esos cambios alteran la capacidad de respuesta. El mecanismo les da un motivo para preguntar; no establece la respuesta.

El enfoque también separa dos predicciones que los lectores pueden confundir fácilmente. El prefetching de expertos anticipa qué pesos requerirá un cálculo próximo. La decodificación especulativa, que redacta tokens de salida candidatos para verificarlos posteriormente, se refiere al propio proceso de generación.

MiniCPM integra DSpark como su componente especulativo. Eso crea otra oportunidad para mejorar el rendimiento, pero también hace más importante la atribución. Una aceleración atribuida de forma amplia a LES puede incluir contribuciones de la programación, el acceso al almacenamiento, la representación numérica y la redacción de tokens.

Para los desarrolladores, la ventaja conceptual es lo bastante clara como para ponerla a prueba. Preservar el trabajo requerido y reorganizar después la preparación y la ejecución para reducir el tiempo inactivo. El desafío práctico consiste en hacer que esa reorganización resulte beneficiosa bajo las restricciones reales del dispositivo.

Esta es una propuesta más sólida y específica que afirmar simplemente que un modelo grande cabe dentro de una pequeña asignación de memoria. Identifica el tiempo de espera al que apunta la implementación y el comportamiento del modelo que afirma preservar.

El resultado de 20,51 tokens combina varias optimizaciones

El resultado publicado para teléfono pertenece al conjunto completo de optimizaciones, y no solo a la programación anticipada.

Los benchmarks en dispositivo de OpenBMB enumeran el iPhone 18 Pro Max con 12 GB de memoria del dispositivo. Los resultados detallados comienzan en 3,38 tokens por segundo para la línea base. La programación con anticipación alcanza 6,57; cambios adicionales de programación y carga llegan a 11,34.

La cuantización de precisión mixta eleva el resultado reportado a 17,16 tokens por segundo. La incorporación de DSpark lo lleva a 20,51, o 6,07 veces la línea base. El resultado correspondiente del iPad Pro M4 totalmente optimizado es de 17,39 tokens por segundo.

Estas cifras respaldan una lectura concreta: varias etapas contribuyen al resultado. No respaldan describir toda la aceleración como el efecto aislado de la predicción de expertos. Los desarrolladores que intenten reproducir el titular necesitan la configuración relevante de cada etapa.

La línea base merece el mismo escrutinio. Una comparación con una implementación sin estas optimizaciones demuestra una mejora respecto a esa implementación. No establece automáticamente superioridad frente a cualquier otro entorno de ejecución o método de despliegue.

Este es un problema interpretativo habitual en los benchmarks de sistemas. Una gran ganancia relativa puede coexistir con un punto de partida modesto. Los lectores necesitan tanto el resultado absoluto como una descripción clara de lo que cambió.

La memoria total del teléfono también responde a una pregunta distinta de la huella de memoria de trabajo reportada por el modelo. La capacidad del dispositivo describe el entorno de hardware. La memoria de la aplicación describe los recursos consumidos dentro de ese entorno, según el método de medición.

El almacenamiento persistente añade otra dimensión. Los archivos oficiales del modelo cuantizado enumeran la variante Q4_K_M con 21,2 GB. Ese listado ilustra por qué una afirmación de baja memoria residente nunca debe interpretarse como una descarga igualmente pequeña.

El listado de archivos no establece que este artefacto exacto produjera todos los benchmarks publicados. Sigue siendo necesario cotejar el benchmark con sus archivos de pesos precisos. De lo contrario, los desarrolladores corren el riesgo de comparar distintas representaciones numéricas bajo el mismo nombre de modelo.

La distinción tiene consecuencias directas para el producto. Una aplicación móvil debe contemplar la instalación, las actualizaciones del modelo, el almacenamiento disponible y el comportamiento de inicio. Una configuración que genera eficientemente tras la preparación sigue necesitando ofrecer una experiencia aceptable antes de que comience la generación.

La velocidad de decodificación mide la generación de salida una vez que la decodificación está en marcha. No debe tratarse como el intervalo completo entre enviar una imagen y recibir una respuesta útil. El manejo y la preparación de la entrada requieren sus propias mediciones.

Del mismo modo, los tokens son unidades que utiliza el modelo, no un número fijo de palabras en inglés. Una cifra de rendimiento ofrece una comparación técnica bajo condiciones declaradas. No se traduce directamente en una experiencia universal de lectura o conversación.

Por tanto, el resultado reportado es significativo, pero limitado. Muestra lo que el equipo afirma que alcanza su implementación combinada en hardware identificado. Las pruebas independientes deberían determinar cómo se traslada ese resultado a sesiones de aplicación realistas.

“Sin pérdida” necesita un punto de referencia definido

Preservar el enrutamiento de expertos respalda una afirmación técnica acotada; no establece un comportamiento idéntico en todos los ajustes de precisión, tareas y dispositivos.

La interpretación más sólida de la descripción de la programación se refiere a la selección. Los expertos necesarios siguen siendo elegibles, y un fallo de predicción no los elimina del cálculo. Esta propiedad aborda un riesgo de calidad específico introducido al restringir el conjunto de expertos disponibles.

El despliegue móvil completo plantea preguntas adicionales. La cuantización modifica la representación de los pesos. Por tanto, la comparación de calidad adecuada debe identificar qué modelo de referencia y qué configuración numérica definen la línea base.

Una afirmación sobre preservar el enrutamiento no debería convertirse silenciosamente en una afirmación sobre igualar todas las salidas de un modelo de mayor precisión. Esas afirmaciones se refieren a propiedades diferentes. Los evaluadores necesitan evidencia adecuada para cada una.

Del mismo modo, preservar un procedimiento de generación no establece que sus respuestas sean correctas. Un modelo puede ejecutarse según lo previsto y aun así interpretar mal un gráfico, malentender una solicitud o inventar un detalle. La fidelidad de ejecución y la precisión de las tareas requieren evaluaciones separadas.

No se estableció ninguna reproducción independiente del benchmark principal en teléfonos a través de las fuentes revisadas para este análisis. Esa limitación no invalida el resultado reportado. Determina con qué confianza los lectores deberían generalizar a partir de él.

La misma cautela se aplica al encuadre de la empresa como “el primero”. Establecer prioridad requiere un conjunto de comparación definido y definiciones consistentes. Términos como fluido, en tiempo real y sin pérdida necesitan límites medibles antes de respaldar una clasificación universal.

El tiempo real depende especialmente de la aplicación. Una respuesta escrita transmitida gradualmente puede tolerar retrasos que interrumpirían una interacción en vivo. Un umbral técnico de rendimiento no puede establecer la idoneidad para cada interfaz.

Las sesiones más largas introducen otra prueba importante. Los evaluadores deberían medir solicitudes repetidas, condiciones cambiantes del dispositivo y actividad concurrente de aplicaciones. Son cuestiones de durabilidad operativa, no evidencia de que la implementación reportada se deteriore necesariamente.

Las pruebas de calidad de respuesta deberían incluir fallos que los usuarios puedan reconocer. En un flujo de trabajo hipotético de gastos, esto significa comprobar si las entradas extraídas coinciden con el recibo. En el análisis de documentos, significa comprobar si las explicaciones siguen fundamentadas en la página proporcionada.

Un flujo de trabajo de conocimiento más amplio añade recuperación, el proceso de seleccionar material almacenado relevante para una respuesta. Los lectores que comparen bases de conocimiento personales deberían evaluar esa capa por separado de la velocidad de generación del modelo. Una salida más rápida no puede compensar la selección del documento fuente equivocado.

La ejecución local también requiere una interpretación cuidadosa. Ofrece una opción de despliegue para procesar entradas en el dispositivo, pero no describe cada flujo de datos de una aplicación terminada. La arquitectura de la aplicación determina qué permanece local.

Estas distinciones fortalecen el análisis al hacer verificables las afirmaciones. La pregunta ya no es si la “IA móvil sin pérdida” parece plausible. Es qué comportamiento permanece sin cambios, qué recursos consume el sistema y qué mediciones demuestran el resultado.

MiniCPM LES ofrece a los desarrolladores una propuesta de programación específica que investigar. La aceptación debería seguir a resultados reproducibles y comprobaciones de calidad a nivel de aplicación, con cada conclusión vinculada a la propiedad realmente medida.

Tres señales mostrarán si el enfoque se traslada a los productos

La siguiente evidencia debería conectar la reproducibilidad, el uso sostenido y la disponibilidad de implementación, en ese orden.

La primera señal es una reproducción independiente con artefactos y ajustes identificables. Durante los próximos meses, el resultado útil incluiría archivos exactos del modelo, revisión del entorno de ejecución, prompts y límites de medición. Esos detalles permitirían a otros desarrolladores examinar la misma afirmación.

Una reproducción debería informar más que su mejor ejecución. La variación entre solicitudes importa cuando los equipos planifican un servicio interactivo. Resultados consistentes reforzarían la confianza en que la velocidad publicada representa una configuración utilizable.

Un resultado inferior requeriría interpretación en lugar de un descarte inmediato. Archivos de pesos o ajustes diferentes podrían explicar una brecha. Una discrepancia reproducible en condiciones equivalentes debilitaría más directamente la afirmación original de rendimiento.

La segunda señal son pruebas sostenidas con cargas de trabajo representativas. Los evaluadores deberían seguir las solicitudes completas desde el envío de la entrada hasta la finalización de la respuesta. También deberían comprobar la calidad junto con la capacidad de respuesta, porque una salida incorrecta más rápida aporta poco valor al producto.

Aquí es donde la inferencia móvil de MoE pasa de una demostración técnica a una decisión de aplicación. Una evaluación útil mostraría si los beneficios persisten durante solicitudes repetidas de documentos o imágenes. También identificaría las condiciones en las que sigue siendo preferible un modelo residente más pequeño.

Los resultados entre dispositivos aclararían el alcance. Un comportamiento similar en hardware adicional respaldaría una aplicabilidad más amplia. Resultados concentrados en una configuración estrecha indicarían una oportunidad de despliegue más especializada.

La tercera señal es la integración accesible de la pila de optimización necesaria. Los desarrolladores necesitan un camino claro desde los pesos publicados hasta la implementación detrás del benchmark. La documentación debería hacer inequívocas las elecciones necesarias de entorno de ejecución y artefactos.

Esa disponibilidad importa porque la compatibilidad y un rendimiento equivalente son logros distintos. Cargar un modelo compatible no garantiza que una aplicación active todas las optimizaciones de programación y almacenamiento. Reproducir la configuración completa es el hito relevante.

Una integración clara reforzaría la idea de que se trata de infraestructura reutilizable para aplicaciones móviles. Instrucciones fragmentadas o resultados dependientes de la configuración dificultarían la adopción, incluso si la técnica subyacente sigue siendo sólida.

Para los equipos que consideren un piloto, el siguiente paso adecuado es una evaluación acotada con material que se parezca a las solicitudes reales de los usuarios. Incluya los documentos difíciles y las imágenes incómodas que revelen si una mayor capacidad del modelo mejora la respuesta. Mida el tiempo de espera que experimentan los usuarios, junto con el uso de recursos y la corrección. Mantenga fija la configuración de referencia mientras evalúa cada optimización, para que las mejoras sigan siendo atribuibles. MiniCPM LES merece atención porque ofrece una forma concreta de preservar la elección de expertos mientras reduce los retrasos de carga. Antes de desarrollar en torno a la velocidad del titular, pregunte si esa misma configuración ofrece respuestas fiables durante todo el flujo de trabajo móvil previsto.