Una Guida Pratica per il Deployment dei Modelli Foundation di Ricerca in Produzione

In Jina AI, la nostra missione è fornire agli utenti aziendali soluzioni di ricerca di alta qualità. Per raggiungere questo obiettivo, rendiamo i nostri modelli accessibili attraverso vari canali. Tuttavia, scegliere il canale giusto per il proprio caso d'uso specifico può essere complesso. In questo articolo, vi guideremo attraverso il processo decisionale e analizzeremo i compromessi, fornendovi una guida pratica sul modo migliore per accedere ai nostri modelli di ricerca fondamentali in base al vostro profilo utente e alle vostre esigenze.

tagModelli di Ricerca Fondamentali Jina

I Nostri Modelli di Ricerca Fondamentali

Abbiamo fatto progressi nei modelli di ricerca sin dal primo giorno. Dai un'occhiata alla nostra evoluzione dei modelli qui sotto - passa il mouse o clicca per scoprire ogni traguardo.

Jina AI

I nostri modelli di ricerca fondamentali includono:

• Embeddings: Questi convertono le informazioni sugli oggetti digitali in vettori di embedding, catturando le loro caratteristiche essenziali.
• Rerankers: Questi eseguono un'analisi semantica approfondita degli insiemi query-documento per migliorare la rilevanza della ricerca.
• Small language models: Questi includono SLM specializzati come ReaderLM-v2 per compiti specifici come HTML2Markdown o l'estrazione di informazioni.

In questo articolo, esamineremo diverse opzioni di deployment per jina-embeddings-v3, confrontando tre approcci chiave:

• Utilizzare Jina API
• Deployment tramite CSP come AWS SageMaker
• Self-hosting su un cluster Kubernetes con licenza commerciale

Il confronto valuterà le implicazioni di costo e i vantaggi di ogni approccio per aiutarti a determinare l'opzione più adatta alle tue esigenze.

tagMetriche di Performance Chiave

Abbiamo valutato cinque metriche di performance chiave in diversi scenari di utilizzo:

• Tasso di Successo delle Richieste: La percentuale di richieste riuscite al server di embedding
• Latenza delle Richieste: Il tempo impiegato dal server di embedding per elaborare e restituire una richiesta
• Throughput dei Token: Il numero di token che il server di embedding può elaborare al secondo
• Costo per Token: Il costo totale di elaborazione per unità di testo

Per gli embedding Jina auto-ospitati su cluster Kubernetes, abbiamo anche esaminato l'impatto del dynamic batching. Questa funzionalità mette in coda le richieste fino al raggiungimento della dimensione massima del batch (8.192 per jina-embeddings-v3) prima di generare gli embedding.

Abbiamo intenzionalmente escluso due fattori di performance significativi dalla nostra analisi:

• Auto-scaling: Sebbene questo sia cruciale per i deployment cloud con carichi di lavoro variabili, la sua efficacia dipende da numerose variabili—efficienza hardware, architettura di rete, latenza e scelte di implementazione. Queste complessità vanno oltre il nostro attuale ambito. Nota che Jina API include lo scaling automatico e i nostri risultati lo riflettono.
• Quantization: Mentre questa tecnica crea vettori di embedding più piccoli e riduce il trasferimento dati, i principali benefici derivano da altri componenti del sistema (archiviazione dati e calcoli della distanza vettoriale) piuttosto che dalla riduzione del trasferimento dati. Poiché ci stiamo concentrando sui costi di utilizzo diretto del modello, abbiamo lasciato fuori la quantization da questa analisi.

Infine, esamineremo le implicazioni finanziarie di ogni approccio, considerando sia i costi totali di proprietà che le spese per token/richiesta.

tagSetup del Deployment

Abbiamo valutato tre scenari di deployment e utilizzo con jina-embeddings-v3:

tagUtilizzo di Jina API

Tutti i modelli di embedding di Jina AI sono accessibili tramite Jina API. L'accesso funziona con un sistema di token prepagati, con un milione di token gratuiti disponibili per i test. Abbiamo valutato le prestazioni effettuando chiamate API via Internet dai nostri uffici in Germania.

tagUtilizzo di AWS SageMaker

Jina Embeddings v3 è disponibile per gli utenti AWS tramite SageMaker. L'utilizzo richiede un abbonamento AWS a questo modello. Per il codice di esempio, abbiamo fornito un notebook che mostra come sottoscrivere e utilizzare i modelli Jina AI con un account AWS.

Mentre i modelli sono disponibili anche su Microsoft Azure e Google Cloud Platform, abbiamo concentrato i nostri test su AWS. Ci aspettiamo prestazioni simili su altre piattaforme. Tutti i test sono stati eseguiti su un'istanza ml.g5.xlarge nella regione us-east-1.

tagSelf-Hosting su Kubernetes

Abbiamo sviluppato un'applicazione FastAPI in Python che carica jina-embeddings-v3 da HuggingFace utilizzando la libreria SentenceTransformer. L'app include due endpoint:

• /embed: Prende passaggi di testo come input e restituisce i loro embedding
• /health: Fornisce monitoraggio di base della salute

L'abbiamo implementato come servizio Kubernetes su Amazon Elastic Kubernetes Service, utilizzando un'istanza g5.xlarge in us-east-1.

Con e Senza Dynamic Batching

Abbiamo testato le prestazioni in un cluster Kubernetes in due configurazioni: Una dove elaborava immediatamente ogni richiesta quando la riceveva, e una dove utilizzava il dynamic batching. Nel caso del dynamic batching, il servizio attende fino a quando MAX_TOKENS (8192) sono raccolti in una coda, o viene raggiunto un timeout predefinito di 2 secondi, prima di invocare il modello e calcolare gli embedding. Questo approccio aumenta l'utilizzo della GPU e riduce la frammentazione della memoria GPU.

Per ogni scenario di deployment, abbiamo eseguito test variando tre parametri chiave:

• Dimensione del batch: Ogni richiesta conteneva 1, 32 o 128 passaggi di testo per l'embedding
• Lunghezza del passaggio: Abbiamo utilizzato passaggi di testo contenenti 128, 512 o 1.024 token
• Richieste concorrenti: Abbiamo inviato 1, 5 o 10 richieste simultaneamente

tagRisultati del Benchmark

La tabella seguente è un riepilogo dei risultati per ogni scenario di utilizzo, mediando su tutte le impostazioni delle tre variabili sopra.

tagTasso di Successo delle Richieste

I tassi di successo nei nostri test variano dal quasi perfetto 99,9% di SageMaker al modesto 56-58% delle soluzioni self-hosted, evidenziando perché l'affidabilità al 100% rimane sfuggente nei sistemi di produzione. Tre fattori chiave contribuiscono a questo:

• L'instabilità della rete causa inevitabili fallimenti anche in ambienti cloud
• La contesa delle risorse, specialmente della memoria GPU, porta a fallimenti delle richieste sotto carico
• I limiti di timeout necessari significano che alcune richieste devono fallire per mantenere la salute del sistema

tagTasso di Successo per Dimensione del Batch

Le dimensioni grandi dei batch causano frequentemente errori di memoria esaurita nella configurazione Kubernetes self-hosted. Senza dynamic batching, tutte le richieste contenenti 32 o 128 elementi per batch sono fallite per questo motivo. Anche con il dynamic batching implementato, il tasso di fallimento per i batch grandi è rimasto significativamente alto.

Sebbene questo problema potrebbe essere facilmente risolto tramite l'auto-scaling, abbiamo scelto di non esplorare questa opzione. L'auto-scaling porterebbe ad aumenti imprevedibili dei costi e sarebbe difficile fornire indicazioni utili dato il vasto numero di opzioni di configurazione disponibili.

tagTasso di Successo Per Livello di Concorrenza

La concorrenza — la capacità di gestire più richieste simultaneamente — non ha avuto un impatto né forte né costante sui tassi di successo delle richieste nelle configurazioni Kubernetes self-hosted, e solo un effetto minimo su AWS SageMaker, almeno fino a un livello di concorrenza di 10.

tagTasso di Successo Per Lunghezza dei Token

I passaggi lunghi con conteggi elevati di token influenzano sia la Jina Embedding API che Kubernetes con dynamic batching in modo simile ai batch grandi: all'aumentare delle dimensioni, il tasso di fallimento aumenta sostanzialmente. Tuttavia, mentre le soluzioni self-hosted senza dynamic batching falliscono quasi invariabilmente con batch grandi, performano meglio con singoli passaggi lunghi. Per quanto riguarda SageMaker, le lunghezze elevate dei passaggi - come la concorrenza e la dimensione del batch - non hanno avuto un impatto notevole sui tassi di successo delle richieste.

tagLatenza delle Richieste

Tutti i test di latenza sono stati ripetuti cinque volte a livelli di concorrenza di 1, 5 e 10. Il tempo di risposta è la media su cinque tentativi. Il throughput delle richieste è l'inverso del tempo di risposta in secondi, moltiplicato per la concorrenza.

tagJina API

I tempi di risposta nella Jina API sono principalmente influenzati dalla dimensione del batch, indipendentemente dal livello di concorrenza. Mentre la lunghezza del passaggio influisce anche sulle prestazioni, il suo impatto non è lineare. Come principio generale, le richieste contenenti più dati - sia attraverso dimensioni di batch maggiori che passaggi più lunghi - richiedono più tempo per essere elaborate.

Concorrenza 1:

Concurrency 5:

Concurrency 10:

Per le richieste individuali (batch size di 1):

• I tempi di risposta rimangono relativamente stabili, variando da circa 600-800ms, indipendentemente dalla lunghezza del passaggio
• Una maggiore concorrenza (5 o 10 richieste simultanee) non degrada significativamente le prestazioni per singola richiesta

Per batch più grandi (32 e 128 elementi):

• I tempi di risposta aumentano sostanzialmente, con batch size di 128 che richiede circa 4-6 volte più tempo rispetto alle singole richieste
• L'impatto della lunghezza del passaggio diventa più pronunciato con batch più grandi
• Con alta concorrenza (10) e batch grandi (128), la combinazione porta a tempi di risposta significativamente più lunghi, raggiungendo quasi 18 secondi per i passaggi più lunghi

Per il throughput:

• Batch più piccoli generalmente ottengono un throughput migliore quando eseguono richieste concorrenti
• Con concorrenza 10 e batch size 1, il sistema raggiunge il suo throughput massimo di circa 15 richieste/secondo
• Batch più grandi mostrano costantemente un throughput inferiore, scendendo a meno di 1 richiesta/secondo in diversi scenari

tagAWS SageMaker

I test AWS SageMaker sono stati eseguiti con un'istanza ml.g5.xlarge.

Concurrency 1:

Concurrency 5:

Concurrency 10:

Differenze principali rispetto all'API Jina:

• Prestazioni di base: SageMaker è significativamente più veloce per richieste piccole (singoli elementi, passaggi brevi) - circa 200ms contro 700-800ms per Jina.
• Comportamento in scala:
  • Entrambi i servizi rallentano con batch più grandi e passaggi più lunghi
  • SageMaker mostra un rallentamento più drastico con batch grandi (128) e passaggi lunghi (1024 token)
  • Con alta concorrenza (10) e carico massimo (batch 128, 1024 token), SageMaker impiega ~26s contro i ~18s di Jina
• Impatto della concorrenza:
  • Entrambi i servizi beneficiano dell'aumentata concorrenza per il throughput
  • Entrambi mantengono pattern di throughput simili attraverso i livelli di concorrenza
  • SageMaker raggiunge un throughput di picco leggermente superiore (17 req/s vs 15 req/s) con concorrenza 10

tagCluster Kubernetes Self-Hosted

I test self-hosting sono stati eseguiti su Amazon's Elastic Kubernetes Service con un'istanza g5.xlarge.

Concorrenza 1:

Concorrenza 5:

Concorrenza 10:

Quando vengono fornite richieste con più di 16.384 token, la nostra configurazione self-hosted fallisce con errori del server, tipicamente errori di memoria insufficiente. Questo è vero indipendentemente dai livelli di concorrenza. Di conseguenza, non vengono visualizzati test con più dati di quello.

L'alta concorrenza ha aumentato i tempi di risposta in modo ampiamente lineare: i livelli di concorrenza di 5 hanno impiegato circa cinque volte più tempo per rispondere rispetto a 1. Livelli di 10, dieci volte di più.

Il batching dinamico rallenta i tempi di risposta di circa due secondi per batch piccoli. Questo è previsto perché la coda di batching attende 2 secondi prima di elaborare un batch non pieno. Tuttavia, per dimensioni di batch maggiori, porta a moderati miglioramenti nel tempo di risposta.

tagThroughput dei Token

Il throughput dei token aumenta con dimensioni di batch maggiori, lunghezze dei passaggi più lunghe e livelli di concorrenza più elevati su tutte le piattaforme. Pertanto, presenteremo solo i risultati a livelli di utilizzo elevati, poiché i livelli inferiori non fornirebbero un'indicazione significativa delle prestazioni nel mondo reale.

Tutti i test sono stati condotti con un livello di concorrenza di 10, con 16.384 token per richiesta, mediati su cinque richieste. Abbiamo testato due configurazioni: dimensione batch 32 con passaggi da 512 token e dimensione batch 128 con passaggi da 128 token. Il numero totale di token rimane costante in entrambe le configurazioni.

Throughput dei token (token al secondo):

In condizioni di carico elevato, la Jina API supera significativamente le alternative, mentre le soluzioni self-hosted testate qui mostrano prestazioni sostanzialmente inferiori.

tagCosti Per Milione di Token

Il costo è probabilmente il fattore più critico nella scelta di una soluzione di embedding. Mentre il calcolo dei costi dei modelli AI può essere complesso, ecco un'analisi comparativa delle diverse opzioni:

tagJina API

Il servizio segue un modello di prezzo basato sui token con due livelli prepagati:

• $20 per 1 miliardo di token ($0.02 per milione) - Una tariffa entry-level ideale per prototipazione e sviluppo
• $200 per 11 miliardi di token ($0.018 per milione) - Una tariffa più economica per volumi maggiori

Vale la pena notare che questi token funzionano su tutta la suite di prodotti Jina, inclusi lettori, reranker e classificatori zero-shot.

tagAWS SageMaker

Il prezzo di SageMaker combina i costi orari dell'istanza con i costi di licenza del modello. Usando un'istanza ml.g5.xlarge:

• Costo dell'istanza: $1.408/ora (US East) o$1.761/ora (EU Frankfurt)
• Licenza jina-embeddings-v3: $2.50/ora
• Costo orario totale: $3.908-$4.261 a seconda della regione

Con una velocità media di 15.044 token/secondo (54.16M token/ora), il costo per milione di token varia da $0.0723 a$0.0788.

tagSelf-Hosting con Kubernetes

I costi di self-hosting variano significativamente in base alla scelta dell'infrastruttura. Usando come riferimento l'istanza g5.xlarge di AWS EC2:

• Costo dell'istanza: $1.006/ora (US East) o$1.258/ora (EU Frankfurt)
• Licenza jina-embeddings-v3: $5000/trimestre ($2.282/ora)
• Costo orario totale: $3.288-$3.540 a seconda della regione

A 2.588 token/secondo (9.32M token/ora), il costo per milione di token arriva a $0.352-$0.379. Mentre il costo orario è inferiore a SageMaker, la minor velocità comporta costi più alti per token.

Considerazioni importanti per il self-hosting:

• I costi fissi (licenze, infrastruttura) continuano indipendentemente dall'utilizzo
• L'hosting on-premises richiede comunque costi di licenza e di personale
• I carichi di lavoro variabili possono impattare significativamente l'efficienza dei costi

tagPunti Chiave

L'API Jina emerge come la soluzione più conveniente, anche senza considerare i tempi di cold-start e assumendo una velocità ottimale per le alternative.

Il self-hosting potrebbe avere senso per organizzazioni con un'infrastruttura robusta esistente dove i costi marginali dei server sono minimi. Inoltre, esplorare provider cloud diversi da AWS potrebbe portare a prezzi migliori.

Tuttavia, per la maggior parte delle aziende, specialmente le PMI che cercano soluzioni chiavi in mano, l'API Jina offre un'efficienza di costo impareggiabile.

tagConsiderazioni sulla Sicurezza e Privacy dei Dati

Nella scelta di una strategia di deployment per i modelli di embedding, i requisiti di sicurezza e privacy dei dati possono giocare un ruolo decisivo insieme alle considerazioni su prestazioni e costi. Offriamo opzioni di deployment flessibili per soddisfare diverse esigenze di sicurezza:

tagProvider di Servizi Cloud

Per le aziende che già lavorano con i principali provider cloud, le nostre offerte sul marketplace cloud (come AWS Marketplace, Azure, e GCP) forniscono una soluzione naturale per il deployment all'interno dei framework di sicurezza preesistenti. Questi deployment beneficiano di:

• Controlli di sicurezza e conformità ereditati dalla relazione con il CSP
• Integrazione immediata con le politiche di sicurezza esistenti e le regole di governance dei dati
• Richiede poche o nessuna modifica agli accordi esistenti sul trattamento dei dati
• Allineamento con le considerazioni preesistenti sulla sovranità dei dati

tagSelf-Hosting e Deployment Locale

Le organizzazioni con requisiti di sicurezza stringenti o obblighi normativi specifici spesso preferiscono il controllo fisico completo della loro infrastruttura. La nostra opzione self-hosted permette:

• Controllo completo sull'ambiente di deployment
• Elaborazione dei dati interamente all'interno del proprio perimetro di sicurezza
• Integrazione con il monitoraggio di sicurezza e i controlli esistenti

Per ottenere licenze commerciali per i nostri modelli CC-BY-NC, è necessario prima ottenere una licenza da noi. Non esitare a contattare il nostro team commerciale.

tagServizio API Jina

Per startup e PMI che cercano di bilanciare sicurezza e praticità rispetto ai costi, il nostro servizio API fornisce sicurezza di livello enterprise senza aggiungere overhead operativo:

• Certificazione SOC2 che garantisce robusti controlli di sicurezza
• Piena conformità GDPR per il trattamento dei dati
• Politica di zero data retention - non memorizziamo né registriamo le tue richieste
• Trasmissione dati crittografata e infrastruttura sicura

Le offerte di modelli di Jina AI permettono alle organizzazioni di scegliere la strategia di deployment che meglio si allinea con i loro requisiti di sicurezza mantenendo l'efficienza operativa.

tagScegliere la Tua Soluzione

Il diagramma di flusso sottostante riassume i risultati di tutti i test empirici e le tabelle che hai visto:

Prima, considera le tue esigenze di sicurezza e quanta flessibilità puoi sacrificare per soddisfarle.

Poi, considera come pianifichi di utilizzare l'AI nella tua azienda:

1. Indicizzazione offline e casi d'uso non time-sensitive che possono utilizzare in modo ottimale l'elaborazione batch.
2. Usi sensibili all'affidabilità e alla scalabilità come la generazione aumentata da retrieval e l'integrazione LLM.
3. Utilizzi time-sensitive come la ricerca e il retrieval online.

Inoltre, considera la tua esperienza interna e l'infrastruttura esistente:

1. Il tuo stack tecnologico è già fortemente dipendente dal cloud?
2. Hai una grande operazione IT interna in grado di gestire il self-hosting?

Infine, considera i volumi di dati previsti. Sei un utente su larga scala che prevede di eseguire milioni di operazioni utilizzando modelli AI ogni giorno?

tagConclusione

L'integrazione dell'AI nelle decisioni operative rimane territorio inesplorato per molti dipartimenti IT, poiché il mercato manca di soluzioni chiavi in mano consolidate. Questa incertezza può rendere difficile la pianificazione strategica. La nostra analisi quantitativa mira a fornire una guida concreta sull'incorporazione dei nostri modelli di ricerca nei tuoi specifici flussi di lavoro e applicazioni.

Quando si tratta di costo per unità, l'API Jina si distingue come una delle opzioni più economiche disponibili per le aziende. Poche alternative possono eguagliare il nostro prezzo offrendo funzionalità comparabili.

Siamo impegnati a fornire capacità di ricerca che non sono solo potenti e user-friendly, ma anche convenienti per organizzazioni di tutte le dimensioni. Che sia attraverso i principali provider cloud o deployment self-hosted, le nostre soluzioni soddisfano anche i requisiti aziendali più complessi che vanno oltre le pure considerazioni di costo. Questa analisi scompone i vari fattori di costo per aiutare il tuo processo decisionale.

Dato che ogni organizzazione ha i propri requisiti unici, riconosciamo che un singolo articolo non può affrontare ogni scenario. Se hai esigenze specifiche non coperte qui, contattaci per discutere come possiamo supportare al meglio la tua implementazione.