- Gemma 4 26B-A4B roda em velocidade de leitura em um servidor de 2016 com um único Intel Xeon E5-2620 v4, 128GB de DDR3 e sem GPU, usando otimizações do
ik_llama.cpp
- No decoder pass de LLMs, o gargalo é a largura de banda da memória mais do que o processamento, e a CPU passa muito tempo esperando trazer os próximos pesos da RAM para o cache
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack e outros reduzem os gargalos em ambiente DDR3 com decodificação especulativa MTP, roteamento MoE e layout de memória amigável ao cache- Pelos logs, a exigência total de memória é de 82,355MiB, e no contexto completo de 262K o cache KV com cerca de 56GB é maior do que os pesos, com cerca de 25GB
- Ferramentas caixa-preta como
ollama não oferecem o suporte de modelo nem os knobs de ajuste fino necessários, e em hardware antigo é preciso entender a fundo o motor de inferência e a estrutura de memória para extrair desempenho
Ambiente de execução e gargalo principal
- O servidor de teste é equipamento reaproveitado, com especificações Intel Xeon E5-2620 v4 @ 2.10GHz, 8 núcleos, 16 threads, AVX2, 20MiB de cache L3, 2MiB de L2, 128GB de DDR3 e sem GPU
- Essa CPU não suporta AVX-512, AVX-VNNI nem BF16, e também não tem GPU integrada
- Na inferência de LLMs, o decoder pass que gera tokens um a um fica limitado principalmente pela largura de banda da memória, não pelo volume de cálculo
- Para calcular o próximo token, é preciso continuar movendo da RAM para o cache e os núcleos da CPU os pesos que contêm o conhecimento aprendido pelo modelo, e o processador passa mais tempo esperando a movimentação dos próximos pesos do que fazendo contas matriciais
- Esse “memory wall” também é uma barreira importante de desempenho não só em Xeon, mas até em hardware de alto desempenho como o H100
Os knobs de execução necessários em vez de ferramentas caixa-preta
- Rodar simplesmente
llama-cli em um ambiente com DDR3 e sem GPU é muito lento, e como as otimizações são voltadas para casos de uso comuns com GPU, ainda sobra bastante espaço para melhorias
- O
ollama pode não ter suporte para o modelo necessário e não expõe configurações detalhadas o suficiente para extrair de fato o desempenho em execução
- Na prática, a execução só é possível combinando vários flags expostos pelo
ik_llama.cpp
- O conjunto principal de flags é o seguinte
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Decodificação especulativa e otimização de MoE
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune usa o verificador 26B junto com um pequeno drafter MTP gerado anteriormente--draft-max 3 define no máximo 3 tokens por draft, --draft-p-min 0.0 aceita todas as probabilidades, e --spec-autotune ajusta o tamanho da cadeia ao workload- Ao gerar cadeias longas de inferência, mesmo que o usuário veja apenas uma resposta final curta, cada token oculto de raciocínio ainda exige um decoder pass completo
- Em CPU, o custo de fazer streaming dos pesos do verificador para o cache é alto, e como as camadas ativas do pequeno drafter cabem bem no cache L3, o benefício da decodificação especulativa fica ainda maior
- O Gemma 4 26B-A4B tem arquitetura MoE em que 8 especialistas são ativados por token entre 128 especialistas, e dos cerca de 25.2B de parâmetros no total, aproximadamente 3.8B ficam ativos
--cpu-moe ajusta o roteamento ao hierarquia de cache da CPU e trabalha para reduzir o cache thrashing causado por ficar alternando entre 128 especialistas, esvaziando o cache e trazendo tudo de novo da DDR3--merge-up-gate-experts funde a up projection e a gate projection dentro do especialista em uma única multiplicação de matrizes, e isso aparece no log como fused_up_gate = 1-t 8 corresponde aos 8 núcleos físicos, e em um workload limitado por memória usar todas as 16 threads SMT pode aumentar o custo de agendamento em vez do throughput
Fixação de memória, rearranjo e divisão do grafo
--run-time-repack reorganiza as matrizes de pesos de acordo com o layout de cache da CPU imediatamente antes da inferência, e no log aparece como Repacked 265 tensors- Essa configuração gasta alguns segundos na inicialização para rearranjar na RAM a tabela de números em um formato que a CPU consegue ler melhor, permitindo usar a largura de banda da memória ao máximo durante a geração real de texto
--mlock fixa o modelo na RAM para impedir que o sistema operacional o troque para disco- Se o limite memlock do kernel não for suficiente, aparecem os avisos
failed to mlock 27628376064-byte buffer e Try increasing RLIMIT_MEMLOCK, o que não é um problema do LLM em si, mas da configuração padrão de ulimit
--no-kv-offload faz a execução ignorar tentativas de mover o cache KV para GPU em um ambiente sem GPU e o mantém na RAM do sistema-sm graph tenta fazer graph splitting, dividindo verticalmente o grafo computacional para que vários dispositivos de processamento ou regiões de memória calculem ao mesmo tempo partes diferentes da mesma camada- Nesta execução, isso foi reduzido com segurança para layer splitting, junto com o log
Split mode 'graph' is not supported for Gemma4 external MTP
-sas instrui a divisão do workload entre sockets físicos de CPU ou nós NUMA, e --split-mode-f32 faz os pontos intermediários reunidos após a divisão usarem precisão de ponto flutuante de 32 bits
Attention, uso de memória e conclusão
- ikawrakow escreveu kernels customizados para processar Flash Attention em CPU, permitindo que isso funcione sem GPU em processamento pesado de contexto
--flash-attn on funde o softmax da attention e a multiplicação de matrizes, sem gravar fisicamente na RAM toda a matriz de attention N×N, calculando e consumindo tudo dentro do cache em pequenos blocos--mla-use 3 ativa Multi-Head Latent Attention para comprimir Key e Value do cache KV em representações latentes menores- Os logs mostram
flash_attn = 1, fused_moe = 1, fused_up_gate = 1, confirmando que essas otimizações foram realmente aplicadas
- Pelos logs de memória, a soma total de todas as camadas é de 81,607.46MiB, e a memória necessária para tensores do modelo e caches é de 82,355MiB
- No contexto completo de 262K, os pesos ocupam cerca de 25GB e o cache KV cerca de 56GB, então o cache KV é maior que o modelo
- Essa configuração carrega um MoE de 25B parâmetros e faz decodificação especulativa com drafter MTP para gerar texto em velocidade de leitura em um servidor com Xeon de 2016, DDR3 e sem GPU
- A conclusão é que o gargalo para rodar localmente IA moderna de pesos abertos não está só no silício, mas também em entender como o motor de inferência funciona e como a memória é estruturada, e que com o fork certo, quantização bem calibrada e entendimento da arquitetura de memória, até servidores antigos conseguem rodar isso
2 comentários
Comentários do Hacker News
Escrevi o post por frustração com a falta de formas de rodar o novo modelo Gemma 4 Drafter e com as ferramentas mainstream esconderem os pontos de ajuste de desempenho
No fim, consegui fazer um modelo MoE 26B atual rodar em velocidade de leitura num servidor antigo reaproveitado, sem GPU, com apenas um Xeon E5-2620 v4 e 128GB de RAM DDR3
Também linkei um modelo quantizado no fim do texto, mas ele não vai rodar a menos que você use o fork ik_llama-cpp mencionado, e para detalhes é preciso ver outro post
Não sou engenheiro de machine learning e o servidor também fica ocupado servindo como cache do Nix, mas posso responder perguntas dentro do possível
Enquanto uma thread espera pela DDR3, outra thread poderia executar
Também não entendi bem a explicação de
--cpu-moe. Um especialista tem cerca de 4.0GiB de parâmetros, então se o cache L3 é de só 20MiB, parece que não dá para manter parâmetros em cache de forma significativa, mesmo otimizando a ordem dos especialistasComo outras pessoas disseram, só alguns Intel Xeon E5-2xxx v4 suportavam DDR3, e segundo a documentação da Intel o E5-2620 v4 não é um deles
É uma configuração com dois Xeon e 128GB de DDR3, e os CPUs são 2 × Xeon E5-2697 v2, totalizando 24 núcleos/48 threads, então em número de núcleos é melhor, mas talvez na prática a diferença não seja grande
É um equipamento só juntando poeira, então Gemma em velocidade de leitura parece bem promissor
Procure por “chia farming” na Amazon, mas pode ignorar chia seeds
Agora o mesmo equipamento está uns 2,5× mais caro, mas ainda é muito mais barato que uma máquina atual com DDR5
https://www.amazon.com/dp/B095TRGCSX
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, CPUs online 0-31, 128GB de RAMFico curioso se, com 8 slots de DIMM, a largura de banda de memória realmente melhora. Hoje essa pobre máquina só serve para ver YouTube
Ainda não chegamos lá, mas o ponto final óbvio da bolha atual é que modelos abertos rodando em hardware e dispositivos locais se tornem “bons o suficiente” para a maioria dos usos
Se isso acontecer, pode desmontar completamente o que está acontecendo hoje na indústria de tecnologia
Quando eu realmente travar, posso chamar a API do Claude, mas acho que uns 80% da necessidade dá para cobrir com um modelo local mais burro
Linguagens e técnicas de programação não mudam tanto assim, então espero conseguir usar isso por pelo menos 5 anos, e quando aparecer otimização para colocar um modelo mais inteligente na mesma VRAM eu faço upgrade
Gosto dessa direção
Meu palpite para não fazerem isso é que, como os labs de IA hoje vendem modelos com prejuízo enorme, para a Amazon computação de baixa margem talvez seja menos atraente que outros produtos de margem alta
Talvez nem precise chegar à execução local para esse estado atual ruir. Quando a pista de dinheiro grátis dos labs de IA acabar e eles tiverem de vender acima do custo real de execução, qualquer um com computação terá incentivo para oferecer serviços de modelos abertos mais baratos, a preço de commodity
Todo mundo vai ter modelos e capacidade de executá-los, e por isso a escassez de GPU joga a favor delas
A esperança delas depende de grandes e médias empresas moverem todos os fluxos de trabalho para a nuvem e de funcionários competirem para usar o máximo possível de tokens
Modelos “bons o suficiente” com privacidade e redução de custo no longo prazo ficam atraentes
Ironicamente, quanto melhor ficar o ambiente de execução genérico para agentes de programação, menor será o fosso competitivo de serviços como o Claude. É difícil acreditar na rapidez com que alguns modelos abertos alcançaram os modelos de ponta de alguns meses atrás
O texto é bom e tecnicamente impressionante. Concordo que é preciso entender o pipeline de build e conseguir rodar localmente
Só que, dependendo da tarifa de energia, pode não ser economicamente viável. Servidores antigos são pouco eficientes energeticamente, e eu achava que servidores Xeon antigos consumiam algo como 200W sob carga, enquanto o mesmo modelo está disponível no OpenRouter por 0,1/0,3 dólar por milhão de tokens, 76 tokens/segundo e contexto de 262k
Além disso, esses servidores fazem barulho. Mas talvez minha estimativa de 200W tenha sido alta demais; os servidores Xeon antigos que usei realmente gastavam muita energia, mas não lembro os modelos exatos
Servidores em geral são barulhentos, mas isso também varia conforme a configuração. Existe muita hospedagem barata baseada nesses chips, e eles têm eficiência energética melhor do que parece
Rodando uma configuração parecida num gabinete 4U com ventoinhas lentas de 120mm, fica tranquilo
Fico feliz em ver que outras pessoas também estão percebendo isso. Estou rodando Gemma 26B-A4B Q4 em um contêiner com um Xeon de 2012 e 16~24GB de RAM, e consigo algo em torno de 8~12 tokens/s
Não dá para comparar com contexto grande ou execução em GPU, e o decodificador de imagem do llama.cpp também é muito mais lento que na GPU, mas para pequenas tarefas de automação ou perguntas de conhecimento geral funciona bem. É rápido o bastante para acompanhar lendo, então a espera incomoda menos
A configuração é um build do
llama.cppcom OpenBLAS e OpenMP ativados,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, cacheq8_0e contexto de 8192Vale a pena procurar otimizações específicas da CPU, como AVX2; testei MTP rapidamente, mas não houve ganho de desempenho. Também dá para ajustar o tamanho do lote de cache/contexto ou até baixar para Q2, e é melhor evitar superalocação de threads. Recomendo começar pelos padrões ou pelo
llama-benchNos testes, rodei
gemma4:e4b-it-q4_K_M, que cabe completamente em 11GB de VRAM, e passei de 50 tokens/s. Um modelo tão pequeno assim não é útil para programação, mas pode servir para outras coisasQuero fazer um Wake-on-Use para usar como um ChatGPT pessoal. Talvez dê para colocar um Pi como proxy e chamar um script de Wake-on-LAN; quem sabe isso vire um projeto divertido de fim de semana algum dia
O LLM que fica sempre ligado é o dense
Gemma4:31b, que nem chega à metade dos 12GB de uma 2060; é bem lento, mas a qualidade é boa, e como ele serve para processamento automático em fila, eu não fico esperando a saída olhando para a tela. Tenho mais uma 2060, mas se colocar as duas o PC não passa do POSTFiquei um tempo considerando um Mac Studio Pro, mas no fim vim por esse caminho. Tenho uma máquina HP Z620 headless com 192GB de RAM ECC, dois Xeon E5-2680 v2, Optane AIC, duas P102-100 com 10GB de VRAM, um SSD mínimo de boot com Debian 12.6 e uma versão antiga fixa do CUDA que suporta placas Pascal
Uso remotamente do porão via AMT/meshcommander, subo o
llama.cppe o frontend e acesso pela rede local. Tenho mexido com Talkie, Qwen 3.6 27b e medgemma, e escolhendo a quantização certa, o desempenho em GGUF no geral foi bem decenteO custo total ficou abaixo de 500 dólares, mas comprei o servidor no eBay no ano passado, então hoje pode ser diferente
No futuro, se os LLMs ternários florescerem, espero que esse hardware antigo consiga de fato hospedar modelos densos em conhecimento e de alta densidade. Não me importo se ultrapassar a RAM da GPU e acabar usando Optane, e conhecimento factual geral importa mais para mim do que velocidade
O plano final é, depois de configurar tudo, guardar no porão dentro de uma lata de lixo Faraday, para ficar como um oráculo de “reconstrução da civilização” quando o mundo desmoronar. Claro que, nessa situação, energia seria um problema, mas se esse hardware está tão barato e a IA moderna já é prática em tantos momentos, vale a tentativa
O mais interessante no avanço da IA não é AGI nem o modelo mais recente de algum unicórnio específico da IA, mas sim o que dá para rodar localmente
Seis anos atrás, eu rodava em um PC gamer parrudo modelos divertidos, mas pouco úteis; hoje, em um notebook M5, dá para rodar algo 100 vezes melhor do que aquilo
Se o mercado reagir à falta de memória e a evolução do Apple silicon continuar nesse ritmo, o que será possível rodar localmente daqui a seis anos vai ser muito interessante ou assustador
Também não sei o que isso significa para as valuations das empresas de IA. Uma vez fiz uma pergunta parecida para um funcionário de uma dessas empresas em um evento, e ele não respondeu — só foi pegar um coquetel
O negócio de IA é intensivo em capital, como uma fábrica antiga. Datacenters são caros, modelos consomem muita eletricidade, e o hardware interno precisa ser trocado a cada 3~4 anos
Modelos menores e mais especializados vão corroendo as margens por baixo. Para transcrição, voz e detecção de imagem, não é preciso um modelo gigante
Não há motivo para esperar margens altas como no software tradicional, e a maior parte dos ganhos da IA vai para o consumidor. Ainda assim, alguns gigantes como Microsoft, Google, Amazon e Meta podem buscar vantagem de custo por economia de escala
Não precisa ser algo topo de linha como uma 5080; com uma GPU gamer decente já dá para rodar localmente, em 2025, modelos melhores do que o estado da arte do começo do ano
Dependendo da tarefa que você quer, talvez precise trocar de modelo, e um modelo gigantesco que resolva tudo ainda continua sendo coisa de datacenter
Mas a maioria das pessoas com emprego em tempo integral e dois filhos não tem tempo nem energia para aplicar patches e fazer manutenção. Os sistemas continuam ficando mais complexos e cheios de bugs. É o velho trade-off entre liberdade e conveniência
A maioria dos usuários não sabe o que é um LLM nem como ele roda. Muitos usuários de LLM usam por padrão o que o trabalho oferece, e mesmo usuários um pouco mais experientes parecem tranquilos em pagar assinatura da OpenAI ou da Anthropic
Vai surgir um grupo pequeno, mas dedicado, de usuários de modelos abertos que preferem LLMs locais, mas o restante provavelmente continuará consumindo dos grandes provedores. Pode acabar parecido com a escolha de sistema operacional hoje: uma minoria de usuários Linux e a maioria em Windows, macOS e Chrome
Jogos de 5~6 anos atrás podem ser comprados muito mais baratos e rodam em hardware comum. Mas a indústria não fica parada por 5 anos, então continua saindo software novo que exige hardware melhor
O resultado que o autor do post original revelou nos comentários é de cerca de 12 tokens/s
É um esforço muito mais impressionante do que eu imaginava ser possível nesse hardware, mas ainda fica bem aquém do necessário para uma sessão interativa satisfatória
Muitas vezes custam de 100 a 500 vezes menos do que os modelos de ponta, e às vezes também são de 2 a 5 vezes mais rápidos em tokens/s
Para uso em segundo plano, seria totalmente aceitável
Funciona, mas não tem vazão para trabalho sério
O E5-2620 v4 é excelente. Uso o meu há 10 anos e fui tentar fazer upgrade, mas parei quando vi os preços atuais
Coloquei 64 GB de DDR4 e uma RX 9060 XT 16 GB, e os jogos ainda rodam rápido. Em DOOM The Dark Ages, a CPU talvez seja um pequeno gargalo, mas a 60 fps não há problema
Rodar LLMs leves na GPU é a escolha óbvia, e é legal ver que, com ajuste fino, também dá para rodar de forma decente na CPU
Comprei uma 2667 v4 por 30 dólares há um mês, e provavelmente haverá um bom ganho de desempenho, mas ainda não precisei. Se eu fosse forçar mais para o lado de LLM como no post, talvez fizesse o upgrade, porque a 2667 consegue lidar com RAM um pouco mais rápida
Ainda me surpreendo bastante com o que dá para encontrar no mercado de usados
Eu não imaginava que os preços de RAM e GPU iam disparar tanto, então dei sorte no timing. Até penso em pegar uma 3080 na faixa dos 300 dólares no eBay e vender a 1080 Ti, mas fora isso foi um upgrade excelente
Consome eletricidade como Coca-Cola, mas como workstation funciona muito bem, então pretendo usar até quebrar
Eu achava que danos causados por calor matavam CPUs depois de uns 5 a 7 anos, e fico me perguntando se isso era uma suposição errada. Talvez as CPUs de hoje sejam muito mais resistentes e robustas do que antes
Houve recentemente um post parecido sobre otimização de Xeon antigo
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
Surpreendentemente, o Itanium também parece se encaixar muito bem para LLMs: https://medium.com/@tglozar/running-llama-inference-on-intel...
Pensando bem, faz sentido
O conteúdo é interessante. Tenho um sistema Xeon antigo, então vou tentar também.