NVIDIA acquisisce SchedMD: il controllo dello scheduler Slurm ridefinisce la gestione delle infrastrutture AI

L'acquisizione di SchedMD da parte di NVIDIA porta sotto il controllo del produttore di GPU Slurm, il workload manager utilizzato nel 60% dei supercomputer TOP…

Contenuto

NVIDIA acquisisce SchedMD: il controllo dello scheduler Slurm ridefinisce la gestione delle infrastrutture AI

Scopri anche

NVIDIA acquisisce SchedMD: il controllo dello scheduler Slurm ridefinisce la gestione delle infrastrutture AI

NVIDIA acquisisce SchedMD: il controllo dello scheduler Slurm ridefinisce la gestione delle infrastrutture AI

In questo articolo:

Il 15 dicembre 2025 NVIDIA ha annunciato l'acquisizione di SchedMD, azienda con sede a Lehi, Utah, responsabile dello sviluppo di Slurm, il workload manager open-source che gestisce circa il 60-65% dei supercomputer della lista TOP500. La transazione, il cui valore non è stato reso pubblico, ha sollevato interrogativi tra specialisti di intelligenza artificiale e supercomputing riguardo all'impegno di NVIDIA nel mantenere un campo di gioco equo per i produttori di chip concorrenti e per i costruttori di data center AI.

Cosa fa Slurm e perché è strategico

⬆ Torna su

Slurm (originariamente acronimo di "Simple Linux Utility for Resource Management") è un sistema di gestione dei carichi di lavoro che alloca risorse computazionali, gestisce code di processi e arbitra i conflitti tra job in competizione. Quando un ricercatore sottomette un job di training o un ingegnere ML accoda un'operazione di inference, Slurm decide su quali GPU quel lavoro viene eseguito, quando inizia, quali nodi gestiscono quali porzioni di training distribuito e come vengono priorizzati i job concorrenti.

Secondo i dati di SchedMD, Slurm è utilizzato in oltre la metà dei sistemi presenti nella top 10 e nella top 100 della classifica TOP500 dei supercomputer. Il software è impiegato da sviluppatori di foundation model come Meta, Mistral e Anthropic per specifici compiti di AI training. OpenAI utilizza invece un metodo differente basato su tecnologia sviluppata da Google.

La posizione di Slurm nell'ecosistema è quella di "traffic controller" nell'infrastruttura AI globale: ogni organizzazione che utilizza Slurm ha codificato la propria filosofia di gestione delle risorse in anni di configurazione, con conoscenza istituzionale integrata nelle definizioni delle partizioni, nelle policy di quality of service e nei sistemi di accounting collegati a grant e budget.

Le origini del progetto e l'ascesa a standard de facto

⬆ Torna su

Lo sviluppo di Slurm è iniziato nel 2001 presso il Lawrence Livermore National Laboratory. All'epoca, il mondo HPC si basava su scheduler proprietari: PBS (Portable Batch System) aveva varianti diffuse ovunque, IBM LoadLeveler dominava l'ecosistema IBM, e Platform Computing LSF serviva l'HPC enterprise. LLNL cercava un resource manager che potesse scalare fino a decine di migliaia di nodi, rimanere altamente portabile tra architetture diverse e restare open-source.

La prima release del 2002 era deliberatamente semplice. Il nome mantenne poi il riferimento a Futurama pur abbandonando l'acronimo originale. Nel 2010, Morris Jette e Danny Auble, sviluppatori principali del progetto, hanno fondato SchedMD per creare un modello di supporto commerciale che mantenesse il software gratuito pur finanziando lo sviluppo continuo, replicando il modello Red Hat nell'ambito dello scheduling HPC.

I dati Hyperion Research del 2023 mostrano che il 50% dei siti HPC utilizza Slurm, seguito da OpenPBS al 18,9%, PBS Pro al 13,9% e LSF al 10,6%. Il divario si sta ampliando.

La strategia di consolidamento verticale di NVIDIA

⬆ Torna su

L'acquisizione di SchedMD si inserisce in una strategia più ampia di NVIDIA. Nell'aprile 2024 l'azienda aveva acquisito Run:ai per circa 700 milioni di dollari. Run:ai costruisce orchestrazione GPU basata su Kubernetes: se Slurm è il modo in cui supercomputer e cluster HPC tradizionali gestiscono i carichi di lavoro GPU, Run:ai è il modo in cui le organizzazioni cloud-native fanno la stessa cosa su Kubernetes. NVIDIA ora possiede il livello di scheduling per entrambi i paradigmi.

Precedentemente, nel gennaio 2022, NVIDIA aveva acquisito Bright Computing, il cui software Bright Cluster Manager è stato successivamente ottimizzato per l'hardware NVIDIA, creando penalità di prestazioni per gli utenti di chip concorrenti senza lavoro aggiuntivo, secondo le fonti del settore AI. NVIDIA ha respinto queste affermazioni, dichiarando che la tecnologia Bright Computing supporta "quasi tutti i cluster CPU o GPU-accelerati".

Con l'acquisizione di SchedMD, NVIDIA completa un pattern di consolidamento: possiede il silicio GPU (H100, H200, GB200), si è integrata nello sviluppo dei modelli con Nemotron 3, e ora controlla Slurm, il sistema che decide come quelle GPU e quei modelli vengono effettivamente eseguiti in produzione.

Le dichiarazioni di NVIDIA e l'impegno open-source

⬆ Torna su

NVIDIA ha dichiarato che continuerà a sviluppare e distribuire Slurm come software open-source e vendor-neutral, rendendolo ampiamente disponibile e supportato dalla più ampia comunità HPC e AI su diverse architetture hardware e software. Danny Auble, CEO di SchedMD, ha definito l'acquisizione "la validazione definitiva del ruolo critico di Slurm negli ambienti HPC e AI più esigenti al mondo".

L'azienda ha sottolineato di collaborare con SchedMD da oltre un decennio e di continuare a investire nello sviluppo di Slurm per garantirne la posizione come scheduler open-source leader per HPC e AI. NVIDIA offrirà supporto software open-source, training e sviluppo per Slurm alle centinaia di clienti di SchedMD, che includono cloud provider, produttori, aziende AI e laboratori di ricerca in settori come guida autonoma, healthcare, energia, servizi finanziari e governo.

La licenza GPLv2 sotto cui è distribuito Slurm rendere legalmente problematica la chiusura del codice sorgente. Tuttavia, resta aperta la questione di come NVIDIA influenzerà la roadmap di sviluppo.

Le preoccupazioni dell'ecosistema

⬆ Torna su

Cinque fonti tra ingegneri ed executive del settore hanno espresso preoccupazioni sul fatto che NVIDIA potrebbe favorire sottilmente se stessa, scrivendo aggiornamenti software per i propri chip prima di quelli dei concorrenti come AMD. Un test iniziale sarà la velocità con cui NVIDIA integrerà i nuovi chip AMD attesi più tardi nel 2026 nel codice Slurm rispetto all'integrazione con tecnologie proprietarie come i chip di rete InfiniBand.

Secondo Addison Snell, CEO di Intersect360 Research, rimane la preoccupazione che NVIDIA "possa prendere ciò che è uno strumento open-source comune e farlo funzionare meglio o esclusivamente per le proprie parti, rispetto a tecnologie concorrenti come quelle di Intel, AMD o qualsiasi altra azienda di elaborazione AI".

Diversi esperti che utilizzano il software SchedMD non hanno espresso preoccupazioni immediate sull'acquisizione, ma hanno dichiarato di essere consapevoli di tali timori e di osservare attentamente le azioni di NVIDIA con Slurm. Molti nel settore supercomputer e AI vedono l'acquisizione come un test delle intenzioni di NVIDIA.

La differenza tra vendor-neutral e vendor-optimized

⬆ Torna su

L'analisi del settore sottolinea che software "vendor-neutral" e software "vendor-optimized" non sono la stessa cosa. Quando NVIDIA controlla la roadmap, stabilisce priorità e gestisce i contributi, la spinta gravitazionale naturale è verso funzionalità che fanno funzionare meglio l'hardware NVIDIA, schedulare più efficientemente e consegnare risultati più rapidi. Questo non è malizia, è allineamento degli incentivi.

Il parallelo storico è con Android: gratuito e open-source, con Google che manteneva la finzione di apertura mentre ottimizzava silenziosamente i servizi Google e l'hardware Google per funzionare meglio su Android rispetto alle alternative. La piattaforma rimaneva tecnicamente neutrale, ma gli incentivi fluivano in una direzione.

Le alternative open-source

⬆ Torna su

Per le organizzazioni che cercano alternative, esistono progetti che forniscono percorsi verso un futuro vendor-neutral. Google ha investito significativamente in Volcano, un progetto CNCF per l'orchestrazione batch su Kubernetes. Microsoft ha storicmente standardizzato su OpenPBS. PBS si è frammentato in OpenPBS, Torque e PBS Pro, con ogni fork che ha diluito la comunità e disperso l'innovazione.

Una possibilità è che la comunità open-source effettui un fork di Slurm creando un progetto parallelo esplicitamente progettato per la neutralità hardware, come accaduto con OpenStack quando emersero preoccupazioni sulla governance. Un'altra è che AMD e Intel finanzino silenziosamente scheduler alternativi come PBS o TORQUE per garantirsi asset infrastrutturali indipendenti dal controllo NVIDIA.

La prospettiva dei hyperscaler

⬆ Torna su

Hyperscaler come Google e Amazon hanno sviluppato silicio interno per AI, ma la loro dipendenza da strumenti open-source come Slurm per la gestione dei carichi di lavoro crea una dipendenza dall'ecosistema NVIDIA. L'acquisizione rafforza la capacità di NVIDIA di dettare gli standard per lo scheduling dei carichi di lavoro, un collo di bottiglia critico nel deployment AI su larga scala.

I dati di NVIDIA stimano che l'azienda detiene tra il 70% e il 95% del mercato degli acceleratori AI, con le sue GPU diventate lo standard de facto per training e inference dei modelli AI. Questa posizione è rafforzata da CUDA, piattaforma di calcolo parallelo adottata dal 98% degli sviluppatori AI.

Implicazioni per chi adotta Slurm

⬆ Torna su

Per le organizzazioni che già utilizzano Slurm, non molto cambia immediatamente: il software rimane open-source, i contratti di supporto SchedMD presumibilmente continuano, e i 40 dipendenti che hanno costruito la loro carriera attorno al funzionamento di Slurm sono ora dipendenti NVIDIA con presumibilmente risorse NVIDIA.

Per le organizzazioni che costruiscono alternative al dominio hardware di NVIDIA, il panorama è diventato più difficile: il nuovo acceleratore necessita di supporto nell'ecosistema software, il che ora significa convincere Slurm di proprietà NVIDIA a trattare l'hardware come cittadino di prima classe o costruire da zero un livello di orchestrazione proprio.

La raccomandazione del settore è mantenere un piano di readiness per la migrazione: documentare le dipendenze da Slurm, monitorare se le nuove feature arrivano prima su hardware NVIDIA, valutare alternative come Volcano per carichi di lavoro Kubernetes e OpenPBS per carichi di lavoro tradizionali.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Implicazioni e scenari

⬆ Torna su

L'acquisizione di SchedMD completa una strategia di consolidamento verticale che ora abbraccia silicio, orchestrazione e scheduling. La questione centrale non è la chiusura del codice — impedita dalla licenza GPLv2 — ma l'influenza sulla roadmap e sui tempi di integrazione per hardware concorrente.

  • Scenario 1: NVIDIA mantiene Slurm effettivamente vendor-neutral, integrando tempestivamente nuove architetture AMD e Intel. La reputazione di neutralità si consoliderebbe, rafforzando la posizione di standard de facto.
  • Scenario 2: La roadmap si orienta progressivamente verso ottimizzazioni prioritarie per GPU NVIDIA e InfiniBand, con integrazioni per concorrenti ritardate. Le organizzazioni potrebbero migrare verso alternative come Volcano o OpenPBS.
  • Scenario 3: La comunità HPC crea un fork di Slurm per garantire indipendenza, frammentando lo sviluppo come accaduto con PBS. Questo ridurrebbe gli incentivi per NVIDIA a investire nel progetto originario.

Cosa monitorare

⬆ Torna su
  • Tempi di integrazione dei nuovi chip AMD previsti per il 2026 rispetto alle tecnologie NVIDIA InfiniBand.
  • Eventuali annunci di fork o migrazioni da parte di laboratori di ricerca e cloud provider.
  • Segnali sulla governance della roadmap Slurm e trasparenza nelle priorità di sviluppo.

Nota editoriale: questa sezione propone una lettura analitica dei temi trattati, senza introdurre dati fattuali non presenti nelle fonti.

Fonti

⬆ Torna su

In breve

  • nvidia
  • gpu
  • hpc
  • opensource

Link utili

Apri l'articolo su DeafNews