El mes pasado asumí un proyecto de atención al cliente inteligente. El equipo de negocio pidió integrar simultáneamente tres grandes modelos: DeepSeek, Tongyi Qianwen y Doubao, con el argumento de que "usemos el más barato y, si uno tiene límite de tasa, cambiemos a otro". Suena razonable, pero al implementarlo descubrí que los SDK de los tres tienen métodos de autenticación, criterios de facturación y estrategias de reintento por tiempo de espera completamente distintos. DeepSeek usa Bearer Token, Tongyi pasa por la API-KEY de DashScope con firma, y los campos de autenticación de Doubao son diferentes otra vez. En la facturación, algunos calculan por separado los tokens de entrada y salida, otros combinan el precio, y otros aplican descuentos cuando hay aciertos de caché. Los tiempos de espera son aún más problemáticos: uno tiene 30 segundos por defecto, otro 60, y el número de reintentos y la estrategia de retroceso hay que escribirlos por separado.
Al final del código, conté y solo la capa de adaptación que encapsula los tres clientes ocupaba más de 800 líneas, sin contar el mapeo de códigos de error. Por eso el concepto de gateway de modelos se ha mencionado repetidamente en el círculo de ingeniería de IA en China desde el año pasado. En una frase: un gateway de modelos es la capa intermedia que oculta las diferencias entre las API de múltiples grandes modelos y expone una interfaz unificada al negocio superior.
Conexión directa, gateway propio y plataforma de agregación: el costo de ingeniería de tres enfoques
Primero, la conexión directa al SDK oficial. Tres modelos implican tres conjuntos de autenticación, tres de manejo de errores y tres de lógica de reintento. El código de negocio está lleno de if-else para decidir a cuál ir. Agregar un nuevo modelo obliga a modificar otra vez la capa de adaptación. Calculamos que mantener el código de adaptación de tres conexiones directas representa aproximadamente el 15% del trabajo de backend de todo el proyecto. Si la cantidad de modelos llega a cinco o más, esa proporción se sale de control.
Construir un gateway propio es la segunda opción. La idea central es escribir una capa de proxy que reenvíe las solicitudes a las API de cada proveedor. La ventaja es el control; la desventaja es que hay que encargarse de la conversión de protocolos, la rotación de claves, las colas de limitación de tasa y las estadísticas de uso. Evaluamos internamente que un gateway propio listo para producción requiere al menos dos ingenieros durante seis a ocho semanas, y después hay que mantener continuamente los cambios de versión de cada API. Para equipos pequeños y medianos, esa cuenta no sale rentable.
La tercera opción es una plataforma de agregación de API de IA. Estas plataformas encapsulan las API de múltiples grandes modelos y ofrecen un único conjunto de interfaces. El costo de ingeniería es el más bajo y el ciclo de integración suele medirse en días. En nuestro proyecto usamos SiCore TokenWorks, que es compatible con el OpenAI SDK; basta cambiar una línea de base_url para hacer el cambio. Hay que tener cuidado con una trampa: las distintas plataformas de agregación tienen políticas predeterminadas diferentes para tiempos de espera y reintentos. Antes de integrar, hay que confirmar si la plataforma permite personalizar el tiempo de espera; de lo contrario, las solicitudes con respuestas largas ocasionales en producción serán cortadas antes de tiempo por la capa de la plataforma, y el mensaje de error no permitirá distinguir si fue un timeout del gateway o del modelo.
Las cuatro capacidades centrales de un gateway de modelos
La normalización de protocolos es la base. Unificar los formatos de solicitud, los formatos de respuesta y los códigos de error de cada proveedor en un solo estándar. En el estado ideal, el negocio superior solo reconoce un formato de interfaz y cambiar de modelo solo implica modificar la configuración, no el código. Esta es también la razón por la que la interfaz compatible con OpenAI es popular en China: casi toda la cadena de herramientas del ecosistema la soporta.
La estrategia de enrutamiento es donde reside el valor del gateway. Se puede enrutar por tipo de tarea, por ejemplo, preguntas y respuestas simples van a Doubao y el razonamiento complejo va a DeepSeek; también por costo, usando el que tenga el precio más bajo en ese momento; o por disponibilidad, cambiando automáticamente a un respaldo cuando uno alcanza su límite de tasa. Al probar el enrutamiento multimodelo de SiCore TokenWorks, descubrimos que la estrategia de derivar según la complejidad de la tarea puede reducir bastante el costo total de las llamadas en escenarios de atención al cliente, porque una gran cantidad de preguntas simples no necesitan invocar el modelo con mayor capacidad de razonamiento.
La limitación de tasa con degradación y la agregación de uso son necesidades imprescindibles en producción. La limitación debe poder identificar errores 429 y reintentar automáticamente en cola; la degradación debe cambiar a un modelo de respaldo cuando un servicio no esté disponible. La agregación de uso, por su parte, reúne en un solo lugar el volumen de llamadas, el consumo de tokens y los costos dispersos entre varios proveedores, para facilitar la contabilidad de costos y el control presupuestario. Si se construyen estas dos partes por cuenta propia, el trabajo no es menor, sobre todo la agregación de uso, ya que los criterios de facturación de cada proveedor no son consistentes y la lógica de conciliación hay que escribirla por separado.
Implementación por etapas según la madurez del negocio
Si el proyecto recién comienza y solo integra un modelo, basta con la conexión directa al SDK oficial; no hace falta un gateway, y añadir una capa solo agrega un punto de fallo. Cuando el negocio se estabilice y haya que integrar un segundo modelo, entonces conviene considerar introducir la capa de gateway, ya que en ese momento el costo de cambio todavía es bajo.
Si el negocio ya integra tres o más modelos y tiene requisitos de disponibilidad, se recomienda ir directamente a una plataforma de agregación de API de IA y externalizar los costos de adaptación y operación. Al seleccionar, hay que fijarse en tres puntos clave: si es compatible con el OpenAI SDK, si permite personalizar tiempos de espera y reintentos, y si las estadísticas de uso son claras. En cuanto al gateway propio, salvo que existan requisitos especiales de cumplimiento normativo o que el equipo tenga suficiente personal de operación, no se recomienda invertir en él durante las primeras etapas del negocio.
El gateway de modelos resuelve la complejidad de ingeniería de la integración multimodelo, no el problema de la capacidad de los modelos. Elegir bien el enfoque permite que el equipo vuelva a concentrar su energía en la lógica de negocio en sí.