Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés
Configuración y diagnósticos de rendimiento
Estado: Activo
Alcance: estado actual
Última revisión: 2026-09-13
Responsable: runtime de ax-code
Elegir un perfil de herramientas
Para las sesiones de programación que no necesitan operaciones de infraestructura, programación de tareas, generación de imágenes ni análisis especializado,
define toolProfile como coding para el proveedor conectado en tu configuración de AX Code:
{
"provider": {
"your-provider-id": {
"options": {
"toolProfile": "coding"
}
}
}
}
Sustituye your-provider-id por el ID del proveedor conectado. Esto conserva la inspección y la edición de archivos, el trabajo de shell y en segundo
plano, la delegación, los cuadernos, los objetivos, las skills, la memoria y la verificación de revisión. Las herramientas web y las opcionales siguen
sus reglas existentes de activación y de permisos. Las herramientas personalizadas y de MCP conservan sus reglas de admisión y pueden sumar
al tamaño de la solicitud.
Usa full cuando necesites council o arena, operaciones, programación de tareas, generación de imágenes o herramientas de análisis especializado. Los
proveedores de nube usan de forma predeterminada full; AX Engine conserva su valor predeterminado más pequeño core. coding no cambia el esfuerzo de razonamiento,
los permisos, la captura de instantáneas ni los requisitos de verificación. Su efecto sobre la velocidad y el éxito de la tarea depende del modelo
y de la carga. Consulta Esfuerzo del modelo para los controles explícitos de razonamiento.
Separar la preparación local del tiempo de respuesta del proveedor
Activa el perfilado local de una ejecución:
AX_CODE_PROFILE_NATIVE=1 ax-code run --model your-provider-id/your-model "Your task"
ax-code session replay YOUR_SESSION_ID --mode export
El perfil de salida en stderr incluye los tramos session.insertReminders, session.preparePromptRequest, session.preflight,
session.resolveTools y de instantánea track/patch. Son mediciones agregadas; los tramos anidados o solapados
no deben sumarse como tiempo de reloj de la tarea. El propio perfilado añade sobrecarga de medición.
Los eventos llm.response registrados ganan un objeto opcional timing:
| Campo | Significado |
|---|---|
boundary |
provider-adapter: observado en el adaptador del modelo, antes del manejo del resultado de herramienta del SDK |
attempt |
Número de intento del adaptador dentro de esta llamada LLM.stream; los otros campos describen este intento |
setupMs |
Tiempo desde la entrada en LLM.stream hasta este despacho del adaptador; en un reintento incluye los intentos anteriores y la espera |
firstContentMs |
Del despacho al primer delta no vacío de texto, de razonamiento o de entrada de herramienta, o a la llamada de herramienta completa |
firstTextMs |
Del despacho al primer delta de texto no vacío; ausente en una respuesta solo de herramienta o solo de razonamiento |
streamMs |
Del despacho al fotograma de fin del adaptador; ausente cuando no se observó un fotograma de fin |
Los fotogramas de metadatos y de inicio de flujo no cuentan como contenido. Los tiempos usan un reloj monótono y reflejan cuándo se observan los fragmentos,
incluida cualquier contrapresión del flujo. No son tiempos de red en bruto, tiempos de inferencia del servidor ni tiempos de representación de la TUI.
Los adaptadores de CLI pueden incluir el trabajo propio de la CLI hija. El latencyMs existente conserva su tiempo de paso mixto más antiguo
y puede incluir la ejecución de herramientas y el trabajo de instantánea. Los campos de tiempo nuevos contienen solo duraciones y la identidad del intento.
Sin AX_CODE_PROFILE_NATIVE=1, se omite el objeto de tiempo adicional. El perfilado usa diagnósticos locales y el
registro de eventos de sesión existente; no activa un exportador de telemetría externo.
Para una comparación útil, mantén constantes la tarea, la revisión del repositorio, el endpoint del proveedor, el modelo exacto, el esfuerzo de razonamiento, los permisos de herramientas y las condiciones de caché. Registra el tiempo de la primera respuesta visible y el tiempo hasta un resultado verificado, incluidas las pruebas y los intentos de reparación. Una solicitud más pequeña o una instantánea local más rápida, por sí solas, no establecen que la tarea en la nube termine antes.
Usa controles del harness y evaluación verificada para probar la recuperación de contexto, el descubrimiento de MCP, recetas de solo lectura y comparaciones de fixtures emparejadas con verificación independiente.
Entender el tamaño de la solicitud
Los eventos nuevos llm.request en ax-code session replay YOUR_SESSION_ID --mode export incluyen requestBytes cuando hay procedencia de la solicitud:
| Campo | Significado |
|---|---|
encoding |
canonical-json-utf8: longitud en bytes de la representación canónica existente de la huella |
system |
La matriz de mensajes de sistema ensamblada por separado |
messages |
La matriz completa de mensajes ensamblada, incluidos los mensajes de sistema |
toolDefinitions |
Nombres de herramientas activas, descripciones y esquemas de entrada resueltos |
system ya está representado dentro de messages; no los sumes. Se incluye el encuadre de la matriz. Los valores binarios usan la representación de resumen existente, así que estos tamaños no son tamaños de carga de red ni mediciones de memoria residente. No son recuentos de tokens: el uso de tokens del proveedor y los contadores de caché siguen siendo la fuente de la contabilidad de entrada del modelo. Un resumen del paquete de contexto cubre una etapa más estrecha y no es la entrada total del modelo. Los eventos heredados omiten este campo; la procedencia fallida permanece explícitamente no disponible.
Este diagnóstico solo registra tamaños y los hashes y metadatos existentes. No se guardan cuerpos de prompt ni credenciales adicionales. Reutiliza la serialización canónica necesaria para cada hash en lugar de tokenizar la solicitud. Compara tamaños en turnos equivalentes al decidir si las instrucciones de sistema, las definiciones de herramientas o un historial que crece necesitan atención. El perfil de programación de arriba puede reducir las definiciones de herramientas sin cambiar el esfuerzo de razonamiento; el completo sigue disponible para las capacidades que añade.
Evitar exploración redundante
Para buscar un archivo conocido o un recuento sencillo, usa una búsqueda enfocada o un solo comando agregado. Resuelve las rutas contra el directorio actual del espacio de trabajo; una sesión iniciada dentro de un paquete ya tiene ese paquete como raíz de búsqueda. El grep integrado usa la sintaxis de expresiones regulares predeterminada de ripgrep, sin lookaround ni referencias hacia atrás.
Usa un investigador para un camino de llamadas. Las tareas paralelas de solo lectura deben tener entregables distintos y rutas o subsistemas propios, con la evidencia existente aportada en sus informes. Una revisión independiente puede volver a la evidencia para una pregunta de verificación aparte. Repetir el descubrimiento en varios contextos nuevos cuesta rondas de modelo aunque la caché de evidencia acierte; los aciertos de caché no eluden la validación del contenido actual ni los permisos.
Los servidores de lenguaje arrancan ahora bajo demanda de forma predeterminada. Consulta Uso de memoria para la activación optativa del precalentamiento especulativo y el compromiso con la latencia de la primera consulta semántica. La orientación del prompt y las pruebas locales no establecen una reducción concreta de las llamadas al modelo en vivo ni de la RAM física.