음성 클로닝 오픈모델, VRAM보다 RTF·동시성이 진짜 예산이다

음성 클로닝 오픈모델의 VRAM은 다른 모델과 반대로 벽이 아니다 — 모델이 작기 때문이다. 실측 핵심 셋: ① Chatterbox는 2~3GB, XTTS-v2는 4~6GB로 어지간한 GPU에 들어가고, Kokoro 같은 초경량은 1GB 미만이라 CPU에서도 돈다(무거운 건 Bark 8~12GB·Dia 10~14GB뿐). ② 그래서 진짜 예산은 저장이 아니라 실시간 인자(RTF)와 지연이다 — XTTS-v2는 측정상 RTF 0.3(4090)·첫 오디오 150~400ms, Chatterbox는 최적화 시 sub-300ms다. ③ 그리고 동시성이 진짜 병목이다: 실시간은 사실상 GPU당 1요청이라, 큰 GPU 하나가 아니라 인스턴스를 늘려 수평 확장한다. 즉 질문이 "들어가나"가 아니라 "충분히 빠른가·몇 스트림인가"로 바뀐다.

한 줄 요약: 음성 클로닝은 성우 부스 같다. 부스(모델)는 작아 방에 여러 개 들어가지만, 한 부스에서 동시에 두 사람이 녹음하면 소리가 겹친다(동시성 한계). 그래서 사람이 늘면 부스(GPU 인스턴스)를 늘리지, 부스 하나를 키우지 않는다.

음성 클로닝 VRAM은 왜 벽이 아닌가?#

TTS 모델이 수백 M~2B로 작기 때문이다. 파이프라인은 텍스트 인코더+음향 모델(AR 백본·플로매칭)+뉴럴 코덱/보코더인데, 각 조각이 작아 총합이 Chatterbox 2~3GB·XTTS 4~6GB다. LLM(수십 GB)이나 이미지 모델(Flux 24GB)과 차원이 다르다. 그래서 "VRAM이 되나"는 대부분 문제가 안 되고, 8GB면 가벼운 동시성으로 자체 호스팅이 된다. CPU로도 되지만 느려서 RTF가 1을 넘어 실시간이 깨진다 — 실시간이 목표면 GPU가 답이다.

모델별 VRAM 크기를 나란히 막대로 보면, 클로닝 모델이 LLM·이미지 모델과 얼마나 다른 리그인지 한눈에 들어온다.

그럼 진짜 예산은 무엇인가?#

실시간 인자(RTF)와 첫 오디오 지연이다. RTF는 '오디오 길이 대비 생성 시간'으로, 1보다 작아야 실시간 스트리밍이 된다 — XTTS-v2는 측정상 RTF 약 0.3(여유가 적고 첫 청크가 늦음), Kokoro는 0.03으로 10초를 0.3초에 만든다. 첫 오디오 지연도 중요하다: XTTS 클로닝은 GPU에 따라 150~400ms(3090 190ms→5090 135ms), Blackwell이 Ampere보다 30~40% 낮다. 대화형 음성 에이전트는 sub-200ms 첫 오디오가 목표라, 여기선 VRAM보다 GPU 세대와 스트리밍 설계가 성패를 가른다.

RTF 1을 기준선으로 놓으면 왜 CPU가 실시간을 깨고 GPU가 여유를 갖는지 명확하다 — 아래에서 막대가 점선(RTF=1) 아래여야 실시간이다.

왜 동시성이 병목인가?#

실시간 TTS는 GPU 인스턴스당 활성 요청이 사실상 하나이기 때문이다. 모델이 작아도 두 요청이 병렬로 붙으면 지연이 무너진다(Chatterbox는 2병렬을 넘으면 열화). 그래서 확장 규칙이 다르다 — 큰 단일 GPU가 아니라 GPU 인스턴스를 늘리고, 큐로 스파이크를 흡수한다. 스트리밍은 문장 경계에서 버퍼링해 LLM이 뒷부분을 만드는 동안 앞 문장을 들려줘 체감 지연을 줄인다. 즉 음성 서비스의 사이징은 'VRAM'이 아니라 '동시 스트림 × GPU 인스턴스'로 한다.

우리가 운영하는 오픈 TTS 스택(Fish Speech·MOSS-TTS·Higgs Audio·Qwen3-TTS)도 같은 규칙으로 사이징한다 — 어느 모델이든 GPU당 스트림을 1로 보고 인스턴스로 수평 확장하며, 큐로 스파이크를 흡수한다.

음성 에이전트 스택엔 얼마나 드나?#

핵심은 TTS는 스택에서 가장 작은 조각이라는 것이다.

• 단독 TTS: 8GB면 경량 동시성, 16~24GB면 다중 보이스·높은 처리량.
• 풀 스택(ASR+LLM+TTS): Whisper Large(5~8GB)+Llama 11B(~22GB)+XTTS(~6GB)≈33~36GB라 24GB로는 빠듯(H100 80GB 권장). LLM이 VRAM을 지배하고 TTS는 덤이다.
• 규칙: 모델 선택보다 RTF·동시성·GPU 세대로 설계하고, 정확한 처리량은 내 텍스트·부하로 직접 재라.

풀 스택 VRAM을 쌓아 보면 왜 TTS 걱정이 번지수를 잘못 짚은 건지 분명하다 — 아래처럼 덩치의 대부분은 LLM이고 TTS는 맨 위 얇은 층이다.

함께 읽기: 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고, 오픈 음성 클로닝 파이프라인: 직접 써보고 느낀 점과 한계

함께 읽기: 로컬 음성합성(TTS) 오픈모델 — VRAM·RAM 요구량 실측, Ollama·LM Studio·llama.cpp 실행기 VRAM·RAM 실측

참고 링크

• Chatterbox(오픈 클로닝·MIT)
• Coqui XTTS(다국어 클로닝)
• Chatterbox-TTS-Server(셀프호스팅·동시성)
• Kokoro(초경량 TTS)
• F5-TTS(플로매칭 클로닝)

참고: VRAM·RTF·지연 수치는 2026년 공개 벤치(상당수 벤더 측정)·추정이며 GPU·텍스트 길이·동시성에 따라 달라진다(영구 수치 아님, Chatterbox sub-200ms 등은 최적화 자체보고). 정확한 처리량·지연은 내 하드웨어·부하로 직접 부하테스트하라(여기 수치는 출발점). XTTS는 Coqui 종료 후 커뮤니티 유지·라이선스 확인 필요. TTS 스택은 빠르게 바뀌니 분기별로 다시 본다.