Corrección de Tiempo de Espera de OpenClaw LLM para Carga de Modelo Frío
Problema: Tiempos de espera de modelos en frío a los 60 segundos
Los usuarios informaron que los modelos locales cargados en frío en OpenClaw fallaban consistentemente después de aproximadamente 60 segundos, a pesar de tener configurado un tiempo de espera general del agente mucho mayor. Este problema también ocurría con modelos en la nube a través de Ollama y, a veces, con OpenAI Codex.
El patrón típico de fallo:
- Los modelos funcionan si ya están calientes
- Los modelos en frío fallan alrededor de los ~60 segundos
- Los registros mencionan tiempo de espera / conmutación por error embebida / estado: 408
- El modelo de respaldo toma el control
Configuraciones engañosas
La fuente advierte que varias opciones de configuración obvias NO son la solución real y pueden llevar a los desarrolladores por el camino equivocado:
agents.defaults.timeoutSeconds- Exportaciones de
.zshrc LLM_REQUEST_TIMEOUT- Culpar inmediatamente a LM Studio / Ollama
Causa raíz
El problema surge porque OpenClaw tiene un tiempo de espera de inactividad del LLM del ejecutor embebido separado para el período antes de que el modelo emita el primer token transmitido.
Rastro de la fuente encontrado en:
src/agents/pi-embedded-runner/run/llm-idle-timeout.tsValor predeterminado:
DEFAULT_LLM_IDLE_TIMEOUT_MS = 60_000La ruta de configuración se resuelve desde:
cfg?.agents?.defaults?.llm?.idleTimeoutSecondsPor lo tanto, el parámetro de configuración real es:
agents.defaults.llm.idleTimeoutSecondsLa solución
Después de las pruebas, la configuración que funciona es:
{
"agents": {
"defaults": {
"llm": {
"idleTimeoutSeconds": 180
}
}
}
}Las pruebas mostraron que una llamada en frío a Gemma que antes fallaba alrededor de los 60 segundos sobrevivió más allá de ese umbral y finalmente respondió con éxito sin una conmutación por error inmediata.
Configuración permanente recomendada
{
"agents": {
"defaults": {
"timeoutSeconds": 300,
"llm": {
"idleTimeoutSeconds": 300
}
}
}
}La recomendación de 300 segundos tiene en cuenta que los modelos locales son impredecibles, donde las conmutaciones por error falsas son más problemáticas que esperar más tiempo para modelos genuinamente en frío.
📖 Leer la fuente completa: r/openclaw
👀 Ver también
Creación de un portafolio de desarrollador con Claude Code: Flujo de trabajo y lecciones aprendidas de un desarrollador junior
Un desarrollador júnior (MERN stack) de 21 años comparte cómo construyó nidhil.live usando Claude Code, destacando la importancia de indicaciones específicas y de entender el código generado en lugar de copiar y pegar a ciegas.
Usuario de Reddit comparte errores comunes al hacer prompts en Claude Code con sus soluciones.
Un desarrollador que usa Claude para trabajo backend en Node.js identificó 10 errores comunes al hacer prompts después de meses de uso, incluyendo omitir requisitos de validación y tratar a Claude como una herramienta de un solo uso. Crearon una guía visual con soluciones para cada problema.
¿Gastaste $850 en OpenClaw en un mes? Arregla tu arquitectura, no tu modelo
Un desarrollador gastó $850 en un mes en una configuración multiagente de OpenClaw, con $350 desaparecidos en un solo día. La solución no fue un modelo más barato, sino el diseño del sistema: poda estricta del contexto, reinicios de sesión, n8n para tareas que no requieren razonamiento, y un nivel de enrutamiento para modelos baratos frente a modelos potentes.
Corrección de velocidad de procesamiento de prompts en Llama.cpp usando el parámetro --ubatch-size
Un usuario descubrió que ajustar --ubatch-size para que coincida con el tamaño de la caché L3 de la GPU (64MB para Radeon 9070XT) mejoró drásticamente la velocidad de procesamiento de prompts para modelos grandes como Qwen 27B en Llama.cpp, haciendo que la invocación de código Claude sea utilizable.