Quando più di 170 persone si riuniscono a Bengaluru per parlare di profiler, kernel e comunicazione tra GPU, il dato non è l'affluenza ma lo spostamento di attenzione: dall'uso dei modelli alla costruzione dei sistemi che li tengono in piedi. La serata organizzata da Red Hat e Hugging Face ha avuto tre interventi da Hugging Face e due dal team di ingegneria PyTorch di Red Hat, e ha evitato le demo per concentrarsi su ciò che rende l'AI eseguibile in produzione.

Il filo conduttore è emerso con chiarezza. L'India ha già molti talenti che consumano modelli e costruiscono applicazioni; il passaggio più difficile, e più prezioso, è trasformare parte di quella base in manutentori e progettisti di profiler, runtime, astrazioni per il training, tooling per il reinforcement learning e librerie di comunicazione distribuita. Non è una semplice questione di carriera: è la differenza tra subire le scelte di chi sviluppa il core stack e partecipare alle decisioni che determinano costi, latenza e controllabilità dei deployment.

Sul piano tecnico, la sequenza degli interventi ha raccontato un percorso unico. Aritra Roy Gosthipaty ha mostrato il profiling in PyTorch come pratica disciplinata: annotare le regioni di interesse, separare le fasi di attesa e raccolta, leggere le tracce per distinguere il collo di bottiglia della CPU dal lavoro reale sulla GPU. L'idea di essere 'overhead bound' è centrale: molti rallentamenti non nascono dal modello, ma dai costi di orchestrazione lato CPU che solo un profiler rende visibili.

Adarsh ha poi spostato il discorso sull'inference LLM. La distinzione tra prefill e decode, con la cache KV che domina il costo in decode, spiega perché i motori di serving non sono un dettaglio applicativo ma una scelta di sistema. SGLang, con la RadixAttention e la cache a prefissi, trasforma la struttura ripetuta del traffico in un vantaggio di capacità. La divisione del lavoro con Hugging Face Transformers è altrettanto rilevante: i modelli restano la fonte di verità, mentre i motori costruiscono il percorso veloce. Per chi valuta un deployment self-hosted, questo non è tecnicismo: significa poter servire una coda lunga di modelli senza riscrivere a mano ogni runtime.

La parte sul post-training ha mostrato un altro asse di crescita. Adithya S Kolavi ha descritto gli ambienti RL come una combinazione di task, stato, strumenti, osservazioni, logica di ricompensa e controllo degli episodi. Il passaggio da RLHF a ricompense verificabili programmaticamente rende ogni repository di codice una potenziale sorgente di ambienti addestrabili, come nel caso di Repo2RLEnv. È un segnale per chi costruisce infrastrutture locali: il training non si gioca solo sui pesi, ma sulla capacità di generare e orchestrare ambienti verificabili.

Gli ultimi due interventi, di Mansi Agarwal e Arkadip Maitra, hanno toccato il sottofondo del training distribuito. DeviceMesh, DTensor e FSDP2 promettono composabilità dove prima servivano process group fatti a mano; il percorso zero-copy tra GPU mostra che l'efficienza vera sta nel ridurre i costi dei layer invisibili. Le limitazioni dichiarate di DTensor, come l'overhead in eager mode e la copertura incompleta degli operatori, danno credibilità al framework: non si tratteggia una magia, ma una direzione ingegneristica.

La tesi di fondo, avanzata da Sudhir Dharanendraiah, è che l'India non debba restare un grande consumatore di AI. È una posizione che ha implicazioni strutturali. Se la comunità indiana produce manutentori e progettisti di questi strati, il centro di gravità dell'open ML stack si sposta e cresce lo spazio per deployment locali e ibridi non dipendenti da API proprietarie. Non è un caso che Red Hat, azienda open source per eccellenza, abbia investito qui: la battaglia per il controllo dello stack si combatte sui kernel e sulle primitive di comunicazione, non nei cartelloni pubblicitari dei modelli.