DS4 / DwarfStar
As lições anteriores deram o vocabulário — MoE, memória unificada, quantização, KV cache. O DS4 é onde tudo isso vira um binário que roda. Não é mais um carregador genérico de GGUF: é um engine nativo em C escrito por antirez com um único alvo em mente — rodar o DeepSeek-V4 num Mac. Esta lição abre a caixa: a arquitetura, o build que já provamos neste Mac, o streaming de SSD que dissolve o limite de RAM, e como ligar um cliente.
Esta lição destila o README + MODEL_CARD do DS4 (hf.co/antirez/deepseek-v4-gguf) e o ensaio news/165 — mais o build real neste M5 Max. Por que importa pra missão: é o motor que coloca um modelo de fronteira a rodar local, exatamente o cérebro que o Alembic quer rodar neste Mac sem mandar nada pra nuvem.
- Explicar a tese central do DS4 — um engine focado em UMA família de modelos em vez de muitos — e por que isso vence engines genéricos para o DeepSeek-V4.
- Descrever a pilha em 5 camadas (GGUF assimétrico → núcleo C/Metal → KV híbrido RAM+disco → ds4-server → clientes) e desenhar o caminho de um token entre elas.
- Escolher o quant correto para uma RAM dada (q2 / q2-q4 / q4 / pro-q2) e prever, antes do download, se cabe.
- Explicar o streaming de SSD em termos de cache-hit/miss e estimar como mais RAM se traduz em mais tokens por segundo.
make (Metal)01 · O que é o DS4 — e por que ele é diferente
O DS4 — apelidado de "DwarfStar" — é um engine de inferência pequeno, nativo e autocontido, escrito em C. Ele não tenta rodar qualquer modelo: foi otimizado primeiro para o DeepSeek-V4-Flash (284 B de parâmetros totais, 13 B ativos por token, contexto de 1M). A variante Pro (1,6 T totais / 49 B ativos) existe para máquinas de memória gigante. Pense nele como um motor de corrida construído para uma pista — não um carro de passeio que vai a qualquer lugar.
A diferença em relação a um llama.cpp da vida é o foco: em vez de suportar centenas de arquiteturas, o DS4 conhece uma família a fundo e gasta toda a engenharia nela — quantização sob medida (seção 02), streaming de SSD desenhado para o MoE (seção 04) e um servidor que já fala os protocolos comerciais (seção 05). É o que permite a um modelo de 284 B parecer de fronteira num laptop.
É a primeira vez que uso um modelo local para coisa séria que eu normalmente pediria pro Claude ou pro GPT... o DS4 é muito mais B [fronteira] do que A [modelo local pequeno].— antirez, antirez.com/news/165
A leitura de antirez (news/165): pela primeira vez um modelo que roda local fica perto do território de Claude/GPT — não no "brinquedo" da esquerda. O DS4 existe para colocar esse ponto no laptop.
01b · DS4 vs llama.cpp — a aposta estreita
A melhor forma de entender o DS4 é contrastá-lo com o carregador genérico que todo mundo conhece. Não é "melhor" em abstrato — é uma troca deliberada: ele abre mão da generalidade para ganhar profundidade numa família só. (O próprio README agradece ao llama.cpp: o DS4 herda formatos GGUF, kernels e tabelas de quant daquele ecossistema.)
llama.cpp (genérico) × DS4 (uma família)A aposta do DS4: "um modelo de cada vez, validação por vetores oficiais, e integração de agente suficiente para saber se funciona de verdade" (README). Largura é do llama.cpp; profundidade vertical é do DS4.
| Dimensão | llama.cpp (genérico) | DS4 / DwarfStar |
|---|---|---|
| Modelos suportados | Centenas de arquiteturas | Só os GGUF do DeepSeek-V4 deste projeto |
| Quantização | Formatos genéricos (Q2_K…Q8) | Assimétrica sob medida: experts em 2-bit, resto em Q8 |
| KV cache | Tipicamente residente na RAM | "Cidadão de disco de 1ª classe" (RAM + SSD) |
| RAM < modelo | Geralmente "não cabe" | SSD streaming: vira espectro de velocidade |
| Validação | Genérica | Logits batem com a impl. oficial em vários ctx |
| Agente | Externo | ds4-agent nativo, sem fronteira de socket |
Repare que metade da tabela são coisas que só fazem sentido quando você fixa o modelo: o quant assimétrico, o streaming do MoE e o agente vertical dependem de conhecer a arquitetura exata. É o preço e o prêmio da aposta estreita.
Um modelo de 284 bilhões de parâmetros em FP16 (16 bits) ocuparia ~568 GB. Quantizado para 2 bits ingênuos, a conta limpa dá ~71 GB. Quanto pesa o GGUF q2 real do DS4 em disco? (Dica: ele não esmaga tudo em 2 bits.)
02 · A arquitetura do engine
O DS4 é uma pilha curta e direta: um GGUF com quantização assimétrica no disco, um núcleo C com kernels Metal que faz a matemática, um KV cache que vive entre RAM e disco, e um servidor que fala os protocolos das APIs comerciais. Os clientes (Claude Code, Codex, seu app) nem percebem que estão falando com algo local. Veja a pilha se montar, camada por camada:
O GGUF assimétrico (1) alimenta o núcleo C com kernels Metal (2); o KV cache (3) vive entre RAM e disco; o ds4-server (4) expõe quatro famílias de API e os clientes (5) falam o protocolo que já conhecem.
A quantização assimétrica 2/8-bit
Aqui está a sacada que faz 284 B caber em 81 GB sem virar lixo. O DS4 não quantiza tudo no mesmo nível. Os especialistas roteados — a maior parte dos parâmetros, mas só um punhado ativo por token — vão para 2-bit. Todo o resto (atenção, embeddings, roteador, camadas densas) fica em Q8. A precisão é gasta onde importa para a fidelidade, e a economia é feita onde há volume. É a tese da Lição 04 aplicada com bisturi, não com martelo.
Os quants de 2-bit não são brincadeira; ele chama ferramentas de forma confiável.— antirez, DS4 MODEL_CARD
git clone && make compilou 5 binários Metal — ds4, ds4-server, ds4-bench, ds4-eval e ds4-agent — com exit 0, e os binários rodam. Não é "deve compilar": compilou e executou.02b · O fluxo de um token, do prompt ao próximo token
Camadas empilhadas é o mapa estático. Agora siga um token pelo engine — é aqui que MoE, atenção comprimida e streaming aparecem em movimento. Cada token novo refaz este caminho. Repare no losango de decisão: é o ponto onde o roteador escolhe os experts, e onde o streaming de SSD pode ou não custar um acesso a disco.
As caixas verdes/Q8 (embeddings, projeções) estão sempre na RAM. O custo variável está no losango: um HIT não toca o disco; um MISS sobe o expert do SSD. Como cada token re-roteia, a geração é mais sensível a misses que o prefill — exatamente o que diz o README.
Por que 1M de contexto cabe: atenção comprimida (CSA + HCA)
A pergunta óbvia: como um modelo expõe 1 milhão de tokens de contexto sem um KV cache gigante para cada token em cada camada? A resposta está no design de atenção do DeepSeek-V4, que o DS4 implementa fielmente. Cada camada guarda uma janela crua dos últimos 128 tokens (alta resolução, recente) e, além dela, linhas comprimidas no eixo do tempo — várias posições agrupadas numa só linha de KV.
Depois das 2 primeiras, o modelo alterna ratio-4 e ratio-128. Comprimir no eixo do tempo (várias posições → 1 linha) é o que troca "KV por token" por "KV por janela", e é por isso que 1M tokens deixa de exigir um cache linear gigante. Fonte: DS4 MODEL_CARD (CSA+HCA, 43 camadas, top-k 512).
03 · Quanto baixar — escolha pela sua RAM
O download não é tamanho único. Cada quant casa com uma faixa de memória: quanto mais RAM, mais experts cabem residentes e maior a qualidade que você pode pagar (a seção 04 explica o porquê). Todos vêm de hf.co/antirez/deepseek-v4-gguf. Escolha o alvo de download e arraste a RAM — o painel diz, ao vivo, se cabe:
Escala: 0–512 GB. A barra é o tamanho do download em disco (≈ a memória que os pesos pedem); a linha vermelha é a RAM da máquina. A regra é simples: verde quando o download fica abaixo da RAM. Num M5 Max de 128 GB, o q2 (81) cabe com folga e o q2-q4 (98) cabe apertado; q4 e pro-q2 pedem máquinas maiores.
| Alvo de download | Disco ≈ | Classe de RAM | Variante |
|---|---|---|---|
| q2-imatrix | 81 GB | Macs de 96 / 128 GB | V4-Flash |
| q2-q4-imatrix | 98 GB | 128 GB (mais qualidade) | V4-Flash |
| q4-imatrix | 153 GB | ≥ 256 GB | V4-Flash |
| pro-q2 | 430 GB | 512 GB | V4-Pro |
Todos de hf.co/antirez/deepseek-v4-gguf. O q2-imatrix é o ponto de entrada para os Macs de coding/agente — é o que cabe nos 128 GB com folga e o que vamos servir na seção 05. O streaming de SSD (abaixo) suaviza as bordas, mas a tabela é o ponto de partida.
03b · Conta na ponta do lápis — de onde saem os 81 GB
A tabela diz "81 GB"; aqui está por que. O quant de 2-bit do DS4 é cirúrgico: ele só comprime os experts roteados do MoE — que são a maioria do espaço do modelo — e ainda assim em dois níveis: up/gate em IQ2_XXS e down em Q2_K. Todo o resto (experts compartilhados, projeções, roteamento) fica intacto em Q8. Veja a divisão real:
q2-q4 mantém as últimas 6 camadas em q4 e dá 98 GB. Quantos GB a mais que o q2 puro? (98 − 81 = 17 GB — o preço de mais qualidade nas camadas finais, ainda dentro de 128.)E quando o modelo NÃO cabe? O orçamento de cache de experts
Aqui mora a alavanca prática do streaming (seção 04). Quando você liga --ssd-streaming, os pesos não-roteados ficam residentes e o resto da RAM vira um cache de experts. O orçamento automático do DS4 faz a conta sozinho: pega 80% do working set recomendado pelo Metal, subtrai os pesos não-roteados, e o que sobra vira cache de experts. Arraste a RAM e veja o orçamento se formar (no M5 Max de 128 GB, o automático escolheu ~59 GB — número medido no README):
Conta do orçamento automático: cache = 0,8 × workingset − não-roteados. Mais RAM ⇒ mais cache ⇒ mais experts residentes ⇒ menos cache-miss. Os pesos não-roteados (~22 GB aqui) são fixos; tudo acima deles dentro dos 80% é cache. Estimativa ilustrativa da fórmula do README; o automático no M5 Max real selecionou ~59 GB.
04 · Streaming de SSD: a RAM vira um espectro
Este é o mecanismo mais original do DS4. Em vez de tratar a RAM como um corte rígido — "cabe ou não cabe" — o DS4 trata o SSD como uma extensão contínua. Os pesos não-roteados (atenção, roteador, densas) ficam residentes na memória. Os especialistas roteados são lidos do GGUF sob demanda: quando o roteador pede um especialista que não está no cache, ele é trazido do SSD (cache-miss). E o KV cache é, nas palavras de antirez, "um cidadão de disco de primeira classe".
Pesos não-roteados ficam fixos na RAM; os experts quentes vivem num cache; um expert frio (E88) é trazido do SSD só quando o roteador o pede. Mais RAM = mais experts cabem residentes = menos misses = mais rápido — um espectro, não um corte.
O KV cache é um cidadão de disco de primeira classe. O streaming de SSD transforma a RAM disponível de um corte rígido num espectro contínuo de níveis de velocidade.— antirez, DS4 README
É isso que reconcilia a tabela da seção 03 com a vida real: o q4 (153 GB) "não cabe" num corte rígido de 128 GB, mas com streaming a borda fica macia — os experts mais frios apenas custam um pouco de latência quando são chamados. A RAM deixa de ser um sim/não e vira um botão de velocidade.
04b · Cache-hit → velocidade (e prefill ≠ geração)
O streaming não é grátis: cada cache-miss paga uma leitura de SSD. Mas há uma assimetria importante que o README destaca — o prefill (ler o prompt) tolera misses muito melhor que a geração (produzir tokens), porque cada token novo re-roteia pelos experts. Daí a regra: contexto longo entra rápido; é a geração token-a-token que sente o disco.
No mesmo Mac e no mesmo ponto de contexto, o prefill é ~18× mais rápido que a geração — porque o prefill amortiza o custo dos experts num lote, e a geração paga a cada token. (Números do benchmark do README, q2, M5 Max 128 GB.)
Comparativo: o mesmo q2, em três máquinas
O DS4 publica números reais de velocidade. Compare o nosso M5 Max com o M3 Max anterior e com um Mac Studio M3 Ultra — tudo no mesmo quant (q2), prompt curto, decode guloso. É a prova de que "mais banda/mais máquina = mais tok/s" (a tese da Lição 03):
| Máquina (q2, prompt curto) | Prefill | Geração |
|---|---|---|
| MacBook Pro M3 Max, 128 GB | 58,52 t/s | 26,68 t/s |
| MacBook Pro M5 Max, 128 GB | 87,25 t/s | 34,27 t/s |
| Mac Studio M3 Ultra, 512 GB | 84,43 t/s | 36,86 t/s |
Sinta o efeito: taxa de acerto → tok/s efetivo
Modelo mental simples: se um cache-hit gera a 34 t/s (o número do M5 Max) e um miss custa uma leitura de SSD, então o tok/s efetivo da geração depende de quantos tokens acertam o cache. Mais RAM ⇒ mais experts residentes ⇒ taxa de acerto maior. Arraste a taxa de acerto e veja:
Modelo ilustrativo (hit ≈ 34 t/s; miss ≈ 6 t/s, dominado pela leitura de SSD): tok/s ≈ hit% × 34 + (1−hit%) × 6. A lição é qualitativa e bate com o README — a geração despenca quando a taxa de miss sobe; o prefill aguenta melhor. [uncertain]: o "~6 t/s de miss" é um valor didático, não medido.
05 · Do clone ao cliente: o fluxo
Quatro passos te levam de zero a um endpoint local servindo. Os dois primeiros — clone e make — já estão provados neste Mac. Os outros dois dependem só de disco e de apontar o cliente. Repare no badge verde de prova nas duas primeiras caixas:
O comando, na prática
# 1+2 — clone e build (provado neste Mac: 5 binários Metal, exit 0) git clone <repo-do-ds4> && cd ds4 && make # → ds4 ds4-server ds4-bench ds4-eval ds4-agent # 3 — baixar o quant que cabe nos 128 GB (≈ 81 GB) ./download_model.sh q2-imatrix # 4 — servir (NUNCA make cpu no macOS: kernel panic; Metal é o default) ./ds4-server # OpenAI + Anthropic + Responses + completions em 127.0.0.1:8000 # 5 — plugar um cliente (ex.: chamada Anthropic-compatível) curl -s 127.0.0.1:8000/v1/messages -d '{"model":"deepseek-v4-flash","messages":[...]}'
O que "single-stream" significa
O ds4-server aceita os quatro protocolos, mas tem uma propriedade que define como você o opera: ele é single-stream — uma única requisição em voo por vez. Não há paralelismo de requisições; o servidor processa um grafo de cada vez e serializa o resto. Consequência prática: um cliente sério por vez. Para visão concorrente, separe o endpoint (assunto da Lição 08).
ds4-agent é alpha. Trate como ferramenta de fronteira em movimento: ótima para trabalho sério agora, mas ainda não como infra estável de produção. E a regra que pode custar o sistema: no macOS, nunca make cpu — um bug da VM dá kernel panic. Sempre Metal (o default).05b · As quatro APIs lado a lado — e por que single-stream
O ds4-server fala quatro famílias de protocolo de uma vez. Isso é o que faz um cliente comercial (Claude Code, Codex) "não perceber" que está falando com algo local: cada um usa o endpoint que já conhece. Veja qual cliente casa com qual rota:
A propriedade que define a operação: o parsing roda em threads, mas a inferência é serializada por um único graph worker — o servidor não junta requisições independentes em lote. É o "single-stream". Veja a fila:
Consequência prática: um cliente sério por vez. Não é limitação de bug — é a escolha de manter um único checkpoint de KV vivo (e reusar o prefixo). Para rodar visão concorrente, separe o endpoint (Lição 08).
Comparativo extra: os três modos de raciocínio
O DeepSeek-V4-Flash tem três "marchas" de esforço de raciocínio — e a diferença em tarefas de código/matemática é enorme. Isso importa porque o mesmo modelo local pode ser rápido-e-direto ou lento-e-profundo. Clique para comparar (números do MODEL_CARD oficial):
</think>). Bom para tarefas fáceis e latência baixa. LiveCodeBench 55,2 · HMMT 2026 40,8 · GPQA Diamond 71,2. É a marcha dos benchmarks de velocidade da seção 04b.<think>…</think>) para tarefas mais difíceis. LiveCodeBench 88,4 · HMMT 2026 91,9 · GPQA Diamond 87,4. O salto sobre Non-think em código/math é brutal — o "pensar" paga.Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.
Revisão cumulativa — recupere de memória
Antes de clicar: tente responder de cabeça. Recuperar da memória (não reler) é o que fixa de verdade. As opções têm tamanhos parecidos de propósito — sem pista pela forma. O placar conta seus acertos.
--cors, --host) — o serial é proposital.:8000 local?". É só dizer.