Existe uma diferença prática entre um modelo que responde rápido e um modelo que "pensa antes de responder". O DeepSeek-R1 é a referência aberta desse segundo tipo: um modelo de raciocínio treinado com Reinforcement Learning em larga escala, publicado sob licença MIT, com destilações pequenas o bastante para caber em uma GPU de consumo. A parte que costuma passar batido é que o modelo de referência (671B de parâmetros) e as versões que rodam no seu notebook (1,5B a 70B) não são a mesma coisa disfarçada de tamanhos diferentes — são famílias de modelo com trade-offs distintos, e confundir as duas é a causa mais comum de expectativa errada sobre o que dá para rodar localmente.
O que muda em um modelo "de raciocínio"?
A maioria dos modelos de linguagem gera a resposta token a token, sem um espaço explícito para revisar o próprio caminho. Modelos de raciocínio como o R1 são treinados para produzir uma cadeia de pensamento antes da resposta final — o modelo escreve etapas intermediárias, testa hipóteses, às vezes se corrige no meio do processo, e só então converge no resultado. Esse padrão de "pensar em voz alta" já existia como técnica de prompt (chain-of-thought), mas o R1 é treinado para fazer isso nativamente, sem precisar que o usuário peça.
O diferencial, descrito no paper técnico oficial, está em como esse comportamento foi ensinado — e aqui vale separar dois modelos que o repositório trata como coisas distintas. O DeepSeek-R1-Zero foi treinado por Reinforcement Learning em larga escala sem fine-tuning supervisionado como etapa preliminar: ele não aprendeu a imitar cadeias de raciocínio escritas por humanos, foi recompensado por chegar a respostas corretas em tarefas verificáveis (matemática, código), e o raciocínio passo a passo emergiu como estratégia para maximizar essa recompensa. Foi a primeira demonstração aberta de que essa capacidade pode ser incentivada por reforço puro. O R1 que você baixa é a etapa seguinte: para corrigir os defeitos do R1-Zero — repetição sem fim, legibilidade ruim, mistura de idiomas — a DeepSeek acrescentou dados de cold-start antes do RL, num pipeline que combina duas etapas de reforço e duas de fine-tuning supervisionado. Ou seja: o raciocínio nasceu de reforço puro, mas o modelo distribuído passou por supervisão para virar utilizável.
MoE de 671B: o que significa "37B ativados por token"
O R1 completo usa uma arquitetura Mixture-of-Experts (MoE): em vez de um único bloco denso de parâmetros processando cada token, o modelo é dividido em múltiplos "especialistas", e um mecanismo de roteamento decide quais especialistas ativar para cada token específico. O repositório oficial no GitHub confirma os números: 671B de parâmetros totais, mas apenas 37B ativados por token processado.
Essa distinção importa porque os dois números respondem perguntas diferentes:
| Métrica | Valor | O que determina |
|---|---|---|
| Parâmetros totais (671B) | Capacidade armazenada | Quanto de memória o modelo completo ocupa em disco/VRAM |
| Parâmetros ativados por token (37B) | Custo de inferência | Quanto de computação cada token gerado exige |
Um modelo denso de 37B custaria, por token, o mesmo que o R1 completo custa — mas teria muito menos capacidade armazenada porque não tem a "biblioteca" de especialistas para escolher. É esse desenho que permite ao R1 ter qualidade de modelo grande com custo de inferência mais próximo de um modelo médio. O preço é que rodar o modelo completo ainda exige carregar os 671B de parâmetros em memória — daí a necessidade de cluster de GPU de nível empresa para a versão original.

Destilação: como o raciocínio cabe em 7B
A peça que torna o R1 relevante para quem não tem cluster é a destilação. A DeepSeek pegou o comportamento de raciocínio do modelo de 671B e usou como sinal de treino para modelos bem menores — baseados nas arquiteturas Qwen2.5 e Llama —, gerando uma família de destilações oficiais publicadas pela DeepSeek e linkadas no repositório oficial: 1,5B, 7B, 8B, 14B, 32B e 70B.
Destilação, nesse contexto, não é "comprimir" o modelo grande. É fazer fine-tuning de um modelo aberto menor, já existente, usando amostras geradas pelo modelo grande como material de treino — transferindo padrão de comportamento sem transferir os 671B de parâmetros. O resultado herda parte da capacidade de raciocínio estruturado do modelo original, mas com o custo computacional de um modelo do tamanho declarado — não do R1 completo.
Isso explica por que uma destilação de 7B roda em uma GPU de 8GB e ainda assim mostra passos de raciocínio visíveis na resposta, algo que modelos de 7B convencionais (sem esse treino específico) normalmente não fazem de forma consistente.
Onde rodar: Ollama para uso individual, vLLM para servir gente
Os dois caminhos resolvem problemas diferentes, e escolher errado custa tempo de configuração sem ganho real.
Ollama é a rota para rodar uma destilação do R1 na própria máquina, sem infraestrutura de servidor. O comando ollama pull deepseek-r1:7b baixa o modelo em formato GGUF já quantizado e o disponibiliza via CLI e API HTTP local. É o caminho certo para desenvolvimento, teste de prompt, uso individual ou um agente rodando em uma única máquina — o guia completo de Ollama cobre requisitos de hardware por tamanho de modelo.
vLLM é a rota para servir o modelo como serviço, atendendo múltiplas requisições simultâneas com throughput alto. O diferencial técnico, segundo o repositório oficial, é o PagedAttention — um mecanismo de gerenciamento de memória para o cache de atenção (KV cache) inspirado em paginação de sistemas operacionais, que reduz desperdício de memória e permite servir mais requisições em paralelo com o mesmo hardware. É licenciado sob Apache-2.0 e é o motor por trás de boa parte dos deployments de LLM open source em produção.
| Critério | Ollama | vLLM |
|---|---|---|
| Público-alvo | Desenvolvedor individual, uso local | Serviço com múltiplos usuários concorrentes |
| Setup | Um binário, um comando | Requer GPU dedicada e configuração de serving |
| Formato de modelo | GGUF quantizado | Pesos originais (safetensors), com quantização configurável |
| Ponto forte | Fricção mínima para começar | Throughput e uso eficiente de memória em escala |
| Cenário típico | Testar um modelo, rodar um agente pessoal | API interna servindo um time ou produto |
Não existe "melhor" absoluto — existe o caminho certo para o volume de requisições que você precisa atender. Testar uma destilação do R1 em Ollama antes de decidir investir em uma infraestrutura vLLM é o fluxo de trabalho mais comum, e o mais barato para validar se o raciocínio do modelo resolve o seu caso antes de comprometer hardware de servidor.

Qual destilação escolher
A pergunta prática é sempre "qual tamanho cabe no meu hardware e ainda resolve o problema". Como ponto de partida por VRAM disponível:
| Destilação | Base | VRAM recomendada | Cenário típico |
|---|---|---|---|
| 1,5B | Qwen2.5-Math-1.5B | 2-4 GB | Teste rápido, hardware muito limitado |
| 7B | Qwen2.5-Math-7B | 8 GB | Notebook comum, uso individual diário |
| 8B | Llama-3.1-8B | 8 GB | Notebook comum, uso individual diário |
| 14B | Qwen2.5-14B | 12-16 GB | GPU de consumo dedicada (RTX 4060 Ti 16GB e acima) |
| 32B | Qwen2.5-32B | 24 GB+ | Workstation com GPU de ponta ou Mac com memória unificada alta |
| 70B | Llama-3.3-70B-Instruct | 48 GB+ ou multi-GPU | Servidor dedicado, próximo ao teto de qualidade das destilações |
As destilações de 1,5B e 7B partem de um checkpoint especializado em matemática (Qwen2.5-Math), não de um Qwen2.5 generalista — vale considerar isso antes de escalar o 7B para uso individual diário fora de tarefas matemáticas ou de código.
A regra prática: comece pela menor destilação que roda no seu hardware, valide se o raciocínio resolve a tarefa (matemática, lógica, código estruturado), e só suba de tamanho se a qualidade não for suficiente. Subir de tamanho sem medir qualidade primeiro é o erro mais comum — muita tarefa simples (classificação, extração, resumo curto) não precisa de raciocínio profundo, e um modelo convencional menor resolve mais rápido e mais barato.
Quando o raciocínio explícito compensa — e quando atrapalha
Cadeia de raciocínio visível tem um custo real: o modelo gera muito mais tokens antes de chegar na resposta final, o que significa mais tempo de geração e mais custo computacional por resposta. Vale a pena nas tarefas onde o caminho até a resposta é o que garante a resposta certa:
Compensa: matemática com múltiplos passos, depuração de código com lógica não óbvia, problemas de lógica com restrições, planejamento de tarefas com dependências.
Não compensa: resposta factual direta, classificação de texto, extração de campos estruturados, resumo — tarefas onde o modelo não precisa "pensar em voz alta" para acertar, e o tempo extra de geração só atrasa a resposta sem ganho de qualidade.
Misturar as duas coisas no mesmo pipeline — usar um modelo de raciocínio para toda chamada, inclusive as triviais — é a forma mais comum de tornar um sistema mais lento sem ganho perceptível. Vale reservar o R1 (ou suas destilações) para os pontos do fluxo onde o raciocínio de fato muda o resultado.
Limitações reais
Ser direto sobre isso evita decisão de arquitetura baseada em expectativa errada:
A destilação não é o modelo completo. Uma destilação de 7B ou 14B herda parte do comportamento de raciocínio do R1 de 671B, mas não a capacidade bruta do modelo original. Em tarefas de raciocínio muito complexo, a diferença de qualidade entre a destilação e o modelo completo (ou entre a destilação e um modelo de fronteira proprietário) ainda é perceptível.
Latência é maior por design. A cadeia de pensamento explícita significa mais tokens gerados antes da resposta final, o que se traduz em mais tempo de espera — um trade-off inerente ao formato, não um bug a ser corrigido.
Servir em produção exige mais do que "rodar o modelo". Tanto Ollama quanto vLLM resolvem a inferência; fila de requisições, observabilidade, redundância e dimensionamento de hardware para o volume esperado são camadas que precisam ser construídas por fora, como em qualquer serviço de produção.
Perguntas Frequentes
DeepSeek-R1 é realmente gratuito para uso comercial?
Depende do tamanho. O código do repositório e os pesos do DeepSeek-R1 estão sob licença MIT, que autoriza uso comercial, modificação e trabalhos derivados. As destilações, porém, herdam a licença do modelo-base: as quatro baseadas em Qwen2.5 (1,5B, 7B, 14B e 32B) são originalmente Apache 2.0; a Distill-Llama-8B segue a licença Llama 3.1 e a Distill-Llama-70B a licença Llama 3.3, ambas com restrições de uso que a MIT não tem. Antes de embarcar uma destilação em produto, confira a licença do tamanho escolhido na seção License do repositório oficial.
Preciso de GPU para rodar uma destilação do R1?
Não é obrigatório, mas faz diferença grande de velocidade. As destilações menores (1,5B, 7B) rodam em CPU para teste, mas a geração de texto — já naturalmente mais longa por causa da cadeia de raciocínio — fica bem mais lenta sem GPU dedicada ou memória unificada (Apple Silicon).
Dá para rodar o DeepSeek-R1 completo (671B) localmente?
Na prática, não em hardware de consumo. O modelo completo exige carregar 671B de parâmetros em memória, o que demanda cluster de GPUs de nível empresa. Para uso local, as destilações de 1,5B a 70B são o caminho viável.
Vale a pena usar vLLM em vez de Ollama para poucos usuários?
Geralmente não. O ganho do vLLM (PagedAttention, throughput em paralelo) só compensa a complexidade adicional de setup quando há volume real de requisições concorrentes. Para um time pequeno ou uso individual, o Ollama resolve com muito menos fricção.
O DeepSeek-R1 substitui modelos como GPT ou Claude?
Depende da tarefa. Em benchmarks de raciocínio matemático e código, o R1 é competitivo com modelos de fronteira proprietários nesses domínios específicos — mas isso não significa paridade geral. Para decisões de arquitetura, o ponto de partida é testar o modelo na sua tarefa real, não em benchmark genérico.
Conclusão
O DeepSeek-R1 provou dois pontos ao mesmo tempo: que raciocínio explícito e verificável pode ser incentivado por reforço — o R1-Zero chegou lá sem nenhum fine-tuning supervisionado preliminar —, e que esse comportamento pode ser destilado em modelos pequenos o bastante para rodar fora de um data center. Isso não elimina o trade-off entre modelo completo e destilação, nem torna raciocínio explícito grátis em termos de latência — mas move a régua do que é possível rodar localmente, com controle total sobre os dados, sem depender de uma API externa.
Se a sua empresa está avaliando onde rodar modelos de raciocínio — local, em nuvem ou em arquitetura híbrida — a MaxVision ajuda a desenhar essa decisão considerando custo de inferência, latência aceitável e o volume real de requisições concorrentes. Fale com a nossa equipe.