Optimización de AutoResearch en RTX 5090: Lo que falló y lo que funcionó
Problemas Iniciales y Camino Funcional
La configuración inicial para ejecutar AutoResearch en un sistema RTX 5090/Blackwell estaba "seriamente dañada" con un rendimiento extremadamente pobre—solo unos pocos miles de tokens por segundo y una MFU (Utilización de FLOPs del Modelo) esencialmente inútil, a pesar de que el código técnicamente se ejecutaba.
El camino de configuración funcional involucró:
- Evitar la ruta de compilación completa del modelo dañada en esta configuración
- Mantener las mejoras de compilación del optimizador fusionado donde realmente ayudaban
- Usar la ruta de atención SDPA/CuDNN estable
- Ajustar el lote total y el presupuesto de tiempo empíricamente en lugar de adivinar
- Automatizar el ciclo de evaluación/extracción/estrategia/reejecución
Lo que Falló
Varios modos de falla fueron engañosos:
- Una ruta que era técnicamente correcta pero catastróficamente lenta
- Interpretación engañosa de MFU hasta que el denominador se corrigió para el contexto 5090
- Configuraciones de lote por dispositivo más altas que parecían que deberían ayudar pero que en realidad empeoraban mucho las cosas
- Errores de automatización alrededor de la limpieza de bloqueos/ganchos de finalización/orden de despacho
Como señaló el desarrollador: "Había varias formas de obtener una ejecución que parecía viva mientras hacía algo estúpido."
Lo que Ayudó
Las mejoras reales vinieron de:
- Reactivar la ruta de compilación del optimizador fusionado
- Reducir el lote total de la configuración original más grande
- Validar 2**17 como la región de lote total mejor
- Aumentar el presupuesto de tiempo una vez que se encontró el régimen de lote estable
- Tratar la automatización como parte del sistema de evaluación, no como una idea tardía
Progresión del Rendimiento
La progresión de ejecuciones útiles mostró mejoras claras:
- Ejecución de referencia saludable: val_bpb: 1.165452, mfu: 40.49%
- Mejora de compilación del optimizador fusionado: val_bpb: 1.155400, mfu: 42.88%
- TOTAL_BATCH_SIZE = 2**18: val_bpb: 1.108381, mfu: 43.18%
- Validación TOTAL_BATCH_SIZE = 2**17: val_bpb: 1.089424, mfu: 43.03%
- Mejor resultado actual del bucle automático: TOTAL_BATCH_SIZE = 2**17, TIME_BUDGET = 1200, multiplicador LR = 1.0, val_bpb: 0.999445, mfu: 42.56%, total_tokens_M: 387.8, num_steps: 2959
Mejor Configuración Actual
El mejor resultado encontrado hasta ahora:
- TOTAL_BATCH_SIZE = 2**17
- TIME_BUDGET = 1200
- Multiplicador LR = 1.0
Esta combinación superó a variantes de lote más grandes, la variante más pequeña 2**16, una prueba de LR más baja y presupuestos de entrenamiento más cortos.
Conclusiones Clave
La lección principal fue que la configuración ganadora no era una configuración de "máximo todo". El mejor camino involucró un régimen de lote estable, un horizonte de entrenamiento más largo y la eliminación cuidadosa de errores de automatización y backend.
El desarrollador enfatizó que si estás trabajando en entrenamiento Blackwell/5090 y ves comportamientos extraños, "puede que no sea tu imaginación. Algunas rutas son simplemente mucho peores de lo que parecen al principio". La parte útil de este ejercicio fue encontrar una ruta que sea estable, automatizable, reproducible y lo suficientemente buena para construir experimentos de seguimiento reales sobre ella.
📖 Leer la fuente completa: r/LocalLLaMA
👀 Ver también
Guía: Implementación de OpenClaw con llama.cpp en la Mini PC GEEKOM IT15
Un recorrido técnico detalla cómo cambiar OpenClaw de Ollama a llama.cpp para ejecutar un modelo local Qwen3-8B con aceleración de GPU Intel Arc, cubriendo cambios de configuración, gestión manual del servidor y solución de problemas comunes.
Puedes Ejecutar OpenClaw: Tres Caminos hacia un Agente de IA (Sin Necesidad de Terminal)
El instalador de una línea de OpenClaw, las plataformas gestionadas y los modelos locales de ollama eliminan la barrera técnica. Elige tu camino y empieza con tareas aburridas.
OpenClaw 2026.3.7 interrumpe las llamadas a herramientas de Kimi, revertir a la versión 2026.3.2 soluciona la regresión.
La versión 2026.3.7 de OpenClaw tiene una regresión donde el proveedor de la API de Kimi genera XML <function_calls> crudo en lugar de ejecutar herramientas. La solución es volver a la versión 2026.3.2 y restaurar un archivo de configuración compatible.
Optimización de la Configuración de OpenClaw: Patrones e Ideas Prácticas
Los usuarios de OpenClaw comparten patrones de configuración efectivos, como el uso de cron para tareas programadas y la creación de subagentes especializados, para mejorar la funcionalidad y la eficiencia de costos.