Kimi K3 Open-Source-Lizenz: Welche Kosten entstehen?

Stand: 01.08.2026. Die Angaben wurden anhand der offiziellen Kimi-K3-Dokumentation, des Hugging-Face-Modellrepositoriums und des veröffentlichten Lizenztexts geprüft.

Das offizielle Kimi-K3-Modell umfasst laut Kimi-K3-Kurzdokumentation 2,8 Billionen Parameter. Dieser Datenpunkt beantwortet die Kostenfrage noch nicht, zeigt aber die Richtung: Offene Gewichte machen Selbsthosting möglich, nicht automatisch günstig oder rechtlich unkompliziert. Gewinner ist die begrenzte Selbsthosting-Variante für interne Entwicklung und kontrollierte Produktfunktionen. Für externe Modelldienste oder Unternehmen nahe den Lizenzschwellen bleibt die Kimi K3 API zunächst die bessere Baseline, bis die Rechtsabteilung die konkrete Nutzung geprüft hat.

Diese Entscheidungshilfe richtet sich an:

• AI-Plattformverantwortliche, die interne Agenten, eingebettete Produktfunktionen und externe Modellzugänge trennen müssen.
• Rechts- und Sicherheitsteams, die Lizenzhinweise, Datenschutz, Zugriffskontrollen und Auditnachweise planen.
• Technische Einkäufer, die nicht nur Token- und Rechenkosten, sondern auch laufende Compliance-Arbeit vergleichen.

Der Beitrag ordnet die Lizenz technisch ein und ersetzt keine Rechtsberatung.

Die Kimi K3 Open-Source-Lizenz bewertet den Zugriff, nicht nur den Besitz der Gewichte

Der offizielle Lizenztext für Kimi K3 erlaubt grundsätzlich das Nutzen, Kopieren, Ändern, Weitergeben, Unterlizenzieren und Verkaufen des Softwarepakets unter den dort genannten Bedingungen. Zum Paket gehören nach dem Lizenztext unter anderem Modellgewichte, Parameter, Konfigurationsdateien, Inferenz- und Trainingscode sowie Dokumentation.

Die praktische Einordnung darf deshalb nicht mit dem Satz „kommerzielle Nutzung ist erlaubt“ enden. Entscheidend sind mehrere Fragen:

1. Wer erhält Zugriff auf Modell und Outputs?
2. Kann ein Dritter Eingaben, Parameter oder Trainingsdaten sinnvoll steuern?
3. Ist Kimi K3 nur Bestandteil einer konkreten Produktfunktion?
4. Oder wird eine allgemeine Modellfähigkeit angeboten?
5. Wird das Modell ausschließlich intern verwendet?
6. Werden Umsatz- oder Nutzergrenzen aus der Lizenz erreicht?

Die Lizenz unterscheidet zwischen einer eingebetteten Funktion und einem Model-as-a-Service-Angebot. Als Model as a Service wird ein Zugang beschrieben, bei dem ein Dritter sinnvoll auf Eingaben, Parameter oder Trainingsdaten einwirken kann. Eine Anwendung, die lediglich eine feste Funktion bereitstellt, ist daher nicht automatisch gleich zu behandeln wie eine frei konfigurierbare Modell-API.

Die zentrale Trennlinie lautet somit nicht einfach „API gegen Server“. Maßgeblich ist, wie viel Kontrolle ein externer Nutzer über die Modellfähigkeit erhält.

Drei Nutzungsszenarien verändern den Lizenzaufwand

Nutzungsszenario	Typischer Zugriff	Lizenzrisiko	Zusätzliche Kostenpositionen
Interne Agenten und Experimente	Nur Mitarbeitende und interne Systeme	Niedriger, sofern kein Drittzugriff besteht	Lizenzablage, Rechtekonzept, Datenfreigabe, Versionsprüfung
Eingebettete Produktfunktion	Kunden nutzen eine konkrete Funktion, aber kein allgemeines Modell	Mittel, abhängig von Produktdesign und Kontrollmöglichkeiten	Produktanalyse, Hinweise, Datenschutzprüfung, Regressionstests
Externe Modell-API	Kunden steuern Prompts, Parameter oder Trainingsdaten	Hoch	Vertragsprüfung, Schwellenwertüberwachung, Audit, Zugriffsschutz

Diese Tabelle ist ein technisches Vorsortierungswerkzeug. Sie ersetzt keine Prüfung durch eine qualifizierte Rechtsabteilung. Sie verhindert jedoch einen häufigen Fehler: Ein Team klassifiziert die Anwendung einmal als „intern“ und behält diese Einordnung bei, obwohl später Kunden, Partner oder externe Entwickler Zugriff auf Modelloutputs oder Modellfunktionen erhalten.

Interne Nutzung bleibt die kostengünstigste Lizenzklasse, aber nicht kostenfrei

Die Lizenz nimmt interne Nutzung von den besonderen Regeln zu Model as a Service und großskaligen kommerziellen Produkten aus, sofern Modell, Outputs und zugrunde liegende Fähigkeiten nicht Dritten zugänglich gemacht werden. Das passt typischerweise zu:

• einem internen Coding-Agenten,
• einer firmeninternen Wissenssuche,
• Experimenten mit nichtöffentlichen Dokumenten,
• automatisierter Codeanalyse innerhalb einer geschützten Entwicklungsumgebung.

„Intern“ muss technisch belegbar sein. Ein öffentlich erreichbarer Endpunkt mit einer angeblich internen Zielgruppe ist kein belastbarer Nachweis. Auch ein interner Agent kann neu bewertet werden müssen, wenn er Kundeninhalte verarbeitet und seine Antworten anschließend in einem externen Produkt erscheinen.

Die Lizenzkosten liegen in diesem Szenario meist nicht bei einer zusätzlichen Nutzungsgebühr. Sie entstehen durch die interne Organisation:

• Speicherung des Lizenztexts und der verwendeten Repository-Version,
• Freigabeprozess für Modellgewichte und abgeleitete Dateien,
• Rollen für Entwickler, Administratoren und Sicherheitsprüfer,
• Protokollierung des Zugriffs auf Gewichte und Inferenzendpunkte,
• Prüfung, ob vertrauliche Daten in Trainings- oder Evaluationspipelines gelangen,
• Dokumentation der Modellversion bei jedem Upgrade.

Für DSGVO-relevante Daten kommt eine separate Prüfung hinzu. Die Kimi K3 Open-Source-Lizenz kann interne Nutzung erlauben, beantwortet aber nicht die Fragen nach Zweckbindung, Löschung, Auftragsverarbeitung, Zugriff und Speicherort personenbezogener Daten. Die Datenschutzinformationen von ProxyMac können als organisatorischer Ausgangspunkt dienen; die eigentliche Bewertung muss projektspezifisch erfolgen.

Typischer interner Fall

Ein Unternehmen baut einen Agenten, der interne Git-Repositories durchsucht und Quellcode kommentiert. Der Dienst ist nur über das Unternehmensnetz erreichbar. Mitarbeitende erhalten Antworten, Kunden nicht. In diesem Fall spricht viel für eine interne Nutzung.

Die Entscheidung bleibt trotzdem nur dann stabil, wenn:

• externe Supportmitarbeiter keinen unkontrollierten Zugang erhalten,
• die Wissensbasis nicht versehentlich öffentlich gemacht wird,
• Agentenlogs keine unnötigen personenbezogenen Daten speichern,
• Modellgewichte und Zugangsdaten getrennt verwaltet werden,
• der Dienst nicht später als Kundenfunktion weiterverwendet wird.

Die technische Architektur ist damit zugleich ein Lizenznachweis. Netzwerkregeln, Identitätsrollen und Protokolle sind nicht nur Sicherheitsmaßnahmen, sondern Belege für die gewählte Nutzungskategorie.

Eingebettete Produktfunktionen stehen zwischen API und interner Nutzung

Eine Kundenfunktion wie „Verträge zusammenfassen“ oder „Fehler im Quellcode erklären“ ist nicht automatisch ein Model-as-a-Service-Angebot. Die Lizenz unterscheidet zwischen einer konkreten, eingebetteten Funktion und einem Zugang, der Dritten eine sinnvolle Kontrolle über das Modell ermöglicht.

Für die Bewertung sollten Produktteams den tatsächlichen Ablauf dokumentieren:

1. Welche Eingaben kann der Kunde frei senden?
2. Kann der Kunde Systemanweisungen oder Modellparameter ändern?
3. Werden Trainingsdaten, Adapter oder Werkzeuge vom Kunden gewählt?
4. Gibt es eine feste Geschäftsfunktion oder einen allgemeinen Chat-Endpunkt?
5. Werden Modellname und Lizenzhinweise angezeigt oder dokumentiert?
6. Kann ein Kunde die Modellfähigkeit für beliebige Aufgaben verwenden?

Ein festes Formular mit begrenzten Feldern ist anders zu bewerten als eine frei konfigurierbare Entwickler-API. Ein Support-Assistent mit vorgegebenem Wissensbestand ist anders zu bewerten als ein Dienst, bei dem Kunden eigene Trainingsdaten hochladen und Inferenzparameter kontrollieren.

Produktänderungen können die Einordnung verschieben

Die Lizenzklassifizierung ist kein einmaliger Projektstatus. Eine kleine Produktänderung kann eine neue Prüfung auslösen. Wird aus einer Zusammenfassungsfunktion später ein frei konfigurierbarer Agent, ändern sich möglicherweise:

• der Umfang der Kundeneingaben,
• die Kontrolle über Systemanweisungen,
• die Verwendung eigener Dateien,
• die Modelltransparenz,
• die Anforderungen an Zugriffsschutz und Protokollierung.

Deshalb sollte die Produktfreigabe mit einer kurzen Architekturzeichnung verbunden werden. Sie muss zeigen, welche Daten vom Kunden kommen, welche Anweisungen intern bleiben und welche Modellfunktionen nach außen sichtbar sind.

Die Zusatzkosten liegen häufig in:

• technischer Analyse der Kontrollmöglichkeiten,
• Anpassung von Rollen und API-Rechten,
• Anzeige oder Dokumentation des Modellnamens,
• Prüfung von Nutzungsbedingungen und Kundenhinweisen,
• Tests nach Modell- oder Produktupdates,
• Nachweis, welche Modellversion zu welchem Zeitpunkt aktiv war.

Der Aufwand kann bei einer kleinen Funktion überschaubar bleiben. Er steigt deutlich, wenn das Produkt mehrere Mandanten, frei definierbare Agenten, Uploads und eigene Werkzeuge unterstützt.

Externe Modell-APIs machen Schwellenwerte zu einer Controlling-Aufgabe

Der vollständige Lizenztext als überprüfbare Repository-Datei nennt für ein Model-as-a-Service-Geschäft eine Umsatzschwelle von mehr als 20 Millionen US-Dollar beziehungsweise dem Gegenwert in anderen Währungen über einen beliebigen zusammenhängenden Zeitraum von 12 Monaten. Wenn der Lizenznehmer oder verbundene Unternehmen diese Grenze überschreiten, ist vor einer kommerziellen Nutzung der Software oder abgeleiteter Werke eine separate Vereinbarung mit Moonshot AI erforderlich. Diese Angabe sollte direkt aus der jeweils aktuellen Lizenzversion geprüft werden.

Für kommerzielle Produkte oder Dienste nennt der Lizenztext außerdem:

• mehr als 100 Millionen monatlich aktive Nutzer, oder
• mehr als 20 Millionen US-Dollar monatlicher Umsatz.

Wird eine dieser Grenzen erreicht, muss „Kimi K3“ laut Lizenz prominent auf der Benutzeroberfläche des betreffenden Produkts oder Dienstes angezeigt werden.

Diese Regeln dürfen nicht zu zwei gegensätzlichen Vereinfachungen führen:

• „Kimi K3 darf nicht kommerziell genutzt werden.“
• „Kimi K3 ist ohne weitere Bedingungen frei kommerziell nutzbar.“

Beide Aussagen sind zu ungenau. Die konkrete Verpflichtung hängt von Geschäftsmodell, Zugriffskontrolle, verbundenen Unternehmen und erreichtem Maßstab ab.

Für eine eigene Modell-API gehören deshalb folgende Aufgaben in das Betriebsmodell:

• Erfassung der Umsätze relevanter verbundener Unternehmen,
• Definition eines Verantwortlichen für die Schwellenwertüberwachung,
• Prüfung, ob Kunden Eingaben, Parameter oder Trainingsdaten kontrollieren,
• Pflege eines Lizenznachweises für jedes eingesetzte Modellartefakt,
• technische Umsetzung erforderlicher Modellhinweise,
• revisionsfähige Protokolle über Releases und Konfigurationsänderungen,
• Abstimmung zwischen Einkauf, Recht, Sicherheit, Produkt und Finanzen.

Kimi K3 API und Selbsthosting haben verschiedene Kostenprofile

Die offizielle Preisdokumentation der Kimi K3 API beschreibt eine Abrechnung pro 1 Million Tokens und weist darauf hin, dass Steuern abhängig vom jeweiligen Rechtsgebiet berechnet werden. Für den Vergleich mit Selbsthosting reicht die Tokenabrechnung jedoch nicht aus.

Kosten- und Risikofaktor	Kimi K3 API	Begrenztes Selbsthosting	Eigene externe Modell-API
Modellbetrieb	Beim Anbieter	Eigenverantwortlich	Eigenverantwortlich mit Bereitschaftsbetrieb
Lizenzprüfung	Nutzungs- und Vertragsprüfung	Prüfung von Gewichten, Änderungen und Weitergabe	Laufende Geschäftsmodell- und Schwellenwertprüfung
Zugriffskontrolle	API-Schlüssel und Organisationsrechte	Netzwerk, Identitäten, Secrets und Endpunkte	Mandantenfähige Rechte und Missbrauchsschutz
Datenschutz	Anbieter- und Datenflussprüfung	Eigene Daten- und Speicherarchitektur	Zusätzlich Kunden-, Mandanten- und Löschprozesse
Änderungsaufwand	API- und Modelländerungen beobachten	Updates, Rollbacks und Kompatibilität	Produkt-, UI-, Vertrags- und Betriebsänderungen
Geeignet für	Interne Nutzung und wechselnde Last	Kontrollierte PoCs und sensible Daten	Nur nach belastbarer Rechts- und Betriebsprüfung

Die API ist meist die bessere Ausgangsbasis, wenn:

• interne Aufgaben unregelmäßig auftreten,
• das Team keine eigene Inferenzplattform betreiben möchte,
• eine Anwendung schnell validiert werden soll,
• Kunden keinen frei steuerbaren Modellzugang erhalten,
• Datenfluss und Auftragsverarbeitung geprüft sind.

Selbsthosting gewinnt an Gewicht, wenn:

• sensible Daten nicht an einen externen Modellendpunkt übertragen werden sollen,
• Netzwerkzugriff, Protokollierung und Löschung vollständig kontrolliert werden müssen,
• eine begrenzte interne Anwendung über längere Zeit stabil betrieben wird,
• das Unternehmen eigene Inferenz- und Sicherheitskompetenz besitzt,
• ein PoC die technische Notwendigkeit tatsächlich nachweist.

Offene Gewichte bringen Speicher-, Betriebs- und Wiederanlaufkosten

Das offizielle Kimi-K3-Modellrepositorium auf Hugging Face weist aktuell eine Repository-Größe von 1,56 TB aus. Diese Angabe ist kein fertiger Produktionskostenwert. Sie zeigt jedoch, dass Speicher, Transfer, Replikation, Sicherung und Versionswechsel eigene Budgetposten bilden.

Für die Infrastrukturplanung sollten Verantwortliche mindestens erfassen:

• Speicher für Gewichte, Zwischenstände und Backups,
• Übertragungskosten beim Erstimport und bei Updates,
• Beschleunigerkapazität,
• Strom, Kühlung und Bereitschaftsbetrieb,
• Monitoring, Alarmierung und Bereitschaftsdienst,
• Sicherheitsupdates für Laufzeit, Treiber und Serving-Stack,
• Wiederanlauf und Rollback bei inkompatiblen Modellversionen.

Die offizielle Modellkarte nennt Integrationspfade wie Transformers, vLLM und SGLang. Das belegt verfügbare Softwarewege, nicht aber eine bestimmte Produktionsleistung, Latenz oder Hardwarekosten. Community-Angaben zu benötigten Beschleunigern und erzieltem Durchsatz sind daher nicht-offizielle Erfahrungswerte. Sie dürfen nicht als feste Beschaffungszusage verwendet werden.

Für Unternehmen ist diese Abgrenzung wichtig. Ein technischer Prototyp kann mit einer bestimmten Konfiguration funktionieren, während ein produktiver Dienst zusätzliche Replikate, Lastreserven, Überwachung und Notfallkapazität benötigt. Ohne belastbare Messung bleiben Aussagen über Durchsatz oder Amortisation Annahmen.

Ein Lizenz-PoC beginnt mit fünf kontrollierbaren Schritten

Ein PoC sollte nicht mit dem Download der Gewichte beginnen. Ein belastbarer Ablauf sieht so aus:

1. Nutzungsszenario schriftlich klassifizieren

Das Team beschreibt, ob Kimi K3 intern, als konkrete Produktfunktion oder als allgemeiner Modellzugang eingesetzt wird. Zusätzlich wird festgehalten, wer Outputs erhält und wer Eingaben, Parameter oder Trainingsdaten kontrolliert.

2. Lizenzstand und Modellversion sichern

Der Lizenztext, die Modellkarte und die verwendete Repository-Revision werden archiviert. Für die Prüfung zählt der tatsächlich eingesetzte Stand. Ein späterer Suchmaschinenausschnitt ist kein ausreichender Nachweis.

3. Datenfluss und Berechtigungen prüfen

Sicherheitsverantwortliche dokumentieren, welche Daten den Inferenzendpunkt erreichen, welche Logs gespeichert werden und wer Zugriff auf Gewichte, Adapter und Prompts besitzt. Personenbezogene Daten müssen in den DSGVO-Prozess einbezogen werden.

4. Produktgrenzen technisch testen

Mit realen Rollen wird geprüft, ob externe Nutzer allgemeine Modellfähigkeiten erhalten. Auf die Testliste gehören frei veränderbare Systemanweisungen, Parameterwahl, Datei-Uploads, Tool-Freigaben und Trainingsdatenkontrolle.

5. Schwellenwert- und Nachweisprozess einrichten

Umsatz- und Nutzergrenzen dürfen nicht erst beim Vertragsgespräch geprüft werden. Finanzen und Produkt definieren regelmäßige Kontrollen. Recht und Sicherheit halten fest, welche Hinweise, Vereinbarungen und Freigaben bei einer Überschreitung erforderlich wären.

Für temporäre Tests ist ein getrenntes Kontrollsystem sinnvoll. Ein Mac kann als Entwicklungs-, Test- und Administrationsarbeitsplatz dienen. Er ist jedoch nicht automatisch die Rechenplattform für vollständige Kimi-K3-Produktionsgewichte. Eine solche Trennung verhindert, dass Zugangsdaten, Modellartefakte und Kundendaten unkontrolliert auf einem Entwicklergerät zusammenlaufen.

Bei einem begrenzten Test kann ein gemieteter Mac als kontrollierter Zugriffspunkt für SSH, VPN, Versionsverwaltung, Monitoring und Freigaben eingesetzt werden. Die Gewichteschicht bleibt auf geeigneter Remote-Infrastruktur. Für Zugangskonfiguration und Kontosicherheit können technische Verantwortliche die ProxyMac-Hilfe mit den eigenen Unternehmensrichtlinien abgleichen.

Die Entscheidung sollte nach Nutzungsszenario fallen

Die folgende Zuordnung eignet sich für eine erste Beschaffungsempfehlung:

• Nur interne Agenten: API als Baseline beibehalten. Selbsthosting erst vertiefen, wenn Datenhoheit, Kosten oder Netzwerkanforderungen den Zusatzaufwand rechtfertigen.
• Konkrete eingebettete Produktfunktion: Einen begrenzten Selbsthosting-PoC prüfen. Produktfluss, Kundenrechte und Modellkontrolle müssen dokumentiert werden.
• Sensible Unternehmensdaten: Selbsthosting kann technisch sinnvoll sein. Datenschutz, Zugriffsschutz und Betriebskosten müssen aber vor der Umstellung geklärt werden.
• Allgemeine externe Modell-API: Lizenzprüfung und Vertragsklärung vor einer breiten Einführung durchführen.
• Nähe zu Umsatz- oder Nutzergrenzen: Die API-Baseline nicht abschalten. Verbundene Unternehmen, historische Zeiträume und UI-Pflichten gemeinsam bewerten.
• Kein dauerhafter Inferenzbetrieb im Team: Keine langfristige Infrastruktur kaufen, bevor ein rückbaubarer PoC die Notwendigkeit bestätigt.

Die Kimi K3 Open-Source-Lizenz kann für Unternehmen attraktiv sein, weil sie weitreichende Nutzungsrechte einräumt. Der wirtschaftliche Vorteil entsteht aber nur, wenn die Organisation auch Speicher, Inferenzbetrieb, Sicherheitskontrollen, Lizenznachweise und Produktänderungen tragen kann.

FAQ zur Kimi-K3-Lizenz

Darf ein Unternehmen Kimi K3 kommerziell einsetzen?

Grundsätzlich erlaubt die veröffentlichte Lizenz die Nutzung, Änderung, Weitergabe und den Verkauf des Softwarepakets unter ihren Bedingungen. Für Model-as-a-Service-Geschäftsmodelle gelten zusätzliche Regeln. Ab bestimmten Umsatzschwellen kann vor einer kommerziellen Nutzung eine separate Vereinbarung mit Moonshot AI erforderlich sein. Die konkrete Einordnung sollte die Rechtsabteilung anhand des tatsächlichen Produkts prüfen.

Braucht ein Unternehmen für internes Selbsthosting eine separate Vereinbarung?

Die Lizenz nimmt interne Nutzung von den besonderen Regeln für Model as a Service und großskalige kommerzielle Produkte aus, sofern Modell, Ausgaben und zugrunde liegende Fähigkeiten nicht Dritten zugänglich gemacht werden. Das ist keine pauschale Freigabe für jede Unternehmensarchitektur. Sobald Kunden, Partner oder externe Nutzer Zugriff erhalten, muss die Nutzung neu klassifiziert werden.

Welche Pflichten gelten bei einer eigenen Modell-API?

Eine eigene API kann als Model as a Service gelten, wenn Dritte die Eingaben, Parameter oder Trainingsdaten sinnvoll steuern können. Dann sind Umsatzschwellen, eine mögliche separate Vereinbarung und die genaue Produktarchitektur relevant. Zusätzlich müssen Lizenzhinweise, Zugriffskontrollen, Protokollierung, Datenschutz und Nachweise für die verwendete Modellversion dauerhaft gepflegt werden.

Ist die Kimi K3 API oder Selbsthosting meist günstiger für Compliance?

Für interne Anwendungen mit niedriger oder wechselnder Nutzung ist die Kimi K3 API häufig einfacher zu kontrollieren, weil Modellbetrieb und ein Teil der Infrastruktur beim Anbieter liegen. Selbsthosting kann bei sensiblen Daten oder festen Kontrollanforderungen sinnvoll sein, erzeugt aber zusätzliche Kosten für Infrastruktur, Sicherheit, Versionsprüfung und Auditnachweise. Die Entscheidung hängt daher nicht nur von Tokenpreisen ab.

Der pragmatische nächste Schritt

Die Alternative zur API ist nicht automatisch ein eigener Dauerbetrieb. Ein vollständiger Selbsthosting-Stack bringt zusätzliche Speicher- und Transferlast, laufende Sicherheitsarbeit, komplexere Zugriffskontrollen und eine größere Verantwortung für Modellversionen mit sich. Bei einer eigenen externen API kommen außerdem Schwellenwertüberwachung, Kundenrechte, UI-Hinweise und mögliche Vertragsverhandlungen hinzu.

Für interne Entwicklung und einen begrenzten Compliance-PoC ist deshalb ein rückbaubarer Aufbau oft belastbarer: Ein Mac dient als kontrollierter Entwicklungs- und Administrationspunkt, während die Gewichteschicht auf geeigneter Remote-Infrastruktur betrieben wird. ProxyMac kann dafür eine temporäre Mac-Umgebung bereitstellen, ohne dass ein Unternehmen sofort langfristige Hardware beschaffen oder eine vollständige Produktionsmigration finanzieren muss. Die passende Einsatzdauer und die organisatorischen Bedingungen sollten vorab anhand der ProxyMac-AGB geprüft werden.

Nach der Lizenzklassifizierung sollte das Team eine Abnahme für den Kimi-K3-PoC und ein gestuftes Budget erstellen. Erst wenn Datenfluss, Produktkontrolle, Lizenzschwellen und Auditnachweise belastbar dokumentiert sind, lässt sich entscheiden, ob aus dem Test ein begrenztes Selbsthosting oder ein größerer Produktionsbetrieb werden sollte.

Weiterlesen

• LLM per API oder lokal betreiben: Gesamtkosten und Betriebsaufwand vergleichen
• Open-Weights-Brief 2026: Lizenzen, Eigenbetrieb und echte Gesamtkosten prüfen