Eseguire modelli linguistici di grandi dimensioni localmente spesso ti costringe in un angolo per quanto riguarda l'hardware. Gli utenti NVIDIA vivono all'interno dell'ecosistema CUDA. Gli sviluppatori Apple scelgono Metal. Tutti gli altri sperano che la propria GPU supporti OpenCL o si limitano a fare affidamento sulla CPU. Questa frammentazione rende la distribuzione di un'applicazione AI desktop più difficile di quanto dovrebbe essere. TensorSharp ha iniziato a smantellare il problema aggiungendo un backend Vulkan, offrendo al motore una via credibile attraverso GPU discrete di diversi produttori.

Perché Vulkan cambia le carte in tavola

Vulkan viene solitamente discusso negli ambienti di gaming, ma come API di calcolo cross-platform a basso overhead, è altrettanto importante per l'inferenza. Raggiunge hardware che CUDA ignora: chip integrati Intel UHD e Iris Xe, vecchie schede discrete, laptop Windows economici senza l'adesivo NVIDIA. Per un motore di inferenza locale, questa portata si traduce in potenza pratica. Uno sviluppatore può distribuire un singolo percorso binario che funziona su molte più macchine di quanto una soluzione basata solo su CUDA potrebbe mai fare.

Il supporto Vulkan di TensorSharp ha debuttato tramite il progetto GGML. Questa integrazione è funzionale oggi, anche se l'autore prevede di costruire un backend Vulkan nativo in seguito. Usare GGML come ponte è stata la mossa strategica corretta. Valida l'architettura e mette l'hardware nelle mani dei tester immediatamente. Seguirà un backend nativo per eliminare l'overhead di astrazione e dare al motore incentrato su C# un controllo più fine su command buffer e memory barrier.

Qual è lo stato attuale dei test

La validazione copre già due configurazioni Windows molto diverse. Lo sviluppatore ha effettuato i test su una GPU NVIDIA GeForce RTX 3080 per laptop e su semplici Intel UHD Graphics. Entrambe hanno funzionato bene. Questa gamma merita attenzione. È raro che silicio discreto ad alto wattaggio e grafica integrata di base condividano un ambiente di test così armonioso nel mondo dell'inferenza. Se utilizzi un laptop leggero senza una GPU dedicata, TensorSharp offre ora un vero percorso di accelerazione che non dipende dai driver NVIDIA.

Il vuoto nella matrice è rappresentato da AMD. Nessun hardware Radeon è stato ancora testato. Se possiedi una GPU AMD, il progetto ha bisogno del tuo feedback. La validazione della community sulle schede della serie RX 6000 o 7000 è ciò che trasforma un backend sperimentale in un'opzione di livello produzione. Apri un issue se si rompe. Aprilo se funziona alla perfezione. In ogni caso, il risultato farà progredire il progetto.

TensorSharp non è un wrapper

Questo punto merita enfasi. TensorSharp non è un binding C# attorno a llama.cpp. Lo sviluppatore ha costruito l'intero motore da zero. Il backend CPU è puro C#. Quando esegui l'inferenza senza una GPU, stai eseguendo codice gestito invece di passare attraverso un'interfaccia di funzioni esterne verso un binario C++. Il progetto mantiene anche backend dedicati per CUDA, MLX di Apple e GGML. Nonostante tale indipendenza architettonica, le prestazioni eguagliano quelle di llama.cpp, che rimane il punto di riferimento che la maggior parte dei progetti di inferenza locale cerca di raggiungere. Questa parità è stata difficile da ottenere. Significa che il layout della memoria, il kernel dispatch e le operazioni sui tensor reggono bene sotto carico reale.

Il supporto ai modelli include Gemma4, DiffusionGemma e Qwen3.6. Il runtime gestisce anche il lavoro multimodale. Le pipeline di visione, audio e ragionamento girano attraverso lo stesso motore. Se stai prototipando un assistente desktop che legge screenshot e accetta comandi vocali, non devi cucire insieme tre runtime separati sperando che il loro consumo di memoria rientri nelle capacità della tua macchina.

Flessibilità di piattaforma e API

TensorSharp funziona su Windows, macOS e Linux. Il nuovo backend Vulkan si inserisce perfettamente in questa matrice insieme ai percorsi CUDA e Metal esistenti. Il motore espone inoltre la compatibilità con le API di OpenAI e Ollama. Questa scelta elimina le frizioni di integrazione. Puoi indirizzare il codice client esistente verso un server TensorSharp locale senza dover riscrivere i prompt template o analizzare una nuova struttura di risposta. Per i team che utilizzano già Ollama internamente o che sviluppano sulla superficie REST di OpenAI, passare a un'istanza locale di TensorSharp è in gran parte solo una questione di modifica dell'URL di base.

Ottimizzazioni prese in prestito che funzionano

Le prestazioni non dipendono solo da quale API comunica con la GPU. TensorSharp integra diverse ottimizzazioni già testate in produzione altrove.

La Paged KV cache, presa in prestito da vLLM, impedisce alla memoria di gonfiarsi durante le conversazioni lunghe. Invece di riservare un'area di memoria contigua per ogni sequenza, il motore alloca pagine di dimensioni fisse e le mappa su richiesta. È possibile mantenere le finestre di contesto aperte più a lungo senza dover monitorare picchi improvvisi nell'uso della RAM.

Il continuous batching, introdotto anche da vLLM, migliora il throughput. Il motore può inserire nuove richieste nei batch attivi invece di attendere la fine del gruppo corrente. Se il prompt di un utente è di dieci token e quello di un altro è di duecento, l'hardware rimane più occupato e la latenza media diminuisce.

Per i modelli Mixture-of-Experts, TensorSharp implementa una strategia di cache basata su SSD derivata da oMLX. I pesi degli esperti consultati frequentemente rimangono pronti su un'archiviazione veloce invece di competere per la RAM di sistema. Su macchine con memoria limitata ma dischi NVMe decenti, questo mantiene utilizzabili le architetture MoE.

La quantizzazione segue lo standard GGUF stabilito da llama.cpp. I tuoi modelli quantizzati a 4 e 5 bit vengono caricati direttamente senza una fase di conversione.

Il vero punto fondamentale

Il supporto Vulkan trasforma TensorSharp da un interessante esperimento in C# in un'opzione di inferenza pratica per hardware eterogeneo. La roadmap è chiara: validare su silicio discreto AMD e Intel, per poi perfezionare l'implementazione con un backend Vulkan nativo. Se hai una scheda AMD nella tua workstation o nel tuo laptop, esegui la build e condividi i tuoi risultati. Questo ciclo di feedback è ciò che rende robusto il codice sperimentale, trasformandolo in qualcosa che puoi rilasciare.

Puoi trovare i dettagli del rilascio nel resoconto dello sviluppatore. Se il progetto ti evita di dover gestire diversi toolkit CUDA o di lottare con i vincoli delle versioni di macOS, lascia una stella sul repository. Per discussioni continue e thread di test della community, il gruppo Telegram rimane aperto.