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