Preguntas frecuentes sobre gateways de IA
Preguntas reales sobre la elección de un gateway de IA / gateway de LLM / proxy de LLM, su costo, fiabilidad y cumplimiento, con respuestas.
Estas preguntas provienen de lo que desarrolladores y arquitectos realmente preguntan sobre gateways de IA en Reddit, StackOverflow y Zhihu: costo, conmutación por error, latencia, riesgo de los relés, cumplimiento en China, compatibilidad con llamadas a herramientas, acceso con varios SDK, herramientas MCP, upstreams de Bedrock, voz en tiempo real y aislamiento multiusuario. GateLLM es un gateway empresarial multimodelo, autoalojado y BYOK: las claves viven en memoria, las solicitudes van directas a las API de los proveedores y se licencia por instancia, sin recargo por token.
Solo si el gateway se licencia por instancia en lugar de recargar los tokens. GateLLM se licencia por instancia de 2 GB (Pro $400/mes), nunca con recargo por token ni sobretasa de plataforma o pago; usted paga a los proveedores a tarifas estándar. El ahorro real viene de la Composición: un modelo de primer nivel (Claude Opus) planifica mientras los modelos SOTA abiertos (GLM / Qwen / DeepSeek) ejecutan, a ~1/7 del costo. Los agregadores SaaS suelen añadir ~5–8% en tarifas de plataforma y pago: un costo oculto importante a escala.
Criterio honesto: un solo proveedor, un solo equipo, sin restricciones de cumplimiento y un gasto mensual manejable: llamar directamente a las API es más sencillo y no necesita un gateway. Un gateway empieza a amortizarse cuando necesita conmutación por error entre proveedores, atribución de costos por equipo, cumplimiento o residencia de datos, o visibilidad en tiempo real del gasto desbocado. No adopte uno antes de necesitarlo de verdad.
Llamar directamente a un solo proveedor es un punto único de fallo: una caída puede tumbar toda su aplicación. GateLLM admite conmutación por error entre proveedores: cuando el primario devuelve 5xx o se agota el tiempo, el tráfico pasa a un proveedor de respaldo sin cambios de código. Además, para llamadas de mayor riesgo puede ejecutar una revisión de código multimodelo en su capa de orquestación (por ejemplo, revisión paralela en GitHub Actions); el gateway aporta la interoperabilidad de protocolos para que varios modelos comprueben la misma solicitud.
Un gateway SaaS añade un salto adicional fuera de su red. GateLLM está autoalojado dentro de su VPC; el salto adicional hasta la API del proveedor es comunicación local entre procesos: una sobrecarga inferior a un milisegundo, con un impacto insignificante en el tiempo hasta el primer token en streaming.
Sí. La Composición de GateLLM admite políticas según el modo: los administradores fijan los niveles de planificación y ejecución (modelos cerrados de primer nivel para planificar, SOTA abierto para ejecutar) para lograr ~97% de capacidad a ~14% del costo. También puede clasificar por número de tokens o complejidad para enrutar dinámicamente, evitando que todo el tráfico vaya al modelo más caro.
Un proxy deficiente sí: almacena el flujo, rompe los fragmentos JSON de tool_calls o falla ante las diferencias de formato de llamada a herramientas entre proveedores. GateLLM reenvía los flujos de forma nativa sin almacenarlos y hace normalización de capacidades: unifica las llamadas a herramientas, la salida estructurada, la caché de prompts, los tokens de razonamiento y otros tres puntos de acoplamiento entre proveedores tras una sola interfaz, para que la mezcla de modelos entre proveedores nunca se rompa por deriva de formatos.
Un relé reenvía sus solicitudes a través de sus propios servidores: sus prompts, claves y salidas quedan expuestos a él, con riesgos reales de sustitución de modelo, degradación o fuga del operador (un estudio de CISPA encontró fallos de verificación de identidad en el 45,83% de las pruebas de huella de modelos, arxiv.org/abs/2603.01919). GateLLM es BYOK y autoalojado: las claves viven solo en la memoria del gateway, las solicitudes van directas a las API de los proveedores y no hay terceros en la ruta, así que no hay margen para sustituir, degradar ni desaparecer.
Sí. GateLLM se despliega por completo dentro de su red: los datos nunca salen, lo que cumple con la normativa de exportación de datos. Habla de forma nativa el protocolo DashScope para llegar a modelos nacionales (Tongyi / Zhipu / DeepSeek / Doubao). El tráfico a modelos cerrados se reduce mediante la Composición, lo que recorta las llamadas transfronterizas.
Las facturas mensuales llegan demasiado tarde. Token Ops de GateLLM atribuye el costo por solicitud (por equipo / agente / modelo / cliente) con visibilidad en tiempo real de la tasa de consumo y topes de presupuesto por agente que realmente detienen las llamadas. La facturación tolerante a fallos (reservar → liquidar → reembolsar) sigue siendo correcta ante caídas del proceso; la API de gestión exporta datos de conciliación a su sistema interno de facturación.
Con un agregador SaaS solo puede confiar en su palabra: no hay verificación criptográfica de que no esté cambiando discretamente a un modelo más pequeño para quedarse con el margen (OpenRouter, de hecho, no verifica la identidad del modelo). GateLLM es BYOK y autoalojado: usted usa sus propias claves y las solicitudes van de su gateway directamente al endpoint de la API del proveedor; la identidad del modelo la garantiza la propia API del proveedor, sin ningún salto reemplazable en medio.
Sí. Apunte el base_url de su SDK de OpenAI a GateLLM (con /v1), sin otros cambios de código, y llame a todos los modelos mediante una interfaz unificada. Un solo cambio de base_url completa la migración: sin deriva de funciones ni capa de proxy; su cliente de OpenAI usa directamente un endpoint unificado equivalente al del proveedor.
No: un solo gateway sirve a los tres. Apunte el base_url del SDK de OpenAI al gateway (con /v1); apunte el SDK de Anthropic a la raíz del gateway (el SDK añade /v1/messages por su cuenta, con la clave en la cabecera x-api-key); el SDK de Google Gemini se conecta directamente (clave en la cabecera x-goog-api-key). El gateway traduce en ambas direcciones entre cuatro protocolos de entrada y cuatro de salida (OpenAI / Anthropic / Gemini / DashScope); los protocolos del cliente y del upstream pueden diferir: llame a Claude desde el SDK de OpenAI, a GPT desde el SDK de Anthropic o a DeepSeek desde el SDK de Gemini sin cambios de código; los clientes de terceros como Cherry Studio usan la entrada compatible con OpenAI. Consulte la matriz de interoperabilidad de protocolos en docs.gatellm.io reference/protocol-matrix.
Sí. Bedrock se conecta como upstream (protocolo aws_converse / aws_invoke, clave de API de Bedrock + endpoint regional de ejecución, con soporte de perfiles de inferencia); los clientes siguen usando los SDK de OpenAI / Anthropic / Gemini y el gateway traduce el protocolo. Los modelos Claude / GLM alojados en Bedrock y los modelos directos del proveedor pueden mezclarse en el mismo enrutamiento o balanceador bajo un único plano de gobernanza.
Sí. El gateway tiene un proxy MCP integrado: agrega varios servidores externos de herramientas MCP (HTTP con streaming / SSE) detrás de un único endpoint /mcp, para que Claude Desktop o cualquier cliente MCP los llame todos con una sola clave del gateway. Las ACL de herramientas por grupo de claves y los presupuestos de contexto gobiernan el acceso, con búsqueda BM25 integrada cuando la lista de herramientas crece. La admisión de herramientas, la limitación de velocidad y la auditoría comparten el mismo plano de gobernanza que el tráfico de modelos.
Sí. El gateway conecta sesiones WebSocket en /v1/realtime (protocolos OpenAI Realtime y DashScope Realtime). Las sesiones de voz de larga duración se ejecutan en paralelo al tráfico HTTP: misma autenticación y admisión con clave, medida por turno (response.create → response.done) en la misma canalización de estadísticas, facturación y registros que HTTP, con un único libro de costos coherente.
Cinco capas: los grupos de claves delimitan a qué modelos y balanceadores puede llegar cada inquilino; las claves de acceso y las reglas de ACL por cabecera diferencian a los clientes según la cabecera de la solicitud; el mapeo de modelos por identidad enruta el mismo nombre de modelo a distintos upstreams por inquilino; los límites de RPM / concurrencia / TPM por clave acotan el uso; y la atribución de costos por solicitud hace que cada inquilino vea solo su propio gasto. Consulte la guía de aislamiento multiusuario en docs.gatellm.io usecases/multi-tenant-isolation.
Sí. GateLLM intercepta la búsqueda en la capa del gateway: configure un motor de búsqueda (serper, comprobable directamente en la consola) y luego use interruptores de tres estados por modelo (seguir la capacidad / forzar activación / forzar desactivación) para controlar la inyección. Los resultados se sintetizan en bloques de búsqueda nativos por protocolo de cliente (server_tool_use de Anthropic / url_citation de OpenAI / web_search_call de Responses): los modelos abiertos también obtienen fundamento de búsqueda. Los fallos de búsqueda se degradan sin bloquear las solicitudes, y la búsqueda interceptada se excluye de la facturación de uso. Consulte console/search en docs.gatellm.io.
Sí. Un upstream puede contener varias claves de API con distribución ponderada: un hash ponderado determinista (FNV-1a) fija de forma persistente cada llamador a la misma clave (afinidad de caché), y cuando una clave falla el gateway reintenta con la siguiente clave no probada dentro de ese upstream. Las claves con weight=0 están en espera y solo se usan después de que fallen todas las claves con weight>0. El estado de fijación se puede observar fila por fila en la consola. Consulte reference/upstreams-models-fields en docs.gatellm.io.
Sí. Cualquier endpoint compatible con OpenAI funciona como upstream: configure una URL base personalizada y los servicios de vLLM / Ollama / TGI se gobiernan junto a los proveedores de la nube. Los proxies de salida (socks5 / http), las cabeceras de solicitud personalizadas y el DNS por upstream se pueden configurar para redes privadas y topologías especiales.
No se requiere YAML. GateLLM incluye una consola visual: upstreams / modelos / balanceadores de carga / control de acceso / MCP / estadísticas / logs se configuran todos por interfaz gráfica, con cambio instantáneo entre chino e inglés. Los cambios por lotes pasan por preparar → previsualizar (conjunto completo de conflictos de espacio de nombres) → confirmación atómica, revirtiendo todo el lote ante cualquier conflicto. Las cuentas de la consola tienen roles de administrador y monitor (solo lectura), y cada operación e inicio de sesión queda auditado.
LiteLLM es un excelente proxy de LLM de código abierto. GateLLM y LiteLLM comparten una base de capacidades (enrutamiento, llamadas a herramientas, salida estructurada, caché y SSO mediante OIDC + SAML 2.0 + SCIM). Los diferenciadores de GateLLM son el único binario en Rust, las 15 formas de protocolo (las 4 familias de protocolo de chat traducen cualquiera a cualquiera, el resto según la matriz de interoperabilidad), la inyección automática de caché en el gateway y una consola sin YAML; LiteLLM lidera en su ecosistema empresarial (gestores de secretos, callbacks de guardrails de terceros, callbacks de observabilidad). Consulte /compare/litellm.
Sí. Totalmente autoalojado en su VPC; claves BYOK solo en memoria, nunca en disco; SSO empresarial (OIDC: Azure AD / Okta / genérico, más SAML 2.0 y aprovisionamiento automático SCIM 2.0); registros de auditoría a nivel de solicitud, exportables; listo para RGPD; controles alineados con SOC 2 Type II / ISO 27001 (certificación en preparación). Consulte /security.
En Consola → Ajustes → Facturación, cree una captura de precio manual para el modelo: queda marcada como fijada (insignia amarilla). Un precio fijado pasa a ser el vigente y prevalece sobre la base automática que hay debajo; las actualizaciones del sistema omiten ese modelo y nunca sobrescriben su precio manual. Al eliminarlo, se vuelve a la siguiente fila automática y se autorregenera.
No. Las capturas de precios se ordenan por created_at y cada una cubre solo su ventana [su tiempo, siguiente tiempo): la más antigua rellena el historial y la más reciente se extiende hacia adelante indefinidamente. Cree una captura nueva con una fecha de vigencia futura para programar la bajada y que solo afecte a los meses posteriores, o rellene un precio histórico para costear los meses pasados con precisión.
Fije una cuota de costo diaria y mensual (importe en USD) en la clave de acceso: son dos ciclos independientes evaluados por día y mes calendario UTC, que devuelven 429 quota_exceeded y detienen el servicio en el momento en que cualquiera se supere (la ventana diaria incluye Retry-After). Las cuotas se heredan de clave → grupo → global; la cuota de un grupo es un tope por clave dentro del grupo (no un libro compartido), y entre grupos prevalece la más amplia.
¿No encontró su pregunta? Hable con nosotros.