Worum es geht: Ein Sprachmodell einzubinden ist technisch unspektakulär – Sie schicken ein Wörterbuch los und bekommen eines zurück. Interessant sind die vier Dinge drumherum: Systemanweisung, Schlüssel, Fehler und Kosten. Genau die entscheiden, ob aus einem Versuch etwas Betriebsfähiges wird.
1. Der Aufbau jeder Anfrage 📨
| Teil | Bedeutung |
|---|---|
model | Welches Modell – größer heißt besser und teurer |
system | Rolle und Regeln, gelten für das ganze Gespräch |
messages | Der Verlauf als Liste: abwechselnd user und assistant |
max_tokens | Obergrenze für die Antwortlänge – schützt vor Ausreißern bei den Kosten |
temperature | 0 für gleichbleibende Ergebnisse, höher für mehr Abwechslung |
Die Unterscheidung zwischen system und messages wird oft übersehen und ist wichtig: Die Systemanweisung ist die dauerhafte Vorgabe, die Nachrichten sind das Gespräch. Regeln gehören ins System, nicht in jede einzelne Frage.
2. Im Editor üben
Wir bauen die Anfrage von Hand – ohne echten Aufruf, damit kein Schlüssel nötig ist:
model, max_tokens und messages mit einer Nachricht der Rolle user. Geben Sie die Zahl der Nachrichten aus.3. Der Schlüssel 🔑
Schritt 3 ist der wichtigste der Lektion. Ein Schlüssel im Code landet in Git, und bei öffentlichen Projekten wird er innerhalb von Minuten automatisch abgegriffen und benutzt – auf Ihre Rechnung.
Der Schlüssel gehört in eine .env-Datei, die in der .gitignore steht. Auf dem Server wird er als Umgebungsvariable gesetzt. Und er gehört niemals in Code, der im Browser läuft – dort ist er für jeden sichtbar, der die Entwicklerwerkzeuge öffnet.
.env in der .gitignore? Diese eine Frage verhindert den teuersten Anfängerfehler im Umgang mit KI-Schnittstellen.4. Kosten 💶
Abgerechnet wird nach Token – grob ein Token je drei bis vier Zeichen. Eingabe ist deutlich billiger als Ausgabe. Ein einzelner Aufruf kostet Cent-Bruchteile, tausend am Tag ergeben eine Summe, die niemand veranschlagt hat.
usage = {"input_tokens": 120000, "output_tokens": 8000}
kosten = usage["input_tokens"] / 1_000_000 * 3 + usage["output_tokens"] / 1_000_000 * 15
print(round(kosten, 4)) # 0.48 EUR für diesen einen AufrufVier Hebel senken die Rechnung: den Kontext kürzen (der größte), max_tokens begrenzen, für einfache Aufgaben ein kleineres Modell wählen und Antworten zwischenspeichern. Rechnen Sie vor dem Bauen – Aufrufe je Tag mal Kosten je Aufruf mal dreißig.
5. Fehler einplanen ⚠️
Schnittstellen antworten nicht immer. Häufig sind Überlastung (429 oder 529), Zeitüberschreitungen und vorübergehende Serverfehler. Alle drei behandelt man gleich: erneut versuchen mit wachsendem Abstand, nach drei Fehlversuchen aufgeben und das dem Aufrufer sagen.
Bei 4xx-Fehlern gilt das Gegenteil – dort liegt der Fehler bei der Anfrage, und ein zweiter Versuch ändert nichts außer den Kosten. Genau diese Unterscheidung haben Sie in Schritt 5 gebaut.
6. Streaming und Antwortzeit ⏱️
Ein längerer Text braucht mehrere Sekunden. Wenn die Anwendung währenddessen nichts zeigt, wirkt sie eingefroren. Die Antwort darauf heißt Streaming: Das Modell schickt die Antwort Stück für Stück, und die Oberfläche zeigt sie im Entstehen.
Der wahrgenommene Unterschied ist groß, der technische klein – die Bibliotheken der Anbieter haben es eingebaut. Für alles, was ein Mensch direkt liest, lohnt es sich.
7. Was Sie mitnehmen sollten
- Regeln gehören in
system, das Gespräch inmessages. - Der Schlüssel kommt aus der Umgebung, nie aus dem Code und nie in den Browser.
- Bei 5xx und 429 wiederholen, bei 4xx nicht.
- Kosten vor dem Bauen hochrechnen, nicht nach der ersten Rechnung.