9 pontos por GN⁺ 2025-12-21 | 1 comentários | Compartilhar no WhatsApp
  • Experimentos comparando AMD, Intel e Nvidia GPUs rodando no Raspberry Pi 5 com um PC desktop mostraram, em muitos casos, perdas de desempenho de apenas 2% a 5%
  • Foram testados quatro cenários — transcodificação no Jellyfin, renderização no GravityMark, inferência com LLM/IA e configuração com múltiplas GPUs — para medir eficiência e desempenho por custo
  • Em um caso com 4 Nvidia RTX A5000 conectadas, a diferença de desempenho ficou em até 2% em relação a um servidor Intel, com o compartilhamento de memória entre GPUs via switch PCIe tendo papel central
  • O custo total de um sistema eGPU com Raspberry Pi ficou em cerca de $350~400, enquanto um PC custa $1500~2000; o consumo de energia também é muito menor no Pi (4~5W em idle vs 30W)
  • O caso demonstra o potencial do Raspberry Pi como uma plataforma alternativa de baixo consumo e baixo custo para usar GPUs grandes com eficiência

Visão geral do experimento

  • Verificação da viabilidade de uso de GPU mesmo considerando a limitação de largura de banda PCIe Gen 3 x1 (8 GT/s) do Raspberry Pi 5
    • A comparação foi feita com um PC desktop moderno (PCIe Gen 5 x16, 512 GT/s)
  • Os testes cobriram transcodificação de mídia (Jellyfin), renderização por GPU (GravityMark), desempenho em LLM/IA e configuração com múltiplas GPUs
  • Foi realizado um experimento com 2 GPUs rodando simultaneamente usando o switch externo PCIe Gen 4 e backplane de 3 slots da Dolphin ICS

Caso de Raspberry Pi com 4 GPUs conectadas

  • O usuário do GitHub mpsparrow conectou 4 GPUs Nvidia RTX A5000 a um único Pi
    • Ao rodar o modelo Llama 3 70B, a diferença de desempenho ficou em menos de 2% em relação a um servidor Intel (11.83 vs 12 tokens/sec)
  • O switch PCIe permite compartilhamento de memória entre as GPUs, contornando a limitação de largura de banda do Pi
  • Mesmo com uma única GPU, alguns workloads mostraram desempenho equivalente ou superior ao desktop

Comparação de custo e eficiência

  • Configuração Raspberry Pi eGPU: cerca de $350~400; configuração Intel PC: cerca de $1500~2000
  • Consumo em idle: Pi 4~5W, PC 30W
  • Excluindo a GPU, o Pi levou vantagem tanto em custo quanto em eficiência energética nas mesmas condições

Benchmark de transcodificação no Jellyfin

  • Com uma Nvidia 4070 Ti, o PC teve vantagem em throughput bruto (2GB/s)
    • O Pi ficou em PCIe 850MB/s e USB SSD 300MB/s
  • Porém, em streaming de mídia H.264/H.265, o Pi também lidou bem com transcodificação em 1080p e 4K
    • Há suporte a codificação por hardware NVENC, e 2 transcodificações simultâneas também foram estáveis
  • GPUs AMD apresentaram alguns problemas de estabilidade na transcodificação

Teste de renderização no GravityMark

  • Os testes foram focados em GPUs AMD; o PC foi ligeiramente mais rápido, mas a diferença foi pequena
  • Com a RX 460, o Pi registrou eficiência maior (desempenho/W) do que o PC
  • Em GPUs mais antigas com a mesma largura de banda PCIe Gen 3, o Pi obteve vantagem relativa

Comparação de desempenho em IA e LLM

  • No teste com a AMD Radeon AI Pro R9700 (32GB VRAM), o desempenho ficou abaixo do esperado, possivelmente por problemas de driver ou configuração de BAR
  • Com uma Nvidia RTX 3060 (12GB), o Pi foi mais rápido que o PC no modelo Llama 2 13B
  • Nas medições de eficiência, o Pi superou o PC em throughput por consumo de energia
  • Mesmo no teste com a RTX 4090, a diferença de desempenho ficou em até 5% para modelos grandes como o Qwen3 30B, e em muitos casos o Pi foi mais eficiente
  • Tanto o backend CUDA quanto o backend Vulkan funcionaram normalmente no Pi

Experimento com configuração dual GPU

  • Uso da placa de interconexão PCIe da Dolphin e da MXH932 HBA
  • Com ACS desativado, foi possível acesso direto à memória entre as GPUs
  • Em combinações de modelos de GPU diferentes (4070, A4000), não houve pooling de VRAM, limitando o ganho de desempenho
  • Com GPUs idênticas, foi possível rodar modelos maiores, como o Qwen3 30B
  • A combinação AMD RX 7900 XT + R9700 falhou ao executar alguns modelos devido a problemas de driver
  • O Intel PC foi mais rápido no geral, mas o Pi manteve desempenho próximo em modelos grandes

Conclusão

  • Em desempenho absoluto e conveniência, o PC continua superior
  • Porém, em workloads centrados em GPU e em ambientes de baixo consumo e baixo custo, o Raspberry Pi é uma alternativa prática
  • Há redução de 20~30W em consumo idle, e SBCs baseadas em Rockchip e Qualcomm podem oferecer eficiência e largura de banda de I/O ainda maiores
  • O objetivo do experimento era entender os limites do Pi e a estrutura da computação com GPU, e nesse processo ficou evidente o potencial de sistemas compactos

1 comentários

 
GN⁺ 2025-12-21
Comentários no Hacker News
  • Para rodar LLM localmente, no fim das contas o essencial é a GPU
    Então estou pensando qual seria o computador mais barato que dá para colocar ao lado da GPU
    Eu não tenho capacidade de entender ou corrigir problemas como BAR, então acabei montando e usando uma caixa x86 barata com uma GPU razoável espetada nela
    Mas essa ideia de que ainda deve existir um jeito mais eficiente não sai da minha cabeça

    • Eu mantenho um site colaborativo para reunir as combinações ideais de hardware para LLMs locais
      O site é inferbench.com, e o código-fonte está no repositório no GitHub
    • Ainda é difícil obter desempenho relevante com um único dispositivo PCIe
      Acho que a GPU precisa de pelo menos 128GB de RAM
      O desempenho da CPU pode até ser baixo, mas como ela precisa suportar várias lanes PCIe, uma CPU de servidor mais simples como a AMD EPYC parece adequada
    • Você nem considerou usar Apple Silicon como M4 Max ou M3 Ultra?
      Para LLMs de porte intermediário, funciona bem
    • O sistema que você descreveu é basicamente o papel que o DGX Spark cumpre
  • Não entendo por que disseram que a parte de múltiplas GPUs foi surpreendente
    A maioria dos frameworks de LLMs, como o llama.cpp, divide o modelo por camadas, então surge uma dependência sequencial e não há paralelismo real mesmo usando várias GPUs
    Algumas GPUs também são mais rápidas no processamento do prompt, enquanto outras são melhores na geração de tokens, então às vezes misturar Radeon e NVIDIA funciona
    O ganho de desempenho real vem em backends com modos como tensor parallel
    Nesse caso, a rede neural é dividida na direção do fluxo de dados, então a conexão entre GPUs precisa ser boa, como PCIe x16, NVlink, Infinity Fabric etc.
    Sem isso, o uso das GPUs pode parecer bastante irregular
    É interessante a ideia de dividir o LLM de um jeito que permita executar várias tarefas em paralelo, por exemplo com uma arquitetura de agentes separando papéis de “gerente” e “engenheiro”

    • Exato, esse é justamente o conceito de um sistema de agentes
      O modelo gerente cria os prompts, os modelos subordinados trabalham em paralelo e depois retornam os resultados
    • Dizer que a transferência entre camadas é de ordem de kilobytes é exagero
      Na prática, isso cresce para a ordem de megabytes dependendo do tamanho da sequência
      Por exemplo, se o hidden state do Qwen3 30B for 5120, então com quantização de 8 bits isso dá 5120 bytes por token
      Passando de 200 tokens, já entra na casa dos MB
      Mesmo a largura de banda de um PCIe x1, cerca de 2GB/s, já basta, mas a latência pode ser um problema maior
  • Fico muito feliz que alguém tenha feito esse tipo de experimento
    Eu também usava uma eGPU ligada a um notebook sobrando e pensava: “será que não daria para fazer isso até com um Raspberry Pi?”

  • Acho que teria sido legal ver também o desempenho em jogos
    Mas é difícil encontrar jogos AAA com suporte a ARM, e forçar emulação x86 com FEX não seria justo

    • A questão deve ser encontrar um jogo sem gargalo de CPU
  • Ao usar constrained decoding (baseado em JSON schema), o uso da CPU sobe para 100%
    Vi o mesmo fenômeno na minha instância do vLLM

  • PCIe 3.0 entrega cerca de 1GB/s por lane, ou seja, velocidade de nível 10Gb Ethernet
    Talvez no futuro as GPUs consigam operar de forma independente, sem sistema host
    Já houve casos como o Radeon Pro SSG, que tinha SSD acoplado à GPU,
    e talvez um chip RISC-V pequeno ou um controlador do nível de um Raspberry Pi já seja suficiente
    Artigo relacionado: TechPowerUp
    Uma estrutura em que a GPU se conecta diretamente a um switch de rede, com 400Gbe ou comunicação baseada em CXL, parece realista
    Além disso, tecnologias de flash de próxima geração como High Bandwidth Flash também podem vir a substituir a DRAM
    Artigos relacionados: ServeTheHome, Tom’s Hardware

  • Esses dados me fazem repensar a configuração do meu PC principal
    Um mini PC de 300 dólares consumindo menos de 20W provavelmente já basta
    Para navegar na web, ver vídeos e jogar algo leve, ele dá conta sem problema,
    e para tarefas pesadas basta acessar uma workstation remotamente

    • Estou testando uma combinação de VM Proxmox + eGPU
      Só com 1 vCPU e 4GB de RAM já é suficiente para navegar e tocar projetos por hobby
      Parece que os fabricantes de hardware exageraram no marketing ao dizer que “profissionais precisam de notebooks de alto desempenho”
    • Quando troquei um mini PC Ryzen de 8 núcleos por um desktop também de 8 núcleos, a velocidade dos testes unitários melhorou muito
      A diferença de TDP gera uma diferença grande de desempenho
    • Eu também uso um mini PC da Beelink, e a mesa fica muito mais organizada
      Deixando o equipamento mais potente em um espaço com isolamento acústico, tudo fica bem mais confortável
  • Fico me perguntando por que essa estrutura de PCI/CPU ainda é necessária
    Parece mais correto seguir a direção de Apple e NVIDIA e colocar CPU e MPP no mesmo pacote

    • Esse método é vantajoso para tarefas sensíveis à latência,
      mas talvez não faça tanta diferença em computação de grande escala, como IA ou HPC