AMD RX580 roda LLM em casa: como domar ROCm e Ollama e fazer a inferência rodar na GPU

Rodar um LLM em uma AMD RX580 antiga exigiu bem mais do que um comando certeiro: virou uma investigação de engenharia completa. O autor tentou obter inferência na GPU com ROCm e Ollama no Kubernetes, mas, em vez de uma geração estável, encontrou falsos sinais de sucesso, falhas de memória e, em alguns casos, texto sem sentido na saída.

Sintomas e armadilhas No início, tudo parecia quase funcionar.

A placa de vídeo era detectada, os contêineres subiam e a VRAM era ocupada, o que sugeria que o sistema realmente usava a GPU. Era uma armadilha: memória ocupada não significa que os cálculos estejam rodando corretamente no processador gráfico. O problema principal aparecia na hora da inferência de fato: as requisições falhavam com erros de hipMemGetInfo ou terminavam em uma geração estranha, que lembrava o funcionamento do modelo, mas não produzia nenhum resultado útil.

A GPU era detectada, a VRAM era ocupada, os contêineres iniciavam — mas a inferência falhava com erros de hipMemGetInfo.

O caso ilustra bem um erro típico ao rodar LLMs localmente: confiar apenas nos "sinais de vida" da infraestrutura. Se o Kubernetes iniciou o contêiner, o Ollama enxergou o modelo e a GPU ocupou alguns gigabytes, isso ainda não confirma que a stack ROCm está executando as operações matriciais como deveria. Em placas antigas como a RX580, é especialmente importante verificar não só se o dispositivo está disponível, mas também o caminho real de computação, porque a falha pode estar escondida abaixo da camada da própria aplicação.

Como a causa foi encontrada A raiz do problema não foi isolada com

mais uma reinstalação de pacotes, e sim com o diagnóstico do circuito de computação. O autor comparou os sinais de funcionamento em diferentes camadas do sistema e separou os sucessos cosméticos da execução real da inferência. A ferramenta-chave, curiosamente, foi o Vulkan: ele ajudou a verificar se a GPU conseguia processar tarefas de computação de forma estável e, com isso, deixou claro que o problema não se resumia ao Ollama ou à configuração do contêiner.

Na prática, a investigação partiu dos sintomas para hipóteses verificáveis. Em vez de adivinhar a partir dos logs, o autor descartou explicações falsas uma a uma e montou uma configuração mínima funcional, testando cada camada separadamente: do contêiner e do runtime aos drivers e ao próprio modelo. Essa ordem importa porque é ela que permite entender onde termina o "a infraestrutura subiu" e começa o pipeline de computação de verdade.

Passo a passo, a análise ficou assim: Verificação do processamento real na GPU, não apenas do uso de VRAM Comparação do comportamento do ROCm e do Vulkan Eliminação de problemas de contêiner e orquestração Busca por versões compatíveis de kernel e ROCm * Controle da qualidade da própria saída do modelo Essa abordagem importa porque texto sem sentido na saída também é um sinal de diagnóstico. Se o modelo responde, mas gera lixo, a falha pode não estar no carregamento dos pesos, e sim em cálculos incorretos, incompatibilidade de drivers ou um backend parcialmente funcional que só parece vivo na superfície. São justamente esses estados de meio funcionamento que costumam consumir mais tempo do que uma falha total, porque se disfarçam de bugs aleatórios da aplicação.

A combinação que funciona na RX580 O desfecho do experimento não foi

um "ajuste mágico", mas uma combinação de versões e componentes com a qual a velha RX580 finalmente entrega resultado estável. Segundo o autor, determinadas versões do ROCm e do kernel Linux funcionaram, e, depois de resolvidos os conflitos, a inferência parou de falhar e passou a gerar texto normal. É uma conclusão importante para quem tenta rodar modelos locais em placas AMD menos recentes: o sucesso depende menos do suporte nominal ao hardware e mais da compatibilidade exata entre as camadas de driver, sistema e runtime.

O resultado prático é convincente: a RX580 chegou a cerca de 42 tokens por segundo. Para uma placa doméstica de geração anterior, isso já vai além de uma demonstração: é um modo de trabalho viável para testar assistentes locais, protótipos de cenários RAG e serviços pessoais de inferência sem a necessidade obrigatória de migrar para uma stack NVIDIA recente. Mas a principal lição nem está no número de velocidade, e sim no método: se a GPU "parece funcionar", isso não basta.

É preciso verificar justamente a estabilidade dos cálculos, a correção da saída e a reprodutibilidade do resultado.

O que isso significa O caso da RX580 mostra que a inferência local de

LLMs em hardware AMD antigo é possível, mas exige disciplina no diagnóstico. Para desenvolvedores, fica uma boa referência: não confundir VRAM ocupada com o modelo funcionando de verdade, verificar toda a stack, do kernel ao runtime, e tratar saídas estranhas como um erro completo, não como uma falha menor. Para homelabs, é quase um checklist pronto para não perder dias com falsos sinais de sucesso.