Los resultados de IA en el dispositivo de Pipette son pruebas de despliegue, no clasificaciones de chips
Pipette publica resultados de latencia, rendimiento, memoria y calidad en muchas configuraciones, pero distintos teléfonos, entornos de ejecución y cuantizaciones no forman una clasificación única y limpia.
Liquid AI y Artificial Analysis publicaron Pipette el 24 de agosto como un benchmark abierto para modelos de lenguaje pequeños que se ejecutan en teléfonos y ordenadores. Su unidad útil no es el nombre del modelo, sino el despliegue completo: modelo, cuantización, entorno de ejecución, dispositivo, configuración del entorno de ejecución y carga de trabajo.
Ese diseño corrige un problema habitual en las comparaciones de IA en el dispositivo. Una puntuación de calidad de precisión completa obtenida en un servidor no indica si un modelo cuantizado cabe en un teléfono, responde antes de que el usuario pierda la paciencia o se ralentiza drásticamente al crecer el prompt. Pipette reúne esas dimensiones en un mismo panel, pero colocarlas unas junto a otras no hace que todas las filas sean directamente comparables.
La limitación central es sencilla: los gráficos entre dispositivos son observaciones de despliegue, no clasificaciones de chips, y la puntuación de calidad que aparece junto al rendimiento del teléfono se midió mediante una ruta de evaluación independiente.
Pipette mide una configuración de despliegue
El anuncio del lanzamiento de Pipette dice que el conjunto de datos público inicial contiene más de 1.000 combinaciones entre más de 30 modelos, varias cuantizaciones, compilaciones de llama.cpp para macOS, iOS, Windows y Android, y longitudes de prompt de 256 a 8.192 tokens. Publica la latencia, la velocidad de procesamiento del prompt, la velocidad de generación de tokens y la memoria máxima en los dispositivos objetivo, y después empareja las filas compatibles con evaluaciones de calidad de tareas.
Las dimensiones adicionales no son metadatos que se puedan ignorar después de encontrar un modelo. Pueden cambiar el resultado:
| Dimensión | Qué cambia | Qué debe mantenerse fijo para una comparación limpia |
|---|---|---|
| Artefacto del modelo y cuantización | Memoria de los pesos, calidad de salida y, a veces, velocidad | El artefacto exacto del modelo y el formato de cuantización |
| Entorno de ejecución | Kernels, uso del acelerador, límites de medición y funciones compatibles | Nombre y compilación del entorno, backend y flags relevantes |
| Dispositivo y sistema operativo | Memoria disponible, ruta del procesador, contadores y comportamiento energético | Clase exacta del dispositivo y compilación del sistema operativo |
| Forma de la carga de trabajo | Trabajo de prellenado, trabajo de generación, presión del contexto y memoria de la caché de clave-valor | Tokens de entrada, tokens de salida, definición del benchmark y asignación de contexto |
| Condiciones del dispositivo | Limitación térmica y carga en segundo plano | Alimentación, refrigeración, puerta de preparación y estado de reposo comparable |
| Evaluación de calidad | Qué capacidad representa la puntuación | Versión del conjunto de datos, evaluador, modo de razonamiento, modelo y cuantización |
La guía de Pipette para comparar resultados es más estricta que una mirada a la clasificación: los flags del entorno, Flash Attention, el número de hilos, el número de capas de GPU, el modo de razonamiento, la cuantización y la configuración de tokens forman parte de la configuración. Cambiar un ajuste significa cambiar el experimento.
Por eso «el modelo A obtiene 80 tokens por segundo» es una afirmación incompleta. Una formulación útil sería: «este artefacto cuantizado, en este dispositivo y con esta compilación del entorno, generó 100 tokens de salida a esta velocidad después de un prompt de 2.048 tokens bajo las condiciones de laboratorio documentadas».
La latencia, el prellenado y la decodificación responden a preguntas distintas
La inferencia de modelos de lenguaje tiene dos fases principales. El prellenado procesa el prompt de entrada antes del primer token generado. La decodificación genera la respuesta un token cada vez. Un documento largo y una respuesta corta ponen a prueba el prellenado; un prompt corto y una respuesta larga dan más peso a la decodificación.
La metodología de rendimiento de Pipette informa de estas fases por separado. Su benchmark estándar de decodificación genera 100 tokens de salida, mientras que la latencia de extremo a extremo genera 256. Las ejecuciones de medición usan decodificación codiciosa, descartan el comportamiento de inicio y calentamiento, y comunican la media y la desviación estándar muestral de cinco repeticiones medidas.
Elige la métrica que corresponda a la pregunta del producto:
| Pregunta del producto | Métrica de Pipette | Léela junto con |
|---|---|---|
| ¿A qué velocidad puede el sistema absorber un prompt? | Rendimiento de prellenado, en tokens de entrada por segundo | La longitud exacta de entrada y la ruta del entorno |
| ¿Con qué rapidez aparece el texto cuando empieza la generación? | Rendimiento de decodificación, en tokens de salida por segundo | La longitud de salida y el comportamiento de respuesta del modelo |
| ¿Cuánto tarda la solicitud fija completa? | Latencia de extremo a extremo | Ambos recuentos de tokens y la sobrecarga del cliente incluida |
| ¿Cabe el despliegue? | Memoria máxima | El contador específico de la plataforma y la longitud del contexto |
| ¿Conserva el artefacto una capacidad útil? | IFBench, GPQA Diamond o MATH-500 | La tarea representada y la ruta de evaluación independiente |
No calcules el tiempo de respuesta visible para el usuario sumando dos cifras de rendimiento redondeadas. Pipette señala que las rutas de extremo a extremo pueden incluir la tokenización y la sobrecarga de las solicitudes locales, que las tasas de las fases aisladas excluyen. Mide también la aplicación real si importan el inicio, la carga del modelo, la construcción del prompt, el streaming o el trabajo de la interfaz.
La varianza también debe formar parte de la decisión. Pipette aconseja tratar una desviación estándar superior al 5 % de la media como evidencia de una ejecución ruidosa o inestable. Cinco repeticiones cercanas no demuestran el rendimiento de toda la población, pero son más informativas que una media redondeada que oculte una ejecución con limitación térmica.
La puntuación del teléfono y la de calidad proceden de máquinas distintas
El error más fácil al leer un gráfico de Pipette es suponer que todos los valores representados se produjeron en el teléfono seleccionado. El rendimiento se mide en el dispositivo mostrado. Los resultados de calidad publicados actualmente se generaron por separado con llama.cpp en sistemas NVIDIA H100 de 80 GB y después se emparejaron con los resultados del dispositivo cuando el modelo y la cuantización son compatibles.
Ese emparejamiento es útil. Permite a un equipo preguntar si una cuantización más pequeña ahorra suficiente memoria y tiempo sin perder demasiado rendimiento en la tarea. No demuestra que el teléfono ejecutara MATH-500, GPQA Diamond o IFBench a la velocidad mostrada en el eje de rendimiento. La metodología de publicación de Pipette también dice que cambiar el dispositivo de rendimiento no selecciona una nueva fila de calidad.
La cobertura de calidad es más estrecha que «es bueno para la IA móvil». El conjunto de lanzamiento prueba el seguimiento de instrucciones, las matemáticas de competición y el razonamiento científico. Las limitaciones documentadas de Pipette dicen que no es exhaustivo para el comportamiento agéntico, las tareas con mucho conocimiento, el trabajo multimodal u otros usos orientados al dispositivo. Un equipo que lance funciones de resumen, extracción, llamadas a herramientas, voz o visión sigue necesitando una evaluación construida a partir de las entradas y los costes de fallo de esa función.
La cuantización hace que convenga mantener esta separación. Reduce la precisión usada para almacenar los pesos del modelo, lo que a menudo disminuye el uso de memoria y a veces mejora la velocidad, pero la pérdida de calidad depende del artefacto y de la tarea. Compara las cuantizaciones dentro de un modelo y un despliegue objetivo, y después prueba la tarea de la aplicación. Un benchmark general es una evidencia, no una prueba de aceptación para una promesa de producto.
Un gráfico entre dispositivos no es un duelo de procesadores
Pipette recomienda explícitamente comparar dentro del mismo dispositivo. Las rutas iniciales de Android e iOS no son equivalentes con control del hardware. La metodología de cobertura dice que los resultados públicos de Android utilizan una ruta de línea de comandos de llama.cpp solo con CPU, con Flash Attention desactivado y sin capas de GPU. Las mediciones publicadas de iOS se ejecutan dentro de la aplicación con Metal y ajustes que no tienen equivalente en Android.
La plataforma también afecta a la medición. Los contadores de memoria máxima no significan exactamente lo mismo en todas partes, y la señal térmica pública de iOS es demasiado burda para el proceso de laboratorio de Pipette. Las ejecuciones públicas de iOS utilizan una compilación interna consciente de la temperatura que puede leer la temperatura del chip, una capacidad que la aplicación pública no puede reproducir exactamente.
Pipette controla parte del ruido ambiental. Su metodología de condiciones del dispositivo comprueba las señales térmicas y de carga antes de las repeticiones cronometradas, mantiene los teléfonos de la flota conectados a la red eléctrica y usa refrigeración externa. Esos controles mejoran las comparaciones dentro de su laboratorio. La refrigeración sigue gestionada por el operador y no se almacena en cada fila de resultados, así que el conjunto de datos no puede demostrar por sí solo que dos filas cualesquiera de teléfonos tuvieran condiciones físicas idénticas.
Un análisis práctico independiente de GIGAZINE muestra que la aplicación pública para iPhone puede descargar un modelo y ejecutar cargas de trabajo de benchmark locales. Es una confirmación útil de la experiencia del cliente, no una reproducción independiente de todo el conjunto de datos de laboratorio de Liquid AI ni de la instrumentación térmica privada de iOS.
Si la decisión es «¿qué configuración debería usar nuestra aplicación para iPhone?», filtra por el iPhone compatible y compara allí las configuraciones. Si la decisión es «¿qué chip de teléfono es más rápido?», las rutas multiplataforma actuales de Pipette no aíslan el chip del entorno de ejecución, el backend, los flags, el sistema operativo, la alimentación, la refrigeración y las diferencias entre contadores. Un número mayor puede describir el despliegue completo publicado sin identificar el componente que lo causó.
Qué puede establecer Pipette hoy
Pipette hace más auditable la selección de modelos en el dispositivo al publicar cargas de trabajo versionadas, resultados por configuración, varianza y envíos trazables. Puede mostrar que una configuración probada es más rápida, más pequeña o más capaz que otra en una evaluación cubierta y bajo las condiciones registradas.
No puede convertir rutas de plataforma distintas en una clasificación controlada de procesadores. No puede hacer que tres pruebas de calidad ejecutadas en servidores representen todas las funciones móviles. Y, dado que los resultados verificados actuales proceden del laboratorio de Liquid AI mientras la publicación de la comunidad sigue en beta, todavía no describe la distribución de los dispositivos ordinarios de los usuarios, calientes, ocupados y alimentados por batería.
La próxima evidencia significativa serán envíos reproducibles de forma independiente, con etiquetas claras de las condiciones y una cobertura más amplia de dispositivos. Hasta entonces, Pipette es una sólida superficie para crear una lista corta y comparar configuraciones, cuyas filas siguen describiendo despliegues completos, no modelos ni procesadores aislados.