はじめに

2025年9月、清華大学とByteDanceが公開した HuMo は、参照画像・音声・テキストを統合して 人間らしい短尺動画を生成できるマルチモーダルAI です。

従来の「トーキングヘッド」系（Wav2Lip, SadTalker, VASA-1など）が主に口パクや表情同期にとどまっていたのに対し、HuMo は ID保持（見た目の一貫性）＋音声同期＋背景や衣装の演出 を 単一の推論で同時に扱える のが大きな特徴。

公開直後から 17B（高画質・720p対応） と 1.7B（軽量・480p対応） の2モデルが提供され、ComfyUI統合やCLI実装も整備されています。 短尺（約4秒）の制約はあるものの、リップシンク精度・演出の自由度・オープンな公開方針（Apache 2.0ライセンス）により、次世代の人間中心動画生成モデルとして注目を集めています。

GitHub - Phantom-video/HuMo: HuMo: Human-Centric Video Generation via Collaborative Multi-Modal Conditioning

HuMo: Human-Centric Video Generation via Collaborative Multi-Modal Conditioning - Phantom-video/HuMo

https://github.com/Phantom-video/HuMo

ひとめで分かる HuMo

技術詳細（Technical Deep Dive）

性能と仕様・実績

運用・制限点（What’s Hard / Where It Falters）

• 動画の長さ制限：97 フレーム（約 3.9秒）を超える生成は訓練時の位置エンベディングなどの設計上、クオリティが劣化する。長尺版チェックポイントはまだ一部未公開。(GitHub)
• VRAM要求が大きい：17B + 720p の組み合わせでは GPU メモリが相当必要。1.7B の方が軽量だけど、ここでも 32GB 程度メモリが必要という報告がある。 (GitHub)
• モダリティのバランス調整が必要：テキスト・画像・音声のどれを強めるかは、実験で scale パラメータを触らないと狙い通りにならない。誤った設定だと subject の見た目が崩れたり、テキスト内容が薄まったり、リップ同期が甘くなったりする。 (高效码农)
• デモでの限界：背景や動作の複雑さ、手の動きや細かい身体運動などはまだ完璧ではない。上半身〜表情／口動き中心。全身、複雑アクションはまだ試されていないか、性能が揃っていない可能性。これは他モデルと比べても共通のハードル。
• 倫理・悪用リスク：著作権・肖像権／フェイク動画の問題。論文にも注意事項として記載あり。 (arXiv)

応用可能性・ユースケース & 注意すべき点

応用可能性：

• プレゼン／チュートリアル映像：話す人の顔＋テキスト指示で説明動画を作る。発話とリップ同期がそれなりに取れるので、ナレーション＋表情あり動画が簡単に作れる。
• SNSコンテンツ／短尺動画：3〜4秒のクリップなら、参照画像でキャラクター見た目を固定して、テキストで演出を加えて音声で話すシーンを作成。特にスタイリング重視な宣伝・商品レビュー。
• キャラクター紹介・デモ映像・プロトタイプ：ゲームやアバター、キャラの見た目テストなどにも有効。あるいは教育素材で、キャラクターが話す形式。

注意すべき点：

• 長尺動画を常時使いたいなら、あとから出る長尺版チェックポイントを待つか、自分で拡張する工夫が必要。
• リファレンス画像やテキストが不十分だと、subject preservation が弱くなる。参照画像は角度・表情など複数枚あると安定しやすい。
• 音声の質／ノイズ：バックグラウンドノイズやラップトップ／近接マイクによる音質低下が同期精度に影響する可能性がある。音声前処理（ノイズ除去・正規化）が有効。
• モデル出力には「AI生成」であることの明示・倫理対応をすること。公開用途なら特に。

技術のキモ（なにが新しい？）

最小侵襲の画像注入（minimal-invasive image injection）

要点：既存のT2Vの“プロンプト追従力”を壊さずに、参照画像から人物ID（顔つき・髪・衣装）の一貫性を注入する戦略。 なぜ効く：画像由来の潜在表現を時間次元に軽量に結合し、DiTの更新を最小限に抑えることで、テキスト追従と画生成の既存能力を保持したままID保持だけを強化できる。 実装の勘どころ：注入は“軽く・局所的”に。大規模な再学習や重いAdapterを避け、subject preservationを独立タスクとして先に学習してから多モーダル統合へ段階的に進めるのが肝。 (arXiv)

音声→顔領域の“予測でフォーカス”（focus-by-predicting）

要点：単なる音声 cross-attention では粗い同期になりがち。そこで顔領域を予測するマスク予測器を導入し、リップシンクと表情の同期を強化。 なぜ効く：モデルに**“音声と画面内のどこが対応するか”を暗黙に学習させ、口元・頬・眉などの顔まわりの動きに注意が向く。これで口形と音素の一致や表情のタイミングが安定する。 実装の勘どころ：全フレームで顔検出に依存せず、latent上でのマスク予測を損失に組み込む。音声は専用の cross-attention レイヤで各DiTブロックに供給しつつ、この予測フォーカスで同期の粒度**を上げる。 (arXiv)

時間適応型CFG（time-adaptive Classifier-Free Guidance）

要点：拡散の各デノイズ段階でテキスト/画像/音声の重みを可変にして、生成の進行に合わせてどのモダリティを強めるかを最適化。 なぜ効く：初期ステップはレイアウト・スタイル形成のためテキスト＋参照画像寄り、後段は音声同期（口形・表情）に比重を移すと、ID保持・内容整合・リップシンクの三立がしやすい。 実装の勘どころ：固定スケールのCFGよりも段階的スケジューリングが鍵。論文は“モダリティ別ガイダンス強度の時間変化”を設計指針として提示（近年のTA-CFG系の流れにも整合）。 (arXiv)

データ側の工夫（Text × Image × Audio のトリプレット）

要点：テキスト・参照画像・音声が揃ったペアデータを高品質で構築。 なぜ効く：マルチモーダル統合のボトルネックは学習データの欠落。トリプレットでsubject preservation（見た目一貫）とaudio-visual sync（音声同期）を段階学習でき、共同制御（collaborative conditioning）が安定。 実装の勘どころ：二段階の進行的学習（先にID保持、後から音声同期を追加）。既に獲得した能力を土台に徐々にタスクを協調させるカリキュラムが推奨。 (arXiv)

実用メモ（生成長・解像度・所要）

生成長（フレーム数・秒数）

• 訓練の標準長：97フレーム / 25FPS ≒ 3.9秒。HuMo のベースモデルはこの範囲で学習されているため、これを超えると時間的整合性が落ちやすい。
• 長尺対応：公式は「Long-form checkpoint（10月公開予定）」をアナウンスしており、より長いクリップ生成に対応する計画がある。現状は短尺クリップを複数つなげるか、他のVid2Vid系ツールでリファインするのが現実解。

解像度

• 17Bモデル：フルで動かすと720p生成が安定。人物の顔や衣装の精細さもここで発揮される。
• 1.7Bモデル：軽量版だが、実質480p生成が現実的。解像度を上げると破綻しやすい。

所要時間（ユーザー実測報告）

• 1.7B：32GB GPU環境で 480p・97f を約8分で生成。720pでは時間・VRAMともに厳しい。
• 17B：公式は720p推奨。ただし必要VRAMが大きく、クラスタ環境やオフロード前提。RTX3090（24GB）での動作報告もあるが、実運用はギリギリ。

VRAM要求と実用レンジ

• 1.7B：実験ベースで32GB級GPUが推奨。480pならシングルGPUで現実的。
• 17B：フル機能（720p）は80GB級GPUまたは分散環境を前提。個人環境では 3090/4090 (24GB) で動いた例はあるが、安定性に限界。
• 対処法：ComfyUI 版では fp8 や FSDP（分散）、フレーム短縮（64f前後）、解像度落とし込みで現実的に動かす工夫が共有されている。

まとめると：

• **短尺（4秒）・480p → 1.7B（32GB級GPU）**で実用ライン。
• **高精細（720p） → 17B（大型GPU or クラスタ）**で映像クオリティを追う。
• 長尺動画は現状未対応、10月リリース予定のロング版CKPTを待つか、分割生成→編集で対応。

どうやって動かす？（2通り）

A) ComfyUI 派（GUIで楽に試す）

1. ノード導入

   • custom_nodes に ComfyUI-WanVideoWrapper を追加インストール。
   • 2025-09-17 以降の更新で、HuMo 専用ノードがフォルダごと用意済み。

2. モデル読み込み

   • 17B版：Wan 系統の VAE / エンコーダ（Wan2.1 互換）を併用して HuMo 重みをロード。

     • RTX3090 (24GB) 単機で動かした報告がある（ただし解像度・フレーム数を落とす必要あり）。

   • 1.7B版：ComfyUI 本体に正式統合（2025-09-17）。32GB GPUで 480p / 97f が実用ライン。

3. ワークフローの基本

   • 入力は テキスト + 音声 + 参照画像（複数可）。

   • モードは：

     • TA = Text + Audio
     • TIA = Text + Image + Audio

   • 調整する主要パラメータ：

     • frames：64～97（既定）
     • resolution：1.7Bなら 480p、17Bなら 720pも可能
     • scale_a：音声ガイド強度（リップシンク重視なら 1.2–1.6）
     • scale_t：テキストガイド強度（演出・背景重視なら 0.8–1.2）

👉 GUI派に向いてる点は「ワークフローに画像・音声・テキストをドラッグ＆ドロップするだけで統合できる」ところ。複数画像を束ねてキャラの安定度を上げられるのも便利。

B) CLI 派（素のリポジトリで直接動かす）

1. リポジトリ取得

   git clone https://github.com/Phantom-video/HuMo.git
   cd HuMo
   pip install -r requirements.txt
   

2. モデル取得

   • Hugging Face の bytedance-research/HuMo から以下をダウンロード：

     • HuMo-17B または HuMo-1.7B
     • Wan2.1 関連（VAE, テキストエンコーダ）
     • Whisper （音声処理用）

3. 設定ファイル編集

   • configs/generation/generate.yaml を編集して入力を指定。例：

     generation:
       mode: "TIA"
       frames: 80
       height: 480
       width: 832
       scale_a: 1.4
       scale_t: 1.0
       reference_images: ["ref1.png", "ref2.png"]
       audio_path: "voice.wav"
       prompt: "a young woman speaking cheerfully in a cafe"
     

4. 推論実行

   • Text + Audio の場合：

     bash scripts/infer_ta.sh
     

   • Text + Image + Audio の場合：

     bash scripts/infer_tia.sh
     

   出力は ./outputs に mp4 として保存される。

補足：両方式の向き不向き

ComfyUI派（GUIベース）

• メリット

  • 直感的操作：ノードを繋げるだけで、画像＋音声＋テキストを組み合わせ可能。パラメータもスライダーで調整できる。
  • 統合性：既存の LoRA・VAE・アップスケーラ（ESRGAN, RealESRGAN, Video2Videoノードなど） と自然に接続可能。HuMoの出力をすぐ強化できる。
  • コミュニティワークフロー：公開されている JSON ワークフローを読み込めば、そのまま再現可能。初学者でも試しやすい。
  • マルチ入力の柔軟さ：参照画像を複数ドラッグして束ねられる → ID保持が安定。

• デメリット

  • 細かい制御はやや不向き：学習時のロジックや低レベルのパラメータまでは直接触れない。
  • 再現性の担保が難しい：GUIでの設定保存はできるが、環境差やノード更新で結果が変わることがある。

👉 向いてる層：クリエイター・映像制作寄りのユーザー。プロトタイピングや日常的な短尺生成。

CLI派（スクリプトベース）

• メリット

  • 精密制御：generate.yaml でフレーム数・CFGスケジュール・マルチGPU分散などを細かく指定可能。
  • 自動化・大量生成：シェルスクリプトやPythonから呼び出してバッチ処理可能。研究検証やデータセット生成に向く。
  • 安定した再現性：YAMLとシードを固定すれば、ComfyUIより環境依存が少なく、結果の再現がしやすい。
  • 研究用途に適合：論文の ablation 実験やベンチマークに必要な低レベルパラメータまで直接操作できる。

• デメリット

  • セットアップ負荷が高い：HuggingFaceから複数モデルを手動で取得、依存関係も自分で解決する必要がある。
  • 視覚的なワークフローなし：パラメータ調整がテキストベース。試行錯誤のスピードはGUIより落ちやすい。

👉 向いてる層：研究者・エンジニア。長期的にHuMoを解析したり、ベンチマーク環境を整備したい人。

結論

• 「映像を作る」目的なら ComfyUI派：LoRA・アップスケーラと組み合わせてクリエイティブに遊ぶ。
• 「モデルを解析・検証する」目的なら CLI派：実験条件の固定・バッチ処理・パイプライン化に強い。

VRAMとマシン事情（lain向けの現実解）

• 4070 Ti（12GB）単機では 1.7B でも厳しい。作者カードルールが32GB目安なので、ローカルなら

  • 解像度を 480p 固定、フレームを 64–80程度に短縮
  • 低メモリ最適化（fp8/シーケンス並列/FSDP）を活用
  • それでも足りなければクラウド or ComfyUIのオフロード手を検討 という順で。“3090で17B”の報告はあるが、安定運用はハードル高め。(GitHub)

既存モデルとの違い

• Wav2Lip（2020, ACM MM） 単一画像（or 既存動画）＋音声から口パク同期を最優先で合成する古典的代表格。被写体のID一貫性は高めだが、衣装・背景・演出の制御は基本持たない＝“話す顔”特化。高速・実装も豊富だが、シーン構成やスタイルの作り込みは不得手。 (arXiv)

• SadTalker（CVPR 2023） 音声→3DMMモーション係数（表情・頭部姿勢）を推定し、3D意識的レンダで表情とヘッドポーズを強化した“トーキングヘッド”路線。依然として顔中心で、衣装・背景・小道具の指示までは射程外。長さは音声に応じて伸ばしやすいが、演出面の自由度は限定的。 (SadTalker)

• EMO（ECCV 2024） 1枚の参照画像＋音声で、表情の豊かさ（emote）とアイデンティティ保持を両立するAudio→Video拡散の直結型。中間3D表現に依存しないのが強みだが、基本はポートレート動画生成で、背景や衣装のテキスト駆動の演出制御は薄い。 (arXiv)

• VASA-1（Microsoft, 2024） 1枚画像＋音声から高品質かつリアルタイム級の“話す顔”を生成。リップ同期と表情ニュアンス、自然な頭部運動が強み。こちらも顔中心で、**舞台作り（背景・衣装・小物）**をプロンプトで作り替える設計ではない。 (arXiv)

• HuMo（2025, 清華×ByteDance） 参照画像＋音声＋テキストを同一の推論内で協調させる“人間中心の統合T2V”。

  • ID保持：minimal-invasive image injection で、基盤T2Vのプロンプト追従を壊さずに見た目（顔・髪・衣装）を固定。
  • 音声同期：通常のAudio Cross-Attentionに加えて、顔領域を予測してフォーカスする focus-by-predicting を導入し、リップ・表情の安定度を向上。
  • 演出（背景・小道具・衣装変更）：テキスト条件を並走させ、背景やスタイリングも同時制御。
  • 整合を保つ工夫：時間適応型CFG（Time-Adaptive CFG）で、拡散過程の段階ごとにテキスト／画像／音声の効きを可変にして、ID・内容・同期の三立ちを図る。 ＝要するに「話す顔」に閉じず、見た目＋台詞（音声）＋演出を一本の生成で同時に面倒見る設計思想。既存“トーキングヘッド”系より制作志向（人物ショート映像の総合演出）に寄っている。 (arXiv)

まとめ（使い分けの指針）

• “とにかく口パクを素早く”：Wav2Lip／SadTalker／VASA-1／EMO（用途＝顔の語り、歌ってみた等）。背景や衣装を作り替える余地は小さい。 (arXiv)
• “IDを保ったまま、背景や衣装もテキストで演出して短尺を作る”：HuMo。**画像×音声×テキストの“協調制御”**を中核に据えた設計で、一発の推論で人物＋演出まで通すのが他と決定的に違う。 (arXiv)

具体的なパラメータのコツ

• generation.frames：64–97（まずは 80） 学習は 97f / 25fps ≒ 3.9秒 前提。これを超えると品質が落ちやすいので、検証は 64–80f、仕上げで 97f に伸ばすのが安定。ロング版CKPTは“今後提供予定”。 (Hugging Face)

• generation.height/width：まずは 480p（例 832×480）→ 余力があれば 720p 1.7B は 480p 運用が現実的。17B は 720p も射程だが VRAM 依存が大きい。まず 480p・短尺で挙動を掴んでから 720p を試す。 (Hugging Face)

• generation.mode：TA → TIA の順 まず TA（Text+Audio） でリップシンクと表情同期の素性確認→ 問題なければ TIA（Text+Image+Audio） に切替えて ID保持 を追加。モードは公式ページ/READMEの基本導線。 (ファントムビデオ)

• generation.scale_a（音声ガイド）：1.2–1.6 値を上げるほど音声→口形/表情の同期を強化。過剰に上げるとテキスト演出（背景・小物）が弱まるので 1.4 前後から微調整。パラメータの役割は README に明記。 (Hugging Face)

• generation.scale_t（テキストガイド）：0.8–1.2 値を上げるほどテキスト追従（背景・衣装・小道具）が強まる。scale_a とのトレードオフなので、scale_a を決めてから scale_t を合わせるのがコツ。 (Hugging Face)

• dit.sp_size（Sequence Parallel/FSDP 用のスライス数） マルチGPU推論を使うときに設定。単機なら既定のまま、2GPU 以上なら GPU 数に応じて増やす。FSDP+シーケンス並列の対応はモデルカードに明記。 (Hugging Face)

まず失敗しない最小セット（1.7B / 480p / 80f）

generation:
  mode: "TA"            # まず音声同期の素性確認
  frames: 80            # 64〜80で安定確認→最終97へ
  height: 480
  width: 832
  scale_a: 1.4          # リップ/表情同期を優先
  scale_t: 1.0          # 演出は控えめに様子見
  prompt: "a friendly person speaking in a cozy room"
  audio_path: "voice.wav"
# TIAに移行する場合は reference_images を追加:
#  reference_images: ["ref_front.png", "ref_45deg.png"]

この設計は 学習長97f・短尺優先・音声同期重視という HuMo の想定に合わせた“外さない型”。 (Hugging Face)

仕上げ（TIA / 97f / 720p を狙う流れ）

1. TA で同期OKを確認 → 2) TIA で参照画像2–4枚（正面＋斜め） → 3) frames=97 に伸ばす → 4) 余力があれば 720p → 5) 画/演出が弱いと感じたら scale_t を 1.1–1.2 に、小道具・背景の指示もテキストに具体化。 (ファントムビデオ)

マルチGPU・低VRAMのヒント

• 単機運用（<=24GB）：480p / 64–80f、TA→TIAの順。
• 複数GPU：FSDP + Sequence Parallel を有効化し、dit.sp_size を GPU 数に合わせる。長さ・解像度を少しずつ上げる。 (Hugging Face)

よくある崩れ方とリカバリ

• 口形が甘い：scale_a を +0.1〜0.2、BGMのないクリーン音声にする（正規化推奨）。 (Hugging Face)
• 見た目が揺らぐ：TIAで参照画像の枚数を増やす（正面＋斜め＋表情違い）。frames を一旦 64–80 に戻す。 (ファントムビデオ)
• 演出が弱い/背景が出ない：scale_t を 1.1–1.2 に上げ、テキストを具体化（背景、照明、小道具、衣装の質感まで明示）。 (Hugging Face)

注意点・既知の制約

• クリップ長は現状 ≒4秒で頭打ち 学習は 97フレーム＠25FPS（≒3.9秒） 前提。97fを超えると品質が落ちやすい旨が公式READMEに明記。長尺用チェックポイント（HuMo-Longer）は10月に公開予定とあるので、現時点では短尺を複数作って連結、またはVid2Vid系でアップスケール／リファインが現実解。 (GitHub)

• 1.7Bは“速い・軽い・同期は強い”が、画質では17Bに劣る 1.7Bは32GB GPUで480p・97fを約8分が目安。画質は17Bに劣るが、音声同期（lip/表情）はほぼ劣化しないとモデルカードが明示。したがって下書き（1.7B/480p）→最終だけ17B/720pという二段運用がコスパ良。 (Hugging Face)

• VRAM要求と実行環境の現実 17Bで720pは画質◎だが重い。READMEはHuMo-17B（480p/720p対応）＋Multi-GPU（FSDP＋Sequence Parallel）を想定し、RTX3090（24GB）で動かした報告パスはComfyUI-Wan統合経由で案内。ただし安定運用には解像度・フレーム数の調整が必須。個人環境なら1.7B/480p/64–80fから入るのが堅い。 (GitHub)

• ベストプラクティスとデータ詳細は“近日公開” 公式は**“Best-Practice Guide soon”**の告知に加え、トレーニングデータやロング生成用CKPTの提供予定をTODOとして掲示。運用TIP（scale_a/scale_t/frames/mode など）はREADMEのサンプル構成を拠り所にし、プロジェクト更新を追うのが前提。 (GitHub)

• 設計上のフォーカス範囲 目標は**“人間中心”の短尺映像**。上半身・表情・口形同期は強いが、全身の複雑アクションや長時間の一貫表現はまだ守備範囲外。長尺は後述CKPT待ち or 連結編集で補うのが無難。 (GitHub)

公式＆実装リンク（信頼できる順）

• Project ページ（Phantom-Video / HuMo） 公開日：2025-09-09。デモ動画、概要、リリースノート、今後の更新計画をまとめたトップページ。**「ロング版CKPT予定」「Best-Practice soon」**といったアナウンスもここで最初に出る。研究紹介＋一般ユーザー向けの窓口。

• arXiv 論文（HuMo: Human-Centric Video Generation via Collaborative Multi-Modal Conditioning） 提出日：2025-09-10。HuMoの中核技術を解説：

  • minimal-invasive image injection
  • focus-by-predicting
  • time-adaptive CFG
  • Progressive multimodal training paradigm 手法の根拠とアブレーション結果を確認できる一次情報源。理論や設計思想を理解したい人向け。

• GitHub（公式：Phantom-video/HuMo） 推論コード、generate.yaml 設定、スクリプト (scripts/infer_ta.sh など) を提供。 ニュース欄には 1.7B/17B公開日、ComfyUI対応（2025-09-17） などの更新ログあり。研究者・開発者向けに必須。CLI派はここが主軸。

• Hugging Face（bytedance-research/HuMo） 17B / 1.7B のモデル重み公開。Quick Start コード、推論例（480p/97f）、推奨VRAM目安などが整理。 → CLIで動かす場合は必ずここから ckpt を取得する。ComfyUI利用者も HuggingFace 経由でモデルパスを指定するのが標準。

• ComfyUI-Wan 統合（kijai） HuMo用のノードセットを ComfyUI の custom_nodes に追加可能。HuMoタブ付きワークフロー、Wan 系統（VAE, Encoder）との互換設定も同梱。GUI派はこの導入が一番手軽。3090（24GB）での実行報告も出ている。

👉 まとめると：

• 読むなら arXiv（理論）
• 試すなら GitHub + HuggingFace（実装＆重み）
• GUIで触るなら ComfyUI-Wan（ノード）
• 最新アナウンス追うなら Project ページ

最短で“自分の素材”を動かすワークフロー（提案）

1. 音声を先に磨く

   • HuMoは音声同期が要。BGM入りや環境ノイズは同期精度を落とす。
   • 推奨：ボーカル分離（Demucs等）→ノーマライズでクリーン化。
   • 公式model cardにも「音声前処理を推奨」と明記。

2. TAモードで下見（Text+Audio）

   • 参照画像なしでリップシンクと表情の出方をまず検証。
   • 設定例：frames=80, resolution=480p (832×480), scale_a=1.4。
   • ここで“口形・音声一致”が確認できれば、参照画像導入に進める。

3. TIAモードでID固定（Text+Image+Audio）

   • 参照画像を2–4枚投入（正面＋斜め、表情違いもあると安定）。
   • 衣装・小道具・背景はテキストで演出。HuMoはテキスト演出が同時効く設計。
   • ここでID保持＋演出＋音声同期を一発で検証できる。

4. 最終だけ重いモデル（HuMo-17B / 720p）

   • 同じ seed とパラメータで、**ドラフト（1.7B/480p）をフィニッシュ（17B/720p）**に差し替え。
   • こうすることで音声同期は軽量モデルで確認 → 高画質出力は大型モデルという二段運用が可能。コストと時間を大幅節約。

補足Tips

• seed固定：1.7Bで確認したシーン構図を17Bで高精細化できる。
• scaleバランス：同期が弱ければ scale_a↑、演出が弱ければ scale_t↑。
• 長さは80f前後でテスト → 問題なければ97f（フル）で本番。

関連リンク

Humoモデルがネイティブ対応しているという話｜shiba*2

＜注＞ 個人的な実験の要素もあり、記事が中途半端な内容でアップされています。 ワークフローについて追記しました。＜記事内容＞最近のComfyUIのアップデートログにHumoモデルが対応していると記載がありました。Support the 1.7B HuMo model. by comfyanonymous · Pull Request #9903 · comfyanonymous/ComfyUIHumoモデルは、バイトダンスが出しているモデルの様です。 Huggingfaceのページは以下になります。bytedance-research/HuMo · Hugging

https://note.com/gentle_murre488/n/nf4b3b9d9654d