Como a Hooc roda o DeepSeek V4 Flash.

Queríamos a configuração mais poderosa possível pelo menor custo — objetivos que quase sempre brigam entre si. Então a decisão foi dupla: escolher o menor modelo que ainda entregasse qualidade de verdade, e o hardware que conseguíssemos pagar.

O DeepSeek V4 Flash é um modelo mixture-of-experts: 284B de parâmetros no total, mas só 13B ativos por token. É isso que permite rodá-lo em hardware que uma startup consegue pagar. Os pesos publicados já vêm quantizados em MXFP4, um formato de ponto flutuante de 4 bits que mantém a qualidade próxima do original de 16 bits ocupando cerca de um quarto da memória: ~150GB em disco, contra ~570GB em BF16.

O checkpoint quantizado apontou o caminho para a NVIDIA. A linha Blackwell executa MXFP4 nativamente no hardware, e o suporte de software para modelos abertos é o melhor do mercado. Dentro dela, escolhemos a RTX PRO 6000 — na AWS, isso é a instância g7e.24xlarge: quatro GPUs de 96GB cada, 384GB no total, com folga para os pesos e para o serving.

Instâncias spot reiniciam com frequência: a AWS recupera a máquina sempre que precisa da capacidade. A cada boot, a máquina precisa de ~150GB de pesos de volta — então onde eles ficam guardados importa muito.

Não deixamos os pesos embutidos na imagem da máquina (isso gera descompasso de versão) nem dependemos de snapshot EBS (que é lento para carregar). Guardamos um release imutável num bucket S3 na mesma região das GPUs. No boot, a instância copia o release para o NVMe local, confere um manifesto e só então sobe o servidor de inferência.

A cópia no NVMe é apenas espaço de trabalho. Se a instância morre, nada se perde: a próxima baixa o mesmo artefato de sempre. Manter o bucket na mesma região faz mais diferença do que parece — um download entre regiões transforma uma troca rápida em uma longa indisponibilidade.

Para respostas rápidas, usamos speculative decoding. Um módulo leve sugere os próximos tokens e o modelo grande confere a sugestão inteira de uma vez, em vez de gerar token por token. Como a maioria dos tokens é previsível, quase tudo é aprovado em lote — e a máquina produz vários tokens por ciclo de GPU.

No DeepSeek V4 usamos o DSpark, o release de speculative decoding da própria DeepSeek: um módulo leve que acompanha os pesos, não um modelo separado. Na nossa configuração, ele é uma única flag:

--speculative-config '{"method":"dspark","num_speculative_tokens":5}'▋

Cada token de uma conversa gera tensores de key e value que o modelo reutiliza em todas as requisições — juntos, eles formam o KV cache. Em produção, ele consome a maior parte da memória da GPU. Se você ignorar isso, o cache vira o gargalo, por mais rápida que seja a GPU.

Sessões longas de agente acumulam resultados de ferramentas, leituras de arquivo e turnos anteriores. Na maioria dos modelos, o cache cresce com cada token do histórico. O design de atenção do V4 resolve isso: o histórico recente é comprimido e consultado de forma esparsa, o antigo é comprimido com muito mais força, e uma janela curta de tokens preserva o detalhe mais recente.

# em nossos workers ao vivo
GPU KV cache size: 2,712,968 tokens
Maximum concurrency for 262,144 tokens per request: 10.35x

Recuperação de spot, prioridade justa e fallback: os detalhes que fazem o custo fixo não custar caro em confiabilidade.

Sob demanda, uma g7e.24xlarge custa em torno de US$ 12 mil por mês. Em spot, rodamos 24/7 com aproximadamente US$ 4 a 6 mil por mês por máquina.

O número importa menos do que o comportamento do custo. Preço por token cresce com o uso; uma máquina é um custo fixo para um tamanho de frota. Quando mais gente usa, as requisições entram em lote ou na fila — o serviço fica mais lento, não mais caro.

Essa é a troca por trás da sua assinatura: sob pico, a resposta pode demorar um pouco mais. O que não pode acontecer é a fatura crescer a cada requisição.