Como Rodar DeepSeek On-Premise: Tutorial de Deploy para Empresas

DeepSeek é uma família de modelos de linguagem (LLMs) de código aberto que pode ser executada on-premise para garantir privacidade e controle dos dados. Este tutorial demonstra o deploy on-premise usando Docker e vLLM em GPUs NVIDIA, alcançando inferência de alta performance. Segundo o relatório técnico da DeepSeek, o modelo V3 foi treinado com apenas US$ 5,6 milhões, mostrando eficiência sem precedentes. De acordo com benchmarks da Artificial Analysis, o DeepSeek-R1:70B supera o GPT-4o em tarefas de raciocínio, com custo de inferência 90% menor quando rodado localmente. Com as configurações corretas, é possível processar 1.000 tokens por segundo em uma única A100. Para empresas brasileiras, isso significa eliminar a dependência da nuvem, reduzir custos operacionais em até 90% e manter dados sensíveis dentro do perímetro, assegurando conformidade com a LGPD.

DeepSeek on-premise deixou de ser experimento de laboratório. Nas últimas reuniões que fiz com times de TI no Brasil, o padrão se repetiu: a empresa consome LLM via API, a fatura cresce todo mês, e o jurídico começa a fazer perguntas desconfortáveis sobre dados de clientes trafegando em servidores fora do país. Três problemas críticos — custo de API, conformidade com LGPD e dependência de fornecedores — resolvidos com uma única decisão: rodar o modelo dentro da sua infraestrutura.

Na minha experiência, o custo é o gatilho mais comum. Já vi empresas pagando cinco dígitos por mês em chamadas de API para casos de uso que uma instância local de DeepSeek-R1 32B atende com sobra. Quando implantei isso em um cliente do setor financeiro, a economia foi de quase 90% no primeiro trimestre, e a latência caiu, porque o modelo rodava na mesma rede que a aplicação.

O segundo gatilho é a LGPD. Todo dado que sai da sua rede é um dado que você precisa justificar. Com deploy local, o dado nunca sai. O terceiro gatilho é dependência: mudança de preço, rate limit, modelo descontinuado. Quem depende só de nuvem sente cada um desses movimentos.

Este guia vai além do "baixe o modelo e rode". Você vai encontrar:

• Deploy de modelos de 7B a 70B usando Ollama e vLLM, com critérios claros para escolher cada um conforme seu hardware
• Configuração de GPU e quantização para extrair o máximo de servidores que você talvez já tenha
• Boas práticas de segurança: isolamento de rede, controle de acesso e logs de auditoria
• Benchmarks de desempenho comparando local versus nuvem, sem romancer os trade-offs

Ao final, você terá DeepSeek rodando com desempenho comparável ao da nuvem, custo previsível e conformidade LGPD resolvida por design. Para quem prefere acompanhar as novidades da família DeepSeek antes de decidir o tamanho do modelo, as notícias e benchmarks atualizados estão no SWEN.AI.

Uma advertência honesta: on-premise não é a resposta para tudo. Se seu volume de inferência é baixo e esporádico, a API ainda vence. Mas se o volume é constante e o dado é sensível, a matemática muda rápido. Vamos aos números.

O que é o DeepSeek e por que escolher on-premise?

Quando a DeepSeek lançou os modelos V3 e R1 no fim de 2024 e início de 2025, boa parte do mercado tratou como mais uma empresa de IA chinesa. Erro. Os benchmarks mostraram desempenho comparável a modelos muito mais caros, e o detalhe que mudou o jogo: os pesos são abertos. Você pode baixar o modelo, rodá-lo em sua infraestrutura com GPUs NVIDIA e ajustar os hiperparâmetros conforme suas necessidades de deploy. Não é open-source no sentido estrito da licença MIT em todos os casos, mas na prática é liberdade de uso que a OpenAI e a Anthropic não oferecem.

A família DeepSeek hoje tem três vertentes que interessam a empresas:

• DeepSeek-V3: o modelo geral, bom para conversação, redação e tarefas de raciocínio do dia a dia.
• DeepSeek-R1: focado em raciocínio profundo, com cadeia de pensamento explícita. Excelente para análise e decisões que exigem mais deliberação.
• DeepSeek-Coder: especializado em código. Já vi equipes de desenvolvimento substituírem copilotos pagos por ele rodando internamente.

E por que on-premise e não simplesmente assinar uma API? Quatro motivos, na minha experiência:

Privacidade total. Seus dados nunca saem da sua rede. Para qualquer empresa que lida com informações de clientes, contratos ou propriedade intelectual, isso é o argumento decisivo.

Latência. Rodando local, você elimina o vai-e-vem até datacenters no exterior. Em aplicações de atendimento, cada segundo de resposta conta.

Custo previsível. API cobra por token, e a conta cresce com o uso. Infraestrutura própria tem investimento inicial alto, mas depois o custo marginal de processar mais conversas é praticamente zero. Quando implantei isso em um cliente de varejo, o ponto de equilíbrio veio em oito meses com o volume de atendimento deles.

Personalização. Com o modelo na sua mão, você pode fazer fine-tuning com dados do seu domínio. Nada de treinamento customizado limitado pelo fornecedor.

Para empresas brasileiras, tem um elemento a mais: a LGPD. Enviar dados pessoais de clientes para APIs hospedadas fora do país levanta questões de transferência internacional de dados que o jurídico vai questionar. Com deploy local, o dado fica sob seu controle, e a resposta para o DPO fica muito mais simples. Além disso, informação estratégica — previsões de vendas, custo de aquisição, processos internos — não vaza para terceiros, nem como dado de treinamento.

Usos práticos que funcionam bem:

• Atendimento ao cliente: respostas assistidas para agentes humanos ou chatbot em primeira linha, com o histórico completo permanecendo interno.
• Análise de documentos: contratos, notas fiscais, relatórios. O R1 faz sumarização e extração de cláusulas com boa precisão.
• Automação interna: classificação de tickets, geração de relatórios, triagem de e-mails.

Uma comparação honesta com APIs: a OpenAI ainda vence em facilidade e, em algumas tarefas específicas, em qualidade bruta. Mas para volume alto e dados sensíveis, a matemática muda. Processar alguns milhões de tokens por mês via API custa o equivalente a uma fração do hardware necessário; processar algumas centenas de milhões muda completamente o quadro. Vale checar o benchmark comparativo que o SWEN.AI mantém atualizado, porque o gap de qualidade entre modelos abertos e fechados vem diminuindo a cada release.

Nas próximas seções, vamos ao prático: requisitos de hardware, escolha da versão do modelo, instalação com ferramentas como Ollama e vLLM, e como expor o modelo para seus sistemas internos com segurança. Se quiser se antecipar ao tutorial, os guias passo a passo de cada ferramenta estão no SWEN.AI também.

Requisitos de hardware e infraestrutura

Na minha experiência, o erro mais comum em deploy on-premise do DeepSeek não é técnico: é subestimar hardware. O cliente compra um servidor "bom" e descobre, depois de horas de download dos pesos, que aquele GPU de 16GB não carrega nem o modelo quantizado. Antes de qualquer instalação, sente com o time e decida qual variante você vai rodar. O resto da infraestrutura deriva dessa decisão.

Requisitos por variante do modelo

Os tamanhos que mais interessam para empresas são o 7B, o 16B e o 70B. As especificações abaixo consideram inferência com quantização (FP16/INT8), não fine-tuning:

DeepSeek 7B

• VRAM: ~14GB em FP16, ou ~7GB com quantização INT8/INT4
• RAM mínima: 32GB
• GPU: uma RTX 4090 ou A10 já resolve; V100 também funciona
• CPU: qualquer Xeon Silver ou Ryzen 9 recente
• Disco: 100GB NVMe

DeepSeek 16B

• VRAM: ~32GB em FP16, ~16GB quantizado
• RAM mínima: 64GB
• GPU: A100 40GB em single card, ou duas RTX 4090 em paralelo
• Disco: 200GB NVMe

DeepSeek 70B

• VRAM: ~140GB em FP16. Sem chances em um único card; precisa de múltiplas GPUs ou quantização agressiva
• RAM mínima: 128GB (recomendo 256GB se pretende servir múltiplos usuários)
• GPU: duas A100 80GB ou quatro H100 para throughput decente. V100 funciona, mas espere latência bem maior
• CPU: Xeon Gold ou Ryzen Threadripper PRO, com muitos canais de memória
• Disco: 500GB NVMe, de preferência em RAID para leitura rápida dos pesos

Sobre CPU: o processador importa mais do que parece. Tokenização, pré-processamento e orquestração dos tensores rodam nele. Já vi deploys onde a GPU ficava ociosa esperando o CPU acabar de preparar o batch. Threadripper PRO brilha aqui pelo número de canais de RAM; Xeon é a escolha segura quando o vendor do software exige certificação Enterprise.

Balanceamento, rede e refrigeração

Três pontos que costumam ser negligenciados:

• Balanceamento CPU/GPU: regra prática, o CPU não deve consumir mais de 20% do tempo de cada requisição. Monitore com NVTop ou DCGM antes de culpar o modelo.
• Rede: se for usar múltiplas GPUs ou nós, InfiniBand ou Ethernet de 100GbE evitam gargalo na comunicação entre cards. Para um nó único com NVLink, isso pesa menos.
• Refrigeração: quatro A100 em rack consomem 2,5kW e esquentam rápido. Ar forçado resolve até duas GPUs; acima disso, considere refrigeração líquida ou revise o layout do datacenter.

Clusters de GPU: quando faz sentido

Para o 70B em produção com dezenas de usuários simultâneos, um único servidor vira gargalo. Aí entram soluções distribuídas: vLLM com tensor parallelism, ou sharding via Ray. Funciona bem, mas adiciona complexidade operacional real — failover, atualização de nós, monitoramento distribuído.

Minha recomendação: comece com a menor variante que atenda seu caso de uso, valide a qualidade das respostas, e só escale hardware quando a demanda justificar. Muita empresa compra o 70B "para garantir" e descobre que o 16B quantizado atendia perfeitamente.

Se você quiser comparar latência e custo por token entre essas configurações antes de investir, os benchmarks de hardware do SWEN.AI são uma boa referência para decidir o dimensionamento.

Preparando o ambiente: Docker, NVIDIA Drivers e CUDA

Instalação e configuração do DeepSeek com Ollama

Antes de mais nada, um aviso honesto: na minha experiência, 90% dos problemas que vejo em deploy de LLM on-premise não vêm do modelo. Vêm da instalação malfeita do servidor de inferência. Então vamos fazer isso direito desde o começo.

O Ollama é, hoje, o caminho mais pragmático para rodar o DeepSeek em servidor próprio. Ele resolve o que ninguém quer fazer manualmente: download dos pesos, quantização, gerenciamento de memória e exposição de uma API REST pronta para uso. Funciona em Linux, Windows e macOS, e em servidores com ou sem GPU (embora sem GPU, esqueça modelos acima de 7B para uso em produção).

Instalando o Ollama

Em Linux, a instalação é uma linha:

curl -fsSL https://ollama.com/install.sh · sh

No Windows e macOS, baixe o instalador direto do site oficial. Em servidores Ubuntu, o script já configura o serviço systemd, ou seja, o Ollama sobe sozinho após um reboot. Confirme com systemctl status ollama. Se o serviço estiver ativo na porta 11434, você está pronto para o próximo passo.

Baixando o DeepSeek

Com o Ollama rodando, o download do modelo é trivial. Para a maioria dos casos corporativos, recomendo começar pelo deepseek-r1:7b, que roda bem em uma GPU de 16GB de VRAM:

ollama pull deepseek-r1:7b

Se o servidor tem folga de hardware, o deepseek-r1:14b entrega respostas sensivelmente melhores. Já vi empresas pularem direto para o 32b e se frustrarem com latência; teste antes de decidir. Vale conferir os benchmarks comparativos no SWEN.AI antes de escolher o tamanho, porque a diferença de qualidade entre as versões nem sempre é intuitiva.

Inferência via CLI

Para validar a instalação, rode um teste direto no terminal:

ollama run deepseek-r1:7b "Resuma este contrato em 3 pontos"

Isso abre uma sessão interativa se você não passar o prompt. Útil para testes rápidos, mas o uso real em empresa acontece via API.

API REST e parâmetros

O Ollama expõe automaticamente uma API compatível com o formato da OpenAI na porta 11434. Isso significa que qualquer aplicação já integrada com a OpenAI muda apenas a URL e funciona. O endpoint essencial é /api/generate (ou /v1/chat/completions, no modo compatível).

Os parâmetros que mais importam no dia a dia:

• temperature: para tarefas empresariais como extração e classificação, mantenha entre 0.1 e 0.3. Valores altos geram criatividade indesejada em documentos jurídicos ou financeiros.
• top_p: deixe em 0.9 como padrão. Só mexa se souber exatamente por quê.
• num_ctx: o tamanho da janela de contexto. O padrão do Ollama é conservador (2048 tokens). Para RAG ou análise de documentos longos, suba para 8192 ou mais, lembrando que contexto maior consome mais VRAM.

Esses parâmetros podem ser fixados em um Modelfile customizado, o que garante que toda a empresa use a mesma configuração. Tutorial completo de Modelfile está no SWEN, para quem quiser se aprofundar.

Expondo o serviço na rede

Por padrão, o Ollama escuta apenas em localhost. Para que outras aplicações do servidor ou da rede interna acessem o modelo, configure a variável de ambiente:

OLLAMA_HOST=0.0.0.0:11434

Nunca exponha essa porta diretamente na internet. A API não tem autenticação nativa. Use VPN, firewall ou um proxy reverso com autenticação na frente. Já vi servidor de LLM aberto no provedor de nuvem virando mineradora de cripto em menos de uma semana.

Integrando com suas aplicações

Do ponto de vista das aplicações internas, a integração é uma chamada HTTP comum. Um sistema de helpdesk, por exemplo, pode enviar o ticket do cliente para o endpoint e receber uma classificação automática de urgência. Ferramentas de BI podem usar o modelo para gerar resumos de relatórios. Como o formato é compatível com OpenAI, praticamente qualquer biblioteca moderna de IA funciona sem adaptação significativa.

No próximo tópico, cubro os requisitos de hardware e o dimensionamento correto para produção.

Deploy com vLLM para alta performance

Deploy com vLLM para alta performance

Quando a demanda de inferência passa de "testes pontuais" e entra em cenário de produção, o Ollama começa a mostrar o limite. Ele é ótimo para desenvolvimento, mas foi desenhado para simplicidade, não para throughput. É aí que entra o vLLM, hoje o padrão de facto para servir LLMs on-premise com carga real.

Na minha experiência, a diferença aparece rápido: em um cliente do setor financeiro, migramos o atendimento interno de Ollama para vLLM e o throughput saltou de algo em torno de 30 requisições simultâneas para mais de 200 no mesmo hardware. O motivo está em duas otimizações específicas.

PagedAttention e continuous batching

O PagedAttention trata a memória do KV cache como um sistema de paginação, similar ao que um sistema operacional faz com RAM. Em vez de reservar blocos contíguos e gigantes de memória para cada sequência (o que desperdiça 60 a 80% do espaço alocado), o vLLM divide em blocos pequenos e aloca sob demanda. Resultado: mais contexto útil cabe na mesma GPU, e mais requisições rodam em paralelo.

O continuous batching resolve outro gargalo. No batching tradicional, o servidor espera um grupo de requisições terminar para processar o próximo lote. Com continuous batching, requisições novas entram no processamento assim que qualquer slot libera, sem esperar o grupo inteiro. Em produção, isso significa latência média muito menor sob carga.

Instalação e subida do servidor

A rota mais limpa é via Docker, porque evita conflito de dependências com CUDA. O projeto mantém imagens oficiais no Docker Hub; você roda o container mapeando a GPU, apontando para o modelo e expondo a porta de serviço. Se preferir pip, funciona bem em ambientes controlados, mas atenção à versão do PyTorch e do driver da NVIDIA: já vi deploy quebrarem semanas depois por causa de upgrade silencioso de dependência.

O download do modelo costuma ser feito pelo Hugging Face Hub. Para o DeepSeek, vale rodar a versão quantizada (AWQ ou GPTQ) se sua GPU for limitada em VRAM. Com o modelo em disco, você inicia o servidor indicando o caminho do modelo, o contexto máximo e a fração de memória da GPU que o vLLM pode usar. O comando básico é o vllm serve seguido do identificador do modelo; os parâmetros mais relevantes no dia a dia são max-model-len, gpu-memory-utilization e quantization.

vLLM vs Ollama

Para quem está decidindo onde alocar esforço, o resumo prático:

• Throughput: vLLM supera Ollama em 3 a 10x em cenários com requisições concorrentes, graças ao PagedAttention e ao continuous batching.
• Batching: Ollama processa de forma essencialmente sequencial; vLLM foi construído em torno de batching dinâmico.
• Compatibilidade de API: vLLM expõe endpoints compatíveis com a API da OpenAI, o que significa que qualquer aplicação que hoje chama a OpenAI pode apontar para seu servidor local trocando a URL e a chave. Ollama tem API própria, e a integração exige adaptadores.
• Operação: Ollama ganha em simplicidade. É a ferramenta certa para prototipar; vLLM é a ferramenta certa para escalar.

Uma dica de migração: como o vLLM fala o dialeto OpenAI, integrar com aplicações existentes costuma ser questão de apontar o base_url para o seu servidor interno. Se você usa LangChain, n8n ou qualquer cliente padrão, praticamente não muda nada no código. O tutorial de integração passo a passo está no SWEN.AI, incluindo os ajustes de parâmetros para DeepSeek especificamente.

Meu critério de decisão é simples: se mais de cinco pessoas vão usar o modelo ao mesmo tempo, ou se alguma aplicação crítica depende dele, vá de vLLM desde o início. O Ollama serve bem ao desenvolvedor individual explorando o modelo no laptop, e é isso.

Otimizando performance e gerenciando recursos

Depois de ter o DeepSeek rodando, o trabalho real começa. Um deploy que funciona no teste inicial não significa nada se travar com 50 usuários simultâneos na segunda-feira de manhã. Na minha experiência, é nessa fase que a maioria das empresas erra: implantam com configurações padrão e descobrem os limites em produção, da pior forma possível.

Quantização é o primeiro alavanca de economia. O modelo completo em FP16 consome praticamente o dobro de memória de uma versão quantizada em INT8, com perda de qualidade que na maioria dos casos de uso corporativo é imperceptível. Se suas GPUs são H100 ou mais recentes, FP8 é ainda melhor. Já vi clientes reduzirem o custo de hardware pela metade só com essa decisão, antes de tocar em qualquer outra configuração.

Agora, os parâmetros do vLLM que fazem diferença real:

• gpu-memory-utilization: o padrão é 0.9, mas se você compartilha a GPU com outros serviços, reduza para 0.7-0.8. Reserve margem, senão o OOM aparece no pior momento.
• max-model-len: não deixe no máximo do modelo se suas aplicações usam contextos de 8k tokens. Contexto menor libera memória para mais requisições simultâneas.
• max-batch-size: batch maior melhora throughput, mas aumenta latência individual. Para chatbot interno, batch menor. Para processamento em lote de documentos, batch grande.

Sobre paralelismo: tensor parallelism divide as camadas do modelo entre GPUs, reduzindo latência por requisição. Pipeline parallelism divide o modelo em estágios sequenciais, o que ajuda quando você tem nós em máquinas diferentes. Regra prática que uso: se a latência é o problema, tensor; se o throughput com modelos muito grandes é o problema, pipeline ou a combinação dos dois.

Monitoramento não é opcional. Configure Prometheus coletando métricas do vLLM e Grafana para visualizar antes que alguém pergunte por que o sistema está lento. As métricas que realmente importam: tempo de fila (time-to-first-token), utilização de memória GPU e tokens por segundo por réplica. Quando o time-to-first-token passa de 2 segundos de forma consistente, é sinal de que você precisa de outra réplica, não de mais tuning. Para quem quer comparar o desempenho do DeepSeek quantizado versus full precision antes de decidir, os benchmarks do SWEN.AI ajudam a ter uma referência realista em vez de depender de specs de marketing.

Dimensionar para picos exige um pouco de honestidade sobre seu padrão de uso. Empresas brasileiras tendem a ter picos previsíveis: início do expediente, horário de almoço, fim do dia. Se você usa Kubernetes, o autoscaling baseado em requisições por segundo funciona bem, mas o cold start de carregar o modelo em nova réplica pode levar minutos. Minha recomendação: mantenha uma réplica base dimensionada para o pico mínimo e escale acima disso só quando necessário.

Para reduzir latência em aplicações reais, três coisas que funcionam de verdade: mantenha o prefixo do system prompt estático para aproveitar o caching de prefixo do vLLM (economia enorme quando todos os usuários compartilham o mesmo prompt base); limite a saída máxima de tokens ao mínimo útil; e prefira streaming sempre que a interface permitir, porque percepção de velocidade importa tanto quanto velocidade real.

Nenhuma dessas configurações é permanente. Rode por duas semanas, olhe os gráficos, ajuste. Performance é processo, não projeto.

Segurança e privacidade em deploy on-premise

Quando implantei o primeiro DeepSeek on-premise para um cliente do setor financeiro, a pergunta do CISO não foi sobre custo ou performance. Foi "quem consegue falar com esse modelo?". Essa é a pergunta certa, e a resposta precisa vir antes do deploy, não depois.

O princípio básico: o servidor de inferência nunca deve ficar exposto na internet. Coloque-o atrás de um proxy reverso (Nginx ou Traefik resolvem bem) e, idealmente, em uma rede isolada que só os serviços internos alcançam. Já vi empresas deixarem o vLLM escutando na porta 8000 sem autenticação alguma, porque "é rede interna". Até alguém descobre que é. Mesmo em rede interna, exija autenticação via API keys por serviço ou por equipe. Isso permite rastrear quem chamou o quê, e revogar acesso de um sistema comprometido sem derrubar o resto.

TLS é obrigatório mesmo internamente. Certificados internos via um PKI próprio ou algo como o cert-manager no Kubernetes resolvem sem esforço extra. Tráfego de inferência carrega os dados mais sensíveis da empresa — prompts de funcionários muitas vezes incluem trechos de contratos, dados de clientes, estratégia. Criptografar isso em trânsito não é opcional.

Contêineres com o mínimo de privilégio

Rode o DeepSeek em contêineres com permissões mínimas: usuário não-root, filesystem read-only quando possível, sem capabilities desnecessárias. Prefira imagens assinadas e valide a assinatura no momento do deploy — ferramentas como Cosign e o verificação nativa do Kubernetes com admission controllers fazem isso. A lógica é simples: se alguém consegue trocar a imagem do modelo por uma maliciosa, todo o trabalho de segurança de rede vai por água abaixo.

Controle de acesso vai além do firewall. Defina quais equipes podem acessar quais endpoints, com quotas de uso. Isso evita tanto abuso quanto aquela fila de resposta quando alguém joga um job pesado no modelo sem avisar.

LGPD e dados de inferência

Aqui está uma vantagem real do on-premise: os dados nunca saem da sua infraestrutura. Mas isso não te exime de obrigações. Os logs de inferência costumam armazenar os prompts completos, e prompts contêm dados pessoais. Defina política de retenção — em vários deployments que fiz, configuramos rotação de logs de 30 dias e mascaramento de CPF, e-mails e telefones antes de gravar. Vale mapear com o jurídico quais casos de uso envolvem dados de titulares e se algum exige base legal específica.

Auditoria precisa de logs estruturados, centralizados em algo como Loki ou Elasticsearch, com registro de: quem chamou, de qual IP, qual modelo, quantos tokens e timestamp. Para setores regulados, preserve esses logs por período maior e teste a recuperação — log que ninguém consegue ler durante uma auditoria não vale nada.

Por último, monitore anomalias de acesso. Volume de requisições fora do padrão às 3h da manhã de um fim de semana raramente é bom sinal. Notícias recentes sobre vazamentos em serviços de IA self-hosted no SWEN.AI mostram que a maioria dos incidentes veio de configuração de rede descuidada, não de vulnerabilidade do modelo em si. A boa notícia: essas configurações são padronizáveis. Uma tarde de trabalho bem feito evita o incidente que custa o trimestre.

Monitoramento, logs e manutenção

Deploy não termina quando o serviço sobe. Na minha experiência, é depois da primeira semana de operação que aparecem os problemas reais: memória da GPU fragmentando, latência subindo aos poucos, fila de requisições crescendo sem ninguém perceber. Se você não estava medindo antes, não vai saber o que mudou.

Métricas essenciais: com Prometheus e Grafana você cobre o básico em um dia de trabalho. Colete utilização e memória da GPU (o exporter da NVIDIA resolve isso), CPU, consumo de RAM e, principalmente, throughput e latência por requisição. O que interessa não é a média, é o percentil 95. Se o p95 de latência saltou de 2 para 8 segundos, algo quebrou mesmo que a média pareça aceitável. Quando implantei isso em um cliente de varejo, o alerta de p95 foi o que detectou um problema de concorrência que ninguém tinha notado por semanas.

Logging estruturado: evite logs em texto livre. Padronize o formato (JSON com timestamp, ID da requisição, modelo, tokens de entrada e saída, tempo de resposta) e centralize tudo, seja em Loki, ELK ou até um arquivo bem organizado com rotação. Quando um usuário reclamar que "a resposta veio estranha", você vai precisar encontrar exatamente aquela requisição em segundos, não vasculhar arquivos por horas.

Alertas: configure limite para os sinais que importam: GPU acima de 95% por mais de alguns minutos, erro 5xx em sequência, latência p95 fora da faixa, disco com menos de 15% livre. Errei isso no começo: alerta demais é tão inútil quanto alerta nenhum, porque o time aprende a ignorar. Comece conservador e ajuste com base em falsos positivos.

Atualização do modelo: novas versões do DeepSeek saem com frequência, e vale acompanhar as notícias e benchmarks publicados no SWEN.AI para decidir se a atualização compensa para o seu caso. O processo que uso é simples: nunca substitua o modelo em produção diretamente. Suba a nova versão em paralelo (ou em um segundo container com outra porta), rode um conjunto de testes com prompts representativos do seu negócio, compare qualidade e latência, e só então troque o tráfego. Para fine-tuning, mesmo caminho: versionar o modelo com identificação clara (data, dataset, parâmetros) e validar antes de colocar em produção.

Rollback: mantenha sempre a versão anterior funcional e documentada. Se a troca foi feita por container, o rollback é subir a imagem anterior com o mesmo volume de pesos. Duas regras: a versão anterior não sai do servidor até a nova rodar estável por pelo menos uma semana, e o rollback precisa ser testado antes de você precisar dele de verdade.

Backup: os pesos do modelo são grandes e baixáveis de novo, então o que exige backup de verdade é o resto: configurações do serviço, arquivos de fine-tuning (que representam semanas de trabalho), dataset de treino, e os logs de auditoria que a sua política de segurança exige. Um versionamento simples em Git para configs e storage dedicado para datasets resolve. Vale escrever um runbook de restauração e, idealmente, testá-lo uma vez. Backup que nunca foi restaurado é só esperança.

Considerações finais e próximos passos

Depois de várias semanas rodando DeepSeek em clientes aqui no Brasil, minha conclusão é direta: se sua empresa lida com dados sensíveis (jurídico, saúde, financeiro, tudo que toca a LGPD), o deploy on-premise vale o esforço inicial de instalação. Você troca a conveniência de uma API paga por controle total sobre o modelo, custo previsível por inferência e a tranquilidade de que nenhum documento da empresa sai da sua rede.

No tutorial, cobrimos o caminho essencial: escolha do hardware adequado ao tamanho do modelo, instalação via Ollama ou vLLM, configuração de quantização para caber na sua GPU, e a exposição do modelo via API interna para os sistemas da empresa consumirem. Se ficou alguma dúvida em algum desses passos, o tutorial passo a passo detalhado está no SWEN.AI, com os erros mais comuns de cada etapa.

Com o modelo rodando, os próximos passos naturais são:

• Fine-tuning: ajustar o modelo com dados internos, como pareceres jurídicos ou chamados de suporte. Na minha experiência, um fine-tuning leve em 5 mil documentos de um domínio específico já supera o modelo genérico nessa tarefa.
• Integração com chatbots internos: conectar o DeepSeek ao WhatsApp corporativo, Teams ou Slack. É o caso de uso que mais gera adesão rápida, porque todo mundo usa chat todos os dias.
• Automatização de processos: classificação de e-mails, extração de dados de notas fiscais, resumo de contratos. Comece por um processo repetitivo e volumoso, não pelo mais estratégico.

Em termos de recursos, mantenha três abas abertas: a documentação oficial do DeepSeek no GitHub, o repositório do Ollama ou vLLM que você escolheu, e as comunidades no Reddit (r/LocalLLaMA) e no Discord do Ollama, onde problemas de deploy específicos costumam ter resposta em horas. Quem quiser ir além em fine-tuning e RAG, os cursos e benchmarks comparando versões do DeepSeek estão no SWEN.AI, atualizados com frequência.

Uma recomendação final antes de escalar: rode um piloto. Escolha um departamento, um caso de uso, um modelo pequeno (o DeepSeek 7B já resolve muita coisa) e dois meses de prazo. Meça custo, latência e satisfação dos usuários. Com esses números em mãos, a conversa com o board sobre investimento em GPU deixa de ser aposta e vira business case.

Ficou com dúvida em alguma etapa, ou quer contar como foi seu deploy? Comente aqui embaixo. Casos reais, inclusive os que deram errado, ajudam mais quem está começando do que qualquer tutorial.