Diagrama de arquitectura de pasarela API de LLM para enrutamiento y conmutación por error entre varios proveedores

Una pasarela API de LLM es el plano de control entre el código de la aplicación y múltiples proveedores de modelos. La arquitectura útil no es solo una URL de proxy. Tiene que autenticar a los clientes, mapear modelos, aplicar políticas, elegir una ruta upstream, imponer cuotas, registrar el uso, calcular el costo y decidir qué sucede cuando falla un proveedor.

Esta guía ofrece a los ingenieros de plataforma un diagrama práctico de arquitectura de pasarela API de LLM para enrutamiento multi-proveedor y conmutación por error. Usa patrones públicos de pasarela de Vercel y Pydantic como referencias de categoría, y mantiene las afirmaciones específicas de Flatkey limitadas a pruebas públicas actuales: una clave API, un endpoint de enrutamiento compatible con OpenAI en https://router.flatkey.ai/v1, precios claros, facturación unificada, un panel para claves, uso y enrutamiento, conmutación automática y balanceo de carga.

El objetivo es ayudarte a revisar el diseño antes de que el tráfico de producción dependa de él. Usa el diagrama como una lista de verificación para tu propia pasarela, una evaluación de proveedor o una prueba en entorno de staging de Flatkey.

Diagrama de arquitectura de LLM API Gateway

El diagrama muestra la ruta de las solicitudes desde las aplicaciones cliente hasta los proveedores de modelos upstream. El centro de la arquitectura es el LLM API gateway. A su alrededor están los servicios de política que hacen que el enrutamiento sea seguro de operar: ámbito de clave, asignación de modelo, clase de ruta, libro mayor de cuotas, facturación, registros, comprobaciones de salud y reglas de respaldo.

Capa	Responsabilidad	Pregunta de diseño
Aplicaciones cliente	Envían solicitudes de chat, respuestas, imágenes, vídeo, agentes o herramientas.	¿Qué SDKs y formatos de endpoint deben seguir funcionando?
Endpoint del gateway	Recibe solicitudes a través de una URL base estable y una clave API.	¿Pueden las aplicaciones migrar cambiando solo la clave, la URL base o la configuración del proveedor?
Autenticación y ámbito de clave	Identifica al solicitante, equipo, aplicación, entorno y conjunto de modelos permitidos.	¿Se pueden separar el entorno de staging, producción y el tráfico de clientes?
Motor de políticas	Aplica asignación de modelo, clase de ruta, presupuesto, cuota y reglas de respaldo.	¿La política explica por qué una solicitud puede o no puede usar una ruta?
Enrutador	Selecciona un proveedor upstream, cuenta, modelo o ruta de respaldo.	¿El enrutamiento se basa en una política aprobada y no en magia oculta?
Salud y conmutación por error	Rastrea errores del proveedor, timeouts, reintentos, respaldo y condiciones de parada.	¿Qué fallos deben reintentar, cambiar, poner en cola o fallar de forma cerrada?
Registros, cuota y facturación	Registra modelo, ruta, estado, unidades de tokens o medios, coste, propietario y clave.	¿Pueden los ingenieros y finanzas rastrear una solicitud después de un incidente?
Proveedores upstream	Sirven el modelo seleccionado mediante APIs nativas del proveedor o compatibles.	¿Qué proveedores están aprobados para cada clase de tráfico?

Cómo se mueve una solicitud a través del gateway

Un gateway de API LLM de producción debería hacer que la ruta de la solicitud sea fácil de explicar. Si tu equipo no puede dibujar la ruta, probablemente tampoco pueda depurarla durante una interrupción o una revisión de facturación.

1. El cliente envía una solicitud. La aplicación llama al gateway con un nombre de modelo, endpoint, mensajes o entrada multimedia, y una clave API de aplicación.
2. El gateway autentica la clave. La clave se asigna a un propietario, entorno, cuota, conjunto de modelos permitidos y política de registro.
3. El motor de políticas clasifica el tráfico. La solicitud se etiqueta como chat de cliente, trabajo en segundo plano, evaluación, generación de medios, tráfico de herramientas de codificación u otra clase de ruta.
4. El enrutador elige una ruta candidata. Comprueba la asignación del modelo, la disponibilidad del proveedor, las cuentas upstream permitidas, la política de costos, el estado de la cuota y cualquier prioridad o peso configurado.
5. El gateway envía la solicitud upstream. Según el proveedor y el endpoint, esto puede conservar una forma de solicitud compatible con OpenAI o usar un protocolo nativo del proveedor.
6. La respuesta se normaliza cuando es posible. El gateway devuelve al cliente la forma de respuesta esperada, un error, un stream o una referencia de trabajo.
7. La solicitud se registra. Los logs capturan la ruta, el modelo, el estado, la latencia, las unidades de uso, la estimación de costo, la clave y el propietario para que el equipo pueda depurar y conciliar el gasto.

Por eso el paso de migración de API compatible con OpenAI es solo una parte de la arquitectura. Cambiar una URL base lleva el tráfico al gateway. La preparación para producción depende de la política, el enrutamiento, la cuota, la facturación, los registros y el comportamiento de fallback después de eso.

La política de enrutamiento va antes que el failover

El error arquitectónico más común es tratar el failover como algo universalmente positivo. Una pasarela API de LLM no debería reintentar a ciegas cada solicitud fallida contra cada proveedor. Primero debe decidir si la ruta de respaldo está permitida para esa clase de tráfico.

La documentación pública de las pasarelas muestra por qué esta distinción importa. Pydantic documenta grupos de enrutamiento en los que los proveedores pueden tener prioridad, peso y estado activo, lo que permite failover entre proveedores que sirven el mismo modelo o balanceo de carga entre miembros con la misma prioridad. Vercel posiciona AI Gateway en torno al enrutamiento, la facturación, la observabilidad, múltiples modelos y el enrutamiento de proveedor/modelo con fallbacks. Esos patrones son referencias útiles, pero tu política de producción sigue teniendo que definir qué es aceptable para tu carga de trabajo.

Clase de tráfico	Regla principal de enrutamiento	Regla de failover
Chat orientado al cliente	Usar solo familias de modelos y proveedores aprobados.	Cambiar solo a un equivalente aprobado, o devolver un error controlado.
Resumido en segundo plano	Priorizar coste y rendimiento cuando los requisitos de calidad sean estables.	Reintentar, poner en cola o usar un modelo aprobado de menor coste si la calidad de salida sigue siendo aceptable.
Evaluación y benchmarks	Mantener estable la identidad del modelo.	Fallos cerrados; un fallback oculto dificulta comparar resultados.
Generación de medios	Respetar la forma del endpoint, el ciclo de vida del trabajo, la política de medios y el presupuesto.	Fallar cerrado a menos que el modelo alternativo tenga el mismo contrato de salida aprobado.
Flujos de trabajo de agentes	Respetar la compatibilidad con herramientas, los límites de contexto, el límite de datos y las necesidades de auditoría.	Fallback solo cuando el comportamiento de las herramientas y el manejo de datos sigan siendo válidos.

El texto público de Flatkey dice que enruta varias cuentas upstream con conmutación automática y balanceo de carga. Usa eso como punto de partida del producto y luego define cuáles de tus clases de tráfico pueden cambiar automáticamente y cuáles deben fallar cerradas.

El failover necesita una condición de parada

Todo diseño de failover de una pasarela de API de LLM necesita una condición de parada. Sin una, una solicitud malformada puede convertirse en una cascada de llamadas inválidas repetidas, gasto duplicado, registros confusos y comportamiento de usuario inconsistente.

Una escalera práctica de fallos se ve así:

1. Rechazar antes del upstream: fallar cerrado para autenticación inválida, modelo prohibido, cuota excedida, endpoint no compatible o parámetros requeridos faltantes.
2. Reintentar la misma ruta: reintentar solo cuando el error sea plausiblemente transitorio, como un timeout de red o un 5xx del upstream seleccionado.
3. Cambiar el mismo contrato: usar otra cuenta, región o ruta de proveedor solo si sirve al mismo contrato de modelo aprobado.
4. Usar respaldo aprobado: pasar a otro modelo solo cuando los responsables de producto, calidad, cumplimiento y presupuesto aprueben el respaldo.
5. Encolar o degradar: retrasar el trabajo no urgente cuando la alternativa inmediata sería costosa o arriesgada.
6. Devolver un error controlado: detenerse cuando la política indique que no queda ninguna ruta segura.

La guía de balanceo de carga y failover de la API de IA cubre esto con más detalle. En la revisión de arquitectura, la pregunta importante es si cada transición es explícita y observable.

La cuota, la facturación y los registros forman parte de la ruta de solicitud

El tráfico de modelos no se factura como el tráfico HTTP ordinario. Una sola pasarela de API de LLM puede tener que contabilizar tokens de entrada, tokens de salida, tokens en caché, tokens de razonamiento, unidades de imagen, duración de vídeo, llamadas a herramientas, reintentos y unidades de cuota específicas del proveedor. Si la facturación y la cuota se tratan como un informe nocturno, la pasarela no puede impedir en el momento un uso descontrolado.

Coloque la cuota y la facturación cerca de la política de enrutamiento:

• Compruebe el presupuesto restante del solicitante antes de reenviar solicitudes costosas.
• Bloquee o advierta sobre rutas con datos de precios faltantes cuando importan los límites de gasto.
• Registre el modelo seleccionado, la familia de endpoint, la ruta ascendente, la clave, el propietario, el estado y las unidades de uso.
• Separe en los registros los reintentos y las llamadas de respaldo para que una solicitud de usuario no oculte varios intentos del proveedor.
• Haga visibles las claves de staging y producción como diferentes centros de coste.
• Exporte suficientes datos para finanzas, soporte y revisión de incidentes.

El posicionamiento público actual de Flatkey incluye precios claros, facturación unificada, visibilidad del uso, límites de cuota y un único panel para claves, uso y enrutamiento. Una instantánea de la API de precios del día de lanzamiento devolvió 656 filas de modelos y admitió metadatos de endpoint para tráfico compatible con OpenAI, OpenAI Responses, Anthropic, Gemini, generación de imágenes y generación de vídeo. Trátelo como evidencia fechada y, después, verifique su modelo y unidad exactos en la página de precios en vivo.

Dónde encaja Flatkey en esta arquitectura

Flatkey está diseñado para reducir la proliferación de cuentas de proveedor detrás de una sola clave. En esta arquitectura de pasarela de API de LLM, Flatkey se asigna al endpoint de pasarela alojado, la capa de acceso al proveedor, el panel, la capa de uso/facturación y la capa de enrutamiento.

Una prueba de staging cuidadosa de Flatkey debería verse así:

1. Cree una clave de no producción en el panel de Flatkey.
2. Apunte un cliente a https://router.flatkey.ai/v1.
3. Ejecute una solicitud conocida como válida para la familia de endpoints que necesita.
4. Confirme que la solicitud aparezca en los registros de uso con el modelo, el estado, las unidades y evidencia de coste.
5. Revise la página de precios en vivo para el modelo y la unidad de facturación seleccionados.
6. Defina qué clases de tráfico pueden usar el cambio automático o el equilibrio de carga.
7. Ejecute una prueba de fallo segura, o documente por qué la simulación de fallos no está permitida en staging.

No infiera de este artículo un SLA de disponibilidad, una garantía de latencia, un algoritmo de enrutamiento exacto ni disponibilidad garantizada del proveedor. La arquitectura le dice qué validar; la evidencia de su staging le dice si un despliegue específico está listo.

Lista de verificación de implementación

Antes de enviar tráfico de producción a través de un LLM API gateway, asegúrese de que la arquitectura tenga estos controles implementados:

Elemento de la lista de verificación	Condición de aprobación
URL base y migración de SDK	Al menos una solicitud de staging se completa correctamente a través del gateway con el SDK o cliente previsto.
Asignación de modelo y endpoint	Toda familia de endpoints de producción tiene un modelo, protocolo y responsable aprobados.
Ámbito de las claves	Las claves se separan por app, entorno, equipo o cliente cuando es necesario.
Política de enrutamiento	Las clases de tráfico definen las rutas primarias permitidas y las rutas de respaldo.
Condición de detención por failover	El gateway sabe cuándo reintentar, cambiar, poner en cola y fallar de forma cerrada.
Controles de cuota y presupuesto	Los límites pueden detener o restringir el tráfico costoso antes de que llegue a un proveedor upstream.
Logs y observabilidad	Se pueden revisar posteriormente evidencias de solicitud, ruta, modelo, responsable, estado, uso y costo.
Rollback	La app puede volver a su configuración previa del proveedor si falla la implementación del gateway.

Para una visión más amplia de los requisitos, comience con la lista de verificación de AI API gateway. Para el trabajo de comparación de plataformas, la guía de alternativas a OpenRouter muestra cómo difieren las compensaciones de un gateway gestionado frente a los marketplaces de proveedores y las capas de enrutamiento autogestionadas.

FAQ

¿Qué es un gateway de API para LLM?

Un gateway de API para LLM es una capa de control entre las aplicaciones y los proveedores de modelos. Puede centralizar las claves de API, el acceso a modelos, el enrutamiento, las cuotas, la facturación, los registros y la política de conmutación por error para el tráfico de LLM.

¿Qué debe incluir una arquitectura de gateway de API para LLM?

Una arquitectura de gateway de API para LLM debe incluir aplicaciones cliente, un endpoint estable del gateway, autenticación, alcance de claves, comprobaciones de políticas, asignación de modelos, enrutamiento de proveedores, comprobaciones de estado, reglas de conmutación por error, cuotas, facturación, registros y proveedores upstream.

¿La conmutación por error siempre es segura para el tráfico de LLM?

No. La conmutación por error solo es segura cuando la ruta de respaldo preserva el contrato de modelo aprobado, el límite de datos, el comportamiento del endpoint, las expectativas de calidad y la política de costos. Algunos flujos de tráfico deberían fallar de forma cerrada en lugar de cambiar.

¿En qué se diferencia un gateway de API para LLM de un gateway de API normal?

Un gateway de API normal gestiona tráfico de API general. Un gateway de API para LLM añade consideraciones específicas de modelos, como formatos de proveedores, uso de tokens y medios, asignación de modelos, política de fallback, controles de gasto, observabilidad de prompts/respuestas y enrutamiento específico de IA.

¿Dónde encaja Flatkey en el diagrama?

Flatkey encaja como la capa hospedada de gateway, enrutador, acceso a proveedores, uso, facturación y panel de control. Su comunicación pública admite una sola clave de API, https://router.flatkey.ai/v1, precios claros, facturación unificada, visibilidad de uso/enrutamiento, conmutación automática y balanceo de carga.

Conclusión final

Un LLM API gateway de producción debería hacer que el tráfico de modelos sea más fácil de controlar, no más difícil de explicar. La arquitectura necesita un endpoint estable, claves con alcance, asignación de modelos, verificaciones de políticas, reglas de enrutamiento, controles de cuota y facturación, registros y una condición de parada por failover.

Flatkey ofrece a los equipos una sola clave, un endpoint de router compatible con OpenAI y un único panel para el acceso a modelos y las operaciones. Para probar la arquitectura con tu propia carga de trabajo de staging, obtén una clave y verifica la ruta de la solicitud antes de mover el tráfico de producción.