ROCm vs Vulkan para Hospedagem Local de LLMs da AMD: Guia 2026

Escolha o backend AMD adequado para cada engine

Conteúdo da página

Tanto o ROCm quanto o Vulkan aceleram GPUs AMD para a hospedagem local de LLMs, mas eles não são intercambiáveis. A escolha certa depende do motor, da GPU e da carga de trabalho.

Na hospedagem local de LLMs, os dois backends ocupam camadas diferentes. O ROCm é a plataforma de computação da AMD sob o PyTorch, vLLM e SGLang, enquanto o Vulkan é uma API de GPU portátil que motores da classe llama.cpp usam para executar modelos quantizados em uma ampla variedade de hardware.

Backends ROCm e Vulkan para hospedagem local de LLMs em AMD

Este guia compara os dois motores um a um — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI e LocalAI — com comandos de compilação, verificações de dispositivo e modos de falha que se disfarçam de problemas de desempenho. Se você é novo no cenário de hospedagem, comece pela visão geral da Hospedagem de LLMs, que mapeia as famílias de ferramentas que este artigo examina em detalhe.

ROCm vs Vulkan: a resposta curta

Situação Ponto de partida recomendado Por quê
llama.cpp com GGUF no Linux Vulkan Pequena superfície de instalação, ampla cobertura de GPUs e fácil reversão
llama.cpp em uma GPU RDNA 3 ou RDNA 4 suportada Benchmark de ambos O desempenho do kernel muda com a forma do modelo, quantização, contexto e compilação
Ollama em uma GPU AMD listada ROCm primeiro, verifique Vulkan também O Ollama suporta ambos, mas a escolha do backend é menos explícita do que no llama.cpp puro
LM Studio em uma GPU AMD de desktop Vulkan primeiro A troca de runtime torna a comparação fácil e evita uma pilha de computação em todo o sistema
vLLM ou SGLang ROCm, mas verifique a cobertura de kernels da família de GPU Estes são pilhas PyTorch/HIP; o Vulkan não é um backend alternativo, e arquiteturas recém-lançadas ainda podem faltar kernels otimizados
TGI em hardware Instinct suportado ROCm O caminho do contêiner AMD publicado visa as famílias MI210, MI250 e MI300
GPU Radeon mais antiga ou não listada Vulkan Os drivers Vulkan geralmente cobrem mais hardware gráfico do que as bibliotecas ROCm
Servidor AMD Instinct ROCm Computação multi-GPU, RCCL, kernels de framework e ferramentas operacionais estão aqui
Servimento de GGUF local no Windows Vulkan É geralmente o caminho menos restritivo para runtimes da classe llama.cpp
Ryzen AI Max ou outra APU de memória grande Vulkan primeiro, então ROCm se necessário Ambos podem funcionar, mas a memória compartilhada e o suporte a kernels exigem testes específicos de carga de trabalho

Esta tabela é uma política inicial, não um resultado de benchmark. Um backend que detecta a GPU, mas deixa algumas operações na CPU, pode parecer saudável enquanto performa mal, portanto, toda decisão final precisa de inspeção de logs e um teste ponta a ponta de prompt.

O que são realmente o ROCm e o Vulkan

ROCm é uma plataforma de computação

O ROCm inclui o runtime HIP, compilador, bibliotecas matemáticas, comunicação coletiva, perfis e pacotes de framework necessários para executar cargas de trabalho de computação AMD. É a fundação do lado AMD sob as compilações do PyTorch e motores como vLLM e SGLang, e também pode acelerar o llama.cpp através de seu backend HIP.

Essa amplitude é a vantagem e o custo do ROCm. O driver do host, o alvo da GPU, as bibliotecas de espaço de usuário, a roda do framework, a versão do kernel e a imagem do contêiner devem formar um conjunto compatível; quando o fazem, o ROCm oferece muito mais do que geração de tokens através de um único executável local.

O ROCm 10.0.0, lançado em 26 de agosto de 2026, é construído sobre o TheRock (o sistema de compilação e lançamento da AMD desde o ROCm 7.14), valida o PyTorch 2.13, vLLM 0.27 e SGLang 0.5.15, e adiciona formalmente o suporte a RDNA 4 para gfx1200 (RX 9060/9060 XT/9050) e gfx1201 (RX 9070/9070 XT/9070 GRE, série Radeon AI PRO R9700). A matriz de compatibilidade do ROCm ainda é a autoridade para uma combinação exata de GPU e sistema operacional, não uma postagem de fórum que acontece de usar a mesma família de marketing.

Vulkan é uma interface de GPU portátil

O Vulkan é uma API de gráfico e computação implementada por um driver de GPU. Na hospedagem local de LLMs, isso normalmente significa que um motor de inferência empacota ou compila shaders de computação que executam através de uma implementação Vulkan, como a Mesa RADV no Linux ou o driver do fornecedor no Windows.

O Vulkan não fornece uma plataforma PyTorch plugável comparável ao ROCm. Sua força prática é mais estreita e útil: um motor do estilo llama.cpp pode usar o mesmo design de backend em hardware AMD, Intel, Nvidia e outros capazes de Vulkan, sem instalar uma pilha de aprendizado de máquina específica do fornecedor.

Essa distinção explica a maior parte da decisão. Se a aplicação oferece apenas um caminho HIP ou PyTorch, o Vulkan não pode salvá-la; se a aplicação já é baseada no llama.cpp e GGUF, instalar toda a pilha ROCm pode resolver um problema que você não tinha.

Matriz de suporte por motor em 2026

Motor ROCm ou HIP Vulkan Formato de modelo típico Nota prática
llama.cpp / llama-server Sim Sim GGUF Melhor plataforma para um teste A/B controlado de backend
Ollama Sim Sim Modelos GGUF derivados gerenciados Conveniente, mas a seleção do backend e o empacotamento são abstraídos
LM Studio Sim Sim GGUF e formatos gerenciados pelo produto Runtimes selecionáveis tornam o teste de desktop acessível
vLLM Sim Não Safetensors e quantizações suportadas Use a imagem ou conjunto de rodas ROCm combinado da AMD; verifique a cobertura de kernels da família de GPU primeiro
SGLang Sim Não Safetensors e quantizações suportadas O ROCm faz parte da arquitetura de implantação
TGI Sim Não Safetensors e quantizações suportadas A validação AMD publicada permanece focada em Instinct
LocalAI Sim Sim Dependente do backend, comumente GGUF Usa imagens de contêiner ROCm e Vulkan diferentes

O ROCm não implica Safetensors, e o Vulkan não implica formalmente GGUF. A associação útil vem dos motores: o llama.cpp pode ler o mesmo GGUF com sua compilação HIP ou Vulkan, enquanto servidores nativos do PyTorch usam ROCm e geralmente consomem repositórios de modelos do Hugging Face.

Isso torna o inventário de modelos uma restrição arquitetural. Uma biblioteca de quantizações GGUF cuidadosamente selecionadas aponta naturalmente para llama-server, Ollama, LM Studio ou LocalAI; uma implantação construída em torno de paralelismo de tensor, lote contínuo e pesos nativos do framework aponta para ROCm com vLLM ou SGLang. Para o cenário mais amplo de motores além dos backends AMD — maturidade de API, chamada de ferramentas e prontidão para produção em uma dúzia de ferramentas — veja nossa comparação de Ollama, vLLM, LM Studio, LocalAI e outras ferramentas de hospedagem local de LLMs.

llama.cpp: a comparação ROCm vs Vulkan mais limpa

O llama.cpp expõe ambos os backends sem alterar o arquivo do modelo ou o cliente HTTP. Este é o lugar mais justo para comparar ROCm e Vulkan porque o tokenizer, configurações de amostragem, modelo de chat, quantização e comportamento do servidor podem permanecer fixos.

A documentação atual de compilação do llama.cpp usa GGML_HIP para ROCm e GGML_VULKAN para Vulkan. Artigos antigos que recomendam GGML_ROCM ou as bandeiras removidas do Makefile não devem ser confiados sem verificar as opções CMake atuais do projeto.

Construa o backend Vulkan no Ubuntu

Instale os cabeçalhos Vulkan, o compilador de shader e os cabeçalhos SPIR-V, então verifique que o driver pode enumerar a GPU pretendida:

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

Em um sistema com iGPU e GPU discreta mistos, a ordem de enumeração merece atenção. GGML_VK_VISIBLE_DEVICES pode restringir o llama.cpp a um dispositivo Vulkan específico, e o log de inicialização deve nomear o cartão selecionado, em vez de meramente reportar que um dispositivo Vulkan existe.

Construa o backend ROCm ou HIP

Primeiro confirme que o ROCm identifica a GPU e relata o alvo gfx esperado. O alvo pode ser omitido para compilar para as GPUs do sistema atual, mas fixá-lo reduz o trabalho de compilação quando você conhece o hardware de implantação.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

Substitua gfx1201 pelo alvo reportado para o cartão real — esse valor mapeia para a família RX 9070/9070 XT/9070 GRE e Radeon AI PRO R9700 no RDNA 4, enquanto gfx1200 cobre a série RX 9060 e gfx1100/gfx1101/gfx1102 cobrem as linhas RX 7900/7800/7700/7600 do RDNA 3. Não copie HSA_OVERRIDE_GFX_VERSION para um serviço de produção apenas porque ajudou alguém a iniciar uma GPU não suportada; uma sobrescrita pode fazer o código carregar, mas não transforma esse hardware em uma plataforma validada.

Benchmark da mesma carga de trabalho, não dois padrões

Use um arquivo GGUF, a mesma configuração de flash-attention, o mesmo offload de camada e execuções repetidas. O processamento de prompt (pp) e a geração de tokens (tg) exercitam o sistema de forma diferente, enquanto um servidor de contexto longo também adiciona alocacao de KV-cache e pressão de memória que um benchmark sintético curto perderá.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

Os resultados da comunidade ilustram por que um vencedor universal é enganoso, e o alvo gfx1201 do RDNA 4 é o exemplo recente mais claro. Em uma submissão da mesma máquina RX 9070 XT, o Vulkan alcançou cerca de 143 tokens/s contra 128 tokens/s do ROCm no teste de geração 7B Q4_0, mas submissões posteriores mostraram lacunas menores conforme as compilações mudaram; as discussões de Vulkan e ROCm também contêm grandes diferenças nos resultados de processamento de prompt e condições de teste. Uma execução separada e mais detalhada do OpenBenchmarking.org em um RX 9070 XT com llama.cpp b6401 encontrou o Vulkan à frente na decodificação em vários modelos de classe 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0), mas atrás do HIP no processamento de prompt em comprimentos de prompt maiores — os dois backends trocam a liderança dependendo de qual fase você mede.

A lacuna também pode correr na direção oposta, e em grande escala, para formas de modelo específicas. Uma questão aberta do llama.cpp documenta o Vulkan no gfx1201 tornando-se 4.7–6.7x mais lento que o HIP na geração de tokens assim que o tamanho oculto do modelo atinge 4096 ou acima (a largura de banda de decodificação efetiva colapsando para cerca de 70–100 GB/s em um cartão de 640 GB/s), enquanto um modelo menor 4B com tamanho oculto 2560 não mostra tal regressão em nenhum dos backends. Trate cada número aqui como uma instantânea de uma compilação, um driver e uma forma de modelo — não como uma regra que generaliza entre tipo de quantização, arquitetura de modelo, flash attention, tamanhos de lote, versão do driver, estado térmico ou o commit do llama.cpp.

Ollama em AMD: conveniente, mas verifique o backend

O Ollama suporta oficialmente GPUs AMD listadas através do ROCm e agora documenta cobertura adicional AMD através do Vulkan no Windows e Linux. Sua página atual de suporte a hardware diz que o Vulkan é ativado por padrão quando o backend é instalado, suporta GGML_VK_VISIBLE_DEVICES para seleção de dispositivo e pode desativar o Vulkan com OLLAMA_VULKAN=0.

Esta é uma melhoria significativa sobre o período em que o conselho Vulkan dependia de compilações experimentais. Isso também torna alguns tutoriais antigos obsoletos: definir um interruptor não documentado e assumir que o serviço selecionou o Vulkan é uma evidência mais fraca do que ler o log do servidor.

sudo systemctl edit ollama

Para diagnósticos, adicione um drop-in em vez de exportar variáveis apenas em um shell interativo:

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Em seguida, recarregue, reinicie e inspecione tanto a colocação do processo quanto as mensagens de descoberta:

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

Procure pelo GPU nomeado, biblioteca selecionada, alocação do modelo e porcentagem de GPU. Um log que mostra um tempo limite de descoberta seguido por uma resposta HTTP bem-sucedida pode significar que o Ollama caiu silenciosamente para a CPU. Para o conjunto de comandos diários em torno deste serviço, a folha de dicas da CLI do Ollama é a referência mais rápida.

O Ollama é excelente quando a aquisição de modelo e uma API local estável importam mais do que o controle do backend. Se o teste repetível de ROCm versus Vulkan é o objetivo, o llama-server puro é o instrumento melhor porque o diretório de compilação torna o backend explícito.

vLLM e SGLang tornam o ROCm a decisão — mas verifique a cobertura de kernels da família de GPU primeiro

O vLLM e o SGLang não são aplicações Vulkan. Seus caminhos AMD estão sobre o ROCm, PyTorch e kernels HIP otimizados, portanto, escolher um desses motores já selecionou a plataforma de computação.

O guia atual da vLLM no ROCm da AMD recomenda um contêiner pré-construído e publica imagens combinadas para ROCm, PyTorch, Python e vLLM. Essa acoplamento é útil: ele substitui um grande exercício de solução de dependências por uma unidade de implantação versionada.

No momento da escrita, a AMD documenta esta imagem ROCm 10 para vLLM 0.27:

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

Use a imagem selecionada para a família exata de GPU na documentação da AMD; as imagens RDNA e CDNA nem sempre foram intercambiáveis. Para um servidor de produção, fixe o tag completo ou digest e valide o driver do host antes de culpar o vLLM por uma falha de inicialização.

Gerações novas de GPU são o caso de borda mais afiado, e o RDNA 4 é um exemplo real e documentado, não um risco teórico. Testes independentes em um RX 9070 XT (gfx1201) no início de 2026 encontraram o vLLM no ROCm 7.2 caindo silenciosamente para desquantização FP32 para pesos de modelo FP8 — porque o gfx1201 ainda não era reconhecido na detecção de plataforma do vLLM — o que bypassou completamente os aceleradores de matriz da GPU e produziu apenas 48 tokens/s, contra 62 tokens/s do llama-server no Vulkan executando uma quantização GGUF de um modelo comparável no mesmo cartão. A lição generaliza: uma pilha ROCm/PyTorch pode carregar com sucesso em uma nova arquitetura e ainda assim executar um caminho de fallback não otimizado sem mensagem de erro. Sempre confirme qual caminho de kernel realmente executou (via rocprof, notas de perfis do fornecedor ou uma linha de base de throughput conhecida-bom para a GPU) antes de confiar em um único resultado de “começou bem” em hardware que foi lançado nos últimos dois ciclos de lançamento.

O motivo para aceitar a maior superfície operacional do ROCm, uma vez confirmada a cobertura de kernels, é a arquitetura de throughput — não meramente alguns tokens/s a mais em um teste de usuário único. Lote contínuo, quantização nativa do framework, paralelismo de tensor, comportamento do agendador e as ferramentas PyTorch circundantes são o caso real para migrar para o vLLM, e se você está ponderando se essa mudança é justificada em primeiro lugar, nosso guia de migração de Ollama para vLLM lista os sinais de carga de trabalho.

TGI: suporte ROCm com um alvo mais estreito

O Hugging Face documenta uma imagem AMD para Text Generation Inference, mas sua validação publicada está centrada em hardware Instinct MI210, MI250 e MI300. O guia TGI AMD usa a imagem 3.3.5-rocm e lista recursos ROCm não suportados, portanto, não deve ser generalizado para uma promessa para cada cartão Radeon. Nosso guia de instalação do TGI cobre essa configuração de imagem ROCm em mais detalhe.

Não há um caminho Vulkan TGI para comparar. Se o TGI é um requisito fixo, escolha hardware ROCm suportado e reproduza o contêiner documentado; se o motor é negociável, o suporte atual do vLLM e SGLang merece avaliação antes de começar uma nova implantação AMD.

LM Studio: troque runtimes em vez de recompilar

O LM Studio empacota múltiplos runtimes de inferência e expõe o gerenciamento de runtime através do comando lms. Sua documentação de runtime suporta listagem, download, seleção, atualização e remoção de runtimes, o que torna os experimentos ROCm versus Vulkan acessíveis sem manter árvores de fonte separadas.

lms runtime ls
lms runtime get
lms runtime select

Execute o mesmo GGUF com o mesmo comprimento de contexto, offload de GPU, configuração de flash-attention e prompt. Compare o tempo até o primeiro token, a taxa de geração, o tempo de carregamento e a memória de pico, em vez de julgar um backend por uma única resposta curta de chat.

O empacotamento de runtime não elimina falhas específicas do backend. Por exemplo, uma questão do LM Studio em um R9700 em 2026 reportou um grande modelo travando perto do final de um carregamento ROCm enquanto o runtime Vulkan o carregava, enquanto uma questão separada de espaço de memória Vulkan descreveu o resultado oposto perto da VRAM total. Estes são relatos individuais, mas juntos fazem o ponto operacional certo: mantenha um runtime de fallback e deixe margem de memória.

LocalAI: escolha a imagem bem como o backend

O LocalAI fornece variantes separadas de contêiner ROCm ou hipblas e Vulkan. Seu guia de aceleração de GPU documenta imagens gpu-hipblas para computação AMD e imagens gpu-vulkan para o caminho portátil, portanto, um tag de contêiner copiado de um guia CUDA não descobrirá o backend correto por magia. O quickstart do LocalAI cobre a configuração geral; a escolha de contêiner específica do backend é o que esta seção adiciona.

O contêiner ROCm precisa de /dev/kfd e /dev/dri, enquanto o Vulkan normalmente precisa do dispositivo de render apropriado sob /dev/dri. Fixe um tag de lançamento para um serviço real; latest e master são úteis para diagnóstico, mas tornam a reversão e a comparação de desempenho desnecessariamente vagos.

# Imagem ROCm ou HIP
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Imagem Vulkan
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

Os exemplos de tag refletem a documentação disponível no momento da publicação; confirme os nomes atuais do registro antes de automatizar um pull. Mais importante, não infira aceleração apenas pelo nome do contêiner — inspecione o log de depuração do LocalAI e observe a utilização de GPU durante uma requisição.

O que mudou no empacotamento do ROCm 10

O ROCm 10 não é apenas outra atualização menor de pacote. O guia de transição TheRock da AMD diz que os pacotes do Core SDK do ROCm agora usam o prefixo amdrocm-, a raiz de instalação versionada é /opt/rocm/core-10.0, e vários pacotes legados foram consolidados.

É por isso que um comando de um artigo antigo do ROCm pode retornar “pacote não encontrado” mesmo em um repositório corretamente configurado. Por exemplo, o HIPCC agora vem de amdrocm-llvm, os componentes BLAS são combinados em amdrocm-blas, e uma instalação completa do sistema pode usar um meta-pacote Core SDK de todas as arquiteturas ou específico da família de GPU — cartões RDNA 4 usam a tag de família gfx120X-all (sufixo de pacote -gfx1200-gfx1201), o que vale a pena saber antes de procurar por um nome de pacote apenas para gfx1201 que não existe.

O meta-pacote amdrocm configura alternativas e links de compatibilidade sob /opt/rocm. Uma instalação mínima ou personalizada pode não fornecer os mesmos caminhos, portanto, scripts de compilação que codificam duramente /opt/rocm/bin/hipcc devem usar hipconfig ou definir ROCM_PATH explicitamente.

Duas mudanças de diagnóstico são fáceis de perder. O ROCm SMI foi removido em favor do AMD SMI, e o ROCm Bandwidth Test atingiu o fim da vida; scripts que chamam rocm-smi ou rocm-bandwidth-test precisam migrar para amd-smi e as ferramentas substitutas da AMD em vez de reinstalar pacotes legados arbitrários.

Contêineres ainda dependem do host

Um contêiner ROCm carrega bibliotecas de espaço de usuário, não um driver de kernel substituto. O host deve expor /dev/kfd e /dev/dri, seu driver deve ser compatível com a pilha do contêiner, e o usuário do serviço precisa de permissão para abrir esses dispositivos.

Contêineres Vulkan têm uma fronteira similar em torno do driver Vulkan do host e do nó de render. O empacotamento é mais leve, mas um ICD incorreto, falta de associação de grupo de render ou uma iGPU selecionada acidentalmente ainda podem transformar uma imagem de contêiner funcionando em um serviço limitado a CPU ou instável.

GPUs discretas, APUs e cartões Radeon mais antigos

GPUs discretas RDNA 3 e RDNA 4

Os modelos atuais Radeon RX 7000, RX 9000 e Radeon AI Pro têm o caso mais forte para testar ambos os backends do llama.cpp. O suporte ROCm agora é explícito para muitos alvos gfx110x e gfx120x, enquanto o Vulkan através de uma Mesa RADV atual ou driver de fornecedor do Windows é maduro o suficiente para ser uma rota primária em vez de um fallback desesperado. Para o lado de hardware dessa decisão — VRAM, largura de banda, potência e preços entre fornecedores — veja nossa comparação de GPUs para cargas de trabalho de IA em 2026.

Não converta um benchmark 7B em uma regra para um modelo denso 27B ou um modelo mixture-of-experts. Formas de matriz, parâmetros ativos, kernels quantizados, comprimento de prompt e pressão de memória podem mudar a ordem, e o desempenho do backend se moveu substancialmente entre revisões do llama.cpp — a regressão de tamanho oculto gfx1201 notada acima é um caso concreto de exatamente esse tipo de mudança.

APUs Ryzen e memória compartilhada

Sistemas Ryzen AI Max de memória grande são incomumente interessantes porque a GPU pode acessar um pool de memória compartilhada muito maior do que um cartão discreto de consumidor normal oferece. O ROCm 10 lista as famílias Ryzen AI atuais, enquanto runtimes llama.cpp capazes de Vulkan também podem usar a iGPU sem construir um ambiente PyTorch.

Capacidade não é largura de banda. Um modelo que cabe em 64 GB ou 96 GB de memória compartilhada alocada não significa que ele vai decodificar como um cartão discreto de 32 GB, e uma alocação agressiva de contexto pode sufocar o sistema operacional mesmo quando uma aplicação relata memória GPU abundante. A mesma disciplina de orçamento de VRAM que se aplica a cartões NVIDIA e AMD discretos se aplica aqui também — veja KV Cache em GPUs de 16 GB para a matemática de orçamento subjacente, que é agnóstica de backend.

Máquinas com iGPU e dGPU mistas precisam de seleção explícita de dispositivo. Um relato recente do llama.cpp descreveu reserva excessiva de memória de sistema quando uma iGPU não usada permaneceu visível ao lado de um R9700; é uma questão não confirmada, mas é uma boa razão para expor apenas o dispositivo que o serviço está destinado a usar.

Hardware Radeon mais antigo e não suportado

O Vulkan é geralmente a primeira rota para um Radeon mais antigo porque a cobertura do driver gráfico é mais ampla do que o conjunto de alvos de computação suportados do ROCm. Projetos baseados em ROCm também notam que lançamentos mais novos do rocBLAS removeram kernels para alguns alvos mais antigos, portanto, forçar um valor gfx próximo não pode restaurar código que não é mais distribuído.

Uma sobrescrita é aceitável para um experimento de laboratório com expectativas de falha claras. É uma fundação pobre para uma API não supervisionada, porque a próxima atualização do ROCm ou da aplicação pode substituir um mismatch tolerado por uma falha de inicialização ou resultado incorreto.

Linux vs Windows para backends de LLM AMD

O Linux é o host ROCm natural para inferência de produção. Ele oferece o suporte mais amplo de motores, mapeamento de dispositivos de contêiner estabelecido, drivers Vulkan Mesa atuais e as ferramentas operacionais esperadas por implantações vLLM e SGLang.

O Windows tem suporte ROCm genuíno para hardware listado, mas o ecossistema de aplicações permanece mais estreito. Para inferência de GGUF de desktop através do llama.cpp, Ollama ou LM Studio, o Vulkan é geralmente o ponto de partida mais calmo; use o ROCm quando a aplicação fornece um caminho Windows suportado e um recurso ou benchmark concreto o justifica.

O WSL2 deve ser tratado como uma terceira plataforma, não como um sinônimo para Linux nativo. Combine o driver Windows documentado da AMD, a distribuição WSL, o lançamento do ROCm e o pacote de framework como uma combinação suportada.

Lista de verificação de verificação antes de servir tráfego

Comece abaixo da aplicação. Se o driver não pode enumerar o dispositivo correto, mudar bandeiras de modelo é apenas rearranjar o sintoma.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# Caminho ROCm
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Caminho Vulkan
vulkaninfo --summary

Então verifique o motor. A saída de inicialização deve nomear o ROCm ou Vulkan, nomear o GPU pretendido e relatar que camadas ou tensores do modelo foram colocados nele; finalmente, a memória e a utilização de GPU devem subir enquanto uma requisição está em execução.

# Observe um GPU AMD enquanto outro terminal envia requisições
watch -n1 amd-smi monitor

# Verificação básica de API compatível com OpenAI para llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Registre o driver, o runtime, o commit do motor ou digest da imagem, o checksum do arquivo do modelo, o contexto, as configurações de lote e a linha de comando com cada benchmark. Sem esses metadados, um número de tokens por segundo é uma anedota que não sobrevive à próxima atualização — e como o fallback vLLM-no-gfx1201 e a regressão de tamanho oculto Vulkan acima mostram ambos, um número plausível pode esconder um caminho de código silenciosamente não otimizado.

Modos de falha que parecem com desempenho de backend

Fallback silencioso para CPU

O servidor inicia e responde corretamente, mas a geração é inesperadamente lenta e a utilização de GPU permanece plana. Verifique os logs de descoberta, permissões de dispositivo, offload do modelo e dispositivos do contêiner antes de ajustar threads ou parâmetros de amostragem.

Fallback silencioso de precisão (hardware novo, kernels novos)

O servidor inicia, a utilização de GPU parece razoável e não há erro — mas o framework caiu silenciosamente para um caminho numérico não otimizado porque a capacidade de computação da GPU ou a string de arquitetura ainda não era reconhecida. É exatamente o que aconteceu com os kernels FP8 do vLLM no gfx1201; a correção é verificar o código de detecção de plataforma próprio do framework ou o rastreador de questões para sua string exata de GPU antes de confiar em um único número de throughput em uma geração de GPU lançada nos últimos dois ciclos de lançamento.

O GPU errado é selecionado

Um desktop Ryzen pode expor uma iGPU como dispositivo Vulkan 0 e um Radeon discreto como dispositivo 1. Restrinja os dispositivos visíveis e confirme o nome completo do dispositivo no log; não assuma que a numeração é estável após uma mudança de driver ou BIOS.

Mismatch de alvo ROCm

O rocminfo relata um alvo gfx enquanto a imagem da aplicação contém kernels para outro conjunto. Use uma imagem correspondente ou recompilar para o alvo exato; reserve HSA_OVERRIDE_GFX_VERSION para experimentos explicitamente não suportados.

Mismatch de driver e espaço de usuário

O contêiner tem bibliotecas ROCm atuais, mas o driver do host pertence a uma stream de lançamento mais antiga. Tempos limite durante a descoberta, erros de lançamento de kernel ou um fallback para CPU são mais prováveis do que uma mensagem limpa explicando a fronteira de versão.

Confusão de ICD Vulkan

Mais de uma implementação Vulkan está instalada, e o carregador seleciona um ICD inesperado. Inspecione vulkaninfo, remova duplicatas acidentais ou selecione o ICD e dispositivo pretendidos explicitamente em vez de caminhar outro SDK sobre o problema.

Estimas de VRAM não deixam margem operacional

O modelo parece caber, mas falha durante o aquecimento, configuração de flash-attention ou o primeiro prompt longo. Deixe alguns gigabytes de folga em um modelo grande, então reduza o contexto ou o tamanho do lote antes de concluir que o backend não pode executar a quantização.

Um procedimento prático de seleção de backend

Passo 1: escolha o comportamento de servimento

Se o objetivo é um ou dois usuários locais, arquivos GGUF e um endpoint compatível com OpenAI simples, comece com llama-server, Ollama ou LM Studio. Se o objetivo é lote contínuo, alta concorrência, modelos nativos do framework ou paralelismo de tensor, comece com vLLM ou SGLang e aceite o ROCm como parte do design.

Passo 2: verifique o suporte oficial a hardware

Combine o alvo exato de GPU, versão do sistema operacional, kernel e driver na matriz ROCm atual. Para Vulkan, confirme o GPU pretendido através de vulkaninfo e use um driver atual em vez de assumir que a presença de libvulkan.so prova suporte de computação útil. Se a GPU é da geração de arquitetura mais nova, também verifique o código de detecção de plataforma específico do framework ou as questões abertas para esse alvo gfx exato — o suporte oficial e o suporte a kernels otimizados nem sempre são lançados juntos.

Passo 3: estabeleça a linha de base de trabalho mais simples

Para GGUF, o Vulkan é normalmente essa linha de base porque altera menos componentes do sistema. Para um motor PyTorch, use o contêiner ROCm fixado da AMD em vez de montar torch, Triton, AITER e vLLM de versões latest não relacionadas.

Passo 4: benchmark de prompts com forma de produção

Meça o processamento de prompt, tempo até o primeiro token, taxa de decodificação, memória de pico e comportamento de requisições concorrentes. Inclua o padrão de contexto e chamada de ferramentas que o serviço real usará; um microbenchmark de 128 tokens não prevê uma sessão de agente de 100.000 tokens.

Passo 5: mantenha o fallback implantável

Dois diretórios de compilação do llama.cpp custam pouco comparado a um dia perdido para uma regressão de driver. Mantenha o digest de contêiner ou runtime conhecido-bom anterior instalado, e avance apenas após o candidato passar no mesmo conjunto de testes.

O mesmo procedimento como um fluxo de decisão:

flowchart LR A["Escolha o motor de servimento"] --> B{"Motor PyTorch/HIP?"} B -- Sim --> C["ROCm: contêiner fixado
+ verificação de cobertura de kernels"] B -- Não --> D{"GGUF em GPU AMD?"} D -- Sim --> E["Linha de base Vulkan"] E --> F{"Benchmark: ROCm vence
por uma margem mensurável?"} F -- Sim --> G["Mude para ROCm"] F -- Não --> H["Mantenha Vulkan,
mantenha compilação ROCm como fallback"]

Veredito final: ROCm ou Vulkan para hospedagem de LLM AMD?

O Vulkan é o melhor padrão para inferência local de GGUF quando portabilidade, velocidade de configuração, suporte Windows ou cobertura de Radeon mais antiga importam. Já não é razoável descrevê-lo como inerentemente lento; em algumas combinações recentes de Radeon e llama.cpp, ele é o backend mais rápido, e em outros está perto o suficiente que a menor fricção operacional vence.

O ROCm é a escolha correta quando o motor é construído em torno do PyTorch, quando o AMD Instinct e a computação multi-GPU são centrais, ou quando uma compilação HIP testada vence a carga de trabalho real do modelo. Seu ecossistema é muito mais forte em 2026, mas o novo empacotamento e as camadas de compatibilidade estritas ainda recompensam versões fixadas e verificação disciplinada — e na geração mais nova de RDNA especificamente, verificar que o caminho de kernel otimizado realmente executou não é opcional.

Para uma estação de trabalho Radeon suportada, minha recomendação é deliberadamente despoética: instale o Vulkan primeiro, adicione o ROCm quando um motor ou benchmark ganhar a complexidade, e mantenha ambas as compilações do llama.cpp se a máquina regularmente servir diferentes formas de modelo. O melhor backend AMD não é uma propriedade permanente do cartão; é uma propriedade do cartão, motor, modelo, driver e carga de trabalho juntos.

Referências

Subscrever

Receba novos artigos sobre sistemas, infraestrutura e engenharia de IA.