Cuando los equipos de China continental hablan de la API de DeepSeek, el problema suele resumirse en una sola pregunta: «¿se puede conectar?». Lo que realmente afecta a producción son cuatro cosas: si la red es estable, si los pagos y las facturas funcionan, si los límites de velocidad en horas punta son aceptables y si existe un canal alternativo cuando algo falla. Si una de estas condiciones no se cumple, el simple «se puede conectar» no sirve de nada.

Este artículo compara tres rutas habituales —conexión directa al servicio oficial, proxy propio y gateway de IA local— y propone métodos para configurar tiempos de espera, reintentos, degradación y validación. Los modelos, precios y formas de acceso concretos se rigen por los precios de modelos y por las indicaciones de este sitio.

Nota: DeepSeek es una marca de su titular. Este artículo toma como ejemplo la situación habitual en octubre de 2026; el entorno de red y las condiciones del servicio pueden cambiar, así que consulta la documentación oficial y la normativa local.

1. Las tres rutas en una sola tabla

Dimensión Conexión directa Proxy propio Gateway de IA local
Punto de entrada Dirección oficial de DeepSeek Servidor propio que reenvía Entrada unificada compatible con OpenAI
Pago Canales admitidos por el servicio oficial Primero se paga el servidor y el ancho de banda Recarga en el sitio, reglas según la página
Alcance de modelos Solo DeepSeek Depende de la configuración del proxy Varios proveedores, según disponibilidad
Responsabilidad de estabilidad Servicio oficial y red local Toda recae en el equipo Compartida entre proveedor y equipo local
Costo de operación Bajo Alto Medio
Equipos adecuados Un solo modelo, poco volumen, red estable Con capacidad de operar redes Varios modelos, factura y facturación unificada

Ninguna ruta sirve para todos. El orden para decidir es: primero, si el negocio tolera interrupciones; después, si necesitas varios modelos y factura; por último, si el equipo tiene personal para operar la infraestructura.

2. Conexión directa: cuándo es suficiente

La conexión directa encaja en estos casos: solo llamas a DeepSeek, el volumen es estable, la red local funciona bien, puedes completar la recarga oficial y el negocio acepta que el servicio vaya más lento en horas punta. Los pasos de integración no son complicados:

  1. Crea una API Key en la plataforma abierta de DeepSeek y ponle el nombre del proyecto.
  2. Guarda la clave en una variable de entorno del servidor; no la escribas en el frontend ni en el repositorio.
  3. Ejecuta una solicitud mínima con curl y confirma la Base URL y el nombre de modelo.
  4. Configura en el SDK el tiempo de espera de conexión, el de lectura y el máximo de reintentos.
  5. Registra en cada solicitud el modelo, los tokens, la latencia y el tipo de error.
export DEEPSEEK_API_KEY="sk-tu-clave"

curl "https://api.deepseek.com/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Responde solo OK"}],
    "max_tokens": 16
  }'

Si este comando falla por timeout de forma ocasional pero funciona al cambiar de red, el problema suele estar en la salida local o en el DNS, no en la clave. Guarda primero la hora de la solicitud y el mensaje de error, y después decide si necesitas cambiar de ruta.

3. Proxy propio: resuelve la salida, no la capacidad

La forma habitual de un proxy propio es montar un proxy inverso en un servidor que sí puede acceder a la interfaz oficial y reenviar allí las solicitudes. Esto resuelve una parte del problema de «red local inestable», pero crea trabajo nuevo:

  • El servidor del proxy es un punto único de fallo: si se cae, fallan todas las solicitudes a la vez.
  • Hay que gestionar TLS, autenticación y control de acceso para que el proxy no se use de forma abusiva.
  • Hacen falta registros, limitación de velocidad y monitoreo; sin ellos, cualquier problema es difícil de localizar.
  • Una capa más de reenvío añade latencia y puede aumentar el tiempo hasta el primer token en las respuestas en streaming.
  • La responsabilidad de red y cumplimiento sigue recayendo en el equipo.

Si el equipo no tiene personal para mantener el proxy de forma continua, lo que empezó como «solución temporal» termina convertido en «deuda permanente». Puede servir como transición, pero no conviene usarlo como único punto de entrada.

4. Gateway de IA: concentra varios modelos y la inestabilidad en una sola entrada

El valor de un gateway de IA local no está solo en «hacer de intermediario», sino en reunir en un mismo lugar la gestión de claves, la recarga, la facturación, el cambio de modelo y el tratamiento de fallos. Para los equipos que usan varios modelos, el cambio más directo es este: el código de negocio solo conoce una entrada compatible con OpenAI y, al cambiar de modelo, se modifica la configuración en lugar del código.

export ZSQH_API_KEY="sk-tu-clave"

curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Explica en una frase qué hace un gateway"}],
    "max_tokens": 128
  }'

Al elegir un gateway, confirma cinco puntos: si admite los modelos que necesitas, si tiene reglas claras de facturación y recarga, si ofrece detalle de consumo, cómo avisa de los fallos y si sus condiciones de datos cumplen tus requisitos de cumplimiento. No te limites a comprobar «si la llamada funciona».

5. La estabilidad se construye en el cliente: timeouts, reintentos y degradación

Sea cual sea la ruta, el cliente debe tener protecciones. Se recomienda configurarlas en este orden:

  1. Separa el timeout de conexión y el de lectura: el de conexión puede ser corto y el de lectura más largo; configura por separado los textos largos y las tareas de razonamiento.
  2. Reintenta con retroceso: reintenta solo ante 429, 5xx y timeouts, con retroceso exponencial y jitter aleatorio, y define un número máximo.
  3. Controla la concurrencia: usa colas para suavizar los picos de las tareas por lotes; no lances todo a la vez en punto.
  4. Prepara un modelo de respaldo: el negocio principal puede cambiar a un modelo o canal alternativo, asumiendo que la salida será algo distinta.
  5. Añade un cortacircuitos: cuando los fallos consecutivos alcancen el umbral, pausa las solicitudes para evitar una tormenta de reintentos.
  6. Garantiza la idempotencia: en operaciones con efectos secundarios, consulta el estado antes de reenviar; no reintentes a ciegas.
import httpx
from openai import OpenAI

client = OpenAI(
    api_key="sk-tu-clave",
    base_url="https://ai.zhongshangqihang.com/v1",
    timeout=httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=10.0),
    max_retries=2,
)

No hay cifras universales para los timeouts: ajústalas según la tolerancia del negocio y la longitud de la tarea. Lo importante es no dejar que una solicitud espere indefinidamente y no reenviar en paralelo de inmediato después de un fallo.

6. Valida una ruta durante una semana

Indicador Cómo registrarlo Qué observar
Tasa de éxito Porcentaje de respuestas que no son 200 Si se concentran en horas punta
Latencia p50, p95 y tiempo hasta el primer token Si la latencia de cola afecta la experiencia
Límites de velocidad Número de 429 y momento en que se activan Si es un problema de cuota o un pico de tráfico
Errores de red DNS, TLS y timeouts de conexión Si es un problema de salida local
Calidad Revisión manual de un conjunto fijo de tareas Si la salida es coherente al cambiar de ruta

La validación debe cubrir al menos una hora punta de un día laborable y un periodo de baja carga nocturno. Ejecutar el mismo lote de solicitudes a la misma hora todos los días durante siete días aporta más información que una única prueba de carga.

7. Pagos, facturas y cumplimiento

  • Los equipos que necesitan pago corporativo y factura deben confirmar de antemano las reglas de facturación del proveedor y los plazos de emisión.
  • Si se manejan datos de clientes, lee primero las condiciones de datos y confirma si las entradas se conservan o se usan para mejorar el servicio.
  • Separa las claves por entorno; la clave de producción no debe estar en el frontend ni en repositorios públicos.
  • Conserva registros de llamadas y facturas para conciliación financiera y auditoría de seguridad.
  • Las exigencias de transferencia transfronteriza y de regulación sectorial se confirman según la normativa local y los procesos de cumplimiento de la empresa.

Preguntas frecuentes

¿Es estable la conexión directa a DeepSeek desde China?

Depende de la red local, la franja horaria y la carga del servicio oficial; no hay una respuesta única. En producción no conviene depender de una sola ruta: prepara al menos timeouts, reintentos y un canal alternativo.

¿Un gateway añade latencia?

Una capa más de reenvío puede añadir algo de latencia, pero el gateway suele ofrecer una entrada más estable y conmutación ante fallos. Prueba el mismo lote de solicitudes contra la conexión directa y contra el gateway, y compara p95 y tasa de éxito, no una sola llamada.

¿El proxy propio sirve para cualquier equipo?

No. Requiere operación de red, configuración de seguridad y monitoreo continuos. Sin una persona dedicada, el propio proxy se convierte en un nuevo punto de fallo.

¿Una sola clave puede llamar a varios modelos?

En un gateway normalmente sí: el modelo se indica en la solicitud y el alcance concreto depende de la página de precios y de la consola. La clave de la conexión directa oficial solo puede llamar a los modelos que el servicio oficial expone.

¿Cómo sé si el problema está en local o en el proveedor?

Primero prueba con una solicitud mínima; después cambia de red, de clave y de punto de entrada por separado. Guardar la hora de la solicitud y el mensaje de error permite distinguir rápidamente entre DNS, TLS, autenticación, límites de velocidad y fallos del proveedor.

Próximos pasos

Crea una clave de prueba en ZSQH AI Gateway y compara la tasa de éxito y la latencia de la conexión directa y del gateway con el mismo lote de solicitudes; después decide la ruta de producción. Los modelos y precios se rigen por los precios de modelos.

Lecturas relacionadas: