Amazon Bedrock unterstützt für Kimi K3 nun Inferenz innerhalb Indiens, zusätzlich zu globaler und US-basierter Inferenz. Laut AWS können Organisationen ein Inferenzprofil wählen, das festlegt, welche Zielregionen eine Anfrage verarbeiten dürfen. Für Workloads, deren Verarbeitung in Indien bleiben soll, ist das Profil in.moonshotai.kimi-k3 vorgesehen. Es beschränkt die Inferenzverarbeitung auf die AWS-Regionen Mumbai und Hyderabad.

Das Profil legt die Verarbeitungsgrenze fest

Kimi K3 wird in Amazon Bedrock über regionsübergreifende Inferenzprofile angeboten. Das für einen Aufruf verwendete Profil bestimmt die zulässigen Zielregionen. Die Profilwahl ist damit eine zentrale Bereitstellungsentscheidung: Das Indien-Profil definiert einen Bereich aus zwei indischen Regionen, während die globalen und US-basierten Optionen andere Anforderungen an den Verarbeitungsort abdecken.

Bei regionsübergreifender Inferenz werden Daten während der Übertragung zwischen Regionen verschlüsselt und verbleiben im AWS-Netzwerk. Nutzer müssen keine eigene VPC-Infrastruktur für mehrere Regionen einrichten. Der Dienst übernimmt somit die für die Inferenz erforderliche regionale Verbindung, während das ausgewählte Profil die möglichen Verarbeitungsorte begrenzt.

Runtime-APIs und Dokumenteingaben

Anwendungen können Kimi K3 über den Bedrock-Runtime-Endpunkt mit mehreren APIs aufrufen. AWS nennt die Chat-Completions- und Responses-APIs einschließlich Streaming, Tool-Aufrufen und strukturierten Ausgaben. Eine Anwendung kann dadurch Antworten schrittweise anzeigen, definierte Werkzeuge einbinden oder Ergebnisse in einem vorhersehbaren, maschinenlesbaren Format anfordern.

Kimi K3 akzeptiert Bilder, PDF-Dateien und weitere Dateitypen. Eingabedateien lassen sich direkt base64-kodiert übertragen. Das Modell kann Bilder mit mehrsprachigem Text lesen und inhaltlich verarbeiten. Im von AWS beschriebenen Dokumentenablauf entfällt dadurch ein gesonderter OCR- oder Übersetzungsdienst. Ein Dokument kann in seiner ursprünglichen Schrift interpretiert werden, während die Anwendung ein anders strukturiertes oder formuliertes Ergebnis anfordert.

Strukturierte Ergebnisse und Beispielpipeline

Strukturierte Ausgaben werden über Function Calling oder ein Ausgabeformat auf Basis von JSON Schema unterstützt. Das ist besonders relevant, wenn eine Antwort nicht nur als Text angezeigt, sondern an einen weiteren Anwendungsschritt übergeben wird. Eine Schemafestlegung kann die erwarteten Felder definieren; ein Funktionsaufruf kann das Ergebnis mit einem verfügbaren Werkzeug verbinden.

Die bereitgestellte Beispielpipeline führt OCR in der Originalschrift durch, extrahiert konfigurierbare JSON-Felder, erzeugt eine englische Zusammenfassung und beantwortet mehrstufige Fragen in Hinglish. Das Beispiel verbindet das Lesen mehrsprachiger Dokumente, maschinenlesbare Extraktion, Zusammenfassung und dialogorientierte Rückfragen in einem Ablauf. Dies beschreibt die bereitgestellte Pipeline und ist keine unabhängige Bewertung ihrer Genauigkeit.

Preis und Warteschlangenverhalten pro Anfrage

Die Service-Stufen von Amazon Bedrock ermöglichen eine Preis-Leistungs-Auswahl für jede einzelne Anfrage. Die Flex-Stufe bietet bei weniger latenzempfindlichen Anfragen einen Rabatt von 50 Prozent gegenüber der standardmäßigen Standardpreisgestaltung. Die Priority-Stufe gewährt eine höhere Priorität in der Warteschlange, kostet jedoch mehr. Anwendungen können die Stufe somit an die Dringlichkeit des jeweiligen Aufrufs anpassen.

Kimi K3 unterstützt in Amazon Bedrock außerdem vergünstigte Preise bei Treffern im Prompt-Cache. Sowohl implizite als auch explizite Modi für das Prompt-Caching stehen bereit. Integrationen können damit wählen, wie sie wiederverwendbaren Prompt-Kontext behandeln; die Cache-Nutzung ist insbesondere für wiederholte Interaktionen relevant.

Protokolle, Metriken und Zielregion

Protokolle und Metriken werden in der Quellregion gespeichert, in der eine Anfrage eingereicht wurde, unabhängig davon, welche Zielregion sie verarbeitet. Die optionale Protokollierung von CloudTrail-Datenereignissen kann die Zielregion im Feld additionalEventData.inferenceRegion festhalten. Betriebsteams sollten daher zwischen dem Speicherort der Beobachtungsdaten und dem Ort der Inferenzverarbeitung unterscheiden.

Mehrere Entscheidungen bleiben klar getrennt: Das Inferenzprofil definiert die zulässigen Verarbeitungsorte, API und Ausgabemechanismus bestimmen die Interaktion der Anwendung, und Service-Stufen sowie Prompt-Caching gestalten die Preis-Leistungs-Wahl. Beim Indien-Profil umfasst die Verarbeitungsgrenze Mumbai und Hyderabad, während Protokolle und Metriken in der Ursprungsregion der Anfrage verbleiben.