¿Qué es la inferencia de LLM? Latencia, rendimiento, procesamiento por lotes y costes explicados
Í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 error. Una pasarela de IA traslada estas preocupaciones compartidas a una única capa de control. Proporciona 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 crece de un solo modelo y una sola funcionalidad a múltiples cargas de trabajo en 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 pertinentes 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 cubrir 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, credenciales, reintentos, registros de uso y políticas de acceso. Algunas pasarelas normalizan principalmente los formatos de API. Otras ofrecen una gestión del tráfico, observabilidad y controles de costes más avanzados.
La pasarela de IA de SiliconFlow combina un acceso unificado a los modelos con enrutamiento inteligente, límites de tasa y control de costes. Los desarrolladores pueden acceder a más de 200 modelos lingüísticos y multimodales optimizados a través de una API compatible con OpenAI, lo que reduce 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 a través de una pasarela de IA suele seguir este camino:
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 funcionalidades individuales del producto. Un asistente de atención al cliente, un procesador de documentos y una herramienta 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 coherente facilita probar 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 diferir en la longitud de contexto, los parámetros admitidos, la llamada a herramientas (tool calling), la output estructurada y el comportamiento de la respuesta.
Pasarela de IA frente a pasarela de API tradicional
Una pasarela de API tradicional gestiona el tráfico general de la aplicación. Suele encargarse 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 cobran por el uso.
La decisión entre pasarela de IA o pasarela de API rara vez es una opción 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 políticas 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 multimodales |
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 del backend | Reintentos más fallback a un modelo de respaldo validado |
Visibilidad de costes | Recuentos de solicitudes y límites de cuota | Gasto de token de input, output y en caché por funcionalidad 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 la extracción rutinaria, 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 multimodales 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 actual.
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 preguntas complejas sobre cuentas. El enrutamiento centralizado permite al equipo ajustar esa política sin 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 de límite de tasa 429 o un fallo temporal del servicio. El respaldo debe admitir las características esenciales de la solicitud original. Un modelo de solo text no puede procesar una solicitud de image, y un modelo sin soporte para tool calling no puede reemplazar 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 respaldo en cuanto a precisión, formato de output, latencia y finalización 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 generar trabajo o cargos duplicados si la primera solicitud continuó procesándose. Las acciones de los 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 suelen aplicar límites de solicitudes por minuto y de tokens por minuto al mismo tiempo. Un número reducido de prompts largos puede alcanzar un límite de token antes del límite de solicitudes, mientras que muchas llamadas cortas pueden agotar primero la asignación de solicitudes.
Una pasarela de IA puede poner solicitudes en cola, controlar la concurrencia, aplicar retroceso (backoff) y distribuir el tráfico antes de que una 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 ascendente siguen aplicándose, por lo que la pasarela debe operar dentro de la capacidad disponible.
SiliconFlow utiliza RPM, RPH, RPD, TPM, TPD, IPM e IPD en diferentes servicios de modelos. Sus límites de tasa se aplican a nivel de cuenta y no por separado a cada API Key. Los diferentes modelos tienen límites independientes, por lo que alcanzar el umbral de un modelo no interrumpe el acceso normal a otro.
Alcanzar un límite aplicable devuelve un HTTP 429. Las aplicaciones en producción deben utilizar una concurrencia controlada y un retroceso 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 indican por millón de tokens, el cálculo es:
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 basado en costes puede enviar el trabajo rutinario a un modelo económico mientras reserva los modelos de mayor capacidad para las tareas que los necesitan. Los límites máximos de output pueden evitar generaciones inesperadamente largas, mientras que las cuotas de usuario o de proyecto pueden contener el tráfico anormal.
Donde se admita, las pasarelas también pueden atribuir el gasto por funcionalidad, establecer límites presupuestarios, detectar bucles de reintento y almacenar en caché respuestas repetidas adecuadas. El almacenamiento en caché funciona mejor para solicitudes estables cuyas respuestas se pueden reutilizar. Los prompts dinámicos, personalizados o confidenciales requieren un tratamiento más cuidadoso.
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 token en nuestra página de precios, y luego elegir un modelo que coincida con 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 aplicación. Una pasarela se vuelve más valiosa a medida que aumenta la complejidad operativa.
Las señales habituales 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 requieren un respaldo probado.
Los costes de las API son difíciles de atribuir.
Cambiar de modelo requiere modificaciones en varios servicios.
Los equipos necesitan políticas de acceso o uso centralizadas.
Las operaciones de producción necesitan registros y métricas coherentes.
El volumen de solicitudes es solo un factor. Una aplicación más pequeña que maneje datos confidenciales puede necesitar controles centralizados tempranamente, mientras que un servicio de alto volumen que use un solo endpoint estable puede beneficiarse inicialmente más de la puesta en cola y 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 admita las cargas de trabajo de lenguaje, vision, audio, embedding y reclasificación que utiliza su aplicación. Pruebe el streaming, el contexto largo, 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 fallos. La pasarela debe hacer que el comportamiento de tiempo de espera agotado, reintento y fallback sea claro. Los equipos necesitan saber qué errores activan otro intento, cómo se distribuye el tráfico y cómo evita el sistema las tormentas de reintentos.
Los controles de tráfico deben reflejar tanto las solicitudes como los tokens. Compruebe si se pueden aplicar límites por modelo, usuario, aplicación, proyecto o equipo. Los informes de costes deben separar tokens de input, tokens de output, tokens en caché y precios de modelos al nivel requerido para la elaboración de presupuestos.
La observabilidad debe cubrir el tiempo 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 políticas de registro también deben proteger los prompts y las respuestas confidenciales mediante controles de acceso y retención adecuados.
Por último, mida la latencia propia de la pasarela y su disponibilidad bajo una concurrencia realista. Se encuentra en la ruta crítica de las solicitudes, por lo que su fiabilidad debe coincidir con la de las aplicaciones que dependen de ella.
Preguntas frecuentes sobre pasarelas de IA
¿Añade latencia una pasarela de IA?
Cada 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, las comprobaciones de políticas y el registro. Los equipos deben medir tanto la sobrecarga de la pasarela como la latencia total del modelo bajo un tráfico realista.
¿Puede una pasarela de IA gestionar respuestas en streaming?
Sí, si la pasarela admite el protocolo de streaming utilizado por el endpoint del modelo. Verifique que preserve los eventos, los errores, los datos de uso, el tiempo hasta el primer token y el comportamiento ante la desconexión del cliente.
¿Puede una pasarela de IA gestionar modelos alojados y autodesplegados?
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, las redes, las características admitidas y el modelo de despliegue de la pasarela.
¿Dónde deben almacenarse las API Keys de los modelos?
Las credenciales del proveedor deben permanecer en un sistema de secretos controlado o en el almacén protegido de credenciales de la pasarela. Las aplicaciones reciben un acceso acotado a la pasarela en lugar de incrustar claves de proveedor sin procesar en el código del cliente o distribuirlas entre múltiples servicios.
