Khalaは24GB VRAM前提のオープン音楽生成システム

Khala は、歌詞とテキスト条件からフル尺の曲を生成するオープンソース実装として出ている。
Web UI、FastAPIバックエンド、GPU推論ワーカー、Hugging Face上のモデル重みまで公開されていて、論文だけではなく動かすための一式がある。

ただ、手元のローカル音楽生成として扱うと、ACE-Step UI よりかなりGPUサーバー寄りだ。
READMEは24GB以上のNVIDIA GPUを推奨し、Docker + NVIDIA Container Toolkitを前提にしている。
Macや低VRAM GPUで粘る話ではなく、RTX 4090以上の箱で研究実装を回す話に近い。

出てくるのは「歌入り＋伴奏」が混ざった1本のオーディオ

「音楽生成」と一口に言っても、出力形態はモデルによって違う。

出力形態	内容
MIDI/シンボリック生成	ノート列を出力する。DAWに取り込んで楽器を差し替えたり、コードを編集したりできる
ステム分離生成	ボーカル・ドラム・ベース等のトラック別に出力する。あとから個別ミックスが可能
伴奏のみ生成	ボーカルなしのBGMだけを出力する
フル曲生成	ボーカル・伴奏・空間処理まで全部混ざった完成形の1本を出力する

Khalaは最後の「フル曲生成」型で、SunoやUdio、ACE-Stepと同じ系統だ。
出力はミックス済みのWAVとMP3が1本ずつ、と付随するJSONメタデータがセットで backend/generated_audio/ に出る。
ボーカル単独や伴奏単独のような分離トラックは出ない。MIDIでもないので、後からDAWで「ここのコード変えたい」のような編集はできない。

歌詞を入れたときの挙動も、この前提で読むと整理しやすい。
lyrics に渡した歌詞を、混ざった1本の中のボーカルパートがその通りに歌う、というのが目標仕様だ。
論文の主張も、純粋な音響トークン言語モデリングだけで歌詞→ボーカルの時間軸対応が出る、という話になっている。

ただし、一字一句完全に合うかは保証されない。
SunoやUdioでも歌詞ズレや発音崩れは普通に起きるし、Khalaは2026年5月7日の品質不安定告知（数値精度疑い）が消えていない段階なので、歌詞アラインメントを評価軸に置くのはまだ早い。

mode="instrumental" を選ぶと、ボーカルなしの伴奏側だけが出る。
このとき lyrics フィールドは無視され、伴奏として鳴らしたいキャラクターを tags または自然文 prompt で記述する形になる。
逆に mode="vocal" で lyrics を空にすると、ボーカルラインの根拠がない状態で生成が走るので、出力は安定しない。

長さは1〜10分の範囲に丸められる。
1リクエストごとにWAVとMP3が同じ音源の別エンコードとして書き出され、JSONには生成設定・使ったプロンプト類のメタデータが入る。

中身として混ざっているパート

「混ざった1本」と言っても何が混ざっているかは曲による。
タグカタログ（backend/tags.json のVocals/Instruments・Rhythm/Production系）と一般的なポップスのトラック構成を突き合わせると、Khalaの出力に含まれうる要素はだいたいこの並びになる。

パート	役割 / 該当タグの例
リードボーカル（主旋律）	歌詞を実際に歌う声。mode="vocal" のときに出る。Male Vocals / Female Vocals で性別寄せ
コーラス・ハモリ	Harmonized Vocals / Choir / Duet / Male and Female Vocals / Vocal Chops などのタグで足される
ドラム / パーカッション	Electronic Drums / Drum Machine / Driving Drums / Percussion / Four-on-the-floor
ベース	Synth Bass / 808 Bass / Sub-bass / Heavy Bass / Distorted Bass
主旋律楽器・伴奏楽器	Piano / Solo Piano / Electric Guitar / Distorted Guitar / Acoustic Guitar / Synth Lead / Brass / Cello / Guzheng
ハーモニー・パッド系	Synth Pads / Atmospheric Pads / Strings / Synth Strings / Synth Arpeggios
空間処理・ミックス	Reverb / Lush Reverb / Wide Stereo / Sidechain Compression / Vinyl Crackle / Tape Hiss

ここで気をつけたいのは、上の「パート」はあくまで人間が聴いて分けたときの分類で、Khalaの内部に独立したトラックがあるわけではない、という点だ。
モデルが出すのは64層RVQの音響トークン列で、その時点でボーカル・ドラム・ピアノ・パッドはすべて同じ信号の中に絡んだ状態で同時に決まる。
タグ Piano を渡す意味は「ピアノというトラックを追加する」ではなく「ピアノが鳴っているように聴こえる方向へ全体の信号生成を寄せる」になる。

ボーカルと伴奏の関係も同じで、信号レベルでは最初から一体だ。
よくある誤解として「伴奏トラックを作ってから、その上にボーカルを重ねる」というカラオケ/DAW的なフローを想像しがちだが、Khala（およびSuno・Udio系のフル曲生成）はそうなっていない。
最初の1ステップから声入りの波形をまとめて生成しているので、「先にBGMができていて、後から歌が乗る」という工程は存在しない。

歌詞→ボーカルの時間軸対応も、音響トークン言語モデリングの中で「歌っているように聴こえる位置にそういう音を置く」という形で発生する、というのが論文の立て付けだった。
ステム分離が原理的に難しく、部分修正の手段も限られるのは、この一体生成という構造から来ている。

気に入らない部分があっても、原則「再生成」しかない

混ざった1本のオーディオしか出ない、という出力形態は、運用面ではっきりした制約になる。

「Aメロは良いけどサビのボーカルだけ気に入らない」「歌詞の3行目だけ発音が崩れている」「ドラムだけ別パターンにしたい」のような部分修正は、Khalaの公式APIではできない。
POST /generate は曲を最初から生成するエンドポイントで、リクエストにinpaintや継続生成（特定区間の再合成、既存曲のextend）の口は含まれていない。
ボーカルだけ・伴奏だけのステムも取れないので、「伴奏は残してボーカルだけ差し替える」もできない。

手元で取れる選択肢はだいたい以下に限られる。

• 同じプロンプトで temperature や top_k_bb を変えて再生成（ガチャを回す）
• プロンプト・タグ・歌詞を書き換えて再生成
• 出力後にDAWで波形カット・EQ・タイムストレッチ・ピッチ補正など、波形レベルの後処理
• Demucs等のステム分離ツールで擬似的にボーカル/伴奏を分ける（音質劣化あり）

主軸は最初の二つ、つまり「気に入った1本が出るまで回す」というガチャ寄りのワークフローになる。
SunoやUdioも基本構造は同じで、「曲単位を確率で当てに行く」前提で組まれている。
ただし、ガチャだけで完成度を上げきれない場合に、外部のステム分離を挟んで部分編集に持ち込むルートが現実的な逃げ道として残る。

事後ステム分離で「擬似的に編集する」ルート

Khala自体に分離機能はないが、出力されたWAVを既存のステム分離ソフトに通せば、ある程度のパート別編集に持ち込める。
ボーカル差し替えや楽器のEQ調整など、DAW側の通常制作フローに乗せたい場合はこの経路を通ることになる。

代表的なツールは以下。

ツール	内容
Demucs（Meta、OSS）	4ステム分離（vocals / drums / bass / other）の定番。現状もっとも精度が高い部類
MDX-Net	後発の分離モデル。Demucsと並んで使われる
Spleeter（Deezer、OSS）	古参。2ステム / 4ステム / 5ステムから選べる
UVR（Ultimate Vocal Remover、OSS）	上のモデル群をGUIからまとめて使えるフロントエンド。WindowsならこれかGoogle Colab経由が一番楽

いずれも事後の推定処理であって、Khalaが内部に持っていた個別トラックを取り出しているわけではない。
ボーカル側に伴奏のにじみが残ったり、ドラム抜きにシンバルの余韻が残ったり、4ステム基準では other の中にピアノ・ギター・パッドが全部一緒に入ったままだったりする。
「ピアノだけ抜き出してリハモする」のような楽器単位の精密な分離は、現状の4ステム系では難しい。

実務的なワークフローはこうなる:

1. Khalaで曲を生成（ガチャ含む）
2. 出力WAVをDemucs / UVRに通して4ステム化
3. DAWに読み込んで、ボーカルだけ別テイクに差し替え、ドラムだけパターン変更、伴奏側だけEQやサイドチェイン処理、といった編集をかける
4. ミックスし直して書き出す

「ちゃんと演奏してる風」に聴こえるKhala出力ほど分離精度は出やすく、AI特有の歪みやアーティファクトが乗った出力ほど分離は荒れる傾向がある。
2026年5月7日の品質不安定告知が消えるまでは、この事後分離経由の編集ルートも読み筋が立てにくい。

フル曲生成系を制作フローに組み込むときは、Khalaをラフ案ジェネレータとして使い、Demucs等でステム化してからDAWで詰める形になる。最終素材ジェネレータとして単独で使い切るのは、現状の品質告知と非商用ライセンスの両方が残っている間は難しい。

64層RVQをそのまま生成対象にする

Khalaの中心は、64層のRVQ（Residual Vector Quantization）で音を離散トークン化し、その階層を粗い音楽構造から細かい音響成分まで使う設計だ。
論文では、構造と高音質化を別々の表現空間へ分けるのではなく、同じ深い音響トークン階層の中で段階的に扱う、と説明している。

処理は二段に分かれる。
Backboneがフル曲の粗い音響トークンを生成し、Super-resolutionモデルが残りの細かいRVQ層を埋める。
最後にDAC RVQデコーダーが波形へ戻す。

flowchart TD
    A[Prompt and lyrics] --> B[Backbone<br/>coarse acoustic tokens]
    B --> C[Super-resolution<br/>q0 to q63]
    C --> D[DAC RVQ decoder]
    D --> E[WAV and MP3]

ここでいうSuper-resolutionは画像の拡大ではなく、音響トークン階層の細かい層を補う処理だ。
arXivの要旨では、Super-resolution段がフル曲スケールで動き、時間方向は並列に処理しながら層を順に詰めるため、推論は固定62ステップになると書かれている。

セマンティックトークンなしで歌詞アラインメントを扱う

音声・音楽生成では、意味寄りのトークン（HuBERTやw2v-BERT系）と音質寄りのトークン（DACやEnCodec系）を分ける構成がよく出る。
意味側で「何を言っているか」を決め、音質側で「どう鳴るか」を組む二段構えにすると、テキストと発声の対応が取りやすい、という考え方だ。
Khalaはそこを分けず、純粋な音響トークン言語モデリングだけでテキストとボーカルの対応が出る、と主張している。

そのために、学習ではハイブリッドアテンションを使う。
Backboneの歌詞アラインメント側は因果アテンション（自己回帰の素直な並び）、Super-resolutionの層ごとのリファイン側は全アテンション（双方向）、という使い分けだ。
歌詞→ボーカルの時間順は壊さず、層方向のディテール補完は前後文脈を全部見て決める設計になる。

さらに、Super-resolutionモデルをランダム初期化ではなくBackboneチェックポイントから初期化すると、収束と最終品質の両方が改善したと論文に書かれている。
同じ音響トークン空間で動かす二段なので、粗い側で得た表現を細かい側の出発点に使える、という解釈になる。

推論側は固定62ステップ。
Super-resolution段は時間方向には並列、層方向（q0〜q63のRVQ階層）には順番に詰めるので、曲尺が伸びてもステップ数は変わらない。
逆に言えば、短いクリップでも62ステップ分のコストがかかるので、ループ用途のような短尺生成にはオーバーヘッドが大きい構成になる。

この設計は、ACE-Step V1.0の下調べ で扱ったFlow-matching系とは別系統だ。

項目	Khala	ACE-Step V1.0
生成方式	64層RVQの音響トークンLM	Flow-matching拡散
二段構成	Backbone → Super-resolution	単段
推論ステップ	固定62ステップ	拡散ステップ数で可変
推奨GPU	NVIDIA 24GB+	Mac/中位GPUでも動く
配布形態	Docker + FastAPI + Vite	デスクトップアプリ寄り
ライセンス	CC BY-NC 4.0（非商用）	Apache-2.0系

ACE-Stepはローカル実行の速さと制作系機能を前面に置く実装で、Khalaは音楽構造と音響ディテールを同じトークン階層で扱うアプローチを取る。

実装は研究者向けのサーバー構成

READMEは、現行リリースをGPUサーバーに慣れた研究者・開発者向けとしている。
プリビルドイメージは ghcr.io/davidliujiafeng/khala-env:ngc25.02-node24 で、docker run --gpus all でNGC PyTorchベースのコンテナに入る。
ホスト→コンテナのポートは 30869（フロントエンド）と 8889（API）の二つを開ける構成だ。

システムは三層に分かれている。
フロントエンドはVite + Reactでプロンプト・歌詞・生成設定を受け取る。
API dispatcher（backend_api.py）がリクエストをジョブ化してキューに積み、空いている推論ワーカーへ振り分ける。
推論ワーカー（backend_worker.py）が1GPUあたり1プロセスで動き、トークナイザー、Megatron Backbone、Super-resolution、デコーダーを順に通して音を作る。

flowchart TD
    A[Frontend UI] --> B[backend_api.py]
    B --> C[backend_worker.py]
    C --> D[Backbone]
    D --> E[Super-resolution]
    E --> F[Decoder]
    F --> G[generated_audio/]
    G --> B
    B --> A

run_backend.sh は、2026年5月11日の更新で単一GPUでも起動しやすい安全側のデフォルトになった。
GPU選択は --gpus 0（単一GPU）、--gpus 0,1 や --gpus 6,7（複数GPU）のように渡し、IDの数だけワーカーが立つ。
ランタイムモードは --runtime-mode one_shot と --runtime-mode keep_loaded を切り替える。

one_shot はリクエストごとに一部モデルを解放するので、24GB級のシングルGPUで詰まりにくい安全側。
keep_loaded は重みをVRAM上に保持したまま回すので、推論バーストが多い高メモリ環境向き。
スループット重視か、VRAM圧迫を避ける側か、で選び分ける形になる。

ポートは run_backend.sh 内の API_PORT、WORKER_BASE_PORT、BASE_MASTER_PORT で変えられる。
API_PORT はフロントエンドからの口、WORKER_BASE_PORT は各ワーカーのバインド先、BASE_MASTER_PORT はMegatronの分散初期化に使う。
複数ワーカーを立てるときに既存サービスとぶつかったらこの3つを順にずらす。

ログは backend/logs/api.log と backend/logs/worker_0.log（ワーカーIDごと）に分かれる。
APIログでジョブのキュー・dispatchを追い、ワーカーログでBackbone→Super-resolution→デコーダーのどこで止まったかを見る。
生成物は backend/generated_audio/ 配下に .wav、.mp3、.json のメタデータがセットで出る。

何を放り込むと曲が出るのか

UI（または POST /generate）に渡すのは8フィールド。
backend_api.py の GenerateRequest がそのまま受ける形だ。

フィールド	型 / デフォルト	説明
mode	"vocal" / "instrumental"	ボーカル入り or インスト
prompt_mode	"tags" / "natural"	タグで指定するか、自然文で指定するか
prompt	文字列	prompt_mode="natural" のときに使う自由記述
tags	文字列（カンマ区切り）	prompt_mode="tags" のときに使うタグ列
lyrics	文字列	歌詞。mode="vocal" のときだけ使われる
duration	int, デフォルト 3	曲尺（分）。1〜10 の範囲に丸められる
top_k_bb	int, デフォルト 80	Backboneのtop-kサンプリング
temperature	float, デフォルト 1.0	Backboneのサンプリング温度

タグカタログは GET /tags（backend/tags.json）で取れる。
4カテゴリに分かれていて、UIではカテゴリ別チップとして並ぶ。

カテゴリ	タグ例
Genre/Style	J-Pop / Lo-fi / Cinematic / EDM / Hip-hop / Synthwave / Ballad / Anime
Vocals/Instruments	Male Vocals / Female Vocals / Piano / Synth Bass / Distorted Guitar / Strings / 808 Bass / Instrumental
Emotion/Mood	Melancholic / Nostalgic / Uplifting / Atmospheric / Anthemic / Dreamy
Rhythm/Production	Slow Tempo / 128 BPM / Reverb / Wide Stereo / Lo-fi Hiss / Sidechain Compression

歌詞は内部で clean_lyrics() を通る。
日本語・中国語の全角句読点（、 。 ？ 「」 （） 等）と全角英数字をASCIIへ自動変換するだけのシンプルな前処理で、構造タグ（[Verse] [Chorus] 等）を要求するような厳格なフォーマットは課されていない。
原文をそのまま貼って渡せる前提になっている。

タグモードの最小例

curl -X POST http://127.0.0.1:8889/generate \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "vocal",
    "prompt_mode": "tags",
    "tags": "J-Pop, Female Vocals, Piano, Melancholic, Slow Tempo",
    "lyrics": "夜風が窓を叩く\n眠れないまま朝を待つ",
    "duration": 3,
    "top_k_bb": 80,
    "temperature": 1.0
  }'

レスポンスは job_id を返し、進捗は GET /job/{job_id}、音は GET /job/{job_id}/track/0/mp3（または /wav）で取れる。

自然文モードの最小例

curl -X POST http://127.0.0.1:8889/generate \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "instrumental",
    "prompt_mode": "natural",
    "prompt": "A dreamy lo-fi hip-hop instrumental with vinyl crackle, warm piano chords, and a slow boom-bap beat around 80 BPM.",
    "duration": 2,
    "top_k_bb": 80,
    "temperature": 1.0
  }'

mode="instrumental" のとき lyrics は無視される。
逆に mode="vocal" で lyrics を空にすると、ボーカルラインの根拠がない状態で生成が走るので、出力は安定しない。

ジョブ進行とフェーズ

ワーカーは内部状態を backbone → superres → decoding → idle の順に進める。
GET /job/{job_id} のレスポンスにこのフェーズが入るので、UIや別ツールで「今どこを処理中か」が表示できる。
処理が長く感じても、worker_0.log でフェーズが進んでいれば動いている。止まっているのは大抵 backbone の初回ロードか、CUDA OOMのどちらかになる。

重みは約52GBで、ライセンスは非商用

Hugging FaceのAPIで確認すると、liujiafeng/Khala-MusicGeneration-v1.0 の使用ストレージは約52GBだった。
中身はBackbone、Super-resolution、DAC RVQデコーダーのチェックポイントに分かれている。
READMEの手順では、リポジトリ直下に checkpoints/ を作って hf download liujiafeng/Khala-MusicGeneration-v1.0 --local-dir checkpoints で落とす。

モデルカードのライセンスは cc-by-nc-4.0。
GitHub READMEでも、モデル重みはCreative Commons Attribution-NonCommercial 4.0 Internationalとして公開予定、と書かれている。
商用の制作素材として扱う前提なら、この時点では使えない。

コード側のGitHubリポジトリは2026年5月17日時点で113 stars、9 forks、リリースは未作成。
24時間で30 starほど伸びていて、5月16日のデモページ公開のタイミングと重なっている。
Hugging Face側のモデルカードはlikes 13、downloads 0として返ってきた。
数字だけで品質は決まらないが、普段使いのツールとして成熟している段階ではない。

2026年5月7日の品質不安定告知が残っている

READMEのNewsには、2026年5月7日付で推論品質に大きく影響する可能性のある問題を調査中で、数値精度との関連を疑っている、という警告が残っている。
2026年5月16日にはオンライン音声デモが公開されたが、この警告はまだ消えていない。

この状態だと、同じプロンプトでも実行モードや環境で品質がぶれたときに、それがモデル設計の問題なのか数値精度起因なのかを切り分けられない。
当面の検証対象は音質評価より、環境構築、メモリ使用量、ワーカー分離、ジョブ処理、重み配置あたりが主軸になる。

手元で触るなら4090以上のDocker環境から

手元で動かすなら、RTX 4090 / A5000 / A6000 / L40S / A100 あたりのCUDA環境を用意して、まずはDockerでREADME通りに動かす。
24GB VRAM・約52GBの重み・NGC PyTorchコンテナのセットなので、M1 MaxやRTX 4060 Laptopでは推奨条件を割る。

最初の検証では音質評価よりも、backend/logs/api.log と backend/logs/worker_0.log を眺めながら、1曲分のWAVとMP3が backend/generated_audio/ に書き出されるところまで通すのが先になる。
非商用ライセンス（CC BY-NC 4.0）と2026年5月7日の品質不安定告知が両方残っている間は、出力を商用素材に転用する経路も塞がっている。

参考

• Khala GitHub README
• Khala: Scaling Acoustic Token Language Models Toward High-Fidelity Music Generation
• Khala model weights on Hugging Face
• backend/README_backend.md
• ENVIRONMENT_SETUP.md