Spcnet.it

2026-05-27 16:35:17

SQL Server 2025 e Azure SQL: vettori, modelli AI nativi e agenti autonomi nel database

SQL Server 2025: un database nativamente AI

Con il rilascio di SQL Server 2025 (versione 17.x) e i progressivi aggiornamenti di Azure SQL Database, Microsoft ha compiuto un salto qualitativo radicale: non si tratta più di integrare l’intelligenza artificiale come funzionalità accessoria, ma di rendere il database stesso una piattaforma AI di prima classe. Vettori, modelli esterni, agenti autonomi e GitHub Copilot nel gestore dello studio: in questo articolo esploriamo tutto ciò che i professionisti IT devono conoscere.

Tipo di dato VECTOR e ricerca semantica con DiskANN

Il cambiamento più strutturale è l’introduzione del tipo di dato nativo VECTOR, supportato dall’indice DiskANN (Disk-based Approximate Nearest Neighbor), un algoritmo ottimizzato per la ricerca di similarità in grandi dataset ad alta dimensionalità.

Un vettore di embedding è una rappresentazione numerica densa di un contenuto (testo, immagine, documento) in uno spazio ad alta dimensionalità. SQL Server 2025 supporta vettori fino a 1536 dimensioni, compatibili con i modelli di embedding Azure OpenAI come text-embedding-3-large.

-- Creazione tabella con colonna vettoriale
CREATE TABLE Documenti (
    Id INT PRIMARY KEY,
    Testo NVARCHAR(MAX),
    Embedding VECTOR(1536)
);

-- Ricerca di similarità semantica tramite distanza coseno
SELECT TOP 5
    Id,
    Testo,
    VECTOR_DISTANCE('cosine', Embedding, @queryEmbedding) AS Distanza
FROM Documenti
ORDER BY Distanza ASC;

La funzione VECTOR_DISTANCE supporta le metriche cosine, euclidean e dot. In marzo 2026 Microsoft ha annunciato ulteriori ottimizzazioni tramite quantizzazione (riduzione della precisione vettoriale per risparmiare storage e accelerare il calcolo) e iterative filtering, disponibili sia su Azure SQL Hyperscale che su SQL Database in Microsoft Fabric.

CREATE EXTERNAL MODEL: modelli AI come oggetti database

Una delle novità più significative per gli sviluppatori è la possibilità di registrare modelli AI esterni come oggetti database di prima classe, con la stessa dignità di una tabella o di una view.

-- Registrazione di un modello Azure OpenAI come external model
CREATE EXTERNAL MODEL AzureOpenAI_Ada
WITH (
    LOCATION = 'https://mio-endpoint.openai.azure.com/',
    API_KEY = 'secret-key',
    API_TYPE = 'azure_openai',
    DEPLOYMENT = 'text-embedding-ada-002',
    TASK = 'EMBEDDINGS'
);

Una volta registrato, il modello è disponibile per tutte le query T-SQL dell’istanza, con gestione automatica del retry per i fallimenti transitori e supporto per il versioning (A/B testing tra deployment diversi).

La stored procedure sp_invoke_external_rest_endpoint consente invece di chiamare qualsiasi API REST direttamente da T-SQL, incluse OpenAI, Azure OpenAI, Anthropic e anche modelli locali come Ollama:

EXEC sp_invoke_external_rest_endpoint
    @url = 'https://api.openai.com/v1/embeddings',
    @method = 'POST',
    @headers = '{"Authorization": "Bearer sk-xxx", "Content-Type": "application/json"}',
    @payload = '{"input": "testo da vettorializzare", "model": "text-embedding-3-small"}',
    @response = @json OUTPUT;

RAG nativo: addio al database vettoriale separato

Il pattern Retrieval-Augmented Generation (RAG) — recuperare contesto rilevante da una base di conoscenza per arricchire il prompt di un LLM — si implementa ora interamente all’interno di SQL Server, senza bisogno di database vettoriali separati come Pinecone, Milvus o Weaviate.

Il flusso tipico è:

1. Inserire i documenti nella tabella con colonna VECTOR
2. Generare gli embedding tramite CREATE EXTERNAL MODEL o sp_invoke_external_rest_endpoint
3. Archiviare i vettori nella stessa tabella dei dati operativi
4. Al momento della query, vettorializzare il testo dell’utente e cercare i k documenti più simili con VECTOR_DISTANCE
5. Passare i documenti recuperati come contesto all’LLM

Questo approccio elimina la complessità della sincronizzazione tra il database relazionale e quello vettoriale, riducendo la latenza e semplificando enormemente la gestione della sicurezza (un solo perimetro di autorizzazione).

Per scenari ibridi, è disponibile anche l’integrazione con Azure AI Search, che combina full-text search tradizionale con ricerca vettoriale semantica.

Agenti AI autonomi e GitHub Copilot in SSMS 22

SQL Server 2025 introduce il concetto di agente AI integrato nel database: un componente che riceve richieste in linguaggio naturale, le traduce in T-SQL, le esegue e ragiona sui risultati per determinare i passi successivi, rispettando il modello di sicurezza e i permessi SQL Server.

Azure SQL Database Hyperscale espone un SQL MCP Server (endpoint Model Context Protocol, ora in public preview), che consente ad agenti AI e Copilot di connettersi al database e ragionare sui dati SQL per applicazioni cloud-native.

GitHub Copilot in SSMS 22 è diventato generalmente disponibile l’11 novembre 2025. Le funzionalità principali:

• Chat in linguaggio naturale per interrogare il database o costruire query T-SQL
• Slash command: /doc per la documentazione, /fix per la correzione errori, /explain per la spiegazione di query complesse
• Database instructions: contesto specifico del database e regole di business memorizzati come extended properties, che Copilot applica automaticamente
• Autocompletamento contestuale nell’editor query (disponibile dalla versione SSMS 22.2.1, rilasciata il 21 gennaio 2026)

Machine Learning Services e integrazione con i framework AI

SQL Server Machine Learning Services — disponibile sin da SQL Server 2016 con R e poi Python — continua a essere supportata in SQL Server 2025. Permette di eseguire script Python e R in-database, senza spostare i dati fuori da SQL Server, mantenendo il perimetro di sicurezza e riducendo l’overhead di rete.

SQL Server 2025 aggiunge il supporto ai principali framework di orchestrazione AI:

• LangChain: il pacchetto langchain-sqlserver abilita chatbot con pattern RAG sui dati SQL, con orchestrazione tramite LangChain e UI via Chainlit
• Semantic Kernel: SDK open source Microsoft per .NET (e altri linguaggi), include un connettore nativo per il vector store di SQL Server, permettendo di costruire agenti e applicazioni RAG che chiamano modelli, strumenti e SQL Server in modo integrato
• LSTM e architetture ibride: l’integrazione con Long Short-Term Memory offre un framework per agenti che devono mantenere stato contestuale su sequenze di interazioni

Copilot in Azure SQL Database

Microsoft Copilot in Azure SQL Database — in GA dall’11 aprile 2025 — offre esperienze AI-assisted per DBA e sviluppatori:

• Risposta a domande sulle performance del database in linguaggio naturale
• Troubleshooting tramite Dynamic Management Views e Query Store
• Generazione T-SQL da descrizioni plain-text con spiegazione dettagliata delle query
• Code completion nell’editor query di Fabric e quick actions per fix/explain

Il sistema analizza i metadati del database (nomi tabelle, colonne, struttura) per generare suggerimenti contestuali senza accedere ai dati effettivi.

Requisiti e disponibilità

Le funzionalità core — tipo VECTOR, CREATE EXTERNAL MODEL, sp_invoke_external_rest_endpoint — richiedono:

• On-premises: SQL Server 2025 (17.x)
• Azure SQL Database: tier Hyperscale
• Azure SQL Managed Instance: policy di aggiornamento Always-up-to-date o SQL Server 2025
• GitHub Copilot in SSMS: SSMS 22 o superiore, account GitHub con Copilot attivo
• Azure OpenAI: risorsa con modelli di embedding distribuiti (text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002)

In marzo 2026 Microsoft ha aggiunto: Database Hub in Microsoft Fabric (early access), SQL MCP Server per Azure SQL Hyperscale (public preview), e opzioni vCore più ampie (160 e 192) per Hyperscale. È stato anche annunciato un savings plan per database con risparmio fino al 35% rispetto al pay-as-you-go su impegno annuale.

Conclusione

SQL Server 2025 non è un semplice aggiornamento di versione: è il risultato di una strategia pluriennale per trasformare il database relazionale in un motore AI nativo. Per i professionisti IT che già operano nell’ecosistema Microsoft, le implicazioni sono concrete: è possibile implementare ricerca semantica, RAG, agenti autonomi e assistenza AI alle query senza aggiungere infrastrutture esterne, riutilizzando il perimetro di sicurezza e la governance già in essere su SQL Server.

La sfida è ora architetturale: capire dove ha senso spostare logica AI dentro il database e dove invece mantenerla nell’application layer. Ma avere questa scelta — e i tool per implementarla — è già un notevole passo avanti.

---

Fonte originale: AI features in Microsoft SQL Server 2025 and Azure SQL – 4sysops

AI features in Microsoft SQL Server 2025 and Azure SQL

Microsoft SQL Server 2025 and Azure SQL Database introduce comprehensive artificial intelligence capabilities that transform how you build intelligent applications.

^{IT Experts (4sysops)}

Spcnet.it

2026-05-27 12:38:29

Runtime Async in .NET 11 Preview 1: addio alle state machine del compilatore

Introduzione

Con il rilascio di .NET 11 Preview 1, Microsoft ha introdotto uno dei cambiamenti architetturali più significativi nella storia dell’async in .NET: il Runtime Async V2. Questo cambiamento sposta la responsabilità della gestione delle operazioni asincrone dal compilatore al runtime stesso, con impatti concreti su debug, profiling, leggibilità degli stack trace e potenzialmente sulle prestazioni.

In questo articolo analizziamo nel dettaglio come funziona il nuovo modello, come differisce dall’approccio attuale basato su state machine, come abilitarlo nei propri progetti e cosa aggiunge .NET 11 Preview 1 oltre al solo Runtime Async.

Il problema: le state machine del compilatore

Chiunque abbia lavorato seriamente con codice asincrono in C# conosce la frustrazione di leggere uno stack trace in produzione e trovarsi sommerso da frame generati dal compilatore. Ogni metodo async viene trasformato dal compilatore in una classe di stato (state machine) che implementa IAsyncStateMachine. Questa trasformazione è efficace, ma introduce livelli di indirezione che offuscano la reale catena di chiamate.

Un semplice stack di tre metodi async produce tipicamente oltre dieci frame nello stack trace live, la maggior parte appartenenti all’infrastruttura del compilatore (AsyncMethodBuilderCore.Start, ecc.). Il risultato è un debug più laborioso e strumenti di profiling che faticano a restituire una visione chiara dell’esecuzione.

Runtime Async V2: come funziona

Con Runtime Async, il compilatore non genera più la state machine. Emette invece un IL semplificato, annotato con [MethodImpl(MethodImplOptions.Async)], e delega al runtime la gestione della sospensione e ripresa dei metodi asincroni. In pratica, è il CLR stesso a tracciare l’esecuzione asincrona, non il codice generato dal compilatore.

Il risultato più visibile è nei live stack trace, ovvero ciò che profiler, debugger e new StackTrace() vedono durante l’esecuzione. Con Runtime Async, i metodi effettivi appaiono direttamente nello stack, senza wrapper di stato.

Confronto diretto degli stack trace

Consideriamo questo codice di esempio:

await OuterAsync();

static async Task OuterAsync()
{
    await Task.CompletedTask;
    await MiddleAsync();
}

static async Task MiddleAsync()
{
    await Task.CompletedTask;
    await InnerAsync();
}

static async Task InnerAsync()
{
    await Task.CompletedTask;
    Console.WriteLine(new StackTrace(fNeedFileInfo: true));
}

Senza Runtime Async — 13 frame, con tutta l’infrastruttura del compilatore visibile:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__InnerAsync|0_2()
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__MiddleAsync|0_1()
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
...
(13 frame totali)

Con Runtime Async — 5 frame, la reale catena di chiamate:

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
at Program.<Main>$(String[] args) in Program.cs:line 3
at Program.<Main>(String[] args)

È importante notare che questo miglioramento riguarda i live stack trace. Gli exception stack trace (catch (Exception ex)) già apparivano in modo pulito grazie all’ExceptionDispatchInfo nelle versioni precedenti.

Miglioramenti al debugging

Con Runtime Async, il debugger può finalmente fare ciò che ci si aspetterebbe da sempre:

• I breakpoint all’interno di metodi async si associano correttamente, senza essere deviati su codice generato
• È possibile fare step-through attraverso i boundary degli await senza “saltare” nell’infrastruttura del compilatore
• La finestra call stack del debugger mostra la catena reale, non i wrapper di stato

Questi miglioramenti avvantaggiano qualsiasi strumento che ispeziona lo stack live: profiler come dotTrace, logging diagnostico, e naturalmente il debugger integrato di Visual Studio e VS Code.

Come abilitare Runtime Async nel proprio progetto

Runtime Async è una feature in anteprima che richiede opt-in esplicito. Aggiungere le seguenti proprietà al file .csproj:

<PropertyGroup>
  <Features>runtime-async=on</Features>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>

Ovviamente, essendo ancora in anteprima, non è consigliato per ambienti di produzione. È tuttavia un ottimo momento per sperimentarlo su branch di sviluppo e fornire feedback al team .NET.

Requisiti hardware aggiornati

.NET 11 alza il baseline hardware richiesto. Per x86/x64, il minimo passa da x86-64-v1 a x86-64-v2, richiedendo istruzioni aggiuntive come SSE3, SSSE3, SSE4.1, SSE4.2 e POPCNT. Questo rientra nei requisiti già imposti da Windows 11 e copre tutta l’hardware Intel/AMD attualmente supportato ufficialmente (i chip più vecchi sono usciti dal supporto intorno al 2013).

Per Arm64 su Windows, il baseline aggiunge ora il requisito dell’instruction set LSE, richiesto da Windows 11 e da tutti gli Arm64 supportati da Windows 10.

Altre novità di .NET 11 Preview 1

Supporto nativo a Zstandard

Le librerie guadagnano il supporto nativo alla compressione Zstandard tramite la nuova classe ZstandardStream. Zstandard offre rapporti di compressione migliori rispetto a gzip con velocità di decompressione molto elevate — un’aggiunta benvenuta per pipeline di dati e API ad alta frequenza.

BFloat16 per AI e ML

Arriva il tipo BFloat16 (Brain Float 16), un formato floating-point a 16 bit nato per carichi di lavoro di machine learning. È ampiamente usato da librerie AI come TensorFlow e PyTorch, e la sua presenza nativa in .NET facilita l’integrazione con modelli ML senza conversioni intermedie.

Miglioramenti JIT

• Eliminazione dei bounds check: il JIT elimina ora i controlli ridondanti sul pattern i + cns < len, comune nei loop su array e Span
• Rimozione di contesti checked ridondanti: quando un valore è già noto essere nel range, i controlli di overflow vengono rimossi
• Devirtualizzazione in ReadyToRun: le immagini R2R possono ora devirtualizzare chiamate a virtual method generici non condivisi

Miglioramenti VM

Su piattaforme senza JIT (come iOS), l’interface dispatch ora usa un meccanismo di cache con miglioramenti di performance fino a 200x in codice ad alta intensità di interfacce. Guid.NewGuid() su Linux migliora del 12% circa usando la syscall getrandom() con batch caching.

C# 15: prime anticipazioni

.NET 11 Preview 1 include anche le prime feature di C# 15. Tra quelle già disponibili:

• Collection expression arguments: possibilità di specificare capacità, comparatori o altri parametri del costruttore direttamente nella sintassi delle espressioni di collezione
• Extended layout support: il compilatore emette TypeAttributes.ExtendedLayout per tipi annotati con ExtendedLayoutAttribute, principalmente per scenari di interop

Conclusione

Il Runtime Async V2 rappresenta un passo importante verso un’esperienza di sviluppo asincrono più trasparente e debuggabile in .NET. Non è ancora pronto per la produzione, ma la direzione è chiara: Microsoft vuole che gli sviluppatori smettano di combattere con stack trace incomprensibili e possano finalmente fare debug dell’async come del codice sincrono.

Con .NET 11 previsto per novembre 2026 come Standard Term Support (STS), c’è ancora tempo per sperimentare e contribuire al processo di feedback prima del rilascio finale.

Fonte: What’s new in the .NET 11 runtime — Microsoft Learn | InfoQ: .NET 11 Preview 1

.NET 11 Preview 1 Arrives with Runtime Async, Zstandard Support, and C# 15 Features

NET 11 Preview 1 is released, featuring Runtime Async as the headline change, moving async method handling from the compiler into the runtime itself.

^{Almir Vuk (InfoQ)}

Spcnet.it

2026-05-27 12:36:33

GPUStack: cluster GPU self-hosted per inferenza AI con API OpenAI-compatibile

Avete le GPU. Magari un paio di NVIDIA A100 in un rack, alcune RTX 4090 sotto le scrivanie, o un cluster con hardware misto. Avete la potenza di calcolo. Bene. Adesso, però, viene il problema vero: come gestirla?

Capire quali modelli entrano in quale scheda, come bilanciare il carico tra più macchine, come gestire un nodo che cade alle 2 di notte, e come esporre tutto questo come una API pulita che il team di sviluppo possa effettivamente chiamare — questa è la parte che manda in crisi la maggior parte dei team. Il risultato tipico è una raccolta fragile di script Python e crontab entries che nessuno tocca da anni e che funzionano finché non smettono di funzionare.

GPUStack è stato costruito precisamente per risolvere questo problema.

Cos’è GPUStack?

GPUStack è uno strumento open source (licenza Apache 2.0) per la gestione di cluster GPU destinati all’inferenza AI. Pensatelo come Kubernetes per i vostri workload di inferenza, senza la necessità di passare tre giorni a debuggare un errore di indentazione in un Helm chart.

Al suo nucleo, GPUStack fa tre cose bene:

• Aggrega le GPU: che l’hardware sia su bare-metal, pod Kubernetes o istanze cloud, GPUStack le vede tutte come un unico pool di compute. Una dashboard, visibilità completa.
• Orchestrare gli inference engine: GPUStack si integra con vLLM, SGLang e TensorRT-LLM, sceglie il motore giusto per il job, lo configura e ne gestisce il ciclo di vita.
• Espone i modelli via API OpenAI-compatibile: una volta deployato un modello, il team applicativo ottiene un endpoint REST familiare. Nessuna libreria client custom. Nessun protocollo nuovo da imparare. Solo cambiare il base URL.

Installazione in meno di 5 minuti

Step 1 — Avviare il server di controllo

Vi serve una macchina per il control plane. Non deve nemmeno avere una GPU — un box CPU-only è sufficiente per il ruolo di server:

sudo docker run -d --name gpustack   --restart unless-stopped   -p 80:80   --volume gpustack-data:/var/lib/gpustack   gpustack/gpustack

Aprite il browser, navigate a http://<ip-del-vostro-server> e vedrete la dashboard GPUStack. Al primo accesso impostate le credenziali admin.

Step 2 — Aggiungere i worker GPU

Su ogni nodo worker, assicuratevi di avere installato NVIDIA driver e NVIDIA Container Toolkit, poi eseguite:

sudo docker run -d --name gpustack-worker   --restart unless-stopped   --gpus all   -e GPUSTACK_SERVER_URL=http://<ip-server>   -e GPUSTACK_TOKEN=<vostro-token>   gpustack/gpustack

Il token lo trovate nella dashboard GPUStack. In pochi secondi il worker compare nella vista cluster con modello GPU, capacità VRAM e stato di salute. Tre macchine? Tre comandi. Trenta macchine? Un playbook Ansible.

Nota pratica: la parte più difficile non è eseguire il comando worker, ma installare correttamente driver e toolkit sull’host. Verificate sempre la compatibilità tra versione del driver NVIDIA, versione CUDA e container runtime prima di procedere.

Step 3 — Deploy di un modello

Dalla web UI andate al catalogo modelli. GPUStack supporta il pull da Hugging Face e dall’Ollama Library. Selezionate un modello e cliccate “Deploy”.

Qui il scheduler dimostra il suo valore: legge i metadati del modello, calcola i requisiti di VRAM e compute, e determina quali worker possono gestirlo. Se il modello è troppo grande per una singola GPU, può distribuirlo su più schede (model sharding). Non dovete calcolare manualmente se un modello a 70B parametri entra nel vostro hardware: ci pensa GPUStack.

Step 4 — Chiamare l’API

Una volta che il modello è running, ottenete un endpoint OpenAI-compatibile. Recuperate una API key dalla dashboard e testate:

curl http://<ip-server>/v1/chat/completions   -H "Authorization: Bearer <api-key>"   -H "Content-Type: application/json"   -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Spiega la gestione di cluster GPU in un paragrafo."}
    ]
  }'

Se usate già l’OpenAI Python SDK, la migrazione alla vostra infrastruttura è una modifica su una riga:

from openai import OpenAI

client = OpenAI(
    base_url="http://<ip-server>/v1",
    api_key="<api-key>"
)

response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Hello from my own GPU cluster!"}]
)
print(response.choices[0].message.content)

Il codice applicativo rimane invariato. La vostra infrastruttura è ora completamente sotto il vostro controllo.

Funzionalità Avanzate

Flessibilità Multi-Backend

GPUStack supporta vLLM, SGLang e TensorRT-LLM out of the box. Nessun motore di inferenza è il migliore per ogni workload:

• vLLM: eccellente per batch processing ad alto throughput
• TensorRT-LLM: massimizza le performance sull’hardware NVIDIA
• SGLang: ideale per la generazione strutturata

GPUStack vi permette di scegliere il motore giusto per ogni deployment, o di lasciare che il scheduler scelga per voi in base al workload.

Monitoraggio Integrato

GPUStack si integra nativamente con Grafana e Prometheus, offrendo dashboard in real-time per utilizzo GPU, consumo VRAM, token throughput e request rate dell’API. Non serve aggiungere uno stack di monitoraggio separato. Quando qualcosa si rompe alle 2 di notte, saprete esattamente quale GPU su quale macchina è il problema.

Recovery automatico dai guasti

Un nodo che cade a causa di un errore PCIe bus o un driver mismatch che si manifesta solo sotto carico pesante tipicamente porta la vostra API di inferenza a restituire 500 finché non intervenite manualmente. GPUStack rileva i nodi non raggiungibili e redistribuisce i workload automaticamente, eliminando la necessità di un intervento manuale d’emergenza.

Quando Usare GPUStack

GPUStack è la scelta giusta se:

• Avete 2 o più macchine GPU e volete servire LLM o altri modelli AI tramite una API unificata
• Volete eseguire inferenza sulla vostra hardware invece di pagare per token a un cloud provider — il risparmio sui costi a scala è reale
• Il vostro team non vuole diventare ingegneri di infrastruttura a tempo pieno solo per tenere i modelli in funzione

Forse non è la scelta giusta se:

• Avete una singola GPU e volete solo eseguire modelli localmente per uso personale: in quel caso Ollama è più semplice
• Siete già profondamente integrati in una piattaforma ML custom su Kubernetes con KubeFlow o simili, dove l’overlap potrebbe non valere l’investimento

Il Quadro Generale: l’Inferenza Self-Hosted è di Nuovo Praticabile

Il panorama dell’infrastruttura AI sta cambiando rapidamente. Un anno fa la maggior parte dei team optava automaticamente per API provider per l’inferenza. Oggi, con modelli open-weight sempre più capaci e costi GPU in calo, l’inferenza self-hosted è diventata un’opzione reale — non solo per i grandi player, ma per startup e aziende di medie dimensioni.

Il collo di bottiglia non è più l’hardware. Sono le operations: il codice collante tra “abbiamo le GPU” e “la nostra applicazione può chiamare un modello in modo affidabile”. GPUStack è un tentativo serio di risolvere questo gap, ed è open source sotto licenza Apache 2.0 — ispezionabile, modificabile e deployabile senza vendor lock-in.

Se avete hardware che al momento scalda solo la stanza server, o se siete stanchi di bollette di inferenza cloud che sembrano mutui, vale la pena provare. Il progetto è disponibile su GitHub.

Fonte originale: Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack — DZone

Learn How to Use GPUStack

Struggling to manage GPU clusters? Discover how GPUStack simplifies self-hosted AI inference with an easy-to-use, open-source, OpenAI-compatible API.

^{Sandeep Sadarangani (dzone.com)}