HeartMuLa-oss-3BのMPS環境で確認したAR LMのbf16による条件付け破綻
今回やったこと
Apache 2.0ライセンスの音楽生成基盤モデル HeartMuLa-oss-3B を、heartlibのcloneとPython 3.12の仮想環境でローカル導入した。Apple SiliconのMPSで生成を確認し、音が出るところまで動かしたうえで、条件付けが正しく効いているかをCPU fp32と比較した。
この比較で重要だったのは、bf16の自己回帰言語モデル（AR LM）がエラーを出さずに壊れることだった。処理が停止するなら原因を追いやすいが、音声ファイルが生成されるため、最初はモデル品質やプロンプトの問題に見える。
音は出るのに条件付けが崩れる
MPS上でAR LMをbf16にすると、日本語歌詞が別言語のようになり、タグが無視され、指定していないインストゥルメンタル寄りの出力になる現象が出た。90秒を指定しても3〜21秒で早期EOS終了するケースがあり、cfgを上げるとコーラス風に崩れることもあった。
これらは単発で発生した場合、プロンプトの相性やサンプリング時の乱数の偏りとして片付けられる。しかしCPU fp32を比較対象にし、精度だけをfp16へ変更すると、今回検証した範囲では症状が正常化した。DiT（拡散トランスフォーマー）ではbf16で問題ない処理でも、今回のMPS上のAR LMでは数値精度の影響がトークン選択に直結した。エラーが出ないことは、条件付けが正しく機能している証拠にならない。
MPS + bf16 AR LM
↓
エラーなし・音は出る
↓
歌詞 / タグ / 長さが崩れる
↓ 精度をfp16へ変更
条件付けが正常化
導入時に必要だったもの
チェックポイントは新版（HeartCodec更新版）と初代版があり、それぞれ21GB、合計42GBだった。MPSで動かすにはcodec側の .type() 呼び出しを置き換えるパッチの適用も必要になる。モデル本体だけを取得して終わりではなく、codec側のMPS互換性とディスク容量を先に確認する必要がある。
性能はRTFがおよそ2.0（90秒の曲を3分弱）〜3.2（20秒の曲を64秒）だった。ここでのRTFは生成時間と音声長の比率として扱い、モデルの品質を表す指標とは分けて考える。速度が出ても、歌詞や構造タグが崩れていれば実用上の成功とは言えない。
安定した指定と避けるべき設定
タグは japanese,j-pop,pop,female vocal のように簡素にし、歌詞側は [Intro][Verse][Prechorus][Chorus][Outro] の構造タグで制御すると安定した。条件を増やせば細かく制御できるとは限らず、まず言語・ジャンル・ボーカルと曲構造を分けて確認する方が、どこで崩れたかを追跡しやすい。
精度はAR LMをfp16にする。DiTまで同じ精度へ落とすという意味ではない。コンポーネントごとに数値精度への感度が違うため、全体へ一括適用する設定は避け、どのモジュールがトークン選択を担っているかを確認してから変更する。
実装ステータスと再現時の注意
ローカル導入とMPSでの検証は完了している。ただし、チェックポイントの構成、PyTorch、macOS、MPSの組み合わせが変われば再測定が必要である。再現時はまずCPU fp32などの基準出力を一つ保存し、音が出るかではなく、歌詞・タグ・長さ・構造が維持されるかを比較する。こうした静かな破綻を見逃さないためには、生成成功という一つの判定だけでなく、条件付けごとの検査を用意することが重要になる。
更新履歴
- 2026-09-08: 初稿。HeartMuLaのローカル導入、MPS bf16の症状、fp16での切り分けを整理。