Guía de migración de API Gateway: cambia de OpenAI y OpenRouter a una API sin censura

¿Cuál es la diferencia entre un API Gateway y un modelo dedicado sin censura?

Aclaremos los conceptos para no elegir mal. Un API Gateway suele revender o agregar cuotas de modelos de grandes empresas, ofreciendo una dirección compatible con OpenAI para que uses el mismo SDK con distintos modelos. Resuelve el acceso y el pago (entrada única, facturación unificada), pero el modelo sigue siendo el original: las políticas de contenido del proveedor se mantienen intactas, y cambiar la dirección no cambia eso.

Un modelo dedicado sin censura es diferente. No reenvía modelos de otros; es un modelo independiente que no bloquea contenido adulto legal, ficción o temas controvertidos. Wu Xianzhi API ofrece solo un modelo, con el nombre uncensored. Es compatible con el formato OpenAI, por lo que la migración es sencilla, pero tiene límites claros: solo texto, sin imágenes, audio, vectores ni fine-tuning. Bloquea contenido sexual con menores, incluso si es ficticio, devolviendo 403.

Así que antes de migrar pregúntate: ¿tu problema es «API inestable o cara» o «el modelo rechaza constantemente tus solicitudes válidas»? Si es lo segundo, cambiar de relay tiene poco sentido; la solución es cambiar a una API sin censura dedicada. Muchos equipos mantienen ambos: las tareas generales siguen usando la API original, mientras que las solicitudes que requieren salida sin censura se enrutan aquí. Más adelante se explica cómo hacerlo.

Los tres cambios necesarios al migrar desde OpenAI o OpenRouter

Ya sea que uses la API oficial de OpenAI, un agregador como OpenRouter o un relay, si tu código usa un SDK compatible con OpenAI, solo necesitas cambiar tres cosas: base_url a https://api.wuxianzhiapi.com/v1; api_key por la clave que obtengas en /get-api-key/; y model a uncensored. No hay otros modelos disponibles; GET /v1/models solo muestra este.

复制import os
from openai import OpenAI

messages = [{"role": "user", "content": "你好"}]

# 迁移前（示意）：
# client = OpenAI(api_key=os.environ["OLD_API_KEY"], base_url="旧地址")
# resp = client.chat.completions.create(model="旧模型名", messages=messages)

# 迁移后：只动 base_url、api_key、model 这三处
client = OpenAI(
    base_url="https://api.wuxianzhiapi.com/v1",
    api_key=os.environ["WUXIANZHI_API_KEY"],
)
resp = client.chat.completions.create(model="uncensored", messages=messages, max_tokens=100)
print(resp.choices[0].message.content)

Para Node.js es igual: cambia new OpenAI({...}) baseURL y apiKey. Si tu proyecto usa peticiones HTTP directas, cambia la URL de la petición a https://api.wuxianzhiapi.com/v1/chat/completions y mantén el encabezado Authorization: Bearer <clave>. Las implementaciones completas en Python, Node.js y cURL se pueden consultar en ejemplos de código.

复制curl https://api.wuxianzhiapi.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $WUXIANZHI_API_KEY" \
  -d '{"model":"uncensored","messages":[{"role":"user","content":"你好"}],"max_tokens":50}'

Tabla de parámetros: qué funciona y qué no

La siguiente tabla revisa los campos más comunes al migrar. La regla es: los campos centrales de chat en formato OpenAI funcionan igual; las funciones relacionadas con otros modelos o modalidades no están disponibles aquí.

Uso anterior	Cómo manejarlo aquí
model (ej. modelos gpt)	Cambia a uncensored
messages (system / user / assistant / tool)	Formato idéntico, úsalo directamente
max_tokens	Por defecto 2048, máximo 32,000; excederlo da error 400
stream: true	Compatible; se añade un bloque de uso al final
tools / tool_choice	Compatible, formato OpenAI
Longitud del contexto	100,000 tokens combinando prompt y salida
Tamaño del cuerpo de la petición	No más de 8 MB
Tasa de limitación	300 peticiones por minuto por clave
embeddings vectoriales	No compatible
Generación de imágenes, reconocimiento de imágenes, audio y video	No compatible, solo texto
Fine-tuning	No compatible
Cambiar entre varios modelos	Solo hay un modelo, no hay lista de opciones para cambiar

No asumas que otros campos opcionales no listados aquí funcionarán igual que en el modelo original. Lo seguro es probarlos por separado en un entorno de pruebas y confirmar que se comportan como esperas antes de lanzar. Para ver el soporte exacto, consulta documentación de la API.

¿Qué hacer con las capacidades que no se admiten: alternativas para vectores, imágenes y audio

Si tu proyecto original usaba tanto conversaciones como recuperación de vectores, no intentes migrar todo de golpe. Aquí solo se ofrece conversación de texto, por lo que el código relacionado con embeddings, como la recuperación de conocimiento o la deduplicación semántica, debe seguir usando tu servicio de vectores original o cambiar a una solución de vectores implementada por ti mismo. Mueve la parte de conversación a este servicio y deja la parte de recuperación donde está; al no interferir entre sí, es la forma más sencilla de separarlas.

Lo mismo aplica para imágenes y audio. Por ejemplo, si tu producto es de tipo «texto con imágenes», la generación de texto puede pasar por aquí y las imágenes pueden seguir usando tu API de imágenes original; para la narración de audio, envía el texto generado a tu servicio de voz existente. Extraer la generación de texto como una función independiente hace que cualquier combinación posterior con otras capacidades requiera cambios mínimos.

Otro caso es cuando tu código usa varios modelos para diferentes tareas, como un modelo barato para clasificación y uno caro para creación. Aquí solo hay un modelo, así que también él hará la clasificación. Por suerte, el precio por entrada es de $0,25 por millón de tokens, por lo que el costo de tareas de salida corta como la clasificación es bajo. Configura max_tokens en un valor pequeño y el costo será prácticamente despreciable. Para más detalles, consulta la página de precios.

Ejecución en paralelo: cambia entre dos endpoints con variables de entorno

Lo que más se teme en una migración es el cambio «todo o nada». Una forma más segura es crear una capa de envoltura ligera en el código que use una variable de entorno para decidir qué endpoint usar. Así puedes dirigir un pequeño porcentaje de tráfico o una función específica al nuevo endpoint y, si surge un problema, revertir el cambio modificando una sola variable. Como ambos endpoints usan el formato compatible con OpenAI, la envoltura es muy sencilla.

复制import os
from openai import OpenAI

PROVIDERS = {
    "old": {
        "base_url": os.environ.get("OLD_BASE_URL", ""),
        "api_key": os.environ.get("OLD_API_KEY", ""),
        "model": os.environ.get("OLD_MODEL", ""),
    },
    "wuxianzhi": {
        "base_url": "https://api.wuxianzhiapi.com/v1",
        "api_key": os.environ.get("WUXIANZHI_API_KEY", ""),
        "model": "uncensored",
    },
}

def get_client(name=None):
    name = name or os.environ.get("LLM_PROVIDER", "old")
    cfg = PROVIDERS[name]
    return OpenAI(base_url=cfg["base_url"], api_key=cfg["api_key"]), cfg["model"]

def chat(messages, provider=None, **kwargs):
    client, model = get_client(provider)
    return client.chat.completions.create(model=model, messages=messages, **kwargs)

# 通用任务走旧接口，需要无审查输出的请求显式指定新接口
resp = chat([{"role": "user", "content": "写一个黑色幽默的短故事"}],
            provider="wuxianzhi", max_tokens=800)
print(resp.choices[0].message.content)

La granularidad del cambio puede tener tres niveles: por entorno (primero cambia en el entorno de pruebas), por función (solo mueve las interfaces de creación) o por usuario (gradualmente para un subconjunto de cuentas). En cualquier nivel, se recomienda dejar el campo provider en los registros de log para poder comparar y depurar cuando surjan diferencias. También se recomienda almacenar el historial de conversaciones como un array estándar de messages, de modo que una misma conversación pueda continuar sin interrupciones entre ambos endpoints.

Lista de verificación para el cambio

Pasa por el siguiente orden antes del lanzamiento para asegurar que no se te escape nada:

1. Regístrate en /get-api-key/, obtén tu clave y verifica con $0.50 de crédito de prueba (válido 7 días) sin necesidad de recargar.
2. Usa curl /v1/models para confirmar que la clave es válida y que la red es accesible.
3. Convierte base_url, api_key y model en variables de entorno para que la clave no se almacene en el repositorio de código.
4. Busca nombres de modelo hardcodeados, valores de max_tokens y llamadas a embeddings en tu código.
5. Verifica el código de streaming para manejar el último bloque de uso con choices vacío.
6. Agrega reintentos con retroceso exponencial para 429 y 503, y ramas de mensaje de error explícito para 402 y 403.
7. Ejecuta una batería de pruebas de regresión con tus prompts reales, prestando especial atención a si las respuestas que antes eran rechazadas ahora se generan correctamente.
8. Inicia con un pequeño porcentaje de tráfico, compara el uso y la latencia, y amplía solo si todo funciona bien.
9. Confirma que tu producto está dirigido a usuarios adultos y que su uso es legal; este es un requisito para usar este endpoint.

Los errores más comunes durante la migración

Nombre de modelo sin cambiar. Si envías rutas de modelos gpt antiguos o de agregadores sin cambiarlas, recibirás errores. Busca globalmente y asegura que se envíe uncensored.

Exceso de tokens en max_tokens. Algunos proyectos configuran max_tokens en 32000 o más para que el modelo genere textos largos. Aquí, el máximo por solicitud es de 32,000; si se supera, se devuelve un error 400. Además, la suma del prompt y max_tokens no puede exceder los 100,000 tokens. Para solicitudes de entrada muy largas, reduce el límite de salida en consecuencia.

Bloques de uso en streaming. El servidor añade un bloque con usage al final; su choices es un array vacío. Si tu código lee chunk.choices[0] directamente, fallará al final. No necesitas pasar stream_options manualmente aquí.

Confundir sin censura con sin límites. Se permite contenido adulto, ficción y controversia, pero se bloquea contenido sexual con menores (incluyendo ficción/roleplay), devolviendo 403 content_blocked. El producto debe gestionar el acceso de usuarios adultos.

Saldo y expiración de la prueba. El crédito de prueba caduca a los 7 días. Cuando se agote el saldo, recibirás un 402 con el código de error no_credit. Traduce este error en tu aplicación a un mensaje comprensible para el usuario, en lugar de un genérico «error del servicio». Para el diseño de casos de uso, consulta escenarios de aplicación.