LFM2.5-Audio-1.5B-JPとは｜1.5Bで7.7B級を上回る日本語音声モデルの性能と使い方

LFM2.5-Audio-1.5B-JPは、Liquid AIが2026年6月に公開した日本語特化の音声モデルです。音声を聞き取り、応答を考え、声で返すまでを単一モデルで担い、この軽量規模では初の日本語Speech-to-Speechモデルと位置づけられています。本記事では、約1.5Bという規模で7.7BのJ-Moshiを上回った音声対話スコアの中身、CommonVoiceとReazonSpeechで大きく分かれたASRの得手不得手、liquid-audioとGGUFでの動かし方、採用を避けるべき場面までを、公式モデルカードとarXiv技術レポートをもとに整理します。

LFM2.5-Audio-1.5B-JPの実力と使いどころのまとめ

このモデルは「整った日本語の聞き取り・読み上げ・対話」を端末内で完結させたい用途で有力な選択肢になります。VoiceBench(ja)の音声対話では、自然な発話を扱うspoken_Elyzaで2.118を記録し、7.7BのJ-Moshi(1.012)やLLM-jp-Moshi(1.023)を倍以上引き離しました。5.5BのQwen2.5-Omni-3B(2.094)も僅差で上回り、パラメータ規模あたりの効率が際立ちます。

得意領域ははっきり分かれます。ASRの文字誤り率(CER)はCommonVoice 8(ja)で4.42と、Whisper-large-v3の8.5を半分近くまで下げた水準ですが、雑多な自然発話を集めたReazonSpeechでは24.24まで悪化し、専用ASRのreazonspeech-nemo-v2(11.2)に大きく劣後します。整った読み上げ調の音声には強く、ノイズや言い淀みの多い録音には弱い。これがこのモデルの素顔です。

導入はliquid-audioパッケージの取得だけで始められ、GPUが無くてもllama.cpp向けのGGUF量子化版でCPU実行できます。ライセンスはLFM Open License v1.0で、Apache 2.0ではない点を先に押さえてください。テキスト版を含む両モデルの全体像や採用判断の枠組みはLFM2.5の日本語モデル群全体の位置づけで扱っているため、本記事は音声モデル単体の性能と実装に踏み込みます。

ASR・TTS・音声対話を1.5Bで統合するLFM2.5-Audio-1.5B-JPの構成

このモデルの特徴は、音声認識・音声合成・音声対話という3つの仕事を、別々の部品を継ぎ足さずに1つのモデルで成立させた点にあります。まずは何を内側に持ち、どんな方式で動くのかを押さえます。

ASR/TTS分離を不要にするエンドツーエンド音声モデルの立ち位置

一般的な音声対話は、音声認識(ASR)で文字に起こし、言語モデルで応答を作り、音声合成(TTS)で読み上げる三段構成を取ります。各段が独立しているぶん実装は見通しやすい反面、テキストへ落とし込む過程で抑揚や言い淀みが失われ、段の継ぎ目ごとに遅延も積み上がる構造です。LFM2.5-Audio-1.5B-JPは、これらを分けずに音声とテキストを直接扱うエンドツーエンド構成を採り、情報の取りこぼしと遅延の累積を抑えます。

系譜としては、英語圏向けに先行公開された無印のエッジAI向け新音声モデルLFM2.5-Audio-1.5Bの概要を土台に、日本語データで仕上げた派生にあたります。日本語の対話・ASR・TTSを1モデルで賄える点が、同規模の英語版との実用上の違いです。

言語コア1.2Bと音声エンコーダ115Mで構成する約1.5Bの内部仕様

内部は、事前学習済みのLFM2.5を言語コアに据え、その周囲を音声専用の部品が固める構造です。入力側は連続波形を取り込むFastConformerベースの音声エンコーダ、出力側はRQ-transformerが離散的な音声トークンを生成し、軽量なデトークナイザが波形へ戻します。主要な仕様を並べると規模感が見えてきます。

言語コアはLFM2系のハイブリッド構造（16層＝LIV畳み込み10層＋GQA6層）で、アテンション一辺倒の設計より計算量とメモリを抑えています。約1.5Bという規模は、量子化を併用すれば数GB級のメモリでも常駐させやすく、設計仕様の詳細はarXiv:2511.23404の技術レポートで確認できます。

低遅延のインターリーブドと変換向けシーケンシャルの2生成方式

生成方式は2種類あり、用途で切り替える仕組みです。インターリーブド生成はテキストと音声を交互に織り交ぜて出力するため、文章全体の完成を待たずに発話を始められ、双方向の音声チャットで体感テンポが上がります。シーケンシャル生成は出力するモダリティを場面ごとに切り替えながら順に生成する方式で、応答テンポより確実な変換が要るASRやTTSに向きます。

• インターリーブド生成：低遅延が要る双方向の音声対話・チャットボット向け
• シーケンシャル生成：書き起こし(ASR)や読み上げ(TTS)など非対話の変換処理向け
• 切り替え基準：応答テンポを優先するか、入力の確実な変換を優先するか

会話エージェントなら前者、議事録の書き起こしやナレーション生成なら後者、と役割を割り振ると取りこぼしが減ります。両方式を1モデルで賄えるため、対話と変換でランタイムを分ける必要がありません。

VoiceBenchとASR-CERで検証する日本語音声性能と7.7B超えの実像

「1.5Bで7.7B級を上回る」という見出しは、どの指標のどの数字を指すのかを分けて読むと正確に評価できます。音声対話とASRでは強さの出方が異なるため、ベンチマークごとに中身を確かめます。

spoken_Elyzaで7.7BのJ-Moshiを上回る音声対話スコアの中身

音声対話の評価には、voicebench-jaから派生したVoiceBenchが使われ、GPT-4oを審査役にスコアを付けています。ElyzaとspokenElyzaは0〜5、M-ifevalは0〜1の尺度です。数字を並べると、規模と性能が比例しない様子が見えます。

応答が音声対話に適しているかを測るspoken_Elyzaで2.118を出し、7.7BのJ-MoshiとLLM-jp-Moshiを倍以上引き離しました。5.5BのQwen2.5-Omni-3B(2.094)も上回っています。書き言葉の応答を前提とするElyzaではQwen2.5-Omni-3B(2.365)に僅差で届かず、指示追従を測るM-ifevalは0.143と低めで、複雑な制約の同時遵守は不得手です。音声を介した自然な対話に強みが寄っている、と読むのが妥当です。

CER4.42のCommonVoiceと24.24のReazonSpeechに出るドメイン差

ASRは文字誤り率(CER)で評価し、数値が低いほど正確です。3つのデータセットで測ると、得意な音声と苦手な音声がはっきり分かれます。

読み上げ調のCommonVoiceでは4.42と、whisper-large-v3(8.5)を半分近くまで引き離し、専用ASRのreazonspeech-nemo-v2(9.1)も上回ります。一方、放送やインタビューなど雑多な自然発話を含むReazonSpeechでは24.24まで悪化し、同セットに強いreazonspeech-nemo-v2(11.2)の倍以上です。整った発話には強く、ノイズや崩れた話し言葉には弱いという、明確なドメイン差が出ています。雑多な録音を相手にするなら、Whisperによる文字起こしなど別系統のASRと比較検証してから選ぶのが安全です。

Qwen2.5-Omni-3BやWhisperと並べた音声モデルの位置づけ

競合との関係を整理すると、立ち位置がつかめます。音声対話の品質ではQwen2.5-Omni-3Bと同等帯にありながら、規模は3分の1以下で、端末側に載せやすい点が差別化軸です。読み上げ調ASRではWhisper-large-v3を上回りますが、自然発話の頑健性ではreazonspeech-nemo-v2やWhisperに一歩譲る構図です。7.7BのMoshi系は音声対話スコアで大きく下回っており、規模が大きいほど日本語音声で強いとは限らない実例になっています。「軽量で端末完結」「整った発話の対話・読み上げ」を取りに行くなら有力で、「あらゆる録音を高精度に書き起こす万能ASR」を求めるなら専用モデルが適します。

liquid-audioとGGUFで動かす3機能別セットアップと実行手順

動かす経路は、Pythonのliquid-audioパッケージを使う標準ルートと、CPUだけで動かすllama.cpp(GGUF)ルートの2つです。タスクの切り替えはコードではなくシステムプロンプトで指定する点に特徴があります。

pip install liquid-audioで始める最小構成とflash-attnの注意点

標準ルートは専用パッケージの導入から始めます。基本コマンドはpip install liquid-audioで、デモ用の追加依存やflash attentionは任意です。対応GPUで高速化したい場合のみpip install flash-attn --no-build-isolationを別途実行しますが、未導入でも標準のtorch SDPAへ自動で切り替わるため、まずは最小構成で一往復を通すのが安全です。flash-attnはビルドに時間がかかり環境依存も強いので、動作確認を終えてから追加を検討すると詰まりを避けられます。

システムプロンプトでASR・TTS・音声対話を切り替える具体手順

同じモデルで3つの仕事を切り替えるには、システムプロンプトに固定の指示文を渡し、対応する生成方式を呼びます。タスクごとの組み合わせは次のとおりです。

会話の組み立てには状態管理のChatStateを使い、システム→ユーザー→アシスタントの順にターンを積み上げます。初回実行では入力音声のサンプリングレートが想定と合っているか、出力を音声にするかテキストにするかの指定が意図どおりかを確認すると、想定外のモダリティで返る事態を防げます。独自データで追加学習する場合、日本語のインターリーブ比率はテキスト6トークン対音声9トークンが既定値です。

GPUなしでもCPU・llama.cppで動かすGGUF量子化版の構成要素

GPUを持たない環境では、量子化済みのGGUFをllama.cppで読み込み、CPUのみで推論できます。音声モデルは言語処理だけでなく音声の入出力も担うため、テキストモデルと違い複数の要素ファイルを揃える必要があります。CPU実行で扱う構成要素は次の4つです。

• 言語モデル本体：応答テキストと音声トークンを生成する中核
• 音声エンコーダ（マルチモーダルプロジェクタ）：入力音声をモデルが扱う表現へ変換
• ボコーダ（音声デトークナイザ）：生成された音声トークンを波形へ戻す
• 音声トークナイザ：音声と離散トークンの相互変換を担う

量子化は精度を落とすほどメモリを節約できますが、応答品質とのトレードオフが生じます。発話開始までの遅延はCPU性能に大きく依存するため、本番に近いハードウェアで応答速度とメモリ使用量を早めに実測しておくと、後の設計変更を減らせます。

車載・オフライン業務での適性と採用を避けるべき場面の判断基準

性能のドメイン差は、そのまま向く用途・向かない用途の線引きになります。端末内完結という長所が効く場面と、精度の限界に当たる場面を具体的に切り分けます。

通信断でも完結する車載・現場端末での日本語音声操作の適性

端末内で推論が閉じる設計は、通信が不安定な現場で価値が出ます。走行中にトンネルや山間部で回線が切れる車載環境では、クラウド依存の音声アシスタントが肝心な場面で応答できなくなりますが、本モデルを端末側に置けば圏外でも日本語の音声操作を続けられる点が強みです。発話から応答までの往復が短く、運転中の操作に伴う待ち時間を抑えられる点も、低遅延のエンドツーエンド構成が支えます。車載ECUからCPU中心の組込み機器まで、量子化精度を機器性能に合わせて選べば、幅広いハードウェアで成立します。

コールセンター応対や議事録など整った発話の業務への強み

CommonVoiceで示した読み上げ調への強さは、発話が比較的整う業務でそのまま効きます。コールセンターの定型応対、対面接客の音声案内、会議後の議事録ドラフト作成などは、明瞭なマイク入力と落ち着いた話し方が前提になりやすく、CER4.42相当の精度を引き出しやすい領域です。音声を端末内で処理すれば、顧客の発話や社内会議の内容を外部送信せずに扱え、個人情報や機密を含む音声でも持ち出しリスクを抑えられます。整った入力が得られる業務ほど、軽量モデルの費用対効果が高まります。

採用を避けるべき場面｜雑多な自然発話と知識集約タスクの限界

逆に、次のような場面では採用を見送るか、別系統との併用に切り替えるのが妥当です。ここは玉虫色にせず、条件を付けて言い切ります。

• ノイズ環境や複数話者が混ざる自然発話の書き起こし：ReazonSpeechでCER24.24まで落ちるため、reazonspeech-nemo-v2やWhisper系の専用ASRを使う
• 専門知識や事実の正確さが要となる応答：約1.2Bの言語コアでは知識網羅に限界があり、誤りを後段で検証できない用途では採用しない
• 複数制約を同時に課す厳密な指示処理：M-ifeval0.143が示すとおり指示遵守が弱く、形式と内容の両立が崩れやすい

これらは規模と引き換えの設計上の代償であり、追加学習でも根本的には埋まりません。誤りを許容できる範囲に用途を絞り、苦手な入力は別モデルへ回す構成にすれば、軽量・低遅延・端末完結という長所を取りこぼさずに使えます。

LFM2.5-Audio-1.5B-JPに関するよくある質問

導入検討でよく挙がる論点を、公式モデルカードの記載をもとに整理します。

LFM2.5-Audio-1.5B-JPは無印のLFM2.5-Audio-1.5Bと何が違いますか？

無印のLFM2.5-Audio-1.5Bを土台に、日本語データで仕上げた派生版です。アーキテクチャや動かし方は共通ですが、日本語の音声対話・ASR・TTSへ向けて学習し直しており、この軽量規模では初の日本語Speech-to-Speechモデルと位置づけられています。日本語中心の用途であれば、JP版を選ぶのが基本になります。

商用利用はできますか？ライセンスは何ですか？

重みはオープンウェイトとして公開され、ライセンスはLFM Open License v1.0です。Apache 2.0とは条項が異なるため、商用利用や再配布の可否は導入時点の原文で必ず確認してください。加えて音声エンコーダはNVIDIA NeMo(Apache 2.0)とcanary-180m-flash(CC-BY 4.0)、依存に含むKyutai Mimi(MITおよびCC-BY 4.0)が関わるため、再配布時はこれらの条件も併せて確認が要ります。

GPUは必須ですか？CPUだけでも動きますか？

GPUは必須ではありません。標準ルートは対応GPUがあればflash attentionで高速化できますが、未導入でもtorch SDPAで動きます。GPUを持たない環境でも、GGUF量子化版をllama.cppで読み込めばCPUのみで推論できる構成です。発話までの遅延はCPU性能に依存するため、本番相当の機器で実測しておくと見積もりが安定します。

テキスト版のLFM2.5-1.2B-JPとどう使い分けますか？

音声の入出力が要るならAudio版、テキスト処理だけならLFM2.5-1.2B-JP（最新版202606）が向きます。現場で音声入力を受けて書き起こし、その内容をテキスト版で整形・要約し、業務システムへ渡すといった役割分担も有効です。両モデルの全体像と選定基準は、関連記事の全体像解説で詳しく扱っています。

日本語以外の言語にも対応していますか？

このJP版は日本語に特化しており、対応言語は日本語です。多言語を横断して扱う場合は、無印のLFM2.5-Audioや他系統のモデルを検討してください。日本語に用途が偏るアプリほど、特化版の効率が活きます。

関連記事

• AItuber運営者が注目する8B日本語特化モデルArrowCanariaの設計思想：日本語特化モデルを対話品質の観点で選ぶ際の比較軸として参考になります。
• LLM-jp-4が国産LLMの新到達点とされる開発背景と2モデル構成の全体像：国産・日本語特化LLMの系譜とライセンス確認の進め方を補完できます。
• Ollama + Open WebUI でローカルLLMを手軽に楽しむ方法：ローカルでLLMを動かす実行環境づくりの入口として併読をおすすめします。