ProssimamenteL'Addestramento Modelli sarà presto disponibile in Scalata Enterprise. Insegni a un modello a rispondere come il Suo team.Scoprire le novità in arrivo

Risorse/Addestramento del modello/Test e distribuzione di un modello

Concetto

Inferenza e deployment

L'inferenza consiste nell'utilizzare un modello per generare risposte. Un modello addestrato deve prima essere sottoposto a deployment — i suoi pesi caricati sull'hardware dietro a un endpoint — un processo che può richiedere minuti, per poi comportare un costo per token o per ora.

Capitolo 9Lettura di 3 min4 riferimenti

Cos'è

L'inferenza è tutto ciò che accade dopo l'addestramento: viene inserito un prompt e il modello produce una risposta. Non viene appreso nulla; i pesi rimangono fissi. Ogni chat di test, ogni risposta di valutazione, ogni verdetto di giudizio e ogni risposta in produzione costituiscono inferenza.

Come funziona

Un modello genera testo un token alla volta. Inizialmente legge l'intero prompt in un unico passaggio (chiamato prefill), un'operazione rapida poiché tutti i token possono essere elaborati in parallelo. Successivamente decodifica: prevede il token successivo, lo aggiunge e ripete l'operazione fino a produrre un token finale o raggiungere un limite di lunghezza. Ogni nuovo token richiede un ulteriore passaggio attraverso il modello, motivo per cui le risposte lunghe richiedono più tempo rispetto alle domande lunghe.

  • Il Time to first token è costituito principalmente dal prefill: prompt più lunghi comportano un'attesa maggiore prima che appaia qualcosa.
  • I Tokens per second indicano la velocità di decodifica: determinano la rapidità con cui viene trasmessa la risposta.
  • Le Sampling settings, come la temperatura, stabiliscono come viene selezionato il token successivo in base alle probabilità del modello. Valori bassi rendono le risposte più prevedibili; valori alti le rendono più varie.
  • Batching: un server risponde a molteplici richieste contemporaneamente per mantenere attiva la GPU. I sistemi di serving come vLLM gestiscono la memoria in modo così efficiente da aver aumentato il throughput di 2–4 volte rispetto ai sistemi precedenti, a parità di latenza.

Deployment

L'addestramento produce un set di pesi archiviati presso il provider. Per fornire risposte, è necessario eseguire il deployment di tali pesi: caricarli nella memoria di una o più GPU, dietro a un endpoint che accetta le richieste. La memoria necessaria è approssimativamente pari al numero di parametri moltiplicato per i byte utilizzati per parametro:

perché i modelli di grandi dimensioni richiedono hardware potente
memory for weights ≈ parameters × bytes per parameter

7B model  × 2 bytes (16-bit)  ≈ 14 GB
70B model × 2 bytes (16-bit)  ≈ 140 GB  → several GPUs

L'allocazione di tale hardware, il download dei pesi e il loro caricamento nella memoria della GPU costituiscono l'avvio a freddo. Per i modelli gestiti è solitamente rapido o impercettibile; per i modelli aperti su GPU dedicate richiede spesso dai 10 ai 40 minuti. Una volta caricato, il deployment rimane attivo e risponde in pochi secondi — per tutta la sua durata.

  1. 01Scegliere la duratacosto orario mostrato in anticipo
  2. 02Deployment in corsocaricamento dei pesi · cold start
  3. 03Attivochat · il contatore scorre
  4. 04Eliminazionela fatturazione si interrompe
Un deployment dedicato viene fatturato per ogni ora di esistenza, che venga utilizzato o meno. Il ciclo di vita termina con la sua eliminazione.
Esempio pratico: test di un modello aperto ottimizzato
  1. Un'esecuzione supervisionata su un modello aperto da 8 miliardi di parametri è terminata. Con una precisione a 16 bit, i suoi pesi occupano circa 16 GB, quindi necessita di una GPU con una memoria superiore, oltre allo spazio per le richieste in fase di elaborazione.
  2. Avvia una chat di prova per due ore. Il prezzo orario viene mostrato prima di creare qualsiasi elemento.
  3. Distribuzione: la GPU viene allocata e i pesi vengono caricati. Questa operazione richiede circa 15 minuti; la fatturazione per la distribuzione è iniziata.
  4. Live: ogni domanda riceve risposta in uno o due secondi. Prova dieci domande reali della scorsa settimana.
  5. Termina in anticipo e chiude la sessione. L'azione Deleting rimuove il deployment e interrompe la fatturazione. Costo: il tempo di esistenza del deployment × il prezzo orario, indipendentemente dal numero di domande poste.

Errori comuni

  • Lasciare un deployment dedicato in esecuzione durante la notte “per sicurezza” — viene fatturato a ore, che sia utilizzato o meno.
  • Valutare un modello in base alla sua prima risposta dopo un avvio a freddo, o al tempo di risposta mentre è ancora in fase di caricamento.
  • Effettuare test con impostazioni di campionamento o prompt di sistema diversi da quelli utilizzati in fase di valutazione.
  • Aspettarsi che un modello ottimizzato conosca eventi accaduti dopo l'addestramento: l'inferenza non apprende.

Riferimenti e letture di approfondimento

Le fonti esterne si aprono in una nuova scheda.

  1. 01Efficient Memory Management for Large Language Model Serving with PagedAttentionKwon et al., 2023 · arXiv · arxiv.orgIl documento su vLLM: come i sistemi di serving raggruppano le richieste e gestiscono la memoria della GPU.
  2. 02Text Generation InferenceHugging Face docs · huggingface.coUno stack di serving in produzione per modelli aperti, con la spiegazione delle sue funzionalità.
  3. 03Inference EndpointsHugging Face docs · huggingface.coCosa comporta il deployment di un modello dietro a un endpoint gestito.
  4. 04Cold start (computing)Wikipedia · en.wikipedia.orgIl concetto generale di avvio a freddo.
ConcettoServerless vs dedicatoIl serving serverless fattura per token su capacità condivisa senza costi di inattività; un deployment dedicato riserva le GPU per il modello e fattura per ogni ora di esistenza. La convenienza dipende dall'utilizzo.Best practiceCi sarà spazio per il modello? Memoria per l'addestramentoL'addestramento richiede spazio per i pesi del modello, i suoi gradienti e lo stato dell'ottimizzatore, oltre alla memoria di lavoro. Una semplice regola empirica, circa 2 GB per miliardo di parametri per LoRA e 12 GB per il full fine-tuning, permette di sapere prima di iniziare se un modello è adatto alla propria macchina.ConcettoPerché i token determinano i costiCome i conteggi dei token si traducono nel prezzo di addestramento e di utilizzo di un modello, con esempi numerici pratici, e quali leve riducono effettivamente i costi.ImpostazionePrompt di sistemaIl prompt di sistema è un'istruzione permanente inserita prima di ogni conversazione. Aggiunto durante l'addestramento, il modello apprende il proprio comportamento in presenza di quell'esatto prompt, pertanto dovrebbe rimanere invariato quando il modello viene utilizzato.ConcettoModello di base e ottimizzato a confrontoUna valutazione pone al modello di partenza e al modello addestrato le stesse domande tenute da parte e ne confronta le risposte, in modo che Lei possa vedere se l'addestramento ha effettivamente migliorato le risposte.ConcettoCome viene fatturato l'addestramentoLa maggior parte del fine-tuning gestito viene fatturata per token elaborato: token nel file di addestramento moltiplicati per le epoche e per un prezzo. I job su GPU a noleggio vengono invece fatturati a tempo. L'utilizzo successivo del modello rappresenta un costo separato.

Trasformate settimane di lavoro esperto in pochi minuti

Scoprite come Scalata si adatta al vostro team, ai vostri dati e ai vostri Controlli.

Contatta il team vendite