ROCm vs Vulkan per l’hosting locale di LLM su AMD: Guida 2026

ROCm e Vulkan accelerano entrambe le GPU AMD per l’hosting locale di LLM, ma non sono intercambiabili. La scelta giusta dipende dal motore, dalla GPU e dal carico di lavoro.

Nell’hosting locale di LLM, i due back-end si trovano su livelli diversi. ROCm è la piattaforma di calcolo di AMD sotto PyTorch, vLLM e SGLang, mentre Vulkan è un’API GPU portabile che i motori di tipo llama.cpp utilizzano per eseguire modelli quantizzati su un’ampia gamma di hardware.

Questa guida confronta i due back-end motore per motore — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI e LocalAI — con comandi di build, verifiche del dispositivo e modalità di guasto che si spacciano per problemi di prestazioni. Se sei nuovo nel panorama dell’hosting, inizia con la Panoramica sull’hosting di LLM, che mappa le famiglie di strumenti approfondite in questo articolo.

ROCm vs Vulkan: la risposta breve

Questa tabella è una politica di partenza, non il risultato di un benchmark. Un back-end che rileva la GPU ma lascia alcune operazioni sulla CPU può apparire sano ma performare male, quindi ogni decisione finale richiede l’ispezione dei log e un test end-to-end del prompt.

Cosa sono realmente ROCm e Vulkan

ROCm è una piattaforma di calcolo

ROCm include il runtime HIP, il compilatore, le librerie matematiche, la comunicazione collettiva, i profiler e i pacchetti framework necessari per eseguire carichi di lavoro di calcolo AMD. È la fondazione AMD sotto le build di PyTorch e motori come vLLM e SGLang, e può anche accelerare llama.cpp attraverso il suo back-end HIP.

Questa ampiezza è il vantaggio di ROCm e il suo costo. Il driver dell’host, la GPU di destinazione, le librerie user-space, la wheel del framework, la versione del kernel e l’immagine del container devono formare un insieme compatibile; quando lo sono, ROCm offre molto di più della generazione di token tramite un singolo eseguibile locale.

ROCm 10.0.0, rilasciato il 26 agosto 2026, è costruito su TheRock (il sistema di build e rilascio di AMD dal ROCm 7.14), valida PyTorch 2.13, vLLM 0.27 e SGLang 0.5.15, e aggiunge formalmente il supporto per RDNA 4 per gfx1200 (RX 9060/9060 XT/9050) e gfx1201 (RX 9070/9070 XT/9070 GRE, serie Radeon AI PRO R9700). La matrice di compatibilità ROCm rimane l’autorità per la combinazione esatta di GPU e sistema operativo, non un post di forum che per caso usa la stessa famiglia di marketing.

Vulkan è un’interfaccia GPU portabile

Vulkan è un’API di grafica e calcolo implementata da un driver GPU. Nell’hosting locale di LLM, questo significa generalmente che un motore di inferenza fornisce o compila shader di calcolo che vengono eseguiti attraverso un’implementazione Vulkan come Mesa RADV su Linux o il driver del vendor su Windows.

Vulkan non fornisce una piattaforma PyTorch drop-in paragonabile a ROCm. La sua forza pratica è più stretta e utile: un motore di tipo llama.cpp può usare lo stesso design del back-end su AMD, Intel, Nvidia e altro hardware con supporto Vulkan senza installare uno stack di machine learning specifico per il vendor.

Questa distinzione spiega la maggior parte della decisione. Se l’applicazione offre solo un percorso HIP o PyTorch, Vulkan non può salvarla; se l’applicazione è già basata su llama.cpp e GGUF, l’installazione di tutto lo stack ROCm potrebbe risolvere un problema che non avevi.

Matrice di supporto dei motori nel 2026

ROCm non implica Safetensors, e Vulkan non implica formalmente GGUF. L’associazione utile deriva dai motori: llama.cpp può leggere lo stesso GGUF con la sua build HIP o Vulkan, mentre i server nativi PyTorch usano ROCm e consumano generalmente repository di modelli Hugging Face.

Questo rende l’inventario dei modelli un vincolo architetturale. Una libreria di quantizzazioni GGUF selezionate con cura punta naturalmente verso llama-server, Ollama, LM Studio o LocalAI; un deployment costruito attorno al parallelismo tensoriale, al batch processing continuo e ai pesi nativi del framework punta verso ROCm con vLLM o SGLang. Per il panorama più ampio dei motori oltre i back-end AMD — maturità delle API, tool calling e prontezza per la produzione su una dozzina di strumenti — vedi il nostro confronto tra Ollama, vLLM, LM Studio, LocalAI e altri strumenti di hosting locale di LLM.

llama.cpp: il confronto ROCm vs Vulkan più pulito

llama.cpp espone entrambi i back-end senza modificare il file del modello o il client HTTP. Questo è il luogo più equo per confrontare ROCm e Vulkan perché tokenizer, impostazioni di sampling, template di chat, quantizzazione e comportamento del server possono rimanere fissi.

La documentazione di build llama.cpp attuale usa GGML_HIP per ROCm e GGML_VULKAN per Vulkan. I vecchi articoli che raccomandano GGML_ROCM o le flag Makefile rimosse non dovrebbero essere fidati senza controllare le opzioni CMake attuali del progetto.

Compila il back-end Vulkan su Ubuntu

Installa le intestazioni Vulkan, il compilatore shader e le intestazioni SPIR-V, quindi verifica che il driver possa enumerare la GPU prevista:

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

Su un sistema misto con iGPU e GPU discreta, l’ordine di enumerazione merita attenzione. GGML_VK_VISIBLE_DEVICES può limitare llama.cpp a un dispositivo Vulkan specifico, e il log di avvio dovrebbe nominare la scheda selezionata piuttosto che riportare semplicemente che esiste un dispositivo Vulkan.

Compila il back-end ROCm o HIP

Prima conferma che ROCm identifichi la GPU e riferisca il target gfx atteso. Il target può essere omesso per compilare per le GPU del sistema attuale, ma fissarlo riduce il lavoro di compilazione quando si conosce l’hardware di deployment.

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

Sostituisci gfx1201 con il target riportato per la scheda effettiva — quel valore corrisponde alla famiglia RX 9070/9070 XT/9070 GRE e Radeon AI PRO R9700 in RDNA 4, mentre gfx1200 copre la serie RX 9060 e gfx1100/gfx1101/gfx1102 coprono le linee RX 7900/7800/7700/7600 di RDNA 3. Non copiare HSA_OVERRIDE_GFX_VERSION in un servizio di produzione solo perché ha aiutato qualcuno a far partire una GPU non supportata; un override può far caricare il codice, ma non trasforma quell’hardware in una piattaforma validata.

Benchmark dello stesso carico di lavoro, non due predefiniti

Usa un file GGUF, la stessa impostazione flash-attention, lo stesso offload di layer ed esecuzioni ripetute. L’elaborazione del prompt (pp) e la generazione dei token (tg) sollecitano il sistema in modo diverso, mentre un server con contesto lungo aggiunge anche l’allocazione della KV-cache e la pressione sulla memoria che un benchmark sintetico corto mancherà.

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

I risultati della community illustrano perché un vincitore universale sia fuorviante, e il target gfx1201 di RDNA 4 è l’esempio recente più chiaro. In una submission su stesso macchinario RX 9070 XT, Vulkan ha raggiunto circa 143 token/s contro i 128 token/s di ROCm nel test di generazione 7B Q4_0, ma submissions successive hanno mostrato gap più piccoli man mano che le build cambiavano; le discussioni Vulkan e ROCm contengono anche grandi differenze nei risultati di elaborazione del prompt e nelle condizioni di test. Un’esecuzione separata e più dettagliata su OpenBenchmarking.org su un RX 9070 XT con llama.cpp b6401 ha trovato Vulkan in vantaggio nel decode su diversi modelli di classe 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0) ma dietro HIP nell’elaborazione del prompt a lunghezze di prompt più lunghe — i due back-end si scambiano la leadership a seconda della fase misurata.

Il gap può anche correre nella direzione opposta, e di molto, per specifiche forme di modello. Un issue open di llama.cpp documenta Vulkan su gfx1201 che diventa 4,7–6,7 volte più lento di HIP nella generazione dei token una volta che la hidden size di un modello raggiunge 4096 o superiore (la larghezza di banda di decodifica effettiva crolla a circa 70–100 GB/s su una scheda da 640 GB/s), mentre un modello 4B più piccolo con hidden size 2560 non mostra alcuna regressione su nessuno dei back-end. Tratta ogni numero qui come uno snapshot di una build, un driver e una forma di modello — non come una regola che generalizza su tipo di quantizzazione, architettura del modello, flash attention, dimensioni del batch, versione del driver, stato termico o commit di llama.cpp.

Ollama su AMD: comodo, ma verifica il back-end

Ollama supporta ufficialmente le GPU AMD elencate tramite ROCm e ora documenta una copertura aggiuntiva AMD tramite Vulkan su Windows e Linux. La sua attuale pagina di supporto hardware afferma che Vulkan è abilitato per impostazione predefinita quando il back-end è installato, supporta GGML_VK_VISIBLE_DEVICES per la selezione del dispositivo e può disabilitare Vulkan con OLLAMA_VULKAN=0.

Questo è un miglioramento significativo rispetto al periodo in cui i consigli su Vulkan dipendevano da build sperimentali. Rende anche alcuni vecchi tutorial obsoleti: impostare uno switch non documentato e assumere che il servizio abbia selezionato Vulkan è un’evidenza più debole rispetto alla lettura del log del server.

sudo systemctl edit ollama

Per le diagnostiche, aggiungi un drop-in anziché esportare variabili solo in un shell interattivo:

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

Poi ricarica, riavvia e ispeziona sia la collocazione del processo sia i messaggi di discovery:

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

ollama run qwen3:8b "Rispondi esattamente: backend test passed"
ollama ps

Cerca la GPU nominata, la libreria selezionata, l’allocazione del modello e la percentuale di GPU. Un log che mostra un timeout di discovery seguito da una risposta HTTP riuscita può significare che Ollama è retrocessa silenziosamente alla CPU. Per il set di comandi quotidiano attorno a questo servizio, la scheda rapida CLI di Ollama è il riferimento più veloce.

Ollama è eccellente quando l’acquisizione del modello e un’API locale stabile contano più del controllo del back-end. Se l’obiettivo è un test ripetibile ROCm-vs-Vulkan, llama-server nudo è lo strumento migliore perché la directory di build rende il back-end esplicito.

vLLM e SGLang rendono ROCm la decisione — ma prima verifica la copertura dei kernel per la famiglia di GPU

vLLM e SGLang non sono applicazioni Vulkan. I loro percorsi AMD si basano su ROCm, PyTorch e kernel HIP ottimizzati, quindi la scelta di uno di questi motori ha già selezionato la piattaforma di calcolo.

La guida vLLM su ROCm attuale di AMD raccomanda un container precompilato e pubblica immagini abbinate per ROCm, PyTorch, Python e vLLM. Questa accoppiata è utile: sostituisce un grande esercizio di risoluzione delle dipendenze con un’unità di deployment versionata.

Al momento della scrittura, AMD documenta questa immagine ROCm 10 per 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

Usa l’immagine selezionata per la famiglia di GPU esatta nella documentazione di AMD; le immagini RDNA e CDNA non sono state sempre intercambiabili. Per un server di produzione, fissa il tag o digest completo e valida il driver dell’host prima di incolpare vLLM per un errore di inizializzazione.

Le generazioni di GPU nuovissime sono il caso d’uso più critico, e RDNA 4 è un esempio reale e documentato, non un rischio teorico. Test indipendenti su un RX 9070 XT (gfx1201) nei primi mesi del 2026 hanno trovato vLLM su ROCm 7.2 che retrocede silenziosamente alla dequantizzazione FP32 per pesi di modello FP8 — perché gfx1201 non era ancora riconosciuto nella rilevazione della piattaforma di vLLM — il che ha aggirato completamente gli acceleratori matriciali della GPU e ha prodotto solo 48 token/s, contro i 62 token/s da llama-server su Vulkan che eseguiva una quantizzazione GGUF di un modello comparabile sulla stessa scheda. La lezione si generalizza: uno stack ROCm/PyTorch può caricare con successo su una nuova architettura e comunque eseguire un percorso fallback non ottimizzato senza alcun messaggio di errore. Conferma sempre quale percorso di kernel è stato effettivamente eseguito (tramite rocprof, note di profiling del vendor o una baseline di throughput nota-good per la GPU) prima di fidarti di un singolo risultato “è partito senza problemi” su hardware rilasciato negli ultimi uno o due cicli di rilascio.

La ragione per accettare la superficie operativa più grande di ROCm, una volta confermata la copertura dei kernel, è l’architettura di throughput — non meramente pochi token/s in più in un test single-user. Batch processing continuo, quantizzazione nativa del framework, parallelismo tensoriale, comportamento dello scheduler e gli strumenti PyTorch circostanti sono il vero caso per passare a vLLM, e se stai valutando se quel passaggio sia giustificato in assoluto, la nostra guida alla migrazione da Ollama a vLLM} elenca i segnali di carico di lavoro.

TGI: supporto ROCm con un target più stretto

Hugging Face documenta un’immagine AMD per Text Generation Inference, ma la sua validazione pubblicata è centrata su hardware Instinct MI210, MI250 e MI300. La guida TGI AMD usa l’immagine 3.3.5-rocm ed elenca funzionalità ROCm non supportate, quindi non dovrebbe essere generalizzata in una promessa per ogni scheda Radeon. La nostra guida all’installazione di TGI} copre in dettaglio quel setup dell’immagine ROCm.

Non c’è un percorso Vulkan per TGI da confrontare. Se TGI è un requisito fisso, scegli hardware ROCm supportato e riproduci il container documentato; se il motore è negoziabile, il supporto attuale di vLLM e SGLang merita valutazione prima di iniziare un nuovo deployment AMD.

LM Studio: cambia runtime invece di ricompilare

LM Studio imbalza più runtime di inferenza ed espone la gestione del runtime tramite il comando lms. La sua documentazione del runtime supporta l’elenco, il download, la selezione, l’aggiornamento e la rimozione dei runtime, il che rende accessibili gli esperimenti ROCm-vs-Vulkan senza mantenere alberi di sorgenti separati.

lms runtime ls
lms runtime get
lms runtime select

Esegui lo stesso GGUF con la stessa lunghezza del contesto, offload GPU, impostazione flash-attention e prompt. Confronta il tempo al primo token, il tasso di generazione, il tempo di caricamento e la memoria di picco invece di giudicare un back-end da una singola breve risposta di chat.

L’imballaggio del runtime non elimina i guasti specifici del back-end. Ad esempio, un issue LM Studio su R9700 del 2026 riportava un modello grande che impiccava vicino alla fine di un caricamento ROCm mentre il runtime Vulkan lo caricava, mentre un issue separato sulla memoria Vulkan descriveva l’esito opposto vicino a VRAM piena. Questi sono report individuali, ma insieme fanno il punto operativo giusto: mantieni un runtime di fallback e lascia spazio di memoria.

LocalAI: scegli l’immagine oltre al back-end

LocalAI fornisce varianti container ROCm o hipblas e Vulkan separate. La sua guida all’accelerazione GPU documenta le immagini gpu-hipblas per il calcolo AMD e le immagini gpu-vulkan per il percorso portabile, quindi un tag del container copiato da una guida CUDA non scoprirà il back-end corretto per magia. Il quickstart LocalAI} copre il setup generale; la scelta del container specifico per il back-end è ciò che questa sezione aggiunge.

Il container ROCm ha bisogno di /dev/kfd e /dev/dri, mentre Vulkan ha normalmente bisogno del dispositivo render appropriato sotto /dev/dri. Fissa un tag di rilascio per un servizio reale; latest e master sono utili per la diagnosi, ma rendono il rollback e il confronto delle prestazioni inutilmente vaghi.

# Immagine ROCm o 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

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

Gli esempi di tag riflettono la documentazione disponibile al momento della pubblicazione; conferma i nomi attuali del registry prima di automatizzare un pull. Più importante, non dedurre l’accelerazione dal solo nome del container — ispeziona il log di debug di LocalAI e osserva l’utilizzo della GPU durante una richiesta.

Cosa è cambiato nel packaging di ROCm 10

ROCm 10 non è solo un altro aggiornamento minore dei pacchetti. La guida alla transizione TheRock di AMD afferma che i pacchetti Core SDK di ROCm ora usano il prefisso amdrocm-, la radice di installazione versionata è /opt/rocm/core-10.0, e diversi pacchetti legacy sono stati consolidati.

Questo è il motivo per cui un comando da un vecchio articolo ROCm potrebbe restituire “pacchetto non trovato” anche su un repository correttamente configurato. Ad esempio, HIPCC ora proviene da amdrocm-llvm, i componenti BLAS sono combinati in amdrocm-blas, e un’installazione completa del sistema può usare un meta-pacchetto Core SDK all-architettura o specifico per la famiglia di GPU — le schede RDNA 4 usano il tag di famiglia gfx120X-all (suffisso pacchetto -gfx1200-gfx1201), il che vale la pena sapere prima di andare a caccia di un nome di pacchetto solo-gfx1201 che non esiste.

Il meta-pacchetto amdrocm configura alternative e symlink di compatibilità sotto /opt/rocm. Un’installazione minima o personalizzata potrebbe non fornire gli stessi percorsi, quindi gli script di build che hard-codano /opt/rocm/bin/hipcc dovrebbero usare hipconfig o impostare ROCM_PATH esplicitamente.

Due modifiche diagnostiche sono facili da perdere. ROCm SMI è stato rimosso a favore di AMD SMI, e ROCm Bandwidth Test ha raggiunto la fine della vita; gli script che chiamano rocm-smi o rocm-bandwidth-test devono passare a amd-smi e agli strumenti sostitutivi di AMD invece di reinstallare pacchetti legacy arbitrari.

I container dipendono ancora dall’host

Un container ROCm porta librerie user-space, non un driver di kernel sostitutivo. L’host deve esporre /dev/kfd e /dev/dri, il suo driver deve essere compatibile con lo stack del container, e l’utente del servizio ha bisogno del permesso per aprire quei dispositivi.

I container Vulkan hanno un confine simile attorno al driver Vulkan e al render node dell’host. L’imballaggio è più leggero, ma un ICD errato, l’assenza di appartenenza al gruppo render, o una iGPU selezionata accidentalmente possono comunque trasformare un’immagine container funzionante in un servizio vincolato alla CPU o instabile.

GPU discrete, APU e schede Radeon più vecchie

GPU discrete RDNA 3 e RDNA 4

I modelli attuali Radeon RX 7000, RX 9000 e Radeon AI Pro hanno il caso più forte per testare entrambi i back-end di llama.cpp. Il supporto ROCm è ora esplicito per molti target gfx110x e gfx120x, mentre Vulkan attraverso un Mesa RADV attuale o un driver vendor Windows è maturo abbastanza da essere un percorso primario piuttosto che un fallback disperato. Per il lato hardware di quella decisione — VRAM, larghezza di banda, potenza e prezzi tra vendor — vedi il nostro confronto GPU per carichi di lavoro AI nel 2026.

Non convertire un benchmark 7B in una regola per un modello denso 27B o un modello mixture-of-experts. Le forme delle matrici, i parametri attivi, i kernel quantizzati, la lunghezza del prompt e la pressione sulla memoria possono cambiare l’ordine, e le prestazioni del back-end si sono spostate sostanzialmente tra le revisioni di llama.cpp — la regressione della hidden size gfx1201 menzionata sopra è un caso concreto di esattamente questo tipo di spostamento.

APU Ryzen e memoria condivisa

I sistemi Ryzen AI Max con molta memoria sono insolitamente interessanti perché la GPU può accedere a un pool di memoria condivisa molto più grande rispetto a ciò che offre una normale scheda consumer discreta. ROCm 10 elenca le attuali famiglie Ryzen AI, mentre i runtime llama.cpp con supporto Vulkan possono anche usare la iGPU senza costruire un ambiente PyTorch.

La capacità non è larghezza di banda. Un modello che entra in 64 GB o 96 GB di memoria condivisa allocata non significa che decodificherà come una scheda discreta da 32 GB, e un’allocazione aggressiva del contesto può affamare il sistema operativo anche quando un’applicazione riferisce memoria GPU abbondante. La stessa disciplina di budget VRAM che si applica alle schede discrete NVIDIA e AMD si applica qui — vedi KV Cache su GPU da 16 GB} per la matematica del budget sottostante, che è indipendente dal back-end.

Le macchine miste iGPU e dGPU necessitano di selezione esplicita del dispositivo. Un report recente di llama.cpp ha descritto una riserva eccessiva di memoria di sistema quando una iGPU inutilizzata rimaneva visibile accanto a un R9700; è un issue non confermato, ma è una buona ragione per esporre solo il dispositivo che il servizio è destinato a usare.

Hardware Radeon più vecchi e non supportati

Vulkan è di solito il primo percorso per una Radeon più vecchia perché la copertura del driver grafico è più ampia rispetto all’insieme di target di calcolo supportati da ROCm. I progetti basati su ROCm notano anche che i nuovi rilasci di rocBLAS hanno rimosso kernel per alcuni target più vecchi, quindi forzare un valore gfx vicino non può ripristinare codice che non viene più rilasciato.

Un override è accettabile per un esperimento di laboratorio con aspettative di guasto chiare. È una base scarsa per un’API non sorvegliata, perché il prossimo aggiornamento ROCm o dell’applicazione può sostituire uno scostamento tollerato con un errore di avvio o un risultato errato.

Linux vs Windows per back-end LLM AMD

Linux è l’host naturale per l’inferenza di produzione con ROCm. Offre il supporto più ampio dei motori, mapping dei dispositivi del container consolidati, driver Vulkan Mesa attuali e gli strumenti operativi attesi dai deployment di vLLM e SGLang.

Windows ha un supporto ROCm genuino per l’hardware elencato, ma l’ecosistema delle applicazioni rimane più stretto. Per l’inferenza GGUF desktop tramite llama.cpp, Ollama o LM Studio, Vulkan è di solito il punto di partenza più calmo; usa ROCm quando l’applicazione fornisce un percorso Windows supportato e una funzionalità o un benchmark concreti lo giustificano.

WSL2 dovrebbe essere trattato come una terza piattaforma, non come un sinonimo per Linux nativo. Abbina il driver Windows documentato da AMD, la distribuzione WSL, il rilascio ROCm e il pacchetto framework come una combinazione supportata.

Checklist di verifica prima di servire traffico

Inizia sotto l’applicazione. Se il driver non può enumerare il dispositivo corretto, cambiare le flag del modello è solo riorganizzare il sintomo.

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

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

# Percorso Vulkan
vulkaninfo --summary

Poi verifica il motore. L’output di avvio deve nominare ROCm o Vulkan, nominare la GPU prevista e riferire che i layer del modello o i tensori sono stati collocati su di essa; infine, la memoria e l’utilizzo della GPU devono aumentare mentre una richiesta è in esecuzione.

# Osserva una GPU AMD mentre un altro terminale invia richieste
watch -n1 amd-smi monitor

# Verifica di base API compatibile OpenAI per 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": "Rispondi esattamente: pronto"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Registra driver, runtime, commit del motore o digest dell’immagine, checksum del file del modello, contesto, impostazioni di batch e riga di comando con ogni benchmark. Senza quei metadati, un numero di token-per-secondo è un aneddoto che non può sopravvivere al prossimo aggiornamento — e come mostrano entrambi il fallback di vLLM su gfx1201 e la regressione della hidden size Vulkan sopra, un numero dall’aspetto plausibile può nascondere un percorso di codice silenziosamente non ottimizzato.

Modalità di guasto che sembrano prestazioni del back-end

Fallback CPU silenzioso

Il server parte e risponde correttamente, ma la generazione è inaspettatamente lenta e l’utilizzo della GPU rimane piatto. Controlla i log di discovery, i permessi del dispositivo, l’offload del modello e i dispositivi del container prima di tarare thread o parametri di sampling.

Fallback di precisione silenzioso (hardware nuovo, kernel nuovi)

Il server parte, l’utilizzo della GPU sembra ragionevole e non c’è alcun errore — ma il framework è retrocesso silenziosamente a un percorso numerico non ottimizzato perché la capacità di calcolo o la stringa di architettura della GPU non era ancora riconosciuta. È esattamente ciò che è successo con i kernel FP8 di vLLM su gfx1201; la correzione è controllare il codice di rilevazione della piattaforma o l’issue tracker del framework per la tua stringa di GPU esatta prima di fidarti di un singolo numero di throughput su una generazione di GPU rilasciata negli ultimi uno o due cicli di rilascio.

Viene selezionata la GPU sbagliata

Un desktop Ryzen può esporre una iGPU come dispositivo Vulkan 0 e una Radeon discreta come dispositivo 1. Restringe i dispositivi visibili e conferma il nome completo del dispositivo nel log; non assumere che la numerazione sia stabile dopo un cambio di driver o BIOS.

Scostamento del target ROCm

rocminfo riferisce un target gfx mentre l’immagine dell’applicazione contiene kernel per un altro insieme. Usa un’immagine corrispondente o ricompila per il target esatto; riserva HSA_OVERRIDE_GFX_VERSION per esperimenti esplicitamente non supportati.

Scostamento tra driver e user-space

Il container ha librerie ROCm attuali ma il driver dell’host appartiene a un flusso di rilascio più vecchio. Timeout durante la discovery, errori di lancio del kernel o un fallback alla CPU sono più probabili di un messaggio pulito che spiega il confine di versione.

Confusione ICD Vulkan

Più di un’implementazione Vulkan è installata, e il loader seleziona un ICD inaspettato. Ispeziona vulkaninfo, rimuovi duplicati accidentali o seleziona esplicitamente l’ICD e il dispositivo previsti invece di stratificare un altro SDK sul problema.

Le stime VRAM lasciano margine operativo zero

Il modello sembra entrare ma fallisce durante il warmup, il setup flash-attention o il primo prompt lungo. Lascia diversi gigabyte di spazio su un modello grande, poi riduci contesto o dimensione del batch prima di concludere che il back-end non può eseguire la quantizzazione.

Una procedura pratica di selezione del back-end

Passo 1: scegli il comportamento di servizio

Se l’obiettivo è uno o due utenti locali, file GGUF e un endpoint compatibile con OpenAI semplice, inizia con llama-server, Ollama o LM Studio. Se l’obiettivo è batch processing continuo, alta concorrenza, modelli nativi del framework o parallelismo tensoriale, inizia con vLLM o SGLang e accetta ROCm come parte del design.

Passo 2: controlla il supporto hardware ufficiale

Abbina il target GPU esatto, la versione del sistema operativo, il kernel e il driver nella matrice ROCm attuale. Per Vulkan, conferma la GPU prevista tramite vulkaninfo e usa un driver attuale anziché assumere che la presenza di libvulkan.so dimostri supporto di calcolo utile. Se la GPU proviene dalla generazione di architettura più nuova, controlla anche il codice di rilevazione della piattaforma o gli issue open del framework specifico per quel target gfx esatto — il supporto ufficiale e il supporto dei kernel ottimizzati non vengono sempre rilasciati insieme.

Passo 3: stabilisci la baseline di lavoro più semplice

Per GGUF, Vulkan è normalmente quella baseline perché cambia meno componenti di sistema. Per un motore PyTorch, usa il container ROCm fisso di AMD anziché assemblare torch, Triton, AITER e vLLM da versioni latest non correlate.

Passo 4: benchmark di prompt di forma di produzione

Misura l’elaborazione del prompt, il tempo al primo token, il tasso di decodifica, la memoria di picco e il comportamento delle richieste concorrenti. Includi il contesto e il pattern di tool-calling che il servizio reale userà; un microbenchmark di 128 token non predice una sessione agent di 100.000 token.

Passo 5: mantieni il fallback deployabile

Due directory di build di llama.cpp costano poco rispetto a un giorno perso per una regressione del driver. Mantieni installato l’ultimo digest del container o il runtime noto-good, e procedi in avanti solo dopo che il candidato supera lo stesso set di test.

La stessa procedura come flusso decisionale:

Verdetto finale: ROCm o Vulkan per l’hosting LLM AMD?

Vulkan è la preimpostazione migliore per l’inferenza locale GGUF quando la portabilità, la velocità di setup, il supporto Windows o la copertura Radeon più vecchia contano. Non è più ragionevole descriverlo come intrinsecamente lento; su alcune combinazioni recenti di Radeon e llama.cpp è il back-end più veloce, e su altri è abbastanza vicino che l’attrito operativo inferiore vince.

ROCm è la scelta corretta quando il motore è costruito attorno a PyTorch, quando AMD Instinct e il calcolo multi-GPU sono centrali, o quando una build HIP testata vince il carico di lavoro del modello effettivo. Il suo ecosistema è molto più forte nel 2026, ma il nuovo packaging e i livelli di compatibilità rigorosi premiano ancora le versioni fisse e la verifica disciplinata — e sulla generazione RDNA più nuova in particolare, verificare che il percorso di kernel ottimizzato sia stato effettivamente eseguito non è opzionale.

Per una workstation Radeon supportata, il mio consiglio è deliberatamente poco romantico: installa Vulkan per primo, aggiungi ROCm quando un motore o un benchmark merita la complessità, e mantieni entrambe le build di llama.cpp se la macchina serve regolarmente diverse forme di modello. Il miglior back-end AMD non è una proprietà permanente della scheda; è una proprietà della scheda, del motore, del modello, del driver e del carico di lavoro insieme.

Riferimenti

• Note di rilascio ROCm 10.0.0
• Matrice di compatibilità ROCm
• Transizione TheRock e mappatura pacchetti ROCm
• Istruzioni di build HIP e Vulkan di llama.cpp
• Supporto hardware AMD e Vulkan di Ollama
• Guida all’inferenza e al servizio AMD vLLM
• Hugging Face TGI su GPU AMD
• Gestione runtime LM Studio
• Accelerazione GPU LocalAI
• Discussione sulle prestazioni Vulkan di llama.cpp
• Discussione sulle prestazioni ROCm di llama.cpp
• Angelov, I. “Inferenza locale LLM su AMD RX 9070 XT — Benchmark Vulkan vs ROCm su RDNA4.” digtvbg.com, marzo 2026. https://digtvbg.com/blog/llama-server-vulkan-rdna4-vllm-rocm-benchmark/
• “ROCm Vs. Vulkan Llama.cpp RDNA4 Radeon RX 9070 XT Benchmarks.” OpenBenchmarking.org. https://openbenchmarking.org/result/2509078-NE-ROCMVSVUL92
• "[Vulkan] Rallentamento patologico della generazione di token su RX 9070 XT (gfx1201) per modelli con hidden_size >= 4096." Issue GitHub di llama.cpp.