Die Beschaffung der Kimi API im Unternehmen ist nicht dasselbe wie eine private Aufladung. Privatpersonen interessiert, ob und wie günstig der Dienst nutzbar ist; Unternehmen müssen zusätzlich Vertragspartner, Unternehmensverifizierung, Firmenzahlung, Rechnungen, Kontingente und SLA, Datencompliance, Modelllebenszyklus und Kostenverteilung klären. Was nicht im Vertrag steht, wird nach dem Start schnell zum Betriebsproblem.
Dieser Artikel liefert eine umsetzbare Beschaffungscheckliste ohne feste Preisangaben. Konkrete Stückpreise, Rabatte und Bedingungen richten sich nach dem offiziellen Angebot, dem Vertrag und den Modellpreisen.
Hinweis: Moonshot und Kimi sind Marken ihrer jeweiligen Inhaber. Enterprise-Angebote, Verifizierungsabläufe und Geschäftsbedingungen können sich ändern. Der Beitrag beschreibt die übliche Situation im Oktober 2026; vor der Beschaffung gelten die offiziellen Seiten und der Vertrag.
1. Zuerst zwei Produkte unterscheiden
| Produkt | Zielgruppe | Abrechnung | Zugangsdaten | Geeignet für |
|---|---|---|---|---|
| Kimi API | Entwickler und Unternehmenssysteme | Nutzungsabhängig nach Token | API-Key | Produktintegration, Batch, Agenten |
| Kimi Business | Teams, die den Kimi-Assistenten nutzen | Mitgliedschaft | Konto | Bürozusammenarbeit, persönliche Nutzung |
Beides ist nicht dasselbe. Wer Kimi in Kundenservice, Dokument- oder Codesysteme integriert, kauft die API; wer Mitarbeitern eine Kimi-Assistenten-Mitgliedschaft gibt, kauft Business. Vor der Beschaffung den Bedarf klären, um das falsche Produkt zu vermeiden.
2. Beschaffungscheckliste
| Position | Zu klärende Frage | Warum wichtig |
|---|---|---|
| Vertragspartner | Sind Vertrags-, Zahlungs- und Rechnungsempfänger identisch? | Betrifft Verifizierung, Zahlung und Erstattung |
| Unternehmensverifizierung | Ist eine Firmenidentitätsprüfung nötig, wie läuft sie? | Voraussetzung für Firmenzahlung und Vertrag |
| Aufladung und Zahlung | Ist Firmenüberweisung möglich, wie lange dauert die Gutschrift? | Beeinflusst die Liquiditätsplanung |
| Rechnung | Rechnungsart, Steuersatz, Kategorie, Empfängerregeln | Betrifft die Buchhaltung |
| Kontingent und Drosselung | Wie hoch sind Parallelität, RPM, TPM, TPD? | Entscheidet über Spitzenlastfähigkeit |
| SLA und Support | Gibt es Verfügbarkeitszusage und Reaktionszeiten? | Grundlage für Haftung und Wiederherstellung |
| Daten und Compliance | Speicherung, Trainingsnutzung, Übertragungswege | Betrifft personenbezogene und Kundendaten |
| Modelllebenszyklus | Wann werden alte Modelle abgeschaltet, wie migriert man? | Vermeidet plötzliche Ausfälle |
| Keys und Rechte | Projektbezogene Keys, minimale Rechte | Senkt Leak- und Missbrauchsrisiko |
| Exit-Mechanismus | Wie werden Guthaben, Daten und Logs behandelt? | Hinterlässt beim Anbieterwechsel keine Altlasten |
Diese Tabelle sollte direkt in das Vertriebsgespräch mitgenommen werden. Schriftliche Antworten gehören in Vertrag oder Anhang; rein mündliche Zusagen sind als Risiko zu behandeln.
3. Wie Kontingent und Drosselung zu verhandeln sind
Die Rate-Stufen der Kimi Open Platform hängen von der kumulierten Aufladung des Kontos ab; Gutscheine zählen üblicherweise nicht zur kumulierten Aufladung. Die niedrigste Stufe ist am engsten begrenzt und enthält ein tägliches Token-Limit. Mit höherer Stufe steigen Parallelität, RPM und TPM; bezahlte Stufen unterliegen meist keinem Tages-Token-Limit mehr, wohl aber Parallelitäts- und Minutenkontingenten.
Unternehmen können über den Vertrieb höhere Raten und Parallelität, dedizierten Support und individuelle SLAs beantragen. Für die Verhandlung geschätztes Monatsvolumen, Spitzenparallelität, Hauptszenarien und Wachstumsplan nennen; sonst kann der Anbieter kein passendes Kontingent anbieten.
Zwei Punkte sind zusätzlich zu beachten: Bei hoher Clusterlast kann die Plattform vorübergehend drosseln; risikobedingte Begrenzungen nach auffälligem Verhalten lassen sich möglicherweise nicht automatisch aufheben. Die Architektur darf daher nicht annehmen, „mit hohem Kontingent gibt es nie Drosselung“; Queue, Backoff, getrennte Keys und ein Ausweichkanal bleiben nötig.
4. Welche Compliance-Unterlagen zu prüfen sind
- Modellregistrierung: Bestätigen, dass der Dienst die anwendbaren Algorithmus- oder generative-AI-Registrierungen abgeschlossen hat, und Nachweise anfordern.
- Datenverarbeitungsvertrag: Wo Daten liegen, wie lange, wer zugreift und ob sie zum Training verwendet werden, muss klar geregelt sein.
- Datenschutzerklärung und Nutzungsbedingungen: Für API und Consumer-Produkt können unterschiedliche Bedingungen gelten; sie dürfen nicht vermischt werden.
- Datenexport: Bei internationalen Instanzen oder Auslandsknoten zuerst prüfen, ob eine grenzüberschreitende Übertragung vorliegt.
- Konto und Rechte: Verifiziertes Unternehmenskonto, projektbezogene Keys, minimale Rechte und Prozess für den Entzug bei Austritt.
- Logs und Audit: Aufruf-, Fehler- und Abrechnungsprotokolle für interne Prüfungen aufbewahren.
- Inhaltssicherheit: Für öffentliche Dienste Mechanismen zur Inhaltsprüfung und Beschwerdebearbeitung vorbereiten.
Bei personenbezogenen Daten, wichtigen Datenbeständen oder Kundenvertragstexten zuerst Rechts- und Sicherheitsteam einschalten, nicht erst nach dem Start.
5. Wie Kosten gesteuert werden
| Maßnahme | Vorgehen | Wirkung |
|---|---|---|
| Caching | System-Prompt, Tool-Definitionen und Wissensdatenbank-Präfix fixieren | Höhere Cache-Treffer, geringere Eingabekosten |
| Kontextsteuerung | Relevantes Retrieval, Verlaufszusammenfassung, gekürzte Tool-Ausgaben | Weniger unnötige Eingabe |
| Modell-Routing | Allgemeine Aufgaben mit K2.6, Code mit K2.7, sehr lange Materialien mit K3 prüfen | Falsche Modellzuordnung vermeiden |
| Ausgabegrenze | max_completion_tokens setzen, strukturierte Ausgabe verlangen |
Lange Ausgaben kontrollieren |
| Projektbudget | Tagesbudget und Alarme je Projekt | Ein Geschäftsbereich blockiert nicht das Gesamtkontingent |
| Monatliche Abstimmung | Nach Projekt, Modell und Szenario auswerten | Schnellst wachsende Verbraucher finden |
import os
from collections import defaultdict
# Preise aus Vertrag oder Preisseite lesen; das Beispiel enthält keine konkreten Zahlen
PRICE = {
"input_miss": float(os.environ["KIMI_INPUT_MISS_PRICE"]),
"input_hit": float(os.environ["KIMI_INPUT_HIT_PRICE"]),
"output": float(os.environ["KIMI_OUTPUT_PRICE"]),
}
# Jede Zeile: Projekt, nicht gecachte Eingabe, gecachte Eingabe, Ausgabe
rows = [
("Kundenservice", 120000, 80000, 30000),
("Dokumentenextraktion", 90000, 20000, 12000),
]
cost = defaultdict(float)
for project, miss, hit, out in rows:
cost[project] = (
miss * PRICE["input_miss"]
+ hit * PRICE["input_hit"]
+ out * PRICE["output"]
)
for project, amount in sorted(cost.items(), key=lambda x: -x[1]):
print(project, round(amount, 2))
Der Code dient nur als Beispiel für die Verteilung; die Preise müssen aus dem Vertrag stammen, nicht aus Screenshots oder mündlichen Angeboten. Falls bei K3 Kosten für Cache-Schreiben anfallen, sind diese separat zu erfassen.
6. Beschaffungsablauf
- Szenarien, Spitzenparallelität, durchschnittliche Tages-Token und Wachstumserwartung zusammenstellen.
- Unternehmensverifizierung abschließen; Handelsregisterauszug, Bankkonto und einheitlichen Sozialkreditcode vorbereiten.
- Mit kleinem Volumen Qualität, Latenz, Drosselung und Fehlerquote testen.
- Vertrag verhandeln: Kontingent, SLA, Support-Reaktionszeiten, Datenverarbeitung und Exit-Klauseln.
- Firmenzahlung oder Kreditlinie nutzen; Gutschrift und Rechnungsprozess bestätigen.
- Inbetriebnahme: projektbezogene Keys, Budgets, Monitoring, Alarme und Ausweichkanal.
- Vierteljährlich Verbrauch, Kosten, Störungen und Alternativen überprüfen.
Häufige Fragen
Wie läuft die Unternehmensverifizierung?
Üblicherweise werden Firmenname, gleichlautendes Bankkonto und einheitlicher Sozialkreditcode eingereicht; die Plattform überweist einen zufälligen Betrag auf das Firmenkonto, den die Buchhaltung prüft und einträgt. Der genaue Ablauf steht auf den offiziellen Seiten.
Sind Firmenzahlung und Rechnung möglich?
Nach abgeschlossener Unternehmensverifizierung kann meist online aufgeladen oder per Firmenüberweisung gezahlt werden; der Rechnungsempfänger muss in der Regel dem verifizierten Unternehmen entsprechen. Rechnungsart, Steuersatz und Kategorie richten sich nach Plattformregeln und Vertrag.
Erhalten Unternehmen ein SLA?
Standard-API und Enterprise-Angebot können unterschiedliche Supportstufen haben. Wenn Verfügbarkeitszusage, dedizierter Support oder höhere Kontingente benötigt werden, im Vertriebsgespräch ausdrücklich verlangen und im Vertrag festhalten.
Werden Daten zum Training verwendet?
Nicht nur auf die Werbeseite schauen. Für API und Consumer-Produkt können unterschiedliche Datenklauseln gelten. Vor Vertragsabschluss Datenschutzerklärung und Datenverarbeitungsvertrag lesen und Speicher-, Trainings- und Löschregeln im Vertrag festhalten.
Kann ein privates Konto Firmengeschäft übernehmen?
Nicht empfehlenswert. Ein privates Konto ist bei Unternehmensverifizierung, Firmenzahlung, Rechnung, Rechteverwaltung und Audit unvollständig; auch die Verantwortlichkeit bei Problemen ist unklar.
Nächster Schritt
Führen Sie zuerst im ZSQH AI Gateway mit einem Test-Key eine Runde echter Szenarien durch und erfassen Sie Verbrauch, Latenz und Fehlerquote, bevor Sie mit diesen Daten Kontingent und Vertrag verhandeln. Modelle, Preise und Enterprise-Angebote richten sich nach den Modellpreisen.
Weiterlesen:
