Perché stiamo passando agli Endpoint di Inference di Hugging Face, e forse dovresti farlo anche tu

Passaggio agli Endpoint di Inference di Hugging Face perché dovresti farlo anche tu

Hugging Face ha recentemente lanciato Inference Endpoints; che, come hanno descritto, risolve il problema dei transformers in produzione. Inference Endpoints è un servizio gestito che ti permette di:

  • Deployare (quasi) qualsiasi modello su Hugging Face Hub
  • Su qualsiasi cloud (AWS, Azure, GCP in arrivo)
  • Su diversi tipi di istanze (incluso GPU)
  • Stiamo passando alcuni dei nostri modelli di Machine Learning (ML) che fanno inferenza su CPU a questo nuovo servizio. Questo blog riguarda il motivo per cui l’abbiamo fatto e perché potresti volerlo considerare anche tu.

Cosa stavamo facendo?

I modelli che abbiamo passato a Inference Endpoints erano precedentemente gestiti internamente e venivano eseguiti su AWS Elastic Container Service (ECS) supportato da AWS Fargate. Questo ti permette di avere un cluster serverless che può eseguire attività basate su container. Il nostro processo era il seguente:

  • Allenare il modello su un’istanza GPU (fornita da CML, addestrata con transformers)
  • Caricare su Hugging Face Hub
  • Creare un’API per servire il modello (FastAPI)
  • Includere l’API in un container (Docker)
  • Caricare il container su AWS Elastic Container Repository (ECR)
  • Deployare il modello su un cluster ECS

Ora, si potrebbe ragionevolmente sostenere che ECS non fosse il miglior approccio per servire modelli di ML, ma ci ha servito fino ad ora e ha anche permesso ai modelli di ML di essere insieme ad altri servizi basati su container, riducendo così il carico cognitivo.

Cosa facciamo ora?

Con Inference Endpoints, il nostro flusso appare così:

  • Allenare il modello su un’istanza GPU (fornita da CML, addestrata con transformers)
  • Caricare su Hugging Face Hub
  • Deployare usando Hugging Face Inference Endpoints.

Quindi tutto questo è significativamente più facile. Potremmo anche utilizzare un altro servizio gestito come SageMaker, Seldon o Bento ML, ecc., ma dato che stiamo già caricando il nostro modello su Hugging Face Hub per usarlo come registro dei modelli e siamo molto impegnati negli altri strumenti di Hugging Face (come transformers e AutoTrain), l’utilizzo di Inference Endpoints ha molto senso per noi.

Cosa dire di latenza e stabilità?

Prima di passare a Inference Endpoints abbiamo testato diversi tipi di endpoint CPU utilizzando ab.

Per ECS non abbiamo testato così approfonditamente, ma sappiamo che un grande container aveva una latenza di circa ~200ms da un’istanza nella stessa regione. I test che abbiamo fatto per Inference Endpoints erano basati su un modello di classificazione del testo sintonizzato su RoBERTa con i seguenti parametri di test:

  • Regione richiedente: eu-east-1
  • Dimensione dell’istanza richiedente: t3-medium
  • Regione endpoint di inferenza: eu-east-1
  • Repliche del endpoint: 1
  • Connessioni simultanee: 1
  • Richieste: 1000 (1000 richieste in 1-2 minuti anche da una singola connessione rappresenterebbero un utilizzo molto intenso per questa particolare applicazione)

La seguente tabella mostra la latenza (ms ± deviazione standard e tempo per completare il test in secondi) per quattro endpoint CPU equipaggiati con Intel Ice Lake.

dimensione   |  vCPU (core) |   Memoria (GB)  |  ECS (ms) |  🤗 (ms)
----------------------------------------------------------------------
piccola  |  1            |  2             |   _       | ~ 296   
VoAGI |  2            |  4             |   _       | 156 ± 51 (158s)  
grande  |  4            |   8            |   ~200    | 80 ± 30 (80s)   
molto grande |  8            | 16             |  _        | 43 ± 31 (43s)    

Ciò che vediamo da questi risultati è piuttosto incoraggiante. L’applicazione che utilizzerà questi endpoint serve richieste in tempo reale, quindi abbiamo bisogno di una latenza più bassa possibile. Possiamo vedere che il container di Hugging Face vanilla è stato più del doppio più veloce rispetto al nostro container personalizzato eseguito su ECS – la risposta più lenta che abbiamo ricevuto dal grande Inference Endpoint è stata di soli 108ms.

Cosa dire del costo?

Quanto costa tutto questo? La tabella sottostante mostra un confronto di prezzi per quello che stavamo facendo in precedenza (ECS + Fargate) e l’utilizzo di Inference Endpoints.

size   |  vCPU         |   Memoria (GB)  |  ECS      |  🤗       |  % diff
----------------------------------------------------------------------
small  |  1            |  2             |  $ 33.18  | $ 43.80   |  0.24
VoAGI |  2            |  4             |  $ 60.38  | $ 87.61   |  0.31 
large  |  4            |  8             |  $ 114.78 | $ 175.22  |  0.34
xlarge |  8            | 16             |  $ 223.59 | $ 350.44  | 0.5 

Possiamo dire un paio di cose riguardo a questo. Innanzitutto, vogliamo una soluzione gestita per il deployment, non abbiamo ancora un team dedicato a MLOps, quindi stiamo cercando una soluzione che ci aiuti a ridurre il tempo che spendiamo nel deploy dei modelli, anche se costa un po’ di più rispetto alla gestione dei deployment da parte nostra.

Gli Inference Endpoints sono più costosi rispetto a quello che facevamo prima, c’è un aumento dei costi tra il 24% e il 50%. Alla scala in cui stiamo operando attualmente, questo costo aggiuntivo, una differenza di ~$ 60 al mese per una grande istanza CPU, non è nulla rispetto al tempo e al carico cognitivo che stiamo risparmiando non dovendo preoccuparci di API e container. Se dovessimo distribuire centinaia di microservizi di ML probabilmente vorremmo ripensarci, ma questo è probabilmente vero per molti approcci di hosting.

Alcune note e avvertenze:

  • Puoi trovare i prezzi per gli Inference Endpoints qui, ma viene visualizzato un numero diverso quando si distribuisce un nuovo endpoint dalla GUI. Ho usato quest’ultimo, che è più alto.
  • I valori che presento nella tabella per ECS + Fargate sono una stima al ribasso, ma probabilmente non di molto. Li ho estratti dalla pagina dei prezzi di Fargate e includono solo il costo di ospitare l’istanza. Non sto includendo il traffico dati in ingresso/uscita (probabilmente la cosa più importante è scaricare il modello dall’Hugging Face hub), né ho incluso i costi correlati a ECR.

Altre considerazioni

Opzioni di deployment

Attualmente puoi distribuire un Inference Endpoint dalla GUI o utilizzando un’API RESTful. Puoi anche utilizzare il nostro strumento da riga di comando hugie (che sarà oggetto di un futuro blog) per lanciare Inference Endpoints in una sola riga di codice passando una configurazione, è davvero semplice:

hugie endpoint create example/development.json

Per me, ciò che manca è un provider terraform personalizzato. È bello e buono distribuire un inference endpoint da un’azione GitHub utilizzando hugie, come facciamo, ma sarebbe meglio se potessimo utilizzare l’incredibile stato del sistema che è terraform per tenerne traccia. Sono abbastanza sicuro che qualcuno (se non Hugging Face) scriverà presto uno – in caso contrario, lo faremo noi.

Ospitare più modelli su un singolo endpoint

Philipp Schmid ha pubblicato un blog molto interessante su come scrivere una classe Custom Endpoint Handler per consentirti di ospitare più modelli su un singolo endpoint, risparmiandoti potenzialmente parecchi soldi. Il suo blog riguardava l’inferenza GPU e l’unico vero limite è quanti modelli puoi inserire nella memoria GPU. Presumo che questo funzioni anche per le istanze CPU, anche se non ho ancora provato.

Per concludere…

Troviamo gli Inference Endpoints di Hugging Face un modo molto semplice e conveniente per distribuire modelli transformer (e sklearn) in un endpoint in modo che possano essere consumati da un’applicazione. Anche se costano un po’ di più rispetto all’approccio ECS che stavamo usando prima, vale davvero la pena perché ci fa risparmiare tempo nel pensare al deployment, possiamo concentrarci sulla cosa che vogliamo fare: costruire soluzioni NLP per i nostri clienti per aiutarli a risolvere i loro problemi.

Se sei interessato agli Inference Endpoints di Hugging Face per la tua azienda, contattaci qui: il nostro team ti contatterà per discutere delle tue esigenze!

Questo articolo è stato originariamente pubblicato il 15 febbraio 2023 su VoAGI.