El relay y el proxy de la API de DeepSeek suelen verse como un trámite de "cambiar la dirección y listo". Al elegir, en realidad hay que responder cuatro preguntas: cómo se calcula el costo, si la red es estable, quién responde cuando algo falla y si la clave y el tratamiento de datos cumplen las normas.
Este artículo compara las opciones habituales y ofrece una lista de migración y verificación. Los precios, nombres de modelo y disponibilidad concretos se rigen por los precios de modelos del sitio y por lo que indique el proveedor.
Nota: DeepSeek es una marca registrada de su titular; este artículo no tiene relación de afiliación con DeepSeek. El mercado de relay cambia con rapidez; aquí se usa como ejemplo la forma habitual de octubre de 2026 y no constituye un respaldo a ningún proveedor.
1. Primero, definamos: relay, proxy y gateway no son lo mismo
- Relay de API: reenvía las solicitudes al servicio de modelo upstream y puede incluir facturación, límites y registros. Algunos "relays" del mercado solo comparten o revenden claves; su estabilidad y cumplimiento dependen del operador.
- Proxy de red: HTTP, SOCKS o proxy inverso; solo resuelve la accesibilidad de red y no cambia la semántica de la API. La clave sigue siendo tuya.
- Proxy propio: despliegas un proxy inverso o un gateway de código abierto en tu servidor y controlas claves, registros y enrutamiento, pero asumes la cuenta upstream, el ancho de banda y la operación.
- Gateway de IA unificado: entrada compatible con OpenAI que agrupa varios modelos y ofrece clave, facturación y consola unificadas. Tanto los gateways comerciales como los de código abierto autoalojados pueden entrar en esta categoría.
Si se mezclan los cuatro conceptos, es fácil confundir un problema de red con uno del modelo. Antes de contratar, pregunta con claridad qué capa de servicio ofrece la otra parte y de quién es la clave.
2. Las cuatro opciones en una tabla
| Dimensión | Conexión directa oficial | Proxy propio | Relay comercial | Gateway de IA unificado |
|---|---|---|---|---|
| Transparencia de facturación | Factura oficial con criterios claros | Factura upstream más tu propio costo | Depende del operador; hay que conciliar | Factura unificada del sitio con reglas de precio visibles |
| Estabilidad de red | Depende de la salida local | Depende del servidor y la ruta | Depende de la ruta del relay | Depende de la ruta del gateway y del upstream |
| Límites y concurrencia | Límites por cuenta oficial | Los controlas tú, pero el upstream sigue limitando | Puede haber un pool compartido; hay que confirmarlo | Según las reglas y el plan del gateway |
| Cobertura de modelos | Solo DeepSeek | Depende del upstream conectado | Suele ser amplia; hay que verificarla | Varios modelos, según la página de precios |
| Riesgo de clave | La clave está en tus manos | La clave está en tus manos | Puede usar claves compartidas o revendidas | Normalmente emite una clave independiente |
| Operación y soporte | Documentación oficial | Todo corre por tu cuenta | Depende de la capacidad del proveedor | Consola, tickets y documentación |
Ninguna opción sirve para todos los equipos. Si solo usas DeepSeek y la red y el pago funcionan bien, la conexión directa oficial es lo más directo. Si necesitas una salida fija y auditoría, elige un proxy propio. Si no tienes personal de operación, evalúa un relay comercial. Si quieres varios modelos con facturación unificada, mira un gateway.
3. Precios: no mires solo el "multiplicador"
Una forma habitual de cotizar relays es "precio oficial por un multiplicador" o "paquetes de tokens". Un multiplicador bajo no implica un costo total bajo. Como mínimo, aclara estos ocho puntos:
- Si la entrada y la salida se cobran por separado y si el multiplicador es el mismo.
- Si la entrada con acierto de caché tiene descuento y cómo se calcula.
- Si los tokens de razonamiento generados por thinking se cuentan como salida.
- Si las solicitudes fallidas y los reintentos se facturan.
- Si el usage de las solicitudes en streaming se devuelve completo.
- Si la recarga tiene monto mínimo, vigencia y reglas de reembolso.
- Si se emiten facturas y cuáles son el tipo de cambio y la moneda de liquidación.
- Si las estadísticas de uso y la factura se pueden desglosar por proyecto, clave y modelo.
Anota estos criterios en una tabla comparativa y pruébalos con el mismo lote de solicitudes para calcular el costo real. Los precios y formas de facturación concretos se rigen por los precios de modelos del sitio y por la factura del proveedor.
4. Estabilidad: verifica con datos, no con publicidad
Para la estabilidad, revisa al menos seis indicadores: tasa de éxito, latencia P50/P95, latencia del primer token, tasa de tiempos de espera, proporción de 429 y velocidad de salida. Prueba con prompts de longitud real y cubre 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,
)
prompt = "Explica en 200 palabras las etapas principales del cumplimiento de pedidos en el comercio electrónico transfronterizo."
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": prompt}],
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:
print("Éxitos", len(latencies), "Fallos", errors)
print("P50", statistics.median(latencies), "ms")
print("Máximo", max(latencies), "ms")
print("Tokens promedio", sum(usage) / len(usage))
Esto es solo una sonda mínima, no una prueba de carga. Antes de producción, conviene observar durante 7 días seguidos, ejecutar una ronda en hora pico y otra en hora valle, y comparar los resultados con la conexión directa oficial. En un relay comercial, fíjate sobre todo en la hora pico nocturna y en las solicitudes largas; en un proxy propio, en la salida del servidor y en los límites del upstream.
5. Riesgo de claves y cumplimiento: más importante que el precio
Lo que más se pasa por alto en un relay es la titularidad de la clave. Una clave compartida, una clave revendida o una cuota de origen desconocido pueden traer cuatro problemas:
- Si el upstream bloquea o ajusta la cuota, el negocio se interrumpe y no hay a quién reclamar directamente.
- Varios inquilinos comparten una clave; los límites y las fallas se afectan entre sí y el problema es difícil de ubicar.
- El contenido de las solicitudes pasa por un tercero, y las políticas de registros, caché y retención de datos no son transparentes.
- Los términos de servicio pueden prohibir la reventa o el uso compartido, y ante una disputa faltan bases contractuales.
Al elegir proveedor, confirma al menos la razón social, los términos de servicio, la política de privacidad, la capacidad de emitir facturas y un contacto para incidentes. No envíes solicitudes con datos personales, claves o contratos a un relay que no puede explicar adónde van los datos. En sectores muy regulados, como finanzas o salud, evalúa primero la conexión directa oficial, el despliegue privado o un proveedor dispuesto a firmar un acuerdo de tratamiento de datos.
6. Lista de migración: de la conexión directa al relay o gateway
- Registra la situación actual: tasa de éxito, latencia P50/P95, consumo de tokens y factura por cada mil solicitudes.
- Inventaría nombres de modelo y parámetros: thinking, max_tokens, tools, salida JSON y streaming.
- Crea claves de prueba y de producción por separado, con presupuesto y alertas para cada una.
- Cambia solo
base_urlyapi_key, y haz funcionar la solicitud mínima en el entorno de preproducción. - Reproduce con prompts reales y compara calidad de salida, latencia y criterios de usage.
- Revisa el mapeo de 401, 402, 429, 5xx y tiempos de espera; confirma que los reintentos no amplifiquen la falla.
- Enruta entre 5 % y 10 % del tráfico, observa de 3 a 7 días y conserva la conexión directa oficial como reversión.
- Tras el cambio total, sigue conciliando durante una semana y confirma que la factura y las estadísticas de uso coincidan.
Durante la migración, no cambies al mismo tiempo el modelo, los prompts y el gateway, porque no podrás atribuir la causa. Modifica una sola variable a la vez.
7. Cómo verificar si un relay es confiable
Primero mira el campo model de la respuesta, pero no confíes solo en él, porque puede reescribirse. Lo más fiable es combinar varias verificaciones:
| Verificación | Cómo hacerla | Señal anómala |
|---|---|---|
| Latencia | Repetir el mismo prompt y comparar P50/P95 | Variación extrema o lentitud clara y sostenida frente a la conexión directa |
| Tasa de errores | Medir la proporción de 429, 5xx y tiempos de espera | Fallas concentradas en hora pico |
| Uso | Comparar el usage de la respuesta con la factura del panel | No cuadra o falta el usage en streaming |
| Identidad del modelo | Comparar límites de capacidad y estilo de salida con un set fijo de pruebas | Capacidad claramente degradada o contexto más corto |
| Aislamiento de clave | Confirmar si es una clave independiente y si se puede rotar | Se niegan a explicar el origen de la clave |
| Contrato y soporte | Revisar razón social, términos, facturas y respuesta a tickets | Solo un contacto personal y sin términos de servicio |
Las señales de alerta incluyen: precios muy por debajo de lo oficial durante mucho tiempo, promesas de "cero fallas", negativa a entregar el detalle de uso, exigencia de que entregues tu clave oficial y falta de explicación sobre dónde se retienen los datos. Ante estos casos, prueba primero con poco tráfico y no migres toda la producción de una vez.
8. Cuándo conviene más un proxy propio
Un proxy propio conviene a equipos con capacidad de ingeniería: necesitan una IP de salida fija, auditoría unificada, enrutamiento entre varios upstream o mantener las claves bajo su control. La práctica habitual es un proxy inverso con gestión de claves, límites de frecuencia, registros y alertas, manteniendo la cuenta oficial o un proveedor conforme como upstream.
Hay que calcular también el costo: servidor, ancho de banda, certificados, actualizaciones, corrección de vulnerabilidades y guardias. Si las llamadas son ocasionales y no hay personal de operación, el proxy propio suele salir más caro que una solución comercial. Además, el proxy propio no evita los límites ni los términos de servicio del upstream.
9. Recomendación de elección: ordena según tus restricciones
- Primero, red y pago: ¿la entrada oficial es accesible de forma estable y permite recargar sin problemas? Si sí, prioriza la conexión directa oficial.
- Luego, control: ¿necesitas salida fija, registros de auditoría y claves privadas? Si sí, evalúa un proxy propio.
- Después, alcance de modelos: ¿quieres llamar a varios modelos desde una sola entrada? Si sí, mira un gateway unificado.
- Por último, capacidad de servicio: ¿la razón social, los términos, las facturas, los tickets y la política de datos están claros?
Si necesitas una entrada unificada para varios modelos, puedes crear una clave de prueba en ZSQH AI Gateway y migrar después de validar; consulta precios y modelos disponibles en Precios de modelos. No tomes "barato" como único criterio: también cuentan los costos de migración y de fallas.
Lecturas relacionadas:
- Acceso a la API de DeepSeek desde China y opciones de red
- ¿Qué es una estación de relay de IA? Guía completa 2026
- Precios y facturación de la API de DeepSeek
Preguntas frecuentes
¿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 además incluye cuenta, facturación o distribución de claves. Los dos términos se usan de forma intercambiable, así que antes de contratar aclara el alcance del servicio.
¿Es creíble que el precio del relay sea más bajo que el oficial?
Puede venir de compras por volumen, subsidios de ruta o reventa de cuota, y también puede acompañarse de claves compartidas, límites o inestabilidad. Verifica primero los criterios de facturación, el detalle de uso y los términos del contrato, 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. Compara con un set fijo de pruebas los límites de capacidad, la longitud de contexto, el estilo de salida y la estructura de usage, y conserva la conexión directa oficial como referencia. Si detectas una degradación clara, detén el tráfico antes de investigar.
¿Cuánto código hay que cambiar para migrar a un gateway?
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 gateway. Si usas thinking, tools o campos de respuesta específicos, hay que hacer pruebas de compatibilidad adicionales.
¿Qué debe priorizar una empresa?
La titularidad de la clave, el acuerdo de tratamiento de datos, la factura y la razón social del contrato, la respuesta ante incidentes y el mecanismo de salida. El precio importa, pero la continuidad del negocio y la responsabilidad de cumplimiento importan más.
