L’AI esce dal cloud tra MCP stateless, kernel portabili e robot Jetson

🤖 Cosa cambia

• MCP C# SDK 2.0 adotta richieste HTTP stateless, interazioni multiround e compatibilità con client e server costruiti sulla specifica precedente.
• K-Search utilizza modelli AI e benchmark hardware per generare e ottimizzare kernel CUDA, Triton e MLX attraverso una ricerca iterativa.
• NVIDIA promuove Jetson come piattaforma portatile per agenti, visione artificiale e robotica, con inferenza interamente locale e fino a 275 TOPS.

Microsoft, Berkeley AI Research e NVIDIA affrontano da tre prospettive differenti lo stesso problema: portare l’intelligenza artificiale fuori dalle dimostrazioni isolate e dentro infrastrutture capaci di funzionare su cloud distribuiti, GPU differenti e macchine fisiche. Il nuovo MCP C# SDK 2.0 rende stateless il protocollo su HTTP e introduce richieste interattive senza sessioni persistenti. K-Search automatizza invece la produzione e l’ottimizzazione di kernel per CUDA, Triton e MLX, utilizzando modelli linguistici guidati dai risultati reali dell’hardware. NVIDIA completa il quadro con Jetson, piattaforma edge progettata per eseguire localmente agenti, modelli visivi e sistemi robotici senza dipendere costantemente dal cloud.

MCP C# SDK 2.0 rende gli agenti nativi del web

Microsoft ha pubblicato la versione 2.0 dell’SDK C# ufficiale per Model Context Protocol, allineandola alla specifica MCP del 28 luglio 2026. Il cambiamento principale riguarda il trasporto HTTP, che diventa stateless per impostazione predefinita. Nella generazione precedente, client e server completavano un handshake iniziale, ricevevano un identificativo di sessione e dovevano mantenere la continuità delle richieste sulla stessa istanza oppure su un archivio condiviso. Questo modello complicava distribuzioni serverless, cluster orizzontali e ambienti edge, perché richiedeva sticky session o sincronizzazione dello stato. La nuova architettura inserisce versione del protocollo, capacità e informazioni operative direttamente in ogni richiesta. Qualunque istanza può quindi ricevere una chiamata senza conoscere quelle precedenti, permettendo di utilizzare normali bilanciatori, proxy, gateway e Web Application Firewall. L’SDK si appoggia ad ASP.NET Core, sfruttando strumenti già maturi per routing, middleware, header, container e scalabilità. Il passaggio consolida MCP come standard per collegare agenti, strumenti e sistemi informativi, invece di trattarlo come un protocollo sperimentale vincolato a sessioni locali.

Gli header MCP aprono routing e osservabilità enterprise

La specifica standardizza header come Mcp-Method e Mcp-Name, che indicano direttamente il metodo richiesto e lo strumento invocato. Un gateway può così riconoscere una chiamata tools/call, applicare limiti, instradarla verso una regione specifica o bloccare uno strumento senza analizzare il contenuto JSON-RPC. Gli sviluppatori possono inoltre promuovere determinati parametri negli header attraverso l’attributo McpHeader, mantenendo comunque il corpo della richiesta come fonte autorevole. Se header e payload non coincidono, il server rifiuta l’operazione invece di scegliere arbitrariamente quale valore utilizzare. Questo dettaglio riduce errori e manipolazioni nei sistemi distribuiti. La nuova superficie HTTP migliora anche tracing, caching e integrazione con OpenTelemetry, facilitando la ricostruzione del percorso compiuto da un agente tra client, gateway, strumenti e servizi finali. Maggiore visibilità non elimina però il rischio degli strumenti compromessi: routing e autenticazione devono essere accompagnati da controlli sul contenuto, perché il tool poisoning negli ambienti MCP può trasformare un’integrazione legittima in un canale di esfiltrazione.

Le richieste multiround conservano l’interazione senza sessioni

La modalità stateless rischiava di eliminare una funzione essenziale: la possibilità che uno strumento interrompa l’operazione e chieda informazioni aggiuntive all’utente o al modello. Microsoft risolve il problema attraverso Multi Round-Trip Requests, abbreviato in MRTR. Quando uno strumento necessita di una conferma, di un valore mancante o dell’elenco delle directory autorizzate, restituisce un risultato input_required con le richieste da soddisfare e uno stato opaco.

Il client raccoglie la risposta e ripete la stessa chiamata includendo gli input e lo stato ricevuto. La continuità viaggia quindi nel payload, senza mantenere aperta una sessione server. Il meccanismo può ripetersi più volte e sostituisce nei flussi stateless le precedenti richieste avviate direttamente dal server per elicitation, sampling e roots. Il client C# gestisce automaticamente il ciclo quando vengono registrati gli handler necessari. Per approvazioni sensibili, autorizzazioni OAuth o accessi a dati protetti, l’SDK prevede anche una modalità basata su URL esterno, nella quale il consenso viene raccolto fuori dalla conversazione dell’agente.

La compatibilità riduce il rischio della migrazione

Nonostante il salto alla versione principale 2.0, Microsoft mantiene la compatibilità con la maggior parte del codice costruito sul ramo 1.x. Client e server aggiornati possono negoziare automaticamente una versione precedente, ripristinando l’handshake e le sessioni quando comunicano con componenti non ancora conformi alla specifica 2026-07-28. Gli sviluppatori possono inoltre disattivare esplicitamente la modalità stateless quando necessitano di notifiche spontanee dal server o di stato legato al trasporto. La principale eccezione riguarda l’estensione sperimentale Tasks, ridisegnata e trasferita in un pacchetto separato insieme alle applicazioni MCP interattive. Tasks gestisce operazioni di lunga durata, polling e persistenza, mentre MCP Apps permette a un server di consegnare interfacce grafiche ai client compatibili. L’SDK supporta .NET 8, 9 e 10, oltre a .NET Standard 2.0 per l’impiego con il vecchio .NET Framework. La struttura modulare consente quindi di costruire client leggeri, server standard oppure servizi HTTP completi senza importare dipendenze non necessarie.

K-Search automatizza l’ingegneria dei kernel GPU

Il progetto K-Search, sviluppato da ricercatori collegati a Berkeley, affronta un collo di bottiglia differente. I modelli AI dipendono da kernel GPU altamente ottimizzati per operazioni come attention, mixture-of-experts, moltiplicazioni di matrici e gestione della memoria. Scrivere questi kernel richiede conoscenza dell’architettura hardware, sincronizzazione dei thread, gerarchie di memoria e profiling. Un codice funzionalmente corretto può risultare molto più lento di una soluzione progettata per una specifica GPU. K-Search utilizza modelli linguistici per generare, compilare, verificare e ottimizzare iterativamente il codice, ma non si limita a chiedere al modello una nuova versione dopo ogni benchmark. Mantiene un world model co-evolutivo, rappresentato come un albero di ipotesi sui colli di bottiglia, sulle trasformazioni possibili e sulle strategie già tentate. Il sistema separa così la pianificazione algoritmica dalla produzione concreta del codice e può attraversare fasi temporaneamente peggiori per raggiungere una soluzione finale più efficiente.

CUDA, Triton e MLX entrano nello stesso ciclo di ricerca

L’architettura supporta più backend e ambienti di valutazione. Può lavorare su CUDA e Triton attraverso FlashInfer-Bench, GPUMode e KernelBench, oppure generare kernel MLX per Apple Silicon. Il backend MLX misura latenza, pressione sulla memoria unificata e indicatori di throughput specifici dei chip Apple, permettendo di applicare lo stesso metodo di ricerca a un’architettura molto diversa dalle GPU NVIDIA. Non si tratta di una traduzione sintattica diretta da CUDA a Metal.

K-Search utilizza il kernel originale o la definizione dell’operazione come punto di partenza, genera una soluzione compatibile con MLX, la prova sull’hardware reale e modifica progressivamente struttura, accessi alla memoria e parallelismo. Il sistema può utilizzare differenti modelli attraverso API compatibili con OpenAI e conserva codice, risultati, rapporti di valutazione e stato della ricerca per riprendere il processo. L’estensione verso MLX rafforza il framework che Apple aveva introdotto come ambiente nativo per il machine learning su Apple Silicon, riducendo almeno in parte la distanza tra ricerca CUDA e sviluppo locale sui Mac.

I benchmark mostrano vantaggi ma restano hardware-specifici

Nei test pubblicati, K-Search registra un miglioramento medio di 2,10 volte rispetto ai sistemi evolutivi presi come riferimento sui kernel complessi di FlashInfer, con guadagni massimi dichiarati di 14,3 volte nelle operazioni mixture-of-experts. Sul task TriMul di GPUMode raggiunge una latenza geometrica vicina a 1,03 millisecondi su GPU H100, superando le soluzioni automatizzate e manuali confrontate dagli autori. Questi risultati dimostrano che un modello linguistico guidato da un piano esplicito e da misure hardware può superare la semplice generazione one-shot.

Non significano però che ogni kernel prodotto risulti automaticamente più veloce su qualunque GPU. Registri, cache, tensor core, bandwidth e dimensioni dei workload cambiano tra H100, B200, Apple Silicon e altri acceleratori. Ogni risultato deve quindi essere verificato sul dispositivo di destinazione, attraverso prove ripetute di correttezza e prestazioni. K-Search automatizza l’esplorazione, ma non elimina la dipendenza dall’hardware reale.

NVIDIA Jetson porta modelli e agenti nel mondo fisico

NVIDIA affronta l’ultimo passaggio della catena: eseguire modelli, visione artificiale e agenti direttamente sulle macchine. La società presenta Jetson come una piattaforma portatile destinata a studenti, laboratori, startup e costruttori di robot. Jetson Orin Nano Super offre 67 TOPS in un developer kit compatto, sufficiente per sperimentare modelli generativi, computer vision e assistenti vocali locali. Jetson AGX Orin sale fino a 275 TOPS per navigazione autonoma, mappatura tridimensionale e workload più complessi, mentre Jetson AGX Thor si rivolge alla nuova generazione di robot e sistemi fisici. NVIDIA affianca all’hardware Device Skills e BSP Skills, strumenti utilizzabili dagli agenti di coding per configurare, ottimizzare e distribuire il software. La piattaforma evolve così da computer embedded a infrastruttura completa per l’AI fisica, direzione già evidente con Jetson, NemoClaw e i blueprint destinati a fabbriche e robot autonomi.

Gli esempi mostrano inferenza locale senza cloud

Tra i progetti mostrati da NVIDIA compare Reachy Mini Jetson Assistant, assistente vocale e visivo a bassa latenza che esegue l’intera inferenza sul dispositivo senza API esterne, connessione internet o servizi cloud durante l’uso. Un secondo progetto utilizza Orin Nano Super per controllare autonomamente un piccolo veicolo elettrico, mentre un’applicazione basata su Mistral dimostra la costruzione di un robot partendo da componenti accessibili. Su AGX Orin, un’interfaccia web esegue in tempo reale modelli visione-linguaggio sul flusso della videocamera.

Un sistema sviluppato alla Carnegie Mellon University costruisce invece una mappa tridimensionale dell’ambiente mentre cerca persone durante scenari di soccorso. Questi esempi non costituiscono prodotti commerciali pronti, ma mostrano il vantaggio dell’elaborazione locale: minore latenza, funzionamento senza rete e maggiore controllo sui dati acquisiti da microfoni e telecamere.

Protocolli, kernel e hardware formano la nuova catena AI

MCP C# SDK, K-Search e Jetson operano su livelli differenti ma compongono una stessa architettura. MCP standardizza il modo in cui gli agenti chiamano strumenti e servizi; K-Search ottimizza il codice che esegue le operazioni più costose; Jetson porta modelli e agenti vicino a sensori, motori e ambienti reali. La direzione riduce la dipendenza da server centralizzati, ma aumenta la necessità di controllare autorizzazioni, compatibilità e correttezza. Un agente stateless può essere scalato facilmente, ma deve autenticare ogni richiesta. Un kernel generato automaticamente può essere veloce, ma deve essere verificato contro errori numerici e accessi alla memoria. Un robot capace di elaborare localmente voce e immagini protegge meglio la continuità operativa, ma può agire fisicamente sulla base di una decisione sbagliata. La maturità dell’AI non dipenderà quindi soltanto da modelli più potenti, ma dalla capacità di collegare protocollo, software e hardware attraverso confini osservabili e verificabili.