Llama a vLLM y otros endpoints compatibles con OpenAI desde n8n
Intermedio8 min de lecturaAutomatizaciones

Llama a vLLM y otros endpoints compatibles con OpenAI desde n8n

Llama a un endpoint local /v1/chat/completions compatible con OpenAI desde el nodo HTTP Request de n8n, con autenticación explícita, presupuestos de tiempo de espera, comprobaciones de la URL base y un límite de red privada.

Lo que deberías poder hacer

n8n puede llamar a una ruta local /v1/chat/completions compatible con OpenAI mediante su nodo HTTP Request, pero el endpoint sigue siendo infraestructura privada: autentica las rutas expuestas, aísla el servicio, mide su latencia y nunca trates una clave API de vLLM como el perímetro de seguridad de todo el servidor.

Guardado solo en este navegador.
En este artículo

Los modelos privados solo resultan útiles si tus automatizaciones pueden alcanzarlos. La ruta genérica verificada de n8n pasa por su nodo HTTP Request. Puede llamar a un servidor vLLM compatible con OpenAI o a otro despliegue que exponga y acepte realmente POST /v1/chat/completions.

Este artículo es una guía para el operador: cómo configurar la llamada HTTP, autenticarla, definir presupuestos de tiempo de espera que reflejen la inferencia local medida y mantener el servicio del modelo alejado de redes no fiables.

Si aún estás decidiendo si n8n es la capa de automatización adecuada, empieza por n8n vs Zapier vs Make. Para flujos de trabajo con forma de agente sobre esa fontanería, consulta tu primer agente de IA en n8n.

Un endpoint compatible con OpenAI accesible desde Internet público sin autenticación es un proxy de inferencia abierto. Cualquiera que lo encuentre puede consumir tiempo de GPU. Con vLLM, un atacante también puede alcanzar rutas de inferencia y operación que --api-key no protege. La filtración de prompts es un riesgo independiente relacionado con el registro y el control de acceso, no una propiedad automática de la ruta de chat. Limita la escucha a redes privadas. Exige autenticación en la pasarela. No reenvíes puertos «solo para una demostración».

Qué significa «compatible con OpenAI» aquí

Para n8n, el contrato es estrecho:

  • La URL base apunta a la raíz del servidor o a /v1, según lo que espere el nodo.
  • Las llamadas de chat van a /v1/chat/completions (o la ruta equivalente que tu nodo añade).
  • El cuerpo de la petición se parece a un completado de chat: model, messages, opcionalmente temperature, max_tokens, etc.
  • La respuesta devuelve choices con contenido de mensaje que el nodo puede parsear.

No necesitas paridad funcional con todas las interfaces de productos de OpenAI. Necesitas una ruta de completado de chat cuya solicitud, autenticación, identificador de modelo y forma de respuesta hayas probado desde n8n.

vLLM documenta este modo de servidor compatible con OpenAI; otros entornos de ejecución anuncian formas similares. Verifica la ruta y una solicitud curl de ejemplo contra tu instalación antes de conectar workflows de producción. La interfaz es común, pero las rutas, los identificadores de modelos, la autenticación y la compatibilidad de las respuestas pueden cambiar entre productos y versiones.

Ruta verificada en n8n: HTTP Request

La documentación oficial actual de n8n no establece una URL base personalizada para las credenciales de OpenAI ni para el nodo OpenAI Chat Model. Considera que cualquier campo de este tipo en una versión concreta de n8n o en un nodo de la comunidad es específico de esa versión hasta que lo verifiques. La ruta genérica documentada es el nodo HTTP Request, que permite controlar explícitamente el método, la URL, los encabezados, el cuerpo, la autenticación y los ajustes de reintento del nodo.

Usa una credencial genérica bearer o de encabezado en lugar de insertar el secreto en el workflow. La credencial debe contener un valor que el servicio de inferencia o su pasarela valide realmente. Una clave de relleno en un endpoint disponible solo en la LAN no constituye autenticación.

POST http://10.0.0.20:8000/v1/chat/completions
Content-Type: application/json
Authorization: Bearer <secret>
{
  "model": "installer-recommended-local-model",
  "messages": [
    { "role": "system", "content": "Classify the ticket. Reply with JSON only." },
    { "role": "user", "content": "{{ $json.body }}" }
  ],
  "temperature": 0
}

Sustituye la cadena del modelo por el identificador exacto servido por /v1/models. Si utilizas la ruta local de vLLM de NVIDIA NemoClaw, usa el identificador que registra desde el servidor activo o desde el perfil gestionado seleccionado. vLLM gestionado es una opción para los hosts compatibles, no una propiedad universal de todas las instalaciones de NemoClaw; un sistema Linux genérico exige seleccionar de forma explícita la vía experimental o de proveedor. No inventes de memoria un nombre de checkpoint.

HTTP Request también es la vía adecuada cuando un nodo de IA específico de un proveedor no documenta un endpoint personalizado.

Autenticación y controles de red que de verdad aguantan

Local no significa sin autenticación.

En vLLM, --api-key no es un perímetro de seguridad para todo el servicio HTTP. La página oficial de seguridad documenta conjuntos de endpoints protegidos y no protegidos, y recomienda aislamiento de red más un proxy inverso cuando la exposición es necesaria (guía de seguridad de vLLM). Una clave de API en las rutas de inferencia no demuestra que todas las rutas rechacen tráfico sin autenticar.

Línea base obligatoria: enlaza vLLM solo a loopback, a una red de contenedores/clúster o a una interfaz privada protegida por una política de firewall que permita únicamente al proxy o a la carga de trabajo de n8n. Pon Caddy, nginx, Traefik o una pasarela controlada equivalente delante cuando deba conectarse más de un host. Termina TLS donde la ruta no sea ya una superposición cifrada de confianza, autentica cada ruta que expongas, aplica límites de solicitudes, acota el tamaño de las peticiones y deja en la lista de permitidos solo las rutas necesarias. n8n habla con el proxy; los clientes no llegan a vLLM directamente.

Usa el --api-key de vLLM como control adicional para los endpoints de inferencia admitidos, no como sustituto del proxy o del firewall. Guarda todas las credenciales en credenciales de n8n o en un almacén de secretos aprobado, no en campos de flujo en texto plano que se exporten a Git.

No hagas:

  • Enlazar 0.0.0.0 en una IP WAN de casa u oficina «temporalmente».
  • Compartir una URL de túnel en Slack.
  • Reutilizar una clave personal de OpenAI como «contraseña» de un servidor local que nunca la comprueba. Si el servidor ignora Authorization, la clave es solo apariencia.

Los prompts enviados a un endpoint local también salen del host de n8n y pueden registrarse en el servidor de inferencia, el proxy y el historial de ejecución de n8n. El alojamiento local reduce la retención en nubes de terceros, pero no elimina los registros, las capturas de pantalla ni el acceso del operador. Clasifica el texto de los clientes como datos potencialmente sensibles o personales según tu política y la legislación aplicable, y verifica después la retención y los controles de acceso.

Para una higiene de integración más amplia, incluidas credenciales de alcance limitado, cuentas de servicio y rastros de auditoría, usa los patrones de conectar la IA de forma segura.

Timeouts e inferencia lenta

La latencia de los modelos locales varía mucho según el modelo, la longitud del prompt, el hardware, la concurrencia y el estado de arranque en frío. El tiempo de espera efectivo de un nodo de n8n también depende del nodo y de la versión instalada. En el nodo HTTP Request, el tiempo de espera documentado cubre la espera hasta recibir los encabezados o el inicio del cuerpo de la respuesta; no demuestra que una generación transmitida o larga esté acotada de extremo a extremo. Por tanto, un valor predeterminado copiado de un tutorial puede hacer fallar una tarea sana o dejar otra capa sin un límite claro.

Fija los timeouts con intención:

  1. Mide una llamada en frío y otra en caliente con curl desde el host de n8n.
  2. Configura el tiempo de espera de la respuesta inicial del nodo por encima del p95 medido, con un margen justificado para los picos de carga.
  3. Alinea los límites del workflow, el proxy, el cliente y el servidor de inferencia con el presupuesto completo de generación.
  4. Prefiere prompts más cortos y valores menores de max_tokens para clasificar o enrutar; reserva las generaciones largas para pasos de redacción que puedan continuar de forma asíncrona.

Si un paso supera rutinariamente unos minutos, puede pertenecer a una cola con continuación asíncrona, no a una respuesta síncrona de webhook.

Haz una prueba de humo desde el espacio de red del proceso n8n, no solo desde tu portátil. n8n en Docker no puede alcanzar localhost en el host a menos que publiques el puerto del modelo en esa red. Usa el nombre del servicio Docker, la IP de la puerta de enlace del host o una dirección LAN a la que el contenedor pueda enrutar.

Checklist de higiene de la URL base

Antes de marcar la credencial como lista para producción:

ComprobaciónCondición de aprobación
AlcanzabilidadEl entorno de ejecución de n8n puede alcanzar la ruta de estado documentada y /v1/models autenticado sin salir de la red privada
Ruta/v1/chat/completions se completa correctamente con un payload mínimo
AuthLa inferencia sin autenticar se rechaza; ninguna ruta de vLLM sin proteger es alcanzable fuera del límite privado previsto
Model idLa cadena exacta coincide con lo que anuncia el servidor
TLSObligatorio si la ruta cruza redes no confiables
LoggingEl registro de prompt/respuesta es intencional y con retención limitada
FailoverEl flujo tiene un comportamiento claro cuando el endpoint cae
Tiempo de esperaLos límites de respuesta inicial y de extremo a extremo reflejan las mediciones desde el entorno de ejecución de n8n

El comportamiento cuando el endpoint no está disponible debe ser explícito: reintentar con espera progresiva, dirigir el elemento a una cola humana o hacer fallar la ejecución de forma visible. No recurras silenciosamente a una API pública con una postura de privacidad distinta, salvo que sea una ruta documentada y aprobada.

Nunca expongas sin una puerta

La regla es simple: no expongas vLLM directamente a una red no fiable. Su clave API no protege todo el servicio HTTP. Usa aislamiento de red y expón únicamente las rutas necesarias mediante una pasarela autenticada y con límites de solicitudes.

Patrones aceptables:

  • Solo loopback o red Docker, n8n en el mismo host u overlay.
  • LAN + lista de permitidos en el firewall para la identidad o IP del proxy o de la carga de trabajo de n8n; verifica las reglas desde un host denegado.
  • VPN o malla Tailscale/ZeroTier; sin listeners WAN.
  • Proxy inverso con auth fuerte, TLS y límites de solicitudes si debes servir varios clientes de confianza.

Patrones inaceptables:

  • Enlace WAN sin autenticación.
  • Demos con «auth después» sobre un dataset real.
  • Compartir el mismo endpoint sin autenticación con todos los portátiles en la Wi-Fi de invitados.

Si estás creando un stack privado con inferencia local, orquestación de n8n y una etapa de agente, mantén la URL base del modelo como contrato interno. Hermes y otros entornos de ejecución pueden apuntar al mismo servicio privado. Cuando n8n invoque a Hermes, elige el servidor API autenticado si n8n necesita el resultado, o el adaptador de webhooks HMAC para recibir eventos y efectuar una entrega configurada por Hermes. Esta diferencia se explica en n8n → Hermes: llamada API o webhook de eventos.

Un camino mínimo de soporte privado

Flujo ilustrativo que puedes implementar sin inventar cifras de rendimiento:

  1. Un webhook de ticket llega a n8n.
  2. Valida y oculta campos sensibles.
  3. HTTP Request llama al endpoint privado /v1/chat/completions para obtener el JSON de clasificación.
  4. Un nodo Switch enruta por etiqueta.
  5. Los borradores que salen del límite de la empresa esperan un control de aprobación humana (idempotencia y controles de aprobación humana).

Eso basta para demostrar que el endpoint local merece su sitio antes de añadir agentes más ricos.

Qué verificar el día que publiques o actualices

Las UI de producto y los nombres de campo de credenciales cambian. El día que publiques o actualices este flujo:

  1. Confirma la documentación en vivo de la ruta compatible con OpenAI de tu servidor de inferencia.
  2. Confirma que las credenciales y la configuración del nodo HTTP Request siguen enviando la autenticación, los encabezados y la forma JSON sin procesar necesarios.
  3. Vuelve a ejecutar curl y una ejecución de prueba en n8n con un payload que no sea de producción.
  4. Confirma que el listener sigue siendo privado (ss/lsof, reglas de firewall, sin túnel sorpresa), que una petición de inferencia sin autenticar falla y que los endpoints sin proteger documentados de vLLM no son alcanzables desde fuera del límite externo.

Los endpoints locales compatibles con OpenAI permiten a n8n usar inferencia privada sin reescribir el grafo de automatización. El trabajo no consiste en crear prompts ingeniosos, sino en tratar la inferencia como cualquier otra API interna: autenticada en el límite expuesto, medida, registrada de forma deliberada e inaccesible para desconocidos.

Leer a continuación

Continúa por el mismo itinerario de aprendizaje con los siguientes artículos prácticos.

Profundiza

Cursos externos seleccionados para profundizar en este tema.

Ver todos los cursos para Automatizaciones