Confronto tra server di inferenza: soluzioni open source per modelli di IA

Cosa fa un server di inferenza

Un server di inferenza mette a disposizione un modello di IA già addestrato per le richieste. Un'applicazione invia i dati di input a un API, il server le trasmette a un'istanza del modello, che le elabora utilizzando i pesi del modello caricati. Il risultato viene restituito all'applicazione tramite il server. Nel caso di un modello linguistico, può trattarsi di una risposta testuale; a seconda dell'interfaccia, può anche essere emessa gradualmente sotto forma di flusso di token.

Il server, il runtime e il modello sono componenti distinti. I pesi contengono i parametri appresi; il runtime esegue i calcoli sull’hardware disponibile. Il server, invece, organizza l’accesso e l’inoltro delle richieste. Un cambio di server non sostituisce quindi automaticamente il modello, ma può richiedere un formato diverso o un runtime diverso.

Per la gestione degli utenti e la logica di business è solitamente necessario un livello applicativo aggiuntivo. Questo livello determina, ad esempio, quali utenti sono autorizzati a inviare una richiesta, quali dati vengono trasmessi al modello e in che modo la risposta di quest’ultimo viene integrata in un flusso di lavoro. Un’API del modello accessibile da sola non è sufficiente a rappresentare queste regole; anche la protezione degli accessi e la registrazione devono essere pianificate come parte integrante del sistema complessivo.

Inoltre, un server LLM progettato per la generazione di testo non è automaticamente una piattaforma per la classificazione delle immagini o altri tipi di modelli. A tal fine, è necessario che siano supportate la rispettiva architettura del modello e un runtime adeguato. Triton adotta un approccio più ampio: inoltra le richieste ai backend tramite scheduler specifici per ciascun modello. Tuttavia, la possibilità di eseguire un modello specifico dipende dal backend appropriato.

Verificare il modello, l'hardware e i diritti

Inizia la selezione partendo dall'incarico e da un caso concreto Revisione del modello: Un modello di chat, un modello di embedding e un classificatore di immagini presentano requisiti diversi. Prendi inoltre nota del formato dei pesi utilizzato e verifica se l'esecuzione desiderata supporti esattamente quella specifica architettura e revisione. Il solo nome di un modello noto non è sufficiente per dare per scontata la compatibilità o la coerenza dei risultati.

• Specificare l'obiettivo, la revisione del modello e il formato di ponderazione disponibile.
• Verificare CPU o GPU, memoria disponibile, driver e backend richiesto.
• Chiarire separatamente i diritti di utilizzo relativi a server, pesi dei modelli e componenti aggiuntivi.
• Documentare la lunghezza prevista delle richieste, il parallelismo e i requisiti relativi alla protezione degli accessi.

La scelta dell'hardware non si limita alla semplice presenza o meno di una GPU. I pesi devono rientrare nella memoria disponibile insieme al codice di esecuzione e ai dati aggiuntivi; anche i driver e il backend devono essere compatibili con la piattaforma. La documentazione sul backend di Triton sottolinea che non tutti i backend sono supportati su ogni piattaforma. Verifica quindi la combinazione di versione del server, modello, backend e hardware, anziché dedurre la compatibilità dal nome del prodotto.

Anche il formato può limitare la scelta: secondo la documentazione del progetto, llama.cpp richiede modelli in Formato GGUF. Per altri formati, il progetto descrive una procedura di conversione; ciò non significa però che ogni architettura o variante del modello funzioni senza modifiche. Il codice sorgente si trova nel ramo di sviluppo. Prima di procedere alla distribuzione, dovresti quindi verificare che le specifiche corrispondano alla versione scelta.

Un server open source non trasferisce la propria licenza ai pesi dei modelli. Verifica separatamente per entrambi se l'uso interno o commerciale previsto è consentito e quali condizioni si applicano. Il fatto che i pesi possano essere scaricati non costituisce di per sé un'autorizzazione a qualsiasi utilizzo o diffusione.

In che modo le richieste LLM consumano risorse

Quando riceve una richiesta di testo, il modello elabora innanzitutto l'input. Questa fase si chiama Precompilazione. Successivamente, nella fase di decodifica, genera la risposta token per token. Un prompt breve e una risposta lunga comportano un carico di lavoro diverso nella fase di generazione rispetto a un lungo estratto di documento con una risposta concisa. Entrambi i casi dovrebbero quindi essere presi in considerazione nella pianificazione delle capacità.

Durante la generazione, il runtime memorizza i dati temporanei nel Cache KV in modo che il contesto già elaborato possa essere riutilizzato nelle fasi successive. Questo fabbisogno di memoria si aggiunge ai pesi del modello e varia in base alla lunghezza delle sequenze e al numero di richieste elaborate contemporaneamente. Il fatto che il modello da solo rientri nella memoria non garantisce che anche il carico previsto possa essere gestito.

Il "Continuous Batching" raggruppa in modo flessibile le richieste di generazione in corso, anziché attendere semplicemente un unico batch fisso. Il "PagedAttention" organizza la memoria della cache KV in blocchi. Entrambe le tecniche sono descritte per i vLLM e possono migliorare l'utilizzo delle risorse. L'efficacia di tali tecniche dipende tuttavia, tra l'altro, dalle dimensioni delle richieste, dal parallelismo e dall'hardware; non è quindi possibile dedurne un vantaggio per ogni carico di lavoro.

Triton, invece, descrive un’architettura server generica: uno scheduler basato su modelli riceve le richieste e le inoltra al backend competente. È possibile configurare il batching dinamico per un modello. Ciò non implica che ogni backend tratti internamente le richieste LLM allo stesso modo o utilizzi le stesse procedure di memorizzazione del vLLM. Ai fini del confronto, è quindi determinante la combinazione specifica di backend e modello.

Per un servizio di chat interno, quindi, non è sufficiente considerare solo il numero di token al secondo. Oltre alla velocità di output, anche il tempo necessario per il primo token e i tempi di attesa in caso di richieste simultanee influenzano l’esperienza d’uso. Confronta le soluzioni candidate con lunghezze di input e output rappresentative e lo stesso livello di parallelismo, prima di prendere una decisione sull’hardware.

Classificare quattro soluzioni, prendere in considerazione SGLang come alternativa

La seguente panoramica classifica vLLM, llama.cpp, Triton e TGI in base ai loro approcci documentati. Non si tratta di un confronto delle funzionalità o delle prestazioni relativo a una versione specifica. SGLang rimane un'alternativa non valutata: Hugging Face lo raccomanda insieme a vLLM come successore di TGI, ma da ciò non è possibile dedurre né i formati dei modelli né le interfacce o il supporto hardware di una specifica versione di SGLang.

Il codice sorgente contiene pagine di documentazione soggette a modifiche e, nel caso di llama.cpp, un ramo di sviluppo. Non è quindi documentata alcuna verifica completa per vLLM 0.10.2, llama.cpp b6000, Triton 25.10 o TGI 3.3.7. Queste corrispondenze di versione non vengono quindi utilizzate come base di confronto. Prima di procedere alla distribuzione, è necessario verificare le caratteristiche richieste per la versione del server e la revisione del modello effettivamente selezionate.

Il reale Spese operative dipende, tra l’altro, dalla messa a disposizione dei modelli, dalla protezione degli accessi e dal monitoraggio. Dalla tabella non è possibile ricavare un confronto diretto dei costi: un’installazione locale singola e una piattaforma con più backend presentano requisiti diversi. Verifica quindi innanzitutto quali compiti l’installazione debba effettivamente svolgere.

Hugging Face guida la classifica TGI nel Modalità di manutenzione e indica vLLM e SGLang come alternative. Non è quindi necessario sostituire immediatamente un’installazione esistente. Per i nuovi progetti, tuttavia, è opportuno tenere conto nella pianificazione del fatto che lo sviluppo futuro sarà limitato; prima di procedere alla migrazione, occorre confrontare separatamente il comportamento delle API e la qualità dei modelli.

Triton e vLLM non si escludono a vicenda in linea di principio: Triton può utilizzare un backend vLLM. È comunque necessario verificare se un determinato modello funzioni con le versioni selezionate e la piattaforma disponibile per quella combinazione. L’architettura generale di Triton, di per sé, non garantisce il supporto per ogni backend su ogni piattaforma.

Preparare il prototipo locale

Per creare un prototipo locale, devi innanzitutto definire il compito e alcuni input tipici. Scegli quindi una versione specifica del modello che ti sembri adatta allo scopo e verifica le relative condizioni d’uso. La licenza del server da sola non indica se sei autorizzato a scaricare, modificare o utilizzare i pesi del modello per lo scopo previsto.

llama.cpp utilizza il formato GGUF. Cerca una variante GGUF adeguata oppure verifica se il modello di partenza possa essere convertito con gli strumenti documentati. La documentazione del progetto descrive tali conversioni nel ramo di sviluppo; essa non costituisce una garanzia che ogni versione precedente supporti ogni architettura o opzione di conversione.

Prima di effettuare il download, verifica che la variante scelta sia supportata dalla tua CPU o GPU con il backend previsto e che sia disponibile memoria sufficiente per i pesi e il runtime. Una variante quantizzata può ridurre il fabbisogno di memoria dei pesi. Confronta però le risposte ottenute con i tuoi requisiti di qualità, invece di dedurre che i risultati siano invariati solo perché il file è più piccolo.

Scegli una build specifica per il prototipo e verifica che l'installazione e le opzioni del server corrispondano alla relativa documentazione. Per la build b6000 menzionata in precedenza non risulta documentata alcuna verifica legata alla versione; pertanto, non è raccomandata come punto di partenza verificato. La documentazione del modello disponibile sul ramo di sviluppo non sostituisce né la documentazione del server relativa alla build selezionata né la relativa verifica di compatibilità.

Inizia per ora a rendere disponibile il servizio solo in locale e invia diverse richieste rappresentative. A tal proposito, verifica non solo se viene visualizzata una risposta, ma anche se il formato di input, il modello e le impostazioni di generazione sono adeguati all’applicazione che intendi realizzare. Una singola chiamata riuscita non garantisce né l’idoneità a carichi più elevati né la qualità di tutte le risposte.

Tieni traccia separatamente di tre aspetti: la qualità dei contenuti sulla base dei tuoi casi di test, il tempo di risposta percepito e lo sforzo richiesto per il download, la conversione e la messa a disposizione. In questo modo potrai capire, ad esempio, se un modello configurato rapidamente sia inadeguato dal punto di vista tecnico. Per la gestione separata dell’host Linux, il Panoramica su 1Panel come strumento di gestione dei server contesto aggiuntivo; un pannello di controllo del server non sostituisce la verifica della durata di esecuzione del modello.

Pianificazione del carico e dello spazio di archiviazione

In un servizio di chat interno, le richieste spesso presentano notevoli differenze: una breve domanda con una risposta concisa richiede risorse diverse rispetto a un lungo estratto di documento con un output dettagliato. È quindi necessario considerare le lunghezze tipiche e massime degli input e degli output, nonché il numero previsto di utenti simultanei. Una singola chiamata riuscita non descrive in modo adeguato la situazione sotto carico.

Lo spazio di memoria richiesto non è costituito solo dai pesi dei modelli. Anche i tempi di esecuzione e i valori intermedi richiedono spazio; inoltre, in caso di richieste LLM in parallelo, aumenta il fabbisogno di Cache KV. Contesti più lunghi e un numero maggiore di richieste elaborate contemporaneamente possono quindi portare una configurazione al limite delle sue capacità, anche se i pesi rientrano da soli nella memoria disponibile.

Il "Continuous Batching" e il "PagedAttention" sono approcci documentati nei vLLM per la gestione delle richieste in corso e della memoria cache, rispettivamente. Tuttavia, non ti sollevano dal compito di pianificare la capacità: quale combinazione di parallelismo e lunghezza del contesto sia praticabile dipende dal modello, dall’hardware e dalla configurazione scelta. Da ciò non è possibile dedurre un aumento generalizzato delle prestazioni per ogni carico di lavoro.

Un semplice calcolo quantitativo aiuta nella preparazione: 100 richieste ipotetiche, ciascuna con 200 token di emissione, danno in totale 20.000 token di emissione. Questo equivale a nessuna misurazione della portata. In assenza di dati relativi all'intervallo di tempo, alla lunghezza degli input, al parallelismo e ad altri parametri operativi, non è possibile trarre alcuna conclusione né sul numero di token al secondo né sui costi.

Per un confronto successivo, crea una matrice di test che includa modello e revisione, quantizzazione, versione del server, hardware e memoria disponibile. Varia in modo controllato la lunghezza degli input e degli output, nonché il parallelismo. Registra il tempo necessario per ottenere il primo token, la velocità di output e il tasso di errore; valuta separatamente la qualità della risposta sulla base degli stessi casi di test. Anche i parametri di generazione e i modelli di chat devono essere inclusi nel protocollo, in modo che le differenze rimangano tracciabili.

Gestire l'API in modo sicuro e monitorabile

Un raggiungibile Server di inferenza Non è ancora un servizio sicuro. Limita innanzitutto l'accesso alla rete ai sistemi che devono inviare richieste o amministrare il server. Per l'accesso esterno, è necessario predisporre un sistema di protezione dell'accesso a monte dell'API; verifica tutti gli endpoint raggiungibili e non solo il percorso per la generazione di testo.

Avviso: Secondo la documentazione, l’opzione “API Key” di vLLM non protegge tutti gli endpoint. Una chiave impostata non sostituisce quindi né l’isolamento di rete né un controllo degli accessi a monte che tenga conto anche delle interfacce amministrative e di altre interfacce accessibili. Verifica le regole dalle rispettive reti prima di abilitare il servizio.

I prompt e le risposte possono contenere informazioni riservate. Stabilisci quindi in anticipo quali dati devono essere registrati, chi è autorizzato a consultarli e quando devono essere cancellati. Per la ricerca degli errori sono spesso sufficienti dati tecnici quali l'ora, la versione del modello, il tipo di errore e la durata della richiesta; dovresti registrare i contenuti completi solo in caso di necessità giustificata.

Il sito Osservabilità dovrebbe registrare separatamente il tempo di attesa, il tempo fino al primo token, la velocità di emissione e gli errori. Se, ad esempio, il tempo di attesa aumenta in caso di richieste simultanee, mentre le singole risposte vengono elaborate rapidamente una volta avviate, ciò indica un collo di bottiglia diverso da un'emissione lenta dei token. Valuta questi indicatori insieme alle dimensioni delle richieste e al parallelismo.

Per la gestione degli host sottostanti, gli strumenti di amministrazione possono raggruppare compiti e responsabilità. Per selezionare separatamente questo livello di amministrazione, il Confronto tra ISPConfig e Froxlor contesto aggiuntivo. La scelta di un pannello server è una decisione infrastrutturale a sé stante; tale pannello non sostituisce né la protezione dell'API del modello né il monitoraggio del servizio di inferenza.

Individuare l'errore e migrare TGI

Se un modello non si avvia, verifica innanzitutto che la revisione del modello e il formato siano compatibili con l'ambiente di esecuzione selezionato. Nel caso di llama.cpp, il formato richiesto è GGUF; tuttavia, la semplice conversione non garantisce che l'architettura e il compito specifici funzionino. Successivamente, verifica se il backend selezionato e la combinazione hardware sono supportati e se è disponibile memoria sufficiente.

Se il server si avvia ma fornisce risposte in chat inaspettate, controlla questo Modello di chat e i parametri di generazione forniti. Un’interfaccia compatibile con OpenAI non implica che ogni parametro venga implementato in modo identico: la documentazione di vLLM indica anche i parametri non supportati o ignorati. Confronta quindi le impostazioni effettivamente utilizzate e non solo la forma della chiamata API.

Nel caso di un servizio TGI già esistente, la migrazione inizia con un’analisi dello stato attuale: tra gli aspetti da considerare figurano la revisione del modello, le chiamate API utilizzate, le impostazioni di campionamento e i requisiti relativi alla qualità della risposta. Hugging Face gestisce TGI in modalità di manutenzione e indica, tra le altre, vLLM e SGLang come alternative. Ciò rende opportuno valutare un passaggio, ma non comporta un'interruzione immediata delle installazioni esistenti.

Costruisci il Installazione di destinazione Analizzali separatamente e confronta entrambi i servizi utilizzando gli stessi dati di input rappresentativi, le stesse lunghezze di output e le stesse condizioni di carico. Oltre alla qualità delle risposte e agli errori, verifica anche se i client riescono a gestire la nuova interfaccia e i relativi parametri. Non trasferire il traffico finché i risultati non sono accettabili per l’utilizzo previsto e non è stata predisposta una soluzione di ripiego.

Anche la guida di Hugging Faces per gli endpoint di inferenza raccomanda di creare un nuovo endpoint ed eseguire alcune chiamate di prova prima di effettuare il passaggio. Si tratta di un modello procedurale utile per la pianificazione, ma non di una guida passo passo universale per le installazioni gestite autonomamente: la rete, l’implementazione e il controllo del traffico potrebbero essere organizzati in modo diverso in tali contesti.

Scegliere l'architettura più adatta

Per un prototipo locale Il file llama.cpp rappresenta un punto di verifica ovvio quando si dispone di un modello GGUF adeguato e di un supporto hardware appropriato. Ciò non implica tuttavia alcuna raccomandazione per una build specifica. Non è determinante solo il fatto che il server si avvii: occorre confrontare anche la qualità dell’attività richiesta, il tempo di risposta e lo sforzo richiesto per i pesi del modello. Il supporto del modello e del backend devono essere verificati per la combinazione specifica.

Per un servizio di chat interno, vLLM potrebbe essere preso in considerazione come candidato da testare: la documentazione disponibile descrive un’interfaccia di chat compatibile con OpenAI con il modello di chat richiesto. Non risulta quindi documentato alcun test per la versione 0.10.2. SGLang rimane in questo contesto un'alternativa non valutata indicata nella documentazione TGI; in assenza di un test tecnico sulla versione, non è possibile considerarlo equivalente.

Una piattaforma per modelli di immagini e modelli linguistici presenta requisiti diversi rispetto a un singolo endpoint di chat. Triton rappresenta un punto di riferimento grazie ai suoi scheduler e backend basati sui modelli, sebbene la versione 25.10 non sia stata verificata in questo contesto. Questa architettura rende la Supporto backend Per quanto riguarda la questione fondamentale dei dettagli: non tutti i backend sono supportati su ogni piattaforma, e ogni modello richiesto deve essere verificato nella combinazione specifica.

Per la decisione, prendi in considerazione la revisione del modello, la versione del server, l’hardware, il backend e i diritti d’uso. Confronta poi la qualità, i tempi di risposta sotto il carico previsto e l’impegno richiesto per la sicurezza, gli aggiornamenti e la ricerca degli errori. Una soluzione adeguata per una prova locale potrebbe richiedere un’infrastruttura aggiuntiva in presenza di più utenti o tipi di modelli; una classifica generica nasconderebbe queste differenze.