El relay y el proxy de la API de Mistral suelen presentarse como «cambiar la dirección y listo». En la práctica, la elección debe responder cuatro preguntas: si se trata de un reenvío de red o de una reventa de cuentas, cómo se calcula el dinero, quién responde cuando algo falla y si las claves y los datos están bajo control.

Este artículo compara las opciones habituales y ofrece una lista de migración y verificación que se puede seguir paso a paso. Los modelos y la facturación concretos se rigen por los precios de modelos y por las condiciones vigentes de cada proveedor.

Nota: Mistral y Mistral AI son marcas de sus respectivos titulares; este artículo no tiene relación de subordinación con Mistral. El mercado de relays cambia con rapidez; aquí se describen las formas habituales de octubre de 2026, sin respaldar a ningún proveedor ni emitir opinión legal.

1. Distingue primero cuatro conceptos

  • Relay de API: reenvía las solicitudes al servicio del modelo en sentido ascendente y puede ofrecer facturación, cuotas y registros. Algunos relays solo comparten o revenden claves; su estabilidad y su cumplimiento dependen del operador.
  • Proxy de red: un proxy HTTP, SOCKS o inverso que solo resuelve el acceso a la red y no cambia la semántica de la API; la clave sigue siendo tuya.
  • Proxy autogestionado: tú despliegas un proxy inverso o un gateway de código abierto en un servidor conforme a la normativa, y controlas claves, registros y enrutamiento; la cuenta ascendente, el ancho de banda y la operación corren por tu cuenta.
  • Gateway de IA unificado: una entrada compatible con OpenAI que agrupa varios modelos y ofrece una clave, una factura y una consola comunes. Tanto un gateway comercial como uno de código abierto autodesplegado pueden entrar en esta categoría.

Los cuatro términos se usan a menudo como sinónimos. Antes de firmar, pregunta qué capa de servicio ofrece realmente la otra parte, de quién es la clave y por qué nodos pasan las solicitudes.

2. Las opciones habituales en una tabla

Dimensión Conexión directa oficial Proxy autogestionado Relay comercial Gateway de IA unificado
Transparencia de facturación Factura oficial con criterio claro Factura ascendente más costo propio Depende del operador; hay que conciliar Factura y reglas de cobro del sitio
Estabilidad de red Depende de la salida local Depende del servidor y del enlace Depende del enlace del relay Depende del gateway y del upstream
Límites y concurrencia Límites de la cuenta oficial Control propio, sujeto al upstream Puede haber un pool compartido; confirma Según reglas y plan del gateway
Titularidad de la clave Tuya Tuya Puede ser compartida o revendida Normalmente se emite una clave propia
Visibilidad de los datos Sujeta a las condiciones oficiales Bajo tu control Visible para un tercero; confirma Sujeta a las condiciones del proveedor
Equipo adecuado Con red transfronteriza y pago conformes Con necesidades de operación y auditoría Integración rápida sin personal de operación Factura unificada para varios modelos

Ninguna opción es mejor para todos los equipos. Si solo usas Mistral y la red y el pago funcionan bien, la conexión directa es lo más simple; si necesitas una salida fija, auditoría o enrutamiento entre varios upstream, el proxy propio es más controlable; para una integración rápida puedes evaluar un relay comercial; si necesitas una factura unificada de varios modelos, considera un gateway.

3. Riesgo de las claves: el punto que más se pasa por alto

Lo que más se descuida en un relay es la titularidad de la clave. Una clave compartida, revendida o con cuota de origen desconocido puede traer cuatro problemas:

  • Si el upstream bloquea la cuenta o ajusta la cuota, el negocio se interrumpe y no puedes reclamar directamente ante el fabricante.
  • Varios inquilinos comparten una clave, de modo que los límites y las fallas se afectan entre sí y son difíciles de aislar.
  • El contenido de las solicitudes pasa por un tercero, y las políticas de registros, caché y retención no son transparentes.
  • Las condiciones del servicio pueden prohibir la reventa o el uso compartido, y en una disputa faltaría base contractual.

Al elegir proveedor, confirma al menos la razón social, las condiciones del servicio, la política de privacidad, la capacidad de emitir facturas y un contacto para incidentes. No envíes solicitudes con datos personales, secretos o contratos a un relay que no explique el destino de los datos. Pide que aclare si la clave se emite de forma independiente o sale de un pool compartido, y si se puede rotar y revocar.

4. Facturación transparente: ocho puntos que hay que aclarar

Una oferta habitual de relay es «precio oficial multiplicado por un factor» o un paquete de tokens. Un factor bajo no implica un costo total bajo; aclara al menos ocho puntos:

  • Si la entrada y la salida se cobran por separado y si el factor es el mismo.
  • Si la entrada que acierta en caché tiene descuento y cómo se calcula.
  • Si los tokens del razonamiento o del proceso de pensamiento cuentan como salida.
  • Si las solicitudes fallidas y los reintentos se cobran.
  • Si el uso de una solicitud en streaming se devuelve completo.
  • Si la recarga tiene un monto mínimo, vigencia y reglas de reembolso.
  • Si se emiten facturas, y cuál es el tipo de cambio y la moneda de liquidación.
  • Si el consumo se puede desglosar por proyecto, clave y modelo, y si la factura se puede exportar.

Pon estos criterios en la tabla comparativa y pruébalos con el mismo lote de solicitudes. Revisa en especial que el uso en streaming coincida con la factura del panel; si no coincide, detén el tráfico y investiga antes de continuar.

5. Monitoreo de latencia y errores

Para evaluar la estabilidad hay que mirar al menos seis indicadores: tasa de éxito, latencia P50/P95, latencia del primer token, tasa de timeout, proporción de 429 y velocidad de salida. No envíes solo un «hola»: usa prompts reales que cubran streaming, contexto largo y concurrencia.

import os
import statistics
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    max_retries=0,
    timeout=60,
)

latencies, errors, usage = [], 0, []
for i in range(20):
    start = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=os.environ["RELAY_MODEL"],
            messages=[{"role": "user", "content": "Describe en 200 palabras las etapas principales del cumplimiento de pedidos."}],
            max_tokens=512,
        )
        latencies.append((time.perf_counter() - start) * 1000)
        usage.append(resp.usage.total_tokens if resp.usage else 0)
        print(i, resp.model, resp.usage)
    except Exception as exc:
        errors += 1
        print(i, type(exc).__name__, exc)

if latencies:
    latencies.sort()
    p95 = latencies[max(0, int(len(latencies) * 0.95) - 1)]
    print("éxitos", len(latencies), "fallos", errors)
    print("P50", statistics.median(latencies), "ms", "P95", p95, "ms")
    print("Tokens promedio", sum(usage) / len(usage))

Esto es una sonda mínima, no una prueba de carga. Antes de producción, observa durante siete días seguidos, ejecuta una ronda en hora punta y otra en hora valle, y compara con la conexión directa oficial. En un relay comercial, revisa sobre todo el pico de la tarde y las solicitudes largas; en un proxy propio, la salida del servidor y los límites del upstream.

6. Lista de migración: de la conexión directa al relay

  1. Registra el estado actual: tasa de éxito, P50/P95, tiempo al primer token, consumo de tokens por cada mil solicitudes y factura.
  2. Inventaria nombres de modelo y parámetros: streaming, max_tokens, llamadas a herramientas, salida JSON y campos específicos de Mistral.
  3. Crea claves separadas de prueba y de producción, cada una con presupuesto y alertas.
  4. Cambia solo base_url y api_key y haz funcionar la solicitud mínima en el entorno de preproducción.
  5. Reproduce prompts reales y compara calidad de salida, tiempo y criterio de uso.
  6. Revisa el mapeo de 401, 402, 429, 5xx y timeouts, y confirma que los reintentos no amplifican la falla.
  7. Despliega entre el 5 % y el 10 % del tráfico, observa de 3 a 7 días y conserva la conexión directa como respaldo.
  8. Tras el cambio total, concilia durante una semana más y confirma que la factura coincide con las estadísticas de uso.

No cambies de modelo, de prompt y de enlace al mismo tiempo: modifica una sola variable por vez o no podrás atribuir la causa.

7. Cómo verificar un relay

Primero mira el campo model de la respuesta, pero no confíes solo en él, porque se puede reescribir. Lo más fiable es combinar varias señales:

  • Latencia: repite el mismo prompt y compara P50/P95; observa si es persistentemente más lento que la conexión directa.
  • Tasa de errores: mide la proporción de 429, 5xx y timeouts y si se concentran en horas punta.
  • Uso: contrasta el usage de la respuesta con la factura del panel y comprueba si el streaming lo devuelve completo.
  • Identidad del modelo: usa un conjunto fijo de pruebas para comparar límites de capacidad, longitud de contexto y estilo de salida.
  • Aislamiento de claves: confirma si la clave es independiente y si se puede rotar y revocar.
  • Contrato y soporte: revisa la razón social, las condiciones, las facturas y la respuesta a tickets.

Las señales de alerta incluyen un precio muy por debajo del oficial durante mucho tiempo, la promesa de cero fallas, la negativa a entregar el detalle de uso, la exigencia de que entregues tu clave oficial y la incapacidad de explicar dónde se conservan los datos. Ante cualquiera de ellas, valida con poco tráfico antes de migrar producción.

8. Contrato, facturas y mecanismo de salida

En un servicio de relay, las condiciones comerciales forman parte de la solución técnica. El contrato debe especificar al menos el alcance del servicio, el criterio de facturación, el SLA o el plazo de respuesta ante fallas, la retención y eliminación de datos, la titularidad de las claves y las reglas de incumplimiento y reembolso. Una operación con solo un contacto personal y sin condiciones escritas es difícil de reclamar si algo sale mal.

También hay que confirmar por anticipado la facturación y la liquidación: moneda, tipo de cambio, periodicidad, tipo de receptor y vía de reembolso. Para la conciliación mensual, exige que la factura se pueda exportar por proyecto o por clave.

Por último, el mecanismo de salida: si los datos se pueden exportar, si el saldo se devuelve, si la clave se puede revocar de inmediato y cuánto tarda volver a la conexión directa. Incluir el plan de salida en el lanzamiento cuesta menos que resolverlo después.

Preguntas frecuentes

¿Cuál es la diferencia entre un relay y un proxy de la API de Mistral?

Un proxy suele referirse al reenvío en la capa de red y solo resuelve el acceso; un relay normalmente también incluye cuentas, facturación o distribución de claves. El mercado mezcla ambos términos, así que antes de firmar pregunta qué capa de servicio ofrece la otra parte y de quién es la clave.

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

Puede venir de compras por volumen, subsidios de enlace o reventa de cuota, y también puede implicar claves compartidas, límites o inestabilidad. No mires solo el precio: revisa el criterio de facturación, el uso y las cláusulas, y luego prueba con poco tráfico.

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

No basta con el campo model de la respuesta. Usa un conjunto fijo de pruebas para comparar límites de capacidad, longitud de contexto, estilo de salida y estructura de usage, y conserva la conexión directa como referencia. Si la capacidad baja de forma clara, detén el tráfico y revisa.

¿Cuánto código hay que cambiar para migrar a un relay?

La mayoría de los proyectos con el SDK de OpenAI solo cambian base_url y api_key, y ajustan el nombre del modelo según la página de precios del proveedor. Si usas parámetros específicos de Mistral, llamadas a herramientas o campos de respuesta propios, añade pruebas de compatibilidad.

¿Qué debe mirar sobre todo una empresa?

La titularidad de las claves, las condiciones de tratamiento de datos, las facturas y la razón social del contrato, la respuesta ante fallas y el mecanismo de salida. El precio importa, pero la continuidad del negocio y la responsabilidad legal importan más.

Siguiente paso

Si necesitas una entrada unificada para varios modelos, crea una clave de prueba en el ZSQH AI Gateway, valida el flujo y luego migra; consulta los modelos y la facturación en los precios de modelos. No tomes «barato» como único criterio: también debes calcular el costo de la migración y de las fallas.

Lecturas relacionadas: