Laya-MLX ejecuta decisiones tipadas en Apple Silicon a 13 ms, sin nube ni PyTorch

El repositorio mizorewww/laya-mlx ha pasado de cero a 4.722 estrellas en tres días, a un ritmo de 1.655 al día. Lo que propone es un runtime nativo de MLX para modelos de decisión tipada que resuelve una pregunta corta en 13,42 ms de mediana en un M3 Max, sin decodificar tokens, sin PyTorch y sin llamar a ninguna API en la nube.

Qué responde y cuánto tarda

La idea es acotar el problema. En vez de generar texto libre, el modelo contesta tres formatos cerrados: choice, probabilidades sobre opciones con nombre; score, probabilidades sobre niveles ordenados de una rúbrica y su puntuación esperada; y noul, la probabilidad de que una proposición sea cierta. Todo sale de una pasada bidireccional del encoder, no de un bucle de decodificación ni de un JSON generado a posteriori. El autor avisa de que las representaciones dependen a la vez del estado y de la pregunta, así que no se puede codificar el estado una vez y reutilizarlo para cualquier consulta.

Los números que publica, medidos en un M3 Max de 40 núcleos de GPU y 128 GiB, separan los dos checkpoints. El de 421M da 13,42 ms de mediana y 13,92 ms en el percentil 95, con 146,8 preguntas por segundo en lotes; el multilingüe de 322M baja a 7,39 y 7,79 ms y sube a 395,0 preguntas por segundo. La memoria pico de MLX en una pregunta corta es de 943,6 MiB y 687,6 MiB respectivamente. Son cifras del propio proyecto, no de un tercero, y el método excluye la carga del modelo del cómputo de latencia.

La demo y la letra pequeña

El repositorio incluye un Snake jugable en terminal, con la particularidad de que cada movimiento pasa por el modelo; una capa de seguridad visible puede corregir propuestas peligrosas. En la prueba emparejada sobre el mismo M3 Max, la ruta con compilación y reutilización de prefijo alcanza 75,40 movimientos por segundo a lo largo de 2.400 movimientos, sin muertes y con dos intervenciones de esa capa, un 6,5% más rápido que su control sin optimizar. Con max-speed, cada movimiento pide una decisión nueva.

Sobre fidelidad, los tres checkpoints coincidieron con la respuesta de referencia en las 63 preguntas de validación, tanto en FP32 como en FP16, lo que suma 378 comparaciones de 378. Cada configuración pasó además 100 llamadas repetidas, finitas y deterministas sin crecimiento de memoria activa. El propio README acota el alcance: eso mide fidelidad sobre ese conjunto, no acierto en cualquier pregunta.

Los requisitos son Apple Silicon, Python 3.11 o superior y macOS 14 o superior. El entorno medido fue macOS 27.2, Python 3.12.13 y MLX 0.32.2, cuya publicación trae ruedas para macOS 14, 15 y 26; el instalador eligió la de 26 y las versiones anteriores no se probaron en esa máquina.

El interés aquí no está en el modelo, sino en el patrón: inferencia local para decisiones acotadas, con latencias de milisegundos y sin arrastrar el ecosistema de PyTorch ni depender de un proveedor. La contrapartida es que esto solo corre en silicio de Apple y que se trata de un port independiente, no oficial, atado a los pesos y al esquema de salida del proyecto original.