Saltar al contenido principal
ENES
Trae el proceso que no despega →

InferNode no responde o devuelve 504

Síntoma​

Depende de desde dónde llames:

  • Con curl o con el SDK, la petición a chat/completions tarda uno o dos minutos y termina con HTTP 504 y este cuerpo:

    {"error":{"type":"provider_error","code":"provider_timeout","message":"http POST timed out","param":"model.url_completions","request_id":"req_…"}}

  • Justo después de varios fallos, el mismo modelo devuelve durante unos segundos un error distinto, con el tiempo de espera en el mensaje:

    {"error":{"type":"provider_error","code":"provider_circuit_open","message":"breaker open for http:chat_completions; retry after 30s","request_id":"req_…"}}

  • En OpenCode, el comando opencode run termina sin escribir nada y sin mensaje de error; en la interfaz interactiva el turno se cierra vacío.

  • En Studio, los agentes que usan ese modelo responden "El agente tardó demasiado en responder" o pasan a Requiere atención (El agente no responde).

Si ni siquiera obtienes el 504 y la conexión se rechaza o expira sin cuerpo, es la segunda causa de abajo.

Causa​

  • El modelo no responde. InferNode recibió la petición, la enrutó al modelo y este no contestó a tiempo. El gateway sigue vivo: por eso devuelve un error con formato y request_id. Suele afectar a un solo modelo (el que está caído o saturado) mientras los demás responden. Cuando un modelo falla varias veces seguidas, InferNode deja de enviarle peticiones durante unos segundos y responde provider_circuit_open con el tiempo de espera; pasado ese tiempo vuelve a intentarlo solo.
  • InferNode no está disponible. No hay respuesta de ningún tipo, o llega un 502/503 para cualquier modelo. Suele coincidir con mantenimiento o con una caída de la instalación.

Cómo confirmarlo​

  1. Prueba el gateway sin llave. Si responde 401 en menos de un segundo, InferNode está arriba y el problema es del modelo:

    curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.<tu-dominio>/infernode/v1/me

  2. Prueba otro modelo con una petición mínima. Si Saptiva Turbo responde y el que usabas da 504, es la primera causa:

    curl -s -m 120 https://api.<tu-dominio>/infernode/v1/chat/completions \
      -H "Authorization: Bearer $INFERNODE_API_KEY" -H 'Content-Type: application/json' \
      -d '{"model":"Saptiva Turbo","messages":[{"role":"user","content":"OK"}],"max_tokens":10}'

  3. Si el paso 1 no responde o todos los modelos fallan, es la segunda causa. Un administrador puede mirar el Panel: "Panel inicializándose" o "Snapshot antiguo" apuntan a lo mismo (El Panel no muestra datos).

Solución​

  1. Cambia de modelo mientras dure: en OpenCode, /models o -m infernode/turbo; en el SDK, el campo model; en un agente de Studio, el selector de modelo.
  2. Si tu código reintenta, hazlo con espera exponencial (1 s, 2 s, 4 s) y un máximo de tres intentos: un 504 repetido en segundos no se va a resolver solo. Ante provider_circuit_open, espera lo que dice el mensaje antes del siguiente intento.
  3. Guarda el request_id del error y repórtalo al administrador junto con el modelo y la hora. Con eso el operador localiza la llamada (cómo reportar).
  4. Si la instalación completa no responde, no hay nada que hacer del lado del usuario: espera el aviso del administrador.

Siguiente paso​

Última actualización en