Quando equipes na China discutem o DeepSeek API, a pergunta costuma ser reduzida a "dá para conectar?". O que realmente afeta a produção são quatro coisas: a rede é estável, o pagamento e a nota fiscal funcionam, a limitação de taxa no horário de pico é aceitável e existe um canal alternativo em caso de falha. Se uma dessas condições não se cumpre, "conseguir conectar" não significa nada.

Este artigo compara três rotas comuns — conexão direta oficial, proxy próprio e gateway de IA doméstico — e apresenta métodos de timeout, retry, degradação e verificação. Modelos, preços e formas de acesso específicos devem seguir a página de preços e as instruções do site.

Nota: DeepSeek é marca registrada de seu titular. Este artigo usa a situação comum de outubro de 2026 como exemplo; o ambiente de rede e os termos de serviço podem mudar. Consulte a documentação oficial e a legislação local.

1. Três rotas em uma tabela

Dimensão Conexão direta oficial Proxy próprio Gateway de IA doméstico
Entrada Endereço oficial do DeepSeek Servidor próprio encaminhando Entrada unificada compatível com OpenAI
Pagamento Canais suportados oficialmente Paga servidor e largura de banda antes Recarga no site, regras conforme a página
Escopo de modelos Apenas DeepSeek Depende da configuração do proxy Vários modelos, conforme disponibilidade
Responsabilidade pela estabilidade Oficial e rede local Toda do próprio time Compartilhada entre provedor e time local
Custo operacional Baixo Alto Médio
Equipe indicada Modelo único, baixo volume, rede estável Com capacidade de operar rede Vários modelos, nota fiscal, cobrança unificada

Nenhuma rota serve para todos. A ordem de avaliação é: primeiro, se o negócio tolera interrupção; depois, se precisa de vários modelos e nota fiscal; por fim, se o time tem pessoal para operação.

2. Conexão direta oficial: quando basta

A conexão direta oficial serve para estes casos: usar apenas DeepSeek, volume estável, rede local funcionando, recarga oficial possível e negócio que tolera lentidão no pico. Os passos não são complexos:

  1. Crie uma API Key no DeepSeek Open Platform, nomeando por projeto.
  2. Coloque a Key em variável de ambiente no servidor; nunca no front-end ou no repositório.
  3. Faça uma requisição mínima com curl e confirme Base URL e nome do modelo.
  4. No SDK, defina timeout de conexão, timeout de leitura e limite de retries.
  5. Registre modelo, tokens, latência e tipo de erro de cada requisição.
export DEEPSEEK_API_KEY="sk-sua-chave"

curl "https://api.deepseek.com/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Responda apenas OK"}],
    "max_tokens": 16
  }'

Se o comando às vezes dá timeout, mas funciona em outra rede, o problema provavelmente está na saída local ou no DNS, não na Key. Guarde o horário da requisição e a mensagem de erro antes de decidir trocar de rota.

3. Proxy próprio: resolve a saída, não a capacidade

A prática comum é fazer proxy reverso em um servidor com acesso à interface oficial e encaminhar as requisições ao DeepSeek. Isso resolve parte da instabilidade da rede local, mas cria novo trabalho:

  • O servidor proxy é um ponto único; se cair, todas as requisições falham juntas.
  • É preciso tratar TLS, autenticação e controle de acesso para evitar abuso.
  • Logs, limitação de taxa e monitoramento são necessários; sem eles, não se localiza o problema.
  • Uma camada extra de encaminhamento aumenta a latência; o primeiro token no streaming pode demorar mais.
  • A responsabilidade de rede e conformidade continua com o time.

Sem pessoal dedicado à manutenção, o proxy próprio costuma passar de "solução temporária" a "passivo de longo prazo". Pode servir de transição, mas não é recomendável como entrada única.

4. Gateway de IA: convergir vários modelos e instabilidade em uma entrada

O valor de um gateway de IA doméstico não é só "intermediar", mas reunir gestão de Keys, recarga, cobrança, troca de modelos e tratamento de falhas em um só lugar. Para equipes que usam vários modelos, a mudança mais direta é: o código de negócio conhece apenas uma entrada compatível com OpenAI; trocar de modelo vira mudança de configuração, não de código.

export ZSQH_API_KEY="sk-sua-chave"

curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Explique em uma frase o papel do gateway"}],
    "max_tokens": 128
  }'

Ao escolher um gateway, confirme cinco pontos: suporta os modelos que você usa; tem regras claras de cobrança e recarga; oferece detalhamento de uso; informa como avisar em caso de falha; e os termos de dados atendem aos requisitos de conformidade. Não avalie apenas "se a chamada funciona".

5. Estabilidade é responsabilidade sua: timeout, retry e degradação

Qualquer que seja a rota, o cliente precisa de proteção. A configuração sugerida, nesta ordem:

  1. Separe timeout de conexão e de leitura: conexão curta, leitura longa; textos longos e tarefas de raciocínio com configuração própria.
  2. Retry com backoff: repita apenas em 429, 5xx e timeout, com backoff exponencial e jitter aleatório, e defina o número máximo.
  3. Controle a concorrência: use filas para suavizar picos em tarefas em lote; não sature tudo na virada da hora.
  4. Prepare modelo de degradação: o negócio central pode migrar para modelo ou canal alternativo, aceitando diferenças de saída.
  5. Adicione circuit breaker: ao atingir o limite de falhas consecutivas, pause as requisições para evitar tempestade de retries.
  6. Garanta idempotência: em operações com efeitos colaterais, verifique o estado antes de reenviar; não repita às cegas.
import httpx
from openai import OpenAI

client = OpenAI(
    api_key="sk-sua-chave",
    base_url="https://ai.zhongshangqihang.com/v1",
    timeout=httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=10.0),
    max_retries=2,
)

Não existe padrão único de timeout; ajuste conforme a tolerância do negócio e o tamanho da tarefa. O essencial é não deixar a requisição esperar indefinidamente nem reenviar em paralelo imediatamente após falha.

6. Valide uma rota em uma semana

Métrica Como registrar O que observar
Taxa de sucesso Proporção de respostas não 200 Se se concentra no horário de pico
Latência p50, p95 e tempo do primeiro token Se a latência de cauda afeta a experiência
Limitação Contagem de 429 e horários Se é cota ou pico de tráfego
Erros de rede DNS, TLS, timeout de conexão Se é problema da saída local
Qualidade Amostragem manual de tarefas fixas Se a saída é consistente após trocar de rota

Na validação, cubra ao menos um pico de dia útil e um vale noturno. Rodar o mesmo lote de requisições em horário fixo por sete dias é mais útil do que um teste de carga isolado.

7. Pagamento, nota fiscal e conformidade

  • Equipes que precisam de pagamento corporativo e nota fiscal devem confirmar antes as regras de faturamento e o prazo de crédito.
  • Com dados de clientes, leia os termos de dados e confirme se as entradas são retidas ou usadas para melhorar o serviço.
  • Separe Keys por ambiente; a Key de produção não entra no front-end nem em repositório público.
  • Guarde logs de chamadas e faturas para conciliação financeira e auditoria de segurança.
  • Transferência transfronteiriça e exigências regulatórias do setor devem seguir a legislação local e o processo de conformidade da empresa.

Perguntas frequentes

A conexão direta ao DeepSeek na China é estável?

Depende da rede local, do horário e da carga oficial; não há resposta única. Em produção, não dependa de uma única rota: tenha ao menos timeout, retry e canal alternativo.

O gateway deixa mais lento?

Uma camada extra pode adicionar latência, mas o gateway costuma oferecer entrada mais estável e failover. Teste o mesmo lote na conexão direta e no gateway, comparando p95 e taxa de sucesso, não uma única requisição.

Proxy próprio serve para qualquer equipe?

Não. Exige operação contínua de rede, configuração de segurança e monitoramento. Sem responsável dedicado, o proxy vira um novo ponto de falha.

Uma Key pode chamar vários modelos?

No modo gateway, normalmente sim; o modelo é indicado na requisição, e o escopo depende da página de preços e do console. Na conexão direta, a Key só acessa os modelos liberados oficialmente.

Como saber se o problema é local ou upstream?

Teste primeiro com uma requisição mínima e depois varie rede, Key e entrada. Guardando horário e mensagem de erro, dá para distinguir rapidamente DNS, TLS, autenticação, limitação e falha upstream.

Próximos passos

Crie uma Key de teste no ZSQH AI Gateway, compare taxa de sucesso e latência da conexão direta e do gateway com o mesmo lote de requisições e então defina a rota de produção. Modelos e preços seguem a página de preços.

Leitura relacionada: