자막용 Whisper 모델 비교: Tiny, Small, Turbo, Large-v3

Whisper는 여섯 가지 크기로 나와요. OpenAI가 밝힌 수치로 tiny는 3,900만 파라미터, base는 7,400만, small은 2억 4,400만, medium은 7억 6,900만, large는 15억 5,000만, turbo는 8억 900만이고, 앞의 네 가지에는 영어 전용 .en 버전도 있어요. 데스크톱 앱이 내려받는 faster-whisper 빌드 기준으로는 tiny의 약 78 MB부터 large-v3의 약 3.1 GB까지 이어져요.

하지만 가장 큰 모델이 자막 작업에 자동으로 가장 좋은 모델이 되는 건 아니에요. large-v3-turbo는 large-v3의 파라미터 수가 대략 절반이면서도 약 8배 빠르게 실행되고, 일반적인 영상에서는 완성된 자막 파일의 차이가 아주 작아서 결국 속도가 승부를 갈라요. 더 작은 모델이 더 큰 모델보다 나은 전사를 만들어내는 실제 사례도 있어요.

이 글에서는 구체적인 수치, 그 수치가 자막 작업에 갖는 의미, 그리고 모델을 실제보다 나쁘게 보이게 만드는 실패 사례를 차례로 살펴봐요.

나란히 놓고 보는 모델들

파라미터 수와 상대 속도는 OpenAI의 Whisper README에서 가져온 값이고, 용량은 Hugging Face에 올라온 faster-whisper(CTranslate2) 빌드의 진짜 총합이에요 — Sablate가 품질 단계별로 내려받는 것과 같은 빌드이고, 대략적인 추정치가 아니에요.

패턴을 깨는 행은 turbo예요. medium보다 파라미터가 더 많은데도 약 4배 더 빠르게 실행되는데, 이건 파라미터 수만으로는 예측할 수 없는 결과예요. Sablate의 네 가지 품질 단계는 다국어 모델을 써요. base와 .en 버전은 비교를 위해 표에 넣었어요.

영어 전용 .en 모델을 써야 할까?

OpenAI는 tiny, base, small, medium의 영어 전용 버전을 공개해요. README에 따르면 이 버전들은 영어에서 더 좋은 성능을 내는 경향이 있고, 특히 tiny.en과 base.en에서 그렇고 small.en과 medium.en에서는 그 차이가 덜 두드러져요. large와 turbo에는 .en 버전이 없어요.

자막 작업에서는 여기서 간단한 기준이 나와요. 오디오가 영어이고 작은 모델밖에 쓸 수 없는 상황이라면 — 오래된 노트북, CPU만 있는 환경, 빠른 초안 — 같은 크기와 속도에서는 .en 버전이 더 나은 선택이에요. 오디오에 다른 언어가 조금이라도 섞여 있다면 다국어 모델을 쓰세요. .en 모델은 영어밖에 모르니까요. large-v3-turbo부터 위로는 다국어 버전만 있어서 이 고민 자체가 사라져요.

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, 디스크, 그리고 내 기기로 돌릴 수 있는 모델

OpenAI의 README는 자체 PyTorch 구현 기준의 대략적인 VRAM을 알려 줘요: tiny와 base는 약 1 GB, small은 2 GB, medium은 5 GB, turbo는 6 GB, large는 10 GB예요. faster-whisper 빌드는 이보다 적게 필요하고, 위 표의 다운로드 용량은 실제로 마주치게 될 메모리 부담을 가늠하는 좋은 지표예요. 실전 기준은 이래요:

• 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를 쓸 일이 없는 사람들은 설치 파일 용량을 작게 유지할 수 있어요.

실제로 어떤 모델을 골라야 할까?

마지막 행이 계산 방식을 바꾸는 지점이에요. 전사 결과가 여덟 개 언어로 번역되는 입력이라면, 오류 하나는 오류 하나가 아니라 여덟 개예요. 다국어 작업 흐름에서 원본 전사에 왜 느린 모델과 꼼꼼한 교정이 필요한지 설명해요.

Sablate에서는 Fast와 Balanced(tiny와 small)가 무료 요금제에서 실행되고, Accurate와 Best는 Pro에 포함되며 가격 페이지에 나온 대로 $29 한 번의 결제로 이용할 수 있어요. 어떤 모델을 쓰든 결과물은 같은 편집기에 도착하고 같은 형식 — SRT, VTT, ASS — 로 내보내지니까, 모델 선택은 무엇을 만들어낼 수 있는지가 아니라 나중에 얼마나 손볼지의 문제예요.

모델을 직접 관리하고 싶지 않다면 오프라인 자막 생성기 비교에서 모델을 알아서 골라 내려받아 주는 데스크톱 앱들을 볼 수 있어요. MacWhisper 윈도우 대안과 TurboScribe 대안은 같은 선택을 앱의 관점에서 살펴봐요.

내 영상으로 직접 테스트하는 방법

5분짜리 방법이 발표된 어떤 벤치마크보다 나아요, 이 글도 포함해서:

1. 60초에서 120초 사이의, 실제 상황을 대표하는 클립을 골라요 — 가장 안 좋은 마이크, 평소에 나오는 억양, 실제로 쓰는 방이요.
2. 다른 건 그대로 두고 후보 모델 두 개로 그 클립을 전사해요.
3. 먼저 누락을 비교하고, 그다음 맞춤법 오류를 비교하세요.
4. 한 단어짜리 큐 개수를 세어보세요. 그게 쌓여 있다면 분할 문제이지 모델 문제가 아니에요.
5. 그런 다음에야 걸린 시간을 비교하고, 그 시간이 나에게 얼마의 값어치인지 판단하세요.

내 자료에서 모든 발화를 놓치지 않고 듣는 모델이 나에게 가장 좋은 모델이고, 그게 꼭 가장 큰 모델일 필요는 없어요.

자주 묻는 질문

Whisper 모델 크기에는 어떤 것들이 있나요?

OpenAI 수치로 여섯 가지예요: tiny(3,900만 파라미터), base(7,400만), small(2억 4,400만), medium(7억 6,900만), large(15억 5,000만), turbo(8억 900만)이에요. tiny, base, small, medium에는 영어 전용 .en 버전도 있어요. faster-whisper 다운로드 기준으로는 순서대로 약 78 MB, 148 MB, 486 MB, 1.53 GB이고, large-v3는 3.09 GB, turbo는 1.62 GB예요.

자막 작업에는 어떤 Whisper 모델이 가장 좋나요?

대부분의 영상에는 large-v3-turbo가 좋아요. large-v3의 15억 5,000만 파라미터에 비해 8억 900만 파라미터로 절반가량이지만 디코더가 32개 레이어에서 4개로 줄어든 덕분에 약 8배 더 빠르게 실행되고, 정확도 차이도 크지 않아서 결국 속도가 선택을 결정해요. 어려운 오디오에는 large-v3 전체 모델을, 초안 작업에는 small을 쓰세요.

large-v3가 medium이나 turbo보다 항상 더 정확한가요?

아니요. 대부분의 자료에서는 그렇지만 전부는 아니에요. 짧은 터키어 클립으로 직접 테스트해 보니 large-v3는 medium이 정확히 받아 적은 발화를 놓쳤는데, 감탄사와 클립 시작 부분의 단어들이 포함돼 있었어요. 파라미터가 많다고 항상 이긴다고 가정하기보다 실제로 쓸 영상으로 직접 테스트해 볼 만해요.

Whisper 모델마다 디스크 용량이 얼마나 필요한가요?

실제로 내려받는 CTranslate2 빌드 기준으로 tiny는 약 78 MB, base는 약 148 MB, small은 약 486 MB, medium은 약 1.53 GB, large-v3-turbo는 약 1.62 GB, large-v3는 약 3.09 GB예요. 영어 전용 .en 버전도 용량은 같아요. 전사 중 VRAM 사용량도 대체로 이 순서를 따르고, float16이나 int8 정밀도를 쓰면 사용량이 크게 줄어요.

large-v3와 large-v3-turbo는 어떻게 다른가요?

turbo는 large-v3를 가지치기하고 다시 파인튜닝한 모델로, 디코딩 레이어를 32개에서 4개로 줄였어요. 그래서 전사 품질은 비슷하게 유지하면서 훨씬 빠르게 실행돼요. 주의할 점 두 가지가 있어요: 번역 데이터 없이 파인튜닝됐기 때문에 음성 번역용으로는 만들어지지 않았고, 특히 태국어와 광둥어에서는 large-v3보다 품질이 더 떨어져요.

GPU가 있으면 Whisper가 실제로 더 빨라지나요?

네, 확실히요 — NVIDIA GPU는 같은 기기의 CPU보다 보통 5~10배 빠르게 전사해요. 이 차이가 커서 어떤 모델을 실제로 쓸 수 있는지도 바뀌어요: 긴 녹화에 large-v3를 쓰면 CPU에서는 밤새 걸리는 작업이 되지만 중급 GPU에서는 커피 한 잔 마실 시간이면 끝나요.

제 전사 결과가 왜 한 단어짜리 자막으로 쪼개지나요?

보통 모델 문제가 아니라 단어 타임스탬프 때문이에요. Whisper는 인접한 단어 사이의 간격을 정확히 0초로 내놓을 때가 많은데, 가장 큰 간격을 찾아 나누는 분할 로직은 이럴 때 진짜 간격을 찾지 못하고 매번 첫 번째 지점에서 나누는 걸 재귀적으로 반복해요. 모델은 문제가 없고, 분할 로직에 동점 처리 규칙이 필요한 거예요.