# Amazon Bedrock udostępnia przetwarzanie Kimi K3 w Indiach

- Source: MechNext — https://mechnext.eu/pl/article/61-amazon-bedrock-adds-india-based-inference-for-kimi-k3
- Published: 2026-11-04
- Updated: 2026-11-04
- Category: Industry News
- Language: pl (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=zh, ?lang=ru)

> Kimi K3 można wywoływać w Amazon Bedrock z przetwarzaniem ograniczonym do regionów AWS w Mumbaju i Hajdarabadzie. Dostępne są też profile globalne i amerykańskie, wejścia multimodalne, ustrukturyzowane wyniki, pamięć podręczna promptów i poziomy usług.

Amazon Bedrock obsługuje dla Kimi K3 przetwarzanie w Indiach, obok inferencji globalnej i opartej na regionach amerykańskich. Według AWS organizacje mogą wybrać profil inferencji określający, które regiony docelowe są uprawnione do obsługi żądania. Dla zadań, których przetwarzanie ma pozostać w Indiach, przeznaczony jest profil `in.moonshotai.kimi-k3`. Ogranicza on inferencję do regionów AWS Mumbai i Hyderabad.

### Wywołany profil określa granicę przetwarzania

Kimi K3 jest oferowany w Amazon Bedrock za pośrednictwem profili inferencji międzyregionalnej. Profil użyty w żądaniu wyznacza zbiór kwalifikujących się regionów docelowych. Jego wybór jest więc ważną decyzją wdrożeniową: profil indyjski ustanawia granicę obejmującą dwa regiony w Indiach, a warianty globalny i amerykański odpowiadają innym wymaganiom dotyczącym lokalizacji przetwarzania.

W inferencji międzyregionalnej dane są szyfrowane podczas przesyłania między regionami i pozostają w sieci AWS. Użytkownik nie musi tworzyć własnej wieloregionalnej infrastruktury VPC. Usługa obsługuje zatem połączenie regionalne potrzebne do inferencji, natomiast wybrany profil kontroluje miejsca, w których może nastąpić przetwarzanie.

### Interfejsy Runtime i pliki wejściowe

Aplikacje mogą wywoływać Kimi K3 przez punkt końcowy Bedrock Runtime z użyciem kilku interfejsów API. AWS wymienia Chat Completions oraz Responses API, wraz ze strumieniowaniem, wywoływaniem narzędzi i ustrukturyzowanymi wynikami. Pozwala to stopniowo prezentować odpowiedź, łączyć model ze zdefiniowanymi narzędziami albo żądać rezultatu w przewidywalnym formacie maszynowym.

Kimi K3 przyjmuje obrazy, pliki PDF i inne typy plików. Pliki wejściowe można przesyłać bezpośrednio z kodowaniem base64. Model potrafi czytać i analizować obrazy zawierające tekst wielojęzyczny. W opisanym przez AWS przepływie przetwarzania dokumentów eliminuje to potrzebę osobnej usługi OCR lub tłumaczenia. Dokument może być interpretowany w oryginalnym piśmie, a aplikacja może zażądać wyniku o innej strukturze lub formie językowej.

### Ustrukturyzowane wyniki i przykładowy proces

Ustrukturyzowane wyjście jest obsługiwane przez wywoływanie funkcji albo format oparty na JSON Schema. Ma to znaczenie, gdy odpowiedź ma zasilać kolejny krok aplikacji, a nie służyć wyłącznie do czytania. Schemat może zdefiniować oczekiwane pola, a wywołanie funkcji może połączyć wynik z dostępnym narzędziem.

Udostępniony przykładowy proces wykonuje OCR w oryginalnym piśmie, wyodrębnia konfigurowalne pola JSON, tworzy angielskie podsumowanie i odpowiada na wieloetapowe pytania w języku hinglish. Przykład łączy odczyt wielojęzycznego dokumentu, ekstrakcję maszynową, podsumowanie oraz konwersacyjne pytania uzupełniające. Jest to opis dostarczonego procesu, a nie niezależna ocena jego dokładności.

### Koszt i priorytet kolejki dla każdego żądania

Poziomy usług Amazon Bedrock pozwalają dobierać relację ceny do wydajności osobno dla każdego żądania. Poziom flex oferuje 50-procentowy rabat względem domyślnej ceny standardowej dla żądań mniej wrażliwych na opóźnienia. Poziom priority zapewnia wyższy priorytet w kolejce za wyższą cenę. Aplikacja może więc dopasować poziom do pilności konkretnego wywołania, zamiast stosować jeden wariant do wszystkich zadań.

Kimi K3 w Amazon Bedrock obsługuje również niższą cenę w przypadku trafień w pamięci podręcznej promptów. Dostępne są tryby niejawnego i jawnego buforowania promptów. Integracja może dzięki temu wybrać sposób obsługi ponownie używanego kontekstu, co jest szczególnie istotne przy powtarzających się interakcjach.

### Logi, metryki i region docelowy

Logi oraz metryki są przechowywane w regionie źródłowym, w którym wysłano żądanie, bez względu na region docelowy realizujący przetwarzanie. Opcjonalne rejestrowanie zdarzeń danych CloudTrail może zapisać region docelowy w polu `additionalEventData.inferenceRegion`. Zespoły operacyjne powinny zatem odróżniać miejsce przechowywania danych obserwacyjnych od miejsca inferencji.

Usługa rozdziela trzy decyzje: profil określa uprawnione lokalizacje przetwarzania, interfejs API i mechanizm wyjściowy definiują współpracę aplikacji z modelem, a poziomy usług i pamięć promptów wpływają na wybór cenowo-wydajnościowy. Dla profilu indyjskiego granicę przetwarzania stanowią Mumbai i Hyderabad, podczas gdy logi i metryki pozostają w regionie pochodzenia żądania.