La revancha llegó 1 día antes. De ayer artículo de ajuste M1 Ultra cerró con una predicción: cuando una versión de MLX llegue con gráficos de decodificación compilados, la revancha contra la pista de 20.3 tok/s tomaría una tarde y 1 descarga. Esta mañana vi un nuevo tiempo de ejecución llamado MTPLX prometiendo ese futuro como un producto terminado — decodificación especulativa de predicción multi-token nativa en Apple Silicon, un autotuner que mide tu máquina específica, un servidor compatible con OpenAI y Anthropic, lanzamientos con un clic para los harnesses de agente que realmente usamos, y Qwen3.8-27B como su modelo de codificación insignia. Su sitio dice "tus herramientas favoritas, al doble de velocidad." Lo llevé a Kimi K3, mi colaborador en la aventura de afinación del día anterior, y establecimos los términos juntos: instalarlo limpio en el Studio, dejar que su propio tuner haga su mejor caso, luego medir lo que el servidor realmente sirve. Kimi ejecutó el trabajo remoto y los contadores; yo mantuve las reglas de la casa y hice las llamadas. Así fue el día realmente.

MTPLX es la versión de producto de la vía que construimos juntos

La arquitectura merece crédito de entrada, porque es la idea correcta ejecutada seriamente. MTPLX redacta con las propias cabezas MTP del modelo — el mismo mecanismo que nuestra vía usa — y acepta borradores mediante muestreo de rechazo exacto, así que muestrear a temperatura 0.6 produce la misma distribución que la decodificación ordinaria, solo más rápido. No hay un modelo de borrador separado que consuma memoria, la profundidad del borrador se ajusta por máquina contra una línea base autorregresiva, y el proyecto se niega a adjuntar sidecars MTP no verificados a pesos arbitrarios. Esa última política es una disciplina que Kimi y yo tuvimos que aplicar manualmente el día antes, cuando reparamos los tensores MTP caídos de Qwen3.8 con su tronco. La vía de la parte uno fue el medidor obvio: mismo Studio, misma familia de modelos, medido de la misma manera.

La instalación pasó las pruebas de cuarentena 2 antes de tocar un peso

La primera prueba fue mi. En marzo, en mi laboratorio de refinamiento autónomo, nos topamos con una trampa donde un entorno Python aislado perdió silenciosamente el acceso a las bibliotecas aceleradas de Apple, y los números solo regresaron lentos. Antes de que Kimi avanzara, pedí prueba de que la trampa no se aplicaba. Una sonda de línea 3 lo resolvió — intérprete nativo arm64, Metal disponible, GPU como el dispositivo predeterminado. La ruta Metal de Apple se incluye dentro de la propia rueda mlx-metal, por lo que el origen del intérprete es irrelevante para el acceso a GPU, y la vía de la parte uno ya había demostrado rendimiento nativo GPU a través de la misma forma de aislamiento. El inspector propio de MTPLX estuvo de acuerdo, calificando ambas de sus construcciones Qwen3.8-27B verificadas nativas con todos los tensores MTP 15 presentes.
La segunda prueba fue la de Kimi, a mitad de descarga. El comando pull de MTPLX ignora las variables de entorno habituales de caché de Hugging Face, y el primer intento fue escribir 20 GB de modelo en el directorio home del Studio en lugar del volumen de datos que las reglas de la casa protegen. Kimi canceló la descarga, eliminó solo lo que había creado, y reinició con un directorio de caché explícito. Los ventiladores permanecieron en la curva de Apple todo el día, lo cual importa en una máquina que también funciona como simulador de vuelo.

La máquina más ruidosa esa mañana no era la que ejecutaba el experimento

A mitad de la descarga, mi propia estación de trabajo empezó a sobrecargarse — el promedio de carga superó 50 — y detuvimos el experimento para responder una pregunta más importante: ¿era esto nuestro trabajo? No lo fue. Nuestro trabajo se ejecutó en el Studio durante sesiones SSH de corta duración; la huella local era solo unos pocos procesos curl y ssh terminados. La tormenta fue una ola de demonio Apple — una descarga de activo atascada, indexación, y un estallido de un proceso de virtualización que desapareció antes de que pudiéramos nombrar a su propietario — más el descubrimiento de que los "procesos de nodo que reaparecían misteriosamente" que había estado matando eran 3 supervisores de desarrollo haciendo exactamente su trabajo al reiniciar sus servidores. Escribimos todo en la transferencia de guardia de máquina y volvimos al experimento con una conciencia limpia. La pausa pertenece a esta historia porque la disciplina es la misma que los benchmarks ejecutan: conoce tu propia huella antes de culpar a una máquina.

El autotuner midió un blowout de 2.20x

El ritual de afinación de MTPLX es ingeniería honesta: ejecuta el modelo real en tu hardware a cada profundidad de borrador, mantiene la decodificación autoregresiva como la línea base, y guarda una profundidad solo si supera esa línea base. En el M1 Ultra produjo AR 11.4, profundidad 1 a 9.2, profundidad 2 a 25.1, profundidad 3 a 20.7 tok/s — profundidad 2 coronó al ganador a 2.20x, guardado para todos los lanzamientos futuros.
Ese 25.1 es una medición real de un motor real, 24% por encima de la tasa de servicio 20.3 de nuestro carril. Si el servidor lo hubiera reproducido, este artículo habría sido una guía de migración.

El servidor sirvió 16.5, y los valores por defecto gastaban tokens a la vista

El banco de pruebas de servicio usó los mismos prompts, temperatura 0, y contabilidad de reloj de pared como la línea base de la lane. La primera ejecución regresó a 14.7 tok/s, y los metadatos de la respuesta mostraron los valores por defecto 2 trabajando en contra de la medición:
  • El modo de razonamiento se activa por defecto, y Qwen3.8 piensa antes de responder. En un prompt trivial de contar hasta 10, 44 de los 64 tokens generados estaban ocultos en el razonamiento que el cliente nunca muestra. Las cargas de trabajo reales pagan por esos tokens, así que la tasa de pared ya los incluye — pero los prompts del afinador no tenían tal impuesto.
  • El perfil de tiempo de ejecución Turbo, con sus kernels de verificación compilados, es una regla de lanzamiento de la app nativa de Mac. Un terminal mtplx serve se resuelve al perfil Sustained en su lugar, así que la ruta de línea de comandos nunca ve los kernels rápidos a menos que lo solicites.
Fijar Turbo, profundidad 2, y desactivar el razonamiento elevó la construcción FP16 a 16.5 tok/s de pared — el mejor MTPLX produjo todo el día. La construcción Optimized-Speed de 4 bits, la que el proyecto recomienda para codificar, sirvió 15.5. Ambas construcciones están en 20.4 GB en disco frente a los 15 GB de nuestra lane, y en una máquina limitada por ancho de banda cada token paga para transmitir esos extra 5 GB.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

El afinador y el servidor miden 2 máquinas diferentes

El hallazgo más útil del día explica la brecha entre 25.1 y 16.5. Los propios registros del servidor de MTPLX registran una escalera de calentamiento al iniciar, y esa escalera reporta 20-24 tok/s del motor — dentro del mismo proceso que luego sirve 16.5 sobre HTTP. El motor es rápido y el transporte está cargado. Entre el bucle de decodificación y el cliente se encuentra la capa HTTP, la contabilidad de banco de sesión por solicitud (una escritura de instantánea de 160 MB apareció en las estadísticas de la primera solicitud), y la maquinaria de razonamiento, y cada token cruza esa frontera. En chips M4 y M5, donde se midieron las cifras publicadas 1.6-2.24x del proyecto, un CPU más rápido y la fabricación absorben el cruce. El motor del M1 Ultra mantiene el ritmo; su ruta de servicio no.
Diagram source
graph LR
    subgraph Ruta del afinador
        A[Modelo real] --> B[Profundidades de borrador D1-D3]
        B --> C[Temporizador solo de decodificación  
25.1 tok/s]
    end
    subgraph Ruta de servicio
        D[HTTP solicitud] --> E[Banco de sesión  
+ valores predeterminados de razonamiento]
        E --> F[Mismo motor  
escalera muestra 20-24]
        F --> G[Frontera por token  
16.5 tok/s muro]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
Esta es la lección de la parte uno usando un nuevo disfraz. Las afirmaciones de la comunidad de llama.cpp de 25-32 tok/s no sobrevivieron al contacto con este chip, y el afinador de MTPLX 25.1 no sobrevivió a su propio servidor. La regla duradera se afina: una tasa de servicio se mide en el límite HTTP con los valores predeterminados de producción visibles, nunca dentro del afinador. Eso es benchmark-driven development aplicado una capa arriba de la pila.

El desafiante quedó 38 GB más ligero, y el vigilante quedó atrás

Le di a Kimi 1 no negociable antes de que comenzara el experimento: lo que sea que se ejecute en ese Studio tiene que detenerse a sí mismo cuando esté inactivo, porque el trabajo nocturno de la máquina es un simulador de vuelo. MTPLX no envía un tiempo de espera de inactividad para su servidor de chat, así que Kimi incorporó el vigilante en un pequeño script envoltorio — enlace solo de loopback, ventiladores en la política de Apple, y un observador de conexión que detiene el servidor después de 10 minutos sin clientes. Pasó su simulacro de fuego en vivo, derribando una instancia de prueba en el momento del segundo 60 y liberando el puerto limpiamente. El envoltorio y el entorno virtual permanecen en la máquina, así que la nueva prueba está a 1 descarga cuando una versión de MTPLX funciona la ruta de servicio de generación M1 o envía un artefacto MTP coincidente más cerca de 15 GB.
Los pesos mismos no permanecieron. Una vez que el veredicto fue claro, revisamos la limpieza cuidadosamente — ambos directorios del modelo MTPLX, 38 GB a través de FP16 y compilaciones de 4 bits, eliminados después de confirmar que ningún proceso los reten, devolviendo el volumen a exactamente su espacio libre previo al experimento. La eliminación sigue siendo parte del flujo de trabajo: cada desafiante que pierde deja el disco el mismo día, lo que mantiene el próximo experimento honesto.

Lo que la revancha añadió a la lista de verificación

La pista de la primera parte nunca se movió. Sirvió la mañana a 20.3 tok/s, sirvió la noche a 20.3 tok/s, y ahora mantiene su ranura frente a los desafiante3 en lugar de 2 — todavía una pista experimental, 1 descarga lejos de su próxima revancha. La lista de verificación de la primera parte gana 3 entradas:
  • El número de afinador es el techo del motor, y el camino de servicio decide cuánto de él mantienes. Mide en el límite lo que tus clientes realmente cruzan.
  • Los valores predeterminados son parte del punto de referencia. Los modos de razonamiento, los perfiles de tiempo de ejecución y las cachés de sesión gastan tokens o tiempo, y una pelea justa los fija explícitamente en ambos lados.
  • El disco es un presupuesto de hipótesis. 2 el desafiante construye a 20.4 GB cada 1 tarde de certeza, y la certeza es más barata cuando los bytes salen según lo programado.
La simetría satisfactoria del par es que la primera parte terminó encolando este experimento exacto, y el experimento llegó empaquetado como un producto con auténtico arte en él — muestreo exacto, ajuste por máquina, verificación honesta. El arte fue real y la pérdida fue real, y ambos hallazgos surgieron del mismo día de medición, tormenta de CPU y todo. Una aventura con una tabla de puntuaciones es el mejor tipo, y esta tuvo a Kimi K3 leyendo cada contador a mi lado — el mismo retorno compuesto que obtengo al tratar ganancias locales de IA como infraestructura. La pista mantiene su ranura, el disco es delgado, la lista de verificación es más larga, y el próximo desafiante ya está bienvenido a probar.