É mesmo possível executar o DeepSeek V4 Flash 284B com 64 GB de RAM e sem uma GPU?

Um projeto comunitário relata a execução do DeepSeek V4 Flash 284B numa máquina Linux com 64 GB, usando apenas o CPU. A configuração relatada utiliza o llama-modchip, um checkpoint personalizado com cerca de 1,71 bits por peso e um CPU de secretária com uma largura de banda de memória considerável. Considere-a uma experiência documentada com uma compilação específica, e não uma recomendação geral de dimensionamento para o checkpoint oficial.

O resultado é útil porque permite avaliar três questões que normalmente se confundem: o ficheiro dos pesos cabe, o processo consegue manter memória suficiente durante a geração e o resultado continua a ser útil com esse nível de compressão? O projeto foi mencionado numa discussão da comunidade a 8 de novembro. As medições abaixo são do repositório do responsável pela manutenção do llama-modchip, não de testes independentes.

Que modelo DeepSeek e ambiente de execução estão envolvidos?

O projeto visa o DeepSeek V4 Flash, descrito na documentação como tendo cerca de 284B de parâmetros no total, com aproximadamente 13B ativos por token. Num modelo de mistura de especialistas, o router seleciona os especialistas para cada token. Isso limita o cálculo por token, mas o conjunto completo de especialistas continua a ter de ser armazenado e disponibilizado. Consulte o cartão do modelo do programador e a visão geral dos requisitos de hardware para conhecer o contexto de implementação habitual.

A experiência utiliza uma transcodificação especializada e patches ao ecossistema ggml/llama.cpp. Até outro ficheiro que anuncie a mesma família de modelos pode ter uma disposição dos tensores ou uma precisão diferentes. Um binário padrão do llama.cpp e um GGUF convencional devem ser considerados uma via distinta. O guia de atualização do llama.cpp existente abrange a via da versão oficial.

Como cabem 284 mil milhões de parâmetros em 64 GB de RAM?

Com uma média de 1,71 bits por peso, 284 mil milhões de pesos correspondem a cerca de 61 GB de dados compactados em unidades decimais. O projeto indica um ficheiro de 56,56 GiB e um pico de memória residente do processo de 57,61 GiB na configuração de 256K. GiB e GB são unidades diferentes. Consulte a memória efetivamente disponível no anfitrião durante o teste para perceber a margem. As reservas do firmware, os gráficos integrados e outros processos podem consumir grande parte de uma margem pequena.

A memória residente e o tamanho do ficheiro dos pesos são medidas relacionadas, mas nenhuma delas abrange todas as alocações do sistema. Durante o carregamento, o kernel pode libertar cache do sistema de ficheiros ou manter buffers temporários. Acompanhe tanto a memória do processo de execução como a memória disponível no sistema. Um conjunto residente elevado durante um teste registado também não caracteriza todos os comprimentos de contexto nem todos os tipos de entrada.

Porque é que a velocidade de processamento do prompt e a velocidade de geração divergem?

O processamento do prompt trata a entrada já conhecida, pelo que o runtime pode agrupar o trabalho de vários tokens. A geração é sequencial: o token seguinte depende dos tokens gerados anteriormente. A geração em CPU de um modelo MoE é sensível à velocidade a que a máquina consegue transferir os pesos e o estado dos especialistas selecionados através da memória. A frequência do relógio, o número de canais, os timings da memória e a distribuição das threads podem influenciar o resultado.

Separe um teste com um prompt curto de um prompt longo com repositório. Meça separadamente o tempo até ao primeiro token e o tempo de geração seguinte. Um prefixo maior pode dominar a latência total, mesmo quando a transmissão parece reativa depois de começar. Registe se o runtime reutilizou o estado em cache. Um prefixo aquecido e uma execução a frio respondem a perguntas diferentes. A documentação da ferramenta de benchmark upstream explica as medições de processamento do prompt e de geração.

Quanta qualidade se perde com esta precisão?

Os bits por peso resumem o armazenamento, não a qualidade do modelo. Diferentes tensores podem receber precisões diferentes, e duas conversões com tamanhos semelhantes podem comportar-se de forma diferente. O raciocínio prolongado, a sintaxe exata, os argumentos de ferramentas e o vocabulário invulgar são bons aspetos a verificar. Uma resposta legível a uma pergunta demonstra que a geração funciona. Não prova que a mesma compilação seja fiável num fluxo de trabalho de programação.

Escolha um pequeno conjunto de referência antes de testar. Inclua uma tarefa de saída num formato exato, uma função com um teste conhecido que falha, uma consulta com contexto longo e um pedido que o modelo deve tratar com cautela. Compare com uma referência suportada de maior precisão ou mais pequena, usando os mesmos prompts. Mantenha estáveis as entradas de teste e registe as saídas incompletas, as chamadas de ferramentas malformadas e os tempos limite. Fixe as revisões do modelo e do ambiente de execução para poder atribuir a uma melhoria posterior a causa correspondente.

Como reproduziria o resultado de forma responsável?

Comece com uma máquina de teste Linux isolada, bastante espaço SSD e o checkpoint e a revisão exatos do responsável pela manutenção. Leia as instruções de compilação e início rápido do projeto, inspecione os scripts antes de os executar e registe o processador, a configuração de memória e o kernel. Um prompt curto, sem ferramentas de shell ativadas, é um bom primeiro teste. Aumente o contexto apenas depois de confirmar que o sistema anfitrião continua responsivo.

1. Meça a memória livre e a atividade da swap antes de carregar o modelo. Pare outras experiências pesadas na mesma máquina.
2. Registe o tamanho exato do ficheiro e o hash do checkpoint, a versão do executor e qualquer configuração especial de transcodificação ou posicionamento de especialistas.
3. Registe o RSS máximo, o tempo até ao primeiro token, os tokens gerados por segundo e se foi utilizada memória swap. Execute o teste duas vezes para distinguir o comportamento a frio dos efeitos da cache.
4. Compare a exatidão das respostas antes de usar o modelo num trabalho mais longo. Verifique a exposição de dados e o acesso ao sistema de ficheiros se, mais tarde, ligar um agente.

Use worktrees Git isoladas para tarefas em repositórios. Se o anfitrião também fornecer serviços de armazenamento ou cópia de segurança domésticos, faça a primeira experiência numa máquina de computação separada. Um processo de inferência que ocupe toda a RAM pode interferir com esses serviços muito antes de ocorrer um erro por falta de memória.

Quando deve optar por um modelo mais pequeno?

Escolha um checkpoint mais pequeno quando precisar de velocidade interativa consistente, atualizações simples ou margem suficiente para várias sessões. A experiência da comunidade é mais interessante se aceitar código personalizado, menor precisão e uma reprodução cuidadosa. Um modelo para uso diário que funcione num ambiente de execução suportado pode ser mais fácil de manter e talvez conclua mais tarefas úteis por hora. Compare os dois modelos na mesma tarefa antes de alterar uma configuração de produção.

Perguntas frequentes

É necessária uma GPU dedicada?

O responsável pela manutenção indica uma execução apenas com CPU para o checkpoint de 284B especificado. Outras configurações no repositório incluem variantes com suporte de GPU, por isso mantenha os perfis de teste separados.

Qualquer PC com 64 GB atingirá a velocidade indicada?

A memória instalada, por si só, não permite afirmar que se obterá uma determinada velocidade. A geração por CPU depende da largura de banda da memória, dos kernels e da distribuição das threads, e o sistema precisa de RAM disponível suficiente.

É esta a velocidade que vou ver num chat em tempo real?

O valor de aproximadamente 44 tok/s refere-se ao processamento do prompt na configuração citada. O repositório indica um intervalo inferior separado para a geração autorregressiva.

O contexto de 256K é a primeira configuração a experimentar?

Comece com um contexto mais curto e meça. O valor de memória indicado pelo responsável pela manutenção depende de um ambiente de execução e de uma configuração de checkpoint específicos.

Isto substitui o guia de hardware publicado?

Use o guia oficial do modelo para uma implementação normal. Considere o llama-modchip uma opção da comunidade, com as suas próprias limitações de precisão, compatibilidade e desempenho.

Conclusão

O resultado interessante é que um ambiente de execução de CPU específico e um checkpoint personalizado de poucos bits conseguem acomodar um modelo MoE inesperadamente grande dentro de um limite de memória apertado. Reproduza exatamente a compilação, distinga o pré-processamento do prompt da geração e teste a qualidade das respostas antes de confiar nele. Um modelo mais pequeno continua a ser um controlo útil para avaliar a latência no dia a dia.