DeepSeek V3.2 localmente: MoE 671B acessível aos mortels

#Por que instalar DeepSeek V3.2 localmente

DeepSeek V3.2 é a atualização intermediária publicada pela DeepSeek AI no fim de 2025, sob licença MIT, que introduz duas mudanças significativas em relação à V3: DeepSeek Sparse Attention (DSA), um mecanismo de atenção esparsa que torna o custo de memória de contextos longos subquadrático, e um refinamento do treinamento com previsão de múltiplos tokens. No papel, mantém-se a qualidade da V3 e ganha-se eficiência com 128 mil tokens ou mais.

Instalar localmente atende a três necessidades reais: confidencialidade total (nenhum documento é enviado para DeepSeek), reprodutibilidade (os pesos não desaparecem de um dia para o outro) e experimentação livre (sem limites de taxa, sem filtro de moderação imposto).

#MoE 671B / 37B ativos + DeepSeek Sparse Attention

DeepSeek V3.2 mantém a arquitetura MoE da V3: um roteador seleciona 8 especialistas entre 256 por camada, o que faz trabalhar apenas ~37 bilhões de parâmetros para cada token gerado. Os 634 bilhões restantes dormem, mas devem permanecer acessíveis, caso contrário o roteador perde acesso aos especialistas que não carregou.

Parâmetros totais

≈ 671 bilhões (independentemente da taxa de bits, é essa massa que precisa ser armazenada em algum lugar: RAM, VRAM ou SSD via mmap).

Parâmetros ativos por token

Aproximadamente 37 bilhões. Esse número determina a velocidade teórica: um MoE 671B tem o custo computacional de um modelo denso de 37B.

Especialistas por camada

256 especialistas MoE + 1 especialista compartilhado, roteamento top-8. Quanto mais RAM, mais camadas de especialistas permanecem residentes e mais estável é a geração.

Atenção

Multi-Head Latent Attention (MLA) herdada da V3, agora combinada com DeepSeek Sparse Attention (DSA) em contextos > 32k tokens.

Contexto

128k tokens anunciados, utilizáveis na prática graças ao DSA — o cache KV já não cresce de forma explosiva e linear como em um modelo denso clássico do tipo Qwen 3.5 ou Gemma 4.

#Requisitos de hardware realistas

Nenhuma configuração de hardware para o consumidor comum consegue rodar o DeepSeek V3.2 sem malabarismos. Aqui estão os três perfis realistas em 2026, classificados pelos compromissos entre velocidade e orçamento.

Perfil A — DDR5 robusta (192–384 GB)

Estação de trabalho com Threadripper 7960X / Xeon W ou EPYC 9354P, 256 GB de DDR5 ECC (8 canais), sem necessidade de GPU. Q2_K_XL cabe inteiramente na RAM. Velocidade: 5–9 tok/s usando apenas a CPU.

Perfil B — RTX 5090 + 192 GB DDR5 (recomendado)

O ponto ideal em 2026: RTX 5090 (32 GB GDDR7, largura de banda de 1792 GB/s) + 192 GB DDR5 em uma plataforma recente voltada ao público em geral. Mantemos as camadas de atenção e o especialista compartilhado na GPU, e o restante na RAM. Velocidade: 10–15 tok/s na geração.

Perfil C — RAM modesta + SSD NVMe Gen 4/5

96–128 GB de RAM DDR5 + SSD NVMe de pelo menos 7 GB/s, ≥ 1 TB livre. Os especialistas são mapeados em memória com mmap a partir do SSD. Velocidade: 1,5–3 tok/s — utilizável em processamento em lote noturno, não em uso interativo.

#1. Escolher a quantização para V3.2

O ecossistema GGUF para DeepSeek V3.2 é sustentado por dois atores principais: Unsloth (que publica as variantes UD = "Unsloth Dynamic", entre elas a famosa Q2_K_XL) e bartowski. As variantes UD utilizam uma matriz de importância para preservar as camadas sensíveis (atenção, especialista compartilhado) com uma precisão maior do que o restante — uma diferença prática real na qualidade final.

IQ1_S (~150 GB)

Quantização dinâmica de 1 bit. Cabe em 192 GB de RAM com margem. Qualidade degradada, mas utilizável para conversas gerais. Evitar para código.

Q2_K_XL (~220 GB)

A referência ik_llama / Unsloth Dynamic. Mantém as camadas críticas em Q4-Q5 e comprime os especialistas em Q2. ~95% da qualidade Q4 nos benchmarks de raciocínio. Cabe em 256 GB de RAM ou em 192 GB com um pouco de offload para SSD.

Q3_K_S (~290 GB)

Para workstations de 384 GB. Qualidade quase Q4 em contextos longos. Recomendado se você planeja usar seriamente os 128k tokens.

Q4_K_M (~400 GB)

A todo vapor. Reservado para servidores EPYC com dois soquetes e 512 GB ou mais de memória DDR5. Além disso, o ganho de qualidade se torna marginal para uso local.

#2. Compilar ik_llama.cpp (o fork que oferece suporte ao V3.2)

No momento em que estas linhas foram escritas, a branch principal de ggerganov/llama.cpp oferece suporte ao DeepSeek V3.2, mas sem otimizações específicas para o roteamento MoE do DeepSeek. O fork ik_llama.cpp (Iwan Kawrakow) inclui kernels CUDA acelerados para os tensores dos especialistas e suporte dinâmico ao DSA — ganho de 30 a 50% na taxa de geração do V3.2, conforme a configuração.

git clone https://github.com/ikawrakow/ik_llama.cpp
cd ik_llama.cpp
cmake -B build \
  -DGGML_CUDA=ON \
  -DGGML_CUDA_FA_ALL_QUANTS=ON \
  -DGGML_CUDA_F16=ON
cmake --build build --config Release -j $(nproc)

No Mac Apple Silicon, substituir GGML_CUDA por GGML_METAL. Em hardware AMD, GGML_HIP com ROCm 6.3+. Conte com 10 a 15 minutos de compilação em uma máquina recente — é C++ com geração CUDA; não execute isso em um laptop sem estar conectado à tomada.

#3. Baixar os GGUF V3.2

Os pesos GGUF de DeepSeek V3.2 estão publicados no Hugging Face. Para Q2_K_XL Unsloth (a opção recomendada para a maioria das configurações), apenas um download de ~220 GB dividido em vários arquivos.

pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/DeepSeek-V3.2-GGUF \
  --include "*UD-Q2_K_XL*" \
  --local-dir ./models/deepseek-v32-q2kxl

O download leva várias horas em uma conexão comum — conte com uma conexão de fibra óptica estável e um disco de destino com pelo menos 250 GB livres. Os GGUF desse tamanho são divididos em 5 a 7 arquivos (split-00001-of-N.gguf), e o ik_llama.cpp detecta automaticamente as partes se você apontar para a primeira.

#4. Execução com --override-tensor (a chave para o desempenho híbrido)

O segredo de uma boa instalação local do DeepSeek V3.2 está em uma opção: --override-tensor (alias -ot). Ela permite selecionar, por regex, quais camadas permanecem na CPU/RAM e quais vão para a GPU. Em um modelo MoE, queremos evitar a todo custo carregar tudo na GPU (a VRAM nunca será suficiente), mas fazemos questão de que a atenção e as camadas compartilhadas sejam aceleradas.

./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_(up|down|gate)_exps\.=CPU" \
  --threads 16 \
  --flash-attn \
  --host 0.0.0.0 --port 8080

A expressão regular \.ffn_(up|down|gate)_exps\. seleciona os três tensores FFN por especialista — ou seja, a esmagadora maioria dos 671B parâmetros — e os força a permanecer na CPU. O que vai para a GPU: atenção (MLA), especialista compartilhado, embeddings, head. Em uma RTX 5090 de 32 GB, o consumo é de ~22 GB de VRAM; o restante é usado para o cache KV.

./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 32 \
  --flash-attn \
  --host 0.0.0.0 --port 8080

#5. Tokens/segundo medidos em uma workstation doméstica

Valores de referência medidos com a build de maio de 2026 do ik_llama.cpp, Q2_K_XL, contexto de 32k e prompt misto de francês e código. Os números permanecem estáveis dentro de uma variação de ±15 %, dependendo do prompt e do aquecimento das páginas de memória.

RTX 5090 + Ryzen 9 7950X3D + 192 GB DDR5-6000

Prefill ~110 tok/s, geração 12–15 tok/s. Configuração recomendada para casa em 2026.

RTX 4090 + Threadripper 7960X + 256 GB DDR5 ECC

Prefill ~90 tok/s, geração 9–12 tok/s. A 4090 fica empatada com a 5090 nesse perfil híbrido porque o gargalo está na RAM, não na GPU.

EPYC 9354P + 384 GB DDR5 ECC (12 canais), sem GPU

Prefill ~70 tok/s, geração 7–9 tok/s. A largura de banda total da memória (~460 GB/s) compensa a ausência de GPU.

Mac Studio M3 Ultra 192 GB

Prefill ~55 tok/s, geração 6–8 tok/s em Q2_K_XL. A memória unificada (~820 GB/s) salva a situação.

Ryzen 9 7950X + 128 GB DDR5 + SSD Samsung 990 Pro

Prefill ~25 tok/s, geração 1,5–2,5 tok/s. Honestamente, utilizável apenas em lote.

#DeepSeek V3.2 vs DeepSeek R1: qual instalar?

Pergunta recorrente, porque os dois modelos compartilham a mesma arquitetura MoE 671B / 37B ativos e a mesma licença MIT. A diferença está no pós-treinamento, não na estrutura.

DeepSeek V3.2

Modelo generalista (chat), com respostas diretas. Excelente em francês, muito sólido em programação. Adiciona DSA para contextos longos. Dar preferência a ele para assistência no dia a dia, síntese e redação.

DeepSeek R1

Modelo de raciocínio (cadeia de pensamento explícita no estilo o1). Emite muitos tokens internos (<think>...</think>) antes da resposta final. Preferível para matemática, lógica e depuração de algoritmos complexos.

Custo de inferência

R1 gera de 3 a 10 vezes mais tokens (devido ao thinking) para produzir a mesma resposta final. Com a mesma taxa de geração, R1 leva 5 minutos enquanto V3.2 leva 30 segundos. Isso é crítico na execução local, onde cada tok/s conta.

Contexto longo

Graças ao DSA, o V3.2 suporta 128k tokens com um cache KV de tamanho razoável. O R1 não tem DSA, e seu consumo de memória dispara acima de 64k.

VRAM/RAM necessária

A mesma. Os dois modelos compartilham a arquitetura 671B/37B e cabem na mesma quantização Q2_K_XL de aproximadamente 220 GB.

#Solução de problemas

« unknown model architecture: deepseek2 »

Seu llama.cpp está desatualizado ou foi compilado sem suporte a deepseek2. Atualize o ik_llama.cpp (branch main posterior a abril de 2026) e recompile. O binário pré-compilado padrão nem sempre é suficiente.

OOM CUDA já no carregamento

Seu regex -ot não gera suficientes especialistas no CPU. Verifique o estilo ollama-style com ik_llama-bench a distribuição real dos tensores. O regex correto para a V3.2 alinha bem ffn_(up|down|gate)_exps, não apenas ffn_exps.

Geração a 1 tok/s com 192 GB de RAM

O kernel fará a paginação a partir do GGUF enquanto não tiver carregado todas as páginas quentes. Um primeiro prompt de aquecimento de 200 tokens pré-carrega os especialistas. Caso contrário, aumente --threads até o número de núcleos físicos (não lógicos).

Respostas que mudam para chinês sem razão

Template de chat incorreto. Verifique se --chat-template está no modo auto e se o GGUF inclui o template Jinja do DeepSeek. Caso contrário, use --chat-template deepseek3 explicitamente.

DSA parece inativo (cache KV linear)

DSA está ativado apenas a partir de um comprimento de contexto mínimo (configurável). Para contextos < 16k, o modelo utiliza atenção densa clássica — é esperado e não afeta a qualidade.

Crash com prompt longo após warmup

Você provavelmente já saturou a swap. DeepSeek V3.2 não gosta de swap: se a RAM física não for suficiente, desative a swap (sudo swapoff -a) e deixe o llama.cpp gerenciar a paginação via mmap, isso é mais rápido e mais estável.

#Para se aprofundar

Executar o DeepSeek V3.2 localmente é um ponto de partida para explorar a categoria de “modelos de fronteira que podem ser auto-hospedados”. Três caminhos complementares:

Otimizar o build do llama.cpp

O guia "Compilar llama.cpp com CUDA" detalha os flags avançados (Flash Attention, MMQ, offload tensors) que realmente alteram o desempenho em modelos MoE.

Entender as quantizações modernas

O guia "Escolher a quantização (Q4, Q5, Q8, FP16)" explica por que Q2_K_XL funciona onde o Q2 clássico falha e quando passar para Q3/Q4.

Ir um passo além em tamanho

O guia "Kimi K2 local" aplica o mesmo método a um modelo MoE com 1T de parâmetros — útil para antecipar onde o ecossistema irá em 2026-2027.