Índice de contenidos
Añadir un segundo modelo a una aplicación de IA introduce más que otra conexión de API. La aplicación debe gestionar diferentes credenciales, formatos de solicitud, límites de tasa, precios, estructuras de respuesta y condiciones de fallo. Una pasarela de IA traslada estas cuestiones comunes a una única capa de control. Ofrece a las aplicaciones una forma coherente de acceder a los modelos mientras gestiona el enrutamiento, el tráfico y los costes. Esta arquitectura resulta útil a medida que un producto de IA pasa de tener un modelo y una función a admitir múltiples cargas de trabajo de producción.
¿Qué es una pasarela de IA?
Una pasarela de IA es una capa de software situada entre una aplicación y los modelos de IA a los que llama. La aplicación envía solicitudes a través de un endpoint común, y la pasarela aplica las políticas correspondientes antes de reenviar cada solicitud a un modelo o endpoint de inferencia.
Los términos pasarela de LLM, pasarela de API de IA y pasarela de API de LLM a menudo describen una infraestructura similar. Una pasarela de LLM se centra en modelos de lenguaje. Una pasarela de IA también puede abarcar modelos de Image, Video, Audio, Embedding y modelos de reclasificación (reranking).
Según la implementación, una pasarela puede gestionar el enrutamiento de modelos, las credenciales, los reintentos, los registros de uso y las políticas de acceso. Algunas pasarelas se limitan a normalizar los formatos de API. Otras proporcionan una gestión del tráfico, observabilidad y controles de costes más avanzados.
La pasarela de IA de SiliconFlow combina el acceso unificado a modelos con enrutamiento inteligente, límites de tasa y control de costes. Los desarrolladores pueden acceder a más de 200 modelos optimizados de lenguaje y Multimodal a través de una API compatible con OpenAI, reduciendo el trabajo de integración necesario para evaluar diferentes modelos.
Cómo encaja una pasarela de IA en una aplicación de LLM
Una solicitud que pasa por una pasarela de IA generalmente sigue esta ruta:
La aplicación envía una solicitud a la pasarela.
La pasarela autentica al emisor y comprueba las políticas aplicables.
La lógica de enrutamiento selecciona un modelo o endpoint.
La solicitud se convierte al formato requerido.
El modelo seleccionado procesa la solicitud.
La pasarela devuelve o transmite en streaming la respuesta.
Se pueden registrar datos de uso, latencia, enrutamiento y errores.
Este diseño mantiene la lógica de gestión de modelos fuera de las funciones individuales del producto. Un asistente de atención al cliente, un procesador de documentos y una herramienta de generación de código pueden compartir la misma pasarela aplicando diferentes modelos y políticas.
Las aplicaciones que utilizan SiliconFlow pueden enviar solicitudes compatibles con OpenAI a:
https://api.siliconflow.com/v1
El campo model de la solicitud identifica el modelo seleccionado. Una estructura de API uniforme facilita la prueba de opciones del catálogo de modelos de SiliconFlow sin necesidad de crear una integración independiente para cada modelo.
La compatibilidad de la API simplifica la conectividad, pero los modelos aún requieren pruebas específicas para cada tarea. Pueden variar en longitud de contexto, parámetros compatibles, llamada a herramientas (tool calling), Output estructurada y comportamiento de respuesta.
Pasarela de IA frente a pasarela de API tradicional
Una pasarela de API tradicional gestiona el tráfico general de las aplicaciones. Comúnmente se encarga de la autenticación, el enrutamiento de URL, las cuotas, la validación de solicitudes y el acceso a los servicios de backend. Una pasarela de IA añade controles que reflejan cómo se comportan las API de los modelos y cómo tarifan el uso.
La decisión entre una pasarela de IA y una pasarela de API rara vez es excluyente. Una organización puede utilizar una pasarela tradicional para las API públicas de la aplicación y una pasarela de IA detrás de ella para el tráfico de modelos. De este modo, cada capa gestiona las directivas pertinentes para su carga de trabajo.
Dimensión | Pasarela de API tradicional | Pasarela de IA |
|---|---|---|
Alcance | Tráfico general de aplicaciones y servicios de backend | Tráfico de modelos e inferencia, incluidas solicitudes de tipo Multimodal |
Unidad de control | Solicitudes, endpoints y cuotas | Solicitudes y tokens, con precios independientes para Input y Output |
Enrutamiento | Enrutamiento por URL y ruta | Tipo de tarea, longitud de contexto, modalidad, soporte de herramientas, umbral de coste, objetivo de latencia |
Gestión de fallos | Reintentos y estado de salud del backend | Reintentos más conmutación por error (fallback) a un modelo de respaldo validado |
Visibilidad de costes | Recuentos de solicitudes y límites de cuota | Gasto en tokens de Input, Output y almacenados en caché por función o equipo |
Observabilidad | Latencia, errores, códigos de estado | Tiempo hasta el primer token, uso de tokens, decisiones de enrutamiento, frecuencia de fallback |
Por qué las aplicaciones multimodelo necesitan enrutamiento y fallback
Diferentes modelos se adaptan a diferentes tareas. Un modelo de menor coste puede encargarse de la clasificación o de extracciones rutinarias, mientras que el razonamiento complejo, la generación de código o el análisis de contextos largos pueden requerir otra opción. Las solicitudes de tipo Multimodal introducen requisitos de capacidad adicionales.
El enrutamiento elige un destino antes de que comience la inferencia. Una pasarela multimodelo puede considerar el tipo de tarea, la longitud de contexto requerida, la modalidad de Input, el soporte de herramientas, el umbral de coste, el objetivo de latencia o la capacidad disponible en ese momento.
Por ejemplo, una aplicación de atención al cliente podría enviar la clasificación rutinaria de intenciones a un modelo más pequeño y utilizar un modelo de razonamiento más potente para consultas complejas sobre cuentas. El enrutamiento centralizado permite al equipo ajustar esa política sin tener que actualizar varios servicios de la aplicación.
El fallback comienza cuando el modelo o endpoint original devuelve un error admisible. Una pasarela puede redirigir una solicitud tras un tiempo de espera agotado, una respuesta 429 de límite de tasa o un fallo temporal del servicio. El respaldo debe admitir las funciones esenciales de la solicitud original. Un modelo de solo Text no puede procesar una solicitud de Image, y un modelo sin llamadas a herramientas no puede sustituir de forma transparente a uno utilizado en un flujo de trabajo de agentes.
El fallback también requiere una evaluación de calidad. Una respuesta HTTP correcta no garantiza un resultado aceptable. Los equipos deben probar cada modelo de respaldo para verificar su precisión, formato de Output, latencia y cumplimiento de la tarea antes de añadirlo a una ruta de producción.
La lógica de reintento necesita una validación similar. Reintentar tras un tiempo de espera agotado puede producir trabajo duplicado o costes adicionales si la primera solicitud continuó procesándose. Las acciones de agentes y otros efectos secundarios requieren controles de idempotencia antes de habilitar los reintentos automáticos.
Cómo gestionan las pasarelas de IA los límites de tasa y el tráfico
Los servicios de modelos a menudo aplican límites de solicitudes por minuto y tokens por minuto al mismo tiempo. Una cantidad reducida de prompts largos puede alcanzar un límite de tokens antes que el límite de solicitudes, mientras que muchas llamadas cortas pueden agotar primero el cupo de solicitudes.
Una pasarela de IA puede poner solicitudes en cola, controlar la concurrencia, aplicar esperas exponenciales (backoff) y distribuir el tráfico antes de que una sola carga de trabajo consuma la capacidad compartida. También puede aplicar cuotas internas para usuarios, aplicaciones o equipos específicos. Los límites del proveedor upstream siguen siendo aplicables, por lo que la pasarela debe operar dentro de la capacidad disponible.
SiliconFlow utiliza RPM, RPH, RPD, TPM, TPD, IPM e IPD en sus diferentes servicios de modelos. Sus límites de tasa se aplican a nivel de cuenta en lugar de hacerlo individualmente a cada API Key. Los diferentes modelos tienen límites independientes, por lo que alcanzar el umbral de un modelo no interrumpe el acceso habitual a otro.
Alcanzar un límite aplicable devuelve el código HTTP 429. Las aplicaciones en producción deben utilizar concurrencia controlada y backoff exponencial en lugar de solicitudes repetidas inmediatas. Los errores temporales de sobrecarga 503 o 504 pueden dirigirse a una ruta de respaldo validada cuando haya una disponible.
Cómo ayudan las pasarelas de IA a controlar los costes de LLM
Los costes de las API de LLM dependen del precio del modelo, el volumen de tokens, la frecuencia de las solicitudes y la longitud de la Output. Cuando los precios se expresan por millón de tokens, el cálculo es el siguiente:
Coste total = (tokens de Input ÷ 1.000.000 × precio de Input por millón de tokens) + (tokens de Output ÷ 1.000.000 × precio de Output por millón de tokens)
Una pasarela de IA proporciona un único lugar para observar e influir en estas variables. El enrutamiento con control de costes puede enviar el trabajo habitual a un modelo económico, reservando al mismo tiempo los modelos de mayor capacidad para las tareas que realmente los necesitan. Los límites máximos de Output pueden evitar generaciones inesperadamente largas, mientras que las cuotas por usuario o proyecto pueden contener el tráfico anómalo.
Cuando es compatible, las pasarelas también pueden asignar el gasto por funcionalidad, establecer límites presupuestarios, detectar bucles de reintentos y almacenar en caché respuestas repetidas idóneas. El almacenamiento en caché funciona mejor para solicitudes estables cuyas respuestas se puedan reutilizar. Las peticiones dinámicas, personalizadas o confidenciales requieren un tratamiento más riguroso.
Los precios de Input y Output están disponibles para cada modelo, mostrándose los precios de Input en caché cuando corresponda. Puede comparar la longitud de contexto y los precios actuales de los tokens en nuestra página de precios y, a continuación, elegir un modelo que se ajuste a los requisitos de capacidad y presupuesto de la tarea.
¿Cuándo necesita realmente un equipo una pasarela de IA?
Un prototipo de bajo volumen que llama a un solo modelo a menudo puede gestionar las credenciales y los reintentos dentro de la propia aplicación. Una pasarela adquiere mayor valor a medida que aumenta la complejidad operativa.
Entre las señales habituales se incluyen:
Varios modelos dan servicio a diferentes cargas de trabajo.
Múltiples aplicaciones comparten el mismo acceso a los modelos.
Los límites de tasa afectan regularmente al tráfico de producción.
Las interrupciones del modelo exigen contar con un respaldo probado.
Los costes de la API son difíciles de atribuir.
Cambiar de modelo requiere modificaciones en varios servicios.
Los equipos necesitan directivas de acceso o de uso centralizadas.
Las operaciones en producción necesitan métricas y registros homogéneos.
El volumen de solicitudes es solo un factor. Una aplicación pequeña que gestiona datos sensibles puede necesitar controles centralizados desde el principio, mientras que un servicio de gran volumen que utiliza un único endpoint estable puede beneficiarse inicialmente más de la puesta en cola y de la planificación de capacidad.
Qué buscar al elegir una pasarela de IA
Comience con la cobertura de modelos y modalidades. Confirme que la pasarela admite las cargas de trabajo de lenguaje, Vision, Audio, Embedding y reclasificación que utiliza su aplicación. Evalúe el streaming, los contextos largos, la Output estructurada y la llamada a herramientas en lugar de confiar únicamente en la compatibilidad básica del esquema.
A continuación, revise los controles de enrutamiento y de fallos. La pasarela debe hacer que el comportamiento frente a tiempos de espera agotados, reintentos y fallback sea claro. Los equipos necesitan saber qué errores desencadenan otro intento, cómo se distribuye el tráfico y cómo evita el sistema las sobrecargas por reintentos reiterados (retry storms).
Los controles de tráfico deben contemplar tanto las solicitudes como los tokens. Compruebe si los límites se pueden aplicar por modelo, usuario, aplicación, proyecto o equipo. Los informes de costes deben desglosar los tokens de Input, los tokens de Output, los tokens en caché y los precios de los modelos al nivel requerido para la presupuestación.
La observabilidad debe abarcar el tiempo transcurrido hasta el primer token, la latencia total, las tasas de error, el uso de tokens, las decisiones de enrutamiento y la frecuencia de fallback. Las directivas de registro también deben proteger los prompts y respuestas confidenciales mediante controles de acceso y periodos de retención adecuados.
Por último, mida la latencia propia de la pasarela y su disponibilidad bajo niveles de concurrencia realistas. Se encuentra en la ruta crítica de las solicitudes, por lo que su fiabilidad debe estar a la altura de las aplicaciones que dependen de ella.
Preguntas frecuentes sobre pasarelas de IA
¿Añade latencia una pasarela de IA?
Cualquier capa de red adicional introduce cierta sobrecarga. El impacto depende de la ubicación de la pasarela, la gestión de conexiones, la complejidad del enrutamiento, la comprobación de directivas y el registro de eventos. Los equipos deben medir tanto la sobrecarga de la pasarela como la latencia total del modelo con tráfico realista.
¿Puede una pasarela de IA gestionar respuestas en streaming?
Sí, siempre que la pasarela admita el protocolo de streaming utilizado por el endpoint del modelo. Compruebe que mantenga los eventos, los errores, los datos de uso, el tiempo transcurrido hasta el primer token y el comportamiento ante desconexiones del cliente.
¿Puede una pasarela de IA gestionar modelos alojados y desplegados por uno mismo?
Algunas pasarelas pueden enrutar entre API gestionadas y endpoints de inferencia autodesplegados a través de una interfaz común. La compatibilidad depende de los esquemas de solicitud, la autenticación, la red, las funciones admitidas y el modelo de despliegue de la pasarela.
¿Dónde deben almacenarse las API Keys de los modelos?
Las credenciales de los proveedores deben permanecer en un sistema seguro de gestión de secretos o en el almacén de credenciales protegido de la pasarela. Las aplicaciones reciben acceso delimitado a la pasarela en lugar de integrar claves de proveedor sin procesar en el código del cliente o distribuirlas a través de múltiples servicios.
