Hardware y latencia medida

Cada cifra aquí indica el hardware en el que se midió, y las proyecciones están identificadas como tales.

Todas las mediciones se realizaron sobre el mismo conjunto de referencia de 50 fotos con las mismas instrucciones. La metodología completa, los intervalos de confianza y las ejecuciones en sí están en eval/BASELINE.md y eval/PERFORMANCE.md.

Los perfiles

Ambas variantes de lite se ejecutan en CPU. quality también funciona en CPU, muy despacio, y en realidad es un perfil para GPU.

quality en GPU: medido

Ambas filas: Qwen3-VL-8B-Instruct Q4_K_M + F16 mmproj, contexto de 8192, imágenes reducidas a 896 px, llama.cpp llama-server b10380, pods alquilados, 50 fotos. Ambas incluyen entre 0.35 y 0.6 s de ida y vuelta de red y proxy que un contenedor en tu propia máquina no asume, por lo que servirlo en local es más rápido que estas cifras, no más lento. Precisión en la misma ejecución: 72.8 % de recuperación de elementos principales con cero alucinaciones en los 50 platos, estadísticamente indistinguible del modelo puntero en la nube que openplate usa por defecto.

Cualquier tarjeta de esa gama de unos 24 GB sirve. Eso es lo que medimos; no probamos una más pequeña.

Mínimo de VRAM. Los pesos ocupan 4.68 GiB (Q4_K_M) + 1.08 GiB (torre visual F16) = 5.8 GiB, y el conjunto de trabajo total medido con 8192 de contexto y 2 ranuras fue de 6.3 GB. Por tanto, una tarjeta de gama de 12 GB debería bastar con holgura y una tarjeta de 8 GB es viable pero muy justa (probablemente tendrías que reducir contexto o descargar parte del modelo). Esto es un cálculo teórico, no una cifra probada: 24 GB es el único tamaño que medimos. Si pruebas con 12 GB y funciona, es información útil.

La variable real es el ancho de banda de memoria, no la VRAM

La velocidad de generación en una sola petición está limitada por el ancho de banda: cada token recorre todo el conjunto de pesos activos. Las dos tarjetas medidas pertenecen aproximadamente a la gama de ~1,000 GB/s (RTX 4090 ≈ 1008 GB/s, RTX 3090 ≈ 936 GB/s), y sus p50 medidos lo reflejan: 0.94 s frente a 1.72 s.

Proyección, no una medición: una tarjeta de la gama de ~300 GB/s (L4 y la mayoría de tarjetas para estaciones de trabajo aptas para inferencia) tiene aproximadamente tres veces menos ancho de banda que la 3090, lo que la sitúa en un tiempo estimado de 4 a 6 s por análisis. Esta cifra es una estimación a partir de la fila de la 3090, no una medición, y los números reales suelen ser peores que una extrapolación lineal.

CPU: medido

Host para cada una de las filas inferiores: AMD Ryzen 9 7940HS, 14 hilos, sin GPU (-ngl 0), llama.cpp llama-server, contexto de 8192, las mismas 50 fotos.

lite: la fila que debes tomar como referencia al planificar. Medido el 13-08-2026 mediante el servicio en producción: este código exacto, su reducción a 896 px, su gramática, su mapeo de salida, 50/50 imágenes, 0 errores, peticiones secuenciales por loopback.

Fuente: eval/runs/2026-08-13-lite-cpu-v3/results.json. Esa ejecución midió únicamente la latencia, sin evaluar la precisión. La cifra de exhaustividad de lite proviene de una ejecución con diferente (2026-08-12: 62.1 % de exhaustividad en elementos clave, motivo por el cual lite se documenta como el mínimo para entornos limitados y no como la opción insignia). Dos ejecuciones, dos números, citados por separado.

La latencia aumenta tanto con el plato como con los hilos. El coste de un escaneo depende de la longitud de su prompt y de los tokens que el modelo lee para esa foto, y el prompt fue cuatro veces más largo para un desayuno completo que para un plato sencillo. Dos escaneos medidos a través del servicio suministrado sobre el mismo modelo de CPU, dentro de una máquina virtual de 6 vCPU con los 4 hilos predeterminados (2026-09-27):

Así, en una máquina estándar con CPU, cuenta con entre 5 segundos y un minuto por plato: el extremo inferior con muchos hilos y un plato sencillo, el superior con pocos hilos y uno abundante. Son dos escaneos aislados, no una distribución.

quality en la misma CPU: ≈94 s / plato (p50, 2026-08-12), medido con una versión previa más detallada del flujo y a resolución completa, sin volver a medirse con la versión final publicada, por lo que debe tomarse como un límite superior. quality es un perfil para GPU.

RAM (RSS medido): lite 1.55 GB, quality 6.31 GB.

El rendimiento de la CPU no mejora con la concurrencia. Medido: dos peticiones simultáneas consumen entre 0.75 y 0.83× respecto a ejecutarse una tras otra, lo que supone recuperar entre 1.2 y 1.3× de rendimiento frente a duplicar la concurrencia, pagándolo por completo en la latencia por petición (una sola petición: 2.5 s; dos en curso: 3.7 s cada una). Planifica la capacidad como si la máquina trabajara en serie.

Máquina mínima con CPU para lite: 8 o más núcleos modernos con AVX2, 4 GB de RAM libre (1.55 GB para el modelo, margen suficiente para el resto), unos 3 GB de disco (1.96 GiB de pesos más la imagen, aproximadamente 1 GB). Usar 8 hilos en lugar de 14 duplica aproximadamente la latencia por plato. Sin GPU, sin CUDA, sin llamadas externas, verificado mediante scripts/smoke-lite.sh, que compila la imagen de CPU, la arranca sin GPU y procesa una foto real a través de ella.

Sin límite máximo de latencia por defecto

LATENCY_CEILING_MS tiene por defecto 0, es decir, desactivado. Si la máquina descartara carga a partir de cierto umbral, rechazaría peticiones que puede atender perfectamente, y en CPU un análisis suele tardar entre segundos y minutos de forma habitual. La experiencia adecuada es asíncrona: tomas la foto, guardas el teléfono y el plato estará analizado la próxima vez que mires. Lo que no funciona en CPU es una vista previa en tiempo real que se actualice mientras encuadras la toma.

Si quieres definir un límite para tu propia máquina, asigna LATENCY_CEILING_MS=10000 y el servicio empezará a rechazar el trabajo que no pueda completar en diez segundos. La mayoría de quienes alojan su propia instancia deberían dejarlo desactivado.