ブログに戻る

字幕用Whisperモデル比較:tiny・small・turbo・large-v3の違い

字幕用Whisperモデルを徹底比較。tiny・small・turbo・large-v3のパラメータ数、実際のダウンロード容量、速度を検証し、字幕作業において大きいモデルが常に最良とは限らない理由をわかりやすく解説します。

2026年9月11日
Sablate Team

Whisperモデルは、大きいものが自動的に字幕向けの最良の選択になるわけではありません。large-v3-turboのパラメータ数はlarge-v3のおよそ半分ですが、速度は約8倍で、通常の映像であれば仕上がった字幕ファイルの差はごく小さく、実質的に速度で選んで構わないレベルです。さらに、小さいモデルの方が大きいモデルより良い文字起こしを作る場面も実際にあります。

以下では、それぞれの数値が字幕作業にとって何を意味するのか、そしてモデルを実力以下に見せてしまう失敗パターンについて解説します。

各モデルを並べて比較する

パラメータ数と相対速度はOpenAIのWhisperモデルカードによるものです。一方、容量はSablateが実際にダウンロードするCTranslate2ビルドの正確な合計値であり、切り捨てた概算値ではありません。

モデルパラメータ数ダウンロード容量large-v3との速度比Sablateの品質レベル
tiny39 M約78 MB約10×Fast
small244 M約486 MB約4×Balanced
medium769 M約1.53 GB約2×turboに置き換え済み
large-v3-turbo809 M約1.62 GB約8×Accurate
large-v31550 M約3.09 GBBest

このパターンから外れているのがturbo行です。mediumより多くのパラメータを持ちながら、それでも約4倍速く動作します。これはパラメータ数だけからは予測できないことです。

turboが推奨を変える理由

turboは、ゼロから学習し直した小型モデルではありません。large-v3のデコーダーを32層から4層に削減し、同じ多言語文字起こしデータでさらに2エポック分ファインチューニングしたものです。Whisperは処理時間の大半をデコーダーで消費するため、そこを大胆に削るだけで速度は大きく向上します。一方、実際に音声を「聴く」部分であるエンコーダーには手が加えられていません。

ここには2つの注意点があり、いずれも噂ではなくOpenAI自身が明記しているものです:

  • 翻訳データを使わずにファインチューニングされている。 turboは文字起こし専用のモデルです。Whisperの音声→英語翻訳タスクを使いたい場合、turboは適した選択ではありません。元の言語で文字起こしをしてから、その後でテキストを翻訳してください — そもそもこちらの方が良いワークフローです。
  • 言語によって精度の落ち方が異なる。 turboはほとんどの言語でlarge-v2と同水準の精度を保ちますが、タイ語と広東語では目に見えて精度が落ちます。これらの言語を扱う場合は、採用前に必ず検証してください。

それ以外の場面では、turboが字幕作業の合理的な既定選択です — large-v3に近い品質を保ちながら、2時間の録音でも現実的な作業時間で処理できる速度があります。

一番大きいモデルが、一番良い字幕を作るのか

必ずしもそうではありません。その例外を知っておく価値があるのは、実際に遭遇するとバグに見えてしまうからです。

この検証は、101秒のトルコ語クリップを対象に、RTX 3060 Tiでfloat16を使い、アプリ自体の文字起こしパスを通して行いました。各モデルが実際にどれだけの発話を捉えられたかで順位をつけると、mediumが最も優れていました。large-v3mediumが正しく文字起こしできていた発話を取り落としており、クリップ冒頭の言葉やいくつかの短い相づちがそのまま消えていました。よく使われる調整をひとつずつ試しましたが、いずれも効果はありませんでした:音声区間検出(VAD)フィルターの無効化、no-speech閾値の上昇、対数確率(log-probability)閾値の除外、temperatureの固定です。対数確率閾値を外すとむしろ大幅に悪化し、文字起こしはおよそ1,110文字から429文字まで減少しました。

さらに、large-v3の代わりにlarge-v2を使うべきだという、コミュニティでよく言われるアドバイスも検証しました。このクリップでは、large-v2が全モデル中最悪の結果でした:28.7秒から58.7秒までの30秒間の発話をまるごと欠落させ、mediumが178語を書き出したのに対し、わずか106語しか出力しませんでした。

1本のクリップはベンチマークにはなりません。しかも今回のクリップは短く、トルコ語で、雑談的な内容でした。ここから受け取るべきはランキングではなく手法です: 同じファイルを2つのモデルで文字起こしし、スペルミスよりも欠落を先に確認し、すべてを聞き取れていたモデルを選んでください。字幕においては、欠落の方が誤字よりもはるかにコストが高くつきます。視聴者は誤った単語なら読み飛ばせますが、そもそも存在しない行は読めないからです。

良いモデルが悪く見えてしまうとき

「大きいモデルの方が悪い」という不満の裏には、モデル自体とは関係のない3つの失敗パターンがあります。

1. 単語タイムスタンプの同着が行分割を壊す。 Whisperは単語ごとにタイムスタンプを出力しますが、隣り合う単語がまったく同じ境界を共有することが頻繁にあります — 検証したクリップでは、177個の単語間ギャップのうち172個がちょうど0.000秒でした。長いキューを最大のギャップで分割するスプリッターは、そのため候補がすべて同着になってしまい、最初の1つを選んでは再帰的に分割を続けます — 1語ずつ剥がしていくような形です。症状としては、文字起こしがすべて単語1つの字幕に切り刻まれてしまい、単語数の多いモデルほどこの症状はひどくなります。同着判定を時間的な中間点を優先する方式に修正したところ、あるクリップでは90キュー(そのうち78個が単語1つ)から、単語1つの行が1つだけ残る28キューまで改善しました。モデルの方は何も変えていません。

2. 選んだはずのモデルが、実際に動いたモデルではない。 モデルのリポジトリ名は、ダウンロード用のレジストリと推論ライブラリの間で一貫していません。あるリポジトリ名でディスク上にダウンロード済みのモデルがあっても、ローダーが別の名前で検索していると、サイレントフォールバックが起きるか、ネットワークの問題のように見えるエラーが返ってきます — しかも正しいモデルの1.6 GBは、すでにディスク上に存在しているのです。

3. 再文字起こしが失敗すると、古い文字起こしが画面に残り続ける。 再実行が失敗し、アプリがジョブをロールバックしても、要求したモデル名だけが表示され続けると、実際には前のモデルの出力を新しいモデルの結果として見ていることになります。この状態から行う比較はすべて誤りです。ベンチマークを行うなら、結論を出す前にテキストが実際に変わったことを確認してください — 異なる2つのモデルから同じ出力が返ってくるのは、発見ではなく警告サインです。

VRAM・ディスク容量と、自分のマシンで動くもの

上の表にあるダウンロード容量は、文字起こし中のメモリ負荷の目安としても使えます。実用的な指針は次のとおりです:

  • VRAM 4 GB以下、または専用GPUなしsmallが最適です。tinyは下書きやタイミング確認用で、納品には向きません。
  • VRAM 6〜8 GBlarge-v3-turboを余裕をもって動かせます。多くの人にとって、ここが標準の構成になるはずです。
  • VRAM 10 GB以上 — 音声が本当に必要としている場合に限りlarge-v3を。強いアクセント、話者の重なり、質の悪いマイクなどが対象です。
  • GPUなし、CPUのみ — 今日中に必要な作業にはsmallを、放置しておける作業にはturboを。

ここでは精度もモデルサイズと同じくらい重要です。Whisperが動作するCTranslate2ビルドはfloat16とint8に対応しており、精度を落とすとメモリ使用量は大きく減ります。その代償は、int8ではわずかで、GPU上のfloat16ではほとんど気づかないレベルです。

GPUを使うと、同じマシンのCPU実行に比べておおよそ5〜10倍の高速化が見込めます。WindowsのSablateでは、NVIDIA CUDAランタイムはインストーラーに同梱されず、GPUでの実行が最初に行われたときにダウンロードされます。これにより、GPUを使わない人にとってはダウンロード容量が小さく保たれます。

結局、どのモデルを選ぶべきか

状況モデル理由
タイミングの確認やキャプションスタイルを試すときtiny数秒で終わる。ここでは精度は関係ない
明瞭な発話、話者1人、良いマイクsmall高速。残りはエディタで直せる
納品用字幕の既定モデルlarge-v3-turbolarge-v3に近い精度を、約8倍の速度で
アクセント、ノイズ、話者の重なりlarge-v3余分なパラメータがここで生きてくる
タイ語または広東語large-v3turboの弱点として明記されている言語
他言語への翻訳の元になる文字起こし出せる中で最も高精度なモデルすべての誤りが、すべての言語に伝わってしまう

最後の行が、計算を変える行です。文字起こしが8言語への翻訳の入力になる場合、1つの誤りは1つの誤りではなく、8つの誤りになります。多言語ワークフローでは、元になる文字起こしにこそ、遅いモデルと丁寧な確認作業をかけるべき理由を解説しています。

Sablateでは、Fast と Balanced(tinysmall)は無料プランで使えます。Accurate と Best はProの機能で、$29の一度きりの支払いで使えるようになります — 詳細は料金ページをご覧ください。どのモデルを使っても、結果は同じエディタに届き、同じ形式で書き出されます — SRT・VTT・ASSです。つまりモデル選びが左右するのは、その後どれだけ修正作業をするかであって、何が作れるかではありません。

自分の映像でこれを検証する方法

5分の検証手順は、この記事を含むどんな公開ベンチマークよりも当てになります:

  1. 60〜120秒の、実際の条件を代表するクリップを用意する — 一番悪いマイク、いつものアクセント、実際に使っている部屋で。
  2. それを候補となる2つのモデルで文字起こしする。他の条件は何も変えない。
  3. まず欠落を、次にスペルミスを比較する。
  4. 単語1つだけのキューの数を数える。それが多ければ、原因はモデルではなく分割処理にある。
  5. そのあとで初めて実際の処理時間を比較し、その時間に対する価値を自分自身で判断する。

自分の素材のすべてを聞き取れるモデルこそが、自分にとって最良のモデルです。そしてそれは、必ずしも一番大きいモデルではありません。