Jede Anfrage an ein Large Language Model (LLM) kostet Geld und so können sich die Kosten schnell summieren. Besonders für einmalige, umfangreiche Aufträge, wie etwa dem Labeln eines Datensatzes durch generative KI-Verfahren, dem “Lesen” großer Dokumentenmengen zur Erzeugung von Embeddings oder der Migration eines bestehenden Systems in einen LLM-Workflow, gibt es jetzt eine kostengünstige Alternative bei OpenAI und Azure: die Batch-API. In diesem Blogbeitrag dokumentieren wir unsere Erfahrungen, einige Vor-und Nachteile sowie nützliche Tipps und Tricks zur Verwendung der Batch-API.
Was ist die Batch-API?
Um zu verstehen, was die Batch-API von der klassischen API unterscheidet, sollte zunächst der klassische Weg der Einzelverarbeitung betrachtet werden. Hierbei wird ein Prompt an das LLM gesendet, sofort verarbeitet und die generierte Antwort zurückgegeben - ein interaktiver Prozess, bei dem es auf kurze Antwortzeiten ankommt, weil Nutzer:innen auf die Antwort warten.
Im Gegensatz dazu wird bei der Batch-API der Prompt nicht sofort verarbeitet. Stattdessen werden mehrere Prompts auf einmal - als Batch - in Auftrag gegeben und dann innerhalb von 24 Stunden, je nach Auslastung der benötigten Ressourcen, verarbeitet. Danach kann das erzeugte Ergebnis heruntergeladen werden.
Jeder Batch wird dabei über verschiedene Files verwaltet. Eine Schlüsselrolle spielt dabei die Task-File, welche alle zu verarbeitenden Prompts enthält. Die Ergebnisse stehen dann ebenfalls als Datei zur Verfügung und können bei Bedarf abgerufen werden.
Ablauf eines Jobs unter Verwendung der Azure OpenAI Batch-API
Eigene Erfahrung mit der Azure OpenAI Batch-API
Von uns wurde die Batch-API in einem viadee-internen Projekt eingesetzt. In diesem war es erforderlich, initial eine große Datenmenge zwecks Entity-Extraction zu verarbeiten. Unser Ziel war es, strukturierte Informationen aus PDF-Dokumenten zu extrahieren, soweit diese enthalten sind. Mithilfe passender Prompts und dem zugehörigen Kontext konnte geprüft werden, welche Informationen in der PDF enthalten sind. Dies ist der perfekte Anwendungsfall für die Batch-API.
Extraction von relevanten Informationen
Durch die klare und verständliche Dokumentation von OpenAI konnte schnell ein erster lauffähiger Prototyp erstellt werden. Lediglich die Unterschiede zwischen dem OpenAI-Client und dem AzureOpenAI-Client sorgten für Mehraufwand, da sich das Verfahren der beiden Anbieter leicht unterscheidet. Einige Tipps und Tricks für den AzureOpenAI-Client haben wir im Folgenden zusammengefasst.
Nun ist die Batch-API ein fester Bestandteil unserer Codebase und wird für größere und zeitunkritische Aufgaben verwendet. Wichtig zu erwähnen ist, dass jeder Task (einzelne Prompts) aus dem Batch auf OpenAI-Seite einzeln verarbeitet wird. Das sorgt dafür, dass es im Fehlerfall keine Auswirkungen auf andere Tasks oder den Gesamtauftrag gibt. Neben der Result-File wird ein Error-File erstellt, das detaillierte Informationen zu den Fehlern einzelner Tasks enthält. Zudem wird der Kontext anderer Anfragen nicht berücksichtigt, was die Robustheit und Effizienz der Verarbeitung erhöht.
Vorteile und Herausforderungen
Vorteile
Ein klarer Vorteil der Batch-API sind die geringen Kosten für die Verarbeitung. Aktuell sind die Kosten dabei per Azure-Preisliste halb so hoch wie bei der Echtzeitverarbeitung. Vor allem für die Verarbeitung großer Datenmengen, die nicht zeitsensibel sind, kann sich die Batch-API daher finanziell lohnen.
Um die Kostenvorteile zu veranschaulichen, hier eine Beispielrechnung aus unserem Projekt:
In einem Testlauf haben wir acht Anfragen pro Dokument extrahiert. Um eine Anfrage zu erhalten, wurde jeweils eine Frage mit dem zugehörigen Kontext als Prompt an das LLM übergeben. Insgesamt wurde für den Test acht verschiedene Dokumente verwendet. Der durchschnittliche Gesamtaufwand pro Anfrage lag bei ~1 Token:
063 Token (davon ~ 1.028 Prompt-Token und ~35 Answer-Token).
In einer Produktionsumgebung skaliert, lässt sich der Kostenvorteil der Batch-API deutlich erkennen. Für unser Projekt gehen wir von einem Gesamtumfang von 800 Dokumenten aus. Aus jedem Dokument sollen dann 40 Anfragen extrahiert werden. So erreicht man ohne die Batchverarbeitung Gesamtkosten in Höhe von 5,61 $ pro Durchlauf. Mit Batchverarbeitung werden die Kosten auf 2,80 $ pro Durchlauf halbiert.
| Dokument (40 Anfrage) | Gesamt (800 Dokumente) | |
| Input-Token | ~41.120 (40 Anfrage * ~1.028 Input-Token/Anfrage) |
~32,896 Millionen |
| Output-Token | ~1.400 (40 Anfragen * ~35 Output-Token/Anfrage) |
~1,12 Millionen |
| GPT-4o-mini-Batch |
||
| Kosten Input-Token (0,075 $/1 Millionen Prompt-Tokens) | ~0,003084 $ | ~2,47 $ |
| Kosten Output-Token (0,3 $/ 1 Millionen Answer-Tokens) | ~0,00042 $ | ~0,34 $ |
| Gesamt | ~0,004 $ | ~2,80 $ |
| … Gesamt ohne Batch (0,15 $/ 1 Millionen Prompt- und 0,6 $/ 1 Millionen Answer-Tokens) | ~0,008 $ | ~5,61 $ |
| GPT-4o Batch | ||
| Kosten Input-Token (1,25 $/1.000.000 Input Tokens) | ~0,0514 $ | ~41,12 $ |
| Kosten Output-Token (5 $/ 1.000.000 Output Tokens) | ~0,007 $ | ~5,6 $ |
| Gesamt | ~0,0584 $ | ~46,72 $ |
| … Gesamt ohne Batch (2,5 $/ 1 Millionen Prompt- und 10 $/ 1 Millionen Answer-Tokens) | ~0,1168 $ | ~93,44 $ |
In unserem Deployment verwenden wir aus Kostengründen das Modell GPT-4o-mini. Dieses ist kosteneffizient und gut für unseren Anwendungsfall geeignet. Möchte man jedoch andere Modelle, wie GPT-4o, oder o1-preview verwenden, können die Kostenvorteile mit 46,72 $ (anstatt 93,44 $) und 280 $ (anstatt 560 $) pro Durchlauf noch stärker zur Geltung kommen.
.svg)
Kostenvergleich mit und ohne Batch-API
Herausforderungen
Allerdings bringt die Batchverarbeitung auch Herausforderungen mit sich, die nicht ignoriert werden sollten. Ähnlich wie in der Softwareentwicklung müssen einige Limitierungen durch die Batcharchitektur berücksichtigt werden. Die längeren Verarbeitungszeiten, die durch das 24-Stunden-Verarbeitungsfenster entstehen, können die Geschwindigkeit von Entwicklungsprojekten beeinträchtigen. Während erste Experimente interaktiv durchgeführt werden können, kann die Notwendigkeit, auf die vollständige Bearbeitung eines Batches zu warten, die Flexibilität und Reaktionsfähigkeit der Teams verringern. Dies führt zu einer erhöhten Komplexität, da Teams möglicherweise nicht ausschließlich mit der Batch-API arbeiten möchten, um ihre Entwicklungszyklen zu optimieren. In unserem Projekt hat eine durchschnittliche Batchverarbeitung maximal 10 Minuten gedauert. So konnte auch die Entwicklung mit der Batch-API in kurzen Iterationen durchgeführt werden.
Zusätzlich müssen Fehlerbehandlungen neu überdacht werden, da Probleme mit einzelnen Prompts erst nach Abschluss des gesamten Batches durch den Download des Error-Files sichtbar werden. Dies kann die Fehlersuche und -behebung erschweren und den Entwicklungsprozess weiter verlangsamen.
Ein weiterer Aspekt, der berücksichtigt werden sollte, ist die aktuelle Einschränkung der Azure-API, die Embeddings nicht unterstützt (Stand 28.10.2024). Embeddings wären besonders vorteilhaft für die Batchverarbeitung, da sie in RAG-Systemen (Retrieval-Augmented Generation) weit verbreitet sind und diese eine umfangreiche Datengrundlage in Form von embeddeten Textstücken benötigen. Diese könnten durch Batchverarbeitung effizient erstellt werden, was die Vorteile der Kosteneinsparungen und der Verarbeitung großer Datenmengen weiter verstärken würde.
Da die Batch-API Prompts nicht in Echtzeit bearbeitet, können Prompting-Frameworks, die auf Echtzeit-Interaktionen basieren, wie Reasoning and Action (ReAct), nicht ohne weiteres auf die Batch-API migriert werden.
Insgesamt müssen die Preisvorteile der Batch-API in Relation zu den erhöhten Entwicklungsaufwänden und der ungewissen Bearbeitungsdauer gesetzt werden. Je mehr Tokens für die Verarbeitung benötigt werden, desto deutlicher wird der Nutzen der Batchverarbeitung.
Die Batch-API ausprobieren
Falls Sie die Batch-API einmal selbst ausprobieren möchte, empfehlen wir dieses Tutorial für die Azure OpenAI-Umgebung, und dieses für die OpenAI-Umgebung. Dort sind die für den jeweiligen Anbieter relevanten Schritte genannt und ausführlich dokumentiert. Damit dabei alles Reibungslos abläuft, folgen hier noch ein paar Hinweise.
Tipps und Tricks
Hier haben wir noch ein paar Tipps und Tricks zusammengetragen, die wir für die Entwicklung mit der Batch-API als sehr hilfreich erachten.
- Ein spezielles Batch-Deployment des zu verwendenden Modells sollte erstellt werden. Dieses ist parallel zu den normalen Modell-Deployments zu pflegen, hat jedoch den DeploymentType: GlobalBatch. Dieser Schritt wird zwar im Tutorial genannt, ist aber schnell zu übersehen.
Ein Batch-Modell kann in der Azure-Plattform aktuell nur in den USA oder in Schweden betrieben werden. - Immer die aktuellste API-Version verwenden! Die Batch-API befindet sich in reger Entwicklung und ältere Versionen sorgen oft für nicht nachvollziehbare Fehler (Stand 28.10.2024 ist das die: 2024 10-01-preview).
- In den Requests als “model” immer den Namen des Batch-Deployments verwenden. Gibt es also ein “normales” GPT-4o-mini Deployment, und eine Batch-Version namens GPT-4o-mini Deployment, und eine Batch-Version namens gpt-4o-mini-batch, so sollte der Request für die Batch-Version so aussehen:
- Bestehende LLM-Workflows können oft mit einer einfachen Anpassung des client-calls in das passende Batch-Format umgewandelt werden. So können Programme erzeugt werden, die variabel mit der Batch-API oder der Echtzeit-API arbeiten.
Hier ein Beispiel eines bekannten API-Calls:
Hier der gleiche Request als Batch-API request:
Diese Requests können dann in eine jsonl Datei geschrieben und bei OpenAI hochgeladen werden.
Dieses File wurde nun bei Azure hochgeladen und kann dort mit den im Tutorial erklärten Schritten mit einem Batch-Job verarbeitet und die Ergebnisse abgerufen werden.
Fazit
Die Azure OpenAI Batch-API bietet Unternehmen, die mit großen Datenmengen arbeiten, bei der Nutzung von LLMs eine vielversprechende Möglichkeit zur signifikanten Kostensenkung. Unsere Erfahrungen zeigen, dass die Batch-API insbesondere für tokenintensive Anwendungen, wie die Extraktion strukturierter Informationen aus umfangreichen Dokumenten, äußerst vorteilhaft ist. Die Möglichkeit, mehrere Prompts in einem Batch zu verarbeiten, führt zu erheblichen Kosteneinsparungen, die in Produktionsumgebungen besonders deutlich werden.
Die längeren Verarbeitungszeiten und die Notwendigkeit, auf die vollständige Bearbeitung eines Batches zu warten, können die Flexibilität und Reaktionsfähigkeit der Entwicklungsteams beeinträchtigen. Zudem erfordert die Fehlerbehandlung eine sorgfältige Planung, da Probleme erst nach Abschluss des gesamten Batches sichtbar werden. Ein weiterer Nachteil ist das Fehlen der Embedding-Funktion bei der Azure OpenAI Batch-API, was die Anwendung der API in typischen Szenarien wie Retrieval-Augmented Generation (RAG) einschränkt.
Es ist wichtig zu erwähnen, dass die Batch-API derzeit nur in den Preview-Versionen der Azure API verfügbar ist und noch nicht in einer General Availability (GA) Version. Da die preview Versionen instabil sein können, sind die Rahmenbedingungen noch nicht für einen dauerhaften Betrieb geeignet, der unseren Ansprüchen an MLOps gerecht wird. Die Azure OpenAI Batch-API entwickelt sich aber schnell weiter und es lohnt sich, diese architektonische “Karte” schon einmal auf der Hand zu haben.
Dieser Beitrag basiert auf der Projekterfahrung von Lars Heimann während seines Praktikums bei der Viadee. Unterstützt wurde er dabei von Moritz Arends.
Haben wir Ihr Interesse geweckt? Melden Sie sich gerne bei uns.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
