SageMaker의 Kokoro TTS 스트리밍, 에이전트가 작성을 마치기 전에 음성 시작

AWS는 10월 22일, AI 에이전트가 응답 생성을 마치기 전에 음성 합성을 시작하는 Kokoro TTS 스트리밍 가이드를 공개했다. 이 설계는 음성 생성을 위해 텍스트를 보내기 전에 전체 답변을 수집하는 익숙한 통합 방식을 재검토하게 한다. 핵심은 새로운 음성 모델을 도입하는 데 있지 않고, 그 대기 시간을 없애는 데 있다.

개발자에게 이 차이는 최적화를 어디서 시작해야 하는지를 바꾼다. 더 빠른 음성 모델도 애플리케이션이 이미 보유한 텍스트를 내보내기까지 기다리는 데 소요된 시간은 되돌릴 수 없다. 즉각적인 비교 대상은 문장 단위 전송과 전체 응답 버퍼링이며, 두 방식 모두 동일한 기저 합성 모델을 사용한다.

더 넓게 보면 Amazon Polly처럼 점진적 입력을 지원하는 관리형 음성 서비스도 선택지에 포함된다. 따라서 구매자는 모델 선택과 애플리케이션 타이밍을 분리해 판단해야 한다. 실질적인 질문은 기존 시스템이 유용한 음성을 지연시키고 있는지, 그리고 어떤 엔지니어링 책임을 직접 맡고 싶은지다.

Kokoro TTS 스트리밍은 모델이 아니라 전달 시점을 바꾼다

중요한 변화는 생성된 텍스트가 음성 처리 대상이 되는 시점이다. 애플리케이션은 텍스트를 점진적으로 표시하면서도 음성 서비스에는 이를 계속 전달하지 않을 수 있다. 따라서 반응성 높은 채팅 인터페이스가 곧바로 반응성 높은 음성 인터페이스를 뜻하는 것은 아니다.

구매 반품에 관한 예시 지원 대화를 생각해 보자. 첫 문장은 즉시 취해야 할 다음 단계를 설명하고, 이후 문장들은 예외 사항과 증빙 서류를 다룰 수 있다. 전체 답변이 끝날 때까지 첫 문장을 보류하면 청취자에게 반드시 필요하지 않은 의존성이 생긴다.

이 의존성을 없애면 작업 일정이 달라진다. 언어 모델이 이후 내용을 계속 작성하는 동안, 초기 일부 텍스트로 음성 생성을 시작할 수 있다. 그렇다고 언어 모델의 사고 속도가 빨라지거나 최종 답변이 반드시 더 빨리 도착한다는 뜻은 아니다.

달라지는 것은 청취자가 유용한 출력을 받기 시작하는 시점이다. 첫 반응과 완료된 응답은 서로 다른 목적을 수행하므로 이 차이는 중요하다. 이른 확인 응답은 진행 중임을 알릴 수 있고, 완전한 답변은 작업을 마무리하는 데 필요한 정보를 제공한다.

모델 자체는 기존 자산으로 남는다. Kokoro 모델 카드는 8,200만 개 매개변수를 갖고 Apache 라이선스 가중치를 제공하는 오픈 웨이트 음성 모델로 이를 설명한다. 문서화된 출시 이력은 이번 AWS 가이드보다 앞선다.

다운로드 가능한 모델 매개변수를 뜻하는 오픈 웨이트는 개발자에게 모델 추론, 즉 모델에서 출력을 생성하는 과정을 어디에서 실행할지 제어할 권한을 준다. 이 유연성은 호스팅 환경을 선택하는 팀에 유의미하지만, 그 자체로 지연 시간 우위를 입증하지는 않는다.

호스팅 제어는 개발자가 떠안게 되는 작업도 바꾼다. 소프트웨어 종속성, 모델 개정판, 음성 동작, 운영 장애를 평가해야 한다. 모델 라이선스는 중요한 배포 질문에는 답하지만, 특정 애플리케이션이 고객 대화를 처리할 준비가 되었는지까지 답해 주지는 않는다.

이 때문에 AWS 사례는 모델 출시 이야기보다 아키텍처 참조 자료로서 더 유용하다. 그 관련성은 Kokoro를 도입하지 않는 팀에도 확장된다. 텍스트 생성과 음성 생성 사이에서 불필요하게 대기하는 모든 애플리케이션은 이 경계를 점검해야 한다.

즉각적인 이점에는 한계도 있다. 애플리케이션이 이미 전체 답변을 보유하고 있다면, 점진적 전달은 이미 끝난 텍스트를 기다리는 시간을 없앨 수 없다. 유용한 텍스트가 점진적으로 도착할 때 전달 방식을 바꿀 가장 강력한 이유가 생긴다.

그래서 비교에서는 실제 지연의 원인을 보존해야 한다. 음성, 언어 모델, 버퍼링을 동시에 바꾸면 어떤 결정이 도움이 되었는지 불분명해진다. 전달 방식을 별도로 평가하면 향후 아키텍처 선택에 더 유익한 결과를 얻을 수 있다.

음성 팀은 모델 문제보다 먼저 스케줄링 문제를 마주한다

기존 에이전트에 음성을 추가하는 개발자는 전체 응답 경로를 측정해야 한다는 압박에 직면한다. 각 구성 요소는 개별적으로는 충분한 성능을 낼 수 있지만, 완성된 제품에서는 청취자를 기다리게 할 수 있다. 이 문제는 모델만큼이나 통합에 속한다.

음성 상호작용은 청취자가 소리를 듣기 전까지 여러 경계를 지난다. 애플리케이션은 요청을 받고, 필요한 정보를 수집하며, 텍스트를 생성하고, 오디오를 만들고, 이를 전송한 뒤 재생을 시작한다. 각 경계에서는 모델 벤치마크로 포착되지 않는 대기 시간이 발생할 수 있다.

이는 제품 팀 내부의 책임 문제를 만든다. 백엔드 엔지니어는 오디오 전송이 성공했다고 보고할 수 있지만, 프런트엔드 엔지니어는 재생 전에 여전히 데이터를 버퍼링할 수 있다. 공동 측정은 이러한 이벤트를 사용자가 실제로 경험하는 것과 연결해야 한다.

첫 오디오까지의 시간, 즉 오디오 출력이 시작되기 전 지연은 유용한 출발 지표다. 다만 정확한 종착점이 필요하다. 애플리케이션이 처음 수신한 바이트가 반드시 브라우저에서 처음 재생되는 소리는 아니다.

브라우저는 오디오를 해석하고 재생 일정을 잡아야 한다. 재생 정책에 따라 소리를 시작하기 전에 사용자 상호작용이 필요할 수도 있다. 서버 전송을 최종 사용자 경험으로 간주하면 이러한 조건은 측정 범위 밖에 남는다.

제품 관리자는 무엇이 유용한 음성인지에 대해서도 관련된 결정을 내려야 한다. 즉각적인 군더더기 문구는 사용자를 답변에 더 가깝게 하지 않으면서도 시스템이 작동 중인 것처럼 들리게 할 수 있다. 평가는 대화형 확인 응답과 최초의 실질적 정보를 구분해야 한다.

이 압박은 이미 자리 잡은 텍스트 어시스턴트를 확장하는 팀에서 가장 뚜렷하다. 텍스트 인터페이스가 이미 부분 응답을 표시한다면, 음성도 유사하게 동작하리라는 기대가 생긴다. 응답 완료 후 합성을 추가하면 텍스트 제품이 이미 없앤 대기를 조용히 되살릴 수 있다.

예시 사내 지식 어시스턴트에서 직원은 고객 에스컬레이션에 어떤 절차가 적용되는지 물을 수 있다. 검증된 지침으로 시작하는 것은 도움이 될 수 있다. 관련 정책을 검색하기 전에 시작하면 다른 문제가 생길 수 있다.

따라서 스트리밍에는 문장 경계뿐 아니라 근거 경계도 필요하다. 애플리케이션은 어떤 진술이 소리로 전환될 준비가 되었는지 결정해야 한다. 이후 정보가 초기 답변을 한정하거나 반박할 수 있을 때 이 판단은 더 중요해진다.

기술 평가를 유지하는 팀은 검색 가능한 지식 베이스와 함께 배포 메모를 관리할 수 있다. 여기서 유용한 연결점은 아키텍처 결정, 테스트 조건, 관찰된 장애 사이의 추적 가능성이다.

이는 시장 승자에 대한 예측이 아니라 즉각적인 엔지니어링 압박이다. 개발자는 다른 모델이나 전송 방식을 선택하기 전에 비교 가능한 측정값이 필요하다. 구매자는 개선 효과가 자신의 응답 패턴, 정보 소스, 재생 환경에서도 유지된다는 증거가 필요하다.

그에 따른 우선순위는 실용적이다. 추가 모델 용량을 구매하기 전에 피할 수 있는 의존성을 식별해야 한다. 다운스트림 작업을 시작하지 않는 애플리케이션은 더 많은 컴퓨팅 자원으로 직접 해결되지 않는다. 모든 배포 제안에서는 스케줄링과 모델 성능을 별도로 설명해야 한다.

지속 연결은 점진적 입력을 유용하게 만든다

스트리밍 연결은 애플리케이션이 작업을 더 일찍 내보내는 데 사용할 때만 도움이 된다. 연결을 계속 열어 두는 것은 불필요한 버퍼링을 없앴다는 증거가 아니라 이를 가능하게 하는 조건이다. 프로토콜과 애플리케이션 일정이 함께 작동해야 한다.

양방향 스트리밍은 지속 연결을 통해 출력을 받는 동시에 입력을 보내는 것을 뜻한다. SageMaker는 모델을 제공하는 패키지형 소프트웨어 환경인 사용자 지정 모델 컨테이너에 이 기능을 문서화하고 있다. 이를 통해 점진적으로 생성된 요청과 점진적으로 반환되는 응답을 처리할 수 있다.

양방향 컨테이너 계약은 명시적인 기능 레이블과 WebSocket 경로를 요구한다. WebSocket은 양방향 메시지를 지원하는 지속 연결이다. 컨테이너 작성자는 예상되는 메시지 처리를 구현해야 한다.

이 계약은 메시지 데이터를 담는 프로토콜 단위인 텍스트 및 바이너리 입력 프레임도 구분한다. 문서화된 동작은 페이로드에 선언된 데이터 유형에 따라 달라진다. 따라서 애플리케이션은 하나의 관찰된 프레임 유형을 SageMaker의 보편적 특성으로 간주해서는 안 된다.

이는 샘플 통합과 플랫폼 보장 사이의 중요한 차이다. 샘플 클라이언트가 바이너리 메시지를 일관되게 전송한다고 해서 지원되는 모든 클라이언트가 반드시 그렇게 동작한다는 뜻은 아니다. 프로덕션 핸들러는 성공적인 시연에서 추론한 가정이 아니라 문서화된 계약을 따라야 한다.

메시지 처리는 하나의 작업 단위 완료와 대화 완료도 구분해야 한다. 하나의 음성 요청을 끝냈다고 해서 애플리케이션이 더 이상 보낼 텍스트가 없다는 뜻은 아니다. 이는 연결 관리에 서로 다른 의미를 지닌 별개의 이벤트다.

아키텍처 측면의 이점은 관련 작업 조각 사이에서 반복되는 설정을 피하는 데 있다. 그러나 지속 연결이 모델 서버 내부의 동시 처리를 의미하지는 않는다. 전송 기능과 합성 동시성, 즉 겹쳐 진행되는 합성 작업은 여전히 별개의 설계 선택이다.

서버는 일련의 입력을 받고 이를 순차적으로 처리할 수 있다. 전체 응답보다 초기 입력이 더 빨리 도착한다면 이 구성도 도움이 된다. 실제 생성이 겹친다는 증거가 없다면 이를 병렬 합성이라고 설명해서는 안 된다.

느린 소비자가 생산자에게 과부하를 받지 않도록 하는 메커니즘인 백프레셔도 중요한 설계 고려 사항이 된다. 텍스트 생성은 음성 생성이나 재생보다 빨라질 수 있다. 애플리케이션에는 무제한 누적이 아닌 대기 중인 자료에 대한 의도적인 정책이 필요하다.

취소도 유사한 경계를 만든다. 사용자가 중단할 때 텍스트 생성만 멈추면 대기열에 오디오가 남아 있을 수 있다. 유용한 중단 정책은 모델 작업, 네트워크 전송, 이미 재생되도록 예약된 소리를 고려해야 한다.

텍스트를 문장 크기 단위로 나누는 문장 분할 역시 일반적인 산문을 넘어 평가할 가치가 있다. 약어, 소수값, 제목, 불완전한 조각은 문장 부호 기반 규칙을 모호하게 만들 수 있다. 이는 공개된 사례의 입증된 장애라기보다 테스트해야 할 엔지니어링 문제다.

따라서 이 아키텍처는 더 이른 출력을 위한 여지를 만드는 동시에, 완료된 응답 뒤에 숨겨졌던 책임을 드러낸다. 팀은 타이밍을 제어할 수 있다. 동시에 메시지 유형, 경계, 대기열, 취소, 불완전한 입력에 대한 명시적 규칙이 필요하다.

SSE 호환성과 바이너리 전송은 서로 다른 문제를 해결한다

합성을 더 일찍 시작하는 것과 오디오 전송 방식을 바꾸는 것은 독립적인 결정이다. 팀은 브라우저 통신 계층을 교체하지 않고도 전자를 개선할 수 있다. 반대로 애플리케이션이 완료될 때까지 모든 텍스트를 계속 보류한다면 바이너리 연결을 도입해도 도움이 되지 않는다.

Server-Sent Events, 즉 SSE는 서버에서 클라이언트로 지속적인 텍스트 이벤트를 전송하는 메커니즘입니다. SSE 이벤트 형식은 UTF-8 텍스트를 사용하며 빈 줄로 메시지를 구분합니다. 이는 단방향 채널입니다.

이 형식은 바이너리 오디오를 SSE 내부에 담을 때 추가적인 표현 방식이 필요한 이유를 설명합니다. 바이너리 데이터를 텍스트로 표현하는 인코딩인 Base64는 이러한 페이로드를 텍스트 채널과 호환되게 만듭니다. 다만 인코딩 및 디코딩 작업도 추가됩니다.

호환성에 대한 주장은 타당합니다. 기존 애플리케이션은 이미 SSE를 중심으로 이벤트 라우팅, 인증, 모니터링, 재연결 동작을 구축했을 수 있습니다. 특히 음성이 이미 자리 잡은 텍스트 경험에 추가되는 기능이라면, 이러한 구성 요소를 재사용해 구현 범위를 줄일 수 있습니다.

바이너리 경로는 해당 연결에서 오디오를 텍스트로 표현해야 하는 요구 사항을 없앱니다. 그렇다고 다른 위치의 모든 버퍼, 디코더 또는 메시지 경계가 자동으로 사라지는 것은 아닙니다. 전송 효율성에 관한 주장은 시스템의 정확히 어느 부분이 달라졌는지 밝혀야 합니다.

이는 에이전트 시스템에 여러 개의 독립적인 통신 구간이 포함되는 경우가 많기 때문에 중요합니다. 모델 연결, 에이전트 런타임 연결, 브라우저 연결은 각각 서로 다른 프로토콜을 사용할 수 있습니다. 전체 제품을 “바이너리 스트리밍”이라고 부르면 중간에 있는 텍스트 기반 릴레이를 감출 수 있습니다.

AWS도 자사 안내에서 이 구분을 명확히 합니다. 배포된 에이전트 예시는 호출자 측 구간에서 여전히 SSE를 통해 Base64 오디오를 반환합니다. 따라서 모델 측 바이너리 접근 방식을 완전히 바이너리 기반의 브라우저 전송 경로로 설명해서는 안 됩니다.

더 넓은 엔지니어링 교훈은 프레이밍, 즉 메시지 경계를 식별하는 규칙에 관한 것입니다. 네트워크 전송 청크가 반드시 애플리케이션 이벤트나 독립적으로 재생 가능한 오디오 단위와 일치하는 것은 아닙니다. 수신자는 이러한 구분을 보존해야 합니다.

예를 들어 이벤트 스트림을 읽는 파서는 콘텐츠를 해석하기 전에 완전한 이벤트를 인식해야 합니다. 그다음 오디오 소비자는 오디오 형식에 따라 결과 데이터를 처리해야 합니다. 이러한 책임을 부주의하게 결합하면 전송 동작이 모델 실패처럼 보일 수 있습니다.

오디오와 제어 메시지를 모두 전달하는 통합 연결에는 또 다른 프로토콜 결정이 필요합니다. 수신자는 받은 메시지의 종류를 안정적으로 식별해야 합니다. 향후 확장을 고려한 프로덕션 프로토콜을 설계할 때는 명시적인 메시지 유형을 검토할 가치가 있습니다.

이 관찰은 아키텍처 권고일 뿐, 샘플에 특정한 대체 방안이 필요하다는 주장은 아닙니다. 애플리케이션마다 다른 선택을 할 수 있습니다. 중요한 요구 사항은 분류, 비정상 메시지, 버전 변경이 어떻게 동작할지 문서화하는 것입니다.

따라서 팀은 실제 병목 지점을 기준으로 전송 변경을 평가해야 합니다. 텍스트 공개 지연이 가장 큰 비중을 차지한다면, 프로토콜 마이그레이션은 가장 큰 대기 시간을 해결하지 못한 채 노력을 소모할 수 있습니다. 전송과 재생이 지배적이라면, 모델 서버만 개선해도 청취자 경험은 대부분 달라지지 않을 것입니다.

관리형 음성은 여전히 유효한 비교 대상입니다

SageMaker의 Kokoro는 호스팅 선택지일 뿐, 점진적 음성을 제공하는 유일한 경로는 아닙니다. 관련 비교 대상에는 텍스트를 점진적으로 받는 서비스도 포함됩니다. 모든 대안을 전체 응답 방식의 시스템으로 규정하면 이 아키텍처가 제공하는 고유한 가치를 과장하게 됩니다.

Amazon Polly의 양방향 음성 합성은 생성된 오디오를 받는 동안 텍스트를 전송할 수 있도록 지원합니다. 문서화된 작동 방식은 생성형 엔진을 사용합니다. 이는 맞춤형 Kokoro 컨테이너를 운영하는 방식에 대한 관리형 대안을 제시합니다.

비교는 운영 책임에서 시작해야 합니다. 맞춤형 배포에서는 팀이 모델 서빙 환경을 선택하고 유지 관리합니다. 관리형 음성 인터페이스에서는 그 환경의 더 많은 부분이 서비스 경계 뒤에 위치합니다.

어느 방식도 애플리케이션 책임을 없애지는 않습니다. 개발자는 여전히 어떤 텍스트를 보낼지, 오디오를 어떻게 전달할지, 재생이 중단에 어떻게 반응해야 할지를 결정해야 합니다. 관리형 합성 서비스가 주변 대화 흐름을 자동으로 정의해 주지는 않습니다.

마찬가지로 공개 가중치가 더 높은 음성 품질, 더 낮은 운영 비용 또는 더 나은 애플리케이션 지연 시간을 보장하는 것은 아닙니다. 그러한 주장은 조건을 맞춘 평가가 필요합니다. 모델 카드의 라이선스 및 크기 정보는 특정 프로덕션 워크로드의 측정을 대체할 수 없습니다.

음성 선택 역시 별도의 주의가 필요합니다. 발음, 속도, 문장 전환은 어시스턴트가 이해하기 쉽고 사용하기 편안한지에 영향을 줍니다. 더 빠른 첫 소리가 가치 있으려면 결과 음성이 여전히 작업에 적합해야 합니다.

서로 다른 음성이나 출력 형식을 사용하는 비교도 구매자가 제품을 선택하는 데 도움이 될 수 있습니다. 하지만 이는 점진적 스케줄링의 효과만을 깔끔하게 분리할 수는 없습니다. 평가자는 완전한 제품 구성과 하나의 아키텍처 결정을 비교하는지 설명해야 합니다.

맞춤형 배포에는 구체적인 유지 관리 주의 사항도 있습니다. 배포 샘플은 자신을 프로덕션 준비 완료 구현이 아닌 가치 검증용으로 설명합니다. 해당 README는 고정된 PyTorch 의존성에 영향을 주는 알려진 권고 사항을 명시합니다.

저장소는 PyTorch 2.6.0을 고정하며, 수정된 버전으로 2.10.0을 제시합니다. 또한 완화 요소로 고정된 모델 리비전을 설명합니다. 이러한 내용은 배포된 애플리케이션이 침해되었다는 의미 없이 의존성 검토가 필요함을 시사합니다.

이 주의 사항은 팀이 예시를 활용하는 방식을 바꿉니다. 재현 가능한 데모는 아키텍처 아이디어를 검증할 수 있지만, 여전히 소프트웨어 유지 관리와 보안 작업이 필요합니다. 이 두 결론은 양립할 수 있으며 어느 하나가 다른 하나를 지워서는 안 됩니다.

따라서 회의적인 질문은 초기 합성이 작동하는지 여부보다 더 넓습니다. 완전한 배포가 수용 가능한 음성, 예측 가능한 동작, 관리 가능한 운영을 제공하는지가 핵심입니다. 현재 자료는 설계를 검토할 근거를 제공할 뿐, 모든 관리형 서비스보다 우수하다고 단정할 근거는 제공하지 않습니다.

엔터프라이즈 구매자에게 유용한 제안은 각 장애 경계를 누가 책임지는지 명시해야 합니다. 모델 호스팅, 애플리케이션 로직, 전송, 재생에는 서로 다른 근거가 필요합니다. 단일 지연 시간 비율로는 이러한 모든 책임을 나타내거나 조달 결정을 확정할 수 없습니다.

다음으로 재생 측정, 지속 부하, 유지 관리를 지켜보십시오

다음으로 유용한 근거는 더 이른 합성을 반복 가능한 사용자 결과와 연결해야 합니다. 앞으로 몇 달간 가장 강력한 후속 검토는 브라우저 재생, 부하 상황의 성능, 참조 구현의 유지 관리를 다룰 것입니다. 각각은 배포 사례의 서로 다른 부분을 검증합니다.

첫 번째 신호는 재현 가능한 브라우저 측정입니다. AWS는 모드별 5회 시험에서 분리된 평균 첫 오디오 지연 시간이 329.3밀리초에서 156.7밀리초로 감소했다고 보고합니다. 또한 배포된 에이전트 비교에서 3.5배 개선을 보고합니다.

이는 독립 측정이 아닌 회사 자체 보고 결과입니다. 조건을 맞춰 가청 재생을 추적하는 후속 검토는 실무적 근거를 강화할 것입니다. 브라우저 수준의 개선 폭이 더 작다면 이전 합성 이점을 부정하지 않으면서도 주장의 범위를 좁힐 수 있습니다.

측정은 응답 내용, 음성, 재생 동작을 가능한 한 비슷하게 유지해야 합니다. 또한 서버 이벤트, 디코딩된 오디오 버퍼, 가청 출력을 구분해야 합니다. 그렇지 않으면 서로 다른 단계 측정값이 이름만 다른데도 비교 가능한 것처럼 보일 수 있습니다.

두 번째 신호는 동시 대화 상황에서의 지속 성능입니다. 빠른 초기 응답만으로는 많은 사용자가 동시에 말할 때 쌓이는 대기열을 알 수 없습니다. 중요한 질문은 시스템이 애플리케이션의 예상 트래픽을 처리하면서도 반응성 있는 전달을 유지하는지입니다.

안정적인 재생과 통제된 대기열의 증거는 더 폭넓은 배포를 뒷받침할 것입니다. 문장 사이 간격이 늘어난다면 초기 응답 지표가 운영 한계를 놓치고 있음을 보여줄 것입니다. 두 결과 모두 팀이 스케줄링과 서빙 용량 중 어디에 주의가 필요한지 파악하는 데 도움이 됩니다.

이 평가는 응답 변동성도 포함해야 합니다. 짧은 답변, 긴 설명, 정보 의존적인 멈춤은 동일한 아키텍처에 서로 다른 요구를 가합니다. 하나의 패턴이 지배적인 벤치마크로는 전체 제품에서 시스템이 어떻게 동작하는지 확립할 수 없습니다.

세 번째 신호는 샘플과 그 의존성의 유지 관리입니다. 문서화된 주의 사항을 해결한 업데이트 구현은 도입을 더 쉽게 평가하게 합니다. 명확한 호환성 안내와 재현 가능한 검증은 또 하나의 속도 비교 헤드라인보다 더 중요합니다.

해결되지 않은 의존성 문제는 배포 전 필요한 작업을 늘립니다. 그러나 이는 구현 전반에 적용될 수 있는 스케줄링 원칙을 무효화하지는 않습니다. 독자는 아키텍처 아이디어에 대한 신뢰와 특정 샘플 코드 리비전에 대한 신뢰를 구분해야 합니다.

Kokoro TTS 스트리밍을 고려하는 개발자는 요청 도착부터 가청 재생까지 대표 대화 하나를 추적하는 것부터 시작하십시오. 유용한 텍스트를 사용할 수 있게 되는 시점, 합성이 시작되는 시점, 청취자가 실질적인 정보를 듣는 시점을 기록하십시오. 관련 없는 구성 요소를 바꾸지 않은 채 점진적 방식과 버퍼링 방식을 비교하십시오.

그다음 더 긴 답변과 중단된 대화를 살펴보십시오. 초기 음성이 정확한지, 대기 중인 오디오가 예상대로 멈추는지, 문장 전환이 이해하기 쉬운지 확인하십시오. 나중의 변경 사항도 설명 가능하도록 관찰 결과를 배포 구성과 함께 보관하십시오. 이 결과를 활용해 다음 투자 대상이 텍스트 공개, 모델 서빙, 전송, 브라우저 재생 중 어디인지 결정하십시오. 어떤 경계가 사용자들을 기다리게 만들고 있습니까?