llama-modchip executa DeepSeek de 284 bilhões de parâmetros em 64 GB sem GPU

Se uma equipe tem um servidor sem placa de vídeo, pode tentar rodar um assistente local no processador dele. Esse é exatamente o cenário proposto pelo llama-modchip. A questão prática aqui é simples: o hardware já pago consegue analisar documentos ou ajudar com código com uma latência aceitável? O projeto dá motivo para montar um experimento, embora ainda não haja uma resposta pronta para a sua máquina.

O autor afirma ter executado o DeepSeek-V4-Flash com 284 bilhões de parâmetros em um sistema com 64 GB de RAM, com velocidade de geração de 9,1–14,7 tokens por segundo. São resultados do desenvolvedor do projeto; nós não os reproduzimos. Fonte original: o repositório llama-modchip.

Como um modelo grande cabe na memória

O projeto se baseia na compressão de pesos e em alterações nos kernels de cálculo do llama.cpp. O DeepSeek usa a arquitetura MoE: ao processar um token, apenas parte dos parâmetros trabalha. Por isso, o número total de parâmetros, por si só, explica mal a carga computacional. O autor estima o tamanho do modelo após a compressão em 56,56 GiB e apresenta medições para o processador AMD Ryzen 9 9955HX. As condições estão descritas no README.

Em termos cotidianos, a ideia lembra guardar uma grande obra de referência em um formato mais compacto: ela ocupa menos espaço e, para uma resposta específica, só são necessárias algumas seções. A analogia explica a economia de recursos, mas não prova nada sobre a qualidade. O quanto as respostas se preservam após a compressão precisa ser verificado separadamente.

Imaginemos um assistente interno para o suporte ao cliente. O funcionário entrega a ele a solicitação de um cliente e alguns trechos das instruções, e o modelo prepara um rascunho de resposta. Nesse cenário, é útil medir todo o percurso: enviar a solicitação, esperar o início da resposta, receber um rascunho completo, verificar os fatos. Esse tempo determina se o funcionário vai querer usar a ferramenta todos os dias.

Se o assistente gera texto com rapidez suficiente, mas confunde regularmente as condições de reembolso, a economia com equipamento perde o sentido. Se responde corretamente, mas obriga a esperar antes de cada mensagem, vale testar um modelo mais compacto. O tamanho no nome não substitui a comparação em uma tarefa real.

Onde terminam as promessas de velocidade

Os limites superior e inferior da faixa declarada foram obtidos com diferentes modos de aceleração. Outra limitação é a compatibilidade: os arquivos especiais do modelo exigem compilar o projeto; o Ollama e o LM Studio padrão não os carregarão. Essas ressalvas constam na documentação.

Para o desenvolvedor, daí decorre um plano de verificação bem concreto. Primeiro, pegar algumas dezenas de solicitações típicas e definir de antemão os sinais de uma boa resposta. Depois, executar o mesmo conjunto na alternativa que a equipe já está considerando: um modelo local menor ou uma API externa. Vale comparar a correção, a latência e o volume de ajustes manuais.

É necessário um teste à parte para solicitações simultâneas. Uma conversa confortável para uma pessoa não significa que o servidor aguentará um dia de trabalho da equipe. É útil verificar como a fila cresce, se sobra memória para a aplicação e o que acontece com uma solicitação longa. Para uma máquina virtual, essas medições são especialmente importantes: os resultados em um processador específico de notebook não determinam as capacidades de uma instância alugada.

Para quem vale a pena tentar

O candidato mais óbvio é uma equipe com um servidor de CPU disponível e tarefas em que uma pausa seja aceitável. Por exemplo, preparação de rascunhos, análise de textos internos ou processamento de uma fila de documentos. São usos possíveis, não resultados confirmados pelo projeto.

É sensato começar com um ambiente de testes separado e uma pequena amostra de materiais reais. Registre a versão da compilação, os parâmetros de execução e os resultados, para que o experimento possa ser repetido. Depois, calcule o custo de uma resposta útil, considerando aluguel, manutenção e revisão humana.

Para o fundador, o valor da notícia está em surgir mais uma opção de infraestrutura. Para o gerente de produto, na possibilidade de testar um cenário local antes de comprar equipamentos. Para o desenvolvedor, em um experimento concreto: descobrir se a CPU disponível basta para a carga necessária. A decisão sobre a adoção virá depois dessa medição.