Analyse der integrierten Retrieval-Funktion von OpenAI: Aufdeckung von Speicherbeschränkungen, Leistungslücken und Kostenbedenken
Nach den jüngsten Ankündigungen von OpenAI begann ich zu hinterfragen, ob OpenAI Assistants mit ihren Einschränkungen, insbesondere dem Limit von 20 Dateien und dem Preis von $0.2 pro GB und Tag, für Anwendungen auf Produktionsniveau geeignet sind. Vor diesem Hintergrund habe ich einen Artikel geschrieben, der sich auf drei Themen konzentriert.
Sind $0.2/GB/Tag für die Wissensdatenbank der OpenAI Assistants teuer?
Ein tieferer Blick in OpenAIs interne Lösungen auf Basis der veröffentlichten Informationen.
In welche Richtung sollte sich die Infrastruktur der Wissensdatenbank von AI Assistants entwickeln?
Hinweis: Der folgende Inhalt enthält einige Berechnungen. Sie können diese detaillierten Berechnungen gerne durchgehen, oder Sie können sich für einen schnellen Überblick auf die hervorgehobenen Schlussfolgerungen konzentrieren.
Die Kosten der Wissensdatenbank von OpenAI Assistants
Machen wir ein paar einfache Rechnungen:
Office 365 berechnet $6 pro TB Daten pro Monat. Google Workspace berechnet $8 pro TB Daten pro Monat.
Bei OpenAI Assistants betragen die Kosten 0.2 ($) x 30 (Tage) x 1024 (GB) = $6,144 pro TB pro Monat.
Daher würde das Hinzufügen eines KI-Assistenten zu meinen Office-Dokumenten mit OpenAI Assistants drei Größenordnungen mehr kosten als ein herkömmlicher Dokumentendienst ($6 vs. $6,144). Ist das teuer? Ich sage: „Ja!“ Das erscheint übermäßig hoch.
| Dienste | Preisgestaltung |
|---|---|
| Traditionelle Dokumentendienste | $6 /TB |
| OpenAI Assistants | $6,144/TB |
Lassen Sie uns auch kurz die Betriebskosten auf Seiten von OpenAI berechnen. Die folgende Analyse ist etwas komplex, aber die Schlussfolgerung ist einfach: Für die Bereitstellung von 1 GB Dokumenten müssen 1.5 GB Vektoren erzeugt werden, und die Serverkosten für die Bereitstellung dieser Vektoren betragen etwa $0.30 pro Tag. Teuer? Im Vergleich zum Preisschild von $0.20/GB ist das ein Schnäppchen. Interessant!
| Preisgestaltung | |
|---|---|
| OpenAIs Kosten | $0.3/GB pro Tag |
| OpenAIs Preisgestaltung | $0.2/GB pro Tag |
Hier ist die Schätzung:
Betrachten wir 1 GB Text, der OpenAIs text-embedding-ada-002-Modell verwendet, um die Vektoren für den Abruf zu erzeugen. Für jedes 1 KB Text erstellt dieses Modell ein 1536-dimensionales Embedding. Jede Vektordimension entspricht einem float32 (also 6KB pro Vektor), wodurch das Größenverhältnis von Eingabetext zu Ausgabevektoren 1:6 beträgt, d. h. 1 GB Text entspricht 6 GB Vektoren. Durch Komprimierung der Vektoren mittels Quantisierung lässt sich ein Kompressionsverhältnis von 4:1 erreichen, was bedeutet, dass 1 GB Text 1.5 GB Vektoren entspricht.
Betrachten wir die Serverkosten für die Bereitstellung von 1.5 GB Vektoren. Die Wahl einer günstigen AWS EC2-Instanz kostet ungefähr $0.30 täglich für jeweils 1.5 GB Arbeitsspeicher. Dieses Szenario ist mehr als fair, da es nur die Vektorspeicherung und -suche annimmt. Es umfasst keine anderen Elemente wie Metadaten, Monitoring, Logs, Indexdateien und die Kosten für hohe Verfügbarkeit mit mehreren Replikaten, die alle in Produktionsumgebungen benötigt werden.
Schlussfolgerung der Kostenanalyse
OpenAIs neue Assistants-Funktion kostet das Unternehmen aufgrund der hohen Serverkosten von $0.3/GB/Tag mehr Geld, als sie einbringt, verglichen mit der Preisgestaltung von $0.2/GB/Tag. Entwickler, die die Assistants nutzen möchten, müssen jedoch über 1,000-mal mehr bezahlen als für herkömmliche Dokumentendienste. Daher müssen sie einen Geschäftswert schaffen, der drei Größenordnungen höher ist als bei konventionellen Dokumentendiensten, um die Kosten zu rechtfertigen.
Dieses Preismodell mag für B2C-Unternehmen gerechtfertigt sein, da einige GB Daten, die monatlich mehrere zehn Dollar kosten, für einzelne Nutzer wahrscheinlich kein erhebliches Problem darstellen. Für B2B-Unternehmen, die mit Daten in großem Umfang arbeiten, könnten diese Kosten jedoch die Geschäftserlöse erheblich schmälern oder sogar den Wert des Geschäfts übersteigen. Beispielsweise könnte die Erstellung eines personalisierten Kundenservice oder eines intelligenten Suchsystems für Patente und juristische Dokumente unerschwinglich teuer werden.
Ein Blick auf OpenAIs Lösung
Nehmen wir das aktuelle Schema von OpenAI Assistants genauer auseinander. Hier sind einige öffentlich verfügbare Informationen:
Maximal 20 Dateien pro Assistent
Eine Obergrenze von 512MB pro Datei
Eine versteckte Begrenzung von 2 Millionen Tokens pro Datei, die wir während unserer Tests aufgedeckt haben
Es wird nur Text unterstützt.
Der Serververkehr hat nach dem OpenAI DevDay erheblich zugenommen. Die Anzahl der Testnutzer und der entsprechend erstellten Assistenten wurde nicht offengelegt, dürfte aber beträchtlich gewesen sein.
Analyse des Retrieval-Dienstes von OpenAI
Rechnen wir auf Grundlage der oben genannten öffentlichen Informationen ein wenig nach.
- Nutzer sind auf 20 Dateien beschränkt, wobei jede Datei auf 2 Millionen Tokens begrenzt ist. Bei 200 Tokens pro Chunk (entsprechend einem Vektor) ergibt sich eine Begrenzung von 200.000 Vektoren pro Nutzer.
| Dateilimit pro Nutzer | Anzahl der Tokens | Anzahl der Vektoren |
|---|---|---|
| / | 200 | 1 |
| 1 Datei | 2.000.000 (Obergrenze) | 10.000 |
| 20 Dateien | 40.000.000 (Obergrenze) | 200.000 |
- Da die meisten Nutzer die Grenze von 2 Millionen Tokens pro Datei nicht erreichen werden, können wir schätzen, dass jede Datei eines Nutzers im Durchschnitt 400.000 Tokens enthalten wird, was 2.000 Vektoren entspricht. Angesichts der Obergrenze von 200.000 Vektoren pro Nutzer und des Durchschnitts von 2.000 Vektoren pro Nutzer ist das Erreichen eines Overselling-Verhältnisses von 1000:1 machbar.
| Dateilimit pro Nutzer | Anzahl der Tokens | Anzahl der Vektoren |
|---|---|---|
| / | 200 | 1 |
| 20 Dateien | 400.000 (im Durchschnitt) | 2.000 |
Darüber hinaus verfügt OpenAI über eine beträchtliche Nutzerbasis, weshalb das Unternehmen ein stabiles System aufrechterhalten und die Auswirkungen etwaiger Katastrophen effektiv managen muss. Daher ist es in den Anfangsphasen der Entwicklung von OpenAI Assistants unwahrscheinlich, dass sie sich für eine supergroße Cluster-Lösung entscheiden. Stattdessen würde OpenAI wahrscheinlich ein System (unten dargestellt) erstellen, bei dem jede Nutzergruppe sich eine kleinere Vektordatenbank-Instanz teilen kann, um eine bessere Stabilität zu gewährleisten.
Eine vereinfachte Architektur der Retrieval-Funktion von OpenAI Assistants
Nehmen wir an, jeder physische Knoten verfügt über 32 GB Arbeitsspeicher und ist in vier Pods unterteilt. Jeder Pod hostet eine separate Vektordatenbank-Instanz, wobei einem Pod 8 GB Arbeitsspeicher zugewiesen werden. 3 GB sind für das Vektordatenbanksystem vorgesehen, und 5 GB sind für die Bereitstellung von Nutzervektordaten reserviert.
Bei einer Obergrenze von 200.000 Vektoren pro Nutzer benötigen quantisierte Vektoren und ihre Indizes etwa 500 MB Arbeitsspeicher. Daher kann jeder Pod ohne Overselling zehn Nutzer aufnehmen. Bei einem Overselling-Verhältnis von 1000:1 kann ein einzelner Pod jedoch bis zu 10.000 Nutzer bedienen (mit mindestens Hunderten aktiver Nutzer). Infolgedessen kann ein einzelner Server mit vier Pods 40.000 Nutzer aufnehmen.
Diese Architektur scheint für die Unterstützung von Testnutzern ausreichend zu sein. Jeder physische Knoten hat jedoch das Potenzial, bis zu 20 GB an Vektoren und Indizes für zahlende Kunden zu speichern, was ungefähr 8 GB Originaltext entspricht. Bei voller Kapazität liegt das tägliche Umsatzpotenzial bei bescheidenen $1.6, was bemerkenswert niedrig ist.
Hinweis: In Extremfällen, in denen mehrere Benutzer mit großen Dateien einen einzelnen Pod gemeinsam nutzen, können wir die potenziellen Herausforderungen durch Scheduling abmildern. Beispielsweise kann das Bereitstellen eines neuen Pods die Last dieser größeren Benutzer effizient migrieren.
Kurze Zusammenfassung
Die Architektur des Retrieval-Dienstes von OpenAI kann für Testbenutzer gut funktionieren, ist jedoch möglicherweise nicht ausreichend skalierbar, um größere Unternehmen mit umfangreicheren Datenanforderungen zu unterstützen.
Die aktuelle Architektur legt Speichergrenzen für Benutzerdaten fest, wodurch potenzielle Gewinne reduziert und Kosten erhöht werden.
Darüber hinaus ist die Architektur für Multitenancy auf Anwendungsebene unzureichend, da einige Kunden möglicherweise für jeden Client einen separaten Assistenten benötigen. Weitere Diskussionen finden Sie im OpenAI-Forum.
Warum die Wissensdatenbank von OpenAI Assistants nicht gut genug ist
Wir haben zuvor die Einschränkungen von OpenAI Assistants und seiner Architektur besprochen. Wie können wir also diese Herausforderung angehen und Kosten senken? Die effektivste Lösung wäre, die Architektur des Dienstes zu optimieren.
Bevor wir uns mit der Lösung befassen, sollten wir entscheidende Faktoren betrachten, die den Weg für eine optimierte Systemarchitektur ebnen.
Eine verfeinerte Vektordatenbank-Lösung: Hybrider Festplatten-/Arbeitsspeicher-Vektorspeicher
Vektordatenbanken laden Vektoren und Indizes in der Regel in den Arbeitsspeicher, um Abfrageantworten zu beschleunigen. Assistant-Anwendungen sind jedoch ein typischer Anwendungsfall von Retrieval Augmented Generation (RAG) , sodass der Leistungsengpass in der Inferenz großer Sprachmodelle (LLMs) und nicht im Abfrageprozess der Vektordatenbank liegt. In solchen Fällen sind ultraschnelle Vektorsuchantworten nicht erforderlich. Indem wir die Leistung der Vektordatenbank bewusst verringern, um sie an LLMs anzupassen, können wir ein Gleichgewicht zwischen Kosteneffizienz und erweiterten Speicherkapazitäten erreichen. Ein vielversprechender Ansatz ist die Untersuchung einer festplattenbasierten Vektordatenbank-Lösung, bei der nur heiße Daten in den Arbeitsspeicher geladen werden. Dieser Ansatz reduziert nicht nur die Hardwarekosten erheblich, sondern erhöht auch die gesamte Speicherkapazität des Systems.
Optimierung der Notfallwiederherstellung: Bündelung von Systemdaten
Derzeit verwendet OpenAI Assistant einen etwas brachialen Ansatz für die Notfallwiederherstellung, indem jedem Pod eine separate Vektordatenbank-Instanz zugewiesen und über 1/3 des Arbeitsspeichers in jedem Pod für die Systemnutzung reserviert wird. Da jedoch nur Benutzerdaten eine Trennung erfordern, besteht eine differenziertere Strategie darin, Systemkomponenten zusammenzufassen. Dieser Ansatz verbessert die Hochverfügbarkeit und ermöglicht es diesen Komponenten, unabhängig zu funktionieren, losgelöst von einzelnen Pods.
Multi-Tenancy-Unterstützung für eine vielfältige Benutzerbasis
Das Architektur-Framework sollte sowohl zahlreiche kleine Benutzer als auch große Unternehmen mit großskaligen Daten nahtlos bedienen. Multi-Tenancy-Unterstützung auf Anwendungsebene ist eine grundlegende Anforderung für Agent-Anwendungen, insbesondere für solche mit umfangreichen Benutzerbasen.
Dieser Überlegung folgend, skizzieren wir ein Architekturdiagramm.
Die optimierte Architektur der Retrieval-Funktion von OpenAI Assistants
Richten wir den Fokus auf einige wichtige Änderungen:
Trennung von System- und Abfragekomponenten. Systemkomponenten, die zuvor innerhalb jedes Pods gemeinsam untergebracht waren, werden nun unabhängig gebündelt, wodurch ihr Ressourcenbedarf im Vergleich zum vorherigen Schema von 1/3 auf weniger als 1/10 reduziert wird.
Verbesserte Flexibilität für Query-Komponenten: Query-Komponenten können nun dynamisch basierend auf unterschiedlichen Pod-Zahlen zugewiesen werden und profitieren von physischer Isolation für unabhängige Skalierbarkeit. Die Kontrolle über den Blast Radius wird fein auf der Granularität von Query-Komponenten gesteuert. Ihre vereinfachte Struktur erhöht die Zuverlässigkeit im Vergleich zu komplexeren Systemkomponenten.
Hybride Speicher-/Festplattenarchitektur: Die Einführung einer hybriden Speicher-/Festplattenarchitektur, bei der der Speicher ausschließlich Hot Data lädt, ist eine weitere entscheidende Änderung. Diese Verbesserung ermöglicht es, mit derselben Speichermenge das 5- bis 10-Fache des ursprünglichen Textes im Vergleich zur vorherigen Lösung zu verarbeiten.
Multi-Partition-Unterstützung für Multi-Tenancy: Das Hinzufügen von Multi-Partition-Unterstützung bedient Multi-Tenancy auf Anwendungsebene. Jedem Benutzer auf höherer Ebene kann nun eine unabhängige Datenpartition zugewiesen werden, was eine kostengünstige Lösung auf Anwendungsebene bietet. Physische Isolation wird erreicht, indem pro Benutzergruppe eine Query-Komponente zugewiesen wird.
Bei einer Neuberechnung der Datenunterstützung mit dieser Architektur kann ein Query Node mit 32 GB Speicher, ergänzt durch Festplattenspeicher, nun effizient 320 GB an Vektoren und Indizes unterstützen, was 128 GB des ursprünglichen Textes des Benutzers entspricht. Die gepoolten Ressourcen der Systemkomponenten, die diesen Query Nodes zugewiesen sind, belaufen sich auf 3 GB und sind physisch von den Query Nodes getrennt. Insgesamt können 35 GB Speicher 128 GB Benutzerdaten aufnehmen, was etwa 3,6 GB Benutzerdaten pro GB Speicher entspricht. Im Gegensatz dazu erlaubte das frühere Design, dass 32 GB Speicher 8 GB Benutzerdaten unterstützen, was durchschnittlich 250 MB Benutzerdaten pro GB Speicher ergibt. Dies entspricht einer bemerkenswerten 15-fachen Effizienzsteigerung.
Ein Überblick über beliebte Vektordatenbanken: Milvus, Chroma und Qdrant
Vektordatenbanken spielen eine zentrale Rolle bei der Optimierung der Architektur von OpenAI Assistants, wodurch die Wahl der robustesten Option von größter Bedeutung ist. Hier betrachten wir drei prominente Open-Source-Vektordatenbanken—Milvus, Chroma und Qdrant—und bewerten ihre Stärken und Einschränkungen bei der Verbesserung der OpenAI Assistants-Architektur.
Milvus
Vorteile: Milvus ist die ausgereifteste Open-Source-Vektordatenbank und wird in groß angelegten verteilten Systemen breit eingesetzt. Zu den bemerkenswerten Funktionen gehören die effektive Trennung von System- und Query-Komponenten, die Isolation von Query-Komponenten durch die Resource Group-Funktion, eine hybride Speicher-/Festplattenarchitektur sowie Multi-Tenancy auf Anwendungsebene, ermöglicht durch RBAC- und Partition-Funktionen.
Nachteile: Trotz seiner Stärken erreicht Milvus keine vollständige Anomalie-Isolation durch die Resource Group-basierte Isolation von Query-Komponenten. Darüber hinaus führt es einige Drittanbieter-Abhängigkeiten wie Etcd und MinIO ein, was zu erhöhten Bereitstellungs- und Betriebskosten führt.
Chroma
Vorteile: Chroma tritt als neues und benutzerfreundliches Projekt hervor, das für seine Einfachheit geschätzt wird. Es eignet sich gut für schnelles Prototyping und schnelle Iteration von KI-Anwendungen und gewinnt unter einzelnen Entwicklern an Popularität.
Nachteile: Chroma überzeugt in kleineren Szenarien, ist jedoch nicht für groß angelegte Unternehmensanwendungen konzipiert. Es fehlen wichtige Funktionen wie verteilte Bereitstellung, Komponententrennung, hybride Speicher-/Festplattenarchitektur und Multi-Tenancy auf Anwendungsebene.
Qdrant
Vorteile: Qdrant bietet als Newcomer Unterstützung für verteilte Bereitstellung in kleinem Maßstab mit einem optimierten Einrichtungsprozess. Es verfügt zudem über eine hybride Speicher-/Festplattenarchitektur, wodurch es modernen Datenbankanforderungen entspricht.
Nachteile: Derzeit unterstützt Qdrant keine entscheidenden Funktionen wie Komponententrennung oder Multi-Tenancy auf Anwendungsebene, was seine Anwendbarkeit in bestimmten Anwendungsfällen einschränkt.
Bei der Bewertung dieser Vektordatenbanken wird deutlich, dass jede Lösung ihre eigenen Stärken und Kompromisse mitbringt, wodurch die Wahl von spezifischen Anforderungen und Prioritäten im Kontext der Optimierung der Architektur von OpenAI Assistants abhängt.
Zusammenfassung
In diesem Blogbeitrag haben wir uns mit den Feinheiten von OpenAI Assistants befasst und dessen Preisgestaltung, Architektur sowie potenzielle Optimierungen für Kosteneffizienz und erweiterte Speicherfähigkeiten untersucht. Eine zentrale Erkenntnis zeigte sich darin, dass die Kosten der Vektordatenbank-Infrastruktur die Bereitstellung von Wissensdatenbanken und Agent-Anwendungen erheblich beeinflussen.
Bei der Analyse der Kosten und Gewinne von OpenAI im Zusammenhang mit Assistants deckten wir ein bemerkenswertes Ungleichgewicht auf, bei dem die Ausgaben die potenziellen Einnahmen übersteigen. Während dies während der Testphase, zur Aufnahme neuer Kunden und zur Erweiterung der Community, gerechtfertigt sein mag, ist ein nachhaltigeres Gleichgewicht unerlässlich.
Der Blogbeitrag schlägt eine Lösung zur Optimierung der Architektur vor und eröffnet die Aussicht, für diese Anwendungstypen im Vergleich zu bestehenden Lösungen eine zehnfache Kostensenkung zu erreichen. Die entscheidende Rolle von Vektordatenbanken in diesem Optimierungsprozess wird hervorgehoben, wobei sich Milvus unter den verfügbaren Alternativen als besonders geeignete Option herausstellt.
Dennoch betont dieser Beitrag in Anerkennung der inhärenten Einschränkungen bestehender Vektordatenbanken, dass keine einzelne Vektordatenbanklösung alle Herausforderungen umfassend bewältigen und jede Designanforderung für die bevorstehende Infrastrukturentwicklung erfüllen kann. Die Wahl der Vektordatenbanken sollte auf spezifische Anforderungen zugeschnitten sein, um die Komplexität der Optimierung der Architektur von OpenAI Assistants effektiv zu bewältigen.
Weiterlesen
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
Announcing the General Availability of Single Sign-On (SSO) on Zilliz Cloud
SSO is GA on Zilliz Cloud, delivering the enterprise-grade identity management capabilities your teams need to deploy vectorDB with confidence.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.