疑問：HunyuanVideoモデルとSkyreelsモデルのキーはComfyUI内でどのように処理されているのか？

HunyuanVideoのモデルマージのカスタムノードについての過去記事を一旦下書きに戻しているのですが、理由としては、一見上手くいったように見えてシード値を変えると思ったほどではなかったからです。
さらにskyreelsとオリジナルのinputの順番を変えたら効果が無くなるということもありました。

このモデルマージのカスタムノード内で、それぞれのモデルのキーを合わせるためにNormalize関数というのを追加したのですが、果たしてこれが意味を成しているのかもいまいちわかっていなかったので、そのあたりを調べてみたという話です。

＜モデルのUnetのキー名を調べる＞
以下のスクリプトをフォルダに配置して以下のコマンドで実行します
--src　以下のところに調べたいファイル名を入れる感じです。

python key_detect.py --src hunyuan_video_t2v_720p_bf16.safetensors

上のスクリプトの結果得られたのが、以下のモデルキーtxt一覧です。
具体例は後述しています。
ファイルは、後で見返すために貼り付けています。

カスタムノードにデバッグを追加することで、inputから入力されるキー名を確認したところ、同じ形式のキー名に変更されていました。。。。。

＜具体例＞
以下のような感じです。
※「double_blocks.0.img_attn.norm」が同じ部分を抽出しただけなので、もしかしたら違うものを比較しているかも知れません。

①オリジナルHunyuanVideoモデルのキー名
model.model.double_blocks.0.img_attn.norm.key_norm.scale  (128,)  torch.bfloat16
②Skyreelsモデルのキー名
double_blocks.0.img_attn_k_norm.weight (128,) torch.bfloat16
③input時のキー名
diffusion_model.double_blocks.0.img_attn.norm.key_norm.scale

ということで、「全てキー名が違う」というところと、inputで入力をもらう場合は、「キー名が統一されている」ということが分かります。
そのため、inputで入力をもらうカスタムノードだと、プレフィックスでdiffusion_model.を指定すれば、siingble blocksとdouble blocksを指定できるということになります。

この方法は、以下のカスタムノードを作成された方の手法になっています。
facok/ComfyUI-HunyuanVideoMultiLora

マージの際の問題点
dtypeの不整合が起こる場合があります。
例えばfp8化したkijaiさんのモデルだと、一部のキーはBF16のままになっている部分があるようですが、ComfyUI上で単純にfp8化すると全てのキーがfp8になるので、マージの際はその部分で整合性が取れなくなるようです。

という事で、ComfyUI-HunyuanVideoMultiLoraを作成された方は凄いという結論になりました。

＜応用？＞
このモデルキーは最終的にはComfyUIを通した際に統一されることが分かりました。
この利用方法として、「ModelSave」ノードで一度保存しなおすことで、キー名の問題をなくすことが出来ます。

Skyreelsモデルをデフォルトで保存したファイルのモデルキーについて調べてみると、オリジナルと同じモデルキー銘になっています！！！

SkyreelsモデルのGGUF化について＠ComfyUIネイティブ用｜shiba*2

このモデル保存をしてキー名を合わせる方法は、別記事のGGUF化の際に使用した方法になります。

＜考察的なもの＞
ComfyUIで動作するAIモデルの場合に以下のことが言えると思います。
①モデルのキー名を使用するスクリプトをComfyUI外で行う場合　⇒　ComfyUIを一度通して統一化
②ComfyUIのカスタムノードで、モデルのキー名を使用する場合　⇒　オリジナルのキー名ではなく、inputされるキー名を使用する