Guia de migração de API Gateway: de OpenAI e OpenRouter para API sem censura

Qual a diferença entre um gateway de API e um modelo sem censura dedicado

Deixe os conceitos claros primeiro, para não escolher a direção errada durante a migração. Um gateway de API comum basicamente revende ou agrega cotas de modelos de grandes fabricantes, oferecendo um endpoint compatível com OpenAI para que você use o mesmo SDK com diferentes modelos. Ele resolve o problema de «acesso e pagamento» (entrada unificada, fatura única), mas o modelo em si continua sendo o original, com as mesmas políticas de conteúdo: tópicos bloqueados continuam bloqueados, mudar o endereço do gateway não altera isso.

Um modelo sem censura dedicado é diferente. Não é um proxy de outro modelo, mas sim um modelo fornecido separadamente que não recusa conteúdo adulto legal, criações fictícias e tópicos controversos. Wu Xianzhi API oferece apenas um modelo, com o nome uncensored. A API é compatível com o formato OpenAI, o que reduz o custo de migração, mas possui limites claros: apenas texto, sem suporte a imagens, áudio, vetores ou fine-tuning. Conteúdo sexual envolvendo menores é bloqueado (403), mesmo em contextos fictícios.

Antes de migrar, pergunte-se: o problema é instabilidade ou custo, ou o modelo bloqueia suas solicitações legítimas? Se for o segundo caso, mudar de gateway tem pouco valor; migre para uma API sem censura dedicada. Muitas equipes usam ambas: tarefas gerais usam a interface original, enquanto solicitações que exigem saída sem censura são roteadas para este serviço, conforme explicado abaixo.

As três alterações necessárias para migrar da OpenAI ou OpenRouter

Independentemente de usar OpenAI, OpenRouter ou gateway, se o SDK for compatível com OpenAI, altere três itens: base_url para https://api.wuxianzhiapi.com/v1; api_key pela chave em /get-api-key/; e model para uncensored. Não há outros modelos; GET /v1/models mostra apenas 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)

No Node.js, altere new OpenAI({...}): mude baseURL e apiKey. Para HTTP direto, use https://api.wuxianzhiapi.com/v1/chat/completions com cabeçalho Authorization: Bearer <chave>. Veja código de exemplo para Python, Node.js e cURL.

复制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}'

Tabela de parâmetros: o que funciona e o que não se aplica

A tabela abaixo revisa os campos mais comuns encontrados durante a migração. O princípio é: campos centrais compatíveis com OpenAI e relacionados a conversas funcionam normalmente; funcionalidades relacionadas a «outros modelos ou modalidades» não estão disponíveis aqui.

Uso original	Como tratar aqui
model (ex: modelos gpt)	Altere para uncensored
messages (system / user / assistant / tool)	Formato idêntico; use diretamente
max_tokens	Padrão 2048, máximo 32.000; retorna 400 se exceder
stream: true	Suportado; bloco de uso é adicionado automaticamente ao final
tools / tool_choice	Suportado, formato OpenAI
Comprimento do contexto	Soma de prompt e saída: 100.000 tokens
Tamanho do corpo da solicitação	Máximo 8 MB
Limite de requisições	300 requisições por minuto por chave
Vetores embeddings	Não suportado
Geração de imagens / Reconhecimento de imagens, áudio, vídeo	Não suportado; apenas texto
Fine-tuning	Não suportado
Alternar entre vários modelos	Há apenas um modelo, sem lista de alternância

Não assuma que campos opcionais não listados funcionarão como no fabricante original. A abordagem segura é testá-los isoladamente no ambiente de staging e confirmar o comportamento antes de ir para produção. Consulte a documentação da API para ver o suporte específico.

O que fazer com capacidades não disponíveis: alternativas para vetores, imagens e áudio

Se o seu projeto antigo usa simultaneamente conversação e recuperação vetorial, não tente migrar tudo de uma vez. Aqui oferecemos apenas conversação por texto, portanto o código relacionado a embeddings (como recuperação de base de conhecimento e deduplicação semântica) deve continuar usando seu serviço vetorial original ou uma solução de vetores implantada por você. Migre apenas a parte de conversação e mantenha a recuperação inalterada; como as duas partes são independentes, essa é a forma mais prática de separação.

O mesmo vale para imagens e áudio. Por exemplo, se o seu produto é baseado em texto com imagens, a geração de texto pode passar por aqui, enquanto as imagens continuam usando a sua API de imagens original. Para narração por voz, após gerar o texto, envie-o para o seu serviço de TTS existente. Isolar a geração de texto em uma função separada minimiza o impacto de quaisquer mudanças futuras ao combinar outras capacidades.

Se usar múltiplos modelos, aqui há apenas um. O custo de entrada é $0.25/1M tokens. Para tarefas curtas, ajuste max_tokens para reduzir custos. Veja detalhes em preços.

Execução em paralelo: alternância entre duas interfaces via variáveis de ambiente

O maior medo na migração é a abordagem de "tudo ou nada". A abordagem mais segura é criar uma camada de abstração leve no código, usando variáveis de ambiente para decidir qual endpoint usar. Assim, você pode direcionar apenas uma pequena parte do tráfego ou uma funcionalidade específica para a nova interface; se houver problemas, basta alterar uma variável para reverter. Como ambas as interfaces seguem o formato compatível com OpenAI, essa abstração é muito simples.

复制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)

A granularidade da migração pode ser em três níveis: por ambiente (migre o ambiente de staging primeiro), por funcionalidade (migre apenas as interfaces de criação) ou por usuário (migre gradualmente para um subconjunto de contas). Em qualquer nível, mantenha o campo provider nos logs para facilitar a comparação em caso de divergências. Armazene o histórico de conversas como um array messages padrão, permitindo continuar a conversa entre os dois ambientes sem interrupção.

Lista de verificação para migração

Antes de ir para produção, percorra a seguinte ordem para garantir que nada seja esquecido:

1. Registre-se em /get-api-key/, obtenha sua chave e valide com o crédito de teste de $0,50 (válido por 7 dias), sem necessidade de recarga inicial.
2. Use curl /v1/models para confirmar que a chave é válida e que a rede está acessível.
3. Altere base_url, api_key e model para serem controlados por variáveis de ambiente, garantindo que a chave não fique armazenada no repositório de código.
4. Procure no código por nomes de modelo fixos, valores de max_tokens e chamadas de embeddings.
5. Verifique o código de streaming para compatibilidade com o último bloco de uso, onde choices é um array vazio.
6. Adicione tentativas com backoff exponencial para erros 429 e 503, e ramificações de tratamento explícito para erros 402 e 403.
7. Execute uma bateria de testes de regressão com seus prompts reais, focando na verificação de respostas que antes eram rejeitadas.
8. Comece com uma pequena porcentagem de tráfego, compare uso e latência; se estiver tudo correto, aumente gradualmente.
9. Confirme que o produto é voltado para usuários adultos e que o uso é legal; este é um pré-requisito para o uso desta interface.

Os principais problemas comuns durante a migração

Nome do modelo não alterado. Se você enviar nomes de modelos gpt ou caminhos de modelos de plataformas agregadas do código antigo, receberá respostas de erro. Faça uma busca global pelo nome do modelo e garanta que o valor enviado seja uncensored.

Limite excedido em max_tokens. Alguns projetos definem max_tokens como 32000 ou mais para gerar textos longos. Aqui, o limite máximo por solicitação é 32.000; valores maiores retornam erro 400. Além disso, a soma dos tokens do prompt com max_tokens não pode exceder 100.000 tokens. Para entradas longas, reduza o limite de saída.

Blocos de uso em streaming. O servidor anexa automaticamente um bloco contendo usage ao final do stream, com choices como array vazio. Se seu código de análise acessar diretamente chunk.choices[0], ocorrerá erro no último passo. Alguns códigos antigos ainda passam manualmente stream_options para obter o uso; aqui isso não é necessário.

Confundir "sem censura" com "sem limites". Conteúdo adulto legal, ficção e tópicos controversos não são rejeitados, mas conteúdo sexual envolvendo menores é sempre bloqueado, incluindo em contextos de ficção e roleplay, retornando erro 403 content_blocked. O produto deve implementar seu próprio controle de acesso para usuários adultos.

Saldo e validade do teste. O crédito de teste expira em 7 dias. Ao acabar, retorna 402 (erro no_credit). Mostre uma mensagem clara ao usuário. Veja cenários de uso.