Un relay de Kimi API añade, en esencia, una capa de gateway entre el negocio y el modelo. Puede resolver el acceso desde China, unificar claves, permitir el cambio entre varios modelos y ofrecer una factura en RMB; también puede introducir nuevos puntos de falla, una facturación opaca y riesgos de datos. La cuestión no es si «el relay es bueno o malo», sino quién mantiene esa capa, si las reglas son transparentes y si un incidente puede investigarse.

Este artículo compara tres rutas: conexión directa, proxy propio y relay gestionado, con énfasis en estabilidad, facturación y aceptación de la migración. Los modelos y precios se rigen por la página de precios de modelos.

Nota: Moonshot y Kimi son marcas de sus respectivos titulares; este artículo solo discute opciones técnicas. Las credenciales, los términos y las reglas de facturación de los servicios de relay los establece cada proveedor; verifícalos por tu cuenta antes de firmar.

1. Las tres rutas, bien delimitadas

Criterio Conexión directa oficial Proxy propio Relay o gateway gestionado
Entrada api.moonshot.cn o api.moonshot.ai Proxy inverso en dominio propio Entrada unificada del proveedor
Titularidad de la clave Clave oficial propia Clave oficial propia Cuenta del proveedor o subclave
Facturación Oficial por tokens Factura oficial más costo de servidores Proveedor por tokens, paquete o multiplicador
Diagnóstico Estado oficial y request_id Toda la cadena es responsabilidad propia Depende de los registros y respuestas del proveedor
Equipos adecuados Un solo modelo, acceso fluido Con capacidad de operación y necesidad de salida unificada Varios modelos, pago local y poca operación

Las tres rutas no son excluyentes. Una práctica común es conectar el negocio crítico de forma directa, enviar pruebas y servicios secundarios por el gateway, y dejar el proxy propio solo para la salida unificada y la auditoría.

2. Conexión directa: la más simple, con límites

La conexión directa oficial ofrece una ruta corta y responsabilidades claras. El sitio chino usa https://api.moonshot.cn/v1; el internacional, https://api.moonshot.ai/v1, y la clave debe corresponder al sitio. Cuando una solicitud falla, error.type y request_id en la respuesta oficial son la pista más directa para el diagnóstico.

Los límites de la conexión directa son cuatro:

  • La calidad de red del sitio internacional desde China es inestable, y las conexiones largas y el streaming se cortan con más facilidad.
  • La plataforma clasifica los límites por recarga acumulada, y las cuentas nuevas suelen tener concurrencia ajustada.
  • Las facturas, los contratos y el proceso de compra siguen las reglas oficiales.
  • Solo cubre Kimi; un negocio con varios modelos debe mantener varias claves y varias facturas.

Si nada de esto representa un problema, la conexión directa es la opción por defecto. No añadas una capa solo para que la arquitectura «se vea mejor».

3. Proxy propio: no es solo un proxy inverso

Muchos creen que un proxy propio es simplemente un reenvío con Nginx. Al llevarlo a producción, hay que resolver al menos esto:

  • Custodia de claves: la clave no puede estar en el frontend ni en el repositorio; la capa de proxy debe inyectar y rotar secretos.
  • Reenvío en streaming: desactiva el buffering para que SSE llegue bloque a bloque; de lo contrario, el streaming se degrada a una respuesta única.
  • Configuración de timeouts: el timeout de conexión y el de lectura se configuran por separado; una generación larga no admite un timeout de lectura corto.
  • Estrategia de reintentos: reintenta solo errores transitorios; no reintentes por saldo insuficiente ni por seguridad de contenido.
  • Contabilidad de consumo: registra modelo, tokens de entrada y salida, request_id y duración; sin eso no hay conciliación posible.
  • Salida y límites: cuando varios servicios comparten salida, evita que uno consuma toda la concurrencia.
  • Alta disponibilidad: el proxy también falla; necesita varias instancias y verificaciones de estado.

Un proxy propio no aumenta la cuota del proveedor. Los límites oficiales siguen existiendo y el proxy solo puede encolar, reducir el ritmo y cambiar de ruta; no crea concurrencia de la nada. También hay que contar el costo humano: mantener una pieza propia y contratar un servicio gestionado pueden tener costos de largo plazo muy distintos.

4. Qué transparencia exigir a un relay gestionado

Al elegir un relay gestionado, no te quedes con las palabras «estable» y «barato». Antes de firmar, aclara estas preguntas:

  1. Quién es el operador y quién emite el contrato y la factura.
  2. Si la fuente es conexión directa oficial, un proveedor cloud u otro revendedor, y cómo se asignan los nombres de modelo.
  3. Cuál es la unidad de facturación: entrada y salida por separado o multiplicador, y si hay consumo mínimo.
  4. Si se pueden exportar los registros de solicitudes, cuánto tiempo se conservan y qué campos incluyen.
  5. Si los datos se almacenan, se usan para entrenamiento o se reenvían a terceros.
  6. Cuáles son las reglas de límite, el máximo de concurrencia y la política de ráfagas.
  7. Si hay página de estado, SLA y cláusulas de compensación por fallas.
  8. Cómo se custodian las claves y si admite subclaves, listas blancas de IP y revocación inmediata.
  9. Cómo se eliminan los datos al salir y qué ocurre con el saldo no consumido.

No hay respuestas estándar, pero deben existir por escrito. Un servicio que solo promete verbalmente «mucha estabilidad» no es adecuado para sostener el negocio crítico.

5. Facturación: fija el criterio en el contrato

La facturación de un relay suele adoptar tres formas: recargo por token, paquete de volumen o precio oficial multiplicado. Ninguna forma es mejor por sí misma; lo importante es que el criterio sea claro y verificable.

Al conciliar, revisa al menos cuatro cifras:

Métrica Uso Fuente habitual de diferencias
Tokens de entrada Verificar aciertos y fallos de caché Si la entrada cacheada se cobra a precio completo
Tokens de salida Verificar el costo de salidas largas Si incluye el contenido de razonamiento
Número de solicitudes Verificar consumo mínimo o cobro por llamada Si los reintentos se cobran dos veces
Solicitudes fallidas Determinar si se facturan Cómo se tratan 429, timeouts y desconexiones

Antes de firmar, confirma: si los aciertos de caché tienen descuento, si el razonamiento cuenta como salida, si las solicitudes fallidas se facturan y cuáles son las reglas de reembolso y compensación. Si el precio es inferior al oficial, pregunta si se trata de una subvención, una compra por volumen o una cuota compartida; no mires solo la cifra.

6. Estabilidad: límites, timeouts y conmutación por falla

Kimi devuelve 429 cuando se activa un límite, junto con X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset. Los 429 deben tratarse en tres categorías:

  • engine_overloaded_error: sobrecarga del servidor; espera y reintenta con retroceso.
  • rate_limit_reached_error: límite de concurrencia, RPM, TPM o TPD excedido; reduce el ritmo o espera el reinicio.
  • exceeded_current_quota_error: falta de saldo o cuota insuficiente; no reintentes, recarga primero.

Una solicitud sin streaming que espere más de 900 segundos puede devolver 504; las tareas largas deben usar streaming. Una desconexión iniciada por el cliente puede manifestarse como 499, así que revisa el proxy y la configuración de timeouts.

La conmutación por falla solo tiene sentido ante errores transitorios:

import os
from openai import OpenAI, RateLimitError

primary = OpenAI(
    api_key=os.environ["PRIMARY_KEY"],
    base_url=os.environ["PRIMARY_BASE"],
    max_retries=0,
)
backup = OpenAI(
    api_key=os.environ["BACKUP_KEY"],
    base_url=os.environ["BACKUP_BASE"],
    max_retries=0,
)

def ask(prompt: str) -> str:
    for client in (primary, backup):
        try:
            resp = client.chat.completions.create(
                model=os.environ["MODEL"],
                messages=[{"role": "user", "content": prompt}],
                max_completion_tokens=512,
            )
            return resp.choices[0].message.content
        except RateLimitError as exc:
            if "quota" in str(exc).lower():
                raise
    raise RuntimeError("Ningún proveedor disponible")

El ejemplo solo muestra la estructura; en producción hay que evaluar error.type y añadir cortacircuitos, sondeo semiable y alertas. La falta de saldo, los errores de parámetros y los errores de seguridad de contenido no deben activar la conmutación: cambiar de ruta tampoco los resuelve.

7. Lista de migración y aceptación

  1. Fija un conjunto de solicitudes de prueba que cubra preguntas cortas, textos largos, streaming y llamadas a herramientas.
  2. Envía la misma solicitud por conexión directa y por relay, y compara model, usage y request_id en las respuestas.
  3. Verifica que el streaming llegue bloque a bloque, que termine con [DONE] y que el bloque de consumo esté completo.
  4. Provoca deliberadamente 401, 404 y 429, y compara si los tipos de error y los mensajes son legibles.
  5. Observa durante una semana la latencia p50 y p95 y la tasa de error, no solo una prueba puntual.
  6. Concilia con la factura real y con usage, y confirma el criterio de cobro de caché, reintentos y solicitudes fallidas.
  7. Revisa las cláusulas de datos, los campos de registro y la custodia de claves.
  8. Despliega primero en negocios de bajo riesgo y conserva un interruptor para volver a la conexión directa.

Si la aceptación no pasa, no migres el negocio crítico. El valor de la capa de relay es reducir complejidad, no esconder riesgos invisibles.

8. Seguridad, cumplimiento y mecanismo de salida

El proveedor de relay puede ver el contenido de las solicitudes; esto lo determina la arquitectura, no es una cuestión de confianza. Antes de enviar solicitudes con datos personales, contratos, claves o código interno, confirma las cláusulas de datos y la política de retención; si es necesario, anonimiza la información o procésala del lado de la conexión directa.

El mecanismo de salida también debe diseñarse con anticipación: si la clave puede revocarse en cualquier momento, si los registros pueden exportarse, si el saldo no consumido puede devolverse y en cuánto tiempo se eliminan los datos. Un costo de migración bajo es lo que evita quedar atado a un solo proveedor.

Preguntas frecuentes

¿Un relay es más estable que la conexión directa oficial?

No necesariamente. Un relay puede unificar la entrada, aplicar reintentos y conmutar, pero también añade un punto de falla. La estabilidad depende de la capacidad operativa del proveedor, la calidad de su fuente y tu configuración de timeouts; hay que validarla con tráfico real durante al menos una semana.

¿Es normal que el precio del relay sea inferior al oficial?

Puede provenir de compras por volumen, subvenciones o cuotas compartidas, o de un criterio de facturación poco claro. Pregunta primero por la unidad de precio, las reglas de caché y si las solicitudes fallidas se cobran; luego verifica con la factura, no solo con la página promocional.

¿Un proxy propio resuelve los 429?

No aumenta la cuota del proveedor por arte de magia. El proxy puede encolar, reducir el ritmo, reintentar y conmutar, pero si la concurrencia o el TPD de la cuenta oficial llegan al máximo, habrá que esperar el reinicio o subir de nivel.

¿Cómo saber si un relay usa realmente Kimi?

Revisa el campo model, la estructura de usage y el request_id de la respuesta, y compara los resultados con la conexión directa usando un conjunto fijo de evaluación. Una sola métrica no lo demuestra; la verificación combinada es más fiable. Ante dudas sobre el origen, prioriza la conexión directa.

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

En proyectos compatibles con OpenAI, normalmente solo la Base URL, la clave y el nombre del modelo. Revisa además streaming, timeouts, equivalencia de tipos de error y estadísticas de consumo; son los puntos que más fallan después del cambio.

Siguiente paso

Ejecuta primero la lista de aceptación con una clave de prueba en ZSQH AI Gateway y después decide qué servicios van por conexión directa y cuáles por el gateway. Los modelos disponibles y los criterios de facturación se rigen por los precios de modelos.

Lecturas relacionadas: