TL;DR

2026-10-27に出た Liquid AI の LFM3-Omni-2B(テキスト・画像・音声を入れて、テキストと音声で返すモデル)を、RTX 3050 6GB のWindows機で動かした。VRAM使用量のピークは 約4.3GB
STT(文字起こし)は実用的。14秒の音声が 約1.4秒 で、名前も電話番号も全部正解した。ただし文脈のない短い語や同音語(「精度」「誤報」「席/咳」)は弱い
TTS(読み上げ)の日本語発音は弱め。受付っぽい8文を読ませ、同じモデルで聞き直すと平均CER 約15%。「さくら歯科」が「桜博士」になった
ストリーミングTTSは 最初の音が出るまで0.62秒。一方、話しながら文字にする LiveASR(transcribe_live)は英語のみ。日本語を流すとローマ字になるので、「一括の文字起こしを0.8秒ごとにやり直す」方式で代用した
速さを決めるのは VRAMの「容量」ではなく「帯域」。4.3GBが載れば、6GBでも24GBでも速さはほぼ同じ(のはず)

やろうとしたこと

Liquid AI が 2026-10-27 に第3世代の LFM3 を発表しました。6モデルあって、全部2B級のオープンウェイトです。中でも気になったのが、同社初のomniモデル LFM3-Omni-2B です。

入力: テキスト・画像・動画・音声
出力: テキスト・音声・その両方を交互に(interleaved)
音声の対応言語に 日本語 が入っている(モデルカードに記載)

「2Bで音声を聞いて、音声で返せる」なら、電話受付AIの部品に使えるかもしれません。そこで 日本語のTTSとSTTがどこまで使えるか を、手元のミドル以下のGPUで確かめてみました。

環境

項目	内容
OS	Windows 11
GPU	GeForce RTX 3050(VRAM 6GB)
Python	3.11(uv で venv)
torch	2.14.1+cu126
transformers	5.21.0
モデル	`LiquidAI/LFM3-Omni-2B`(bf16、ダウンロード約4.2GB)

インストールはモデルカードどおりです。

uv pip install torch torchvision torchcodec --index-url https://download.pytorch.org/whl/cu126
uv pip install "transformers>=5.20.2" accelerate pillow librosa soundfile sounddevice

読み込みは trust_remote_code=True です。音声を出すときは、processor に付いている音声コーデック(audio_tokenizer)も使います。

model = AutoModelForMultimodalLM.from_pretrained(
    "LiquidAI/LFM3-Omni-2B", dtype=torch.bfloat16, device_map="cuda", trust_remote_code=True
).eval()
processor = AutoProcessor.from_pretrained("LiquidAI/LFM3-Omni-2B", trust_remote_code=True)
codec = processor.audio_tokenizer.to("cuda").eval()

モードはシステムプロンプトと generation_mode で切り替えます。

やりたいこと	システムプロンプト	`generation_mode`
STT	`Perform ASR in Japanese.`	`text`
TTS	`Perform TTS in Japanese using a female voice.`	`audio`
音声で返す会話	`Respond with interleaved text and audio.`	`interleaved`

モデルの読み込みは毎回 6〜7秒、VRAMの確保量のピークは 約4.3GB(torch.cuda.max_memory_allocated)でした。6GBのカードに余裕を持って載ります。

STT(文字起こし)の結果

速さ: 文字数でほぼ決まる

マイクで録った14秒の音声(挨拶+名前+電話番号)を途中で切って、処理時間を測りました(ウォームアップ後、2回のうち速い方)。

音声の長さ	処理時間	出力
2秒	0.27秒	おはようございます。
5秒	0.57秒	おはようございます。名前は〇〇と申します。
8秒	1.13秒	…電話番号はゼロ九ゼロ一二三。
14秒	1.36秒	…電話番号はゼロ九ゼロ一二三四五六七八です。

名前(自分の名字)の漢字も、電話番号の全桁も正解しました。注意点として、数字は「ゼロ九ゼロ…」とカナや漢数字で出ます。正解文を算用数字で書いてCERを計算すると35%と出ますが、内容は全部合っています。実際に使うときは数字への変換が要りますね。

精度: ふつうの文は強く、短い語と同音語は弱い

マイクで13回しゃべってみた結果です。

話した内容	文字起こし
電話番号は090…	電話番号はゼロ九ゼロ一二三四五六七八。	✅
もう一度話します	もう一度話します。	✅
うん、なるほど	うん、なるほど。	✅
精度は微妙かな	セイダビンよかな。/ 誠度は微妙かな。	⚠️
ごほんごほん	ごほうごほう。	⚠️
咳	席	⚠️

ふつうの文はほぼ正確です。崩れるのは、前後の文脈がない短い語 と 同音語 でした。名前も、ある回では漢字、別の回ではカタカナになりました。受付の用途なら、名前と電話番号は取れるが、固有名詞の漢字は推測、という感触です。

LiveASR(`transcribe_live`)は英語のみ

モデルには、音声を0.96秒ずつ流し込んで、話しながら文字にする transcribe_live(LiveASR)があります。使い方はOmniではなく、姉妹モデル LFM3-Audio-2B のモデルカード に載っています(システムプロンプトは Perform live ASR.)。同じカードに 「LiveASRは現時点で英語のみ」 と明記されています。

実際にOmniで流した結果がこちらです(1チャンクの処理は平均200〜250ms)。

入力	0.96秒ごとの出力
英語(TTSで作った予約変更の質問)	Thank you. \| for calling \| Sakur a dental. \| I would like to \| change my \| appointment to tomorrow \| at three in the \| afternoon. Is \| that time available?
日本語(マイク録音)	Well, \| hayou gozaimasu. \| Namae wa seki no. \| Namae to moushimasu. \| Dian ban go. \| 0901234 \| 0678.

英語はほぼ完璧です。日本語は 音としては聞き取れているけれど、ローマ字で出てきます。日本語対応を待つしかなさそうです。

代用: 「やり直し方式」の擬似ストリーミング

一括の文字起こしが十分速いので、次の方式にしました。

話している間は 0.8秒ごとに、その発話の頭から今までを文字起こしし直し、途中経過を表示する
0.6秒の無音 で、その発話を確定する

マイクで試したところ、途中経過は「おはよう。」→「おはようございます。名前は…」→「…電話番号はゼロ九…」と伸びていき、話し終わりから確定までは0.62〜1.46秒 でした。内訳は、無音待ち0.6秒、最終の文字起こし0.1〜0.7秒、途中経過の処理との重なり、です。

TTS(読み上げ)の結果

発音: 日本語は弱め

歯科受付っぽい8文を、女性・男性の声で読ませました(計16本)。発音は自分の耳で聞いて「ちょっと弱い」と感じたので、同じモデルのSTTで聞き直して CERを出してみました。STT側の誤りも混ざるので、あくまで目安です。

読ませた文	聞き直した結果(悪かった方)	CER
お電話ありがとうございます。さくら歯科でございます。	お電話る宿小座をます桜博士でございます。	54%
保険証を忘れずにお持ちください。	リペン賞を忘れずにお持ちください。	27%
本日は…まで診療しております。	今週は…まで診療しとろみす。	35%
痛みが強い場合は、すぐにお越しください。	(男女とも完全一致)	0%

16本の平均CERは 約15% でした。このCERには「三」→「3」のような表記の違いも含まれます。決まり文句は綺麗に読めますが、固有名詞(さくら歯科)や「保険証」「診療」のような語で崩れる 傾向があります。そのまま電話口に出すのは、ちょっと厳しいですね。

速さとストリーミング

一括で生成すると、音声の長さに対して 0.74〜1.40倍 の時間がかかります。RTX 3050 だと、再生速度とほぼ同じです。

モデルには音声フレーム(80ms)を1つずつ受け取れる audio_streamer と、コーデックの逐次デコード(streaming_cache)があります。これを使って「生成しながら再生する」ようにしました。

class FrameQueue(BaseStreamer):
    def __init__(self): self.q = queue.Queue()
    def put(self, codes): self.q.put(codes.detach().clone())  # (num_codebooks,)
    def end(self): self.q.put(None)

# 別スレッドで model.generate(..., audio_streamer=frames)
# メイン側で3フレーム(240ms)ずつ codec.decode(chunk, streaming_cache=cache, finalize=last)

	最初の音が出るまで	生成完了 / 音声の長さ	途切れ
TTS(挨拶文)	0.62秒	7.1秒 / 8.3秒	0回
音声で質問→音声で返答	1.14秒	20.2秒 / 23.4秒	3回
同上、先に0.5秒分ためてから再生	1.51秒	12.4秒 / 14.1秒	0回

一括生成では最初の音まで約5秒待っていましたが、それが 0.6秒 まで縮みました。生成は再生のおよそ1.15倍の速さしかないので、会話モードでは途切れが出ます。0.5秒分を先にためれば解消 しました(1回だけの確認です)。

VRAMの「容量」は速さに効くのか

結論から言うと、容量は「載るかどうか」だけで、速さはほぼ帯域で決まります。

TTSは、80msの音声を1フレーム作るたびに約4GBの重みを読み直す、1つずつの生成です。つまり メモリ帯域が律速 になります
STTは、音声をまとめて読む前半は計算性能、文字を出す後半は帯域が効きます
RTX 3050 の帯域は 200GB/s 弱と細めです。帯域だけで見積もると、RTX 4070(約500GB/s)なら2〜3倍速くなる計算です(実測ではありません)
容量が効くのは、載らずにCPUへの退避が起きたときと、複数回線を同時に捌くとき(1回線ごとにKVキャッシュが要る)です

学んだこと

	評価	ひとこと
STT(一括)	✅	14秒の音声を1.4秒で。ふつうの文はほぼ正確
STT(LiveASR)	⚠️	英語は完璧、日本語はローマ字になる。やり直し方式で代用
TTS(発音)	⚠️	決まり文句は良いが、固有名詞で崩れる
TTS(ストリーミング)	✅	最初の音まで0.6秒。6GBのGPUでも再生に追いつく

2Bでこれだけ聞けて、しゃべれるのは素直にすごい。ただ、日本語の電話受付をこれ1本で、はまだ早い。

使うとしたら、STTと応答の判断はLFM3-Omniに任せて、読み上げだけ日本語に強いTTSに差し替える 構成が現実的だと思いました。STTも、日本語特化のモデル(kotoba-whisper など)とはまだ比べていないので、次はそこを並べてみたいです。

なお、ライセンスは LFM Open License です。年商1,000万ドル未満の法人なら無償で商用利用できますが、それ以上は商用ライセンスが必要になります。業務で使う方は確認を。

おわりに

発表の翌日にすぐ手元で動いたのはありがたかったです。2Bという小ささのおかげで、6GBのGPUでも音声の入出力をひととおり試せました。日本語の発音さえ良くなれば、ローカルの受付AIがかなり現実的になりそうです。

LFM3-Omni の日本語TTSを、もっと上手く読ませるコツ(システムプロンプトやサンプリング設定など)をご存じの方がいたら、ぜひコメントで教えてください。

参考