# AWS pokazuje wcześniejszy start mowy agentów z Kokoro na SageMaker AI

- Source: MechNext — https://mechnext.eu/pl/article/49-aws-walkthrough-starts-agent-speech-earlier-with-kokoro-on-sagemaker-ai
- Published: 2026-10-23
- Updated: 2026-10-23
- Category: Industry News
- Language: pl (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=zh, ?lang=ru)

> Instrukcja AWS kieruje gotowe zdania do syntezy jeszcze podczas generowania odpowiedzi. Autorzy opisują szybsze pierwsze audio, zakres pomiarów oraz pułapki transportu i wdrożenia.

Instrukcja AWS przesyła ukończone zdania agenta do Kokoro-82M, zanim powstanie cała odpowiedź. Pozwala to wcześniej rozpocząć syntezę mowy. Model o 82 milionach parametrów działa we własnym kontenerze na punkcie końcowym SageMaker AI czasu rzeczywistego, na instancji GPU ml.g5.xlarge. Wyniki implementacji i pomiarów pochodzą od autorów instrukcji.

### Wiele zdań w jednym połączeniu

POST /invocations strumieniuje wynik dla jednego kompletnego wejścia. WS /invocations-bidirectional-stream obsługuje wiele wiadomości w jednym połączeniu dwukierunkowym. Po wysłaniu audio i ramki sterującej synthesis_complete kontener czeka na kolejną wiadomość. Zamyka sesję dopiero po wyraźnym komunikacie zamknięcia od klienta.

Każdy handler syntetyzuje i wysyła wiadomości kolejno: podczas przesyłania poprzedniego zdania nie generuje jeszcze dźwięku następnego. Opisywana korzyść wynika z wcześniejszego rozpoczęcia pierwszego zdania i uniknięcia ponownego łączenia dla każdego kolejnego.

Mechanizm dzielenia tekstu przyjmuje cały ciąg lub strumień fragmentów. feed() zwraca nowo ukończone zdania i zachowuje niedokończoną końcówkę; flush() oddaje pozostały tekst po zakończeniu wejścia. Autorzy opisują sprawdzenie trzech zdań w jednej aktywnej sesji, z dźwiękiem odpowiadającym tekstowi każdego wejścia.

SageMaker AI dostarcza wiadomości klienta do kontenera jako binarne ramki WebSocket. Handler Starlette oczekujący ramek tekstowych może zgłaszać KeyError dla pola text przy każdym żądaniu, mimo stanu endpointu InService. Przykład obsługuje oba typy ramek, dekoduje dane binarne jako UTF-8 i zaleca testy z ramkami binarnymi.

### Zakres przedstawionych pomiarów

Aby wyodrębnić czas transportu TTS, autorzy użyli tekstu o 267 znakach i czterech zdaniach. Wykonali po pięć prób na aktywnym endpoincie dla całego bloku i dla samego pierwszego zdania. Według nich średni czas do pierwszego bajtu audio spadł z 329,3 do 156,7 milisekundy, czyli o 52,4 % w tym porównaniu.

Przykład całościowy wykorzystuje agenta Strands z Amazon Bedrock, uruchomionego w AgentCore. Osobne połączenia obsługują SSE do przeglądarki, generowanie tekstu w Bedrock i dwukierunkową syntezę Kokoro. Tryb bidi równocześnie odbiera tekst i audio przez wspólną kolejkę zdarzeń; batch czeka z syntezą na całą odpowiedź.

Dla identycznego promptu, tego samego aktywnego modelu Bedrock i endpointu autorzy podają 2,4 raza szybsze pierwsze audio w lokalnym kontenerze oraz 3,5 raza szybsze w AgentCore. Test odtworzeniowy mierzy pierwsze zdarzenie audio_chunk względem agent_start. Oba tryby kodują audio dla wywołującego w base64, ponieważ BedrockAgentCoreApp zwraca słowniki serializowalne do JSON, przekształcane przez SDK w ramki SSE.

### Transport i wymagania wdrożenia

Autorzy zbadali koszty transportu na 24 klipach i porównali MP3 z AAC. Jak podają, użycie Amazon Transcribe potwierdziło brak różnicy jakości między kodowaniami. Base64 zwiększyło rozmiar danych o około 33 %. W jednej odpowiedzi cztery logiczne ramki MP3 dotarły w sześciu fragmentach transmisji, z których dwa kończyły się wewnątrz ramki. Odbiorca musi więc buforować dane i składać je ponownie.

Alternatywa na odcinku do modelu łączy surowe binarne audio i ramki sterujące JSON w istniejącej sesji dwukierunkowej, bez base64 i SSE na tym odcinku. Fragment jest sterowaniem tylko wtedy, gdy daje się zdekodować jako kompletny obiekt JSON; w innym przypadku jest audio. Sprawdzenie całości zapobiega uznaniu PCM za JSON jedynie z powodu początkowego nawiasu klamrowego. Autorzy zalecają zachowanie base64 przez SSE przy istniejącym frontendzie SSE, a rozważenie wspólnego transportu przy nowej ścieżce głosowej lub priorytecie opóźnienia.

Wymagane są uprawnienia do SageMaker AI, AgentCore, IAM i ECR, przygotowane AWS CDK v2, Python 3.12 lub nowszy, uv, Docker, obsługa invoke_endpoint_with_bidirectional_stream w Boto3, znajomość WebSocket i ASGI oraz wskazany kod. Gotowe pakiety wheel bazowego klienta HTTP/2 są dostępne dopiero od Pythona 3.12. Kontener musi deklarować com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true.

speech-infra deploy tworzy infrastrukturę endpointu, role IAM, pamięć podręczną wag w S3, obraz kontenera, model i konfigurację endpointu. Następnie agent-infra deploy tworzy środowisko AgentCore. Usuwanie przebiega odwrotnie. Polecenia destroy pozostawiają bucket S3 i repozytorium ECR; wymagają one osobnego usunięcia, aby zakończyć opłaty za przechowywanie. Wpis ostrzega też o przypiętej starszej wersji PyTorch objętej PYSEC-2026-2286. Jako poprawioną wskazuje torch 2.10.0 i zaleca sprawdzenie oraz aktualizację wersji przed użyciem wykraczającym poza weryfikację wartości rozwiązania.