汎用モデルという器は、字幕には無駄が多すぎる

この記事は、自社ブログの LYR Performance Note #032 に掲載したものの転載です。

圧縮では埋まらない床が見えた——次に削るのはパラメータでなく「汎用」のほう

圧縮を一切かけない素のままの自前モデル（80億パラメータ＝8B）でも、致命的な誤訳は97件中15件残った。同じ難所で、3倍以上大きい汎用モデル（270億＝27B）は4件だった。 圧縮の強さをどう変えても、この15件は動かない。

図1：圧縮を完全に外しても、床は戻らなかった（韓国語→日本語の難所97件・盲検）。自前8Bは、圧縮を一切かけない素のままでも致命的な誤りが15件。中くらいの圧縮（14件）とも、強い圧縮とも統計的に区別できなかった。一方、汎用27Bは4件——素のままの8Bに対して有意に少ない（p=0.015）。
注：判定は別系統の大型モデルによる盲検、同一ラウンド。学習データとの重複が疑われる件を除外した実効n=97。件数は致命的な誤り（主語・意味の取り違え等、字幕として成立しない訳）のみを数えたもので、平均品質ではない。圧縮の3段階は順にINT4／INT8／BF16（＝圧縮なし）。強い圧縮と素のままの差も有意でなかった（p=0.22）。

つまり、この床——最悪のケースがどこで止まるか——を作っていたのは、圧縮ではなくモデルのサイズ（容量）のほうだった。私はこれまで、品質が崩れるたびに「圧縮のせいではないか」を疑い、実際に手を打ってきた——回転（rotation）という補正で圧縮の誤差をならし、大事故を64%→24%まで削ったのがその代表だ。その線は、ここで消えた。

だが「サイズを上げる」に戻る前に、疑う先がもう一つある。器（アーキテクチャ）そのものだ。字幕は短文・制約・有界文脈の仕事なのに、私たちは任意長の自由生成のために設計された汎用LLMを、そのまま使っている。仮説はこうだ——汎用という無駄を削れば、いまより小さいモデルで、いまより良い字幕が出せる。

そして期待しているのは、速さだけではない。LYRが目指しているのは、人間のプロ翻訳家が付けたレベルの字幕が、いま観ている映像にそのまま流れてくるという体験だ。プロの品質そのものは、待てば手に入る。ただしその「待ち」は、翻訳者の手配から下訳・校正・タイミング調整・権利処理まで積み上がって、公開から数週間、作品によっては数ヶ月だ。そして——そもそも自分の言語に訳されない作品のほうが、圧倒的に多い。プロの字幕は採算の合う言語と作品にしか付かないので、多くの人にとって「待てば手に入る」ですらない。だから視聴者は、観たい瞬間に観られないか、粗い自動字幕で妥協するかを選ばされている。逆に、リアルタイムなら今すぐ手に入る——品質を諦めるなら。この2つが同時に成り立つとき、はじめて魔法になる。

だから見ているのは、ネイティブが指摘した「意味は通じるが感情が硬い」、そして画面を見れば自明なのに原文からは復元できない話者の性別——この2つは、器を替えて初めて手が届くと考えている。

ただし正直に書く。本稿は実測の記録ではなく、設計仮説だ。アーキテクチャの当たりはある程度ついたが、自分の言語ペアでのデータ点はまだ無い。だから最後に、何が出たらこの仮説を捨てるかまで書く。

ここまでの前提——借り物を出て、小さく速くするところまでは来た

前提を短く。LYRは、スマートフォン上のテキストをリアルタイムに翻訳する製品だ。使われ方は3通りある——動画に流れる字幕を1行ずつ訳すLive、画面のテキストをまとめて訳すPage、コマ割りされた漫画のセリフを訳すManga。同じ翻訳モデルが、この3つを兼務している。

そのうえで、ここまでの道のりを1段落で畳んでおく。ただしこの記事はモデルの話に限る。速さもコストも、実際にはモデルの外側——待ち行列、距離、端末上の処理、呼ぶ回数そのもの——で大きく削ってきたし、そちらのほうが効いた場面も多い（インフラ・OCRの各カテゴリに譲る）。ここでは、その全体最適の中のモデルという一層だけを縦に辿る。

モデルに限って言えば、最初の一歩は外部の翻訳APIを横並びで比べて、速いものを選ぶことだった（品質を測る前に、失格になるAIがある）。次に、借り物は退役と値上げで消えるという壁に当たって、自前のGPUへ移した。そこから、4分の1に圧縮しても賢さはほぼ落ちないことを確かめ、生成の速さを決めているのはパラメータ数でなく重みのバイト数だと突き止めた。品質側では、素の小型モデルを42%→84%へ引き上げ、Live字幕という1点に絞れば8Bが27Bと引き分けるところまで来た。

つまり「汎用の巨大モデルでなくても、一芸なら小さいモデルで足りる」は、部分的にはもう実証されている。この記事は、その先の話だ。一芸に絞るのを、学習データだけでなく器（アーキテクチャ）まで押し込めるか。

仮説——基盤モデルは、字幕に対してマルチタスクすぎる

いまのLLMは、詩も書くしコードも書くし数学もする。その汎用性のために、どんな長さの・どんな形式の文章でも書き出せる設計になっている。

字幕の仕事は、その真逆だ。

汎用LLMが前提にしていること	字幕という仕事の実際
出力の長さは自由（数語〜原稿用紙数十枚）	1〜2行。表示時間に収まる長さに縛られる
出力の形式は自由	形式は固定。訳文だけを返す
参照する文脈はいくらでも長くできる	前後数発話ぶんしかない
応答は数秒待てる	発話に追従するリアルタイム
世界中のあらゆるタスクを解く	1本の訳を作る

この不一致を、私は汎用税と呼んでいる。払い方は2つある。

1つ目は、無駄なデータの読み出しとして払う。 モデルは文字を1つ書き出すたびに、自分の中身（重み＝膨大な数値）を丸ごと読み直している。だから生成の速さは、計算の重さではなく読み出すデータ量で決まる（生成の速さは重みのバイト数で決まる）。詩やコードや数学のための数値も、字幕を1文字出すたびに一緒に読み出されている。使わない能力の分まで、毎文字、運び賃を払っているということだ。

2つ目は、「速さか、品質か」の二択として払う。 いまは、速いモデルを選べば訳が荒くなり、正確なモデルを選べば遅くなる。この交換レートは動かせないものに見える。だが、これは字幕という仕事に備わった法則ではない。いま使っている汎用の器が、たまたまそのレートの上に乗っているだけだ。器を替えれば、レートごと変わる余地がある（Paretoの見方）。

これは、LYRだけの問題ではないと思っている。基盤モデルを「そのまま製品に載せる」段階が一巡した先で、用途ごとに器を切り直すのは、いま各社が同時に踏んでいる地面のはずだ。私はそれを、字幕という一点から見ている。

だが「小さくして同性能」は無条件ではない——2つの反証

仮説に都合の悪い実測を、先に置く。

反証1：特化は配分の組み替えであって、無料ランチではない。 Live（動画字幕）の成功率を90→96に上げた同じ学習が、残りの2つ——Page（画面まとめ訳）とManga（コマのセリフ）——を各−4崩した（小さな専門家が、現役最強と肩を並べた、機序はモード混合）。1つの器で複数の仕事を兼務する限り、上げた分はどこかを削って生まれている。

反証2：特化では埋まらない層がある。 完璧な文脈を渡しても深い読解は埋まらなかったし（「文脈を足せば賢くなる」は半分ウソだった）、日本語の主語省略や慣用句の読解は容量そのものを要求した（いちばん苦手な言語で律速を見抜く）。「磨けば直る」問題と「容量が要る」問題は、別物だ。

だから問いはこうなる——残っている差のうち、どこまでが容量で、どこからが汎用税なのか。 混ぜたまま「器を替えれば全部良くなる」と言うのは、診断の放棄だ。まずそこを切り分けた。

決着——床は、量子化ではなく容量だった

切り分けの第一手は、量子化を容疑者から外すことだった。

まず、量子化とは何かを一言で。AIモデルの中身は、膨大な数値の集まりだ。量子化は、その数値を粗い目盛りで持ち直して、モデルを軽く詰め直すこと（4分の1に圧縮しても、賢さはほぼ落ちない）。写真をJPEGで保存し直すのに似ている——容量は劇的に減るが、細部はわずかに失われる。本番のモデルは、この圧縮をかけた状態で動いている。速く・安くなるからだ。

そして私はこれまで、品質が崩れるたびに、まずこの圧縮を疑ってきた。実際、学習と本番で圧縮の条件がずれていたことも、圧縮が大事故（床）を増やしていたことも観測している。後者では回転という補正で大事故を64%→24%まで削ったが、圧縮前の水準（12%）には届かなかった——その残り半分は、圧縮の削り残しなのか、それとも別の原因なのか。ならば、圧縮を完全に外せば、床は戻るのか。言い換えれば——細部が1ビットも失われていない、素のままの8Bなら、あの致命的な誤りは消えるのか。

韓国語→日本語の難所100件（学習データとの重複などを除いた実効97件）を訳させ、どの構成の訳かを伏せたまま判定した。比べたのは、同じ自前8Bを強い圧縮／中くらいの圧縮／圧縮なし（素のまま）の3段階で回したものと、汎用の27Bだ。数えたのは平均点ではなく、致命的な誤りの件数——主語や意味を取り違え、字幕として成立しない訳だ。平均点は、こういう「まれな大事故」を薄めて見えなくしてしまう（天井でなく床を上げる）。

結果が、冒頭に載せた図1だ。数字だけをもう一度置く。

構成	致命的な誤り（97件中）
自前8B・強い圧縮（本番と同じ設定）	素のままと差なし
自前8B・中くらいの圧縮	14
自前8B・圧縮なし（素のまま）	15
汎用27B	4

読み方はこうだ。圧縮を完全に外しても、致命的な誤りは減らなかった。 つまり、この床を作っていたのは量子化ではない。同じ難所で27Bが4件に収まるのだから、残っているのはモデルサイズの差だ。15件対4件という開きは、偶然の揺らぎでは説明しにくい水準だった。

これで、私が引けるレバーが3本に分離した。

レバー	効く場所	現状
圧縮（量子化）	生成の速さ＝読み出すデータ量	品質の打ち手としては打ち止め。速さには効くが、床には効かない
サイズ（容量）	意味理解の床＝致命的な誤り	効く。ただし「大きいほど賢い」という高コストな方向へ戻る手
器（アーキテクチャ）	汎用税＝速さと、品質の天井（＝いちばん良いときの上限）	未着手。ここが次の投資先

量子化に賭けるのをやめた、というのがこの実験の結論だ。速度のレバーとしては引き続き有効だが、品質の床を上げる道具ではなかった。投資先を、圧縮から器へ移す。

特化に期待しているのは、速さだけではない

ここで、この記事でいちばん誤解されたくない点を書く。特化型モデルの価値をレイテンシだけで語るのは、狭すぎる。 私が器の切り直しに期待しているのは、独立した3つの改善だ。

① 感情の語り口。 ネイティブに実機の訳を読んでもらったとき、返ってきた評価は「意味は通じるが、感情的な部分が硬い」だった。これは誤訳ではない。意味は合っている。それでも字幕として気になる——その瞬間、視聴者は物語の外へ出る。翻訳の理想が「存在感のない字幕」だとすれば、ここは飾りではなく本丸だ。

そして語り口は、指示文（プロンプト）を工夫しても動かない。モデルの中身そのものを訓練し直すしかない、と分かっている（4Bで苦しんだ語り口が8Bで出たのも同じ話だ）。汎用モデルの語り口は、汎用の平均に引かれている。その平均から降りることが、器を替える動機の第一だ。

② 映像を見て訳すことによる精度。 場面の情報を完璧に与えたら翻訳はどこまで良くなるか——これは別稿で測ってある。効いた要素は3つに凝縮していた。話者の性別・固有名詞の読み・省略された主語だ（13件の改善に対し悪化0件）。

なかでも最大が話者の性別だった。日本語は「俺／私」「〜だぜ／〜だわ」で話者が誰かを常に露出するのに、英語の原文にはその情報が無い。

だから、テキストだけを見て性別を推定させると、正解34%・誤り21%まで落ちる。誤りは「分からない」より悪い——存在しない設定を捏造して訳を汚すからだ。

だが、これは原理的に難しい問題ではない。画面を見れば、誰が喋っているかは自明だ。 「A picture is worth a thousand words（一枚の絵は千の言葉に値する）」という言い回しがある。翻訳では、これがもっと厳しい形で効く——その千の言葉のうち何語かは、原文の中に最初から存在しない。テキストだけを追うモデルは、無い情報をいくら読み直しても復元できない。1フレーム見れば済むことに、文脈をどれだけ積んでも届かないのだ。 実際、性別の情報をモデルに教え込んだだけで、男女の文脈に応じて一人称や語尾を正しく切り替える率は19%→74%に上がった（別の検証セットでの一次実証）。テキストしか入り口を持たない器のままでは、この情報は入れようがない。 入り口を作ることが、器を替える動機の第二だ。

③ レイテンシ。 そして3つ目が、汎用モデルが払っている生成の運び賃。ここは既知の話（別稿）なので、繰り返さない。

重要なのは、この3つが互いに独立していることだ。だから、うまくいけば足し算ではなく、曲線ごと持ち上がる。

次の器——「頭でっかち」な字幕特化モデル

モデルの中身は、大きく2つに分かれる。入力を読んで意味を掴む Encoder（読む側） と、それを訳文として書き出す Decoder（書く側） だ。いまのモデルは、この2つにほぼ同じだけの厚みを割いている。字幕の仕事も、その配分のまま押し込んでいる。

考えているのは、その配分を変えることだ。Encoderを大きく、Decoderを薄く。 字幕の仕事は「長く自由に語る」ことではなく「短く正しく写す」ことなのだから、重みは理解に厚く、書き出しに薄く配るのが素直な配分になる。

図2：器の作り替え——EncoderとDecoderの配分を変える。左が現状で、Encoder（読む側）とDecoder（書く側）にほぼ同じ厚みを割いている。1文字書き出すたびに、この全部を読み直す。右が構想。Encoderは大きくして意味理解の床を上げ（映像という入り口も足す）、Decoderは薄くする。モデル全体としては、むしろ大きくなる。それでも遅くならないのは、1文字ごとに動くのが薄いDecoderだけだからだ。削るのは「汎用」であって、容量ではない。
注：高さは模式的な比率で、実際のパラメータ配分を表すものではない。左右は同じ縮尺。構想段階の設計であり、実装・実測はまだない。

そしてこの形が効くと見込む理由は、動く回数が非対称だからだ。Encoderは入力ごとに1回しか動かないのに対し、Decoderは1文字出すたびに動く。だからDecoderを薄くすると、理解の厚みを保ったまま、レイテンシだけが落ちる。

3つのシフトは、それぞれ別の軸を押す。狙いは勝者を選ぶことではなく、トレードオフの曲線そのものを動かすことだ。

図3：狙いは「勝者を選ぶ」ことではなく、曲線を動かすこと。汎用LLMを使う限り、速さと品質は同じ曲線の上で交換される（実線）。器を字幕に合わせれば、この曲線ごと上へ移せるのではないか——というのが仮説（破線）。
注：破線は未実測の仮説であり、実測点ではない。実線上の3点も、位置関係を示す概念図であって座標は正確な実測値ではない。

裏付けがあるものと、ないものを分けて書く。

裏付けがあるもの。 「Encoderを厚く、Decoderを薄く」は、機械翻訳では既に実証のあるアーキテクチャだ（Decoderが1層でも、同じ速度帯の強い手法を上回るという先行研究がある）。映像側も、性別の情報を入れると語り口が正しく切り替わるところまでは自分で確認した（19%→74%）。部品は、どれも新しくない。新しいのは、字幕という一点でそれらを1枚に束ねることだけだ。

裏付けがないもの。 その先行研究の実証は主に英語↔ドイツ語で、日本語↔英語／韓国語は、この手の高速化がもっとも苦戦する言語の組み合わせだ（語順が大きく違うぶん、書き出す側の負担が大きい）。つまり「薄くしても品質が落ちない」を、そのまま自分の言語に持ち込める保証はない。だから現実解は、極端に薄くするのではなく1〜2層に留める＋大きいモデルの訳を教材にして写させる（蒸留）＋難所だけ大きいモデルへ逃がすあたりだろう、と見積もっている。

そして、いちばん正直に書くべきこと。引き上げ幅の上限は「汎用税の回収分」に限られる。 図1で見たとおり、韓国語→日本語の床の一部はモデルサイズで決まっていて、器を替えても残る。器で回収できるのは速さと語り口であって、意味理解の床は、サイズを上げるか、難所を逃がす設計で埋めるしかない。

残課題——アーキテクチャの当たりはついた。データ点がまだ無い

ここまでが「ある程度検討が進んでいること」。以下が「まだ検討が要ること」だ。

手	何を確かめるか	状態
Decoder（書く側）の厚みを掃く	Encoderを固定したまま、Decoderを1層・2層・4層・6層・12層と振り、品質（語り口を含む）と速さの前線を描く。自分の言語で「どこまで薄くできるか」を測る	未実施
映像の入り口を接ぎ木する	いまの8Bに映像を読む部分を足し、話者の語り口が本当に映像で解けるか	未実施
学習データの出所	映像と訳を対応づけた教材を、どう作るか。テキストだけの作り方は、そのままでは使えない	未設計

反証条件も先に置く。 Decoder（書く側）を薄くしたとき、品質が「汎用税の回収分」を超えて落ちるなら——具体的には、薄くした器が、同じ速さの汎用モデルに品質で負けるなら——この仮説は捨てる。映像を足しても語り口の指標が動かないなら、映像のシフトは切り離す。3つのシフトは互いに独立しているので、1つが外れても、残りの2つはそのまま残る。「この構想は正しいか」とまとめて問うのではなく、1本ずつ検証して、駄目だったものだけを降ろせばいい。

いま言えるのは、ここまでだ。「基盤モデルは字幕には無駄が多すぎる」という直感には、汎用税という説明と、量子化を容疑者から外した実測がある。だが器を替えれば勝てる、という証拠はまだ1つも自分の手元にない。 その線引きを曖昧にしないことが、次に正しく測るための条件だと思っている。

教訓

1. 「圧縮で速くする」と「サイズで賢くする」は別のレバーで、混ぜて語ってはいけない。 圧縮を完全に外しても致命的な誤りは15件のまま、3倍以上大きいモデルは4件だった。品質の床が動かないと分かった時点で、圧縮は品質の打ち手から外れる——速さの打ち手としては生き続けるのに、だ。レバーごとに、効く場所を分けて持つ。
2. 特化モデルの価値を、速さだけで語らない。 汎用モデルの語り口は汎用の平均に引かれているし、テキストしか受け取らない器には映像という入り口がない。速さ・語り口・映像は独立に効く3本の軸で、独立だからこそ、足し算ではなくトレードオフ曲線ごと動かせる可能性がある。
3. 「まだデータが無い」を、はっきり書く。 設計の当たりがついていることと、自分の条件で効くことは別物だ。先行研究の実証は別の言語の組み合わせのもので、そのまま持ち込める保証はない。仮説を仮説として置き、反証条件を先に決めるほうが、勢いで作り始めるより速く終わる。

---

付録：生データ

A. 量子化 vs 容量の切り分け（図1の元データ）

項目	内容
タスク	韓国語→日本語、難所セット100件（学習データとの重複が疑われる件を除外 → 実効 n=97）
比較対象	自前8B（INT4 / INT8 / 圧縮なしBF16）、汎用27B
指標	致命的な誤り（critical）の件数。主語・意味の取り違え等、字幕として成立しない訳。平均品質ではない
判定	別系統の大型モデルによる盲検、同一ラウンド

構成	critical	対BF16
自前8B・INT8	14 / 97	差は統計的に区別不能（不一致ペアがほぼ無い）
自前8B・INT4	—	有意差なし（p=0.22）
自前8B・BF16（圧縮なし）	15 / 97	—
汎用27B	4 / 97	8B-BF16に対し p=0.015（約3.8倍の差）

読み方：圧縮の有無で床が動かないので、床の原因は圧縮ではない。27Bとの差が残るので、原因はモデルサイズ（容量）。→ 品質の打ち手として量子化は打ち止め、投資先を容量／映像／器の形へ移す。

B. 器を替える動機（3つのシフトと、現在の根拠）

シフト	期待する効果	現在の根拠	未確認
汎用税を捨てる	精度・速さ	汎用LLM（読む係と書く係が一体のdecoder-only）は任意長・自由形式の生成用。字幕は短文・固定形式・有界文脈（読み出すデータ量が速さを決める）	自分の言語での実測
映像を足す	語り口・精度	完璧な文脈の効きは性別・固有名・省略主語に凝縮（13件改善・0件悪化、文脈と容量）／英語原文だけでは性別の正解34%・誤り21%／性別情報の学習で追随率 19%→74%（別セットでの一次実証）	映像入力の接ぎ木そのもの
Decoderを薄く	速さ	機械翻訳で「厚いEncoder＋薄いDecoder」は実証済み（主に英↔独）	日↔英／韓は語順差が大きく、この高速化が最も苦戦する組み合わせ。外挿の保証なし

C. 留保

• 図2は構想の模式図で、実装・実測はない。図3の破線も未実測の仮説、実線上の点も位置関係を示す概念図で、座標は実測値ではない。
• Aのn=97は小さい。p値は同一セット上の対応ありの比較で、方向の手がかりとして読む。
• 引き上げ幅の上界は「汎用税の回収分」。韓国語→日本語の床の一部はモデルサイズで決まっており、器を替えても残る（→ 難所を大きいモデルへ逃がす設計で補完する前提）。

---

シリーズ「モデル — 小さく、速く、賢く」第12回の記事です。原文と続きは LYR Performance Note #032 / 記事一覧 にあります。