Relay e proxy da DeepSeek API costumam ser tratados como algo simples: "basta trocar o endereço". Na escolha real, porém, quatro perguntas precisam de resposta: como o dinheiro é calculado, se a rede é estável, quem responde quando há falha e se chave e dados estão em conformidade.
Este artigo compara as soluções comuns e apresenta um checklist de migração e verificação. Preços, nomes de modelo e disponibilidade seguem a página de preços do site e as informações do provedor.
Nota: DeepSeek é marca de seu titular; este artigo não tem vínculo com a DeepSeek oficial. O mercado de relay muda rápido; o texto usa como exemplo o formato comum em outubro de 2026 e não constitui endosso a nenhum provedor.
1. Definição: relay, proxy e gateway não são a mesma coisa
- Relay de API: encaminha a requisição ao serviço de modelo upstream e pode oferecer cobrança, limite e logs. Alguns "relays" do mercado apenas compartilham ou revendem chaves; estabilidade e conformidade dependem do operador.
- Proxy de rede: HTTP, SOCKS ou proxy reverso que resolve apenas o alcance de rede, sem alterar a semântica da API; a chave continua sendo sua.
- Proxy próprio: a equipe implanta um proxy reverso ou gateway open source no próprio servidor e controla chave, logs e roteamento, mas assume conta upstream, banda e operação.
- Gateway de IA unificado: entrada compatível com OpenAI que agrega vários modelos e oferece chave, fatura e console unificados. Gateways comerciais e implantações open source podem pertencer a essa categoria.
Misturar os quatro conceitos leva a tratar problema de rede como problema de modelo. Antes de contratar, pergunte claramente: qual camada o provedor oferece e de quem é a chave.
2. As quatro soluções em uma tabela
| Dimensão | Acesso oficial | Proxy próprio | Relay comercial | Gateway unificado |
|---|---|---|---|---|
| Transparência de cobrança | Fatura oficial, critério claro | Fatura upstream mais custo próprio | Depende do operador; exige conciliação | Fatura unificada no painel; consulte a regra de cálculo |
| Estabilidade de rede | Afetada pela saída local | Depende do servidor e da rota | Depende da rota do relay | Depende da rota do gateway e do upstream |
| Limite e concorrência | Limite por conta oficial | Controlado pela equipe, mas limitado pelo upstream | Pode usar pool compartilhado; confirme | Consulte regras e plano do gateway |
| Cobertura de modelos | Somente DeepSeek | Depende do upstream conectado | Em geral maior; verifique | Multimodelo, conforme a página de preços |
| Risco de chave | Chave sob seu controle | Chave sob seu controle | Pode usar chave compartilhada ou revendida | Normalmente emite chave independente |
| Operação e suporte | Documentação oficial | Tudo por conta da equipe | Depende da capacidade do provedor | Console, chamados e documentação |
Nenhuma solução serve a todas as equipes. Se você usa apenas DeepSeek e rede e pagamento funcionam, o acesso oficial é o mais direto; se precisa de saída fixa e auditoria, avalie proxy próprio; sem equipe de operação, avalie relay comercial; se quer fatura unificada para vários modelos, avalie um gateway.
3. Preço: não olhe apenas o "multiplicador"
Relays costumam cobrar "preço oficial vezes multiplicador" ou "pacote de tokens". Multiplicador baixo não significa custo total baixo. No mínimo, esclareça oito pontos:
- Entrada e saída são cobradas separadamente? O multiplicador é o mesmo?
- Entrada com acerto de cache tem desconto? Como é calculado?
- Tokens de raciocínio gerados pelo thinking entram na saída?
- Requisições com falha e retries são cobrados?
- O usage de requisições em streaming é retornado por completo?
- A recarga tem valor mínimo, validade e regra de reembolso?
- Emite nota fiscal? Qual moeda e câmbio?
- O consumo e a fatura podem ser separados por projeto, chave e modelo?
Coloque esses critérios na tabela de comparação e teste com o mesmo lote de requisições para calcular o custo real. Preços e regras específicas seguem a página de preços e a fatura do provedor.
4. Estabilidade: valide com dados, não com propaganda
Avalie ao menos seis indicadores: taxa de sucesso, latência P50/P95, tempo até o primeiro token, taxa de timeout, proporção de 429 e velocidade de saída. O teste deve usar prompts com tamanho real e cobrir streaming, contexto longo e concorrência.
import os
import statistics
import time
from openai import OpenAI
client = OpenAI(
api_key=os.environ["RELAY_API_KEY"],
base_url=os.environ["RELAY_BASE_URL"],
max_retries=0,
timeout=60,
)
prompt = "Explique em 200 palavras as principais etapas do cumprimento de pedidos no comércio eletrônico transfronteiriço."
latencies, errors, usage = [], 0, []
for i in range(20):
start = time.perf_counter()
try:
resp = client.chat.completions.create(
model=os.environ["RELAY_MODEL"],
messages=[{"role": "user", "content": prompt}],
max_tokens=512,
)
latencies.append((time.perf_counter() - start) * 1000)
usage.append(resp.usage.total_tokens if resp.usage else 0)
print(i, resp.model, resp.usage)
except Exception as exc:
errors += 1
print(i, type(exc).__name__, exc)
if latencies:
print("sucessos", len(latencies), "falhas", errors)
print("P50", statistics.median(latencies), "ms")
print("máximo", max(latencies), "ms")
print("média de tokens", sum(usage) / len(usage))
Isso é só uma sonda mínima, não um teste de carga. Antes de produção, observe por 7 dias consecutivos, rodando uma bateria em horário de pico e outra fora dele, e compare com o acesso oficial. Para relays comerciais, foque no pico da noite e em requisições longas; para proxy próprio, foque na saída do servidor e no limite do upstream.
5. Risco de chave e conformidade: mais importante que o preço
O ponto mais negligenciado em relays é a propriedade da chave. Chave compartilhada, chave revendida ou cota de origem desconhecida podem trazer quatro problemas:
- Se o upstream bloquear ou ajustar a cota, o negócio para junto e não há canal direto de contestação.
- Vários locatários usando a mesma chave fazem limites e falhas se afetarem mutuamente, dificultando o diagnóstico.
- O conteúdo da requisição passa por terceiros, e políticas de log, cache e retenção podem não ser transparentes.
- Os termos podem proibir revenda ou compartilhamento, deixando a empresa sem base contratual em caso de disputa.
Ao escolher o provedor, confirme ao menos pessoa jurídica, termos de serviço, política de privacidade, capacidade de nota fiscal e canal de contato para incidentes. Não envie requisições com dados pessoais, chaves ou contratos a um relay que não explica para onde vão os dados. Em cenários regulados, como finanças e saúde, priorize acesso oficial, implantação privada ou provedor que assine acordo de tratamento de dados.
6. Checklist de migração: do acesso direto para relay ou gateway
- Registre a situação atual: taxa de sucesso, latência P50/P95, tokens por mil requisições e fatura.
- Mapeie nomes de modelo e parâmetros: thinking, max_tokens, tools, saída JSON e streaming.
- Crie chaves de teste e de produção separadas, com orçamento e alertas próprios.
- Altere apenas
base_urleapi_keye valide a requisição mínima em pré-produção. - Reproduza prompts reais e compare qualidade, tempo e critério de usage.
- Verifique o mapeamento de 401, 402, 429, 5xx e timeout; confirme que retries não ampliam a falha.
- Faça canário com 5% a 10% do tráfego, observe de 3 a 7 dias e mantenha o acesso oficial como rollback.
- Após a troca total, concilie por mais uma semana e confirme que fatura e estatísticas de uso coincidem.
Não altere modelo, prompt e gateway ao mesmo tempo na migração, ou não será possível atribuir a causa. Mude uma variável por vez.
7. Como verificar se um relay é confiável
Comece pelo campo model da resposta, mas não confie apenas nele, pois pode ser reescrito. O mais confiável é combinar verificações:
| Item | Como fazer | Sinal anormal |
|---|---|---|
| Latência | Repetir o mesmo prompt e comparar P50/P95 | Oscilação extrema ou muito mais lento que o acesso direto |
| Taxa de erro | Medir proporção de 429, 5xx e timeout | Falhas concentradas no horário de pico |
| Consumo | Comparar usage da resposta com a fatura do painel | Divergência ou ausência de usage em streaming |
| Identidade do modelo | Comparar limites de capacidade e estilo com um conjunto fixo | Queda clara de capacidade ou contexto menor |
| Isolamento de chave | Confirmar se a chave é independente e rotacionável | Recusa em explicar a origem da chave |
| Contrato e suporte | Verificar pessoa jurídica, termos, nota e resposta a chamados | Apenas contato pessoal e nenhum termo de serviço |
Sinais de alerta incluem: preço muito abaixo do oficial por longo período, promessa de "zero falhas", recusa em fornecer detalhamento de consumo, pedido para você entregar sua chave oficial e incapacidade de informar onde os dados são retidos. Diante disso, valide com pouco tráfego antes de migrar produção de uma vez.
8. Quando o proxy próprio é mais adequado
O proxy próprio serve equipes com capacidade de engenharia que precisam de IP de saída fixo, auditoria unificada, roteamento para vários upstreams ou manter a chave sob controle. O padrão comum é um proxy reverso com gestão de chaves, limite de taxa, logs e alertas, usando conta oficial ou fornecedor compatível no upstream.
O custo precisa entrar na conta: servidor, banda, certificado, upgrades, correção de vulnerabilidades e plantão. Para uso esporádico e sem equipe de operação, o proxy próprio costuma sair mais caro que uma solução comercial. Ele também não contorna limites do upstream nem termos de serviço.
9. Recomendação: ordene pelas restrições
- Primeiro rede e pagamento: a entrada oficial é estável e a recarga funciona? Se sim, priorize o acesso oficial.
- Depois controle: precisa de saída fixa, log de auditoria e chave privada? Se sim, avalie proxy próprio.
- Depois abrangência de modelos: quer chamar vários modelos por uma entrada? Se sim, avalie gateway unificado.
- Por fim capacidade de serviço: pessoa jurídica, termos, nota fiscal, suporte e política de dados estão claros?
Se precisar de entrada unificada para vários modelos, crie uma chave de teste no ZSQH AI Gateway e valide antes de migrar; preços e modelos disponíveis estão na página de preços. Não use "barato" como único critério: custo de migração e de falha também contam.
Leituras relacionadas:
- Preços e cobrança da DeepSeek API
- Integração da DeepSeek API: chave, URL base e primeira chamada
- Modelos e preços
Perguntas frequentes
Qual a diferença entre relay e proxy?
Proxy normalmente se refere ao encaminhamento na camada de rede e resolve apenas o alcance; relay também envolve distribuição de conta, cobrança ou chave. Os termos são usados de forma intercambiável, então esclareça o escopo do serviço antes de contratar.
Se o preço do relay é menor que o oficial, posso confiar?
Pode vir de compra em lote, subsídio de rota ou revenda de cota, e também pode vir com chave compartilhada, limite ou instabilidade. Confira critério de cobrança, detalhamento de consumo e contrato, e teste com pouco tráfego.
Como saber se o relay trocou o modelo?
Não basta olhar o campo model da resposta. Compare com um conjunto fixo de testes os limites de capacidade, o tamanho de contexto, o estilo de saída e a estrutura de usage, mantendo o acesso oficial como referência. Se a capacidade cair claramente, suspenda o tráfego antes de investigar.
Quanto código muda ao migrar para um gateway?
Na maioria dos projetos com SDK da OpenAI, mudam apenas base_url e api_key, com ajuste dos nomes de modelo conforme a página de preços do gateway. Se houver thinking, tools ou campos de resposta específicos, faça testes de compatibilidade adicionais.
O que uma empresa deve priorizar?
Propriedade da chave, acordo de tratamento de dados, nota fiscal e pessoa jurídica do contrato, resposta a incidentes e mecanismo de saída. Preço importa, mas continuidade do negócio e responsabilidade de conformidade importam mais.
