Audio AIは「聴く」時代へ。ローカルで動くLALMsをまとめて比較できるOSS「LALMsArena」を作った
はじめに
こんにちは。普段は音データを pandas ライクに扱える OSS ライブラリ「wandas」を開発しています。wandas を作る中で Audio AI の世界が急速に変わってきていることに気づき、実際に触ってみました。
ここ最近、Audio AI の世界が急速に変わってきていると感じています。従来の音声認識（ASR）は「音声をテキストに変換して、それをテキスト LLM に渡す」という 2 段構えが当たり前でした。ところが最近では、音響信号をそのまま受け取って推論まで完結させる Large Audio Language Models（LALMs、大規模音声言語モデル） が続々と登場しています。
しかし、「どのモデルが何を得意にしているのか」「同じオーディオファイルを渡したときに各モデルがどう応答するのか」を横並びで確認できる場所がなかなかありませんでした。
そこで自作したのが LALMsArena です。ローカル環境で動かせる LALMs を並べて比較できるオープンソースのプレイグラウンドです。
1. LALMs とは何か
Audio AI の処理パイプラインは、長らく以下のような 2 段構成が主流でした。
音声 → [ASR] → テキスト → [LLM] → テキスト回答
ASR がまず音声をテキストに起こし、そのテキストをテキスト LLM が処理する、というアプローチです。この方式にはシンプルで組み合わせやすいという利点がありますが、音声固有の情報がテキスト化の段階でほぼ失われてしまうという問題があります。話者の感情、声のトーン、音響の背景環境、音楽のジャンルといった情報は、テキストにすると消えてしまいます。
一方で、LALMs は音響信号を直接受け取り、内部で音響特徴を処理しながら推論まで一気通貫で行います。
オーディオ → [LALMs] → テキスト回答
これにより、「この音声の話者は不安そうですか？」「背景で何の音が鳴っていますか？」「この音楽のジャンルと感情を説明してください」といった、音響そのものに埋め込まれた情報を問うタスクが初めて現実的になってきています。
2024〜2025 年にかけて Qwen2-Audio、SALMONN、Gemma 系、MOSS など多数のモデルが公開され、性能も急速に伸びてきています。
2. LALMsArena の概要
LALMsArena は、こうした LALMs を横並びで比較するためのプレイグラウンドです。
主な機能
- サイドバイサイド比較 — 同一のオーディオファイルとプロンプトを複数モデルへ投入し、回答を並べて確認できる
- 任意のプロンプトを実行 — 感情判定・背景音識別・音楽解釈など、自由な問いかけを各モデルへ同時に投げられる
- 拡張可能な設計 — 新しいモデルや商用 API を FastAPI エンドポイントとして追加するだけで組み込める
サポートモデル（12 種類）
| モデル | パラメータ数 | 必要 VRAM |
|---|---|---|
| Qwen2-Audio | 7B | ~16 GB |
| Audio Flamingo Next | 7B | ~16 GB |
| Audio Flamingo Next Captioner | 7B | ~16 GB |
| Audio Flamingo Next Think | 7B | ~16 GB |
| Gemma-4-E4B | 4B | ~16 GB |
| MOSS-Audio-4B | 4B | ~11 GB |
| MOSS-Audio-8B | 8B | ~17 GB |
| MOSS-Audio-8B-Thinking | 8B | ~17 GB |
| Step-Audio-R1.1 | 33B | ~80 GB |
| Qwen3-Omni | 30B-A3B (MoE) | ~68 GB |
| Qwen3-Omni-Captioner | 30B-A3B (MoE) | ~61 GB |
| Qwen3-Omni-Thinking | 30B-A3B (MoE) | ~61 GB |
最小構成の MOSS-Audio-4B なら VRAM 16GB から試せます。フラッグシップの Step-Audio-R1.1 は思考ステップを出力する「Think」系モデルで、なぜそう推論したかをトレースできます。
ベンチマーク結果
General Audio Understanding（音楽・環境音・音声を横断した音響理解）タスクにおける精度（Accuracy↑）の比較です。
各ベンチマークの概要は以下のとおりです。
- MMAU — 音声・環境音・音楽全般にわたる、専門家レベルの知識と複雑な推論能力を問う大規模ベンチマーク
- MMAU-Pro — 長尺音声や空間把握なども含め、AIの総合的な「音声汎用知能」の評価を目指す包括的なベンチマーク
- MMAR — 音声・音・音楽における、表面的な理解を超えた深い推論能力とそのプロセスを評価するベンチマーク
- MMSU — 日常的な話し言葉の細かな言語的・パラ言語的ニュアンスの理解と推論に特化したベンチマーク
| モデル | サイズ | MMAU | MMAU-Pro | MMAR | MMSU | Avg |
|---|---|---|---|---|---|---|
| オープンソース（小型） | ||||||
| Kimi-Audio | 7B | 72.41 | 56.58 | 60.82 | 54.74 | 61.14 |
| Qwen2.5-Omni | 7B | 65.60 | 52.20 | 56.70 | 61.32 | 58.96 |
| Audio Flamingo 3 | 7B | 61.23 | 51.70 | 57.96 | 60.04 | 57.73 |
| MiMo-Audio-7B | 7B | 74.90 | 53.35 | 61.70 | 61.94 | 62.97 |
| MiniCPM-o-4.5 | 9B | 70.97 | 39.65 | 55.75 | 60.96 | 56.83 |
| MOSS-Audio-4B-Instruct | 4B | 75.79 | 58.16 | 59.68 | 59.68 | 64.04 |
| MOSS-Audio-4B-Thinking | 4B | 77.64 | 60.75 | 63.91 | 71.20 | 68.37 |
| MOSS-Audio-8B-Instruct | 8B | 77.03 | 57.48 | 64.42 | 66.36 | 66.32 |
| MOSS-Audio-8B-Thinking | 8B | 77.13 | 64.29 | 65.73 | 76.06 | 70.80 |
| オープンソース（大型） | ||||||
| Qwen3-Omni-30B-A3B-Instruct | 30B | 75.00 | 61.22 | 66.40 | 69.00 | 67.91 |
| Step-Audio-R1.1 | 33B | 72.18 | 60.80 | 68.75 | 64.18 | 66.48 |
| Step-Audio-R1 | 33B | 78.67 | 59.68 | 69.15 | 75.18 | 70.67 |
| クローズドソース | ||||||
| GPT4o-Audio | — | 65.66 | 52.30 | 59.78 | 58.76 | 59.13 |
| Gemini-3-Pro | — | 80.15 | 68.28 | 81.73 | 81.28 | 77.86 |
| Gemini-3.1-Pro | — | 81.10 | 73.47 | 83.70 | 81.30 | 79.89 |
出典: MOSS-Audio-8B-Thinking - Hugging Face
3. アーキテクチャ
設計のポイントは「モデルを独立したコンテナに閉じ込める」ことです。
[Streamlit UI (app.py)]
│
│ HTTP
▼
[FastAPI コンテナ × N] ← 各モデルが独立したポート (8600〜8609) を持つ
モデルA モデルB ...
各モデルを独立した Docker コンテナで運用することで、次のメリットがあります。
- 依存関係の衝突を防ぐ — モデルによって要求する transformers のバージョンが異なることがよくあります。コンテナを分けることでこれを完全に回避できます
- 必要なモデルだけ起動できる — VRAM が限られる環境では、比較したいモデルのコンテナだけを起動するだけで済みます
- 新モデルの追加が容易 — FastAPI エンドポイントを実装したコンテナを追加するだけで、UI 側には自動的に新しいモデルが現れます
コンテナ間通信とファイル共有
Streamlit UI と各 FastAPI コンテナは Docker ネットワーク経由の HTTP で通信します。オーディオファイルは multipart/form-data 形式でバイナリのままリクエストに乗せて各コンテナへ送信されます。ボリュームマウントはワークスペースと HuggingFace モデルキャッシュの共有に使われており、音声ファイルのやり取りはすべて HTTP 経由です。選択した複数モデルへ同じバイト列を順番に POST し、結果を並べて表示することでサイドバイサイド比較を実現しています。
4. セットアップ方法
前提
- Docker + Docker Compose
- VS Code + Dev Containers 拡張
- NVIDIA GPU（推奨）
開発環境は Dev Container として構成済みです。Python・uv などの依存関係はコンテナ内に自動でセットアップされるため、ホスト環境を汚さずにすぐ試せます。
手順
# 1. クローン
git clone https://github.com/kasahart/LALMsArena
cd LALMsArena
VS Code でフォルダを開き、「Reopen in Container」を選択するとビルドが始まります。
# 2. 使いたいモデルのコンテナを起動（Dev Container 内のターミナルで実行）
# CPU 環境（デフォルト）
docker compose up -d audio-flamingo-next
# GPU 環境
docker compose -f docker-compose.yml -f docker-compose.gpu.yml up -d audio-flamingo-next
# 3. UI を起動
uv run streamlit run app.py
ブラウザで http://localhost:8501 にアクセスすると、モデル選択とオーディオファイルのアップロード画面が表示されます。比較したいモデルを選んでプロンプトを入力すれば、各モデルの回答がサイドバイサイドで並びます。
5. 使ってみて分かったこと
実際に同じオーディオファイルを複数モデルに投入してみると、モデルによって応答の傾向が明確に異なることが分かりました。
以下は、同一のオーディオファイルに「何の音か説明してください」と問いかけた際の実際の出力例です。音源は「サマーストリート」で、0〜5秒は路上でセミが鳴き、その後エンジン音が近づいて遠ざかる構成です。
Audio Flamingo Next Think
音声には、0〜15秒にわたって持続する不明瞭な背景ノイズが含まれており、遠くの交通音や室内環境音のような一定のハムまたはヒス音が続いています。明確な前景音は認識できませんでした。
MOSS-Audio-8B-Thinking
バイクのエンジン音が唸りを上げながら通り過ぎる音が聞こえます。
Qwen3-Omni-Thinking
この音声では、最初にカラスと思われる鳥の鳴き声が聞こえます。その後、バイクまたはスクーターが中程度の速度で近づき、通り過ぎ、遠ざかっていく音が続きます。エンジン音は録音の後半を支配する際立った音です。
Step-Audio-R1.1
00:00〜00:02：低周波のエンジン音のような唸り。00:02：カラスと思われる鳥の鳴き声。00:04：車が通り過ぎる音（風切り音を伴う）。00:06：ドアや自転車のメカニズムと思われるキーッという軋み音。00:08以降：自転車が路面を走るようなリズミカルなカタカタという音が続く。
実際の音源はセミの鳴き声＋エンジン音という構成ですが、Audio Flamingo Next Think はセミもエンジン音も捉えられず「不明瞭な背景ノイズ」と処理しました。MOSS はエンジン音を「バイクが通り過ぎた」と端的に認識し、Qwen3-Omni-Thinking はカラスの鳴き声（セミと誤認）を含めた時系列の記述を返しました。Step-Audio-R1.1 はタイムスタンプ付きで詳細な記述を出力しますが、実際には聞こえない軋み音や自転車音が含まれるなどハルシネーションも見られ、タイムスタンプも実際の音の出現タイミングとは一致していませんでした。
このように、モデルによって注目する情報の粒度や表現スタイルが大きく異なることが分かります。
6. 今後の展望
引き続き対応モデルを逐次追加していく予定です。
まとめ
LALMs はここ 1〜2 年で急速に進化し、音響信号そのものを理解するモデルが現実的な選択肢になってきています。しかし、「どのモデルを使えばいいか」を判断するには、同一条件での横並び比較が不可欠です。
LALMsArena は、その比較を手軽に行えるプレイグラウンドとして作りました。LALMs に興味がある方、ぜひ触ってみてください。
フィードバックや Issue・PR もお気軽にどうぞ。
Discussion