BYOK vs. Managed LLM Keys: KI-Features richtig bepreisen

Rechnen Sie LLM-Kosten standardmäßig in Ihren Abo-Preis ein (Managed Keys) und bieten Sie Bring Your Own Key (BYOK) als optionales Upgrade für Enterprise-Accounts an, die bereits eigene Modellverträge oder Compliance-Vorgaben mitbringen. Der falsche Standard vernichtet entweder Ihre Marge im großen Maßstab oder erzeugt so viel Setup-Aufwand, dass Ihre Self-Serve-Conversion einbricht.

Diese Entscheidung stellt sich, sobald Sie ein LLM-gestütztes Feature in ein SaaS-Produkt einbauen: ein Chat-Assistent, eine KI-Suche, ein Agent, der E-Mails entwirft. Irgendjemand zahlt die Tokens, und irgendjemand hält den API-Key. Liegen Sie falsch, fressen unvorhersehbare Inferenzkosten Ihre Marge auf, sobald das Produkt viral geht – oder Sie zwingen jeden Testnutzer, zuerst einen OpenAI-Account einzurichten, bevor er überhaupt einen Mehrwert sieht.

Die zwei Modelle, klar erklärt

Managed Keys: Ihr Backend hält einen (oder wenige) API-Keys, ruft das LLM für alle Mandanten auf, und Sie kalkulieren die Tokenkosten in den Abopreis ein. Der Kunde sieht weder einen Key noch einen Anbieternamen.

BYOK: Der Kunde erstellt seinen eigenen API-Key bei Anthropic, OpenAI oder Azure, fügt ihn in Ihre Einstellungsseite ein, und Ihre App nutzt seinen Key und seine Abrechnungsbeziehung. Sie stellen Software und Workflow in Rechnung, nicht die Inferenz.

Die meisten Produkte setzen auf Managed Keys, weil das Onboarding-Erlebnis besser ist. Niemand möchte mitten im Anmeldeprozess abbrechen, um woanders einen Account einzurichten, bevor er Ihr Produkt überhaupt ausprobieren kann. Managed Pricing bedeutet aber, dass Ihre Bruttomarge mit Tokenpreisen und Nutzungsmustern schwankt, die Sie nicht vollständig kontrollieren – genau die Problemkonstellation aus multi-llm-provider-failover: Eine Preisanpassung oder ein Ausfall eines einzelnen Anbieters wird zu Ihrem Problem, nicht zu einem Posten, den Sie weitergeben können.

Warum das eine Pricing-Entscheidung ist, nicht nur eine Architektur-Entscheidung

Teams behandeln BYOK oft als technischen Schalter: ein Einstellungsfeld hinzufügen, Key speichern, fertig. Tatsächlich handelt es sich um eine Pricing- und Packaging-Entscheidung, die Ihre Unit Economics bestimmt.

Bei Managed Keys nagt jeder Vielnutzer an Ihrer Marge. Ein Kunde, der im Monat 50.000 Completions auf Ihrem 99 $/Monat-Plan generiert, wird von den Kunden mit 500 Completions quersubventioniert. Im kleinen Maßstab funktioniert das – aber es bricht zusammen, sobald sich nutzungsintensive Kunden auf Ihrem günstigsten Tier häufen. Das ist eine Variante der gleichen Falle, die in saas-pricing-models beschrieben wird: Flat-Pricing funktioniert, bis die Nutzungsvariance groß genug wird, um Ihre besten Kunden oder Ihre Marge zu bestrafen.

Bei BYOK ist Ihre Marge geschützt, weil der Kunde direkt beim LLM-Anbieter zahlt. Dafür haben Sie nun Reibung für jeden Nutzer erzeugt und sich einen Support-Berg aufgebaut: abgelaufene Keys, Rate Limits, falsche Modell-Zugangsstufen und verunsicherte Kunden, die debuggen, warum „Ihr Produkt" einen Fehler zurückgibt, der eigentlich ein Problem mit deren Provider-Account ist.

Die Kostenrechnung, die Sie vor der Entscheidung machen sollten

Messen Sie den tatsächlichen Token-Verbrauch pro Feature – nicht eine Schätzung aus einer einzelnen Demo-Session. Loggen Sie Input- und Output-Tokens pro Request in der Staging-Umgebung, nutzen Sie echte Prompts und erwartete Output-Längen, und multiplizieren Sie das mit der prognostizierten Zahl monatlich aktiver Nutzer pro Preistier. Die Diskrepanz zwischen „was wir angenommen haben" und „wie die echte Nutzung aussieht" beträgt typischerweise das 3- bis 5-Fache – besonders bei agentischen Features, die pro Nutzeraktion mehrere Tool-Calls ausführen.

Hier ist die Call-Architektur genauso wichtig wie das Preismodell. In unserem eigenen Outreach-Tool haben wir die Lead-Qualifizierung ursprünglich auf separate Calls aufgeteilt: einer, um Unternehmensdaten von einer gescrapten Seite zu extrahieren, ein weiterer, um die E-Mail zu verfassen. Dieses Vorgehen in einen einzigen Call zusammenzuführen – der die Daten extrahiert und die E-Mail in einem Schritt entwirft – hat den Tokenverbrauch spürbar gesenkt und die Ausgabequalität sogar verbessert, weil das Modell den vollen Kontext in einem Durchgang hatte, anstatt ihn bei einem Übergabepunkt zu verlieren. Wenn Sie Managed Keys betreiben, ist diese Art der Konsolidierung der Unterschied zwischen einem Feature, das bei 49 $/Monat profitabel ist, und einem, das es nicht ist. Es lohnt sich, das Audit aus llm-cost-optimization durchzuführen, bevor Sie sich für ein Preismodell entscheiden – denn ein chain-lastiges Feature macht Managed Pricing deutlich schwerer tragfähig und macht BYOK-Reibung deutlich schwerer rechtfertigbar.

Wann BYOK der richtige Standard ist

Betrachten Sie den Kunden mit 50.000 Completions pro Monat aus dem Margenbeispiel oben durch die BYOK-Brille: Bei Managed Keys wird er von Ihren Kunden mit 500 Completions quersubventioniert; bei BYOK geht seine Tokenrechnung direkt an seinen eigenen OpenAI- oder Anthropic-Account und hört auf, Ihr Problem zu sein. Das ist das Muster, auf das Sie achten sollten – keine Checkliste, die Sie blind abarbeiten. BYOK ist tendenziell die richtige Wahl, wenn:

• Ihre Kunden Unternehmen sind, die bereits ausgehandelte LLM-Verträge haben (Mengenrabatte, Datenschutzvereinbarungen zum Speicherort oder einen bestimmten Anbieter, der durch ihr eigenes Compliance-Team vorgeschrieben wird)
• Die Nutzung inhärent volumenintensiv und sprunghaft ist – etwa bei einem Coding-Assistenten oder einem Massen-Dokumentenprozessor – wo Pro-Seat-Pricing die Varianz nicht auffangen kann, so wie es beim 99 $/Monat-Tier oben gescheitert ist
• Das Sicherheitsteam des Käufers verlangt, dass kein Dritter (einschließlich Ihrer selbst) Zugriff auf Prompts oder Outputs hat – das ist in Gesundheits- und Rechtsverticals üblich
• Sie ein Developer-Tool verkaufen, bei dem die Zielgruppe API-Keys bereits als Teil ihres normalen Workflows verwaltet

Wann Managed Keys der richtige Standard sind

Managed Keys sind genau für das Profil am sinnvollsten, das unser Outreach-Tool-Beispiel beschreibt: ein Feature, bei dem Sie das Call-Pattern eng genug kontrollieren, dass das Zusammenführen von zwei Calls in einen Ihr Hebel zum Margenschutz ist – anstatt diese Kosten auf den Kunden abzuwälzen. Das funktioniert nur, wenn Sie derjenige sind, der den Key und die Rechnung hält. Managed Keys sind tendenziell die richtige Wahl, wenn:

• Sie an nicht-technische Käufer verkaufen, die selbst nie einen API-Key generieren werden
• Der Verbrauch pro Kunde vorhersehbar genug ist, um ihn in Flat- oder gestaffelte Pläne einzupreisen – so wie ein 49-oder-99-Dollar-Monatstier es voraussetzt
• Time-to-Value wichtiger ist als Margenschutz – was vor dem Product-Market-Fit fast immer gilt
• Das KI-Feature ein Teil eines größeren Produkts ist, nicht das ganze Produkt, sodass die Tokenkosten nur ein kleiner Anteil Ihrer gesamten COGS sind

Der hybride Ansatz, auf den die meisten reifen Produkte zusteuern

Starten Sie mit Managed Keys für Self-Serve- und untere Tiers, wo Onboarding-Reibung das größere Risiko ist als Margenschutz. Fügen Sie BYOK als Enterprise-Tier-Option hinzu, sobald Kunden danach fragen – das sind meist dieselben Kunden, die auch SSO, Audit-Logs und einen unterzeichneten DPA benötigen. Das spiegelt wider, wie die meisten Entscheidungen zur multi-tenant-saas-architecture generell getroffen werden: Bauen Sie zuerst den einfachen Standard, ergänzen Sie den konfigurierbaren Pfad nur, wenn ein echtes Kundensegment ihn benötigt, und halten Sie beide Pfade hinter demselben Feature-Interface – damit das Umschalten eines Mandanten von Managed auf BYOK kein Rewrite erfordert.

Egal für welchen Standard Sie sich entscheiden: Hardcoden Sie ihn nicht. Speichern Sie die Key-Quelle (Managed vs. mandantenbereitgestellt) vom ersten Tag an als mandantenspezifischen Konfigurationswert – auch wenn zunächst alle Mandanten auf Managed starten. BYOK nachträglich in eine Codebase zu integrieren, die einen einzigen globalen API-Key vorausgesetzt hat, ist aufwendiger als es klingt. Es ist genau die Art technischer Schulden, die in technical-debt-management beschrieben wird: günstig zu vermeiden, wenn man es früh tut – und teuer zu beheben, wenn man es nicht tut.

Wenn Sie ein KI-Feature planen und sich nicht sicher sind, welches Modell zu Ihrer Kundenbasis und Ihren Margenzielen passt, sprechen Sie uns an.