Die Beschaffung der Moonshot API für Unternehmen ist nicht dasselbe wie ein privates Guthaben. Neben dem Preis sind Vertragspartei, Bankzahlung, Rechnungen, Kontingente, Datenklauseln, Berechtigungen, SLA und ein Ausstiegsszenario zu klären. Dieser Beitrag liefert eine umsetzbare Checkliste ohne konkrete Stückpreise; Preise und Bedingungen richten sich nach dem offiziellen Angebot, dem Vertrag und den Modellpreisen auf dieser Website.

Hinweis: Moonshot und Kimi sind Marken der jeweiligen Inhaber. Dieser Beitrag steht in keiner Zugehörigkeits-, Vertretungs- oder Kooperationsbeziehung zu Moonshot AI; genannte Abläufe und Regeln richten sich nach den offiziellen Seiten und Verträgen.

1. Zuerst den Beschaffungsgegenstand klären

Die hinter Kimi stehende Moonshot Open Platform bietet eine nach Tokens abgerechnete API, nicht eine Kimi-Mitgliedschaft oder einen Büroarbeitsplatz. Die API dient Kundenservice, Wissensdatenbanken, Dokumentenverarbeitung und Agenten; Chat-Mitgliedschaften für Mitarbeiter sind eine separate Beschaffungslinie. Die Konten und Keys der chinesischen Site platform.kimi.com und der internationalen Site platform.kimi.ai sind nicht austauschbar. Zuerst klären, welche Site das Team nutzt, damit Vertragspartei und tatsächliche Aufrufe zusammenpassen.

2. Beschaffungscheckliste

Die folgenden zehn Punkte sollten in das Gespräch mit dem Anbieter einfließen. Als gesichert gilt nur, was im Vertrag oder einer Anlage steht.

Beschaffungspunkt Zu klärende Frage Nachweis
Vertrags- und Verifizierungspartei Sind Vertrag, Zahlung und Rechnung beim selben Rechtsträger? Handelsregisterauszug, Verifizierungsnachweis
Guthaben und Zahlung Banküberweisung und Gutschriftzeit Zahlungsbeleg, Buchungsnachweis
Rechnung Rechnungsart, Steuersatz, Ausstellungsregeln Musterrechnung oder Erläuterung
Kontingente und Limits Parallelität, RPM, TPM, TPD, temporäre Drosselung Offizielle Limitseite, Vertragsanlage
Daten und ZDR Aufbewahrung, Training, Löschung, Geltungsbereich Datenverarbeitungsvertrag, ZDR-Bestätigung
Berechtigungen Organisation, Projekte, Keys, IP-Whitelist, Offboarding Rechte-Matrix, Screenshots der Konsole
SLA und Support Verfügbarkeit, Reaktionszeiten, Eskalationsweg SLA im Vertrag oder Support-Anlage
Modelllebenszyklus Vorlauf bei Abschaltung, Migrationshilfe Kündigungsfristen, Versionsprotokoll
Kostensteuerung Budgets, Alarme, Abrechnungsgranularität Konfiguration, Beispielrechnung
Ausstieg Guthaben, Daten, Logs Kündigungs- und Rückerstattungsklauseln

3. Kontingente und Rate-Limits

Die Tarifstufe richtet sich nach der kumulierten Aufladung des Kontos; Anrechnungsgutscheine zählen nicht dazu. Unaufgeladenes Tier0 erlaubt nur eine parallele Anfrage, 3 RPM und eine Tagesgrenze für Tokens; bezahlte Stufen heben die Tagesgrenze meist auf, TPM, Parallelität und RPM bleiben aber bestehen. Konkrete Schwellen stehen auf der offiziellen Limitseite.

Projekte teilen sich Limits und Guthaben der Organisation; das TPM eines Projekts überschreitet nicht die Obergrenze der Organisation, und Spitzen sind für die Organisation insgesamt zu berechnen. Für Verhandlungen mindestens fünf Werte bereithalten: durchschnittliche Tokens pro Monat, Spitzenparallelität, durchschnittliches Verhältnis von Eingabe zu Ausgabe, Cache-Trefferquote und Batch-Anteil. Eine reine Monatssumme genügt nicht.

Zusätzlich nach temporärer Drosselung und Risikokontrollen fragen. Laut offizieller Dokumentation kann der Cluster bei hoher Last vorübergehend drosseln; eine durch auffälliges Verhalten ausgelöste Risikosperre lässt sich nach dem Auslösen möglicherweise nicht aufheben. Die Architektur muss Warteschlange, Backoff und Degradation vorsehen und darf nicht annehmen, dass hohe Kontingente nie gedrosselt werden.

4. Guthaben und Rechnungen

Nach der Unternehmensverifizierung sind Online-Aufladung oder Banküberweisung möglich. Der Name des Firmenkontos muss mit der verifizierten Partei übereinstimmen; Überweisungen werden üblicherweise in 1 bis 5 Werktagen gutgeschrieben, die Plattform bucht etwa 10 Minuten nach Eingang. Grenzüberschreitende Zahlungen und Zahlungen durch Dritte bleiben häufig bei Verifizierung und Rechnungsstellung hängen.

Rechnungen lassen sich nach Verbrauch oder Aufladung beantragen. Der Rechnungsempfänger von Unternehmenskonten muss die verifizierte Partei sein; nur Privatkonten können zwischen privater und Firmenanschrift wählen. Laut offizieller Seite lautet der Rechnungssteller Beijing Moonshot Technology Co., Ltd., die Kategorie ist technische Dienstleistung mit 6 Prozent Steuersatz; maßgeblich ist die Rechnungsseite.

Die Konsole unterstützt Tages- und Monatsbudgets pro Projekt und lehnt Anfragen nach Erreichen der Grenze ab, die Abrechnung ist jedoch etwa 10 Minuten verzögert und kein Echtzeit-Schutz. Die Standardwarnung bei niedrigem Guthaben liegt bei 20 Yuan; Produktionskonten sollten den Schwellwert erhöhen und einen Abrechnungszyklus Puffer einplanen.

5. Datenklauseln und ZDR

Die Plattformvereinbarung räumt dem Anbieter das Recht ein, Eingaben, Ausgaben und Feedback im gesetzlich zulässigen Rahmen zur Optimierung der Modellservices zu verwenden. Standardmäßig darf „wird nicht zum Training verwendet“ nicht als Prämisse gelten. Die Datenschutzerklärung nennt Speicherung in Festlandchina.

Unternehmen können Zero Data Retention (ZDR) beantragen. Danach dienen Anfrageinhalte nur der jeweiligen Inferenz und werden nach der Antwort gelöscht; Unternehmensdaten werden nicht zum Training verwendet. ZDR gilt jedoch nicht für Batch, über den Datei-Endpunkt hochgeladene Bilder oder Videos, Hosted Agents, Betriebsdaten (Sicherheitslogs, Abrechnung) und Drittanbieterdienste. ZDR muss geschäftlich freigeschaltet werden und ist nicht in jedem Tarif enthalten.

Für öffentliche Dienste verlangt die Vereinbarung außerdem eigene Sicherheitsbewertung, Algorithmus-Registrierung, Inhaltsprüfung und Incident-Response; bei der Beschaffung klären, welche Unterlagen der Anbieter stellt.

6. Berechtigungen und Zugriffskontrolle

Nach der Unternehmensverifizierung gilt eine Obergrenze von 50 Projekten und 100 Keys; ohne Verifizierung sind es 1 Projekt und 10 Keys, mit privater Verifizierung 20 Projekte und 50 Keys. Ein im Projekt erstellter Key wird dem Verbrauch dieses Projekts zugerechnet; Mitglieder sollten eigene Keys erhalten, statt einen Key an das ganze Team zu verteilen.

Die IP-Whitelist ist ein organisationsweiter Schalter mit maximal 20 Einträgen und akzeptiert nur öffentliche IPv4-Adressen oder gültige CIDR-Bereiche, kein IPv6, keine privaten Netze und keine Loopback-Adressen. Wird ein Mitglied aus einem Projekt entfernt, verlieren die von ihm erstellten Keys ihre Gültigkeit. Vor dem Start Rechte-Matrix, Offboarding und Key-Rotation als Prozess festhalten.

7. SLA, Support und Ausstieg

Stand Oktober 2026 enthält die Standardvereinbarung keine Verfügbarkeitszusage; Wartungsunterbrechungen sind ausgenommen, die Haftung ist auf den Umsatz des letzten Kalendermonats begrenzt. Das bedeutet nicht, dass der Dienst instabil ist, sondern dass die Standardbedingungen kein unternehmensgerechtes SLA bieten.

Bei Verfügbarkeitsanforderungen sollten Vertrag oder Anlage regeln: Verfügbarkeitskennzahl, Fristen für Störungsmeldungen, Support-Reaktionsstufen, Eskalationsweg, Kompensation und Migrationshilfe nach Vertragsende. Wer nur die API kauft und kein SLA abschließt, kann bei einer Störung meist nur wiederholen oder den Anbieter wechseln. Auch der Ausstieg gehört in den Vertrag: ob Guthaben erstattet wird, wie lange Daten und Logs bleiben, wie Rechnungen exportiert werden und wann Keys ungültig werden.

8. Kostenkontrolle

  • Caching: Der automatische Cache hat standardmäßig 5 Minuten TTL und lässt sich auf 1 Stunde setzen; System-Prompt und Wissensdatenbank-Präfix stabil halten, um die Trefferquote zu erhöhen. Cache-Schreiben wird separat berechnet.
  • Modell-Routing: kimi-k2.6 für allgemeine Aufgaben, kimi-k2.7-code für Code, kimi-k3 für sehr lange Materialien oder komplexe Reasoning-Aufgaben.
  • Batch: Laut offizieller Dokumentation 60 Prozent des Standardpreises, nur für kimi-k2.6 und kimi-k2.7-code, geeignet für große Offline-Aufgaben; nicht von Echtzeit-Parallelität begrenzt, aber außerhalb von ZDR.
  • Budget und Abgleich: Tages- und Monatsbudgets sowie Alarme pro Projekt, monatliche Auswertung nach Projekt, Modell und Szenario; die Budgetsperre greift etwa 10 Minuten verzögert und taugt nicht als Echtzeit-Sicherung.

Ein versteckter Kostenfaktor sind Retries. Das OpenAI SDK wiederholt standardmäßig zweimal automatisch; Retries zählen zu RPM und TPM. Fehlgeschlagene 429-Anfragen werden nicht berechnet, erfolgreiche Retries normal. Nicht gestreamte Anfragen erhalten nach 900 Sekunden ohne Antwort ein 504; lange Aufgaben sollten Streaming nutzen.

9. Degradation und Störungsübung

Nicht annehmen, dass ein einziger Anbieter immer verfügbar ist. Mindestens drei Stufen vorbereiten: ein kleineres Modell auf derselben Plattform, Warteschlange oder Asynchronisierung, Wechsel zu einem Ersatzanbieter oder Gateway. Der Ersatzpfad muss vorab getestet werden, nicht erst im Störfall anhand einer Base URL gesucht werden.

Vor dem Start eine Übung durchführen: 429, Timeout und 5xx simulieren und prüfen, ob Alarmierung, Umschaltung und Rollback jeweils Verantwortliche haben. Das Übungsprotokoll ist selbst Abnahmematerial.

10. Pilotabnahme

Zunächst 2 bis 4 Wochen Pilotbetrieb, danach skalieren.

  1. 20 bis 50 echte Aufgaben vorbereiten und Qualitäts-, Format- und Prüfkriterien definieren.
  2. Monatliche Tokens, Spitzenparallelität, Cache-Trefferquote und Batch-Anteil schätzen.
  3. 30 Minuten bei Zielparallelität laufen lassen und Erfolgsquote, P95-Latenz und 429-Typen erfassen.
  4. Die Rechnung prüfen: Werden Cache-Schreiben, Treffer, Batch und Retries wie erwartet berechnet?
  5. Projekt-Keys, IP-Whitelist, Offboarding und Budgetsperre verifizieren.
  6. Geltungsbereich von ZDR, Log-Aufbewahrung und Löschprozess prüfen.
  7. Eine Degradationsübung durchführen: Kann bei 429, Timeout oder 5xx des Hauptmodells automatisch gewechselt werden?
  8. Mit Daten über Kontingente, SLA, Preis, Zahlungsziel und Ausstieg verhandeln.
import os
import time
import statistics
from collections import Counter
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
    max_retries=0,  # waehrend der Abnahme automatische Retries aus, echte Fehlerrate sehen
)

def one_call(_):
    start = time.perf_counter()
    try:
        client.chat.completions.create(
            model="kimi-k2.6",
            messages=[{"role": "user", "content": "Erklaere den Zweck der Abnahme in einem Satz"}],
            max_completion_tokens=128,
        )
        return ("ok", time.perf_counter() - start)
    except Exception as exc:
        resp = getattr(exc, "response", None)
        kind = resp.json().get("error", {}).get("type", type(exc).__name__) if resp else type(exc).__name__
        return (kind, time.perf_counter() - start)

with ThreadPoolExecutor(max_workers=3) as pool:  # an Zielparallelitaet anpassen, kein Lasttest der Plattform
    results = list(pool.map(one_call, range(30)))

latencies = [d for kind, d in results if kind == "ok"]
print("Erfolg", len(latencies), "Fehler", len(results) - len(latencies))
print("P95 Sekunden", round(statistics.quantiles(latencies, n=20)[-1], 2) if len(latencies) >= 2 else "N/A")
print("Fehlerverteilung", Counter(kind for kind, _ in results if kind != "ok"))

Dieses Skript dient nur der Abnahme mit geringem Volumen und repräsentiert nicht die Kapazität der Plattform. Echte Lasttests erst nach Klärung von Bedingungen und Kontingenten durchführen, um Risikokontrollen nicht auszulösen.

Häufig gestellte Fragen

Ist für die Unternehmensbeschaffung eine Verifizierung nötig?

Für Verträge, Bankzahlung, Firmenrechnungen und Mitgliederverwaltung ja. Privatkonten sind in diesen Punkten unvollständig.

Sind Bankzahlung und Rechnungsstellung möglich?

Nach der Unternehmensverifizierung üblicherweise ja. Der Name des Firmenkontos muss mit der verifizierten Partei übereinstimmen, und auch der Rechnungsempfänger kann nur diese Partei sein; Rechnungsart und Steuersatz richten sich nach der Rechnungsseite.

Gibt es ein SLA für die Standard-API?

Stand Oktober 2026 enthält die Standardvereinbarung keine Verfügbarkeitszusage; Wartungsunterbrechungen sind ausgenommen. Ein SLA muss im Vertrag oder einer Anlage vereinbart werden.

Werden Daten zum Training verwendet?

Die Standardvereinbarung erlaubt die Nutzung von Eingaben und Ausgaben zur Optimierung der Modellservices. Unternehmen können ZDR beantragen, mit Ausnahmen etwa für Batch und Datei-Uploads; bei Kundendaten zuerst eine Prüfung durchführen.

Was tun bei zu wenig Kontingent?

Eine Aufladung erhöht die Tarifstufe; höhere Parallelität, TPM oder dedizierter Support laufen über den Vertrieb. Unabhängig vom Kontingent muss der Code 429, Timeouts und Degradation behandeln.

Nächster Schritt

Registrieren Sie zunächst ein Testkonto beim ZSQH AI Gateway, lassen Sie eine Runde echter Aufgaben laufen und exportieren Sie Verbrauch, Latenz und Fehlerverteilung, bevor Sie mit Daten über Kontingente und Verträge verhandeln. Modelle, Preise und Unternehmenslösungen richten sich nach den Modellpreisen.

Weiterführende Beiträge: