Por que o DeepSeek é barato em grande escala, mas caro localmente

• Alguns modelos de IA, como o DeepSeek-V3, são baratos e rápidos quando oferecidos em grande escala, mas ficam lentos e caros em execução local
• O motivo está no trade-off fundamental entre throughput (taxa de processamento) e latency (latência), relacionado à eficiência de uso da GPU
• Ao aumentar o tamanho do batch, a GPU opera com mais eficiência, mas o usuário precisa esperar até que os tokens sejam acumulados, o que causa aumento da latência
• Modelos com arquitetura Mixture-of-Experts e pipeline profundo exigem batches maiores e maior latência
• Em um ambiente local com um único usuário, é difícil formar batches grandes o suficiente, o que causa queda de desempenho e aumento de custo
• OpenAI, Anthropic e outras conseguem respostas rápidas por meio de maior eficiência na própria arquitetura, estratégias avançadas de batching ou até uso excessivo de GPUs

---

Inferência em batch e eficiência de GPU

• A GPU é um hardware otimizado para grandes multiplicações de matrizes (GEMM)
• Ao agrupar os tokens de vários usuários de uma vez e executá-los como uma matriz grande em batch, o throughput aumenta drasticamente devido ao baixo overhead de ida e volta e à eficiência de memória
• O servidor de inferência acumula os tokens de várias requisições em uma fila, escolhe um batch de tamanho adequado e executa uma grande operação GEMM
• Nesse processo, o servidor precisa escolher entre o trade-off de tamanho do batch (aumento de throughput) e tempo de espera (aumento de latência)

Por que alguns modelos são otimizados para batches grandes

Mixture of Experts (MoE) e batch

• A arquitetura MoE (DeepSeek-V3, estimado também para o GPT-4) é uma das principais causas da baixa eficiência de GPU
• Como centenas de blocos “especialistas” exigem multiplicações de matrizes separadas, em batches pequenos cada especialista recebe pouco trabalho e a eficiência cai
• Só com muitas requisições simultâneas é possível aproveitar plenamente todos os especialistas; por isso, em nível de serviço, batches grandes são indispensáveis
• Com espera curta (janela de 5 ms), os especialistas ficam ociosos com frequência; com espera longa (janela de 200 ms), é possível maximizar a eficiência

Problemas de batch em modelos com pipeline profundo

• Grandes transformers com centenas de camadas são executados dividindo as camadas entre várias GPUs (pipelining)
• Se o número de tokens em um batch for menor que o número de etapas do pipeline, ocorre o fenômeno de pipeline bubble, o que reduz o throughput
• Para evitar isso, um batch grande (e portanto uma espera maior) é indispensável, o que aumenta o tempo de resposta do modelo

Por que não é possível manter a fila sempre cheia

• Em teoria, parece que com muito tráfego simultâneo seria possível manter a fila sempre cheia e evitar bubbles
• Mas, na prática, na etapa de attention do transformer, as matrizes precisam ter o mesmo tamanho (comprimento) para poderem ser agrupadas em batch, então é difícil fazer isso funcionar perfeitamente com uma única fila
• Além disso, ao separar as etapas de FFN e attention, surgem problemas de forte aumento de overhead de memória e ineficiência na movimentação de dados

Resumo e conclusão

• O processamento em batch grande é essencial para reduzir o custo de GPU e aumentar o throughput, mas o usuário passa a enfrentar mais tempo de espera
• Modelos com Mixture-of-Experts e estrutura de pipeline grande são, por natureza, otimizados para ambientes de batch de alta eficiência baseados em espera
• Em ambientes com pouco tráfego, como o local, não é possível montar batches grandes otimizados, então a eficiência da GPU despenca e o custo de execução sobe
• OpenAI, Anthropic e outras mostram alta responsividade, e as razões podem ser:
  • (1) usar uma arquitetura mais eficiente que MoE
  • (2) aplicar otimizações de batch/pipeline e técnicas avançadas de inferência
  • (3) empregar mais GPUs do que o estritamente necessário, comprando velocidade com hardware

Adicional: diferença entre batch de prefill e batch do corpo principal

• Em transformers, também é possível executar em batch o prefill de um prompt de usuário (entrada longa), acelerando a inferência inicial
• Porém, o batch discutido no texto é o batch do estágio efetivo de geração de tokens de várias requisições de usuários, onde surge o trade-off entre throughput e latência
• O batch de prefill não tem relação direta com o batch simultâneo de grande porte mencionado no texto

Observações

• Sistemas reais de inferência também usam continuous batching, executando assim que o batch fica pronto
• Porém, a estrutura fundamental do trade-off entre throughput e latency continua a mesma

[GN⁺]

Opiniões do Hacker News

• Estou rodando o DeepSeek V3 em casa e acho que o custo é baixo, com velocidade e desempenho satisfatórios. Muita gente pensa que não dá para rodar modelos grandes sem GPU, mas pela minha experiência um servidor com CPU pode até consumir menos energia e ser mais prático. Meu servidor doméstico usa uma placa Supermicro com um EPYC série 9004 intermediário e 384 GB de RAM, e o custo total ficou em cerca de 4 mil dólares. Sem GPU, usando apenas bastante RAM, o consumo pode até ser menor que o de um desktop gamer. Uso o modelo Unsloth Dynamic GGUF com cerca de 270 GB de RAM, e na prática ele consegue lidar com várias tarefas com qualidade muito próxima da original. Normalmente rodo com contexto de 16k e, se preciso, amplio para 24k. A velocidade de geração fica em 9 a 10 tokens por segundo, ou 7 quando o contexto é maior. Em ambientes com 2 CPUs, há casos de execução do modelo inteiro com velocidade de tokens ainda maior
  • Fico curioso para saber o quão próximo do original é o desempenho do Unsloth Dynamic GGUF na prática. Pela minha experiência, em tarefas simples a diferença não é grande, mas em tarefas complexas ou com contexto longo ela às vezes aparece claramente. É verdade que a Unsloth está fazendo um trabalho excelente, mas é uma pena que faltem avaliações comparativas diretas com o modelo original sem quantização. Também há a limitação prática de que muitas pessoas e empresas não têm condições de rodar o modelo original
  • Fico curioso se é viável rodar o DeepSeek para geração de código com uma ferramenta como o Ollama em uma CPU de 40 núcleos e 256 GB de RAM. Estou pensando em alocar cerca de 200 GB de memória para o modelo
  • Comentário de que o site pessoal não está acessível. Apresenta-se como Jeff Carr, cofundador da DigitalOcean, e diz que espera conseguir entrar em contato
  • Eu achava que uma GPU com memória muito rápida seria obrigatória, então pergunto se realmente é possível fazer inferência sem GPU usando apenas muita memória. Também fico curioso sobre como isso funciona sem memória unificada
  • Concordo que o DeepSeek V3 é realmente muito prático entre os modelos open-weight. Muitas tarefas não precisam de tantos tokens de reasoning quanto se imagina, e a vantagem é não precisar esperar. Também é atraente poder escolher uma opção de reasoning mais alta sempre que necessário. Se você não for rodar localmente, alguns provedores oferecem contexto completo (16k), 80 tps e prometem não usar os dados. Belo setup esse exemplo de servidor doméstico com 9004
• Acho o conteúdo deste post de blog impressionante. Concordo com a conclusão (“é preciso batching”), mas a discussão sobre inferência em modelos MoE deveria ser mais completa. O motivo de batches grandes serem importantes é que o gargalo na inferência de LLM não é falta de capacidade de computação, e sim carregar todos os weights da VRAM. Comparando os TFLOPS e a largura de banda de memória de uma H100, dá para calcular que existe espaço para processar 300 FLOPs por byte. Quanto maior o batch, mais computação você consegue fazer por parâmetro carregado, então é preciso maximizar o tamanho do batch. É por isso que se usa o termo “roofline model”. Conforme os modelos ficam maiores, o modelo inteiro já não cabe na VRAM e passa a ser necessário distribuí-lo entre várias GPUs ou nós. Nem NVLink nem Infiniband são tão rápidos quanto carregar diretamente da VRAM, então isso vira gargalo. A força do MoE está no expert parallelism, isto é, colocar experts diferentes na memória de nós diferentes e minimizar a comunicação entre nós. Mas isso só funciona quando há nós suficientes para que todos os experts caibam na VRAM junto com overheads como o cache KV. No fim, o tamanho do batch naturalmente precisa crescer, e só assim cada GPU consegue operar com eficiência
  • Sugestão de atribuir os diferentes "experts" a um nó em esquema round-robin e só agrupá-los oportunisticamente em batch quando várias requisições usarem o mesmo expert. É como usar uma fila em vez de batch, então a latência aumenta, mas em ambientes como fluxos de trabalho de pesquisa profunda isso pode ser perfeitamente aceitável
  • Quando o modelo não cabe em uma única GPU, há casos reais em que a inferência é feita dividindo por camada e enviando um pequeno vetor para a GPU responsável pela próxima camada. A Cerebras faz isso e gera 2,5 trilhões de tokens por segundo com o Llama 4 Maverick. A transferência de vetores sobre o fabric é tão rápida que quase não há tempo ocioso
  • Imaginação sobre se seria possível operar muito mais rápido caso todos os nós e weights fossem colocados em circuitos analógicos
  • Um dos argumentos para investir na AMD é que o modelo inteiro pode caber em um único chassi, trazendo vantagens de map/reduce e reduzindo custo de equipamentos de rede. Pede opiniões contrárias com insights
• Resumo em uma linha para quem quer poupar tempo: a resposta é inferência em batch. É a abordagem de colocar os prompts de várias pessoas na mesma instância do modelo ao mesmo tempo, e isso é muito mais eficiente do que apenas multiplexar no tempo. Por causa disso, mesmo com temperatura e seed fixos, a resposta do serviço pode variar a cada vez, porque não dá para controlar com quais outros prompts o seu será agrupado. Também se imagina esse fenômeno como um possível vetor de ataque para roubo de dados
  • Uma das vantagens do batch é a conveniência de repetir a avaliação do mesmo conteúdo várias vezes para verificar se realmente há "hallucination", bastando disparar uma quantidade igual ao batch-size. Na verdade, o conceito de batch sempre esteve presente nos LLMs, mas tende-se a perceber seu valor de verdade só com o tempo
  • Eu simplesmente supunha que os provedores sempre usavam batch em todos os modelos, então fico curioso se isso só se aplica a certas famílias de modelos
  • Fico curioso por que o fato de estar em batch com outros prompts faria a resposta do modelo variar
  • Se o prompt puder ser agrupado com o de outra pessoa, isso parece um vetor de ataque extremamente eficaz
• Em resumo conciso:<br>- Modelos com alta sparsity precisam de batches grandes (muitas requisições simultâneas) para tornar uma única operação de multiplicação de matrizes suficientemente intensiva em computação<br>- Para sustentar batches desse tamanho, é preciso algo como 8 a 16 GPUs para fazer caber os weights do modelo e o cache MLA/KV na HBM. Mas com 8 a 16 GPUs o throughput total ainda é baixo, então a velocidade de resposta para cada usuário fica realmente lenta. Para ficar bom mesmo, seriam necessárias algo como 256 GPUs para uma experiência confortável
  • Eu opero um serviço DeepSeek em um ambiente com 16 H100s (2 nós). Vejo 50 a 80 tokens por segundo por requisição e throughput estável de milhares de tokens no total. O tempo até o primeiro token também é estável, e a experiência é mais rápida do que qualquer serviço de nuvem que podemos usar
  • Dizem que alta sparsity = necessidade de batch grande, mas eu não entendo bem essa ligação. Faz um comentário sarcástico de que sparse matmul é, no fundo, só um matmul com muitos zeros
• Impressão de que é uma excelente explicação do ponto de vista de LLM. Prevê que empresas hyperscale de LLM analisam cuidadosamente traces reais de computação, identificam gargalos e levam muito a sério a otimização da carga com load balancers, arquitetura de pipeline, schedulers etc. O “pré-requisito de batch” para ganhar eficiência pode ser desfavorável em aplicações com alta exigência de segurança, porque isolar consultas se torna extremamente caro. A virtualização vGPU da nVidia divide a memória da GPU por fatias de tempo, mas suspeita-se que isso exija unload/reload a cada troca de contexto, sem deduplicação. O MIG também divide a memória de forma fixa entre usuários, e para reconfigurar seria preciso reiniciar a GPU; dá para entender a frustração de não querer dividir uma GPU de 96 GB em 4x24 GB. Imagina-se se adicionar memória secundária (DRAM) à placa de GPU permitiria carregar diversos dados de matriz mais rápido do que via PCIe, usando a HBM como cache.<br>A escrita franca de Software Engineering Survival Guide também recebe elogios
• Há muita margem para otimização de software para DeepSeek. Na prática, a otimização focada em acessibilidade hoje só atende a dois tipos de sistema: GPUs pequenas com muita RAM (ktransformers) ou sistemas com VRAM enorme. Uma configuração com 192 GB de VRAM + memória comum no restante (DGX station, 2xRTX Pro 6000 etc.) provavelmente conseguiria rodar o DeepSeek 4bit com boa velocidade graças ao poder do MoE. Se o prompt do DeepSeek não estiver em chinês, a maioria dos experts nem é ativada. A poda também fica mais fácil nesse ambiente. A direção dos sistemas enthusiast no futuro parece combinar com esse tipo de otimização por software. No Reddit há exemplo de um sistema com 16x3090 (Pcie 3.0 x4) fazendo cerca de 7 tokens por segundo no llama.cpp, e uma única 3090 já consegue varrer toda a VRAM 39 vezes por segundo, então deve haver outros gargalos de desempenho
  • Um sistema com 16x3090 consome nada menos que 5 KW. Nessa altura, considerando a conta de luz, usar uma API sai mais barato. E, já que muitos experts não são ativados quando o prompt no DeepSeek não é em chinês, dá para imaginar reduzir o modelo e rotear tokens para experts mais próximos
  • Uma MI300x consegue oferecer 192 GB de VRAM
• Não sou pesquisador de ML nem engenheiro, então peço que levem isso em conta. O DeepSeek V3/R1 é tão grande em comparação com os modelos locais anteriores que rodá-lo localmente realmente é caro. Os parâmetros ativos são menores que o tamanho total, mas isso só reduz a exigência de computação; a exigência de memória continua a mesma, então na maioria dos casos o uso prático fica praticamente impossível sem GPUs enormes. Também não dá para comparar diretamente com os principais modelos frontier proprietários, porque informações como tamanho não são públicas. Também não há base para esperar que esses modelos rodem localmente de forma mais barata. Pelo contrário, o MoE oferece um trade-off mais adequado para ambientes locais ou de usuário único, onde a ineficiência de batch pesa menos. Quando você aumenta o batch, a latência de espera por token pode subir para 200 ms, mas em compensação a operação feed-forward (GEMM) fica maior e a computação se torna mais eficiente. Fico curioso se aumentar o batch torna a própria matriz maior. No meu modelo mental, o objetivo do batch não é “aumentar o tamanho da matriz de entrada”, e sim “mover a limitação de largura de banda de memória para um gargalo de computação”. Os weights já são quebrados por camada e carregados da HBM para a SRAM, depois multiplicados por bloco e por fim somados. Ao fazer batching, a vantagem é processar várias operações simultaneamente com os mesmos weights e maximizar melhor os FLOPS. Também acho fraca a base do post do blog para dizer que grandes modelos de OpenAI, Anthropic etc. respondem rápido, porque ele não mostra números de time to first token
  • Eu sou o autor do texto original. Não sou pesquisador de ML, e sim um engenheiro interessado no tema. No cenário local de usuário único com MoE, a questão é que você não tem o benefício do batch multiusuário, então o throughput por GPU cai drasticamente. A menos que haja um volume enorme de requisições de inferência em paralelo, é isso que acontece. Ao aumentar a matriz de entrada via batch, quando o batch é 1 a operação é sobre uma matriz 1xdim; quando o batch aumenta, vira batch-size x dim, e a utilização da GPU sobe muito, mudando para gargalo de computação. E, por fim, usando bastante o DeepSeek, dá para sentir que ele realmente é mais lento que outros modelos
• Tenho em mente que mixture of experts exige batch alto, mas com Apple Silicon parece usável mesmo com batch size 1. Graças à unified memory, dá para rodar modelos grandes localmente, embora a largura de banda e os FLOPS sejam baixos e o funcionamento seja relativamente lento. O MoE tem a característica de reduzir a carga computacional porque o número de parâmetros processados a cada passo é menor. Há muitos relatos de gente usando DeepSeek no Mac em inferência single-batch com velocidade razoável. Claro que o custo de compra continua alto se você quiser bastante memória instalada. Se surgirem mais máquinas como os Macs, essa parece uma combinação perfeita para modelos MoE. Em comparação, rodar modelos dense em Macs com upgrades grandes de RAM é bem mais sofrido
• Conversando com um colega, chegamos à conclusão de que, para suporte à programação com LLM, os modelos estão evoluindo numa direção que se afasta da otimização essencial. Pelas regras internas, eu comparo quase todo o meu trabalho entre modelos locais de 4~30B e várias séries GPT, e especialmente o GPT-4o costuma entregar resultados muito bons em média, mas também tende a “inventar partes da resposta”, o que exige bastante tempo em verificação e iteração. No fim, concluí que “a diferença em relação a modelos locais de poucos parâmetros, considerando o esforço, não é tão grande quanto parece”. O problema é que ambos são realmente lentos, então não dá para iterar rápido. Eu preferiria muito mais um modelo de contexto grande, mesmo com qualidade inferior, mas com resposta instantânea como um raio. Mais do que melhorar métricas de qualidade, desejo que a “velocidade de iteração percebida” seja priorizada
• Discordo da afirmação de que é “lento e caro”. Há casos de workstations antigas baseadas em memória DDR4, usando llama.cpp, conseguindo tirar 3 tokens por segundo com sistemas na faixa de mil dólares
  • Pode ser que você esteja confundindo o modelo DeepSeek real com uma versão destilada. Sem pelo menos 192 GB de RAM, não dá para rodar o modelo verdadeiro