Supertonic의 “167배 빠른 TTS”는 특정 하드웨어에서 보고된 순수 추론 RTF를 뜻하며, 모든 기기의 첫 음성 지연과 전체 사용자 경험을 보장하는 수치는 아닙니다.
Supertonic 99M TTS가 정말 167배 빠를까: RTF, 404MB, 음질의 교환
167배는 RTF 0.006을 뒤집은 값이다
RTF(Real-time Factor)는 음성 1초를 만드는 데 걸린 시간을 음성 길이로 나눈 값입니다. RTF가 0.006이면 계산상 실시간보다 약 167배 빠릅니다. 원문은 NVIDIA RTX 4090에서 0.001, Apple M4 Pro에서 0.006이라는 값을 제시합니다.
이 수치를 서비스 지연 시간과 바로 같게 보면 안 됩니다. 모델 다운로드와 초기 적재, 텍스트 정규화, 첫 오디오 조각이 나올 때까지의 시간, WAV 변환과 재생 준비는 별도입니다. 문장 길이, 언어, 실행 제공자와 기기 발열 상태도 결과를 바꿉니다. 따라서 “음성 30초 생성 시간”과 “사용자가 재생을 처음 듣는 시간”을 따로 측정해야 합니다.
99M 모델이 빠른 이유와 404MB의 의미
원문 기준 Supertonic V3는 약 99M 파라미터와 404MB의 공개 ONNX 자산으로 구성되며 31개 언어와 <laugh>, <breath> 같은 표현 태그를 지원합니다. 파이프라인은 세 부분으로 나뉩니다.
- Speech Autoencoder가 파형을 잠재 표현으로 압축합니다.
- Flow-Matching 기반 Text-to-Latent 모듈이 원문 설명 기준 두 번의 추론 단계로 음성 특징을 만듭니다.
- Duration Predictor가 텍스트와 음성 길이를 맞춥니다.
ONNX Runtime을 사용해 CPU, WebGPU, WASM, JVM JNI 등 여러 실행 환경을 겨냥할 수 있다는 점이 온디바이스 배포의 기반입니다. 다만 99M은 대형 음성 모델과 비교해 가벼운 것이지, 404MB 다운로드가 모바일, 브라우저에 항상 작은 것은 아닙니다. 캐시가 비어 있는 첫 방문, 저용량 기기, 느린 네트워크에서는 모델 전달 자체가 병목이 됩니다.
오프라인은 서버 비용을 기기 비용으로 옮긴다
클라이언트에서 합성하면 텍스트를 외부 TTS API로 보내지 않아도 되고 네트워크 단절에도 동작할 수 있습니다. 호출량에 비례하는 서버 추론 비용도 줄일 수 있습니다. 대신 사용자의 CPU, GPU, 메모리, 배터리와 저장 공간을 사용합니다.
브라우저에서는 WebGPU 지원 여부와 WASM 대체 경로를 함께 확인해야 합니다. JVM 연동도 외부 파이썬 서비스를 없앨 가능성은 있지만, JNI와 ONNX Runtime의 플랫폼별 패키징, 메모리 해제, 장애 처리가 새 운영 대상이 됩니다. “온디바이스”는 인프라가 사라진다는 뜻이 아니라 지원해야 할 하드웨어 조합이 늘어난다는 뜻입니다.
음질도 용도별로 들어야 합니다. 짧은 안내, 접근성 읽기, 오프라인 알림에는 속도와 프라이버시가 우선일 수 있습니다. 긴 오디오북이나 섬세한 감정 연기에서는 99M 모델의 표현력이 더 큰 모델보다 부족할 수 있습니다. 표현 태그 지원만으로 문맥에 맞는 연기가 자동 보장되지는 않습니다.
도입 전에는 같은 문장으로 네 축을 비교한다
파일럿은 빠른 한 대에서만 돌리지 말고 실제 하위 기기를 포함해야 합니다.
- 한국어, 영어, 숫자, 통화, 고유명사가 섞인 고정 문장 묶음을 만듭니다.
- 콜드 스타트, 첫 오디오 지연, 전체 RTF를 각각 측정합니다.
- CPU, 메모리, 배터리와 404MB 자산의 다운로드, 캐시 실패를 기록합니다.
- 사람 평가로 발음, 긴 문장 연결, 표현 태그, 반복 합성의 안정성을 듣습니다.
- 지원하지 않는 환경에서 서버 TTS로 돌아갈지 기능을 끌지 정합니다.
원문에 나온 파이썬 호출 예시는 구조를 설명하는 스냅샷입니다. 실제 사용에는 패키지와 모델 버전, 자산 다운로드 정책, 음성 스타일 JSON의 출처, 지원 태그, 오류, 파일 저장 처리가 더 필요합니다. 커스텀 보이스를 만들 때 Voice Builder 의존과 비용도 별도 항목으로 계산해야 합니다.
결론적으로 Supertonic은 “클라우드 API보다 항상 낫다”가 아니라, 음질 요구가 맞고 실제 대상 기기에서 콜드 스타트까지 통과할 때 강한 선택지입니다. 167배라는 숫자보다 서비스가 허용할 첫 음성 지연과 최저 기기 기준이 도입 여부를 결정합니다.
콜드 스타트와 첫 음성 지연은 어떻게 분해할까?
새 사용자의 첫 실행에는 모델 자산 다운로드, 압축 해제 또는 캐시 저장, ONNX 세션 생성, 실행 제공자 초기화와 첫 inference 준비가 들어갑니다. 한 번 준비된 뒤의 RTF만 재면 이 비용이 사라져 보입니다. 설치 직후, 앱 재시작, 캐시 적중과 캐시 삭제 네 조건에서 각각 측정해야 실제 체감을 알 수 있습니다.
긴 문장을 모두 생성한 뒤 재생하면 전체 RTF가 빨라도 첫 소리가 늦을 수 있습니다. 문장 분할 또는 스트리밍이 지원되는 범위에서 텍스트 정규화 완료, 첫 합성 chunk, 오디오 장치 제출과 실제 재생 시작 시각을 따로 기록하세요. 너무 짧게 나누면 문장 사이 억양이 끊기고 호출 준비 비용이 반복될 수 있으므로 음질과 지연을 함께 비교합니다.
캐시 전략에는 모델 버전과 무결성 검사가 필요합니다. 새 자산을 배포하다 일부 파일만 바뀌면 세션 생성이 실패할 수 있으므로 버전별 디렉터리에 완전히 받은 뒤 원자적으로 전환하고 검증된 이전 버전을 남깁니다. 저장 공간이 부족하거나 다운로드가 중단됐을 때 부분 파일을 정리하고 서버 음성이나 시스템 TTS로 돌아갈 경로를 정합니다.
대상 기기 행렬은 어떻게 구성해야 하는가?
최신 GPU 한 대가 아니라 실제 사용자 분포의 하위 기기, 통합 GPU, CPU 전용과 브라우저를 포함합니다. 각 기기에서 첫 음성 지연, 전체 RTF, 최고 메모리, CPU, GPU 사용률, 배터리와 지속 실행 때의 발열, throttling을 기록합니다. 한 문장 성공 뒤가 아니라 여러 분 합성을 반복해 성능이 유지되는지 봅니다.
브라우저에서는 WebGPU 사용 가능 여부와 실제 adapter 획득 성공을 구분합니다. 정책, 드라이버, 브라우저 버전 때문에 지원 표시가 있어도 초기화가 실패할 수 있습니다. WASM fallback이 기능적으로 동작해도 목표 지연을 넘으면 짧은 문장만 로컬로 처리하거나 서버 경로를 선택할 수 있습니다. fallback 전환은 사용자에게 무한 로딩으로 보이지 않아야 합니다.
JVM과 JNI에서는 운영체제, 아키텍처별 native library, 메모리 해제, 여러 요청의 thread safety와 앱 종료를 시험합니다. Python 예제가 동작한다는 사실은 모바일, 웹, 서버 패키징을 보장하지 않습니다. 지원하지 않을 조합을 초기에 명시해야 플랫폼 수가 장점에서 유지보수 부채로 바뀌지 않습니다.
음질 평가는 어떤 문장으로 해야 하는가?
평가 문장에는 한국어 조사와 숫자 읽기, 날짜, 통화, 단위, 영문 약어, 고유명사, 괄호와 긴 문장을 포함합니다. 같은 의미를 표현 태그 유무로 합성해 웃음, 호흡이 문맥에 맞는지, 태그가 그대로 읽히거나 과도하게 반복되지 않는지 듣습니다. 짧은 데모 문장만으로는 문장 연결과 장시간 피로를 알기 어렵습니다.
사람 평가자는 모델 이름을 가리고 자연스러움, 이해 가능성, 발음 오류, 일관된 화자성과 용도 적합성을 점수화합니다. 접근성 읽기와 오디오북은 합격 기준이 다르므로 하나의 평균 MOS처럼 뭉치지 않습니다. 자동 신호나 전사 결과를 보조로 쓸 수 있지만 사용자에게 거슬리는 억양과 감정은 청취 평가가 필요합니다.
커스텀 음성을 사용한다면 생성 비용뿐 아니라 사용 권한, 동의와 철회 절차를 확인합니다. 스타일 JSON이나 음성 자산이 어느 버전의 모델과 호환되는지 기록하고, 사용자가 업로드한 음성을 다른 목적에 재사용하지 않습니다. 프로젝트가 표현 태그를 지원한다는 사실만으로 모든 언어에서 같은 품질이 보장되지는 않습니다.
온디바이스와 서버 fallback을 어떻게 나눌까?
첫 실행이거나 낮은 사양에서는 서버 TTS, 다운로드가 끝나고 합격 기기에서는 로컬 TTS를 선택할 수 있습니다. 다만 민감 텍스트를 로컬 처리한다고 약속했다면 조용히 서버로 보내서는 안 됩니다. fallback 전에 사용자 동의와 네트워크 정책을 확인하고, 불가능하면 시스템 TTS 또는 텍스트만 제공하는 경로를 둡니다.
선택 로직은 단순 기기 이름이 아니라 모델 적재 성공, 실제 짧은 probe 지연, 배터리 상태와 네트워크를 사용할 수 있습니다. 로컬 합성 중 메모리 오류가 나면 같은 큰 요청을 반복하지 말고 문장 길이를 줄이거나 다른 경로로 전환합니다. 서버와 로컬의 음성이 달라질 수 있으므로 한 콘텐츠 안에서 화자가 갑자기 바뀌는 UX도 고려합니다.
비용 비교에는 모델 자산 전송량, CDN, 지원되는 플랫폼별 개발, QA, 사용자 기기 자원과 서버 호출 단가를 포함합니다. 오프라인 사용률과 반복 합성량이 높을수록 로컬의 가치가 커질 수 있지만, 대부분 한 번만 쓰는 웹 방문에서는 404MB 전송이 더 큰 비용일 수 있습니다.
출시 판단표에는 어떤 합격선을 둘까?
기기별 p50, p95 첫 음성 지연, 전체 RTF, 오류, fallback 비율, 최고 메모리와 지속 실행 성능을 표로 관리합니다. 음질은 언어, 사용 사례별 발음 오류와 사람 선호를 기록하고, 모델 다운로드 완료율과 캐시 재사용률도 봅니다. 평균이 좋아도 하위 기기에서 앱이 종료되면 해당 기기는 지원 목록에서 빼야 합니다.
모델과 ONNX Runtime 버전을 고정하고 새 버전은 일부 사용자에게 canary로 배포합니다. 지연, 오류, 음질 회귀가 생기면 자산과 선택 로직을 함께 이전 버전으로 돌릴 수 있어야 합니다. 공식 benchmark 수치를 재현하지 못해도 제품 합격선을 충족하면 사용할 수 있고, 반대로 167배를 재현해도 발음과 첫 지연이 기준을 넘으면 출시하면 안 됩니다.
함께 읽으면 이해가 이어지는 글
- Voicebox는 ElevenLabs를 로컬로 대체할까: Qwen3-TTS 설치, GPU, 동의 체크 — Qwen3-TTS와 Whisper를 로컬 UI로 묶은 Voicebox의 기능, 설치 스냅샷, 하드웨어 비용과 음성 복제 동의 조건을 점검합니다.
- VoxCPM은 정말 토크나이저가 없을까: FSQ, 확산 TTS의 실제 구조 — VoxCPM이 기존 오디오 토큰 열 대신 의미, 음향 계층과 FSQ 병목, 로컬 확산 디코더를 쓰는 방식과 레퍼런스 품질, 장문, 사칭 위험을 정리합니다.
- Spark-TTS: 인공지능이 당신의 목소리를 만드는 방법 — Spark-TTS는 인공지능으로 더 자연스럽고 다양한 목소리를 만드는 혁신적인 기술입니다. 복잡한 기술을 단순화해 더 효율적으로 텍스트를 음성으로 변환합니다.
자주 묻는 질문
RTF 0.006이면 사용자가 167배 빠르게 음성을 듣나요?
아닙니다. RTF는 생성 계산의 비율이며 모델 다운로드, 적재, 텍스트 정규화, 첫 오디오 조각과 재생 준비는 포함되지 않을 수 있습니다. 종단 지연을 따로 재야 합니다.
404MB 모델을 웹에서 바로 배포해도 되나요?
대상 네트워크와 저장 공간에 따라 첫 방문 비용이 클 수 있습니다. 버전 고정, 캐시, 무결성, 저사양 기기와 WebGPU 미지원 fallback을 포함해 시험해야 합니다.
온디바이스 TTS가 클라우드 TTS보다 항상 저렴한가요?
호출 서버 비용은 줄 수 있지만 기기 CPU, 메모리, 배터리, 모델 전달, 플랫폼별 패키징과 지원 비용이 생깁니다. 실제 이용량과 대상 기기로 총비용을 비교해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.