영어 안내 음성을 CPU에서 오프라인으로 만들 목적이라면 25MB급 KittenTTS Nano가 후보가 되지만, 한국어와 감정 연기까지 기대하면 맞지 않습니다. 작은 모델이라는 장점은 언어 범위와 표현력, 시스템 의존성을 함께 받아들일 때 유효합니다.
KittenTTS 저장소의 원문 스냅샷은 v0.8, Nano 15M 파라미터와 Mini 80M 파라미터, Apache 2.0 라이선스를 소개합니다. Nano의 Int8 가중치는 약 25MB이며 24kHz 출력을 목표로 합니다. “GPU가 필요 없다”는 말은 CPU 실행 경로가 있다는 뜻이지 모든 기기에서 같은 실시간 속도가 나온다는 뜻은 아닙니다.
선택 기준은 단순합니다. 대상 문장이 주로 영어이고, 오프라인 실행과 작은 배포 파일이 자연스러운 감정 연기보다 중요하다면 Nano부터 시험할 수 있습니다. 발음이 다양한 고유명사, 다국어, 긴 서사와 캐릭터 감정이 핵심이라면 모델 크기 장점만으로 채택해서는 안 됩니다.
KittenTTS는 StyleTTS2 계열을 바탕으로 텍스트 처리와 음성 생성을 여러 단계로 나눕니다. 숫자, 통화, 약어를 정규화하고, 긴 문장은 구두점 기준으로 최대 400자 정도의 조각으로 나눕니다. eSpeak-ng가 영어 텍스트를 음소로 바꾸고, TextCleaner가 이를 토큰 ID로 매핑합니다.
목소리 특성은 모델 가중치에 모두 넣지 않고 voices.npz의 스타일 임베딩에서 가져옵니다. 짧은 문장과 긴 문장에 다른 벡터를 선택해 호흡과 억양을 조절합니다. 최종 추론은 ONNX Runtime을 사용해 무거운 PyTorch 런타임 없이 CPU에서 실행하는 구조입니다.
이 분업은 작은 모델 파일을 가능하게 하지만 품질 문제의 원인도 여러 단계에 나뉜다는 뜻입니다. 단어를 잘못 읽었다면 음소화와 정규화, 목소리가 의도와 다르면 스타일 벡터, 끊김이나 지연은 청킹과 추론 엔진을 각각 살펴야 합니다. 출력 음성이 어색하다는 이유만으로 모델 가중치만 바꾸면 같은 전처리 오류가 남을 수 있습니다.
CPU TTS의 체감 성능은 전체 문장을 만드는 시간 하나로 설명되지 않습니다. 사용자가 재생 버튼을 누른 뒤 첫 오디오 조각이 나오는 시간, 생성 음성 길이에 대한 처리 시간 비율, 긴 문장을 연속 생성할 때의 최고 메모리를 따로 기록해야 합니다. 짧은 알림은 첫 소리 지연이 중요하고, 파일을 미리 만드는 배치 작업은 총 처리량이 더 중요합니다.
측정은 차가운 시작과 따뜻한 시작을 나눕니다. 첫 실행에는 모델 로딩과 캐시 준비가 포함되지만 두 번째 실행은 이미 메모리에 올라와 더 빠를 수 있습니다. 목표 노트북이나 싱글보드 컴퓨터에서 1문장, 1분 분량, 여러 문단을 각각 실행하고 프로세스 RSS와 출력 파일 생성 시간을 남깁니다. 25MB 가중치만 보고 메모리 제한을 정하면 런타임과 오디오 버퍼 때문에 배포 뒤 실패할 수 있습니다.
동시 요청도 별도 조건입니다. 한 사용자의 문장을 순서대로 읽는 경우와 여러 세션이 동시에 음성을 요청하는 경우의 메모리와 지연은 다릅니다. 서비스로 감쌀 계획이라면 대기열을 둘지, 모델 인스턴스를 공유할지, 요청이 길 때 어디에서 잘라낼지를 정해야 합니다. 실시간 기준에 미달하면 더 작은 모델만 찾기 전에 문장 선생성이나 결과 캐시가 가능한 업무인지 검토할 수 있습니다.
25MB는 주로 Nano 가중치 크기를 가리킵니다. 실행할 때는 ONNX Runtime, 음소화 라이브러리, 스타일 파일, 오디오 버퍼와 애플리케이션 메모리가 추가됩니다. 긴 문장을 청킹하는 이유도 첫 오디오가 나오기까지의 지연과 메모리 급증을 줄이기 위해서입니다.
따라서 라즈베리파이나 브라우저에 넣기 전에는 모델 파일 크기보다 실제 RSS 메모리, 문장 길이별 RTF, 첫 오디오 지연을 재야 합니다. 원문이 언급한 WASM, ONNX Runtime Web 경로도 완성된 브라우저 배포 절차가 아니라 적용 가능성으로 읽는 편이 안전합니다.
원문의 파이썬 스니펫은 모델 생성과 파일 저장 흐름을 보여 주지만, 패키지 버전, 운영체제별 eSpeak-ng 설치, 모델 캐시를 모두 담은 완전한 실행법은 아닙니다. 특히 Windows 배포에서는 시스템 라이브러리와 환경 변수 처리가 사용자 경험의 일부가 됩니다. 최초 모델 다운로드 뒤 오프라인으로 쓸 계획이라면 캐시 파일과 라이선스도 배포물에 포함되는지 확인해야 합니다.
시험할 때는 Nano 모델 페이지의 파일과 현재 저장소 문서를 같은 버전으로 맞추고, 숫자, 통화, 약어가 들어간 자체 문장으로 발음을 듣는 것이 좋습니다. 원문에 있던 설정 참고 글 역시 프로젝트 버전이 달라질 수 있는 보조 자료입니다.
실제 스크립트에 등장하는 유형별 시험 문장을 먼저 만듭니다. 숫자와 소수점, 날짜와 시간, 통화, 영문 약어, URL, 괄호, 인명과 지명을 각각 포함하고 기대 발음을 적습니다. 같은 단어도 문장 위치와 구두점에 따라 억양이 달라질 수 있으므로 단독 단어와 문장 안의 형태를 모두 들어 봅니다. 전처리 결과를 확인할 수 있다면 원문, 정규화된 텍스트, 음소 열과 최종 오디오를 함께 보관하면 회귀 원인을 찾기 쉽습니다.
고유명사는 eSpeak-ng의 기본 발음과 맞지 않을 수 있습니다. 제품명이나 등장인물이 반복되는 서비스에서는 발음 치환 사전을 둘 수 있는지 확인하고, 치환이 일반 단어를 망치지 않는지 시험합니다. 숫자 문자열도 전화번호처럼 한 자리씩 읽어야 하는지 수량처럼 읽어야 하는지 문맥이 다릅니다. 정규화 규칙이 업무 문장을 어떻게 해석하는지 확인하지 않으면 자연스러운 목소리보다 잘못 읽힌 정보가 더 큰 문제가 됩니다.
한국어 문장을 출력 파일로 만들 수 있다는 사실과 자연스러운 한국어 지원은 같은 뜻이 아닙니다. 원문 시점의 영어 중심 조건을 기준으로 한국어 품질을 보장할 수 없으므로, 다국어가 필수라면 언어별 승인 문장으로 따로 통과 여부를 정해야 합니다. 지원 근거가 없는 언어를 발음 몇 개만 듣고 프로덕션 대상으로 확대하지 않는 편이 안전합니다.
최대 400자 안팎으로 나누는 과정은 메모리를 관리하지만 문장 경계를 잘못 고르면 억양이 끊깁니다. 마침표가 없는 긴 목록, 괄호가 이어지는 문장, URL이나 소수점의 점을 문장 끝으로 오인하는 경우를 시험해야 합니다. 각 조각을 독립 생성하면 앞 문맥의 말투나 속도가 다음 조각에서 달라질 수도 있습니다.
연결 품질은 오디오 파형만 붙였다고 끝나지 않습니다. 조각 사이 침묵이 지나치게 길거나 짧은지, 클릭음이 생기는지, 단어가 중복되거나 빠지는지 듣습니다. 여러 voice 스타일을 섞지 않았는데도 문단마다 화자 인상이 바뀌는지도 확인합니다. 알림처럼 한두 문장만 쓰는 제품이라면 이 문제가 작지만, 오디오북과 긴 기사 읽기에서는 모델 선택을 바꿀 정도로 중요합니다.
회귀 세트에는 짧은 문장과 경계 길이 직전, 직후 문장을 함께 둡니다. 청킹 기준을 바꾼 뒤 첫 오디오 지연이 개선돼도 문장 연결이 나빠질 수 있으므로 속도와 청취 품질을 같은 릴리스에서 확인해야 합니다. 합성 결과를 파일로 저장하는 업무라면 실패한 조각만 재시도하고 전체 문장을 다시 만들지 않는 구조도 고려할 수 있습니다.
짧은 시스템 알림, 오프라인 리더, 인디 게임의 임시 대사처럼 명료한 영어 전달이 우선인 작업이 잘 맞습니다. 반면 한숨, 속삭임, 극적인 감정 변화가 필요한 오디오북과 캐릭터 연기에서는 큰 상용 모델보다 평탄하게 들릴 수 있습니다. 괄호와 특수 기호가 많은 문장도 전처리 결과를 확인해야 합니다.
원문 시점의 주력 언어는 영어이며 한국어를 포함한 다국어 품질은 프로덕션 수준으로 단정할 수 없습니다. 결론적으로 KittenTTS를 “클라우드 TTS의 전면 대체”로 보기보다, 개인정보를 외부로 보내지 않고 제한된 영어 문장을 읽는 로컬 엔진으로 평가해야 합니다.
먼저 대표 영어 문장 수십 개를 Nano로 만들고 발음 오류, 첫 오디오 지연, 최고 메모리와 긴 문장 경계를 기록합니다. 같은 문장을 Mini나 현재 사용 중인 엔진과 비교하되 음량을 맞추고 모델 이름을 가린 청취 평가를 하면 작은 파일 크기에 대한 기대가 판단을 덜 흔듭니다. 품질 차이가 업무상 허용되고 대상 장치의 자원 한도도 통과할 때만 패키징으로 넘어갑니다.
배포물에는 모델 가중치뿐 아니라 ONNX Runtime, eSpeak-ng, voices 파일과 필요한 캐시가 포함되는지 확인합니다. 네트워크를 끊은 새 장치에서 설치부터 첫 합성까지 실행해 봐야 진짜 오프라인 경로인지 알 수 있습니다. 사용한 모델과 종속성의 라이선스 고지도 함께 남겨야 작은 데모가 제품 배포로 바뀔 때 누락을 줄일 수 있습니다.
반복되는 핵심 고유명사가 안정적으로 발음되지 않거나, 긴 글에서 화자 일관성이 무너지거나, 목표 장치의 지연 한도를 넘는다면 25MB라는 이유만으로 계속 밀어붙이지 않습니다. 반대로 제한된 영어 안내 문장을 미리 검수해 재생하는 제품이라면 큰 모델의 표현력이 필요하지 않을 수 있습니다. KittenTTS의 장점은 모든 음성 작업을 해결하는 데 있지 않고, 요구 범위를 좁혔을 때 로컬 실행 비용을 낮추는 데 있습니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.