いまのモデル地形とエンコーダたち
一言でいうと
2026年現在使われているモデルは、どんなマスクを使うか、何をトークンとして見るか、計算をどう節約するかの3つの軸に分けられます。
なぜ分けて見るのか、軸1: マスクによる3つの系統
| 系統 | マスク | 得意なこと | 例 |
|---|---|---|---|
| デコーダー | 因果(後ろを見られない) | 続きの生成、対話、コード | GPT、LLaMA、Claude、Qwen |
| エンコーダー | なし(双方向) | 分類、検索用の埋め込み | BERT、RoBERTa、E5 |
| エンコーダー・デコーダー | 両方 | 翻訳、要約、音声認識 | T5、Whisper |
実務で重要な分かれ道が1つあります。検索(RAG)の埋め込みには、エンコーダーモデルを使います。生成用のデコーダーモデルの最後の隠れ状態を埋め込みとして使うと、たいてい性能が落ちます。因果マスクのために、後ろのトークンだけが前を見ることになるからです。
軸2: 何をトークンとして見るのか
Transformerはテキスト専用ではありません。「ベクトルの並び」にできるなら、何でも入れます。そのため、エンコーダーが必要になります。
ビジョンエンコーダー(ViT系)
画像をパッチに切って、トークンにします。
- 224×224の画像を16×16のパッチに切ると、196個のトークン
- 各パッチを平らに伸ばして(768次元)線形変換すると、それが埋め込み
- 位置エンコーディングを足します。足さなければ、パッチを並べ替えても同じ結果が出ます(前のラボのあの性質がそのまま現れます)
CNNとの違いは、局所性の仮定がないことです。CNNは、近いピクセル同士をまず見るという構造を、最初から持っています。ViTは、最初の層から画像全体を見ることができます。そのため、データが少なければCNNが優れ、多ければViTが勝ちます。
CLIPは、ここからさらに一歩進みます。画像エンコーダーとテキストエンコーダーを別々に置き、同じペアは近く、違うペアは遠くなるように学習します。すると、画像と文が同じ空間に置かれます。「猫の写真」という文のベクトルで画像を検索できるのはこのためで、最近のマルチモーダルLLMの大半が、CLIP系のビジョンエンコーダーを前段に付けて使っています。
オーディオエンコーダー(Whisper系)
音は、1秒に16,000個のサンプルです。そのままトークンとして使うことはできません。
- ログメルスペクトログラムに変換します。時間 × 周波数の2次元画像になります。メル尺度は、人間の耳が低い周波数に敏感であることを反映した目盛りです
- 畳み込みで時間軸を縮めます。Whisperは、stride 2のconvで半分に縮めます。30秒が1,500トークンになります
- その上にTransformerエンコーダーを載せます
前処理が半分を占めます。この段階で情報をどう圧縮するかが、性能を左右します。テキストのトークナイザーとまったく同じ役割です。
Whisperがエンコーダー・デコーダーである理由も、ここにあります。エンコーダーが音全体を双方向に理解し、デコーダーが文字を1つずつ出力します。
では、マルチモーダルLLMは
이미지 → 비전 인코더 → 프로젝션 → [토큰들] ┐
├→ 디코더 LLM → 글자
텍스트 → 토크나이저 → [토큰들] ────────────┘
このコードブロックの韓国語の図は、画像がビジョンエンコーダーとプロジェクションを経てトークンになり、テキストがトークナイザーを経てトークンになって、その両方がデコーダーLLMに入り、文字を出力する、という意味です。
プロジェクション層1つが、2つの世界をつなぎます。ビジョンエンコーダーの出力次元を、LLMの埋め込み次元に合わせる小さなMLPです。学習のときは、この部分だけを先に合わせ(アライメントの段階)、そのあと全体を少しずつ解放する方法が一般的です。
軸3: 計算をどう節約するのか
KVキャッシュ。生成のたびに、前のすべてのトークンのK・Vを計算し直す必要はありません。保存しておいて、新しいトークンの分だけを加えます。そのため、推論メモリの大半は、モデルの重みではなくKVキャッシュです。コンテキストが長くなるほど、これが支配的になります。
GQA(グループクエリアテンション)。Qヘッドは32個ありますが、K・Vヘッドは8個だけにして、4つずつ共有します。KVキャッシュが4分の1になります。品質の損失がほとんどないので、最近のオープンモデルの大半が使っています。
MoE(専門家混合)。各層にFFNを複数置き、トークンごとに2つほどだけを有効にします。総パラメーター数は大きくても、1つのトークンが使う計算は小さくなります。ただし、メモリにはすべてを載せる必要があるので、サービングコストがパラメーター数と無関係だという意味ではありません。
量子化。重みを8ビットや4ビットに減らします。精度の損失は思ったより小さく、メモリは大きく減ります。ただし、KVキャッシュは別に量子化しなければ、効果が出ません。
FlashAttention。近似ではありません。大きなスコア行列をまるごとメモリに載せず、タイル単位で計算して、GPUの遅いメモリアクセスを減らします。数学的にまったく同じ値が出ながら、数倍速くなります。
コンテキストをどう延ばしたのか
RoPEが鍵です。絶対位置を足す代わりに、Q・Kを角度の分だけ回転させると、2つの位置の内積が距離だけに依存するようになります。すると、学習時に見たことのない長さにも、ある程度通用します。
- 位置補間(PI): 回転角を圧縮して、4kで学習したモデルを16kに延ばします
- NTK/YaRN: 周波数帯ごとに異なる延ばし方をして、短い文脈での性能をあまり損ないません
ただし、コンテキストが長いことと、うまく使えることは別です。長い文脈の真ん中にある情報を見落とす現象(lost in the middle)がよく知られています。検索で必要な断片だけを入れた方が、100kをまるごと入れるより正確な場合が多くあります。
選ぶときに実際に見るもの
- 何をマスクするか: 生成か、理解か
- KVキャッシュがどれだけかかるか: GQAか、コンテキストがどれだけ長いか
- エンコーダーが何を受け取るか: 画像・音を入れるなら、前段のエンコーダーの前処理が性能を左右します
- 量子化したときに崩れないか: デプロイ環境が決まっているなら、これが最初の問いです
パラメーター数は、4つのどこにもありません。実際にサービングコストと品質を分けるのは、上の4つです。
現場では
モデルを選ぶ場で実際に交わされる問いは、性能の順位表ではなく、次のようなものです。検索に使う埋め込みなのにデコーダーモデルを選んでもよいか、文書が韓国語なのにこのトークナイザーは何倍に膨らませるか、コンテキスト128kをサポートするというが、その長さで実際のレイテンシはどれだけか。
そして、これらの軸を知っていると、ベンダーのドキュメントを読む速度が変わります。「スライディングウィンドウアテンション」と書かれていれば、長い文書の前の部分を忘れるという意味で、「GQA」は推論メモリが小さいという意味で、「エンコーダー・デコーダー」は翻訳や要約に強いという意味です。新しいモデルが出るたびに最初から学ぶのではなく、この座標に置いてみれば足ります。
社内に導入するモデルを選ぶなら、最後にもう1つ見ます。ライセンスと重みの公開範囲です。性能がどんなに良くても、商用利用が禁じられていれば、候補から外れます。