API-Schlüssel
Was ist ein API-Schlüssel?
Abschnitt betitelt „Was ist ein API-Schlüssel?“Ein API-Schlüssel ist eine zufällig erzeugte Zeichenkette, die Ihre Anwendung bei jeder Anfrage an maKI mitsendet. Anhand des Schlüssels erkennt maKI, wer fragt und welche Modelle aufgerufen werden dürfen; die Nutzung wird pro Schlüssel protokolliert.
Sie benötigen einen Schlüssel, sobald Sie maKI aus eigenem Code, einem SDK, einem Notebook oder einem Werkzeug wie curl ansprechen — kurz: überall außerhalb der Admin-Oberfläche unter /ui/.
Behandeln Sie den Schlüssel wie ein Passwort:
- Niemals im Quellcode oder in einem Git-Repository hinterlegen
- In einer Umgebungsvariable, einem Secret-Manager oder 1Password speichern
- Bei Verdacht auf Kompromittierung sofort widerrufen lassen
Schlüsseltypen
Abschnitt betitelt „Schlüsseltypen“| Typ | Zuordnung | Personenbezug | Beispiel |
|---|---|---|---|
| Persönlicher Schlüssel | Einzelperson | Ja (indirekt über Nutzungsdaten) | Philipp Hematty |
| Service-Schlüssel | Anwendung oder Team (≥3 Personen) | Nein | F13-Assistenzsystem |
| Batch-Schlüssel | Ad-hoc-Massenverarbeitung | Nein | embedding-migration-2026 |
Schlüssel anfordern
Abschnitt betitelt „Schlüssel anfordern“Wenden Sie sich an den maKI-Administrator (philipp.hematty@uni-mannheim.de) mit:
- Name des Dienstes oder Teams
- Ansprechperson (technischer Kontakt)
- Verwendungszweck (kurze Beschreibung)
Schlüssel widerrufen
Abschnitt betitelt „Schlüssel widerrufen“Bei Verdacht auf Kompromittierung eines Schlüssels:
- Sofort melden an philipp.hematty@uni-mannheim.de
- Administrator deaktiviert den Schlüssel über die LiteLLM Admin-UI (
/ui) - Neuer Schlüssel wird ausgestellt und dem Ansprechpartner mitgeteilt
- Alter Schlüssel wird dauerhaft gelöscht
Widerrufene Schlüssel werden sofort ungültig — laufende Anfragen werden noch abgeschlossen, neue Anfragen abgelehnt.
Priorisierung
Abschnitt betitelt „Priorisierung“API-Schlüssel werden bei GPU-Auslastung nach Typ priorisiert:
| Schlüsseltyp | Priorität | Verhalten bei Auslastung |
|---|---|---|
| Persönlich | Hoch (1) | Anfragen werden bevorzugt aus der Warteschlange bedient |
| Service | Normal (64) | Anfragen warten hinter persönlichen Anfragen |
| Batch | Niedrig (128) | Anfragen warten hinter persönlichen und Service-Anfragen |
Wenn die GPU nicht ausgelastet ist, erhalten alle Typen den vollen Durchsatz — es gibt keine künstliche Drosselung. Die Priorisierung greift erst, wenn alle parallelen Slots eines Modells belegt sind.
Parallelität
Abschnitt betitelt „Parallelität“Ein Modell kann ein Limit für gleichzeitige Anfragen haben (max_parallel_requests); die Tabelle zeigt den aktuellen Stand. Überschüssige Anfragen werden in eine Warteschlange eingereiht und nach Priorität abgearbeitet. Bei langer Warteschlange erhalten Anfragen HTTP 429 und sollten mit exponentiellem Backoff wiederholt werden.
Modellliste wird geladen …
Anfragegröße
Abschnitt betitelt „Anfragegröße“Es gibt derzeit kein hartes Token-Limit pro Anfrage. Die Kontextfenster der Modelle gelten:
Modellliste wird geladen …
Im aktuellen Betrieb mit ausschließlich lokalen Modellen gibt es keine Kostenbudgets pro Schlüssel. Die Nutzung wird zu Planungszwecken erfasst (Zeitstempel, Modell, Token-Anzahl).
Monitoring
Abschnitt betitelt „Monitoring“Die Nutzung wird pro Schlüssel erfasst:
- Anfragen pro Modell und Zeitraum
- Token-Verbrauch (Input/Output)
- Fehlerraten
Diese Daten dienen der Kapazitätsplanung und Kostenverrechnung, nicht der Verhaltenskontrolle (siehe Datenschutz).