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

Serverless vs dedicato

Il 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.

Capitolo 9Lettura di 4 min3 riferimenti

Cos'è

Esistono due modi per eseguire un modello addestrato. Il Serverless (chiamato anche per-token o on-demand) lo esegue su una capacità che il provider condivide tra molti clienti: si inviano richieste e si pagano i token in entrata e in uscita, e quando non si invia nulla non si paga nulla. Una distribuzione dedicata riserva l'hardware esclusivamente al proprio modello: è sempre caricato e pronto all'uso, e si paga per ogni ora in cui esiste.

ServerlessDedicato
Fatturato perToken di input e di outputOre di esistenza del deployment
Costo di inattivitàNessunoPrezzo orario intero
AvvioSolitamente immediatoUn avvio a freddo di alcuni minuti al momento della creazione
CapacitàCondivisa; soggetta a limiti di frequenzaRiservata; throughput prevedibile
DisponibilitàSolo per i modelli supportati in questo modo dal providerLa maggior parte dei modelli addestrati, inclusi i modelli aperti

Confronto dei costi

il punto di pareggio
serverless cost per day  = tokens per day × price per token
dedicated cost per day   = 24 × hourly price               (used or not)
break-even tokens/day    = 24 × hourly price ÷ price per token
utilizzo (token al giorno)costo giornalieroPUNTO DI PAREGGIOSERVERLESS PIÙ CONVENIENTEDEDICATO PIÙ CONVENIENTEdedicato: ore × prezzo orarioserverless: token × prezzo
Il costo del serverless cresce con ogni token; un'implementazione dedicata ha lo stesso costo orario sia che risponda a una domanda o a un milione. Al di sotto del punto di pareggio il serverless è più economico, al di sopra lo è il dedicato — e un'implementazione dedicata inattiva si colloca all'estrema sinistra del grafico, pagando l'intera tariffa per nulla.

Il principio: con una distribuzione dedicata, il costo per token è il prezzo orario diviso per il numero di token effettivamente elaborati in quell'ora. A pieno carico può essere più economico del serverless. A basso carico è molto più costoso e un'ora di inattività ha un costo per token infinito. Il serverless ha un andamento opposto: il prezzo per token è fisso, quindi il costo segue esattamente l'utilizzo.

Perché non è tutto serverless? Il servizio condiviso funziona mantenendo un modello di base caricato per molti clienti. Alcuni provider possono collegare un piccolo adattatore sottoposto a fine-tuning a quel modello condiviso per ogni richiesta, rendendo possibile il servizio per token per i modelli ottimizzati. Altri richiedono che l'intero modello ottimizzato sia caricato su un hardware dedicato — una pratica comune per i modelli aperti e per i fine-tuning completi — e in tal caso la distribuzione dedicata è l'unica opzione. Alcuni provider si spingono oltre e richiedono capacità riservata per qualsiasi modello personalizzato.

Esempio pratico: prezzi illustrativi, tre livelli di utilizzo
  1. Ipotizziamo (a titolo esemplificativo, non sono quotazioni reali) un'architettura serverless a 0,60 $ per milione di token e una distribuzione dedicata a 5 $ all'ora, ovvero 120 $ al giorno.
  2. Punto di pareggio: 120 $ ÷ 0,60 $ per milione = 200 milioni di token al giorno.
  3. Una giornata di test: 300 domande × 1.500 token = 450.000 token. Serverless: circa 0,27 $. Dedicata: 120 $ per l'intera giornata, oppure 10 $ se viene eliminata dopo due ore.
  4. Un assistente interno molto utilizzato: 50 milioni di token al giorno. Serverless: 30 $. Dedicata: sempre 120 $.
  5. Un prodotto ad alto volume: 500 milioni di token al giorno. Serverless: 300 $. Dedicata: 120 $, se una singola distribuzione è in grado di gestire il carico.

Come scegliere

  • Utilizzare il serverless quando disponibile e l'utilizzo è basso, incerto o a picchi — test, valutazioni, progetti pilota.
  • Utilizzare la distribuzione dedicata quando il modello può essere servito solo in quel modo, quando il traffico costante è superiore al punto di pareggio, o quando sono necessarie capacità e latenza garantite.
  • Impostare sempre un orario di fine su una distribuzione dedicata utilizzata per i test ed eliminarla al termine. Impegni di settimane o mesi possono abbassare il prezzo orario, ma eliminano questa opzione.

Errori comuni

  • Dimenticare una distribuzione di test dedicata e pagare per giorni di ore di inattività.
  • Confrontare un prezzo orario per una distribuzione dedicata con un prezzo per token serverless senza effettuare la conversione in base all'utilizzo previsto.
  • Dare per scontato che un modello ottimizzato possa essere servito per token solo perché lo è il suo modello di base.
  • Firmare un impegno di capacità a lungo termine per un modello che è ancora in fase di iterazione.

Riferimenti e letture di approfondimento

Le fonti esterne si aprono in una nuova scheda.

  1. 01Increase model invocation capacity with Provisioned Throughput in Amazon BedrockAmazon Bedrock User Guide · docs.aws.amazon.comUn esempio reale di capacità riservata: fatturata su base oraria fino all'eliminazione, con impegni opzionali.
  2. 02Inference EndpointsHugging Face docs · huggingface.coEndpoint dedicati per modelli aperti, con autoscaling.
  3. 03Serverless computingWikipedia · en.wikipedia.orgIl modello generale di pagamento a consumo e i relativi compromessi, come gli avvii a freddo.
ConcettoInferenza e deploymentL'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.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.ConcettoI costi: come leggere i numeriL'attività del modello viene fatturata in diversi modi, pertanto ogni costo mostrato da Scalata presenta uno stato — Definitivo, Stimato, In sospeso o Non fatturato — che indica su cosa si basa la cifra.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.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.MetodoLoRA e adattatori (PEFT)LoRA congela il modello di base e addestra due piccole matrici accanto a layer selezionati, il cui prodotto viene aggiunto ai pesi congelati. Riduce drasticamente i pesi addestrabili e la memoria e, se ben configurato, eguaglia il fine-tuning completo sui tipici set di dati di fine-tuning.

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