박준 · PARK JOON
프로젝트 / 음성·오디오
음성·오디오TTSMLX음성 복제STT 검증로컬 추론

대형 오픈 TTS 로컬 서버화 + 내 목소리 복제

GPU 서버 전용으로 공개된 35B MoE 음성 합성 모델을 맥에서 4bit로 돌리고, 받아쓰기 검증으로 빠진 문장을 다시 만드는 개인 TTS 서버

기간
2026.10
형태
사이드 프로젝트
상태
배포·운영 중
역할
모델 조사·라이선스 검토·서버/CLI/웹 UI 개발·품질 평가 1인 수행
실제 화면 녹화 · 개인정보와 내부 주소는 가렸습니다클릭하면 멈춤·재생
약 2배실시간 대비 생성 속도 (검증 끔)
약 32GB생성 중 최대 메모리
0~0.07CER본인 목소리 최종 QA 오류율 (용도 7종)
25%이 오류율을 넘는 문장만 다시 생성

문제

2026년 10월 공개된 오픈 TTS 모델 Drama 3(35B MoE, 활성 3B)은 공식 원본이 CUDA 전용 추론 엔진에서만 돌아서 맥에서는 그대로 쓸 수 없었습니다.

커뮤니티 4bit 변환본으로 돌려 보니 줄바꿈에서 문단이 빠지고, 끝에 클릭음이 남고, 무음 프레임이 폭주하는 문제가 있었습니다. 본인 강의 녹음을 13~17초로 잘라 목소리 레퍼런스로 쓰면 결과가 무너지는 등, 생성 결과를 사람이 일일이 듣지 않고는 믿을 수 없었습니다.

접근

  • 원본·변환본의 설정과 라이선스를 먼저 조사했습니다. 맥에서는 4bit 변환본 + mlx-audio 조합으로 가능하고, 라이선스상 남이 텍스트·목소리를 넣어 쓰는 공개 서비스는 금지라 개인 네트워크 안 개인용으로만 운영하기로 정했습니다.
  • mlx-audio의 미머지 수정 3건과 알려진 이슈(줄바꿈 문단 누락, 끝 클릭음, 첫 음절 과출력, 무음 폭주·캐시 누적)를 보강 패치로 막았습니다. 라이브러리 버전이 바뀌면 경고하게 했습니다.
  • 생성 결과를 Whisper 받아쓰기로 원문과 대조해, 문장 단위 오류율이 25%를 넘는 문장만 다시 생성하는 검증 생성을 넣었습니다. 레퍼런스를 «끝난 한 턴»으로 이력 첫머리에 두어 첫 청크 실패를 줄였습니다.
  • 긴 녹음에서 5~8초 후보를 뽑아, 감이 아니라 실제 생성 결과의 받아쓰기 오류율로 목소리 레퍼런스를 고르는 선발 도구를 만들었습니다.
  • 같은 원고로 한국어·영어·일본어 엔진 비교 평가 파이프라인(후보 생성 → 비교 청취 판정 → 고정 → 검증 생성 → 비교군 → 대시보드)을 만들었습니다.

구조

요청웹 UI 또는 CLI로 텍스트·감정 태그·화자별 목소리를 보냅니다.
모델 로드첫 요청에 모델을 올리고 15분 유휴 시 내려 메모리를 돌려줍니다.
문장 생성문장 단위로 음성을 만들고 레퍼런스를 이력 첫 턴으로 둡니다.
받아쓰기 대조Whisper로 받아써 원문과 비교하고, 오류율이 큰 문장만 다시 만듭니다.
저장결과 음성을 저장하고, 마음에 드는 결과는 새 목소리로 등록합니다.

주요 기능

검증 생성빠진 문장·엉뚱한 말을 받아쓰기로 잡아 그 문장만 다시 만듭니다. 대신 속도는 실시간의 약 0.3~1배로 느려집니다.
레퍼런스 자동 선발긴 녹음에서 후보 클립을 뽑아 생성 결과 오류율로 순위를 매기고 가장 안정적인 구간을 고릅니다.
다화자·감정 태그화자별 목소리 지정과 웃음·한숨 같은 태그를 지원해 2인 대화를 생성합니다.
발음 사전음차 정규화와 발음 사전으로 영문 약어·제품명 발음을 고정합니다.
웹·CLI·API웹 UI, 한 줄 CLI, HTTP API로 같은 서버를 쓰며, 메모리 관리를 위해 유휴 시 모델을 내립니다.

결과

  • 35B MoE 모델을 맥에서 4bit로 돌려 실시간의 약 2배 속도, 최대 메모리 약 32GB로 개인 TTS 서버를 운영하고 있습니다.
  • 본인 목소리 최종 QA에서 한국어 내레이션·장문·감정 태그·2인 대화·교육용 대화·영어·일본어 등 용도 7종의 받아쓰기 오류율이 0~0.07이었습니다. 레퍼런스를 다시 고르기 전에는 태그·대화에서 0.74~0.83이었습니다.
  • 교육 내레이션 원고로 엔진을 세 언어에서 비교한 결과, 품질 상위권은 이 모델의 원어민 목소리와 상용 TTS가 0.3점 이내로 비슷했습니다. 한 목소리로 세 언어를 모두 읽히는 것은 이 모델로는 어려웠습니다.
  • 비교 결과를 듣고 고를 수 있는 평가 대시보드와 사용 설명서를 함께 만들었습니다.

포인트

문서의 권장이 오류율과 같은 말은 아니었습니다. «레퍼런스 3개면 유사도가 오른다»는 설명과 달리 3개 묶음은 단일 최선보다 오류율이 나빴고(0.20 대 0.00), 레퍼런스 길이도 길수록 좋은 게 아니라 5~7초가 안정적이었습니다. 그래서 고르는 기준을 «결과를 받아써서 잰 오류율»로 바꿨습니다.

청취 판정은 후보를 더 넣고 다시 들으면 1위가 바뀔 만큼 흔들렸습니다. 그래서 엔진 선택을 점수 하나로 정하지 않고, 두 번 모두 상위에 든 조합과 라이선스·사용 조건을 함께 보고 결론을 냈습니다.

기술

MLXmlx-audioPythonFastAPIWhisperGemini (청취 평가)pm2Tailscale

상단 영상은 실제 화면을 녹화한 것입니다.