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“Jedes Modell hat ein Limit für gleichzeitige Anfragen (max_parallel_requests). Ü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.
| Modell | Max. parallele Anfragen |
|---|---|
| Gemma 4 26B (MoE) | 8 |
| Qwen3.6 | 4 |
| Qwen3.5-27B | 4 |
| Devstral-Small-2 | 8 |
| Ministral-3-14B | 8 |
| Jina Embeddings v2 base-de | 8 |
| Parakeet V3 | 4 |
| Parakeet V3 (Diarization) | 4 |
Anfragegröße
Abschnitt betitelt „Anfragegröße“Es gibt derzeit kein hartes Token-Limit pro Anfrage. Die Kontextfenster der Modelle gelten:
| Modell | Kontextfenster |
|---|---|
| Gemma 4 26B (MoE) | 128kToken |
| Qwen3.6 | 256kToken |
| Qwen3.5-27B | 128kToken |
| Devstral-Small-2 | 128kToken |
| Ministral-3-14B | 128kToken |
| Jina Embeddings v2 base-de | 8kToken |
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).