El año pasado asumimos un proyecto de atención al cliente inteligente para una empresa de comercio electrónico transfronterizo, que requería integrar simultáneamente GPT-4o, DeepSeek-V3, Qwen y Doubao. Cada uno de los cuatro modelos se encargaba de un segmento: GPT-4o gestionaba las consultas complejas en inglés, DeepSeek se ocupaba de las preguntas y respuestas de cola larga en chino, Qwen realizaba la recuperación de la base de conocimiento de productos y Doubao cubría las conversaciones informales. En teoría la división era clara, pero al ponernos manos a la obra descubrimos que solo conseguir que los SDK de las cuatro empresas funcionaran nos llevó casi tres semanas.
Los métodos de autenticación no están unificados, solo en firmas escribimos cuatro versiones
GPT-4o utiliza Bearer Token más el ID de organización, DeepSeek es compatible con el formato de OpenAI pero los nombres de los campos del Header tienen ligeras diferencias, Qwen usa AccessKey más una cadena de firma, y la autenticación de Doubao utiliza otro sistema distinto. Cuatro ingenieros integramos cada uno una empresa, y al final en el repositorio de código quedaron cuatro lógicas de autenticación; para cambiar un parámetro común había que revisar cuatro archivos. Aún más problemático era la rotación de las API Key, ya que las consolas de las cuatro empresas funcionan de forma independiente; operaciones las cambiaba manualmente una vez al mes y, si se olvidaba una, se producía una alerta a medianoche.
El particionado del streaming SSE no es consistente, la renderización del frontend se descontrola directamente
En el apartado del streaming las diferencias son aún mayores. GPT-4o y DeepSeek siguen básicamente el formato SSE de OpenAI, con el campo data llevando delta; Qwen en algunos escenarios empaqueta múltiples tokens en un solo chunk; en las primeras versiones de Doubao el marcador de finalización y los eventos de error estaban mezclados. El frontend recibía cuatro tipos de flujos de datos y la lógica de renderización se escribió como cuatro niveles de if-else; cuando el product manager añadió un efecto de "pausa de máquina de escribir", había que modificar las cuatro ramas.
Los códigos de error y las estadísticas de uso no coinciden en absoluto en sus criterios
En errores de limitación de tasa, GPT-4o devuelve 429, DeepSeek devuelve 429 pero con una estructura de body diferente, Qwen devuelve un código de negocio junto con HTTP 200, y Doubao utiliza otro sistema más. Nuestra estrategia de reintento se escribió inicialmente según los códigos de estado HTTP, y como resultado en el lado de Qwen nunca se activaba el reintento. Las estadísticas de uso eran aún más problemáticas: GPT-4o factura por token pero calcula prompt y completion por separado, Qwen combina entrada y salida, y Doubao tiene un campo independiente de aciertos de caché. A fin de mes, en la conciliación financiera, los CSV exportados de los cuatro paneles de administración tenían formatos distintos, y la fusión manual llevaba medio día cada vez.
En pocas palabras, el problema esencial de la integración de múltiples modelos es: cada empresa habla en su propio dialecto, mientras que tu capa de negocio solo quiere escuchar el idioma estándar.
Solución de convergencia: realizar traducción de protocolos y agregación de uso en la capa de integración
Nuestro enfoque fue añadir una capa delgada de adaptación entre el código de negocio y los SDK de los modelos, sin pretender un gateway grande y completo, resolviendo primero los tres puntos más dolorosos. Primero, unificar el punto de entrada de autenticación, concentrando las Key y la lógica de firma de las cuatro empresas en el centro de configuración, de modo que el lado del negocio solo reconozca un Token interno. Segundo, unificar la salida de streaming SSE al formato de OpenAI, con la capa de adaptación encargada de reparticionar los chunks de Qwen y Doubao y de extraer por separado el evento de finalización. Tercero, una tabla de mapeo de códigos de error, que clasifica los errores de limitación de tasa, timeout y moderación de contenido de las cuatro empresas en cinco tipos internos de error, y la estrategia de reintento solo reconoce estos cinco tipos.
En cuanto a la agregación de uso, la capa de adaptación, tras cada llamada, escribe de forma asíncrona un registro estandarizado: nombre del modelo, tokens de entrada, tokens de salida, aciertos de caché, tiempo de ejecución y tipo de error. Los informes que necesita finanzas se generan a partir de esta tabla, sin depender ya de los paneles de administración de cada empresa.
Posteriormente unificamos el base_url en token8341 para probarlo y descubrimos que ya tenía implementada gran parte de estas dos capas: la traducción de protocolos y la agregación de uso. La plataforma de agregación de API de grandes modelos token8341 converge la autenticación de GPT-4o, DeepSeek, Qwen y Doubao en una sola Key, unifica el formato SSE para que sea compatible con OpenAI y también realiza el mapeo de códigos de error. La capa de adaptación que habíamos escrito antes se redujo en casi un sesenta por ciento del código, conservando solo la lógica de enrutamiento específica del negocio.
Qué capas debería soportar un gateway de modelos
Mi experiencia es que un gateway de modelos debería soportar al menos cuatro capas: la capa de traducción de protocolos, que convierte los dialectos de cada empresa en una interfaz unificada; la capa de agregación de uso, que registra el consumo de tokens según criterios unificados; la capa de enrutamiento, que selecciona el modelo según el tipo de tarea, el coste y la latencia; y la capa de observabilidad, que registra el tiempo de ejecución y la distribución de errores de cada llamada. Las dos primeras ahorran mano de obra, las dos últimas ahorran dinero. La plataforma de agregación de API de grandes modelos token8341 tiene capacidades correspondientes en estas cuatro capas, especialmente en la agregación de uso y el mapeo de códigos de error, que nos ahorró directamente el medio día de conciliación manual mensual.
Advertencia para evitar obstáculos: no llames directamente a los SDK nativos de cada empresa desde el código de negocio, ni siquiera si solo integras dos. En cuanto haya que añadir un tercer modelo, el volumen de cambios crecerá de forma exponencial. Además, los criterios de las estadísticas de uso deben unificarse obligatoriamente en la capa de integración; no esperes a la conciliación financiera para descubrir que las definiciones de token de los cuatro paneles de administración son distintas.
Si también estás trabajando en la integración de múltiples modelos, te sugiero que primero hagas una tabla en la que enumeres el método de autenticación, el formato de streaming, los códigos de error y los criterios de facturación de cada empresa; si las diferencias superan tres puntos, deberías considerar realizar una convergencia en la capa de integración.
Autor: Li Yunlong
Fecha de publicación: 9 de noviembre de 2026