Para un equipo en China que quiere integrar OpenAI API solo hay tres caminos: conexión directa oficial, proxy propio y pasarela de IA local. No se trata de una simple dicotomía entre bueno y malo, sino de dónde se coloca el costo: la conexión directa en la red y el pago, el proxy en la operación, y la pasarela en la dependencia del proveedor y la revisión de términos.

Este artículo compara estabilidad de red, pagos y facturas, cumplimiento, mantenimiento, cobertura de modelos y gestión de fallas, y ofrece una configuración aplicable de tiempos de espera, reintentos y degradación, además de una lista de verificación antes de salir a producción. Es una comparación técnica y no constituye asesoría legal; la disponibilidad concreta y los requisitos de cumplimiento se rigen por la legislación local, la regulación y los términos del proveedor.

Nota: OpenAI, ChatGPT y GPT son marcas de OpenAI. Este artículo toma como ejemplo la situación habitual en octubre de 2026; los precios y la lista de modelos se rigen por la página de precios y la documentación del proveedor, y pueden cambiar.

1. En qué consiste cada una de las tres vías

Conexión directa oficial: usa una cuenta oficial de OpenAI y las interfaces oficiales; red, pago y facturación se resuelven dentro del ecosistema oficial. Requiere que el equipo cumpla las condiciones de registro y pago que admite OpenAI y que la legislación local y los términos de la plataforma lo permitan.

Proxy propio: el equipo alquila un servidor en el extranjero y despliega un proxy inverso o un programa de reenvío; las peticiones pasan primero por su servidor y luego al upstream. El proxy resuelve el enlace y la salida unificada, pero la cuenta, la Key y el pago deben resolverse aparte.

Pasarela de IA local: un proveedor ofrece una dirección de API compatible con OpenAI; el equipo recarga en yuanes y gestiona las Keys dentro del sitio. La pasarela se encarga del acceso upstream, el reenvío y parte de la gestión de fallas, y el equipo normalmente solo cambia la Base URL. ZSQH AI Gateway pertenece a esta categoría; la entrada de registro es la página de registro.

2. Las diferencias en una tabla

Dimensión Conexión directa oficial Proxy propio Pasarela de IA local
Estabilidad de red Depende del enlace internacional; ante fluctuaciones hay que diagnosticar por cuenta propia Depende de la ruta del servidor y la calidad del proxy La mantiene el proveedor; suele ser accesible desde China
Barrera de activación Requiere cuenta oficial y un método de pago disponible Requiere servidor, dominio, certificado y operación Basta registrarse; la barrera es la más baja
Pago y facturas Según las monedas y medios que admite lo oficial Costo del servidor y costo upstream se pagan por separado Recarga en yuanes; facturas según las reglas del proveedor
Cumplimiento y términos Sujeto directamente a los términos oficiales Debe cumplir la ley local y los términos upstream Hay que verificar la habilitación del proveedor y los requisitos de datos
Costo de operación Bajo, pero los problemas de red corren por cuenta propia Alto: certificados, monitoreo y actualizaciones requieren personal Bajo; el diagnóstico depende del proveedor
Cobertura de modelos Modelos propios de OpenAI Depende de la cuenta upstream; suele ser única Suele agregar modelos de varios proveedores; rige la página de precios
Gestión de fallas Canales de soporte oficiales Uno mismo localiza y recupera El proveedor gestiona el upstream; el usuario conserva el ID de petición
Equipos adecuados Con pago y red resueltos, y solo OpenAI Con capacidad de operación y necesidad de salida unificada Equipos pequeños y medianos en China, varios modelos y factura en yuanes

Esta tabla solo sirve para un primer filtro. Lo que realmente determina la experiencia es la latencia, la tasa de fallas y la respuesta ante incidentes en horas pico; conviene probar con peticiones reales del negocio durante una o dos semanas antes de decidir.

3. Estabilidad de red: mira la fluctuación, no solo si conecta

"Se abre" no equivale a "se puede llamar de forma estable". Hay que observar el tiempo hasta el primer byte, el tiempo total, la tasa de timeout y la tasa de interrupción del streaming. Los enlaces internacionales suelen mostrar más latencia y pérdida de paquetes en horas pico nocturnas, lo que se manifiesta como timeouts ocasionales, reinicios de conexión o cortes de streaming, no como fallas en cada llamada.

Un proxy propio no resuelve automáticamente los problemas de ruta: la región del servidor, la ruta de retorno y si el tráfico está limitado afectan la estabilidad. El valor de una pasarela local está en que la entrada se encuentra en China y el enlace lo mantiene el proveedor, pero la latencia sigue dependiendo de la medición real.

No te limites a hacer ping. Ejecuta peticiones reales de forma continua y registra la tasa de éxito, la latencia P95 y el número de timeouts. El siguiente comando muestra el tiempo de cada etapa:

curl -o /dev/null -sS \
  -w "dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n" \
  "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Si el DNS es lento, revisa la resolución; si el TCP es lento, la ruta; si el TLS es lento, el handshake y el certificado; si el primer byte es lento, probablemente hay cola en el upstream. Ejecuta una serie por la mañana, al mediodía y por la noche; el resultado es más útil que una sola medición.

4. Pagos, facturas y presupuesto

La conexión directa requiere un método de pago admitido por OpenAI, y la moneda, el ciclo y las reglas de factura quedan dentro del sistema oficial. Un proxy propio no evita el pago: hay que pagar el servidor y también la cuenta upstream, solo que en dos partidas. Una pasarela local suele admitir recarga en yuanes y facturación dentro del sitio, con facturas según las reglas del proveedor, lo que facilita el reembolso local.

En cualquier caso, conviene configurar un límite de presupuesto y alertas de uso. Los precios cambian y este artículo no incluye precios unitarios; rige la página de precios. El área financiera debe confirmar tres cosas: si la recarga genera un comprobante válido, si el saldo es reembolsable y si el servicio se degrada o se interrumpe cuando hay saldo pendiente.

5. Cumplimiento y términos: primero define los límites

Esta sección solo explica cómo evaluar, no ofrece métodos para eludir. El equipo debe revisar al menos cuatro puntos:

  1. Si el uso cumple la legislación y la regulación locales.
  2. Si se respetan los términos de OpenAI y de los proveedores upstream.
  3. Si la salida de datos fue evaluada y si incluye datos personales o sensibles.
  4. Si el proveedor exige identificación real y dispone de un acuerdo de tratamiento de datos y un canal de reclamaciones.

El cumplimiento no es una fila más en la tabla de selección, sino una condición de entrada. Si falla cualquiera de los puntos, no conviene salir a producción aunque el precio sea bajo. Ante la duda, consulta a un área legal o a un profesional; no sustituyas el juicio con medidas técnicas.

6. Costo de mantenimiento: un proxy no termina al instalarse

Poner un proxy propio en producción es solo el comienzo. Después hay que atender la renovación de certificados, las actualizaciones del programa, los registros y el disco, el control de acceso, los cambios de IP, la limitación de velocidad y las alertas de monitoreo. Además, si la Key se guarda en el proxy, hay que evitar filtraciones y escaneos. En equipos sin turnos de guardia, las fallas suelen ocurrir de madrugada.

La pasarela traslada esa capa al proveedor, pero el equipo debe conservar tres capacidades: consultar el uso, guardar el ID de petición y cambiar a una línea de respaldo ante una falla. Depender por completo de una sola entrada equivale a delegar la disponibilidad; construir todo por cuenta propia equivale a asumirla con el propio personal. La elección depende de qué tipo de riesgo prefiera asumir el equipo.

7. Cobertura de modelos y gestión de fallas

Para un equipo que solo usa OpenAI, la cobertura de modelos no es un problema. Para quien usa varios modelos a la vez, la pasarela ofrece una ventaja clara: una Base URL, un conjunto de Keys y una sola factura. Sin embargo, "compatible" suele referirse al formato de petición: el soporte de parámetros, llamadas a herramientas y formato de streaming no es idéntico entre modelos, y hay que validarlo punto por punto antes de cambiar.

En la gestión de fallas, la conexión directa y el proxy los diagnostica el propio equipo, mientras que en la pasarela el proveedor localiza el upstream. En cualquier caso, el usuario debe conservar el código de estado, el cuerpo de la respuesta y el ID de petición. Ante un 5xx, no reintentes sin límite: define un número máximo y un timeout total. Si el streaming se interrumpe, primero determina si ya se generó salida parcial y si se facturó.

8. Configuración de timeout, reintentos y degradación

El siguiente es un ejemplo de configuración en Python: si la línea principal falla, reintenta bajo ciertas condiciones y luego cambia a la dirección de respaldo. El nombre del modelo se lee de una variable de entorno para no fijarlo en el código.

import os
import random
import time
from openai import OpenAI

PRIMARY = OpenAI(
    api_key=os.environ["PRIMARY_API_KEY"],
    base_url=os.environ["PRIMARY_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
FALLBACK = OpenAI(
    api_key=os.environ["FALLBACK_API_KEY"],
    base_url=os.environ["FALLBACK_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
RETRYABLE = {408, 409, 429, 500, 502, 503, 504}

def call(prompt: str) -> str:
    clients = [PRIMARY, FALLBACK]
    last_error = None
    for client in clients:
        for attempt in range(3):
            try:
                resp = client.responses.create(
                    model=os.environ["OPENAI_MODEL"],
                    input=prompt,
                )
                return resp.output_text
            except Exception as exc:
                last_error = exc
                status = getattr(exc, "status_code", None)
                if status not in RETRYABLE:
                    break
                wait = min(2 ** attempt, 8) + random.random()
                time.sleep(wait)
    raise RuntimeError("Fallaron tanto la línea principal como la de respaldo") from last_error

Puntos clave: el timeout debe ser menor que la espera que permite el negocio; solo se retrocede ante errores reintentables; la línea de respaldo se configura con anticipación y se practica periódicamente; el número de reintentos no debe ser alto, porque en una falla acumula peticiones y genera un efecto avalancha.

9. Lista de verificación antes de producción

Confirma en orden y marca todos los puntos antes de aumentar el tráfico:

  1. La línea fue probada y se registraron la tasa de éxito y la latencia P95 de mañana, mediodía y noche.
  2. El método de pago funciona y las alertas de presupuesto y saldo están configuradas.
  3. Las Keys están separadas por entorno y guardadas en la gestión de secretos del servidor.
  4. La Base URL tiene un solo /v1 y el nombre del modelo se copió de la página de precios.
  5. Timeout, reintentos y degradación están configurados y se practicaron con una falla simulada.
  6. El registro incluye ID de petición, modelo, latencia y código de estado, sin la Key completa.
  7. Se revisaron los requisitos de cumplimiento y tratamiento de datos y, si corresponde, la aprobación interna.
  8. La línea de respaldo funciona y el procedimiento de cambio está documentado y asignado.

10. Preguntas frecuentes

¿La conexión directa siempre es inestable para un equipo en China?

No necesariamente. La calidad del enlace varía mucho según la región, el operador y la franja horaria, y debe medirse con peticiones reales del negocio. La estabilidad es una cuestión de probabilidad.

¿Un proxy propio requiere mantener una cuenta upstream?

Sí. El proxy solo resuelve el reenvío y la salida unificada; la cuenta upstream, la Key, el pago y el cumplimiento de términos se gestionan aparte y no generan cuota disponible por sí solos.

¿Qué requiere menos trabajo, una pasarela o un proxy?

Por lo general, una pasarela requiere menos trabajo: el servidor, los certificados, las actualizaciones y parte de las fallas upstream quedan a cargo del proveedor. El precio es depender del proveedor, así que hay que conservar una línea de respaldo y la capacidad de exportar el uso.

¿Cambiar a una pasarela implica modificar mucho código?

La mayoría de las pasarelas compatibles solo requieren cambiar la Base URL y la Key, y sustituir el nombre del modelo según la página de precios. Los parámetros no estándar o las interfaces privadas deben probarse una por una.

¿Qué revisar primero cuando hay una falla?

Primero el código de estado y el cuerpo de la respuesta, luego el ID de petición y, por último, distinguir si el problema está en la red local, en el servicio de entrada o en el upstream. Sin el ID de petición, la comunicación y el diagnóstico se vuelven más lentos.

Siguiente paso

Ninguna de las tres vías es superior en todos los casos: primero aclara pagos, cumplimiento y gestión de fallas, y luego valida con tráfico real. Si necesitas recarga en yuanes y una entrada unificada para varios modelos, puedes empezar por registrarte en ZSQH AI Gateway; los precios y modelos se rigen por la página de precios.

Lecturas relacionadas: