Home 論文解説: MIO — 音声・テキスト・画像・動画を統一トークンで理解・生成する基盤モデル
投稿
キャンセル

📄 論文解説: MIO — 音声・テキスト・画像・動画を統一トークンで理解・生成する基盤モデル

本記事は MIO: A Foundation Model on Multimodal Tokens (arXiv:2409.17790) の解説記事です。

論文概要(Abstract)

MIOは2024年9月に発表された基盤モデルであり、音声・テキスト・画像・動画の4モダリティを離散トークンに変換し、単一の自己回帰(autoregressive)Transformerで理解と生成の両方を実行する。著者らは、従来のMLLM(Multimodal Large Language Model)が外部エンコーダ/デコーダに依存するのに対し、MIOはend-to-endで全モダリティの入出力を処理できると報告している。実験では、LibriSpeech ASRで4.5% WER、画像理解(MMStar)で59.4%を達成したとされている。

この記事は Zenn記事: Gemini 2.0マルチモーダルAPI実践ガイド:画像・音声・動画をPythonで統合処理する の深掘りです。

情報源

背景と動機(Background & Motivation)

2024年時点のMLLMの主流アーキテクチャは、「モダリティ別エンコーダ + 言語モデル + モダリティ別デコーダ」の構成である。例えばGeminiやGPT-4Vは、画像エンコーダ(ViT等)の出力をTransformerデコーダのコンテキストに注入するアプローチを採用している。

著者らは、この設計には以下の制約があると主張している:

  1. 生成能力の非対称性: 多くのMLLMは画像/音声の「理解」はできるが、「生成」には別モデル(拡散モデル、TTS等)が必要
  2. モダリティ間の統合の限界: エンコーダ出力を投影層で言語空間に変換する際に情報損失が発生する
  3. アーキテクチャの複雑性: 各モダリティに専用のエンコーダ/デコーダが必要で、システム全体が複雑になる

MIOはこれらの課題に対し、全モダリティを「離散トークン」に統一変換し、1つのautoregressive Transformerで処理する設計を提案している。

主要な貢献(Key Contributions)

  • 貢献1: 音声・テキスト・画像・動画の4モダリティを離散トークンに変換し、単一のautoregressiveモデルで理解と生成の両方を実現するアーキテクチャの提案
  • 貢献2: 外部のエンコーダ/デコーダや拡散モデルに依存しないend-to-endマルチモーダル処理
  • 貢献3: 4段階学習(Alignment → Pre-training → Speech Enhancement → Instruction Tuning)により、各モダリティの性能を段階的に最適化

技術的詳細(Technical Details)

モダリティ別トークン化

MIOの核心は、全モダリティを離散トークンに変換する点にある。各モダリティのトークン化方法は以下の通りである(論文Section 2より)。

テキスト: 標準的なBPE(Byte Pair Encoding)トークナイザを使用。語彙サイズは一般的なLLMと同等。

音声: SpeechTokenizerを使用。このトークナイザは音声信号を2種類のトークンに分解する:

\[\mathbf{z}_{\text{speech}} = [\mathbf{z}_{\text{semantic}}, \mathbf{z}_{\text{acoustic}}]\]

ここで、

  • $\mathbf{z}_{\text{semantic}}$: 意味的内容を表現するトークン(言語情報)
  • $\mathbf{z}_{\text{acoustic}}$: 音響的特徴を表現するトークン(声質、韻律等)

この分離により、音声の内容理解(ASR)と音声生成(TTS)の両方が単一モデルで実現される。

画像: VQGAN(Vector Quantized Generative Adversarial Network)のコードブックを使用。画像を8×8のパッチに分割し、各パッチをコードブックの最近傍ベクトルにマッピングする。

\[\mathbf{z}_{\text{image}} = \text{Quantize}(\text{Encoder}(\mathbf{x}_{\text{image}}))\]

1枚の画像は1,024トークンで表現される(8×8パッチ × 16コードブック層)。

動画: 画像フレームの時系列として処理。各フレームを画像と同様にトークン化し、時間順に連結する。

統一Transformerアーキテクチャ

全モダリティのトークンは単一の語彙空間に統合され、autoregressiveに処理される:

\[p(\mathbf{z}_{1:T}) = \prod_{t=1}^{T} p(\mathbf{z}_t | \mathbf{z}_{1:t-1})\]

ここで $\mathbf{z}_t$ はテキスト・音声・画像・動画のいずれかのトークンであり、モデルはモダリティの種類に関係なく、次のトークンを予測する。

アルゴリズム:統一トークン化と生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
import torch
import torch.nn as nn
from typing import Union

class MultimodalTokenizer:
    """MIOの統一トークン化の概念実装

    各モダリティの入力を離散トークン列に変換する。
    """

    def __init__(
        self,
        text_vocab_size: int = 32000,
        speech_vocab_size: int = 1024,
        image_vocab_size: int = 8192,
    ):
        self.text_vocab_size = text_vocab_size
        self.speech_vocab_size = speech_vocab_size
        self.image_vocab_size = image_vocab_size

        # オフセットで統一語彙空間にマッピング
        self.speech_offset = text_vocab_size
        self.image_offset = text_vocab_size + speech_vocab_size

    def tokenize_text(self, text: str) -> list[int]:
        """テキストをBPEトークンに変換"""
        # BPEトークナイザによるトークン化
        # 実際にはsentencepieceやtiktoken等を使用
        return []  # placeholder

    def tokenize_speech(
        self, audio_waveform: torch.Tensor
    ) -> list[int]:
        """音声波形をSpeechTokenizerで離散トークンに変換

        Args:
            audio_waveform: 音声波形 (1, T)

        Returns:
            離散トークンID列(オフセット適用済み)
        """
        # SpeechTokenizerで量子化
        # semantic + acoustic トークンを生成
        semantic_tokens = []  # placeholder
        return [t + self.speech_offset for t in semantic_tokens]

    def tokenize_image(
        self, image: torch.Tensor
    ) -> list[int]:
        """画像をVQGANコードブックで離散トークンに変換

        Args:
            image: 画像テンソル (3, H, W)

        Returns:
            1024個の離散トークンID(8x8パッチ × 16層)
        """
        # VQGANエンコーダ + 量子化
        codes = []  # placeholder: 1024 tokens
        return [c + self.image_offset for c in codes]


class MIOModel(nn.Module):
    """MIOの統一Transformerの概念実装

    Args:
        vocab_size: 統一語彙サイズ(text + speech + image)
        d_model: Transformer隠れ次元数
        n_layers: Transformer層数
        n_heads: アテンションヘッド数
    """

    def __init__(
        self,
        vocab_size: int = 41216,
        d_model: int = 2048,
        n_layers: int = 32,
        n_heads: int = 16,
    ):
        super().__init__()
        self.embedding = nn.Embedding(vocab_size, d_model)
        self.transformer = nn.TransformerDecoder(
            nn.TransformerDecoderLayer(
                d_model=d_model,
                nhead=n_heads,
                dim_feedforward=d_model * 4,
                batch_first=True,
            ),
            num_layers=n_layers,
        )
        self.output_head = nn.Linear(d_model, vocab_size)

    def forward(
        self, tokens: torch.Tensor
    ) -> torch.Tensor:
        """統一トークン列の次トークン予測

        Args:
            tokens: 統一トークンID列 (batch, seq_len)

        Returns:
            次トークンのlogits (batch, seq_len, vocab_size)
        """
        x = self.embedding(tokens)
        # Causal maskでautoregressive処理
        mask = nn.Transformer.generate_square_subsequent_mask(
            tokens.size(1)
        )
        x = self.transformer(x, x, tgt_mask=mask)
        return self.output_head(x)

4段階学習

MIOの学習は4段階で構成される(論文Section 3より):

  1. Alignment(アライメント): 異なるモダリティのトークンを同一の表現空間に整列させる。テキスト-画像、テキスト-音声のペアデータで学習
  2. Multimodal Pre-training(事前学習): テキスト-画像-音声の混合データで大規模事前学習
  3. Speech Enhancement(音声強化): 音声の理解・生成品質を向上させるための追加学習
  4. Instruction Tuning(指示チューニング): 人間の指示に従う能力を獲得するためのファインチューニング

実装のポイント(Implementation)

MIOのアーキテクチャを実装する際の注意点:

  1. トークン化の品質がボトルネック: VQGANの画像トークン化は再構成品質に直結する。コードブックサイズ(8,192)とパッチ解像度(8×8)のトレードオフがある
  2. 音声トークンの二重構造: semanticトークンとacousticトークンの分離は、理解タスク(semanticが重要)と生成タスク(acousticが重要)の両立に寄与する
  3. 学習コスト: 論文ではA100 80GB × 8台で数週間の学習を要したと報告されている。学術研究レベルのリソースが必要
  4. モダリティ間の語彙衝突: テキスト・音声・画像のトークンが同一語彙空間に混在するため、オフセットの管理が重要

実験結果(Results)

著者らは以下のベンチマーク結果を報告している(論文Table 4, 5, 6より)。

音声理解

タスクデータセットMIO比較対象
ASRLibriSpeech (clean)4.5% WERWhisper Large: 2.7%
ASRLibriSpeech (other)10.2% WERWhisper Large: 5.2%

著者らは、MIOのASR性能は専用モデル(Whisper等)には劣るものの、汎用マルチモーダルモデルとしては競争力のある結果だと述べている。

音声生成

メトリクスMIO専用TTSシステム
UTMOS (品質)比較可能ベースライン
自然性中程度高い

画像理解

ベンチマークMIOLLaVA-1.5 (7B)
MMStar59.4%54.7%
POPE--

画像生成

メトリクスMIOLlamaGen
FID (CC3M)132~130

著者らは、画像生成の品質は専用の拡散モデル(Stable Diffusion等)と比較すると劣るが、LlamaGen等のautoregressive画像生成モデルとは同等水準であると報告している。

クロスモーダルタスク

論文では、音声→画像生成、画像→音声説明といったクロスモーダルタスクでも性能が報告されている。これらはGeminiのようなモジュラーMLLMでも理論的には可能だが、MIOではend-to-endで処理される点が特徴である。

実運用への応用(Practical Applications)

MIOのアプローチはGeminiとは対照的な設計思想を持つ。Zenn記事で解説されているGemini APIでは、画像理解・音声理解・動画理解はそれぞれ「入力」として統合的に処理されるが、「出力」側の生成は限定的(テキスト出力が主、画像生成は実験版)である。

MIOは入力・出力の両方で全モダリティをサポートするが、以下の実用上の制約がある:

  1. コード・重みの未公開: 論文投稿時点(2024年9月)では公開されておらず、API提供もない
  2. 生成品質の限界: 画像生成のFID 132は、Stable Diffusion(FID ~10-20)と比較すると大幅に劣る
  3. 学習コストの高さ: A100 × 8台で数週間の学習は、多くの開発者にとって非現実的

Geminiとの比較:

  • Gemini: クローズドAPI、高品質、商用利用可能、生成は主にテキスト
  • MIO: 研究段階、end-to-end生成対応、品質は中程度、重み非公開

関連研究(Related Work)

  • Gemini (Google, 2023, arXiv:2312.11805): モダリティ別エンコーダ + Transformerデコーダのアプローチ。MIOとの主な差異は、Geminiがモダリティ別の連続表現を使用するのに対し、MIOは全モダリティを離散トークンに統一変換する点
  • CoDi (Tang et al., 2023): 任意モダリティから任意モダリティへの生成が可能なモデル。ただし拡散モデルベースであり、MIOのautoregressive方式とは設計思想が異なる
  • LlamaGen (Sun et al., 2024): autoregressive画像生成モデル。MIOの画像生成部分はこのアプローチに類似しているが、MIOはテキスト・音声・動画も統合的に処理する

まとめと今後の展望

MIOは「全モダリティの離散トークン統一」というラディカルなアプローチにより、理解と生成の両方を単一モデルで実現することを試みた研究である。現時点では生成品質が専用モデルに劣る課題があるが、モデルのスケーリングと学習データの拡充により改善が期待される。

Gemini APIを実務で利用する開発者にとって、MIOは「マルチモーダルAIの将来像」を理解するための参考になる。Geminiが今後ネイティブ画像生成やTTSを強化する方向性は、MIOが示す「統一トークンによるend-to-end生成」の思想と共通している。

参考文献

この投稿は CC BY 4.0 でライセンスされています。