Perplexity liberó como código abierto Lily, el motor de inferencia local que está detrás de Hybrid Compute en Perplexity Computer. Se trata de un runtime de proceso único: una capa en Rust carga el checkpoint y conduce el ciclo de generación, una API de chat compatible con OpenAI transmite los tokens, y kernels Metal escritos a mano ejecutan el modelo. Ni PyTorch ni MLX participan del camino de ejecución.
Lily es deliberadamente estrecho, con un solo modelo, Qwen3.6-35B-A3B, sobre una sola familia de hardware. Esa estrechez es precisamente el argumento de rendimiento.
¿Qué se necesita para correrlo hoy?
Hay una demostración autónoma pública en el repositorio pplx-garden: un servidor de inferencia en Rust y Metal que ofrece generación de texto por una API HTTP mínima compatible con OpenAI.
El checkpoint de 4 bits pesa 19,4 GB, así que el piso realista es un Mac con Apple Silicon y 32 GB o más de memoria unificada. El producto comercial Hybrid Compute que ya distribuye Perplexity exige macOS 15 o superior, con 24 GB de mínimo y 32 GB para el mejor resultado.
Para dimensionar el costo local: un Mac mini M4 Pro con 24 GB parte cerca de los 1.400 dólares en el mercado estadounidense, y en Chile los equipos con 32 GB de memoria unificada rara vez bajan del millón y medio de pesos con IVA. No es un motor para cualquier notebook, sino para una estación de trabajo dedicada.
¿Por qué especializar en vez de usar MLX?
El stack por defecto en Mac es MLX más MLX-LM, que ya incluye una implementación de Qwen con trabajo agrupado de expertos, un kernel Metal recurrente fusionado y atención consciente de GQA. El problema es que sus operaciones deben seguir siendo reutilizables entre arquitecturas distintas.
Lily renuncia a eso y concentra la estructura del modelo, los planes de ejecución y la selección de kernels en un solo runtime.
Tres formas de carga en un mismo modelo
Qwen3.6-35B-A3B almacena 35.000 millones de parámetros y activa cerca de 3.000 millones por token. Un enrutador puntúa 256 expertos y elige ocho, junto a un experto compartido que ve todos los tokens. También mezcla 10 capas de atención completa con grouped-query attention (16 cabezales de consulta, dos de clave y valor) y 30 capas Gated DeltaNet.
De ahí salen tres patrones de trabajo distintos: grupos de expertos desparejos, atención sobre una caché de clave y valor que crece, y una recurrencia de tamaño fijo.
Prefill: pesos comprimidos y enrutamiento en la GPU
El checkpoint usa cuantización afín por grupos de 4 bits: cada grupo de 64 pesos comparte una escala y un sesgo en bfloat16, con lo que unos 70 GB de pesos en bfloat16 quedan comprimidos en 19,4 GB. Como las operaciones tensoriales de Metal 4 consumen bfloat16, los pesos deben reconstruirse primero.
Lily hace esa reconstrucción de a un mosaico por vez dentro del GEMM agrupado, mantiene los resultados en memoria del grupo de hilos y acumula en FP32, de modo que el arreglo expandido nunca llega a la memoria unificada. En la prueba de ablación de Perplexity, esa fusión elevó el prefill de punta a punta un 77,4% con un prompt de 512 tokens.
Mantener el histograma de enrutamiento, el barrido de prefijos, el scatter y el mapa de bloques dentro de un solo búfer de comandos de la GPU agregó otro 89% a 512 tokens, al eliminar la sincronización con la CPU dentro de cada capa de expertos. Pasar de mosaicos de 16 filas a 32 filas con cuatro simdgroups sumó 13,2% a 2K, y un barrido de Gated DeltaNet residente en registros aportó 5,6%. Los GEMM de expertos concentran cerca del 90% del tiempo de prefill.
Decode: mover menos bytes por token
Con lote de tamaño 1 casi no hay reutilización de pesos, así que el ancho de banda fija el techo. Un paso registrado lanzó 795 kernels que formaban 555 etapas secuenciales; Lily registra las dependencias reales en un pase concurrente de Metal para que los kernels independientes se superpongan.
El token seleccionado se escribe directo en la ranura de entrada del paso siguiente, ya residente en la GPU, lo que elimina una ida y vuelta a la CPU por token, y cuatro cadenas de kernels se fusionan para mantener los intermedios en registros.
Las lecturas coalescentes de la caché subieron el ancho de banda de claves de 33,8 a 47,9 GB/s y el de valores de 42,0 a 61,8 GB/s. El empaquetado GQA, con cuatro cabezales de consulta compartiendo un grupo de hilos para que cada fila de clave y valor se cargue una sola vez, mejoró el decode 23,8% a 32K. Una disposición de atención por bloques fijos desde 32K en adelante mejoró 7,7% a 32K, 27,4% a 64K y 40,2% a 128K.
Lily contra MLX-LM: los números medidos
Perplexity midió sobre un M5 Max de 40 núcleos y 128 GB, con lote 1, cargando los mismos bytes de checkpoint de 4 bits contra la ruta de generación directa más rápida de MLX-LM, en diez largos que van de 256 a 128K tokens.
| Métrica (M5 Max, lote 1) | Lily | MLX-LM | Ventaja |
|---|---|---|---|
| Prefill promedio | 4.156 tokens/s | 3.388 tokens/s | 1,23x |
| Decode promedio | 170,0 tokens/s | 126,4 tokens/s | 1,35x |
| Prefill con prompt de 4K | 5.749,9 tokens/s | 4.737,5 tokens/s | 1,21x |
| Decode con contexto de 4K | 186,6 tokens/s | 140,9 tokens/s | 1,32x |
Lily fue más rápido en todos los puntos registrados, con rangos de 1,12x a 1,42x en prefill y de 1,31x a 1,37x en decode. Una verificación con teacher forcing sobre 192 posiciones dejó la perplejidad de Lily apenas 0,04% más alta, con el mismo token mejor rankeado el 96,35% de las veces.
Lo esencial
- Lily es un motor en Rust y Metal para Qwen3.6-35B-A3B sobre Apple Silicon, sin PyTorch ni MLX en el camino de ejecución.
- Promedia 1,23x el prefill de MLX-LM y 1,35x el decode en un M5 Max de 40 núcleos y 128 GB.
- Las mayores ganancias en prefill: enrutamiento de expertos residente en GPU (89%) y descuantización fusionada en el GEMM agrupado (77,4%).
- Las mayores ganancias en decode: empaquetado GQA (23,8% a 32K) y atención por bloques fijos (40,2% a 128K).
Los detalles técnicos y el repositorio en GitHub están publicados.
