Was ist eine 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 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

Ein echter Aufruf, serverseitig

// 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 — 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.

// 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.

// Android / Kotlin — Back4app Android SDK
// The client calls YOUR function, never the LLM API directly
val summary = ParseCloud.callFunction<String>(
    "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:

POST /v1/chat/completions            Authorization: Bearer <key>
{ "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 wird bei jeder Anfrage erneut berechnet. Die grobe Monatsformel, die man verinnerlicht haben sollte:

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

Streaming: warum sich Chat-Oberflächen schnell anfühlen

Setzen Sie ein stream-Flag, kommt die Antwort schrittweise als Server-Sent Events 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 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 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:

Tool Calling ist der Mechanismus, der einen KI-Agenten 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

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, 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 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, 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 – 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

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) 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, genau wie die Code-Tabs zeigen – der Client ruft Ihr summarize auf, die Funktion hält den Modellschlüssel in der serverseitigen Konfiguration 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 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ß.