El relay y el proxy de la API de GLM suelen tratarse como un simple cambio de base_url. Solo después de salir a producción se descubre que la experiencia depende de cuatro preguntas: por quién pasa la solicitud, de quién es la clave, cómo se calcula el costo y quién atiende las fallas. Si estas cuatro respuestas no están claras, una tarifa menor no basta para sostener tráfico de producción.

Este artículo compara la conexión directa, el proxy propio y la pasarela gestionada, con énfasis en transparencia de facturación, límites de velocidad, riesgo de claves, conmutación por falla y verificación de la migración. Los modelos disponibles y los precios se rigen por precios de modelos del sitio.

Nota: Zhipu, GLM y BigModel son marcas de sus respectivos titulares. Este artículo solo ofrece una explicación técnica y no implica subordinación ni relación de agencia con Zhipu. El mercado de relays cambia con rapidez y este texto no constituye un respaldo a ningún proveedor.

1. Primero distingue cuatro conceptos

  • Conexión directa oficial: la aplicación solicita directamente la interfaz de la plataforma abierta de Zhipu; la clave, la factura y los límites pertenecen a la propia cuenta.
  • Proxy de red: solo resuelve la accesibilidad de red, no cambia la semántica de la API y la clave sigue siendo propia.
  • Proxy o pasarela propia: el equipo despliega el reenvío, la autenticación, los límites y los registros, y el upstream sigue usando una cuenta oficial o un proveedor conforme.
  • Relay comercial: un tercero reenvía y liquida el costo; puede incluir cuotas, paquetes o claves compartidas, y los límites dependen del operador.
  • Pasarela de IA unificada: entrada compatible con OpenAI que agrega varios modelos y unifica clave, facturación y consola; puede ser gestionada o propia.

Estos términos se mezclan con frecuencia, y el resultado es tratar un problema de red como si fuera un problema del modelo. Antes de firmar basta una pregunta: ¿con la identidad de quién llega la solicitud al upstream?

2. Las cuatro opciones en una tabla

Dimensión Conexión directa oficial Proxy propio Pasarela gestionada
Transparencia de facturación Factura oficial, criterio claro Factura del upstream más el costo propio Depende de las reglas de precio y del detalle de uso
Estabilidad de red Afectada por la salida local Depende del servidor y de la ruta Depende de la ruta de la pasarela y del upstream
Criterio de límites Nivel de cuenta o proyecto Control propio, pero con límites del upstream Revisar reglas del plan y si el grupo es compartido
Clave y datos Propios, los datos van directo al upstream Control propio, auditoría posible Hay que confirmar clave independiente y política de privacidad
Costo de operación Bajo Servidor, certificados y guardias Se traslada al proveedor, sujeto a su disponibilidad

Ninguna opción sirve para todos los equipos: si solo se usa GLM y la red y el pago funcionan, conviene la conexión directa; si se necesita una salida fija y auditoría, el proxy propio; si se requiere una entrada multi-modelo y falta personal de operación, vale la pena evaluar una pasarela gestionada.

3. Facturación: criterios que hay que aclarar más allá del multiplicador

Las cotizaciones habituales de un relay son "precio oficial por un multiplicador" o "paquete de tokens". El multiplicador es solo la entrada; lo que determina la factura son estos ocho puntos:

  1. Si la entrada y la salida se cobran por separado y si el multiplicador es el mismo.
  2. Si la entrada con acierto de caché tiene descuento y sobre qué versión de precio se calcula.
  3. Si los tokens de razonamiento de los modelos de inferencia cuentan como salida.
  4. Si los fallos, los reintentos y las interrupciones de streaming se cobran.
  5. Si la respuesta en streaming devuelve el usage completo.
  6. El monto mínimo de recarga, la vigencia y las condiciones de reembolso.
  7. Si se pueden emitir facturas y cómo se determinan la moneda de liquidación y el tipo de cambio.
  8. Si la factura se puede desglosar por proyecto, clave y modelo.

Escribe estos ocho puntos en una tabla comparativa y reproduce después la misma tanda de solicitudes para calcular el costo real. Los precios del sitio están en precios de modelos y cambian con los modelos y las promociones.

4. Estabilidad: métricas, sondas y conmutación por falla

La estabilidad no se mide con publicidad, sino con seis indicadores: tasa de éxito, latencia P50/P95, latencia del primer token, tasa de timeout, proporción de 429 y velocidad de salida. Prueba con prompts de longitud real, cubriendo streaming, contexto largo y concurrencia, y observa al menos un ciclo de hora pico.

La conmutación por falla no consiste en configurar dos direcciones. Cambia solo ante fallos de conexión, 5xx y códigos claros de límite de velocidad; los errores de configuración como 401, 403 y 400 suelen fallar también en el otro extremo; en solicitudes con efectos secundarios, confirma primero si ya se ejecutaron para evitar cargos duplicados.

import os
from openai import OpenAI

ENDPOINTS = [
    {
        "name": "primary",
        "base_url": os.environ["GLM_BASE_URL"],
        "api_key": os.environ["GLM_API_KEY"],
    },
    {
        "name": "backup",
        "base_url": os.environ["BACKUP_BASE_URL"],
        "api_key": os.environ["BACKUP_API_KEY"],
    },
]

def ask(prompt: str) -> str:
    last_error = None
    for endpoint in ENDPOINTS:
        client = OpenAI(
            base_url=endpoint["base_url"],
            api_key=endpoint["api_key"],
            timeout=60,
            max_retries=0,
        )
        try:
            resp = client.chat.completions.create(
                model=os.environ["GLM_MODEL"],
                messages=[{"role": "user", "content": prompt}],
                max_tokens=512,
            )
            return resp.choices[0].message.content
        except Exception as exc:
            last_error = exc
            print(f"{endpoint['name']} falló: {type(exc).__name__}")
    raise RuntimeError("Fallaron la entrada principal y la de respaldo") from last_error

La capacidad del modelo, la longitud de contexto y el soporte de parámetros de la entrada principal y la de respaldo no tienen por qué coincidir. Antes de conmutar, compara las salidas con un conjunto fijo de pruebas y no trates la entrada de respaldo como equivalente total.

5. Límites y concurrencia: el costo invisible de un grupo compartido

Los límites de la conexión directa oficial suelen estar asociados a la cuenta o al proyecto, y el criterio puede ser concurrencia, solicitudes por minuto o velocidad de tokens, según el plan y el modelo; consulta la consola y la documentación oficial.

Si un relay comercial usa un grupo compartido, tu pico se suma al pico de otros: el servicio funciona con normalidad y en la hora pico aparecen 429 concentrados; el cuerpo del error puede incluir avisos de saldo pendiente o de límite del plan. Ante un 429, lee primero el código de negocio y no reintentes por reflejo.

Otro punto que se pasa por alto es la tormenta de reintentos. Si tres servicios reintentan cuatro veces cada uno, el upstream puede recibir varias veces las solicitudes originales. Lo correcto es limitar la concurrencia en el cliente, usar colas para amortiguar los picos, aplicar retroceso exponencial con jitter y fijar un presupuesto global de reintentos en la pasarela.

6. Propiedad de la clave y límites de los datos

La trampa más habitual de un relay es la clave. Una clave compartida o revendida y una cuota de origen desconocido traen cuatro problemas: si el upstream bloquea la cuenta, el negocio se interrumpe; varios inquilinos compiten por el mismo límite; el contenido de las solicitudes pasa por un tercero y las políticas de registro y retención no son transparentes; las condiciones del servicio pueden prohibir la reventa y, ante una disputa, faltan fundamentos.

Al elegir proveedor, confirma al menos: entidad legal, condiciones del servicio, política de privacidad, capacidad de facturación, contacto de incidentes y mecanismo de salida. En escenarios muy regulados, como finanzas y salud, conviene evaluar primero la conexión directa oficial, el despliegue privado o un proveedor dispuesto a firmar un acuerdo de tratamiento de datos.

Hay una línea que no conviene cruzar: no entregues la clave oficial a un relay para que la recargue o la administre. Cuando la clave sale de la cuenta, el uso y los permisos dejan de estar bajo control.

7. Pasos de migración: cambia una variable a la vez

  1. Registra la línea base: tasa de éxito, P50/P95, tasa de timeout, proporción de 429, consumo de tokens por cada mil solicitudes y factura.
  2. Inventaría dependencias: nombres de modelo, parámetro thinking, tools, salida JSON, streaming y entrada de imágenes.
  3. Crea una clave de prueba y una de producción, con límites de cuota y alertas separados.
  4. Cambia solo base_url y api_key y ejecuta la solicitud mínima en el entorno de preproducción.
  5. Reproduce con prompts reales y compara calidad, tiempo y criterio de usage.
  6. Revisa el mapeo de errores: que 401, 403, 429, 5xx y los timeouts se identifiquen correctamente.
  7. Despliega de forma gradual entre 5% y 10% del tráfico, observa de 3 a 7 días y conserva la entrada original para volver atrás.
  8. Después del cambio total, concilia durante una semana más para confirmar que factura, uso y registros coinciden.

No cambies a la vez el modelo, los prompts y la pasarela; si surge un problema, no podrás atribuirlo.

8. Lista de verificación: cómo saber si una entrada es confiable

Punto a verificar Cómo hacerlo Señal anómala
Latencia Repetir el mismo prompt y comparar P50/P95 Mucha variación o lentitud sostenida frente a la conexión directa
Tasa de error Medir la proporción de 429, 5xx y timeouts Fallos concentrados en hora pico
Consumo Comparar usage de la respuesta con la factura del panel No coinciden o el streaming no trae usage
Identidad del modelo Comparar límites de capacidad y estilo de salida con un conjunto fijo Capacidad claramente degradada o contexto más corto
Aislamiento de clave Confirmar si la clave es independiente y si se puede rotar Se niegan a explicar el origen de la clave
Contrato y soporte Revisar entidad, condiciones, facturas y respuesta a tickets Solo hay un contacto personal y no hay condiciones

Señales de alerta: precio muy por debajo del oficial durante mucho tiempo, promesa de cero fallas, negativa a entregar detalle de uso, exigencia de entregar la clave oficial o imposibilidad de explicar dónde están los datos. Ante cualquiera de ellas, prueba primero con poco tráfico y no migres la producción de una vez.

9. Cuándo conviene más un proxy propio

Un proxy propio conviene cuando se necesita una IP de salida fija, auditoría unificada, enrutamiento entre varios upstream o la clave debe permanecer en manos propias. La práctica habitual es combinar un proxy inverso con gestión de claves, límites, registros y alertas, manteniendo una cuenta oficial o un proveedor conforme en el upstream.

Hay que calcular el costo completo: servidor, ancho de banda, certificados, actualizaciones, parches de seguridad y guardias. Con poco volumen y sin personal de operación, el proxy propio suele salir más caro y tampoco evita los límites del upstream.

10. Recomendaciones de elección: ordena según las restricciones

  1. Mira primero la red y el pago: si la entrada oficial es estable y la recarga fluye, prioriza la conexión directa.
  2. Mira después el control: si necesitas salida fija, auditoría y claves privadas, evalúa el proxy propio.
  3. Mira luego el alcance de modelos: si un solo punto de entrada debe invocar varios modelos, evalúa una pasarela gestionada.
  4. Mira al final la capacidad de servicio: entidad, condiciones, facturas, tickets y política de datos.

Si necesitas una entrada unificada, puedes crear una clave de prueba en ZSQH AI Gateway y migrar después de validar el flujo; los modelos disponibles y la facturación están en precios de modelos. No tomes "barato" como único criterio.

11. Preguntas frecuentes

1. ¿Cuál es la diferencia entre relay y proxy?

El proxy suele referirse al reenvío en la capa de red y solo resuelve la accesibilidad; el relay también incluye cuenta, facturación o distribución de claves. Antes de contratar, aclara los límites y la propiedad de la clave.

2. Si el relay es más barato que el oficial, ¿se puede confiar?

Puede provenir de compra por volumen, subsidio de ruta o reventa de cuota, y también puede venir con claves compartidas e inestabilidad. Revisa primero el criterio de facturación, el detalle de uso y las condiciones, y prueba después con poco tráfico.

3. ¿Cómo saber si un relay cambió el modelo?

No basta con mirar el campo model, porque puede reescribirse. Compara límites de capacidad, longitud de contexto, estilo de salida y estructura de usage con un conjunto fijo de pruebas, y conserva la conexión directa como referencia.

4. ¿Cuánto código hay que cambiar para migrar a una pasarela?

En la mayoría de los proyectos con el SDK de OpenAI solo hay que cambiar base_url y api_key, y ajustar el nombre del modelo según la página de precios. Si se usan thinking, tools o campos de respuesta especiales, hay que hacer pruebas de compatibilidad.

5. ¿En qué casos conviene un proxy propio?

Cuando se necesita una IP de salida fija, auditoría unificada, enrutamiento entre varios upstream o una exigencia de cumplimiento que obliga a mantener la clave en manos propias. Con poco volumen y sin personal de operación, el costo del proxy propio suele ser mayor.

Lecturas relacionadas