TARA：MiniMax H3 引用的原生时序对齐

MiniMax H3 上的运动迁移通常通过把驱动片段的 latent 作为引导注入来实现：Add Guide，或同一 latent 空间中的带遮罩 latent。TARA 走的是另一条路。片段作为原生 <Video N> 引用送入 MiniMax H3 Reference to Video，其时间 RoPE 原点与输出时钟对齐，并且每个输出时刻对远处引导时刻的注意力会被惩罚。用仓库中的话说，该模式"保留原生视频引用，将其时间 RoPE 坐标与目标对齐，并柔和地惩罚目标查询对远处引导时间的注意力"。

补丁本身不训练任何内容。它不添加任何学习权重，也不自带 LoRA；时间偏好是在采样时计算的，并且只作用于关注所选运动视频的输出查询。引用图片保留其原生坐标，文本、引用音频以及目标自身的自注意力仍遵循常规规则。

时间规则

只有从输出视频查询到所选运动视频键的连边会被修改：

dt = abs(output_time - guide_time)
penalty(dt) = min(strength * (max(dt - window, 0) / falloff)^2, cap)
score = dot(Q, K) / sqrt(head_dim) - penalty(dt)

默认值为：自由窗口 0.20 s、falloff 0.25 s、strength 2.0、cap 6.0，在节点上以 window、falloff、strength 和 cap 暴露。在自由窗口内完全没有惩罚。窗口之外，惩罚按二次方增长，直至达到上限，因此远处的引导帧仍以较小权重可用，而不是被完全屏蔽。在默认值下，局部修正约在 0.633 s 处降为零。

文档明确记录了一个注意事项：将 strength 设为零只会移除偏置，并不会移除 RoPE 对齐，因此真正"关闭 TARA"的对比意味着绕过该节点，把原始模型同时接到 guider 和 scheduler。

接线方式

独立节点为 BFS MiniMax H3 TARA - Native Temporal Alignment (Experimental)，置于 MODEL 路径上，位于 LoRA 加载之后、guider 之前。运动片段是普通的原生 <Video N> 引用，motion_video_index 选择由哪一个提供运动；图片和视频的编号相互独立。

仓库要求两端均为 24 fps，且帧窗口匹配（107 帧是合法帧数），并警告不要叠加第二个时间补丁，同时要在 MODEL 路径上保持关闭 Add Guide、首帧引导、VSA、SLA 以及未知的注意力或块替换。普通生成遮罩仍然允许，因为遮罩不会产生时间引导。在 CFG 路径上，补丁模型评估的每个条件分支都必须保留运动引用。

在 Shot Planner（BFS Shot H3 Conditioning）内部，同样的行为只是一个下拉选项：guide_mode = TARA - Native Temporal Alignment (experimental)。条件节点返回打补丁后的模型，实际采样的是当前镜头的打包时间网格。

三种后端

• Flash Partitions（自 1.115.11 起为默认）保留该规则，但通过原生 CUDA FlashAttention 与 log-sum-exp 输出进行评估，合并三个非负贡献，而不是构建稠密偏置张量或 torch.compile 内核。它需要 CUDA FP16/BF16 以及 PyTorch 的 FlashAttention-with-LSE 基础原语。
• Comfy Kitchen one-pass kernels（1.115.16 及更高版本）将该规则融合进稠密 INT8 与 sol-attn 内核，并去掉逐帧注意力循环。Linux 上提供 SM80、SM86、SM89、SM90、SM100 和 SM120 的预编译库，Windows DLL 覆盖 SM86、SM89 和 SM120；即使 PyTorch 运行在 12.x 上，驱动也必须支持 CUDA 13。从 1.115.17 起，Linux SM120 上的首次使用设置是自动的，采样时的一行日志会说明融合路径是否实际运行。
• sol-attn 兼容性（1.115.14）在文档说明的限制内受支持，并且自 1.115.13 起已遵循官方模型注意力后端节点。

数字说明了什么

仓库将一个独立的微基准测试与一位用户的完整工作流日志分开，并对两者都做了标注。在 RTX PRO 6000 Blackwell 上，107,126 个 token、8 个 head、BF16：

对于该形状，这比原始时序后端大约快 1.5 倍，是在一个训练进程同时运行时测得的，且使用 8 个 head 而非 H3 的 56 个，因此这并不是整模型速度的结论。一位用户在 RTX 5090 上以 544×928、360 帧运行，报告在 guide scale 1.0（52,751 行引导）下首次完整模型评估耗时 179.18 s，在 scale 0.5（11,984 行）下为 54.45 s，第二次评估为 47.19 s。较旧的 FlexAttention 路径记录的首次步骤耗时为 603.40 s（含初始化），文档称这无法与预热后的注意力调用相比。

你仍然需要什么

TARA 不会取代运动迁移 LoRA，它改变的是引用的条件方式。文档建议将此节点与通过 ai-toolkit 的 feat/h3-native-temporal-motion 分支训练的 checkpoint（native_temporal_v1）搭配使用，而仓库中的公开对比使用的是为 Add Guide 训练的 step-10500 LoRA。在时间补丁下，该 LoRA 会跟随源表演，并保留引用角色的服装，作者将其记录为实验性观察而非保证。文档中提到一个 step 750 的全新原生时序 checkpoint 显示出较弱的身份保持能力，且未作为下载发布，因此目前还没有匹配的公开适配器。

在 Banodoco Discord 上，一位用户在节点发布当天就在 RTX 4090 和 H100 上试用了该节点，报告两张卡都能运行，在该硬件上 Kitchen 路径略慢于 flash partitions。

六列对比中的一帧，从左到右依次为：原始引导、使用 TARA 且 guide scale 为 1.0 的 step-10500 LoRA、同一 LoRA 使用 TARA 且 scale 为 0.5、同一 LoRA 使用 Add Guide latent、未加时间补丁的原生引用，以及带原生引用的基础模型。视频中时间列标记为 NEW。

仓库导出的完整 15 秒并排视频，六列同时播放。

调整四个控件

该节点包还附带一份动画参数指南，其中包含一个离线 HTML 版本，其滑块会以动画演示同一规则。它的建议是从默认值开始，保持 seed、LoRA、提示词、源与输出不变，每次只改一个控件。运动漂移首先是一个时间线问题：错误的 <Video 1>、帧率不匹配或帧窗口偏移，都无法通过更强的偏置来修复。身份漂移指向引用分配、LoRA 和图像条件，而不是时间控件。

自由窗口、falloff、strength 和 cap，来自仓库的参数指南。

局限性

• 该功能是实验性的且需手动启用；Planner 的默认值仍是 Add Guide，文档称完整的视觉质量验证尚不完整。
• 公开演示是定性的：各列使用相同 seed，但并非所有生成设置都被记录下来，而且所要求的背景替换仍然只是部分实现。
• 两个片段需要匹配的时间网格，且该策略仍保留稠密的二次方注意力计算量。
• 目前的验证包括 CPU 数学与路由测试，以及用户报告的 RTX 5090 评估。引导音频以原生方式打包，但没有施加时间偏置。

可用性

ComfyUI-BFSNodes 在 Comfy 注册表中以 bfsnodes 发布，可通过 ComfyUI Manager 安装，或克隆到 custom_nodes/。TARA 运行在原生 MiniMax H3 节点以及常规 H3 生成所用的 Comfy-Org/MiniMax-H3 权重之上。

完整条件契约见 H3_NATIVE_TEMPORAL.md，后端推导与耗时表见 H3_FLASH_PARTITIONS.md，方法背后的研究分支见 alisson-anjos/ai-toolkit。如需在此节点包之外使用，还有一份手动安装指南。