Lo que se publicó en código abierto
Las conversaciones sobre «qué modelo es mejor» casi siempre chocan con el mismo problema: nadie verificó las cifras. Las mediciones se hacen en otra máquina, con otra cuantización, en otra compilación del runtime, y compararlas entre sí carece de sentido. La empresa Liquid AI propuso remediar esto con apertura y reproducibilidad: lanzó Pipette, una plataforma para el benchmarking de modelos fundacionales en dispositivos edge. La metodología fue validada de forma independiente por Artificial Analysis.
La idea principal sobre la que se sostiene toda la construcción: el comportamiento en el dispositivo es una propiedad del sistema desplegado, no del modelo en aislamiento. Por lo tanto, la unidad de medida tampoco debe ser el «modelo», sino la configuración completa: pesos más esquema de cuantización más entorno de ejecución más hardware concreto. De esta tesis surge tanto la estructura del conjunto de datos como la forma en que deben leerse todas las comparaciones que aparecen a continuación.
Qué entró en el conjunto de datos inicial
- cinco métricas de rendimiento en el dispositivo;
- más de mil configuraciones en la combinación modelo × cuantización × entorno de ejecución × dispositivo × longitud de contexto;
- más de 30 modelos y varios formatos de cuantización;
- compilaciones de llama.cpp para macOS, iOS, Windows y Android;
- longitudes de contexto de 256 a 8 192 tokens.
Las primeras mediciones publicadas se hicieron en un MacBook Pro con M5 Max, un iPhone 17 Pro y un Galaxy S26 Ultra. Para AMD Ryzen AI Max+ 395 y Radeon 8060S los resultados aún están marcados como «coming soon», es decir, la plataforma se anunció desde el principio como multiplataforma, pero la cobertura de hardware todavía está creciendo.
Cuatro conclusiones de las primeras ejecuciones
Parámetros idénticos, comportamiento distinto en contexto largo
Una buena ilustración de por qué se necesita en general este tipo de medición. Dos modelos de 350M parámetros con el mismo Q4_K_M en el mismo teléfono se comportan de manera diferente al crecer los tokens de entrada: Granite-4.0-H-350M conserva el 78,4% del rendimiento de decodificación al pasar de 256 a 4 096 tokens de entrada, mientras que Granite-4.0-350M solo el 33,8%. El número de parámetros aquí no sugiere nada: la diferencia está en la arquitectura y en cómo esta encaja en un runtime y un chip concretos.
La activación dispersa ahorra cómputo, pero no memoria
LFM2.5-8B-A1B en el mismo teléfono con 2 048 tokens de entrada decodifica 2,4 veces más rápido que Qwen3.5-4B, y 2,6 veces más rápido que Ministral-3-3B-Instruct-2512. El secreto está en la activación dispersa: por cada token se activan aproximadamente 1,5B de los 8,5B parámetros. Pero el consumo máximo de memoria es de 5,29 GiB, porque todos los pesos de los expertos de todos modos deben residir en memoria por completo. Conclusión práctica: las arquitecturas tipo MoE ganan en tiempo, pero no salvan el presupuesto de RAM, y en un teléfono el límite a menudo se topa precisamente con la memoria.
Más rápido no significa mejor calidad
En el iPhone 17 Pro con Q4_K_M, MiniCPM5-1B ejecuta una carga de 2 048 tokens de entrada / 256 de salida en 3,47 s, mientras que LFM2.5-1.2B-Instruct lo hace en 4,12 s, es decir, el primero es un 15,8% más rápido. Sin embargo, en los mismos artefactos LFM obtiene 9,0 puntos más en MATH-500. El rendimiento y la calidad son ejes distintos, y elegir un modelo por una sola cifra de la tabla carece de sentido.
Perfiles de sistema casi idénticos pueden ocultar un vuelco en las tareas
En el M5 Max con Q4_K_M y 2 048 tokens de entrada, Granite-4.1-8B y Ministral-3-8B-Instruct-2512 difieren solo un 2,4% en rendimiento de decodificación y un 1,2% en RAM máxima. Pero en las tareas el panorama cambia: Granite gana 7,3 puntos en IFBench, mientras que Ministral lo supera en 14,0 puntos en GPQA Diamond. La diferencia en el perfil «de hardware» está dentro del margen de ruido, la diferencia en el comportamiento es fundamental.
Cómo están diseñadas las mediciones
Las ejecuciones de rendimiento se basan en formas de tokens fijas, decodificación voraz, calentamiento descartado y cinco repeticiones medidas. Antes de cada repetición se activa el readiness gating: una verificación específica de la plataforma se asegura de que las condiciones térmicas y la carga en segundo plano correspondan a la norma. Las ejecuciones fallidas no entran en la publicación: esto es precisamente lo que distingue un benchmark reproducible de un script puntual.
Un apartado aparte es la calidad. No se mide con la misma ejecución: para ello se usan IFBench, GPQA Diamond y MATH-500, y las evaluaciones se toman de ejecuciones de evaluación de llama.cpp en sistemas de referencia con NVIDIA H100 80GB. Luego se cotejan con las ejecuciones en el dispositivo para el mismo modelo y la misma cuantización. Consecuencia importante: la cifra de calidad que aparece junto al rendimiento del teléfono no se obtuvo en el teléfono. Es una métrica cómoda para comparar modelos entre sí, pero no es una medición de lo que ocurre en un smartphone concreto.
Qué es exactamente lo que se libera en código abierto
Pipette se entrega por completo, sin lista de espera:
- infraestructura bajo Apache 2.0: los repositorios pipette-mgmt, pipette-clients y pipette-scores;
- conjunto de datos público de resultados;
- panel de control alojado;
- aplicaciones nativas para benchmarking en iOS y Android.
La única parte que aún no está lista para acceso general es la publicación de resultados enviados por la comunidad: está en beta. Todo lo demás se puede ejecutar de forma autónoma, incluido el despliegue del pipeline dentro del propio perímetro.
Para quién y para qué sirve esto
La forma más sencilla de describir el público objetivo es así: cualquier equipo que lance un modelo a hardware que no posee. Luego las variantes se diferencian por escala.
- A un desarrollador solo y a una startup en etapa seed les bastará con el panel de control y las aplicaciones móviles: no se necesita infraestructura propia.
- Un equipo de producto de tamaño medio puede desplegar los clientes en su propio parque de dispositivos y obtener mediciones en su configuración.
- Los grandes OEM, fabricantes de chips y empresas pueden mantener todo el pipeline detrás del firewall, lo que elimina las dudas sobre adónde van los datos de las mediciones.
Las tareas típicas también son claras sin explicaciones adicionales: elegir el modelo y el formato de cuantización antes de que las tareas del sprint estén fijadas; justificar la compra de un SoC o de equipos; detectar una regresión al actualizar el runtime, el SO o el controlador; planificar la capacidad según la longitud del contexto; verificar de forma independiente las promesas publicitarias de los proveedores. Los sectores: electrónica de consumo y OEM de smartphones, ámbito automotriz, industria y robótica, dispositivos médicos, servicios financieros, defensa: en todos los lugares donde la latencia, la privacidad o la falta de conexión obligan a ejecutar el modelo directamente en el dispositivo.
En qué fijarse antes de confiar en las cifras
Tres cosas que es fácil olvidar al leer cualquier tabla de mediciones.
En primer lugar, las cifras de calidad y las cifras de rendimiento provienen de lugares distintos. El rendimiento se mide en el dispositivo, la calidad en un sistema de referencia con H100 y luego se coteja. Para comparar modelos esto es correcto, para predecir el comportamiento en una aplicación concreta, no.
En segundo lugar, la cuantización no se puede dejar de lado. El mismo formato en modelos distintos y runtimes distintos da un resultado diferente, y la limitación de memoria a menudo resulta decisiva, como en el ejemplo de la activación dispersa, donde la velocidad aumentó pero los 5,29 GiB no desaparecieron.
En tercer lugar, un rendimiento idéntico no dice nada sobre cómo se desempeñarán los modelos en tareas concretas. El vuelco de Granite y Ministral en IFBench y GPQA Diamond con perfiles de sistema casi idénticos es justo el caso en que primero hay que definir la tarea y solo después mirar las tablas.
