LFM2.5-Audio-1.5B-JPとは？英語版との違い・日本語性能・GGUFでGPUなし実行・商用ライセンス【2026年10月】

LFM2.5-Audio-1.5Bは、米Liquid AIが2026年1月に公開した、音声認識（ASR）・音声合成（TTS）・音声対話を1つのモデルで処理する約15億パラメータの音声言語モデルです。無印の対応言語は英語だけで、日本語で使うなら2026年6月に公開された派生版LFM2.5-Audio-1.5B-JPを選びます。この記事では、英語版とJP版の違い、日本語ベンチマーク、Pythonとllama.cpp系ランナーでの動かし方、商用ライセンスの条件をまとめます。公式ランナーが配布されていないIntel Macでランナーをビルドし、JP版で日本語の文字起こし・読み上げ・音声対話を実行した結果も載せています。LFM2.5ファミリー全体の一覧はLFM2.5とは？Liquid AIの全モデル一覧と選び方で扱っています。

まとめ：LFM2.5-Audio-1.5BとJP版の要点

• 日本語ならJP版：無印は英語専用。JP版は同じ構成を日本語向けに学習したもので、システムプロンプトもPerform ASR in japanese.のように日本語用の文字列を使う。
• 構成：言語モデル1.2B＋音声エンコーダ115M＋音声出力用RQ-Transformer 185Mで約1.5B。コンテキスト長はモデルカードの公称で32,768トークン、出力音声は24kHz。
• JP版の実力：日本語の音声対話spoken_Elyzaで2.118と、7.7BのJ-Moshi（1.012）を上回る。ASRのCERは読み上げ調のCommonVoiceで4.42だが、自然な話し言葉のReazonSpeechでは24.24まで悪化する。
• GPUなしの実行：GGUF版（Q4_0は4ファイルで約1.07GB）と専用ランナーllama-liquid-audio-cliで動く。配布ランナーはAndroid・macOS（Appleシリコン）・Ubuntu向けだけ。Intel Mac（Core i9-9880H）でビルドすると、12.2秒の日本語音声を12.47秒で文字起こしできた。
• ライセンス：LFM Open License v1.0。年間売上1,000万米ドル以上の法人による商用利用は許諾の対象外で、売上はグループ会社を含めて判定する。

以下、英語版とJP版の違い、ベンチマーク、Python・GGUFでの実行手順、Intel Macでの実測、ライセンス、採用判断の順に説明します。

英語版とJP版の違いと選び方

共通の構成：1.2Bの言語モデルと音声部品で約1.5B

骨格はLFM2.5の事前学習済み言語モデルです。Liquid AIの公式ドキュメントは、1.5Bの内訳を「1.2BのLM＋115Mの音声エンコーダ＋音声出力用の185MのRQ-Transformer」と記載しています。音声の入力はFastConformerベースのエンコーダが受け取り、出力はRQ-Transformerが生成した離散トークンを軽量デトークナイザが波形に戻します。この構成は英語版とJP版で共通で、ドキュメントもJP版を「英語版と同じアーキテクチャと実行経路を使う日本語向けの派生」と説明しています。

JP版の公開は、Liquid AIの日本法人が2026年6月5日のプレスリリースで、テキストモデルLFM2.5-1.2B-JP-202606と同時に発表しています。Liquid AIの公式なONNX版とMLX版は英語版にしかありません（JP版はサードパーティによるONNX変換が公開されているのみです）。

システムプロンプトの固定文字列と英語版TTSの声4種

このモデルはタスクをシステムプロンプトの固定文字列で切り替えます。英語版と日本語版で文字列が違い、JP版のモデルカードは固定プロンプトとしてPerform ASR in japanese.とPerform TTS in japanese.を指定しており、JP版GGUFの配布ランナーには英語版のASR用文字列Perform ASR.が入っていません。

英語版のTTSは、米国英語と英国英語の男女4種から声を選び、プロンプトで指定する必要があります。JP版のプロンプトには声の指定がありません。インターリーブ生成はテキストと音声のトークンを決まった比率で交互に出す方式で、最初の音声が出るまでの時間を縮められるため音声対話に使います。JP版のモデルカードは、日本語の比率をテキスト6トークン対音声9トークンとしており、インターリーブ形式で追加学習するときはこの値をLFM2AudioChatMapperに渡すよう案内しています。シーケンシャル生成は、モデルが特殊トークンで出力の種類を切り替える方式で、文字起こしと読み上げに使います。

ベンチマークで見る英語版とJP版の実力

英語版：VoiceBench 54.92と英語ASRのWER 7.53

数値は英語版のモデルカードの公表値で（規模も各モデルカードの記載のままで、Qwen2.5-Omni-3Bは英語版のカードでは5B、JP版のカードでは5.5B）、WERは英語8データセットの平均（低いほど良い）です。前世代から最も伸びたのは推論系のBBHで、30.54から49.54に上がりました。一方、指示追従のIFEvalは31.23から28.48に下がっています。ASRはASR専用のWhisper-large-v3と0.09ポイント差です。一方、知識系のMMSU（33.04対55.29）とOBQA（44.40対76.26）では、規模が3倍以上のQwen2.5-Omni-3Bに20ポイント以上及びません。

JP版：spoken_Elyza 2.118で7.7B級を上回る音声対話

JP版のモデルカードによると、評価データはsbintuitions/voicebench-jaから作られ、GPT-4oが採点し、サンプルごとに最も高い採点を報告しています。Elyzaとspoken_Elyzaは0〜5点、M-ifevalは0〜1点です。どちらも質問は音声で入力します。Elyzaはvoicebench-jaがELYZA-tasks-100から抜き出した36問を音声合成したもので、回答の質を見ます。spoken_Elyzaは同じ質問の模範解答から記号やMarkdownなど音声で伝わらない要素を除いた34問で、音声対話に向いた答え方かを見ます。spoken_Elyzaでは、7.7BのJ-MoshiとLLM-jp-Moshi-v1の2倍以上のスコアで、5.5BのQwen2.5-Omni-3Bもわずかに上回ります。ElyzaではQwen2.5-Omni-3Bに届かず、指示追従のM-ifevalは0.143で、J-Moshi（0.151）より低い値です。「7.7B級を上回る」は音声対話の2指標の話で、指示どおりの形式で答える力まで上回るわけではありません。

JP版のASR：CommonVoice CER 4.42とReazonSpeech 24.24の差

値は文字誤り率（CER・%）で、低いほど正確です。比較モデルの値はjapanese-asrの公表値をモデルカードが引用したものです。一般の人が文章を読み上げたCommonVoiceでは、whisper-large-v3の約半分の誤り率です。テレビ放送の音声から作られたReazonSpeechでは24.24まで悪化し、NeMoベースのreazonspeech-nemo-v2（11.2）の2倍を超えます。ただし同じ読み上げ音声でも、1人の話者が朗読したJSUT Basic 5000では8.07と、whisper-large-v3（7.1）やreazonspeech-nemo-v2（7.4）より誤りが多く、読み上げ調なら常に強いわけではありません。NeMo系の日本語ASRの選び方はNeMo ASRとは？NVIDIA音声認識モデルの選び方と日本語の実測・導入手順で扱っています。

LFM2-Audioからの変更：8倍速いデトークナイザ

前世代のLFM2-Audio-1.5Bは、音声トークンを波形に戻す処理にKyutaiのMimiデコーダを使っていました。Liquid AIの発表ブログによると、LFM2.5ではLFMベースの自社デトークナイザに置き換え、同じ精度で比べてモバイルCPU上で8倍速くなりました。INT4を前提にした量子化認識学習（QAT）により、INT4での音質指標UTMOSは3.53で、FP32のMimi（3.65）からの低下は小さく、MimiをそのままINT4にした場合（3.11）より高い値です。PTQとQATの違いは量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説で解説しています。

Pythonで動かす手順（liquid-audio 1.3.0）

動作要件：Python 3.12以上・PyTorch 2.8以上・既定はCUDA

公式の推論ライブラリはliquid-audioです。2026年10月時点のPyPI最新は2026年6月5日公開の1.3.0で、Python 3.12以上、依存にtorch>=2.8.0とtransformers>=4.55.4を含みます。公式ドキュメントはtorchcodecも一緒に入れるよう案内しており、torchcodecはシステムにFFmpegが入っていないと音声ファイルを読めません。FFmpegが要るのはtorchaudio.loadで音声を読む場合で、下の例のようにsoundfileでWAVを読むなら使いません。

pip install liquid-audio torchcodec
brew install ffmpeg            # macOSの場合。Ubuntuは apt install ffmpeg
pip install flash-attn --no-build-isolation   # 任意。未導入ならPyTorchのSDPAで動作

注意点は2つあります。1つ目は実行デバイスです。liquid-audio 1.3.0のソースでは、LFM2AudioModel.from_pretrainedとLFM2AudioProcessor.from_pretrainedの引数deviceの既定値がどちらも"cuda"で、モデルのdtypeの既定はtorch.bfloat16です。ただしdevice="cpu"を渡しても、音声を波形に戻すデトークナイザはソース上.cuda()固定で読み込まれるため、読み上げと音声対話の音声出力にはCUDA（ROCm版PyTorchを含む）が必要です。モデルカードのコードも、NVIDIAのCUDA環境か、READMEがインストール例を載せているAMD ROCm環境を前提にしています。2つ目はIntel Macです。PyPIのtorch 2.8.0はmacOS向けにはarm64のwheelしか無く（x86_64版の最後は2.2.2）、Intel Macにはpipでliquid-audioを入れられません。FlashAttentionの対応GPUはFlashAttentionとは？仕組みとFA2・FA3・FA4の違いを参照してください。

JP版で日本語を文字起こしする最小コード

JP版のモデルカードにあるASRの例です。システムプロンプトにPerform ASR in japanese.を置き、generate_sequentialが返すトークンのうち要素数1のもの（テキスト）だけを文字に戻します。入力はモノラルのWAVで、ここでは実行ディレクトリのasr_jp.wavを読みます。

import torch
import soundfile as sf
from liquid_audio import LFM2AudioModel, LFM2AudioProcessor, ChatState

HF_REPO = "LiquidAI/LFM2.5-Audio-1.5B-JP"

processor = LFM2AudioProcessor.from_pretrained(HF_REPO).eval()
model = LFM2AudioModel.from_pretrained(HF_REPO).eval()

chat = ChatState(processor)
chat.new_turn("system")
chat.add_text("Perform ASR in japanese.")
chat.end_turn()

chat.new_turn("user")
wav, sampling_rate = sf.read("asr_jp.wav", dtype="float32")
chat.add_audio(torch.from_numpy(wav).unsqueeze(0), sampling_rate)
chat.end_turn()

chat.new_turn("assistant")
for t in model.generate_sequential(**chat, max_new_tokens=512):
    if t.numel() == 1:
        print(processor.text.decode(t), end="", flush=True)

英語版で使う場合は、HF_REPOをLiquidAI/LFM2.5-Audio-1.5Bに、プロンプトをPerform ASR.に替えます。読み上げはプロンプトをPerform TTS in japanese.にしてテキストを渡し、要素数が1より大きいトークン（音声）を集め、末尾の音声終了コードを除いて（audio_out[:-1]）からprocessor.decodeで24kHzの波形に戻します。

GPUなしで動かすGGUF版とllama-liquid-audio-cli

4ファイル構成と量子化別の容量

GGUF版は、言語モデル本体・音声エンコーダ（mmproj）・ボコーダ・トークナイザの4ファイルを量子化の種類ごとに置いています。実行時は4つすべてを指定します。

容量は英語版GGUFとJP版GGUFのファイルサイズ（10の6乗バイトを1MBとして計算）で、幅があるのは英語版とJP版の差です。後述の実測ではQ4_0を使いました。

ASR・TTS・音声対話のコマンド（JP版）

使うOSに合ったランナーをJP版GGUFリポジトリのrunnersフォルダから取り出して展開し（英語版リポジトリのランナーには日本語プロンプトが入っていません）、llama-liquid-audio-cliのあるディレクトリで実行します。-sysに渡すシステムプロンプトでタスクを切り替えます。

export CKPT=/path/to/LFM2.5-Audio-1.5B-JP-GGUF
M=(-m $CKPT/LFM2.5-Audio-1.5B-JP-Q4_0.gguf
   -mm $CKPT/mmproj-LFM2.5-Audio-1.5B-JP-Q4_0.gguf
   -mv $CKPT/vocoder-LFM2.5-Audio-1.5B-JP-Q4_0.gguf
   --tts-speaker-file $CKPT/tokenizer-LFM2.5-Audio-1.5B-JP-Q4_0.gguf)

# 文字起こし（音声→テキスト）
./llama-liquid-audio-cli "${M[@]}" -sys "Perform ASR in japanese." --audio input.wav

# 読み上げ（テキスト→音声）
./llama-liquid-audio-cli "${M[@]}" -sys "Perform TTS in japanese." -p "こんにちは。" --output tts.wav

# 音声対話（音声→音声＋テキスト）
./llama-liquid-audio-cli "${M[@]}" -sys "Respond with interleaved text and audio." --audio input.wav --output reply.wav

4ファイルの指定を配列Mにまとめているのは、bashとmacOS既定のzshの両方で同じように動かすためです。文字列の変数にして$Mで展開する書き方は、zshでは1つの引数として渡されinvalid argumentで止まります。JP版GGUFのREADMEに載っているコマンドは、ファイル名がLFM2.5-Audio-1.5B-Q4_0.ggufのように-JPの無い名前になっていて、実際のファイル名と一致しません。上のように-JP付きの名前に直して使います。常駐させたい場合は同じ引数でllama-liquid-audio-serverを起動し、英語版GGUFリポジトリにあるliquid_audio_chat.pyから話しかけます（JP版リポジトリのREADMEも同じスクリプトを案内していますが、ファイルは含まれていません）。

配布ランナーの対応OSとONNX・MLX版

GGUF形式でも、通常のllama-cliやOllamaでは動きません。音声対応はllama.cppのプルリクエスト#18641で実装されていますが、2026年10月時点でも題名に「Do Not Merge」が付いたドラフトのままで、本体には入っていません。配布ランナーはandroid-arm64、macos-arm64、ubuntu-arm64、ubuntu-x64の4種類だけで、WindowsとIntel Mac向けは用意されていない状態です。GGUFと他の量子化形式の違いはLLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説を参照してください。

英語版には別の経路もあります。ONNX版はONNX RuntimeとWebGPUを想定しており、カードはQ4（約1.5GB）を推奨しています。ブラウザで動かすならQ4のデコーダとQ4のボコーダの組み合わせで、Q8はWebGPU非対応です。Appleシリコン向けにはmlx-communityの4bit〜8bit版とbf16版があり、mlx-audioで読み込みます。MLX自体の使い方はMLXとは？mlx-lmの使い方で解説しています。どちらもJP版の公式版は2026年10月時点で公開されていません。

Intel MacでJP版を動かした実測：ビルド手順と速度

PRブランチのビルドで当たる3つの落とし穴

公式ランナーの無いIntel Mac（MacBook Pro、Core i9-9880H 8コア16スレッド、メモリ16GB、macOS 26.6.2）で、PR #18641のブランチ（2026年9月1日のコミットec9d1fd）をビルドしました。そのままでは3か所で止まります。

• OpenSSL 4との非互換：Homebrewで入れたOpenSSL 4.0.3を検出すると、同梱のcpp-httplibがX509_NAMEのconst化でコンパイルエラーになる。音声の実行にHTTPSは不要なので-DLLAMA_OPENSSL=OFFで外す。
• 共有ライブラリでのリンクエラー：既定の共有ライブラリ構成では、libmtmd.dylibがcommon_init_resultを解決できずリンクに失敗する。-DBUILD_SHARED_LIBS=OFFで静的リンクにすると通る。
• 日本語プロンプトを受け付けない：ブランチのCLIは使えるプロンプトを固定のリストで判定しており、リストに英語版の6種しかない。Perform ASR in japanese.を渡すと「Unsupported system prompt」で終了する。JP版GGUFリポジトリのmacOS版ランナーには日本語の2種が文字列として入っており、配布ランナーと公開ブランチのソースは一致していない。

3つ目はtools/liquid-audio/cli.cppの判定に日本語の2種を足して回避しました。CLIのビルドにかかった時間は約5分（297秒）です。

git clone --depth 1 --branch tarek/feat/os-lfm2.5-audio-1.5b-upstream \
  https://github.com/tdakhran/llama.cpp.git
cd llama.cpp
git log -1 --format=%h   # 測定時は ec9d1fd。違う場合はブランチが更新されている
# cli.cpp の判定に日本語プロンプトを追加（変更は2行）
#   tts_system_prompts に "Perform TTS in japanese." を追加
#   if (system_prompt == asr_system_prompt || system_prompt == "Perform ASR in japanese.")
cmake -B build -DGGML_METAL=OFF -DLLAMA_OPENSSL=OFF -DBUILD_SHARED_LIBS=OFF
cmake --build build --target llama-liquid-audio-cli -j 8
# 実行ファイルは build/bin/llama-liquid-audio-cli に出る

-DGGML_METAL=OFFは、このMacBook ProがAMDの単体GPUを積んでいるため、CPUだけの測定にそろえる目的で指定しています。Windowsでも同じブランチから自分でビルドすることになり、同じ3点に当たる可能性があります。ただしこの記事ではWindowsでのビルドは検証していません。いずれも未マージのブランチを自前で保守する形になる点は、採用前に織り込んでください。

Core i9-9880HでのASR・TTS・音声対話の所要時間

JP版Q4_0を、GPUを使わずCPUだけで実行した結果です（2026年10月24日測定）。入力の日本語音声はmacOSのsayコマンド（声はKyoko、16kHzモノラル）で作った読み上げ音声で（音声対話の質問はモデルカードの例文と同じ文です）、所要時間はモデルの読み込み（ASRで約1.8秒）を含むコマンド全体の時間です。

メモリは/usr/bin/time -lのpeak memory footprintです。ASRでは「本日はお忙しい中、貴重なお時間をいただき誠にありがとうございました。次回の会議は十一月五日の午後三時から、第二会議室で行います。」という読み上げを、「誠に」の1語が抜けた以外は正しく文字にしました。漢数字で読ませた日付と時刻は「11月5日の午後3時」と算用数字で返ります。音声対話では「富士山の高さは何メートルですか。」に「富士山の高さは約3,776メートルです。」と音声とテキストで答えました。

速度の面では、TTSの音声生成が毎秒8,034サンプル、音声対話では毎秒6,935サンプルでした。出力は24kHzなので、再生速度の約0.33倍と0.29倍しか作れません。この世代のIntel CPUで、音声を生成しながら途切れずに再生するリアルタイム対話は成り立たないと判断します。文字起こしは、12.2秒の音声を読み込み込みで12.47秒（実時間比約1.02）、読み込みを除くと約10.6秒（約0.87）で処理しました。1時間の音声ならおよそ1時間かかる計算で、会議録をまとめて処理する用途なら実用の範囲です。

TTSに渡した「このたびはご相談いただきありがとうございます。来週中にお見積もりをお送りしたいと考えております。」の出力をもう一度ASRにかけると、「ご相談いただいただけありがとうございます」「見積もりを送りしたい」と返りました。「いただき」が崩れ、「お見積もり」「お送り」の「お」が落ちています。読み上げと文字起こしのどちらで崩れたかはこの往復では切り分けられないので、敬語の多い業務文で使う前に自社の音声で個別に確かめてください。

LFM Open License v1.0の商用利用条件

年間売上1,000万米ドルの基準とグループでの判定

重みとコードはLFM Open License v1.0で提供され、英語版とJP版で同じです。条文の骨格はApache License 2.0と同じですが、第5条に商用利用の制限が加わっています。第1条は閾値（Threshold）を「年間売上1,000万米ドル以上」と定義し、第5条は商用利用の許諾を、利用者の法人がこの閾値を超えないことを条件にしています。閾値を超える法人の商用利用は、このライセンスでは許諾されません。

「商用利用」は「直接または間接の商業的利益や金銭的対価を目的とする利用」と定義されています。製品に組み込んで販売する場合だけでなく、自社業務の効率化に使う場合も間接的な商業的利益に当たる可能性があります。売上の判定単位である法人（Legal Entity）には、利用主体と支配・被支配・共通支配の関係にある組織が含まれ、支配には発行済株式の50%以上の保有も入ります。子会社単体の売上が小さくても親会社を含めると閾値を超える場合があるので、グループの範囲を法務で確認し、必要ならLiquid AIに問い合わせてください。研究など商用でない利用には、この売上条件はかかりません。第5条(c)も、適格な非営利団体による非商用・研究目的の利用に閾値を適用しないと明記しています。

再配布時の義務と同梱コンポーネントのライセンス

第4条では、ライセンス文の添付、変更したファイルへの変更表示、著作権・特許・商標・帰属表示の保持を求めています。元の配布物にNOTICEファイルがある場合は、派生物にも該当する帰属表示を含めます。モデルを組み込んだアプリを配布する場合はこの条件に従います。

リポジトリには、LFM Open License以外の部品も含まれます。音声エンコーダのコードはNVIDIA NeMo由来でApache 2.0、元になったcanary-180m-flashの重みはCC BY 4.0です。KyutaiのMimiのPythonコードはMITライセンス、再配布されているMimiの重みはCC BY 4.0です。CC BY 4.0の部品を含めて配布するなら、それぞれのクレジット表記も必要です。

採用を判断する基準：向く用途と避ける場面

向いているのは、日本語または英語の音声インターフェースを端末の中で完結させたい場合です。文字起こし、読み上げ、音声対話を1つの重みで切り替えられるため、ASR・LLM・TTSを別々に選んで接続する構成より部品が減ります。通信が途切れる車載機器や現場端末、会議音声を社外に出せない議事録作成が主な対象です。JP版のCERは読み上げ調のCommonVoiceで最も良く、放送音声のReazonSpeechで最も悪い値です。ただし朗読コーパスのJSUTではwhisper-large-v3に及ばないため、自社の音声で比べてから決めてください。端末内で動く音声認識を業務システムに組み込む場合は、AI音声認識システム開発として要件定義から支援できます。

次の場面では、このモデルを選ばないほうがよいと判断します。

• 放送や雑談のような崩れた話し言葉を文字起こしする：ReazonSpeechでCER 24.24。reazonspeech-nemo-v2（11.2）やwhisper-large-v3（14.9）のほうが誤りが少ない。
• 知識を問う質問に答えさせる：英語版はMMSUとOBQAでQwen2.5-Omni-3Bに20ポイント以上及ばない。知識が要る応答はRAGで補うか、クラウドのモデルに回す。
• 決まった形式で答えさせる：JP版のM-ifevalは0.143。JSONや箇条書きの形式を守らせる用途は、テキストモデルのLFM2.5-1.2B-JPに文字起こし結果を渡して整形するほうが確実。
• 古いIntel CPUでリアルタイムに音声対話させる：実測でTTSが再生速度の約0.33倍。GPUなしで応答の速さが要るなら、Appleシリコンや配布ランナーのある環境で測り直す。
• WindowsサーバでGPUなしに動かす：配布ランナーが無く、未マージのブランチを自分でビルドして保守することになる。

日本語のオンデバイス音声認識を他の選択肢と比べるなら、Moonshine Voiceとは？STT・TTSの使い方と日本語の実測、Whisper比較が参考になります。音声合成の方式全体は音声合成AIの作り方｜OSS TTS・クラウドAPI・受託開発の方式選定と実装手順、クラウド側で全二重の音声対話を組む選択肢はGPT-Live-1とは？APIの料金・使い方とRealtime APIとの違いで比較しています。

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

LFM2.5-Audio-1.5Bは日本語に対応していますか？

無印は対応していません。モデルカードの対応言語は英語のみです。日本語の音声対話・文字起こし・読み上げには、同じ構成を日本語向けに学習したLFM2.5-Audio-1.5B-JPを使い、システムプロンプトもPerform ASR in japanese.などの日本語用の文字列にします。

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

アーキテクチャ、パラメータ数、実行経路は同じで、学習と評価の対象言語が違います。JP版は日本語の音声対話spoken_Elyzaで2.118を出し、7.7BのJ-Moshiを上回ります。公式の配布形式は、英語版にあるONNX版とMLX版がJP版には無く、PyTorch版とGGUF版だけです。

GPUがないPCでも動かせますか？

GGUF版と専用ランナーのllama-liquid-audio-cliを使えば、CPUだけで動きます。配布ランナーはAndroid、macOS（Appleシリコン）、Ubuntu向けで、Intel MacやWindowsではPR #18641のブランチを自分でビルドします。Pythonのliquid-audio 1.3.0は既定の実行デバイスがCUDAで、音声出力用のデトークナイザもCUDA固定のため、GPUなしでは読み上げと音声対話の音声を作れません。

LFM Open License v1.0で商用利用はできますか？

年間売上が1,000万米ドル未満の法人なら可能です。売上は支配関係にあるグループ会社を含めて判定します。1,000万米ドル以上の法人による商用利用はこのライセンスでは許諾されないため、Liquid AIから別途ライセンスを受ける必要があります。

LFM2-Audio-1.5Bとの違いは何ですか？

骨格の言語モデルがLFM2.5世代に上がったこと、デトークナイザがMimiからLFMベースの新設計に替わってモバイルCPUで8倍速くなったこと、英語ASRの平均WERが9.38から7.53に下がったことの3点です。日本語版が出たのもLFM2.5世代からです。

関連記事

• LFM2.5とは？Liquid AIの全モデル一覧（230M〜8B-A1B）と選び方・Ollama実行・ライセンス【2026年10月時点】
• LFM2.5-1.2B-JPとは？Liquid AIの日本語オンデバイスLLMの性能・使い方・ライセンス
• NeMo ASRとは？NVIDIA音声認識モデルの選び方と日本語の実測・導入手順【NeMo Speech 3.0】
• Moonshine Voiceとは？STT・TTSの使い方と日本語の実測、Whisper比較【v0.1.5】
• 音声合成AIの作り方｜OSS TTS・クラウドAPI・受託開発の方式選定と実装手順