          KI-Beratung · LiteLLM        

LiteLLM API-Keys im Unternehmen: selbst provisionieren, ohne Key-pro

Kurz gesagt

LiteLLM Virtual Keys sitzen am Gateway: Mitarbeiter erzeugen sie selbst, ohne einen Provider-Key pro Person. Self-Service in der UI oder im internen Portal, Budget und Ablauf am Token. Das Gateway bleibt Source of Truth für Modell, Datenklasse und Spend. In den LiteLLM-Docs ist max_budget default null. Ohne gesetztes Budget prüft das Gateway den Spend nicht. Pexon Consulting setzt den Cap.

Microsoft Partner

ISO 27001 zertifiziert

On-Premise und EU-Cloud

Microsoft Solutions Partner (Digital & App Innovation, Infrastructure Azure, Data & AI Azure), ISO/IEC 27001, Google Cloud Partner, AWS Partner

Plattform-Check buchen (45 Min)
Zum LiteLLM-Hub

Warum Key-pro in Unternehmen kippt

Sobald Entwickler einen LiteLLM API-Key fordern, kippt Key-pro: Keys werden geteilt, Budgets fehlen, Shadow-Keys liegen in Repos. Die LiteLLM-Seite beschreibt das Gateway; hier hängt die Provisionierung darunter. Das Muster ist Teil der Open-Source-KI-Plattform. In der LiteLLM Virtual Keys Dokumentation gilt: ohne Datenbank keine Virtual Keys, max_budget default null. Sharing, fehlende Caps und kopierte Provider-Keys sind derselbe Ausfall: Platform kann nicht rotieren, nicht budgetieren und nicht sagen, welches Team den Call ausgelöst hat. Mitarbeiter sollen Keys selbst erzeugen, ohne dass jeder einen OpenAI-, Anthropic- oder Azure-Schlüssel bekommt. Dafür sitzen Virtual Keys am Gateway, Self-Service in der UI oder im internen Portal, und das Budget am Token, nicht in einer Tabelle nach dem Monat.

Sharing statt Besitz

Ein Provider-Key für zwölf Personen ist kein Self-Service. Wer kündigt, bleibt im Log. Niemand weiß, welcher Call zu welchem Team gehört. Rotation trifft alle gleichzeitig und stoppt produktive Jobs. Der LiteLLM API-Key muss deshalb am Gateway hängen, nicht in zwölf privaten Dateien.

Keine Budgets am Key

Ohne max_budget am Gateway-Key läuft Spend durch. Die LiteLLM-Docs setzen den Default auf null: dann wird nicht geprüft. Erst budget_duration, etwa 30d, macht das Limit periodisch. Ohne Cap ist Self-Service nur ein kürzerer Weg in dieselbe Rechnung. LiteLLM Virtual Keys ohne gesetztes Budget sind deshalb kein Kostenstopp.

Shadow-Keys in Repos

Tickets dauern, also kopiert jemand den OpenAI-Schlüssel in .env und in CI-Secrets. Platform verliert Modellzugriff, Ablaufdatum und die Chance, einen Key zu löschen, ohne den Provider zu drehen. Ein Virtual Key lässt sich in der UI löschen; der Provider-Schlüssel bleibt beim Service-User.

Was Virtual Keys gegenüber Provider-Keys belegen

Zahlen aus der LiteLLM Virtual Keys Dokumentation und dem Pexon-Betriebsmodell, ohne erfundene Marktprozente.

null max_budget Default

Ohne gesetztes Budget prüft LiteLLM den Spend nicht. Self-Service ohne Cap ist nur ein kürzerer Weg in dieselbe Kostenfalle. (LiteLLM Docs, Budgets und Rate Limits)

30d budget_duration

Die Docs kennen 30s, 30m, 30h und 30d. Ein Team-Key mit 30d und max_budget ersetzt den monatlichen Excel-Export. (LiteLLM Docs, budget_duration)

sk- Master-Key-Präfix

Der Master-Key muss mit sk- beginnen. Virtual Keys erzeugt die UI oder /key/generate. Personen bekommen keinen Provider-Key. (LiteLLM Docs, Virtual Keys)

8x5 Betrieb statt Folie

Pexon Consulting betreibt das Gateway in der Servicezeit Mo-Fr. Kein 24-Stunden-Claim. 80 MA, ISO 27001, 400+ Projekte. (Pexon Betriebsmodell, MEZ)

Ab wann sich LiteLLM Virtual Keys lohnen

LiteLLM Virtual Keys lohnen sich, sobald mehr als ein Team denselben Provider-Key teilt oder sobald Entwickler Keys fordern, ohne dass Platform den OpenAI-, Anthropic- oder Azure-Schlüssel herausgeben darf. Die Schwelle liegt bei Self-Service: interne User erzeugen eigene Keys, sobald die Rolle internal_user und Team-Rechte das erlauben. Sie liegt bei einem gesetzten max_budget, weil der Default in den LiteLLM-Docs null ist und dann nicht geprüft wird. Sie liegt bei einer Postgres-Datenbank, ohne die Virtual Keys und Budgets nicht greifen. Pexon Consulting hängt den Provider-Key an einen Service-User, nicht an Personen. Gruppenrechte und ein internes Portal oder Shop sitzen davor, wenn Anträge, Datenklasse und Team vor dem generate stehen sollen. Mitarbeiter sehen Modell, Budgetrest und Ablauf; Platform sieht Spend, Rotation und die Modellliste. Welche Prompts welche Klasse dürfen, steht in der Datenklassifizierung, nicht in diesem Self-Service. Das Muster ist Teil der Open-Source-KI-Plattform. Stand 31. August 2026. Betrieb 8x5, kein Rund-um-die-Uhr-Claim.

1 Team

geteilt den Provider-Key

1 Budget

max_budget gesetzt, nicht null

1 DB

Postgres für Keys und Spend

Muster: Service-User, Shop, Gruppenrechte

Use Case 01

Entwickler im Self-Service

Interne User mit Rolle internal_user erzeugen eigene Keys in der UI, sobald SSO sitzt. Sie wählen Modell aus der Freigabeliste, nicht den Provider-Katalog. Platform muss nicht jedes Token per Ticket schneiden.

0 Provider-Keys in privaten .env-Dateien der Entwickler

Use Case 02

Service-User für Apps

Anwendungen bekommen einen Service-Account-Key über /key/service-account/generate. user_id bleibt null, der Key hängt nicht an einer kündigenden Person. Der Provider-Schlüssel bleibt beim Service-User, auch wenn die App wechselt.

1 Service-User hält den Provider-Key, Apps halten Virtual Keys

Use Case 03

Team-Budgets statt Excel

Platform setzt max_budget und budget_duration am Team-Key. Nach dem Cap schlagen Requests fehl. Persönliche Keys bleiben daneben möglich, wenn das Team das erlaubt. Ohne gesetztes Budget bleibt der Default null und der Cap greift nicht.

1 Cap pro Team, Spend in LiteLLM_VerificationTokenTable

Use Case 04

Rotation ohne Provider-Wechsel

Key duration, etwa 30min in den Docs oder länger im Betrieb, plus Löschen in der UI. Der OpenAI-Schlüssel bleibt beim Service-User. Nur das Gateway-Token rotiert. Ein kompromittierter Virtual Key trifft nicht den Provider-Account.

1 Provider-Rotation pro Quartal statt pro Person und Ticket

Was in Ihre Landschaft muss

Virtual Keys brauchen IdP, Postgres und ein Gateway, das den Provider-Key hält. Ohne diese drei Teile bleibt Self-Service eine UI ohne Durchsetzung. SSO in der LiteLLM-UI reicht für viele Teams; ein interner Shop sitzt davor, wenn Anträge, Gruppenrechte und Datenklasse vor dem generate stehen sollen.

IdP, Rollen, Shop

SSO in der UI · Keys erzeugen, ändern, löschen nach Login, nicht über geteilte Admin-Sessions. SSO ist die Tür, nicht der Master-Key im Chat.

internal_user · Rolle darf eigene Keys anlegen, sobald Team-Rechte das erlauben. proxy_admin bleibt bei Platform, nicht bei jedem Entwickler.

Internes Portal · Shop oder Formular vor der LiteLLM-UI, wenn Gruppen und Datenklassen vor dem Key stehen sollen. Ohne Shop bleibt die UI der Shop.

Gateway, Datenbank, Klasse

Postgres · Pflicht für Virtual Keys, Budgets und Spend. Ohne DB kein Key-pro-Ersatz.

Service-User · Hält OpenAI-, Anthropic- oder Azure-Schlüssel. Personen sehen ihn nicht.

Datenklasse · Welche Prompts welche Klasse dürfen, steht in der Datenklassifizierung, nicht im Key-Formular.

Was der User sieht vs. was nur Platform sieht

1

Provider-Key einsperren

Ein Service-User hält den echten Schlüssel. Niemand sonst bekommt ihn in die .env, nicht in CI und nicht im Chat. Apps und Menschen sprechen nur mit Virtual Keys. Kündigt jemand, bleibt der Provider-Key unberührt.

2

Rollen setzen

proxy_admin steuert Teams. internal_user erzeugt eigene Keys. Service-Account-Keys hängen nicht an einer Person. Das steht in den Access-Control-Docs. Ohne diese Rollen bleibt generate ein Admin-Ticket.

3

Budget und Modelle

max_budget, budget_duration und models am Key. Default null heißt: kein Cap, bis Sie ihn setzen. Nach dem Cap schlagen Requests fehl. Die Modellliste ist die Freigabe, nicht der Provider-Katalog.

4

Portal oder Shop

Optional vor der UI: Antrag, Gruppe, Datenklasse. Danach generate in LiteLLM. Ohne Portal bleibt die UI der Shop. Gruppenrechte sitzen im IdP, nicht in einer Excel-Liste neben dem Gateway.

5

Was User sieht

Eigenen Key, erlaubte Modelle, Restbudget, Ablauf. Nicht den Provider-Key, nicht fremde Spend-Tabellen, nicht Master-Key. Das ist der Self-Service, den Entwickler fordern, ohne Key-pro.

6

Was Platform sieht

Alle Keys, Spend, Rotation, Modelllisten. Die Tiefe des Setups steht in der LiteLLM-Implementierung.

Erfahren Sie mehr über LiteLLM-Implementierung

Wer Keys vergibt: Inhouse, Hyperscaler, Pexon

Inhouse-Platform

-Kennt das Gateway, vergibt Keys oft noch per Ticket und Chat.

-Provider-Keys landen in Repos, sobald der Druck steigt.

-max_budget bleibt null, weil niemand den Default gelesen hat.

Hyperscaler-Consulting

-Richtet den Provider-Key in der Cloud ein, nicht den Self-Service am Gateway.

-Interesse am Verbrauch, nicht am internen Shop.

-Kein 8x5-Betrieb für Ihre LiteLLM-UI.

Mit Pexon

✓Service-User, Virtual Keys, Portal, Budgets in einem Setup.

✓LiteLLM API-Key und Virtual Keys unter dem Hub, nicht als zweiter Head-Term.

✓Plattform-Check 45 Min, Paket Setup, Betrieb 8x5. Endpreis nach Scoping.

Wie die Provisionierung in vier Phasen sitzt

45 Min

Plattform-Check

Wer Keys fordert, wo Provider-Keys liegen, ob Postgres und SSO schon laufen.

Phase 2

Service-User

Provider-Key einsperren, Master-Key sk-, Rollen proxy_admin und internal_user.

Phase 3

Budgets und Portal

max_budget, duration, Modelllisten, optional interner Shop vor der UI.

Phase 4

Übergabe

User sieht Key und Cap. Platform sieht Spend. Betrieb 8x5.

Virtual Keys vs. Provider-Keys

Der LiteLLM API-Key, den der Mensch sieht, ist ein Virtual Key. Den Provider-Key hält das Gateway. Quelle: LiteLLM Virtual Keys Dokumentation. Sharing, fehlende Budgets und Shadow-Keys entstehen, wenn dieser Schnitt fehlt. Self-Service ändert das nur, wenn max_budget gesetzt ist und Postgres läuft.

Kriterium	Provider-Key pro Person	LiteLLM Virtual Key
Wer hält den Schlüssel	OpenAI-, Azure- oder Anthropic-Key beim Menschen	Gateway-Key; Provider-Key nur beim Service-User
Budget	Kein nativer Cap am persönlichen Key	max_budget und budget_duration, Default null
Modellzugriff	Alles, was der Provider-Key darf	models-Liste am Key
Rotation	Jeder tauscht den Provider-Key	duration plus UI generate und delete
Self-Service	Ticket an Platform	internal_user erzeugt eigene Keys
Audit	Unklar, wer welchen Call ausgelöst hat	Spend in LiteLLM_VerificationTokenTable

Was der Key-Self-Service im Plattform-Setup enthält

Key-Provisionierung ist Teil des Pakets Setup, nicht ein isolierter Festpreis. Der Plattform-Check klärt Service-User, Portal und Budgets. Endpreis nach Scoping, wenn SSO, Team-Limits und Datenklassen dazukommen. Betrieb danach 8x5.

Ihre Investition

Paket Setup nach Scoping

Teil des Plattform-Setups · Endpreis nach Scoping

Enthält:

Enthalten · Service-User, Virtual-Key-Pfad, Rollen, Budget-Default, Übergabe an Platform.

Einstieg · Plattform-Check buchen (45 Min), bevor SSO und Shop gebaut werden.

Nicht enthalten · Spend-Dashboards, Provider-Rechnung, 24-Stunden-Betrieb. Betrieb ist 8x5. Open-WebUI-Spend ist eine spätere Seite.

Plattform-Check buchen (45 Min)

Plattform-Check, 45 Minuten, ohne Verpflichtung

Nächste Schritte im LiteLLM-Silo

Cluster-Hub

LiteLLM

Zum Überblick

Setup

LiteLLM-Implementierung

Use-Case ansehen

Plattform

Open-Source-KI-Plattform

Use-Case ansehen

Mini-FAQ zu LiteLLM Virtual Keys

Was sind LiteLLM Virtual Keys im Unternehmen?

LiteLLM Virtual Keys sind Gateway-Tokens, keine Provider-Keys. Mitarbeiter erzeugen sie selbst, sobald Rollen und Team-Rechte das erlauben. Budget, Modell und Ablauf sitzen am Key. Den OpenAI- oder Azure-Schlüssel hält ein Service-User. Pexon Consulting richtet den Pfad im Paket Setup ein, nach einem Plattform-Check von 45 Minuten. Stand 31. August 2026.

Braucht jeder Entwickler einen eigenen OpenAI-Key?

Nein. Das ist Key-pro und kippt bei Sharing, fehlendem Budget und Shadow-Keys. Der LiteLLM API-Key, den der Mensch sieht, ist ein Virtual Key. Provider-Keys bleiben hinter dem Gateway. Ohne Postgres gibt es diesen Schnitt nicht. Pexon Consulting hängt den echten Schlüssel an einen Service-User.

Was kostet LiteLLM-Key-Provisionierung bei Pexon Consulting?

Die Provisionierung ist Teil des Pakets Setup, nicht ein isolierter Festpreis. Der Plattform-Check dauert 45 Minuten und klärt Service-User, Portal und Budgets. Den Endpreis nennt Pexon Consulting nach Scoping, wenn SSO, Datenklassen und Team-Limits festliegen. Betrieb läuft 8x5.

Was sieht der User, was nur Platform?

User sieht den eigenen Key, erlaubte Modelle, Restbudget und Ablaufdatum. Platform sieht alle Tokens, Spend in LiteLLM_VerificationTokenTable, Rotation und Modelllisten. Service-Account-Keys haben user_id null. Fremde Keys und den Provider-Schlüssel sieht der User nicht.

Wo greifen Virtual Keys nicht?

Ohne Postgres keine Virtual Keys. max_budget default null heißt: ohne Cap kein Spend-Stopp. Diese Seite ist nicht Spend-Tracking. Wer nur einen Provider-Key in .env will, braucht keinen Self-Service. Kein 24-Stunden-Betrieb, keine erfundenen Festpreise.

Wie hängt das am LiteLLM-Hub?

Der Head-Term LiteLLM bleibt auf dem LiteLLM-Hub. Diese Seite hängt api key und virtual keys darunter. Die Setup-Tiefe steht in der LiteLLM-Implementierung. Teil der Open-Source-KI-Plattform, nicht unter einem zweiten LiteLLM-Pfad.

Keys ohne Key-pro prüfen

Sobald das erste Team denselben Provider-Key teilt, ist Self-Service überfällig. 45 Minuten Plattform-Check: Service-User, Budget, Portal.

Plattform-Check buchen (45 Min)

Nachricht senden

Kein passender Termin? Schreiben Sie uns, wir melden uns innerhalb von 24 Stunden.

Antwort innerhalb von 24 Stunden

Unverbindliches Erstgespräch

Persönlicher Ansprechpartner

Phillip Pham

CEO @ Pexon Consulting

Aktualisiert am 31. August 2026

Sie suchen einen Partner für Ihr Projekt?

Wir analysieren Ihren individuellen Bedarf, geben erste Empfehlungen zu Umsetzungsstrategien und bieten Ihnen transparente Einblicke in unsere Methoden, Technologien und Referenzen.

Vertrieb kontaktieren

400+Projekte seit 2020

100+Kunden im DACH-Raum

ISO27001 zertifiziert

3Hyperscaler Partner