Phonon 온디바이스 TTS: 첫 소리는 빠른데 왜 재생이 끊길까

음성 생성이 서버 밖으로 나왔을 때 바뀌는 선택

오프라인으로 쓰는 현장 점검 앱을 생각해 보자. 화면에는 다음 작업이 나오고, 사용자가 손을 쓰는 동안 앱이 영어 안내를 읽는다. 네트워크가 끊겨도 음성이 필요하며, 다음 단계로 넘어가면 이전 안내는 즉시 멈춰야 한다. 이때 필요한 것은 좋은 목소리만이 아니다. 다운로드를 마친 상태에서 시작할 수 있는지, 긴 문장 중간에 소리가 비지 않는지, 중단한 안내가 뒤늦게 다시 들리지 않는지가 함께 중요하다.

Gradium은 2026년 11월 5일 Phonon의 공개 배포와 추론 구조를 설명하는 글을 냈다. 이날을 최초 출시일로 읽으면 안 된다. 글은 4월 발표와 약 2주 전 공개를 회고한다. 이번 설명은 기기에서 한 스트림을 처리하는 ptts와 GPU 배치 처리에 초점을 둔 Transformers 구현을 구분한다. 용도에 따라 실행 경로를 고를 수 있다는 점이 앱 개발자에게 유용하다. 공식 기술 설명

이 글은 11월 6일 확인한 문헌과 자체 계산을 바탕으로 한다. 실제 음성을 생성하거나 휴대전화·브라우저 성능을 측정하지 않았다. 아래 점검 앱도 가상 사례이며, 제공하는 결과는 모델 선택표와 재생 예산 계산, 첫 도입 시험의 입력표다.

한국어 지원과 모델 크기부터 정확히 읽기

현재 공개된 Phonon 계열의 언어는 영어·프랑스어·독일어·스페인어·포르투갈어다. 한국어는 이 목록에 없다. 공식 글의 한국어 맞춤 학습 상담 안내는 공개 체크포인트가 한국어를 지원한다는 뜻이 아니다. 공개 범위와 향후 상담

선택지	공개 언어와 가중치 조건	가상 점검 앱에서의 판단
phonon-31m-en	영어, Apache 2.0	영어 안내의 첫 비교 후보
40m 언어별 모델	각 해당 언어, CC BY-NC 4.0	상업 앱은 공개 가중치의 조건만 보고 자유 이용으로 판단하지 않기
phonon-40m-multilingual	위 다섯 언어, CC BY-NC 4.0	다국어 요구와 별도 이용 조건을 함께 검토
한국어 안내가 필수인 앱	공개 지원 언어에 없음	이 공개 모델만으로 요구 충족을 약속하지 않기

이는 31m 모델 카드의 계열 표를 정리한 것이다. 공급자는 40m 계열의 상업 이용에 별도 문의 경로를 둔다. 표는 특정 배포의 법률 판단이나 가격 견적을 대신하지 않는다. 고정 리비전 모델 카드, 공급자의 이용 조건 안내

31m은 음성 토크나이저를 제외한 파라미터 수다. 모델 카드의 64.5 MB도 model.q8.gguf라는 양자화 가중치 파일 크기다. 이를 앱 전체 다운로드나 실행 중 최대 메모리로 옮겨 적으면 예산이 틀어진다. 배포에서는 실행 코드·설정·토크나이저·음성 파일을 더하고, 실행 중에는 작업 버퍼와 재생 대기열을 따로 측정해야 한다. 크기와 출력 형식

소리는 어떻게 조금씩 나오는가

Transformers 문서에 따르면 인과적 Transformer가 텍스트와 목소리 조건을 읽고, 한 단계마다 연속적인 오디오 잠재 표현을 만든다. 이 표현을 디코더가 24 kHz 파형으로 바꾼다. 표현의 주기는 12.5 Hz로, 오디오 시간으로는 한 단계가 80 ms에 해당한다. 여기서 80 ms는 생성된 소리의 길이이며 모든 기기에서 한 단계 계산에 걸리는 시간이 아니다. 공식 구조 설명

이 구조 덕분에 문장 전체의 파형이 완성되기 전에 앞부분을 재생하는 설계가 가능하다. 그러나 사용자 경험에는 최소 세 개의 시계가 있다.

시계	시작과 끝	알아낼 수 있는 것
준비 시간	앱 시작 → 모델·음성 사용 가능	첫 다운로드·파일 읽기·초기화 부담
첫 오디오 지연	합성 요청 → 첫 오디오 청크 수신	생성기가 얼마나 빨리 출발하는지
실제 재생	재생 시작 → 마지막 소리 종료	오디오 장치 대기·버퍼 고갈·중단 동작

첫 청크를 받았어도 플레이어가 더 모아서 재생한다면 사용자가 듣는 시각은 늦어진다. 반대로 바로 틀면 시작은 빨라도 뒤의 생성이 따라오지 못할 수 있다. 따라서 “첫 소리가 빠르다”는 수치 하나로 오프라인 안내의 적합성을 판단할 수 없다.

목소리 준비도 구분할 필요가 있다. 공개 Transformers 구현의 목소리 조건은 미리 계산된 잠재 표현이며, 그 구현만으로 녹음 파일에서 새 목소리를 복제하는 기능은 제공되지 않는다. 공급자 Studio에서 음성을 준비하는 경로와 기기에서 합성하는 경로를 나누어 보아야 한다. 목소리 조건의 범위

0.4초를 쌓아 두어도 2초 뒤에 바닥나는 경우

이제 제품 성능과 무관한 가상 재생 계산을 해 보자. 재생을 시작할 때 이미 만들어 둔 소리가 0.4초 있다. 그 뒤 기기가 실제 시간 1초마다 오디오 0.8초를 만든다고 가정한다. 사용자는 정상 속도로 들으므로 1초마다 오디오 1초를 소비한다.

계산을 쉽게 하기 위해 생성과 재생을 연속적인 흐름으로 근사하고, 문장 끝·청크 도착 간격·오디오 장치 지연은 잠시 제외한다. 재생 시작 뒤 t초 시점의 남은 오디오를 B(t)라고 하면 다음과 같다.

b = 재생 시작 때 쌓인 오디오 길이(초)
r = 실제 1초 동안 새로 생성하는 오디오 길이(초/초)
B(t) = b + (r - 1) × t

b = 0.4, r = 0.8이면
B(t) = 0.4 - 0.2 × t
처음 바닥나는 시각 = 0.4 ÷ 0.2 = 재생 시작 2초 뒤

r은 공식 런타임의 성능 표처럼 “초당 만드는 오디오 초” 방향으로 읽는다. 값이 클수록 빠르다. RTF를 “계산 시간 ÷ 오디오 시간”으로 정의한 자료를 읽고 있다면 역수 관계이므로 숫자를 그대로 섞지 않아야 한다. 런타임 성능 표의 단위

같은 초기 버퍼 0.4초에서	계산 결과	실제 선택에 주는 의미
8초 안내, r=0.8 유지	끝나기 전 2초 시점에 고갈	초기 반응이 좋아도 긴 안내에는 부족할 수 있다
1.5초 안내, r=0.8 유지	생성은 1.375초 뒤 완료, 끝까지 재생 가능	짧은 한 문장 성공만으로 긴 안내를 평가하지 않기
충분히 긴 안내, r=1.25 유지	2초 뒤 버퍼 0.9초	이 근사에서는 재생 중 여유가 늘어난다
버퍼 0.4초일 때 생성만 0.6초 정지	최소 0.2초 동안 소리 부족	평균 생성 속도가 빨라도 순간 정체를 살피기

두 번째 행은 중요한 반례다. 총 1.5초 중 이미 0.4초를 만들었으므로 나머지 1.1초를 만드는 데 1.1 ÷ 0.8 = 1.375초가 걸린다. 그때 남은 0.125초를 재생하면 끝난다. 지속 속도가 재생보다 느려도 충분히 짧은 발화는 초기 버퍼로 버틸 수 있다.

반대로 8초 안내를 같은 속도로 전부 끊김 없이 들려주려면 이 이상적인 계산에서는 최소 8 × (1 - 0.8) = 1.6초의 오디오를 미리 쌓아야 한다. 이는 오디오 길이다. 처음부터 같은 속도로 만든다면 쌓는 데 실제 시간 2초가 들고, 파일 로딩 등은 별도다. 시작 대기를 늘려 끊김을 줄이는 선택이므로 무조건 좋은 해결책은 아니다.

계산은 가상 입력·결과와 실행 환경 기록으로 확인할 수 있다. 실제 스트리밍은 청크 단위이고 속도도 변한다. 특히 공식 브라우저 문서는 WebGPU 경로의 청크가 CPU의 80 ms보다 길 수 있다고 설명한다. 위 식은 도입 전 예산을 이해하는 도구이며 실제 플레이어의 안전한 버퍼 크기를 보증하지 않는다. 브라우저의 생성 경로

오프라인 준비와 멈춤을 각각 인수하기

브라우저 패키지는 첫 로드 때 파일을 내려받고 Cache API에 보관한다. 공개 모델의 리비전 조회 응답도 캐시해 이후 오프라인 로드를 지원하지만, 이것을 앱 전체의 오프라인 준비 완료로 해석하면 안 된다. 앱 문서·스크립트가 다시 열리는지와 필요한 음성 파일까지 있는지를 제품에서 따로 시험해야 한다. 40m 계열처럼 접근 승인이 필요한 모델은 브라우저의 공개 Hub 주소 로딩 경로로 바로 받을 수 없으며, 이용 조건을 수락한 뒤 파일 제공 경로를 설계해야 한다. 고정 리비전의 모델 로딩 설명

가상 점검 앱이라면 배포 전에 다음 세 상태를 나누어 본다. 최초 설치 후 바로 비행기 모드에 들어간 상태, 파일 준비를 마친 뒤 네트워크를 끊은 상태, 저장 공간 정리로 모델 파일을 잃은 상태다. 두 번째만 성공해도 “언제나 오프라인에서 시작한다”고 광고할 수는 없다. 오디오 합성이 로컬이어도 앱의 다른 통신이나 로그 전송까지 없어지는 것은 아니다.

중단에는 두 경로가 있다. 새 오디오 생성 중단과 이미 예약한 소리 제거다. Swift 문서는 소비 작업을 취소하고 플레이어의 stop()도 호출하도록 설명한다. 또한 play 반환은 생성 종료 시점이므로, 그때 플레이어를 해제하면 아직 남은 재생이 끊길 수 있다. 함수가 끝난 시각을 사용자가 안내를 다 들은 시각으로 기록하지 않아야 한다. Swift 객체 수명과 Stop 예시

이 차이를 시험하려면 이전 안내를 충분히 길게 만들고 중간에 다음 작업으로 이동한다. 새 화면에 이전 문장의 끝부분이 들리지 않는지, 새 안내가 한 번만 시작되는지를 확인한다. 이는 이 글의 시험 제안이며 실제 앱에서 성공했다고 보고하는 항목이 아니다.

첫 도입 시험에 가져갈 입력표

영어 현장 점검 앱이라면 먼저 짧은 안내, 긴 절차, 숫자·단위·코드가 있는 문장을 고정한다. 예를 들어 Read code A-017, then wait 2.5 seconds.에서 A-017을 어떤 방식으로 읽어야 하는지 사람이 먼저 정한다. 철자별 읽기와 단어처럼 읽기는 모델 품질 점수 이전에 제품 요구의 차이다. 실제 안전 작업에는 이 가상 문장을 그대로 쓰지 않는다.

다음 표를 같은 기기에서 반복하면 시작 지연과 끊김을 혼동하지 않을 수 있다. 수치는 비워 두었으며, 이번에 실행한 시험은 앞의 산술뿐이다.

시험 입력·상태	남길 관측	결과가 나쁘면 비교할 것
모델 미준비 / 준비 완료 후 재시작	다운로드·초기화·첫 소리까지 각각의 시간	사전 탑재와 첫 실행 다운로드
짧은 문장 / 긴 절차, 같은 목소리	첫 청크 시간·최소 버퍼·끊김 구간	초기 버퍼와 문장 분할, 생성 경로
같은 문장, 다른 앱도 동작 중	오디오 생성 속도 변화·메모리·발열 상태	평상시 평균과 느린 구간
숫자·코드·날짜 포함 문장	기대 읽기와 실제 청취 결과	텍스트 전처리와 언어 설정
긴 안내 중 취소 후 다음 안내	잔여 재생·새 안내 중복·재개 시점	생성 작업과 플레이어를 함께 정리했는지

실행 기록에는 모델 리비전, 실행 패키지 버전, 기기·OS, 가중치 형식, 목소리, 언어 정규화 설정을 묶어 남긴다. 이 글이 확인한 런타임 문서 커밋은 e5110afd3ead725c940b6411eec4985fb8b111aa다. 이는 설치·실행 버전이 아니라 문헌 확인 기준이다.

고정된 안내 몇 개만 읽는 앱이라면 미리 녹음하거나 합성한 파일이 더 단순할 수 있다. 반면 매번 달라지는 문장을 네트워크 없이 읽어야 하고 공개 지원 언어가 맞는다면 Phonon의 작은 모델과 로컬 실행이 검토할 이유가 된다. 최종 선택에는 목소리의 자연스러움과 함께 준비 비용·지속 재생·중단 후 다음 작업을 포함해야 한다.

지연을 단계별로 나누는 법은 AI 응답 지연 분석, 음성을 텍스트로 바꾸는 반대 방향의 과제는 전사·번역·화자 구분에서 이어 읽을 수 있다. 이 표를 다음 기기 시험에 다시 쓴다면 상단 저장 기능을 이용하고, 새 모델 분석은 AI 시스템 모음과 RSS에서 확인할 수 있다.