AMD RX580 rodou um LLM localmente: como driblar ROCm, Ollama e obter inferência em GPU

Executar uma LLM em uma antiga AMD RX580 se mostrou não uma questão de um comando de sorte, mas sim uma investigação de engenharia completa. O autor tentava obter uma inferência apropriada de GPU através de ROCm e Ollama em Kubernetes, mas em vez de geração estável, recebeu sinais falsos de sucesso, falhas de memória e, em alguns casos, texto sem sentido na saída.

Sintomas e Armadilhas

No início, tudo parecia praticamente funcional. A placa gráfica era detectada, os contêineres subiam, a VRAM se preenchia, o que significava que o sistema aparentemente estava realmente usando a GPU. Mas era uma armadilha: memória ocupada não significa necessariamente que os cálculos estão acontecendo corretamente no processador gráfico.

O principal problema se manifestava no momento da inferência real — as requisições caíam com erros hipMemGetInfo ou terminavam em geração estranha que superficialmente parecia o funcionamento do modelo, mas na verdade não produzia resultado significativo.

GPU era detectada, VRAM era ocupada, contêineres eram executados — mas

a inferência caía com erros hipMemGetInfo.

Este caso ilustra bem um erro típico ao executar LLM localmente: olhar apenas para a "aparência de vida" da infraestrutura. Se o Kubernetes iniciou o contêiner, o Ollama viu o modelo, e a GPU ocupou alguns gigabytes, isso ainda não confirma que a pilha ROCm está realmente executando operações matriciais corretamente. Para placas antigas como a RX580, é especialmente importante verificar não apenas a disponibilidade do dispositivo, mas também o compute-path real, porque a falha pode estar escondida abaixo do nível da própria aplicação.

Como Encontraram a Causa

A raiz do problema foi reduzida não através de outra reinstalação de pacotes, mas através do diagnóstico do circuito computacional. O autor comparava sinais de funcionamento em diferentes camadas do sistema e separava sucessos cosméticos da execução real de inferência. Vulkan se tornou inesperadamente a ferramenta-chave aqui: ajudou a verificar se a GPU conseguia executar tarefas computacionais de forma estável e, assim, evidenciou que o problema não era reduzível apenas ao Ollama ou à configuração do contêiner.

Essencialmente, a investigação foi dos sintomas para hipóteses testáveis. Em vez de adivinhar pelos logs, o autor eliminou sistematicamente explicações falsas e montou uma configuração minimamente funcional, verificando cada camada separadamente: desde contêineres e runtime até drivers e o próprio modelo. Essa ordem é importante porque permite entender onde a "infraestrutura surgiu" termina e o pipeline computacional real começa.

Na análise, ficou assim passo a passo:

• Verificação do compute real de GPU, não apenas uso de VRAM
• Comparação do comportamento de ROCm e Vulkan
• Filtragem de problemas de contêiner e orquestração
• Busca de versões compatíveis de kernel e ROCm
• Controle da qualidade da própria saída do modelo

Essa abordagem é importante 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 de pesos, mas no funcionamento incorreto da computação, incompatibilidade de drivers ou um backend parcialmente funcional que apenas parece vivo na superfície. Esses estados semifuncionais normalmente consomem mais tempo que falha completa porque se disfarçam de bugs aleatórios da aplicação.

Configuração Funcional em RX580

O experimento terminou não com "ajuste mágico", mas com uma combinação encontrada de versões e componentes sob a qual a antiga RX580 realmente produz resultados estáveis. O autor escreve que versões específicas de ROCm e do kernel Linux se mostraram funcionais, e após resolver conflitos, a inferência parou de cair e começou a produzir texto normal. Esta é uma conclusão importante para quem tenta executar modelos locais em gráficos AMD não tão novos: o sucesso aqui depende menos do suporte nominal de hardware do que do alinhamento exato das camadas de driver, sistema e runtime.

O resultado prático parece convincente: na RX580, conseguiram obter cerca de 42 tokens por segundo. Para uma placa gráfica doméstica da geração passada, isso não é apenas uma demonstração, mas um modo operacional em que você pode testar assistentes locais, protótipos de cenários RAG e serviços de inferência pessoais sem necessariamente fazer upgrade para uma pilha NVIDIA fresca. Mas a lição principal não está no número de velocidade, mas no método: se a GPU está "aparentemente funcionando", isso não é suficiente. O que precisa ser verificado é a estabilidade dos cálculos, a correção da saída e a reprodutibilidade dos resultados.

O Que Significa

A história da RX580 mostra que a inferência LLM local em hardware AMD antigo é possível, mas requer disciplina no diagnóstico. Para desenvolvedores, este é um bom guia: não confunda VRAM ocupada com operação real do modelo, verifique toda a pilha do kernel ao runtime, e trate saída estranha como um erro completo, não como um problema menor. Para laboratórios domésticos, isso é praticamente uma lista de verificação pronta para não gastar dias perseguindo sinais falsos de sucesso.