Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.5 · SDK 2.6.9. Original en inglés

Mediciones de inferencia local: 19 September 2026

Estado: Activo

Alcance: instantánea de diagnóstico medida

Última revisión: 2026-09-19

Responsable: runtime de ax-code

Para la matriz completa de seis combinaciones de cliente después de la corrección del prefijo local, consulta la nueva repetición de prueba de AX Code/OpenCode. Las velocidades de cliente de abajo siguen siendo observaciones históricas en sus condiciones originales.

Estas mediciones investigan la latencia de respuesta local y la velocidad de decode en un Apple M3 Max con 128 GiB de memoria unificada. No son una cualificación de hardware, una evaluación de calidad del modelo ni una promesa de 30–40 tokens/s con longitudes de contexto arbitrarias. Las instrucciones de conexión de MTPLX y oMLX están en la guía del entorno de ejecución local.

Condiciones y tiempos

• Código fuente de AX Code basado en v7.19.3; OpenCode 1.18.31; AX Engine 7.4.0; MTPLX 2.11.3; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, instalación de código fuente aislada).
• Un backend de inferencia a la vez. Control de ventilador predeterminado; no se afirma un ventilador al máximo. Los archivos del modelo residían en almacenamiento SMB. La ejecución de artefacto exacto de MTPLX solo preparó el sidecar MTP en SSD, con su SHA-256 verificado.
• Las repeticiones de artefacto exacto usaron AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, revisión 4d36d652c21590f6813495351c3baf5fca5b3831. Las ejecuciones de cliente aparte de MTPLX Optimized-Speed usaron Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. Son paquetes de modelo distintos, aunque el tamaño total de sus archivos es parecido; sus tasas no pueden aislar una aceleración debida solo al entorno de ejecución.
• Ajustes comunes de repetición: temperatura 0.55, top-p 1, top-k 0, semilla 0, hasta 256 tokens generados. AX Engine y MTPLX usaron MTP activo de profundidad 3. Los núcleos del entorno y los muestreadores especulativos difieren. Los metadatos del artefacto declaran profundidad 1; la profundidad 3 aquí es un experimento explícito del entorno de ejecución, no una ampliación de la certificación del artefacto ni una recomendación predeterminada nueva. AX Engine ignoró EOS en su repetición nativa de salida fija; MTPLX y oMLX siguen sus propias reglas de parada.
• La tasa de decode nativa usa los contadores de decode del backend. La tasa entregada es (reported completion tokens - 1) / (last output payload time - first output payload time); los eventos vacíos y los keepalives no cuentan como salida. Estos límites no son idénticos.
• La latencia del primer payload incluye la preparación de la solicitud en el servidor, la restauración de caché o el prefill, y cualquier búfer antes de la salida. El total de tokens dividido por la solicitud entera es otra medida de rendimiento. Las ráfagas de llamadas a herramientas no sirven para estimar el decode desde el primer payload hasta el último.

Por ejemplo, la misma repetición de MTPLX con 30k de entrada midió 13.99 tokens/s de decode nativo, pero solo 1.13 tokens/s en la solicitud completa, porque el prefill en frío consumió unos 209 segundos. Un número bajo de la solicitud entera, por sí solo, no demuestra un fallo del motor de decode.

Repetición de AX Engine y MTPLX con pesos exactos

Cada par recibió la misma secuencia entera de tokens de entrada y emitió 256 tokens. Los valores de abajo son observaciones únicas; las identidades de los tokens generados pueden diferir pese a una semilla común.

MTPLX usó su perfil Sustained para este artefacto. La solicitud de 30k de AX Engine estaba en caliente mientras MTPLX estaba en frío, así que sus tiempos del primer token no pueden establecer una relación de velocidad de prefill. La entrada de 30k incluye una instrucción histórica de límite de pasos y produce prosa de diagnóstico; no es la aceptación de una tarea de programación. La repetición de MTPLX de 18,643 tokens informó stop después de 256 tokens, en lugar de length.

El prompt corto muestra tasas de decode parecidas. Estas ejecuciones no demuestran que uno de los backends sea siempre más rápido, ni que cambiar AX Code a otro backend garantice una aceleración fija.

AX Code y OpenCode en MTPLX Optimized-Speed

Ambos clientes recibieron la misma tarea de usuario, las instrucciones completas del proyecto y cuatro esquemas de herramientas permitidos. La tarea pedía una caché LRU en TypeScript sin ejecutar herramientas. Se conservaron los prompts específicos de cada cliente; un proxy de grabación alineó el muestreo, desactivó el pensamiento y usó un techo de solicitud y servidor de 1024 tokens. Las respuestas siguientes terminaron con normalidad:

Estas mediciones son anteriores a la corrección del prefijo local de AX Code (42908b46a). AX Code envió más contexto y produjo código distinto. No es una comparación de sobrecarga de cliente con los mismos tokens ni un resultado de antes y después. Quitar solo el mapa de directorios explorado de forma automática, en una repetición aparte, redujo la entrada a 30,717, pero mejoró el decode observado solo en torno a un 2 %; no se adoptó quitar el mapa de directorios.

Una matriz aparte del adaptador de AX Engine observó AX Code a 9.44–11.56 t/s entregados con 33,225 tokens de entrada y OpenCode a 12.82–13.00 con 17,290. Las longitudes del prompt, el contenido de salida, el estado de la caché y el techo de salida de 256 tokens difieren de la tabla de respuestas completas de arriba; no los combines en una sola relación de aceleración del backend.

oMLX

La prueba de oMLX usa el artefacto AXQ exacto y una instalación aislada con MLX 0.32.0. Las cinco comprobaciones de importación del núcleo nativo, incluidas qwen35_prefill y decode_fast, pasaron. La carga solo de texto se elige de forma explícita, la ventana de contexto es 65,536 y la concurrencia es uno.

El intento inicial de Lightning MTP devolvió HTTP 409 porque la prueba omitió el paso exigido de oMLX Importar el sidecar MTP. Fue un error de configuración, no una falta de soporte de AXQuant. AXQuant ya aportaba el contrato canónico qwen3-next-mtp; la revisión actual del Hub b0784088d4026ca569c5653e6e6243c501ef5fa9 también incluye axquant_omlx_compat.json, que enumera 15 tensores MTP. La instantánea original de la repetición es anterior a esa anotación.

La línea base con MTP desactivado terminó con el artefacto original:

Son resultados con MTP desactivado y no deben compararse con entornos con MTP activo como evidencia de una diferencia de velocidad inherente del backend. Los viajes de ida y vuelta del tokenizador y los recuentos de prompt del servidor coincidieron con las entradas enteras usadas por los otros backends de repetición.

La ejecución MTP corregida usa el importador propio de oMLX sobre una copia escribible aparte. Los fragmentos del backbone no cambian. El importador añade language_model. a los 15 nombres de tensores del sidecar; se verificó que el dtype, la forma y el hash de carga de cada tensor eran iguales antes y después de la importación. El hash del archivo importado, por tanto, difiere porque cambió su cabecera. Los metadatos originales y la instantánea compartida del modelo permanecen intactos. La profundidad MTP 3 se elige de forma explícita, y los contadores de borrador y aceptación por profundidad confirman la ejecución real.

El resultado corto confirma que este paquete AXQuant funciona con oMLX Lightning MTP después de la importación. El decode de contexto largo sigue siendo más lento pese al MTP activo. El texto generado distinto, las versiones del entorno, los núcleos y las políticas especulativas impiden atribuir todas las diferencias entre entornos a AX Code.

Aceptación del flujo de programación y exclusiones

Después de la corrección del prefijo local, AX Code completó una tarea aislada de solo lectura tanto en AX Engine como en MTPLX: leer un directorio y dos archivos TypeScript, explicar la excepción de cola llena, identificar la capacidad 7 y devolver un marcador que solo está en el segundo archivo. Ambas salieron con éxito y conservaron los bytes del fixture. Las llamadas posteriores de AX Engine reutilizaron 11,264 tokens de entrada; MTPLX reutilizó 11,264–12,032. Los cuerpos de la primera solicitud eran idénticos, pero las plantillas del entorno produjeron recuentos de tokens distintos. Esto verifica el flujo de herramientas y la reutilización de caché observada, no una aceleración fija debida al parche.

Los ID de proveedor nuevos también superaron la aceptación en vivo desde la CLI de código fuente: omlx con el paquete AXQ importado y tool_call: true explícito, y mtplx con el paquete Optimized-Speed y sin entradas de modelo configuradas. MTPLX descubrió su modelo de chat y la capacidad de herramientas a partir del listado nativo de modelos. Ambas ejecuciones completaron dos lecturas de archivo correctas y devolvieron la excepción, la capacidad y el marcador exclusivo del archivo esperados, sin cambiar los bytes del fixture. El prefijo inicial de sistema y usuario permaneció idéntico en las tres solicitudes de cada ejecución. oMLX reutilizó 8,192 tokens; MTPLX reutilizó 11,829 y 12,047 tokens. Son comprobaciones funcionales, no ejecuciones de rendimiento emparejadas; no se afirma una aceleración de tiempo de reloj entre entornos.

Las respuestas anteriores de AX Code limitadas a 256 tokens se truncaron y entraron en recuperación; sus tasas de salida repetida en torno a 51–58 t/s quedan excluidas de las afirmaciones de generación fresca. También se excluyen las ejecuciones iniciales con instrucciones de proyecto o permisos de herramientas desiguales. Ollama y LM Studio se inspeccionaron solo por la construcción de la solicitud; no se afirma ningún resultado de tasa de generación para ellos.

El prompt genérico de 62 tokens es público como solicitud exacta de completado de oMLX. Desde la raíz de la copia de trabajo, después de importar el sidecar, activar MTP y calentar el modelo, se puede enviar con:

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

Cambia el ID de modelo de la solicitud por el ID que expone tu servidor. El archivo incluye la plantilla representada; usa el endpoint de completions para que una plantilla de chat no se aplique una segunda vez. Confirma 62 tokens de prompt y conserva el evento final de uso. La carga en frío del modelo y el calentamiento deben informarse aparte.

No se publican las instrucciones privadas del proyecto, los prompts de sesión, las rutas locales ni los detalles de autenticación. Los datos de medición saneados contienen recuentos, tiempos, identidad del entorno y hashes de entrada, no texto de prompt. La repetición completa con contexto privado, por tanto, no es una carga de trabajo pública reproducible por sí sola. Para una comparación nueva, usa la misma revisión de modelo, tokenizador y plantilla, ID de entrada, reglas de salida y parada, muestreo, modo MTP, estado de caché, hardware y ejecución en serie; informa aparte del éxito de la tarea completa.

Contratos de origen: guía del servidor y los modelos de MTPLX, oMLX 0.6.4. Sus pruebas publicadas usan otro hardware y otras cargas, y no sustituyen a las mediciones de aquí.