자막용 Whisper 모델 비교: Tiny, Small, Turbo, Large-v3
자막용 Whisper 모델을 비교해요: tiny, small, turbo, large-v3의 파라미터 수, 실제 다운로드 용량, 속도를 정리했고, 큰 모델이 항상 더 낫지는 않은 이유도 다뤄요.
가장 큰 Whisper 모델이 자막 작업에 자동으로 가장 좋은 모델이 되는 건 아니에요. large-v3-turbo는 large-v3의 파라미터 수가 대략 절반이면서도 약 8배 빠르게 실행되고, 일반적인 영상에서는 완성된 자막 파일의 차이가 아주 작아서 결국 속도가 승부를 갈라요. 더 작은 모델이 더 큰 모델보다 나은 전사를 만들어내는 실제 사례도 있어요.
이 글에서는 구체적인 수치, 그 수치가 자막 작업에 갖는 의미, 그리고 모델을 실제보다 나쁘게 보이게 만드는 실패 사례를 차례로 살펴봐요.
나란히 놓고 보는 모델들
파라미터 수와 상대 속도는 OpenAI의 Whisper 모델 카드에서 가져온 값이고, 용량은 Sablate가 실제로 내려받는 CTranslate2 빌드의 진짜 총합이에요 — 대략적인 추정치가 아니에요.
| 모델 | 파라미터 | 다운로드 | large-v3 대비 속도 | Sablate 품질 단계 |
|---|---|---|---|---|
tiny | 3,900만 | ~78 MB | ~10× | Fast |
small | 2억 4,400만 | ~486 MB | ~4× | Balanced |
medium | 7억 6,900만 | ~1.53 GB | ~2× | 대체됨 |
large-v3-turbo | 8억 900만 | ~1.62 GB | ~8× | Accurate |
large-v3 | 15억 5,000만 | ~3.09 GB | 1× | Best |
패턴을 깨는 행은 turbo예요. medium보다 파라미터가 더 많은데도 약 4배 더 빠르게 실행되는데, 이건 파라미터 수만으로는 예측할 수 없는 결과예요.
turbo가 추천을 바꾸는 이유
turbo는 처음부터 다시 학습한 더 작은 모델이 아니에요. large-v3의 디코더를 32개 레이어에서 4개로 가지치기한 다음, 같은 다국어 전사 데이터로 두 에포크 더 파인튜닝한 모델이에요. Whisper는 시간을 대부분 디코더에서 쓰기 때문에 디코더를 이렇게 크게 잘라내면 속도가 아주 크게 좋아지는 반면, 실제로 듣는 부분인 인코더는 그대로 남아 있어요.
여기에는 주의할 점 두 가지가 따라오는데, 둘 다 OpenAI가 문서로 밝힌 내용이고 소문이 아니에요:
- 번역 데이터 없이 파인튜닝됐어요. turbo는 전사 모델이에요. Whisper의 음성-영어 번역 기능이 필요하다면 turbo는 맞는 도구가 아니에요 — 원어로 전사한 다음 그 텍스트를 나중에 번역하는 편이 어차피 더 나은 작업 순서예요.
- 일부 언어는 다른 언어보다 더 많이 나빠져요. turbo는 대부분의 언어에서
large-v2와 비슷한 성능을 보이지만 태국어와 광둥어에서는 눈에 띄게 더 떨어져요. 이 언어로 작업한다면 실제로 쓰기 전에 먼저 테스트하세요.
그 외의 모든 경우에는 turbo가 자막 작업의 합리적인 기본값이에요: large급에 가까운 품질을, 두 시간짜리 녹화도 현실적인 작업으로 만들어 주는 속도로 얻을 수 있으니까요.
가장 큰 모델이 가장 좋은 자막을 만들어줄까?
항상 그런 건 아니고, 이 예외는 알아둘 만해요 — 실제로 마주치면 버그처럼 보이니까요.
RTX 3060 Ti에서 float16으로, 앱 자체의 전사 경로를 그대로 거쳐서 101초짜리 터키어 클립으로 측정했어요. 실제로 발화를 얼마나 놓치지 않고 잡아냈는지를 기준으로 순위를 매기면 medium이 1위였어요. large-v3는 medium이 정확히 받아 적은 발화를 놓쳤는데 — 클립 시작 부분의 단어들과 짧은 감탄사 여럿이 그냥 나타나지 않았어요. 흔히 쓰는 방법 중 어떤 것도 그 단어들을 되살리지 못했어요: 음성 활동 감지(VAD) 필터 끄기, 무음 임계값 올리기, 로그 확률 임계값 없애기, temperature 고정하기까지 다 해봤어요. 로그 확률 임계값을 없앴을 때는 오히려 훨씬 나빠져서 전사 결과가 약 1,110자에서 429자로 줄어들었어요.
large-v3 대신 large-v2를 쓰라는, 커뮤니티에서 흔히 도는 조언도 테스트해 봤어요. 이 클립에서는 그게 가장 나빴어요: 28.7초부터 58.7초까지 이어지는 30초 구간 전체를 통째로 빠뜨려서 medium이 178단어를 받아 적은 자리에 106단어만 남았어요.
클립 하나로는 벤치마크가 될 수 없고, 이 클립은 짧고, 터키어였고, 대화체였어요. 순위보다는 방법을 가져가세요: 같은 파일을 두 모델로 전사하고, 맞춤법보다 무엇이 빠졌는지를 먼저 보고, 모든 발화를 놓치지 않은 모델을 고르세요. 자막에서는 누락이 오타보다 훨씬 비싼 대가를 치르게 하는데, 시청자는 잘못된 단어는 읽고 넘어갈 수 있어도 존재하지 않는 줄은 읽을 수 없기 때문이에요.
좋은 모델이 나쁜 모델처럼 보일 때
모델과는 아무 상관 없는데도 "큰 모델이 더 나쁘다"는 불만을 만드는 실패 사례가 세 가지 있어요.
1. 단어 타임스탬프의 동점이 줄 나누기를 망가뜨려요. Whisper는 단어별 타임스탬프를 내놓는데, 인접한 단어들이 경계를 정확히 공유하는 경우가 자주 있어요 — 살펴본 클립에서는 177개의 단어 간격 중 172개가 정확히 0.000초였어요. 가장 큰 간격에서 긴 큐를 나누는 분할 로직은 그래서 모든 후보가 동점이라는 걸 발견하고 첫 번째 후보를 택한 다음 재귀적으로 반복하면서 — 한 단어씩 계속 떼어내요. 그 증상은 전사 결과가 한 단어짜리 자막들로 잘게 쪼개지는 것이고, 단어를 더 많이 만들어내는 모델일수록 더 심해져요. 동점 처리 기준을 시간상 중간점을 우선하도록 고쳤더니 한 클립이 90개 큐(그중 78개가 한 단어짜리)에서 한 단어짜리 줄이 하나뿐인 28개 큐로 줄었어요. 모델은 전혀 바뀌지 않았어요.
2. 선택한 모델과 실제로 실행된 모델이 달라요. 모델 저장소는 다운로드 레지스트리와 추론 라이브러리 사이에서 이름이 서로 다르게 붙어요. 디스크에는 한 저장소 이름으로 내려받은 모델이 있는데 로더는 다른 이름을 찾고 있으면, 조용히 다른 모델로 넘어가거나 네트워크 문제처럼 보이는 오류가 나요 — 정작 올바른 모델 1.6 GB는 이미 디스크에 있는데도요.
3. 재전사가 실패하면 화면에는 예전 전사 결과가 그대로 남아요. 다시 실행한 작업이 실패해서 앱이 그 작업을 되돌리면서도 요청했던 모델 이름은 그대로 남겨두면, 지금 보고 있는 건 이전 모델의 결과인데 새 모델의 결과라는 이름표가 붙어 있는 상태예요. 그 상태에서 비교한 결과는 전부 틀려요. 벤치마크를 하고 있다면 결론을 내리기 전에 텍스트가 실제로 바뀌었는지 먼저 확인하세요 — 서로 다른 두 모델에서 똑같은 결과가 나온다면 그건 발견이 아니라 위험 신호예요.
VRAM, 디스크, 그리고 내 기기로 돌릴 수 있는 모델
위 표의 다운로드 용량은 전사 중 메모리 부담을 가늠하는 지표로도 쓸 만해요. 실전 기준은 이래요:
- VRAM 4 GB 이하, 또는 전용 GPU 없음 —
small이 가장 균형 잡힌 선택이에요.tiny는 초안 작성과 타이밍 확인용이고 실제 결과물용은 아니에요. - VRAM 6~8 GB —
large-v3-turbo를 여유롭게 돌릴 수 있어요. 대부분의 사람에게 맞는 구성이에요. - VRAM 10 GB 이상 — 오디오가 정말로 필요로 한다면
large-v3를 쓰세요: 억양이 강하거나, 화자가 겹치거나, 마이크 음질이 나쁠 때예요. - CPU만 있을 때 — 지금 당장 필요한 작업에는
small, 켜 두고 기다릴 수 있다면turbo예요.
여기서는 정밀도도 모델 크기만큼 중요해요. Whisper가 실행되는 CTranslate2 빌드는 float16과 int8을 지원하고, 정밀도를 낮추면 메모리 사용량이 크게 줄어드는데 그 대가는 int8에서는 작고 GPU에서 float16을 쓰면 보통 눈에 띄지 않아요.
GPU에서는 같은 기기의 CPU보다 대략 5~10배 빨라질 거예요. Windows용 Sablate에서는 NVIDIA CUDA 런타임이 설치 파일에 포함되지 않고 GPU로 처음 작업을 실행할 때 다운로드되는데, 이 방식 덕분에 GPU를 쓸 일이 없는 사람들은 설치 파일 용량을 작게 유지할 수 있어요.
실제로 어떤 모델을 골라야 할까?
| 상황 | 모델 | 이유 |
|---|---|---|
| 타이밍 확인이나 캡션 스타일 테스트 | tiny | 몇 초 안에 끝나고, 정확도는 여기서 중요하지 않으니까요 |
| 발화가 또렷하고 화자 한 명, 좋은 마이크 | small | 빠르고, 나머지는 편집기에서 고치면 되니까요 |
| 완성된 자막의 기본값 | large-v3-turbo | 속도는 약 8배 빠르면서 정확도는 large급에 가까우니까요 |
| 억양, 잡음, 화자 겹침 | large-v3 | 여기서는 늘어난 파라미터가 제 값을 하니까요 |
| 태국어나 광둥어 | large-v3 | turbo가 문서로 밝힌 약점이니까요 |
| 다른 언어로 번역할 원본 | 감당할 수 있는 한 가장 정확한 모델 | 오류 하나가 모든 언어로 퍼지니까요 |
마지막 행이 계산 방식을 바꾸는 지점이에요. 전사 결과가 여덟 개 언어로 번역되는 입력이라면, 오류 하나는 오류 하나가 아니라 여덟 개예요. 다국어 작업 흐름에서 원본 전사에 왜 느린 모델과 꼼꼼한 교정이 필요한지 설명해요.
Sablate에서는 Fast와 Balanced(tiny와 small)가 무료 요금제에서 실행되고, Accurate와 Best는 Pro에 포함되며 가격 페이지에 나온 대로 $29 한 번의 결제로 이용할 수 있어요. 어떤 모델을 쓰든 결과물은 같은 편집기에 도착하고 같은 형식 — SRT, VTT, ASS — 로 내보내지니까, 모델 선택은 무엇을 만들어낼 수 있는지가 아니라 나중에 얼마나 손볼지의 문제예요.
내 영상으로 직접 테스트하는 방법
5분짜리 방법이 발표된 어떤 벤치마크보다 나아요, 이 글도 포함해서:
- 60초에서 120초 사이의, 실제 상황을 대표하는 클립을 골라요 — 가장 안 좋은 마이크, 평소에 나오는 억양, 실제로 쓰는 방이요.
- 다른 건 그대로 두고 후보 모델 두 개로 그 클립을 전사해요.
- 먼저 누락을 비교하고, 그다음 맞춤법 오류를 비교하세요.
- 한 단어짜리 큐 개수를 세어보세요. 그게 쌓여 있다면 분할 문제이지 모델 문제가 아니에요.
- 그런 다음에야 걸린 시간을 비교하고, 그 시간이 나에게 얼마의 값어치인지 판단하세요.
내 자료에서 모든 발화를 놓치지 않고 듣는 모델이 나에게 가장 좋은 모델이고, 그게 꼭 가장 큰 모델일 필요는 없어요.