OpenRouter frente al acceso directo: cómo elegir la forma de llamar a los LLM

Las tres formas de realizar una llamada a un LLM

1) API directa del proveedor

Te integras con el endpoint de un único proveedor y te encargas del resto: reintentos, alternativas de respaldo, seguimiento del uso, rotación de claves y conmutación por error.

Esta es la opción más sencilla cuando:

• ya sabes qué modelo quieres,
• la latencia importa,
• el área de cumplimiento exige una cadena de proveedores más reducida,
• y tu tráfico es lo bastante estable como para planificar en función de los límites de un único proveedor.

2) Pasarela / agregador / intermediario

Envías solicitudes a una capa intermedia que las reenvía a uno de varios proveedores. OpenRouter es el ejemplo más conocido, pero este patrón va más allá de cualquier empresa concreta.

Esta opción resulta atractiva cuando:

• quieres poder elegir entre modelos con una única integración,
• necesitas enrutamiento hacia alternativas de respaldo,
• experimentas con modelos con frecuencia,
• o no quieres gestionar los SDK y las cuentas de facturación de varios proveedores.

3) Alojamiento propio

Ejecutas un modelo abierto en tu propia infraestructura, normalmente detrás de tu propio enrutador.

Esta opción es la más adecuada cuando:

• el control de los datos no es negociable,
• el volumen es lo bastante alto como para mantener el hardware ocupado,
• o necesitas costes por token predecibles y puedes asumir la carga operativa.

Qué cambia en la práctica

Este es el aspecto que suele pasarse por alto: la mejor opción no suele depender solo del precio de los tokens. Depende de toda la cadena de fallos.

La tabla oculta una verdad importante: una pasarela rara vez ahorra dinero por arte de magia. Ahorra dinero cuando evita la complejidad innecesaria, reduce el tiempo de inactividad o permite dirigir automáticamente las tareas al modelo aceptable más barato.

Dónde cambia realmente el gasto

Si usas un solo modelo para todo, llamar directamente suele ser lo más sencillo y barato. Pero la mayoría de los sistemas reales son más complejos:

• el chat del producto usa un modelo prémium,
• los borradores de soporte usan un modelo más barato,
• la generación de resúmenes usa un modelo pequeño y rápido,
• y los picos de tráfico necesitan capacidad adicional.

Ahí es donde un intermediario puede ayudar. No porque sus precios de catálogo sean más bajos, sino porque permite centralizar las decisiones de enrutamiento.

Una política sencilla podría ser así:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

Esa configuración no es específica de ningún proveedor; es la estructura de un enrutador bien planteado. En la práctica, el ahorro proviene de evitar el desperdicio:

• no envíes todas las tareas de extracción a tu modelo más caro,
• no reintentes indefinidamente las solicitudes a un proveedor inestable,
• no mantengas una segunda integración solo para el 2% del tráfico que se dispara los viernes.

Un problema habitual: si tu aplicación realiza llamadas a herramientas o produce efectos secundarios, los reintentos pueden duplicar acciones. Si una pasarela reintenta una solicitud tras agotar el tiempo de espera, el modelo puede volver a emitir la misma llamada a función. Sin claves de idempotencia y un diseño cuidadoso de las herramientas, una «alternativa útil» se convierte en «ticket duplicado» o «pago cobrado dos veces».

Cuándo ayuda realmente una pasarela

Recurriría a un agregador o intermediario cuando se cumpla una o más de estas condiciones:

• Todavía estás conociendo la carga de trabajo. Al principio, no sabes si GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 o un modelo abierto será la mejor opción para tu tarea.
• Quieres enrutar por tarea, no por proveedor. Un clasificador puede enviar prompts cortos a un modelo barato y rápido, y el trabajo con contextos largos a algo como Fable 5 cuando realmente sea la opción más adecuada.
• Necesitas una forma rápida de recurrir a una alternativa. Si un proveedor empieza a limitar la tasa de solicitudes, el intermediario puede redirigir el tráfico antes de que tus usuarios lo noten.
• No quieres cinco sistemas de facturación. Una sola factura y una sola integración son más fáciles de gestionar que múltiples claves, cuotas y paneles de gasto.
• Necesitas una capa de abstracción para productos multiinquilino. Una pasarela te permite cambiar de proveedor internamente sin reescribir tu aplicación.

Esto resulta especialmente útil si tu equipo es pequeño. He visto a equipos de startups dedicar más tiempo a implementar lógica de reintentos específica de cada proveedor que a aportar valor al producto. Un intermediario puede concentrar ese trabajo en un solo lugar.

Cuándo conviene más llamar directamente

Las API directas de los proveedores suelen ser la mejor opción cuando te importa cualquiera de los siguientes aspectos:

• La menor latencia posible. Un salto menos importa cuando el presupuesto de latencia de tu producto es ajustado. Si quieres una interacción de 300 ms que «se sienta instantánea», añadir sobrecarga de red y enrutamiento puede consumir una parte considerable de ese margen.
• Límites estrictos de cumplimiento normativo. Cada encargado del tratamiento adicional supone otra relación, otro conjunto de reglas de conservación y otra revisión contractual.
• Funciones específicas del proveedor. Algunos proveedores ofrecen capacidades que los agregadores eliminan al normalizarlas o tardan en incorporar.
• Un volumen alto y predecible. Una vez que el uso es estable, un enrutamiento personalizado puede resultar más barato que pagar por una capa intermedia.
• Canales de soporte más claros. Cuando algo falla, hay menos reproches cruzados.

El beneficio oculto es la claridad operativa. Si la ruta de tus llamadas es directa, resulta más fácil aislar la causa raíz de un fallo. Si falla, normalmente el problema está en tu código o en el proveedor. Con una pasarela, también tienes que determinar si el responsable fue el intermediario, su capa de enrutamiento o el proveedor al que envía las solicitudes.

El autoalojamiento es otro escenario

Autoalojar modelos abiertos no es simplemente tener una «API más barata, pero en mi servidor». Es un problema de sistemas.

Tienes que pensar en:

• el dimensionamiento y la utilización de las GPU,
• el procesamiento por lotes,
• la cuantización,
• la presión sobre la caché KV,
• el escalado automático,
• los arranques en caliente,
• los filtros de seguridad,
• las actualizaciones de los modelos,
• y los procedimientos de reversión.

La ventaja es el control. Si tu carga de trabajo es estable y suficientemente alta, el autoalojamiento puede resultar económicamente atractivo. Pero las cuentas solo salen cuando mantienes el hardware ocupado. Las GPU inactivas son caras. También lo es el tiempo de ingeniería necesario para que una infraestructura de servicio de modelos funcione bien bajo presión.

El otro problema habitual es la deriva de calidad. Un modelo abierto puede ser suficientemente bueno para generar resúmenes hoy, pero los resultados de tus evaluaciones pueden desplomarse cuando cambian la longitud de los prompts, los requisitos de estilo o el uso de herramientas. No des por hecho que «abierto» significa automáticamente «lo bastante barato como para sustituir una API gestionada».

Un patrón híbrido práctico

En los sistemas reales, la mejor arquitectura suele ser mixta:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

Y dentro de la aplicación:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

Ese patrón mantiene sencilla la ruta crítica y, a la vez, te da flexibilidad de enrutamiento. He comprobado que los equipos suelen acabar en este punto después del primer mes en producción: conexión directa para la experiencia de usuario principal, pasarela para experimentar y absorber el exceso de tráfico, y autoalojamiento solo cuando las ventajas económicas o de privacidad son indiscutibles.

Privacidad, latencia y confianza

Aquí es donde la ingeniería se convierte en una cuestión de políticas.

Privacidad

Una pasarela cambia tu límite de confianza. Aunque los prompts se reenvíen al proveedor, sigues teniendo que responder a estas preguntas:

• ¿El intermediario registra los prompts?
• ¿Durante cuánto tiempo se conservan?
• ¿Qué subencargados del tratamiento pueden verlos?
• ¿Puedes mantener a determinados inquilinos en una ruta restringida?
• ¿Se puede fijar la región?

Para las cargas de trabajo reguladas, «el proveedor prometió comportarse bien» no basta. Necesitas documentación que lo respalde y un diseño que se ajuste a ella.

Latencia

Un intermediario añade otro salto. Eso no hace que la aplicación sea lenta automáticamente, pero sí añade incertidumbre. Si tu aplicación realiza muchas llamadas y la transmisión de tokens es importante, cada capa adicional puede hacer menos predecible el tiempo hasta el primer token.

Límites de solicitudes

Las integraciones directas te exponen a los límites del proveedor sin intermediación. Las pasarelas pueden mitigar esto distribuyendo el tráfico entre proveedores, pero también pueden introducir sus propias restricciones. En otras palabras: puedes cambiar un límite por otro. La ventaja es la elasticidad, no la inmunidad.

La regla de decisión que uso

Si tuviera que condensar la elección en una frase: llama directamente cuando conozcas el modelo y te importe la ruta; usa una pasarela cuando te importen la flexibilidad y la resiliencia; autoaloja cuando el control y una utilización constante justifiquen el coste operativo.

Algunas reglas prácticas concretas:

• Empieza con una conexión directa si estás lanzando tu primera función en producción y solo necesitas un modelo.
• Añade una pasarela cuando tengas al menos dos clases distintas de modelos o cuando la conmutación por error empiece a aparecer en las revisiones de incidentes.
• Autoaloja solo después de contar con cifras reales de utilización y un motivo claro para gestionar tu propia infraestructura.
• Usa una pasarela para experimentar con el enrutamiento, pero mantén idempotente tu ruta crítica.
• Mide el coste de extremo a extremo, no solo el precio de los tokens.

Conclusiones prácticas

• Prioriza las API directas para obtener la latencia más baja, la depuración más sencilla y el mejor soporte específico del proveedor.
• Prioriza una pasarela o un agregador cuando necesites enrutar entre varios modelos, disponer de alternativas ante fallos o usar una sola integración con muchos proveedores.
• Prioriza el autoalojamiento solo cuando puedas mantener el hardware ocupado y aceptar la complejidad operativa.
• Implementa la idempotencia y una política rigurosa de reintentos antes de añadir alternativas automáticas.
• Compara el coste total: tokens, recargos, reintentos, tiempo de ingeniería y recuperación tras incidentes.
• Mantén la privacidad y la conservación de datos en la decisión desde el primer día, no después de que lo pregunte el departamento de compras.
• Usa una arquitectura híbrida si tu carga de trabajo incluye tanto flujos prémium como flujos estándar.

Si quieres, puedo convertir esto en una versión con una postura más definida para un público específico, como emprendedores de startups, equipos de plataforma o equipos empresariales con requisitos estrictos de cumplimiento normativo.