Semplificare il Deployment di LLM su Architetture aarch64

Il panorama dei Large Language Models (LLM) è in continua evoluzione, con un crescente interesse verso soluzioni di deployment on-premise che garantiscano sovranità dei dati e controllo sui costi. Tuttavia, l'implementazione di questi framework su architetture hardware specifiche può presentare sfide inaspettate. Un esempio significativo è stato il deployment di LLM come vLLM su sistemi Linux aarch64 dotati di GPU, quali le piattaforme NVIDIA GH200, GB200 e GB300. Per anni, gli sviluppatori hanno affrontato ostacoli nell'installazione di PyTorch con supporto CUDA, un componente fondamentale per l'accelerazione hardware.

La problematica risiedeva nella distribuzione dei wheel di PyTorch. Fino alla versione 2.10, un semplice comando pip install torch su sistemi aarch64 scaricava automaticamente la versione di PyTorch ottimizzata solo per CPU dal repository PyPI predefinito. Questo costringeva gli utenti a ricorrere a workaround complessi, rallentando significativamente il processo di deployment e aumentando il Total Cost of Ownership (TCO) indiretto, a causa del tempo speso in debugging e configurazione.

Il Dettaglio Tecnico del Problema e le Soluzioni Temporanee

Il problema non si limitava alla necessità di specificare un index-url personalizzato per ottenere i wheel di PyTorch abilitati per CUDA. La vera complessità emergeva con le dipendenze transitive. Se un qualsiasi pacchetto nella pipeline di vLLM richiedeva una versione specifica di torch, pip tornava al default PyPI index, disinstallando silenziosamente la build CUDA-enabled precedentemente installata e sostituendola con la versione solo CPU. Questo portava a sessioni di debugging frustranti, dove il sistema non riusciva a rilevare la GPU, nonostante un'installazione apparentemente corretta.

Per mitigare questo inconveniente, il team di vLLM ha sviluppato soluzioni temporanee. Una di queste era lo script use_existing_torch.py, introdotto a settembre 2024. Questo script modificava i file di dipendenza di vLLM, rimuovendo i requisiti di torch, torchvision e torchaudio, per impedire a pip di sovrascrivere l'installazione CUDA-enabled preesistente. Successivamente, con la maturazione di uv, è stata adottata un'opzione più elegante: l'aggiunta di [tool.uv] no-build-isolation-package = ["torch"] nel pyproject.toml. Questa configurazione istruiva uv a riutilizzare l'installazione di torch già presente nell'ambiente, evitando reinstallazioni indesiderate. Sebbene efficaci, queste soluzioni rappresentavano un onere aggiuntivo per gli sviluppatori e un'improvvisazione attorno a una lacuna nello standard di packaging.

La Collaborazione e la Risoluzione Definitiva

La svolta è arrivata grazie alla collaborazione all'interno della PyTorch Foundation. Kaichao You di Inferact, in rappresentanza di vLLM nel Technical Advisory Committee (TAC) della Foundation, ha formalmente sollevato la questione a gennaio 2026, dopo averla tracciata in un issue GitHub da agosto 2025. La richiesta era chiara: pubblicare wheel aarch64 abilitati per CUDA direttamente sul default PyPI index, replicando l'esperienza di deployment già consolidata sulle architetture x86.

Il team di ingegneri NVIDIA ha giocato un ruolo cruciale, spingendo per la pubblicazione dei CUDA SBSA wheels su PyPI e guidando l'approccio dei "small wheel" che si collegano dinamicamente a librerie come NCCL e cuBLAS. Questo ha permesso di mantenere le dimensioni dei wheel gestibili, un aspetto fondamentale per i manutentori di PyPI. La PyTorch Foundation ha dimostrato la sua efficacia nel coordinare problemi infrastrutturali tra progetti diversi, trasformando un ostacolo tecnico in un'opportunità di miglioramento sistemico.

Implicazioni per i Deployment On-Premise e l'Esperienza Sviluppatore

La risoluzione del problema è stata confermata ad aprile 2026 con il rilascio di PyTorch 2.11.0. Ora, un semplice pip install torch su sistemi Linux aarch64 installa correttamente la versione abilitata per CUDA, eliminando la necessità di index-url personalizzati o di complesse logiche di gestione delle dipendenze. Questo cambiamento, apparentemente minore, ha un impatto significativo sull'esperienza degli sviluppatori e sulle strategie di deployment on-premise.

Per le organizzazioni che investono in infrastrutture self-hosted basate su silicio aarch64, come i sistemi NVIDIA Grace Hopper e Grace Blackwell, questo significa un deployment più rapido e meno propenso a errori per i framework LLM. La riduzione del tempo dedicato alla configurazione e al debugging si traduce direttamente in un TCO inferiore e in una maggiore agilità nello sviluppo e nel rilascio di applicazioni AI. Mentre i workaround di vLLM rimangono utili per scenari avanzati (come build personalizzate di PyTorch), la via predefinita è ora notevolmente semplificata, rendendo l'adozione di queste potenti piattaforme più accessibile. Per chi valuta il deployment on-premise di LLM, AI-RADAR offre framework analitici su /llm-onpremise per valutare i trade-off tra controllo, performance e costi.