Ollama上のLFM3-Audio-2B：音声はより良く、耳はそのまま

Liquid AIのLFM3-Audio-2Bは、今朝からワンコマンドでダウンロードできるようになった。ollama run lfm3-audio は2.1 GBを取得し、テキストまたは音声を入力として受け取り、テキスト、24 kHz音声、あるいはその両方で応答する2Bパラメータモデルを起動する。モデル自体は登場からまだ1日で、2026年10月27日に6モデル構成のLFM3ファミリーの一員としてリリースされた。10月28日に新しいのは提供方法であり、まず知っておくべきことはLiquid自身のベンチマーク表に示されている：LFM2.5-Audio-1.5B——これが置き換えるモデルだ——と比較すると、音声品質は急激に向上し、音声理解はほぼ2倍になり、英語の音声認識はまったく改善しなかった。

本稿の残りでは、今日検証できるものとそうでないものを区別する。オーディオ系統については、ファミリーのブログ投稿の1段落とモデルカードしかなく——「Introducing LFM3-Audio」という専用の告知は存在せず——、このモデルの独立したベンチマーク実行はどこにも見つからなかった。以下の数値は、文で別段の記載がない限り、すべてLiquidによるものだ。

何が出荷され、その発表がいかに薄っぺらいものだったか

Liquidの10月27日の投稿「LFM3の紹介：専門特化型インテリジェンスのためのあらゆるモダリティ」は、LFM3-1.7B-Baseから学習された6つの2Bクラスモデルを発表した。テキスト、ビジョン、オーディオ、オムニ、そしてビジョンとオムニの各ブランチから特化された2つの意思決定モデルである。オーディオは4つのモダリティブランチの1つであり、UTMOSv2の改善、最初のトークンまでの時間50 msという数値、87倍のリアルタイムコーデックについての1段落だけが割かれている。オーディオ専用の投稿も、オーディオのベンチマークブログもなく、Liquidの価格ページにはどのLFM3モデルの価格項目もない。

今週、3つの成果物がモデルを読者の前に提示しました：

• ウェイト — Hugging Face の LiquidAI/LFM3-Audio-2B（LFM Open License v1.0 に基づく）。完全な比較表を掲載したモデルカード付き。

• llama.cpp — PR #31257（10月27日マージ）は、LFM3-Audio-2B と LFM3-Omni-2B を追加します。音声エンコーダの畳み込みとコーデックを非量子化のまま維持し、TTS フラグを通じて男性または女性の音声を利用可能にし、ライブ ASR は今回のマージには含めず後続の PR と明記しています。

• Ollama — lfm3-audio、2.1 GB、タグは latest と 2b。キャプチャ時点でダウンロード数19、「1時間前に更新」と表示。ページヘッダーには5モデルとありますが、公開されている行は2つです。

Ollamaの掲載は最も重要なものだ。なぜなら、モデルカードを読むことから始まらない唯一のルートだからだ。それもまた、いかなる告知もなしに登場した——投稿も、変更履歴も、モデル自身のカードにそれを示すものもなかった。

仕様書、ほとんど全員が間違ってコピーした図を含めて

• パラメータ — 合計2B、LFM3バックボーン上で、独自の因果的オーディオエンコーダーとLiquidCodecトークナイザーを採用

• 入力 — テキスト、または16 kHzでサンプリングされた音声

• 出力 — テキスト、24 kHz 音声、またはテキストと音声のインターリーブ

• コンテキスト — 入力と出力を合わせて32Kトークン。これはローンチ報道で繰り返されている256Kという数字ではない。それはテキストモデルであるLFM3-1.7Bのものだ。音声ブランチ自身のページには32Kと書かれている。

• 言語 — 18言語。英語がイギリス英語とアメリカ英語の2種類として表示されるため、19ロケールとして記載されています。ライブASRは英語のみ対応。翻訳は英語との相互翻訳が最も高精度です。

• ライセンス — LFM Open License v1.0、年間売上1000万ドル未満は商用利用無料、それを超える場合は有償の商用ライセンスとなります。

• フットプリント — Ollama ビルドで 2.1 GB。

その行のうち2つは、一旦立ち止まって考える価値がある。コンテキスト数は、要約が何か月も間違える項目だ。なぜなら、ファミリーの投稿では256Kが先に示され、オーディオカードはひっそりと32Kと記しているからだ。そして言語数は、実質的にはロケール数だ。19件のエントリ、18言語で、英語の2つの変種がその差分を担っている。どちらもスキャンダルではないが、どちらもユーザーに約束する内容を変える。

コマンド1つ、そしてカードと矛盾するフィールド

ollama run lfm3-audio が本当にセットアップのすべてだ。ページではモデルに tools、audio、2b のタグが付いており、モデル表のすぐ上にある readme には、テキストまたは音声を受け取り、テキスト、音声、あるいはその両方で応答すると書かれている。モデル表はそれと矛盾している。どちらのタグも入力は「Text」、コンテキストはダッシュになっている。

それはレンダリングの不具合として片付けるのではなく、真剣に受け止める価値がある。Ollamaは2026年4月のv0.20以降、音声入力をサポートしている。そのときGemma 4が音声機能、ollama transcribeコマンド、OpenAI形式のinput_audioパーツをもたらした。仕組みは存在する。未確認なのは、それがこのチェックポイント向けに接続されているかどうかだ — 音声タグは機能の主張であり、テスト結果ではない。「WAVをOllamaにパイプする」ことから計画を始めるなら、それを前提に設計する前に1つのファイルで検証せよ。

音声出力も、反対側から見れば同じ形をしている。llama.cpp のマージでは TTS 音声フラグが公開されている。Ollama のページには同等のものは記載されておらず、readme は音声出力を CLI の機能ではなくモデルの特性として説明している。すべての文をひっくり返しても結論は変わらない。今日のターミナル経路は、音声モデルのテキスト半分にすぎない。全二重の音声チャットには Python または llama.cpp の経路が必要だ。

Liquidが公開したスコアボード

6つの数値のうち4つには先行する値がある。それらはすべてLiquidのモデルカードに由来しており、名前付きのテストセットもハーネスもなく、分散もない。

• 英語ASR、単語誤り率 ↓ — LFM3-Audio-2B は 6.23、LFM2.5-Audio-1.5B は 6.13。横ばいで、唯一動かなかった行です。

• 多言語ASR、WER/CER ↓ — 6.03。前モデルの数値は公開されていません。

• 英語TTS、UTMOSv2 ↑ — 3.22に対して3.83。大きな向上であり、4.0は通常ほぼ人間の水準と見なされます。

• VoiceBench ↑ — 55.17に対して73.13。

• 音声理解、MMAR ↑ — 50.60 に対して 25.85。ほぼ2倍。

• 音声からのツール呼び出し、内部評価 ↑ — 58.50。以前の数値なし。

同じ表の他の項目と比べると、これは首位ではなく優れた小型モデルだ。Voxtral Mini 3BはWER 5.51を、NVIDIA Audex 2Bは5.99を記録し、どちらも6.23より良い。Qwen2.5-Omni 3Bは音声理解で50.60に対して54.41を記録する。Gemma 4 E4Bはツール呼び出しで58.50に対して72.40を記録し、Liquid自身のパラメータ行ではそのGemmaを8B、このモデルを2Bとしている — 「E4B」という名称は総パラメータ数ではなく活性パラメータ数を数えている。正直にまとめると、競争力のあるASR、音声出力における明確な向上、そして2Bとしては堅実な音声推論であり、どの列でも記録保持者ではない。

6.23 と 6.13 の差はサンプリングノイズが生み出す範囲内であり、回帰と読むべきではない。3.83 と 3.22 の差はそうではない——0.6 ポイントの UTMOS の動きは、その範囲をはるかに超えている。妥当な読み方は、Liquid がこの世代を「生成」に費やしたということだ。すなわち、より良い声、より良い音声推論、そしてエンコーダがその下で入れ替わる中でも地歩を保った ASR フロントエンドである。どの行についても第三者の再現は見つからなかったので、誰かが公開するまでは、この順序付けは仮説として扱うべきだ。

なぜコーデックはモデルより長く存続するのか

LiquidCodecは、このリリースでチェックポイント以外にも注目すべき部分です。80 msの音声を12個の離散トークンにまとめ、ストリーミング対応で24 kHzにデコードして戻します。Liquidの計測では、M4 Maxの単一CPUスレッド上でリアルタイムの約87倍です。因果エンコーダにより、音声の後ではなく発話中にプリフィルできるため、「最短50 ms」という最初のトークンまでの時間の数値が実現しています。

その2つの数値は、今回のローンチで最も引用され、最も再現性の低いものだ。どちらも、名前の挙がっているAppleハードウェア上でのベンダー測定値であり、テストハーネスも音声セットもパーセンタイルもない。それらはベストケースを述べているにすぎない。スマートフォンやRaspberry Pi、共有のx86 VMではそこには届かず、リリースのどこにも、代わりにどこに届くのかは書かれていない。

公開から1日しか経っていないモデルとしては、ランタイムサポートが異例なほど広範です。trust_remote_code を用いる Transformers 5.20.2 以降、BF16 チェックポイント用の vLLM と SGLang、GGUF 用の llama.cpp、Apple シリコン上の MLX 4 ビット、移植性のための ONNX Runtime、さらに単一 GPU でのファインチューニングに対応します。ピン留めすべき点はカスタムコード要件です。LFM3-Audio は独自のモジュールから読み込まれ、別個の audio_tokenizer ディレクトリからコーデックの重みを読み出すため、ピン留めされていない環境はサポートチケットの発生を待っているようなものです。

ローカル音声とホスト型エンドポイントの比較

2Bの音声モデルが2.1 GBであることが興味深いのは、代替手段では音声の1秒ごとに課金されるからだ。セルフホスティングには固定コストがある——すでに所有しているマシン、ダウンロード、分単位の従量課金なし。ホスト型エンドポイントにはトークンあたりの限界コストがあり、運用面はまったくない。

それぞれが何をカバーするのかを正確に押さえましょう。ホスト型テキスト読み上げ（私たちがルーティングする種類のもので、たとえば gpt-4o-mini-tts は100万トークンあたり入力$0.60、出力$12.00、gemini-2.5-flash-preview-tts は$0.50と$10.00）は、テキストを音声に変えるだけで、それ以外は何もしません。LFM3-Audio-2B は聞き取り、文字起こし、翻訳も行い、ネットワークを切断した状態でも動作します。両者は同じ音声エージェントの異なる半分を解決します。

LFM3-Audio-2B は OrcaRouter にはありません。当社が提供する音声モデルはホスト型の音声エンドポイントなので、今月の音声製品として正直に分けるなら、Liquid モデルを使ったローカルでの音声入力・出力、そしてテキスト側はすべて200以上のモデルを1つのエンドポイントで — プロバイダー表示価格に対する0%のマークアップ、プロバイダーがつまずいたときの自動フェイルオーバー、複数のモデルを1回の呼び出しに組み合わせたい場合のルーティングDSLの背後に置く形です。これが2ランタイム構成を維持可能にする理由です。ホスト側は1つの契約、ローカル側は1つのダウンロードです。

ローカル側のコストはゼロではない。2.1 GBの重み、動かし続けるプロセス、そしてSLAがないことだ。音声が建物の外に出ないなら、そのトレードオフは簡単だ。外に出るなら、ホスト型の価格は十分に安く、通常は運用負担が判断を決める。

今週は誰がそれを実行し、誰が待つべきですか？

ノートPC上でローカル音声ループを動かしたい、そして今のところはターミナルへのテキスト出力で我慢できるなら、これを実行してください。手元のホスト型音声が弱い、または高価な言語で音声出力が必要なら、これを実行してください——18言語は、ほとんどの小型TTSモデルが提供する対応範囲より広いです。録音データをマシンの外に出せず、1つのモデルから文字起こしと要約を得たいなら、これを実行してください。音声によるツール呼び出しをプロトタイピングしていて、モデルをツールと同じマシン上に置きたいなら、これを実行してください。

ASR精度が製品の要なら、待つべきです。6.23 の単語誤り率は悪くないものの、Liquid 自身の表では3つのモデルに後れを取っています。今日ストリーミング文字起こしが必要なら、待つべきです — ライブASRは後続の llama.cpp PR で、実現しても英語のみです。モデルに知識を持たせたいなら、待つべきです。モデルカードは検索を推奨しており、このサイズではエージェント型コーディングや多段推論を明示的に推奨していません。そしてベンダーSLAが必要なら、待つべきです。Liquid の料金ページには d1、d1-ultra、LFM2.5-24B-A2B が記載されているだけで、LFM3 の音声エンドポイントは一切ありません。

ローンチが答えていない3つの問い

LFM3-Audio-2BはLFM3-Omni-2Bと同じモデルですか？

いいえ。両者はLFM3バックボーンを共有し、同じllama.cppのプルリクエストに登場しましたが、Omniは音声に加えて視覚を追加するもので、2つの中ではより大きな取り組みです。用途が電話、会議の録音、音声コマンドであれば、Audioはより小さなモデルがより小さな仕事をする選択です。何かを見ながらその音を聞くような用途なら、それがomniブランチです。

ライブ配信を文字起こしできますか？

まだ llama.cpp 経由ではありません。このマージでは、ライブ ASR はフォローアップ項目とされており、モデルカードには、ライブ ASR が実現した後でも英語のみであることが明記されています。現在サポートされているのは、録音に対するバッチ文字起こしで、32K トークンのコンテキストがあります。音声トークンとテキストトークンがその予算を共有するため、長いファイルではこれがおおよそ計画すべき長さ制限になります。

GPUは必要ですか？

いや、そこがGGUFビルドの要点です。2.1 GBのOllamaアーティファクトはCPUで動作します。87×リアルタイムという数値が測っているのはコーデックであり、言語モデルではないので、ご自身のハードウェアでのエンドツーエンドの速度として読まないでください。Apple siliconはMLXまたは統合されたllama.cppサポートを通るのが最もスムーズな経路です。x86ではCPUデコードがボトルネックになると想定し、誰かにレイテンシの数値を約束する前に必ず測定してください。

何がこの評決を変えるでしょうか

重要な順に3つのシグナル。第一に、llama.cppにライブASRのフォローアップが入ること——これにより、バッチ書き起こしツールがマイク越しに使えるものへと変わる。これは多くの人が実際に求めているユースケースだ。第二に、標準データセットでの独立したWER測定。それが存在するまで、このモデルのASRを公平に保つ唯一の根拠は、ベンダー自身の前モデルと比較したベンダー提供の表だけだ。第三に、オーディオブランチの公開API価格。これがわかれば、Liquidが音声聴取をサービスとして販売するつもりなのか、それともウェイト主導の取り組みとして維持するつもりなのかがわかる。

それまでは、正確な説明は狭くて有用だ。1分でダウンロードできる2B音声モデルで、置き換えるモデルより話すのは上手く、聞き取りはほぼ同程度で、まだ独立した証人はいない。ラップトップ上のプロトタイプなら、それで十分だ。本番の文字起こしパイプラインなら、十分ではない——そしてその二つの文の間の隔たりこそ、ローンチと評価の間の距離そのものだ。