--- term: 'LLM-API' seoTitle: 'LLM-API: Tokens, Streaming, Tool Calling, API-Schlüssel' headline: 'Was ist eine LLM-API?' slug: llm-api category: ai-modern-stack shortDefinition: 'Eine LLM-API ist ein HTTP-Endpoint zu einem gehosteten Sprachmodell: Prompt senden, generierten Text zurückerhalten, abgerechnet pro Token.' relatedTerms: - api - api-key-security - cloud-code-serverless-functions - retrieval-augmented-generation-rag contrastsWith: - ai-agent aboutTerms: - 'Tokens' - 'Chat Completions' - 'Streaming (SSE)' - 'Tool Calling' faq: - question: 'Was ist eine LLM-API?' answer: 'Ein HTTP-Endpoint, über den Ihr Code einen Prompt an ein gehostetes Large Language Model schickt und generierten Text zurückerhält – ohne dass Sie das Modell, GPUs oder Inferenz-Infrastruktur selbst betreiben. Sie senden einen JSON-Body per POST, erhalten eine Assistenten-Nachricht samt Token-Verbrauch und zahlen pro Token.' - question: 'Was ist ein Token, und wie werden die Preise berechnet?' answer: 'Ein Token ist ein Textstück – grob vier Zeichen oder drei Viertel eines englischen Wortes. Sie zahlen pro Million Tokens, mit getrennten Sätzen für Eingabe (Ihr Prompt) und Ausgabe (die generierte Antwort). Die Ausgabe kostet typischerweise ein Vielfaches der Eingabe, weil das Erzeugen eines Tokens mehr Rechenaufwand bedeutet als das Lesen eines Tokens.' - question: 'Was ist ein Context Window?' answer: 'Die maximale Anzahl an Tokens – Eingabe plus Ausgabe –, die ein Modell in einer Anfrage berücksichtigen kann. Es deckelt, wie viel Gesprächsverlauf oder Dokument Sie mitgeben können, und es ist ein direkter Kostentreiber: Jeder Aufruf bezahlt den gesamten Kontext, den Sie senden, sodass ein langer Verlauf oder eine große abgerufene Passage bei jeder Anfrage Geld kostet.' - question: 'Was ist Streaming, und warum nutzen Chat-Oberflächen es?' answer: 'Setzen Sie ein Stream-Flag, kommt die Antwort schrittweise als Server-Sent Events zurück statt als ein einziger Block am Ende, sodass die Oberfläche Tokens rendert, während sie entstehen. Es existiert für die gefühlte Latenz: Die Zeit bis zum ersten Token ist ein Bruchteil der Zeit bis zur vollständigen Antwort, also sieht der Benutzer sofort Wörter statt sekundenlang einen Spinner.' - question: 'Was ist Function Calling oder Tool Calling?' answer: 'Sie beschreiben die verfügbaren Tools – einen Namen und ein JSON-Schema – in der Anfrage; das Modell antwortet dann nicht in Prosa, sondern gibt einen strukturierten JSON-Aufruf mit Tool-Namen und Argumenten zurück. Ihr Code führt ihn aus und gibt das Ergebnis zurück. Das Modell führt die Funktion nie selbst aus; es fordert sie nur an. Das ist der Mechanismus, der aus einer LLM-API einen Agenten macht.' - question: 'Sollten Sie eine LLM-API vom Client oder vom Server aus aufrufen?' answer: 'Immer vom Server. Ein API-Schlüssel, der in einem Browser-Bundle oder einem mobilen Binary ausgeliefert wird, ist einen Blick in den Netzwerk-Tab oder eine Dekompilierung vom Diebstahl entfernt – und ein gestohlener Modellschlüssel ist ein Fremder, der Ihr Token-Budget ausgibt. Jeder LLM-Aufruf läuft über Ihr Backend, mit dem Schlüssel in der serverseitigen Konfiguration.' - question: 'LLM-API oder ein offenes Modell selbst hosten?' answer: 'Eine API bedeutet null Infrastruktur, Abrechnung pro Aufruf und einen Start noch heute; ein offenes Modell selbst zu hosten (mit Werkzeugen wie Ollama, vLLM oder llama.cpp) bringt volle Kontrolle und Datenresidenz, gewinnt bei den Kosten aber erst bei sehr hohem, dauerhaftem Volumen, sobald GPUs und Betrieb eingerechnet sind. Die meisten Produkte starten mit der API und prüfen später erneut.' - question: 'Wie gehen Sie mit Rate Limits und Fehlern um?' answer: 'Die Limits kommen als Anfragen pro Minute und Tokens pro Minute; bei einem 429 oder einem 5xx wiederholen Sie mit exponentiellem Backoff plus Jitter und respektieren einen etwaigen Retry-After-Header. Wiederholen Sie keine 4xx-Fehler – fehlerhafte Authentifizierung, falsch geformte Anfragen und Ablehnungen wegen Inhaltsrichtlinien scheitern beim zweiten Mal genauso.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Server-Sent Events — WHATWG HTML Living Standard' url: 'https://html.spec.whatwg.org/multipage/server-sent-events.html' - name: 'How to call an LLM API with function calling — Martin Fowler' url: 'https://martinfowler.com/articles/function-call-LLM.html' - name: 'RFC 8259 — JSON' url: 'https://datatracker.ietf.org/doc/html/rfc8259' - name: 'Ollama — run open models locally' url: 'https://github.com/ollama/ollama' - name: 'Large language model — Wikipedia' url: 'https://en.wikipedia.org/wiki/Large_language_model' cta: title: 'Wohin der LLM-Aufruf gehört' text: 'Legen Sie den Modellaufruf in eine Cloud Function von Back4app: Schlüssel serverseitig, Kostengrenzen durchgesetzt, Ergebnis in die Datenbank geschrieben und über Live Queries an die Clients gestreamt – nie ein Schlüssel auf dem Gerät.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-25' translationKey: llm-api --- **Eine LLM-API ist ein HTTP-Endpoint zu einem gehosteten Sprachmodell: Prompt senden, generierten Text zurückerhalten, abgerechnet pro Token.** Sie ist eine gewöhnliche [API](/glossary/de/api/) mit drei ungewöhnlichen Eigenschaften – sie ist *zustandslos* (Sie senden bei jedem Aufruf das ganze Gespräch erneut), *nach Tokens bemessen* (Eingabe und Ausgabe getrennt bepreist) und *nicht deterministisch* (derselbe Prompt kann anderen Text liefern). Beherrschen Sie diese drei, ist der Rest die operative Disziplin, die die bestplatzierten Seiten auslassen: wohin der Aufruf gehört, was er kostet und wie er scheitert. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Was es ist | Ein `messages`-Array per POST senden → Assistenten-Antwort + Token-Zahlen | | Die Abrechnung | Pro Token, Eingabe und Ausgabe getrennt bepreist, Ausgabe kostet mehr | | Der zustandslose Haken | Gedächtnis heißt, dass Sie frühere Züge erneut senden – jeder Aufruf, jedes Token bezahlt | | Die eiserne Regel | Nie vom Client aus aufrufen – der Schlüssel leckt; über das Backend proxen | | Die Brücke zu Agenten | Tool Calling – das Modell fordert eine Funktion an, Ihr Code führt sie aus | ## Ein echter Aufruf, serverseitig **JavaScript:** ```javascript // JavaScript — Cloud Code (cloud/main.js) // The LLM call belongs server-side — the key never reaches the client Parse.Cloud.define('summarize', async (req) => { const res = await Parse.Cloud.httpRequest({ method: 'POST', url: 'https://api.llm-provider.example/v1/chat/completions', headers: { Authorization: `Bearer ${process.env.LLM_KEY}`, // server-side secret 'Content-Type': 'application/json', }, body: { model: 'default-chat', messages: [ { role: 'system', content: 'Summarize in one sentence.' }, { role: 'user', content: req.params.text }, ], max_tokens: 80, // cost + latency guardrail, enforced by YOU }, }); return res.data.choices[0].message.content; }); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The client calls YOUR function, never the LLM API directly final summary = await ParseCloudFunction('summarize') .execute(parameters: {'text': longArticle}); print(summary.result); // The model key stays on the server. If this app called the LLM API // itself, the key would ship in the binary — one decompile from theft. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The client calls YOUR function, never the LLM API directly let summary: String = try await Cloud.run( name: "summarize", parameters: ["text": longArticle]) print(summary) // The model key stays on the server. If this app called the LLM API // itself, the key would ship in the IPA — one decompile from theft. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The client calls YOUR function, never the LLM API directly val summary = ParseCloud.callFunction( "summarize", mapOf("text" to longArticle)) println(summary) // The model key stays on the server. If this app called the LLM API // itself, the key would ship in the APK — one decompile from theft. ``` Die Form ist portabel – die meisten Anbieter akzeptieren dasselbe Chat-Completions-Format, sodass Anfrage und Antwort unten gleich aussehen, auf welches Modell Sie auch zeigen: ```text POST /v1/chat/completions Authorization: Bearer { "model": "default-chat", "messages": [ { "role": "system", "content": "You are concise." }, ← legt das Verhalten fest { "role": "user", "content": "Explain tokens." } ], ← die Anweisung "max_tokens": 200, "temperature": 0.7, "stream": false } → { "choices": [ { "message": { "role": "assistant", "content": "A token is…" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 24, "completion_tokens": 118, "total_tokens": 142 } } ← was Ihnen berechnet wird ``` ## Tokens sind die Währung Ein **Token** ist ein Textstück – grob vier Zeichen oder drei Viertel eines englischen Wortes. Alles an den Kosten einer LLM-API läuft darauf hinaus, sie zu zählen, und zwei Tatsachen überraschen. **Die Ausgabe kostet mehr als die Eingabe** – oft ein Vielfaches –, weil das Lesen Ihres Prompts billig ist, während das Erzeugen jedes Antwort-Tokens rechenintensiv ist, eine Vorhersage nach der anderen über das gesamte Vokabular. Und **Kontext wird bei jedem Aufruf bezahlt**: Das Modell ist zustandslos, "Gedächtnis" heißt also, dass Sie frühere Züge erneut senden, und ein langer Verlauf oder eine große [abgerufene Passage](/glossary/de/rag/) wird bei jeder Anfrage *erneut* berechnet. Die grobe Monatsformel, die man verinnerlicht haben sollte: ```text Monatskosten ≈ ( Anfragen/Tag × (avg_input_tokens × input_price_per_M / 1_000_000 + avg_output_tokens × output_price_per_M / 1_000_000) ) × 30 Die Hebel, die daran drehen: max_tokens deckeln, den erneut gesendeten Kontext kürzen, für einfache Aufgaben ein kleineres Modell wählen und wiederverwendete Prompt-Präfixe cachen. ``` ## Die Parameter, die zählen | Parameter | Steuert | Praxishinweis | | --- | --- | --- | | `temperature` | Zufälligkeit (0–2) | 0 für Extraktion/Klassifikation; ~0,7 für Fließtext | | `top_p` | Nucleus Sampling | Entweder diesen *oder* temperature einstellen – nicht beide | | `max_tokens` | Obergrenze der Ausgabelänge | Fast immer setzen – begrenzt Kosten und Latenz | | `stop` | Abbruchsequenzen | Generierung an einem Trennzeichen beenden, das Sie kontrollieren | ## Streaming: warum sich Chat-Oberflächen schnell anfühlen Setzen Sie ein `stream`-Flag, kommt die Antwort schrittweise als [Server-Sent Events](https://html.spec.whatwg.org/multipage/server-sent-events.html) an – `data:`-Zeilen, ein Token-Stück nach dem anderen, abgeschlossen mit einem `[DONE]`-Marker – statt als ein Block nach mehreren Sekunden. Der Grund liegt in der Wahrnehmung: Die **Zeit bis zum ersten Token** ist ein Bruchteil der Zeit bis zur vollständigen Antwort, also sieht der Benutzer Wörter erscheinen, statt einem Spinner zuzusehen. Es ist einseitiger Text vom Server zum Client über schlichtes HTTP, also genau [die Form von SSE](/glossary/de/sse-vs-websockets-vs-polling/) und genau der Grund, warum LLM-Streaming darauf setzt statt auf WebSockets. Die Konsequenz fürs Backend: Ihr Proxy muss *durchreichen* – den Event-Stream des Anbieters lesen und weitergeben – statt die ganze Antwort zu puffern und damit den Sinn zu zerstören. ## Tool Calling und strukturierte Ausgabe Zwei Funktionen machen aus "Text rein, Text raus" etwas Programmierbares. **Tool Calling:** Sie beschreiben die verfügbaren Funktionen (Name + JSON-Schema) in der Anfrage, und das Modell gibt statt Prosa einen strukturierten JSON-Aufruf mit Tool-Namen und Argumenten zurück; Ihr Code führt ihn aus und gibt das Ergebnis zurück ([Fowlers Durchgang](https://martinfowler.com/articles/function-call-LLM.html) ist die klare Referenz). Das Modell führt die Funktion nie selbst aus; es *fragt* nur. **Strukturierte Ausgabe**, vom Tool Calling zu unterscheiden und oft damit verwechselt, sind drei Dinge, die man auseinanderhalten sollte: | Mechanismus | Garantie | Einsetzen für | | --- | --- | --- | | JSON-Modus | Gültiges JSON – aber beliebige Form | Lockere "gib mir JSON"-Anforderungen | | Structured Outputs | Entspricht genau *Ihrem* Schema | Extraktion, Klassifikation, typisierte Daten | | Tool Calling | Ein Aufruf *Ihrer* Funktion | Dinge tun, nicht nur formatieren | Tool Calling ist der Mechanismus, der einen [KI-Agenten](/glossary/de/ki-agent/) möglich macht – dieselbe Anfrage-Antwort-Folge, in einer Schleife ausgeführt, bis das Modell keine Tools mehr anfordert. ## LLM-API vs. Selbst-Hosting eines offenen Modells | | Gehostete LLM-API | Selbst gehostetes offenes Modell | | --- | --- | --- | | Infrastruktur | Keine – der Anbieter betreibt sie | GPUs, Serving-Stack, Betrieb | | Abrechnung | Pro Token, nutzungsabhängig | Feste Kapazität, die Sie füllen müssen | | Zeit bis zum Start | Minuten | Tage bis Wochen | | Datenresidenz | Die Bedingungen des Anbieters | Vollständig bei Ihnen | | Kosten bei geringem/schwankendem Volumen | Am günstigsten | Leerlaufende GPUs verbrennen Geld | | Kosten bei extremem Dauervolumen | Können Selbst-Hosting übersteigen | Gewinnt jenseits des Break-even | Die ehrliche Einschätzung: Eine API gewinnt für fast alle und fast immer – null Infrastruktur, sofortiger Start und günstiger, solange das Volumen nicht wirklich groß und gleichmäßig ist. Ein offenes Modell selbst zu hosten (mit [Ollama](https://github.com/ollama/ollama), vLLM oder llama.cpp) verdient seine Betriebskosten erst jenseits eines hohen Break-even oder wenn Datenresidenz eine harte Anforderung ist. Die meisten Produkte starten mit der API und stellen die Frage erst neu, wenn die Größenordnung sie dazu zwingt. ## Zuverlässigkeit: LLM-Endpoints sind unzuverlässig Behandeln Sie die LLM-API als langsame, ratenbegrenzte, gelegentlich ausfallende entfernte Abhängigkeit, denn genau das ist sie. Die Limits kommen als **Anfragen pro Minute und Tokens pro Minute**; überschreiten Sie eines von beiden, erhalten Sie ein `429`. Die Disziplin ist dieselbe, die jede [ratenbegrenzte API](/glossary/de/api-rate-limiting/) verlangt: bei einem `429` oder einem `5xx` mit **exponentiellem Backoff plus Jitter** wiederholen und `Retry-After` respektieren; bei einem `4xx` – fehlerhafte Authentifizierung, falsch geformte Anfrage, Ablehnung wegen Inhaltsrichtlinien – *nicht* wiederholen, denn es wird genauso scheitern. Fügen Sie Zeitüberschreitungen pro Anfrage hinzu (die Generierung kann hängen bleiben), und denken Sie daran, dass ein wiederholter, nicht idempotenter Aufruf die Tokens zweimal kostet. Nichts davon ist LLM-spezifisch; alles davon lassen die Tutorials aus, die beim `curl` des Glücksfalls aufhören. ## Die Regel, die Tutorials verschweigen: nie vom Client aus aufrufen Die operativ wichtigste Tatsache, und genau die, die Glossarseiten auslassen: **Der Aufruf der LLM-API gehört auf Ihren Server, nie in den Browser oder die App.** Ein Modell-API-Schlüssel, der an den Client ausgeliefert wird, ist einen Blick in den Netzwerk-Tab oder eine Dekompilierung des Binaries vom Diebstahl entfernt – und anders als ein durchgesickerter veröffentlichbarer Schlüssel ist ein gestohlener *Modell*-Schlüssel ein Fremder mit Ihrem Token-Budget und keiner anderen Grenze als Ihrer Rechnung. Das Muster ist [dieselbe Proxy-Disziplin](/glossary/de/api-schluessel-sicherheit/), die jeder Dienst mit geheimem Schlüssel braucht: Der Client ruft *Ihren* Endpoint auf, Ihr Backend hält den Schlüssel in der serverseitigen Konfiguration und ruft das Modell auf, und die Antwort kommt über Sie zurück. In diesem Proxy sitzt auch jede andere Kontrolle aus diesem Artikel – Kostengrenzen, Wiederholungsversuche, Streaming, Prompt-Kürzung –, und deshalb hat die Frage "wohin geht der Aufruf?" nur eine Antwort. ## Typische Anwendungsfälle - **Zusammenfassen und Extrahieren** – langen Text in kurze strukturierte Daten verwandeln, `temperature: 0`. - **Chat und Assistenten** – gestreamte Antworten über einen erneut gesendeten Gesprächsverlauf. - **Klassifikation und Verschlagwortung** – Structured Outputs, die Ihr Label-Schema erzwingen. - **[RAG-Antworten](/glossary/de/rag/)** – Generierung, verankert in abgerufenem Kontext, kostenseitig durch Kürzen dieses Kontexts gesteuert. - **Agentische Aktionen** – Tool Calling in einer Schleife, jedes Tool eine berechtigungsgeprüfte Backend-Funktion. ## Sollten Sie eine LLM-API verwenden? Eine Entscheidungsmatrix | Situation | Greifen Sie zu | | --- | --- | | Ein KI-Feature soll jetzt ausgeliefert werden | Einer LLM-API – null Infrastruktur | | Jede App mit Client-Oberfläche | Der API, **serverseitig** aufgerufen – nie vom Gerät aus | | Extremes, dauerhaftes Volumen | Prüfen Sie Selbst-Hosting (Ollama, vLLM) jenseits des Break-even | | Strenge Datenresidenz | Selbst hosten oder ein Anbieter mit den passenden Zusagen | | Deterministische, regelbasierte Aufgabe | Vielleicht gar keinem LLM – schlichter Code ist günstiger und zuverlässig | | Das Modell muss Dinge *tun* | Tool Calling → einem [Agenten](/glossary/de/ki-agent/) | ## Grenzen und Trade-offs - **Nichtdeterminismus ist der Standard.** Derselbe Prompt schwankt von Lauf zu Lauf; alles, was exakte Wiederholbarkeit braucht, verlangt `temperature: 0` und oft eine Validierung der Ausgabe. - **Die Kosten skalieren still mit den Tokens.** Ein großzügiger Kontext oder ein unbegrenztes `max_tokens` macht aus einem billigen Feature bei Volumen ein teures – messen Sie den Verbrauch, statt ihn anzunehmen. - **Die Latenz liegt bei Sekunden, nicht Millisekunden.** LLM-Aufrufe sind nach Webmaßstäben langsam; planen Sie dafür mit Streaming, asynchronen Mustern und ehrlichen Ladezuständen. - **Die Abhängigkeit ist extern und ratenbegrenzt.** Ausfälle und Drosselung beim Anbieter sind Ihre Ausfälle; Wiederholungsversuche, Ausweichpfade und Caching sind Widerstandsfähigkeit, keine Politur. - **Ausgaben können falsch und dabei selbstsicher sein.** Die API liefert flüssigen Text unabhängig von der Wahrheit; Grounding ([RAG](/glossary/de/rag/)) und Validierung sind der Weg, ihr zu vertrauen. ## LLM-APIs mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Frage "wohin gehört der Aufruf" beantwortet sich hier von selbst: in eine [Cloud Function](/glossary/de/cloud-code-serverless-funktionen/), genau wie die Code-Tabs zeigen – der Client ruft Ihr `summarize` auf, die Funktion hält den Modellschlüssel in der [serverseitigen Konfiguration](/glossary/de/api-schluessel-sicherheit/) und ruft die LLM-API auf, und der Schlüssel berührt nie das Gerät. Diese eine Platzierung löst die ganze Lückenliste auf einen Schlag: Kostengrenzen (die Funktion setzt `max_tokens` und wählt das Modell), Wiederholungsversuche und Backoff (in der Funktion, gegenüber dem launischen Endpoint) und die Zustellung auf zwei Wegen – geben Sie die Antwort für eine einzelne Auskunft synchron zurück, oder schreiben Sie sie in die Datenbank und lassen Sie die Clients über [Live Queries](/glossary/de/live-queries-echtzeit/) zusehen, wie sie sich füllt, was Streaming ohne selbst gebauten Socket ist. Die LLM-API hört auf, ein Integrationsrisiko zu sein, und wird zu einem weiteren serverseitigen Aufruf, den Ihr Backend schon sicher abzusetzen weiß.