¿Qué es un API Gateway: Principio, riesgos comunes y lista de selección

El camino que recorre una petición en un gateway

Primero, aclaremos los términos. Una «API relay» es un gateway que se interpone entre tu aplicación y el backend que ejecuta el modelo. Tu código sigue enviando peticiones en formato OpenAI, solo que apuntas base_url a la dirección del gateway y usas la clave que este te asigna.

El gateway suele hacer tres cosas en este salto.

• Reenvío de peticiones: valida el formato del cuerpo de la petición, completa los parámetros por defecto si faltan y luego la entrega al backend; el contenido que devuelve el backend (incluidos los fragmentos SSE en streaming) se te reenvía tal cual o con ligeros ajustes.
• Mapeo de claves: Tú posees una clave emitida por el gateway, válida solo dentro de él. El gateway identifica quién eres, tu saldo y qué modelos puedes llamar; las credenciales reales con el backend permanecen internas y no aparecen en tu código.
• Facturación y límites: Tras cada petición, el gateway descuenta el saldo multiplicando los tokens de entrada y salida del usage por el precio unitario, y cuenta las peticiones por minuto por clave, devolviendo 429 si se excede.

Si unes estos tres aspectos, entenderás por qué la experiencia varía tanto: la capa de reenvío determina la estabilidad del latencia y del streaming, la capa de claves define el alcance del daño en caso de fuga, y la capa de facturación determina si la factura es transparente y auditable.

Diferencias con un servicio de un solo modelo directo

Conectar directamente significa enviar peticiones al dominio oficial del proveedor del modelo; normalmente, una cuenta corresponde a un conjunto de modelos, reglas de facturación y documentación. Un servicio de relay suele tener dos formas comunes, diferenciadas por «cuántos servicios hay detrás».

Dimensión	Servicio directo de un solo modelo	Gateway agregador	Gateway de un solo modelo
Cantidad de modelos	Varios del propio proveedor	Decenas o cientos	Uno
Formato de interfaz	Formatos propios de cada uno	Unificado compatible con OpenAI	Compatible con OpenAI
Dificultad de depuración	Mínima, cadena más corta	Máximo, muchos mapeos de nombres de modelos	Baja, solo un modelo
Escenarios adecuados	Negocio estable que usa un solo proveedor	Necesidad de cambiar modelos frecuentemente para comparar	Modelo fijo, búsqueda de predictibilidad

Si tu negocio depende de un solo modelo, las ventajas del agregador no se aplican y asumes la incertidumbre de “a qué modelo corresponde el nombre”. Si cambias de modelo semanalmente para pruebas, el agregador ahorra adaptación. No hay优劣 absolutas; lo clave es saber a qué categoría perteneces.

Este sitio es el último caso: ofrece un solo modelo con ID uncensored y una interfaz compatible con OpenAI. Para ver estos compromisos y costos, lee Costos y compensaciones de la API de IA ilimitada.

Tres riesgos más comunes

Seguridad de la clave

La clave del gateway equivale a una tarjeta prepago de saldo: quien la tenga puede gastar tu saldo. Las fugas comunes incluyen: claves en código frontend, repositorios públicos, capturas de pantalla en chats o tickets. Recomendamos guardarla solo en variables de entorno del servidor; el frontend debe reenviar a través de tu backend. Si sospechas una fuga, restablece inmediatamente; la clave antigua debe caducar al instante. Verifica si el servicio permite restablecerla tú mismo y si la clave antigua caduca inmediatamente, no “después de unas horas”.

Sustitución del modelo

Este es el problema más debatido en servicios agregadores: pides A, pero recibes B más barato. Es difícil de juzgar por la documentación; solo se verifica con comportamiento. Fija un conjunto de preguntas con respuestas estándar y temperature constante para probar repetidamente y observar si el estilo de salida es estable; también puedes pedir /v1/models para ver si la lista coincide con la página de precios. Nombres de modelos ambiguos o comportamientos muy distintos del mismo nombre en distintos momentos merecen precaución.

Límites de velocidad opacos

Algunos servicios escriben “uso razonable” en la documentación, pero reducen la velocidad o descartan peticiones en horas pico, causando timeouts esporádicos en tu programa. La práctica madura es especificar las peticiones por minuto por clave y devolver un 429 estandarizado al exceder, en lugar de dejar la conexión colgada. Al elegir, pregunta claramente: si el límite se aplica por clave o cuenta, qué se devuelve al exceder y si se devuelve un código de error independiente al agotarse el saldo.

Lista de verificación para elegir un servicio de retransmisión

Puedes copiar esta lista directamente en tu documento de evaluación y marcar cada punto.

1. ¿Proporciona un GET /v1/models público cuya lista de modelos y precios coincida con la página de tarifas?
2. ¿Las respuestas de error son JSON estructurados que incluyen code y message, con códigos 401, 402, 429 y 503 claramente diferenciados?
3. ¿Está documentado el límite de peticiones por minuto para cada clave, y no solo mencionado verbalmente al soporte?
4. ¿Se especifican claramente la longitud de la ventana de contexto, el máximo de tokens de salida por petición y el tamaño máximo del cuerpo de la petición?
5. ¿La facturación deduce con precisión según el número de tokens en usage y puedes consultar el saldo en cualquier momento?
6. ¿Caduca el saldo prepagado? ¿Está claramente indicado el periodo de validez del crédito de prueba gratis?
7. ¿Puedes restablecer las claves tú mismo y se invalidan las claves antiguas de forma inmediata?
8. ¿Se admite streaming y la respuesta final incluye las estadísticas de usage para que puedas conciliar tus cuentas?
9. ¿Hay una explicación clara y concisa sobre si los prompts se utilizan para el entrenamiento?
10. ¿Se indican con honestidad las capacidades no soportadas (por ejemplo, vectores, imágenes, audio) en lugar de ser vago?

No es realista obtener la puntuación máxima, pero si no puedes responder al menos dos de las primeras cinco preguntas, te recomendamos probar con un monto pequeño antes de recargar un saldo grande.

Verificación básica de diez minutos tras obtener la clave

Independientemente de la opción que elijas, vale la pena dedicar diez minutos a una verificación básica antes de ir a producción. El primer paso es listar los modelos y confirmar que los id devueltos coinciden con tus expectativas:

复制curl -s https://api.llmzhongzhuan.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

El segundo paso es enviar una petición pequeña y observar si existe el campo usage en la respuesta y si la cantidad es razonable. El siguiente ejemplo pide al modelo que repita la fecha para ver si alucina información que no conoce. Es una verificación de comportamiento aproximada, no una evaluación estricta:

复制curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "用一句话介绍你自己，然后复述今天的日期是几号。"}],
    "max_tokens": 200
  }' 

Incluye estos dos pasos en tu script de despliegue y ejecútalos cada vez que cambies de clave o de servicio. Si la respuesta no incluye usage, o si el número de usage no coincide claramente con la longitud de la entrada, significa que hay problemas de transparencia en la facturación y debes aclararlo antes de gastar grandes cantidades. Para ver cómo integrar en diversos frameworks, consulta Guía de configuración de frameworks.

Parámetros del servicio para cotejar con la lista

Aquí se enumeran los parámetros reales de nuestro servicio para que puedas cotejarlos punto por punto con la lista anterior sin tener que ir y volver entre documentos.

• Dirección del endpoint: https://api.llmzhongzhuan.com/v1, que soporta POST /v1/chat/completions y GET /v1/models. La autenticación se realiza con un token Bearer.
• Solo un modelo, con id uncensored; solo texto, sin vectores, imágenes, audio, video ni ajuste fino.
• La ventana de contexto es de 100.000 tokens (entrada más salida), max_tokens tiene un valor predeterminado de 2048 y un máximo por petición de 32.000; el cuerpo de la petición no supera los 8 MB.
• Cada clave permite 300 peticiones por minuto; al exceder el límite se devuelve 429; un 503 con upstream_busy indica que debes reintentar más tarde; cuando el saldo se agota o la prueba expira, se devuelve 402 con no_credit.
• El precio es de $0,25 por millón de tokens de entrada y $1,00 por millón de tokens de salida. Recarga prepagada, sin suscripción y el saldo no caduca.
• Los prompts no se utilizan para entrenamiento.

Los valores exactos están sujetos a la página de tarifas y la documentación. Las cuentas nuevas reciben un crédito de prueba gratis de $0,50 válido durante 7 días. No se requiere información de pago para registrarse; puedes usarlo para completar el flujo de verificación anterior.