Analisi approfondita del recupero integrato di OpenAI: svelare i vincoli di archiviazione, le lacune nelle prestazioni e le preoccupazioni sui costi
Dopo gli ultimi annunci di OpenAI, ho iniziato a chiedermi se gli OpenAI Assistants siano adatti ad applicazioni di livello produttivo, con le loro limitazioni, in particolare il limite di 20 file e il prezzo di 0,2 $ per GB al giorno. Con questo in mente, ho scritto un articolo incentrato su tre argomenti.
0,2 $/GB/giorno per la knowledge base degli OpenAI Assistants è costoso?
Approfondimento sulle soluzioni interne di OpenAI in base alle informazioni rilasciate.
In quale direzione dovrebbe evolvere l'infrastruttura della knowledge base degli AI Assistants?
Nota: Il contenuto seguente contiene alcuni calcoli. Sei invitato a esaminare questi calcoli dettagliati, oppure puoi scegliere di concentrarti sulle conclusioni evidenziate per una rapida panoramica.
Il costo della Knowledge Base degli OpenAI Assistants
Facciamo qualche semplice calcolo:
Office 365 addebita 6 $ per TB di dati al mese. Google Workspace addebita 8 $ per TB di dati al mese.
Per gli OpenAI Assistants, il costo è 0,2 ($) x 30 (giorni) x 1024 (GB) = 6.144 $ per TB al mese.
Pertanto, aggiungere un assistente AI ai miei documenti d'ufficio usando gli OpenAI Assistants costerebbe tre ordini di grandezza in più rispetto a un servizio documentale tradizionale (6 $ vs. 6.144 $). È costoso? Direi: "Sì!" sembra eccessivamente alto.
| Servizi | Prezzi |
|---|---|
| Servizi documentali tradizionali | $6 /TB |
| OpenAI Assistants | $6,144/TB |
Calcoliamo anche brevemente il costo operativo dal lato di OpenAI. La seguente analisi è un po' complessa, ma la conclusione è semplice: servire 1 GB di documenti richiede la generazione di 1,5 GB di vettori, e il costo del server per servire questi vettori è di circa 0,30 /GB. Interessante!
| Prezzi | |
|---|---|
| Costo di OpenAI | $0.3/GB al giorno |
| Prezzi di OpenAI | $0.2/GB al giorno |
Ecco la stima:
Considera 1 GB di testo usando il modello text-embedding-ada-002 di OpenAI per generare i vettori per il retrieval. Per ogni 1 KB di testo, questo modello creerà un embedding a 1536 dimensioni. Ogni dimensione del vettore corrisponde a un float32 (quindi 6 KB per vettore), con il risultato che il rapporto tra la dimensione del testo in input e i vettori in output è 1:6, cioè 1 GB di testo corrisponde a 6 GB di vettori. Comprimere i vettori tramite quantizzazione può raggiungere un rapporto di compressione di 4:1, il che significa che 1 GB di testo corrisponde a 1,5 GB di vettori.
Consideriamo il costo del server per servire 1,5 GB di vettori. Optare per un'istanza AWS EC2 economica costa circa $0.30 al giorno per ogni 1,5 GB di memoria. Questo scenario è più che equo, poiché presuppone solo l'archiviazione e la ricerca dei vettori. Non include altri elementi come metadati, monitoraggio, log, file di indice e il costo dell'alta disponibilità con repliche multiple, tutti necessari negli ambienti di produzione.
Conclusione dell'analisi dei costi
La nuova funzionalità Assistants di OpenAI sta costando all'azienda più denaro di quanto ne faccia guadagnare, a causa dell'elevato costo del server di 0,3 $/GB/giorno, rispetto al prezzo di 0,2 $/GB/giorno. Tuttavia, gli sviluppatori che vogliono usare gli Assistants devono pagare oltre 1.000 volte di più rispetto ai servizi documentali tradizionali. Pertanto, devono generare un valore di business superiore di tre ordini di grandezza rispetto ai servizi documentali convenzionali per giustificare il costo.
Questo modello di prezzo può essere giustificabile per le aziende B2C, poiché pochi GB di dati che costano decine di dollari al mese difficilmente rappresentano un problema significativo per i singoli utenti. Tuttavia, per le aziende B2B che gestiscono dati su larga scala, questo costo potrebbe erodere significativamente i ricavi aziendali o persino superare il valore dell'azienda. Ad esempio, creare un servizio clienti personalizzato o un sistema di ricerca intelligente per brevetti e documenti legali potrebbe diventare proibitivamente costoso.
Approfondire la soluzione di OpenAI
Analizziamo l'attuale schema di OpenAI Assistants. Ecco alcune informazioni disponibili pubblicamente:
Un massimo di 20 file per assistant
Un limite di 512MB per file
Una limitazione nascosta di 2 milioni di token per file, scoperta durante i nostri test
È supportato solo il testo.
Il traffico del server ha registrato un aumento significativo dopo OpenAI DevDay. Il numero di utenti di prova e dei relativi assistant creati non è stato divulgato, ma dovrebbe essere stato significativo.
Analisi del servizio di retrieval di OpenAI
Facciamo qualche calcolo sulla base delle informazioni pubbliche sopra riportate.
- Gli utenti sono limitati a 20 file, ciascuno con un limite di 2 milioni di token. Supponendo 200 token per chunk (corrispondenti a un vettore), c'è un limite di 200.000 vettori per utente.
| Limite di file per utente | Numero di token | Numero di vettori |
|---|---|---|
| / | 200 | 1 |
| 1 file | 2.000.000 (limite massimo) | 10.000 |
| 20 file | 40.000.000 (limite massimo) | 200.000 |
- Poiché la maggior parte degli utenti non raggiungerà il limite di 2 milioni di token per file, possiamo stimare che il file di ciascun utente conterrà in media 400.000 token, che si traducono in 2.000 vettori. Considerando il limite massimo di 200.000 vettori per utente e la media di 2.000 vettori per utente, raggiungere un rapporto di overselling di 1000:1 è fattibile.
| Limite di file per utente | Numero di token | Numero di vettori |
|---|---|---|
| / | 200 | 1 |
| 20 file | 400.000 (in media) | 2.000 |
Inoltre, OpenAI dispone di una base utenti considerevole, il che richiede all'azienda di mantenere un sistema stabile e di gestire efficacemente l'impatto di eventuali disastri. Pertanto, durante le fasi iniziali dello sviluppo di OpenAI Assistants, è improbabile che scelgano una soluzione con cluster super-grande. Invece, OpenAI probabilmente creerebbe un sistema (mostrato di seguito) in cui ogni gruppo di utenti può condividere un'istanza minore di vector database per una maggiore stabilità.
Un'architettura semplificata della funzionalità di retrieval di OpenAI Assistants
Supponiamo che ogni nodo fisico abbia 32 GB di memoria e sia diviso in quattro Pod. Ogni Pod ospita un'istanza separata di vector database, dove a un Pod vengono assegnati 8 GB di memoria. 3 GB sono dedicati al sistema di vector database e 5 GB sono riservati al servizio dei dati vettoriali degli utenti.
Con un limite di 200.000 vettori per utente, i vettori quantizzati e i loro indici richiedono circa 500 MB di memoria. Pertanto, ogni Pod può ospitare dieci utenti senza overselling. Tuttavia, con un rapporto di overselling di 1000:1, un singolo Pod può servire fino a 10.000 utenti (con almeno centinaia di utenti attivi). Di conseguenza, un singolo server composto da quattro Pod può ospitare 40.000 utenti.
Questa architettura sembra adeguata per supportare gli utenti di prova. Tuttavia, ogni nodo fisico ha il potenziale per archiviare fino a 20 GB di vettori e indici per clienti paganti, corrispondenti a circa 8 GB di testo originale. A piena capacità, il potenziale di ricavi giornalieri è un modesto $1,6, un valore notevolmente basso.
Nota: In casi estremi in cui più utenti con file di grandi dimensioni condividono un singolo Pod, possiamo mitigare le potenziali sfide tramite la pianificazione. Ad esempio, il deployment di un nuovo Pod può migrare in modo efficiente il carico da questi utenti più grandi.
Riepilogo rapido
L'architettura del servizio di retrieval di OpenAI può funzionare bene per gli utenti in prova, ma potrebbe non scalare abbastanza bene da supportare aziende più grandi con requisiti di dati più estesi.
L'architettura attuale impone limiti di archiviazione sui dati degli utenti, riducendo i profitti potenziali e aumentando i costi.
Inoltre, l'architettura è inadeguata per la multitenancy a livello applicativo, poiché alcuni clienti potrebbero richiedere un assistant separato per ciascun client. Vedi ulteriori discussioni nel forum di OpenAI.
Perché la knowledge base di OpenAI Assistants non è abbastanza buona
Abbiamo discusso in precedenza le limitazioni di OpenAI Assistants e della sua architettura. Quindi, come possiamo affrontare questa sfida e ridurre i costi? La soluzione più efficace sarebbe ottimizzare l'architettura del servizio.
Prima di addentrarci nella soluzione, considera i fattori cruciali che aprono la strada a un'architettura di sistema ottimizzata.
Una soluzione di database vettoriale raffinata: archiviazione vettoriale ibrida disco/memoria
I database vettoriali di solito caricano vettori e indici in memoria per accelerare le risposte alle query. Tuttavia, le applicazioni Assistant sono un tipico caso d'uso di Retrieval Augmented Generation (RAG) , quindi il collo di bottiglia delle prestazioni risiede nell'inferenza dei modelli linguistici di grandi dimensioni (LLM) piuttosto che nel processo di interrogazione del database vettoriale. In questi casi, non sono necessarie risposte di ricerca vettoriale ultra-rapide. Degradando intenzionalmente le prestazioni del database vettoriale per allinearle agli LLM, possiamo ottenere un equilibrio tra convenienza economica e capacità di archiviazione estese. Una strada promettente è esplorare una soluzione di database vettoriale basata su disco, in cui solo i dati hot vengono caricati in memoria. Questo approccio non solo riduce sostanzialmente i costi hardware, ma aumenta anche la capacità di archiviazione complessiva del sistema.
Semplificare il disaster recovery: mettere in pool i dati di sistema
Attualmente, OpenAI Assistant adotta un approccio piuttosto brute-force per il disaster recovery, assegnando a ciascun Pod un'istanza di database vettoriale separata e allocando oltre 1/3 della memoria in ciascun Pod per l'uso del sistema. Tuttavia, considerando che solo i dati utente richiedono separazione, una strategia più sfumata prevede di mettere insieme in pool i componenti di sistema. Questo approccio migliora l'alta disponibilità, consentendo a questi componenti di funzionare in modo indipendente, svincolati dai singoli Pod.
Supporto multi-tenancy per una base utenti diversificata
Il framework architetturale dovrebbe soddisfare senza problemi sia numerosi piccoli utenti sia grandi aziende con dati su larga scala. Il supporto multi-tenancy a livello applicativo è un requisito fondamentale per le applicazioni Agent, in particolare quelle con basi utenti consistenti.
Seguendo questa linea di pensiero, abbozziamo un diagramma dell'architettura.
L'architettura ottimizzata della funzionalità di retrieval di OpenAI Assistants
Mettiamo in evidenza alcune modifiche chiave:
Separazione dei componenti di sistema e di query. In precedenza co-localizzati all'interno di ciascun Pod, i componenti di sistema sono ora messi in pool in modo indipendente, riducendo la loro impronta di risorse da 1/3 a meno di 1/10 rispetto allo schema precedente.
Maggiore flessibilità per i componenti di query: I componenti di query possono ora essere allocati dinamicamente in base a diversi numeri di Pod, beneficiando dell’isolamento fisico per una scalabilità indipendente. Il controllo sul raggio d’impatto è gestito finemente alla granularità dei componenti di query. La loro struttura semplificata migliora l’affidabilità rispetto a componenti di sistema più complessi.
Architettura ibrida memoria/disco: L’introduzione di un’architettura ibrida memoria/disco, in cui la memoria carica esclusivamente i dati hot, è un’altra modifica cruciale. Questo miglioramento consente alla stessa quantità di memoria di servire da 5 a 10 volte il testo originale rispetto alla soluzione precedente.
Supporto multi-partizione per il multi-tenancy: L’aggiunta del supporto multi-partizione soddisfa il multi-tenancy a livello applicativo. A ciascun utente di livello superiore può ora essere assegnata una partizione dati indipendente, fornendo una soluzione a basso costo a livello applicativo. L’isolamento fisico si ottiene assegnando un componente di query per ogni gruppo di utenti.
Ricalcolando il supporto dati con questa architettura, un nodo di query con 32 GB di memoria, aumentato dallo spazio su disco, può ora supportare efficientemente 320 GB di vettori e indici, equivalenti a 128 GB del testo originale dell’utente. Le risorse dei componenti di sistema condivise allocate a questi nodi di query ammontano a 3 GB, fisicamente distinte dai nodi di query. In totale, 35 GB di memoria possono ospitare 128 GB di dati utente, traducendosi in circa 3,6 GB di dati utente per GB di memoria. Al contrario, il design precedente consentiva a 32 GB di memoria di supportare 8 GB di dati utente, con una media di 250 MB di dati utente per GB di memoria. Ciò riflette un notevole aumento di efficienza di 15 volte.
Una panoramica dei database vettoriali più diffusi: Milvus, Chroma e Qdrant
I database vettoriali svolgono un ruolo fondamentale nell’ottimizzazione dell’architettura di OpenAI Assistants, rendendo fondamentale la scelta dell’opzione più robusta. Qui approfondiamo tre importanti database vettoriali open-source—Milvus, Chroma, e Qdrant—valutandone punti di forza e limiti nel migliorare l’architettura di OpenAI Assistants.
Milvus
Pro: Milvus è il database vettoriale open-source più maturo, ampiamente adottato nei sistemi distribuiti su larga scala. Tra le funzionalità degne di nota figurano l’efficace separazione dei componenti di sistema e di query, l’isolamento dei componenti di query tramite la funzionalità Resource Group, un’architettura ibrida memoria/disco e il multi-tenancy a livello applicativo facilitato dalle funzionalità RBAC e Partition.
Contro: Nonostante i suoi punti di forza, Milvus non riesce a ottenere un isolamento completo delle anomalie tramite l’isolamento dei componenti di query basato su Resource Group. Inoltre, introduce alcune dipendenze di terze parti, come Etcd e MinIO, con conseguenti costi di distribuzione e operativi più elevati.
Chroma
Pro: Chroma emerge come un progetto nuovo e intuitivo, apprezzato per la sua semplicità. Si presta bene alla prototipazione rapida e all’iterazione veloce di applicazioni di IA, guadagnando popolarità tra gli sviluppatori individuali.
Contro: Chroma eccelle negli scenari su scala ridotta, ma non è progettato per applicazioni aziendali su larga scala. Manca di funzionalità chiave come distribuzione distribuita, separazione dei componenti, architettura ibrida memoria/disco e multi-tenancy a livello applicativo.
Qdrant
Pro: Qdrant, come nuovo arrivato, offre supporto per distribuzioni distribuite su piccola scala con un processo di configurazione semplificato. Vanta inoltre un’architettura ibrida memoria/disco, allineandosi ai requisiti dei database moderni.
Contro: Attualmente, Qdrant non supporta funzionalità cruciali come la separazione dei componenti o il multi-tenancy a livello applicativo, limitandone l’applicabilità in alcuni casi d’uso.
Nella valutazione di questi database vettoriali, diventa evidente che ogni soluzione porta con sé punti di forza e compromessi unici, rendendo la scelta dipendente da requisiti e priorità specifici nel contesto dell’ottimizzazione dell’architettura di OpenAI Assistants.
Riepilogo
In questo post del blog, abbiamo approfondito le complessità di OpenAI Assistants, esplorandone i prezzi, l’architettura e le potenziali ottimizzazioni per l’efficienza dei costi e capacità di archiviazione migliorate. È emersa una rivelazione chiave: il costo dell’infrastruttura dei database vettoriali influenza in modo significativo la distribuzione di basi di conoscenza e applicazioni Agent.
Analizzando i costi e i profitti di OpenAI relativi ad Assistants, abbiamo rilevato uno squilibrio notevole, con spese superiori ai potenziali ricavi. Sebbene ciò possa essere giustificabile durante la fase di prova, per accogliere nuovi clienti e favorire l’espansione della community, è essenziale un equilibrio più sostenibile.
Il post del blog propone una soluzione per ottimizzare l’architettura, presentando la prospettiva di ottenere una riduzione dei costi di dieci volte per questi tipi di applicazioni rispetto alle soluzioni esistenti. Viene sottolineato il ruolo fondamentale dei database vettoriali in questo processo di ottimizzazione, con Milvus che emerge come un’opzione particolarmente adatta tra le alternative disponibili.
Tuttavia, riconoscendo i limiti intrinseci dei database vettoriali esistenti, questo post sottolinea che nessuna singola soluzione di database vettoriale può affrontare in modo completo tutte le sfide e soddisfare ogni requisito di progettazione per lo sviluppo imminente dell’infrastruttura. La scelta dei database vettoriali dovrebbe essere adattata a requisiti specifici per orientarsi efficacemente tra le complessità dell’ottimizzazione dell’architettura di OpenAI Assistants.
Continua a leggere
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.