SoulX-FlashHead: Oracle-guided Generation of Infinite Real-time Streaming Talking Heads

Paper: arXiv:2602.07449 Code: Soul-AILab/SoulX-FlashHead Code reference: main @ 12467cef (2026-04-15)

1. Motivation（研究动机）

这篇论文要解决的核心问题是：audio-driven portrait generation 已经能在离线条件下生成很自然的 talking head，但一旦要求“实时、流式、无限长度、身份稳定、整体像素一致”，现有路线会在质量和延迟之间出现明显断裂。大模型式 video diffusion / DiT 往往能保住细节、发型、头饰、衣领和背景一致性，但计算开销高，难以在消费级硬件上交互；轻量 motion-based 或 landmark-based 方法速度快，却经常把嘴型、头部姿态、发丝、眼镜、帽子等局部元素拆开建模，长时间运行后更容易出现 lip-sync mismatch、面部漂移或整体结构断裂。

论文把这个矛盾拆成两个更具体的失效源。第一是 streaming audio feature instability：实时交互通常只能看到很短的音频片段，论文提到 live inference 中片段约为 1.32 秒，这会让 Wav2Vec 类 self-supervised audio encoder 的输入分布偏离完整语音上下文；如果直接用短片段做条件，音频 embedding 可能抖动、塌缩或携带不稳定语义。第二是 long-sequence autoregressive error accumulation：为了无限长度，模型必须一段一段生成视频，并把上一段生成出的 motion frames 当作下一段条件；只要某段有轻微偏差，后面会把偏差当成历史真值继续放大，最终表现为 identity drift、面部形状扭曲、头饰和人体脱节。

SoulX-FlashHead 的目标不是单纯追求“更快”或“更大”，而是同时满足四个约束：streaming capability、real-time performance、infinite generation length、holistic representation。表 1 中对比的 SadTalker、AniPortrait、EchoMimicV3、Ditto、Hallo3、Sonic 都各自缺一个或多个维度，而 SoulX-FlashHead 声称在 1.3B 参数规模下同时具备四项能力。这个定位决定了它的贡献由数据、模型结构、训练策略和推理系统四部分共同组成，而不是某一个单独模块。

2. Idea（核心思想）

核心洞察：把 talking head 当作统一 video latent generation 问题，而不是只预测局部 motion 或 facial landmarks；同时用“长音频上下文缓存”稳定流式音频条件，用“oracle-guided teacher”校正长序列自回归误差。换句话说，SoulX-FlashHead 试图让模型在每个短 chunk 内仍能看到足够音频历史，并在训练时显式模拟 student 的历史错误，再用 ground-truth motion history 作为 teacher oracle 给它纠偏。

这套设计的关键取舍是把速度压力交给 VAE 压缩和推理优化，把长程一致性压力交给训练策略。Pro 版本使用 WAN 2.1 VAE，目标是更高保真；Lite 版本使用 LTX-VAE 的高压缩 latent，目标是单卡 RTX 4090 上的高 FPS。两者共享 1.3B DiT 思路：参考图像和历史 motion 被编码进 latent，audio condition 通过 Wav2Vec2 多层特征进入 DiT block，最后在 latent space 中做 denoising / flow matching 生成视频。

论文最值得注意的地方在于它没有把“实时流式”当作部署阶段才处理的工程问题，而是把 streaming 的两个困难直接写进训练目标。Temporal Audio Context Cache 让音频侧训练/推理一致，Oracle-Guided Bidirectional Distillation 让训练时的 student 真正暴露在自回归历史里，而 teacher 仍持有 ground-truth motion frames。这样可以降低常见的 train-inference mismatch：如果训练永远只看到干净历史，模型上线后遇到自己的历史错误就会快速崩。

3. Method（方法）

3.1 VividHead 数据与 source-first 图示

论文构建了 VividHead 数据集：从超过 10k 小时原始素材中筛选出 330K 个高质量短片段，总时长 782 小时，分辨率 512×512，包含严格时间对齐的 speech audio，并带有 language、ethnicity、age 等元数据。样本被限制为单个可见说话人和 active head region，目的是减少多人、遮挡、背景快速切换对模型学习的干扰。

Figure 1 解读：数据流水线先做 acquisition、deduplication、scene segmentation 和 25 fps 标准化，再进入过滤与标注阶段。过滤包括初帧 face detection / mask extraction、512×512 face-centered crop、optical flow 检测突变场景、每秒采样检查无脸比例、DWpose 过滤 hand-over-face occlusion、SyncNet 计算 LSE-C / LSE-D 去掉音画不同步样本。标注阶段继续抽取 face mask、分离音频、用 Wav2Vec 提取 streaming audio embedding，并生成语言、年龄、族裔等标签。这个数据步骤服务于后续模型：如果训练集本身存在大量 occlusion、scene cut 或音画错位，任何 streaming cache 和 distillation 都只能学习到噪声条件。

3.2 模型结构：统一 latent video generation

SoulX-FlashHead 的主干是 1.3B Diffusion Transformer。输入是参考图像、音频和历史 motion frames；输出是与音频同步的视频帧。论文沿用 flow matching / DiT 风格，在 latent space 学习从 noise 到 video latent 的 vector field，基础目标可写成： ${\mathcal{L}}_{\text{FM}}(\theta )={\mathbb{E}}_{t,p_t(\mathbf{x})}\Vert {\mathbf{v}}_t-{\mathbf{u}}_t{\Vert }^2,{\mathbf{x}}_t=t{\mathbf{x}}_1+(1-t){\mathbf{x}}_0.$ Pro 和 Lite 的主要差异在 VAE。Pro 使用 WAN 2.1 VAE，spatio-temporal downsampling factor 为 $4\times 8\times 8$，更重视 reconstruction fidelity 和细粒度视觉细节。Lite 使用 LTX-VAE，downsampling factor 为 $(32,32,8)$，pixel-to-token ratio 达到 $8192:1$，论文称约为 WAN scheme 的 32×，因此能把 1.3B 模型压到实时交互所需的 token 规模。这个选择也解释了为什么 Lite 能达到 96 FPS，但 Pro 在质量更高时单卡只有约 10.8 FPS。

参考图像注入采用 channel-wise concatenation，而不是只注入 identity embedding。公开代码中 WanModelAudioProject.forward 会把当前 noisy latent x 与参考 latent y 在 channel 维拼接，再做 3D patch embedding；这与论文强调的 holistic representation 一致：发型、头饰、服饰边界和背景不是被拆成局部控制点，而是作为像素/latent 空间的一部分被统一建模。随后 DiT blocks 使用 audio-projected context、time embedding 和 3D RoPE 进行 denoising。

3.3 Temporal Audio Context Cache（TACC）

流式场景中，模型不能等待整段音频结束再编码。论文定义固定长度窗口 $T_{\max }=8s$，对任意 raw audio stream ${\mathcal{A}}_{raw}$ 构造： ${\mathcal{Q}}_{audio}=\{\begin{array}{ll}\text{Concat}(0_{pad},{\mathcal{A}}_{raw}),& |{\mathcal{A}}_{raw}|<T_{\max }\\ {\mathcal{A}}_{raw}[-T_{\max }:],& |{\mathcal{A}}_{raw}|\ge T_{\max }.\end{array}$ 然后用 Wav2Vec 编码 ${\mathcal{Q}}_{audio}$，聚合多层特征得到 $E_{audio}\in {\mathbb{R}}^{S\times Layers\times D}$，再取最后 $N$ 个对齐当前视频帧的音频特征： $Z_{cond}=E_{audio}[-N:].$ 代码中的实现与这个描述是对应的。flash_head/configs/infer_params.yaml 固定 cached_audio_duration: 8、sample_rate: 16000、tgt_fps: 25、frame_num: 33、height: 512、width: 512。generate_video.py 的 stream 模式先用长度为 sample_rate * cached_audio_duration 的 deque 保存 8 秒 audio cache；每来一个 chunk，就把新音频 append 到 deque，把 deque 转为 audio_array，再调用 get_audio_embedding(pipeline, audio_array, audio_start_idx, audio_end_idx)。get_audio_embedding 会先通过 pipeline.preprocess_audio 调用 Wav2Vec2，再用以当前帧为中心的 5-frame window 取局部音频特征，最终形成 DiT 所需的 audio condition。

直觉上，TACC 的作用不是增加模型感受野这么简单，而是把“短片段输入”改造成“短片段末端的局部条件 + 足够长的历史上下文”。这样 Wav2Vec2 的 hidden states 不必在 1 秒左右的孤立音频上工作，而是在 8 秒队列上提取稳定 representation；模型使用最后对齐当前视频的部分，从而兼顾 streaming latency 和 audio feature stability。

3.4 Oracle-Guided Bidirectional Distillation

第二阶段解决长序列自回归误差。标准 DMD 关注 real score 与 fake score 的分布匹配，但如果 student 的条件历史来自自己生成的 motion frames，而 teacher 的条件历史来自 ground truth，则两者的 conditioning distribution 不一致，指导信号会变得不准确。SoulX-FlashHead 的做法是显式模拟 autoregressive inference：student 生成连续 $K$ 个 video chunks，每个 chunk 都 conditioned on ${\mathbf{m}}_{pred}$；teacher 则保持 conditioned on ground-truth motion history ${\mathbf{m}}_{gt}$，作为 oracle physical prior。

论文还引入 Stochastic Truncation Strategy。完整 unroll $K$ 个 chunk 的计算图会非常重，因此训练时从均匀分布随机采样截断长度 $k$，只对第 $k$ 个 chunk 的随机 denoising step $t^{\prime }$ 保留梯度，前面步骤 detach。最终目标把 distribution matching 和 latent regression 合起来： ${\mathcal{L}}_{total}={\mathbb{E}}_{k,t^{\prime }}\left[D_{KL}\left(p_{\varphi }({\mathbf{x}}_0|{\mathbf{m}}_{gt})\Vert p_{\theta }({\mathbf{x}}_0|{\mathbf{m}}_{pred})\right)+\lambda \Vert {\mathbf{z}}_{student}^{(k)}-{\mathbf{z}}_{gt}^{(k)}{\Vert }_2^2\right].$ 这里的“bidirectional”可以理解为两条条件路径的对照：student path 面向真实推理时会遇到的 predicted history，teacher path 面向 ground-truth motion oracle。它不是让模型上线时访问未来真值，而是在训练时把真值作为校正方向，迫使 student 在带噪历史上仍能回到合理 motion manifold。这个机制直接对应 Figure 3 中长视频的 drift 问题：模型需要在几十秒之后仍保持嘴型、眼睛、头饰和身体结构不散。

Figure 2 解读：左侧 Stage 1 用 Temporal Audio Context Cache 和 reference image injection 做 streaming-aware pre-training；右侧 Stage 2 让 Student 自回归生成历史，Teacher 使用 ground-truth motion frames 作为 oracle，并通过 DMD + latent regression 做 distillation。图中最重要的不是模块数量，而是训练条件与推理条件的对齐：Student 必须学会面对自己的历史输出，而不是永远依赖干净真值。

3.5 Real-time Inference Acceleration

推理系统由三层优化组成。第一是 Hybrid Sequence Parallelism：论文使用 xDiT，把 DiT attention 的主要计算通过 Ulysses 与 Ring Attention 分摊到多 GPU；公开脚本 inference_script_multi_gpu_pro.sh 使用 torchrun --nproc_per_node=2，对应 Pro 模型双卡实时场景。第二是 kernel optimization：论文采用 FlashAttention-2，README 也要求安装 FlashAttention，并把 SageAttention 标为可选以支持更高速度。第三是 runtime optimization：FlashHeadPipeline.__init__ 中对 self.model、VAE encode/decode 使用 torch.compile，减少 Python overhead 和启用图级融合。

公开 README 的关键速度结论是：Model_Lite 在单张 RTX 4090 上达到 96 FPS，或 3 路并发实时（25+ FPS）；Model_Pro 在单张 RTX 4090 上生成 10.8 FPS 的高质量视频，在两张 RTX 5090 上可达到实时（25+ FPS）。这些数字与论文 Table 3/4 中 SoulX-FlashHead (Lite)* 的 96 FPS、SoulX-FlashHead (Pro)* 的 10.81 FPS 一致。

3.6 公开代码对应的推理伪代码

Code reference: main @ 12467cef (2026-04-15) — 以下伪代码基于公开仓库的 inference / Gradio / pipeline 实现；训练和数据清洗代码未在该 repo 中公开。

# generate_video.py + flash_head/inference.py + FlashHeadPipeline
pipeline = get_pipeline(
    world_size=WORLD_SIZE,
    ckpt_dir="models/SoulX-FlashHead-1_3B",
    wav2vec_dir="models/wav2vec2-base-960h",
    model_type="lite" or "pro",
)
get_base_data(
    pipeline,
    cond_image_path_or_dir=reference_image,
    base_seed=seed,
    use_face_crop=True/False,
)
params = get_infer_params()
frame_num = params["frame_num"]              # 33
motion_frames_num = params["motion_frames_num"]
slice_len = frame_num - motion_frames_num
 
audio = librosa.load(audio_path, sr=16000, mono=True)
audio_cache = deque([0.0] * (16000 * 8), maxlen=16000 * 8)
for audio_chunk in split(audio, chunk_size=slice_len * 16000 // 25):
    audio_cache.extend(audio_chunk)
    audio_embedding = get_audio_embedding(
        pipeline,
        np.array(audio_cache),
        audio_start_idx=8 * 25 - frame_num,
        audio_end_idx=8 * 25,
    )
    latent_or_frames = pipeline.generate(audio_embedding)
    frames = latent_or_frames[motion_frames_num:]  # remove overlap motion frames
    append(frames)
save_video(frames, audio_path, fps=25)

FlashHeadPipeline.generate 的内部逻辑是：先采样 latent noise，并把前若干 latent motion frames 替换为历史 motion latent；按 scheduler timesteps 循环调用 WanModelAudioProject 预测 flow；如果是 Pro / teacher 模式，会做 classifier-free audio guidance，即再用 zero audio condition 得到 flow_pred_drop_audio，再按 audio_guide_scale 调整；denoising 完成后用 VAE decode 为视频帧，再把末尾 motion_frames_num 帧重新 encode 成下一轮 latent_motion_frames。这个闭环就是无限长度 streaming 的代码路径。

gradio_app_streaming.py 进一步把推理线程和前端输出解耦：worker thread 按 chunk 顺序执行 get_audio_embedding → run_pipeline → video[motion_frames_num:]，把 (chunk_idx, frames) 放进 res_queue；主线程积累若干 chunk 后保存成带音频的 preview segment 并 yield 给 Gradio。这个实现说明论文中的 streaming 不是只在离线脚本里顺序生成，而是有面向前端交互的分段返回路径。

3.7 代码映射表

Paper Concept	Source File	Key Class/Function
模型与权重发布、速度声明	README.md	Highlights, Model download, Inference
单卡 Lite / Pro 推理入口	inference_script_single_gpu_lite.sh, inference_script_single_gpu_pro.sh	python generate_video.py --audio_encode_mode stream
双卡 Pro 推理入口	inference_script_multi_gpu_pro.sh	torchrun --nproc_per_node=$GPU_NUM generate_video.py
推理主循环与 8s audio cache	generate_video.py	generate, _parse_args, save_video
pipeline 组装与参数计算	flash_head/inference.py	get_pipeline, get_base_data, get_audio_embedding, run_pipeline
推理配置	flash_head/configs/infer_params.yaml	frame_num=33, cached_audio_duration=8, sample_rate=16000, tgt_fps=25
VAE 选择、Wav2Vec2、torch.compile	flash_head/src/pipeline/flash_head_pipeline.py	FlashHeadPipeline.__init__, prepare_params, preprocess_audio, generate
DiT 音频条件投影与参考图拼接	flash_head/src/modules/flash_head_model.py	WanModelAudioProject.forward, AudioProjModel.forward
Wav2Vec2 hidden states	flash_head/audio_analysis/wav2vec2.py	Wav2Vec2Model.forward, encode
Gradio streaming 前端	gradio_app_streaming.py	run_inference_streaming, nested inference_worker
数据清洗、Stage-1 pretraining、Oracle-guided distillation 训练	public repo 未公开	论文描述与 released weights 支持，未见训练源码

4. Setup（实验设置）

实验主要在 HDTF 和 VFHQ 两个 benchmark 上比较。指标包括 FID（图像分布质量，越低越好）、FVD（视频分布与时序质量，越低越好）、Sync-C（lip-sync confidence，越高越好）、Sync-D（lip-sync distance，越低越好）和 FPS（速度，越高越好）。论文把 streaming 方法标为 *，non-streaming 方法标为 △；对于 non-streaming，FPS 不作为 meaningful metric，因为它们不按在线流式协议输出。

对比方法覆盖 motion-based、diffusion-based 和大规模 talking-head generation 路线，包括 SadTalker、AniPortrait、EchoMimic、Ditto、Hallo3、Sonic。Table 1 的能力对比强调 SoulX-FlashHead 同时拥有 Stream、Real-Time、Inf-len、Holistic Representation 四个属性，参数规模为 1.3B；相比之下，Ditto 虽然 stream / real-time / infinite-length 都为真，但 holistic representation 为假，Sonic 和 AniPortrait 具备整体表示但不支持 streaming real-time。

数据设置方面，VividHead 和已有数据集相比不是最大时长数据集，但它在 face crop、512p resolution、15 languages、0-60+ age、3 ethnicity、wild source 等维度更均衡。Table 2 中 AVSpeech 有 4700 小时、OpenHumanVid 有 16.7K 小时、SpeakerVid 有 8.7K 小时，但 VividHead 的重点是从 10k 小时素材过滤到 782 小时严格对齐数据，而不是保留最大规模噪声池。论文也把 VividHead 发布到 Hugging Face dataset 页面，公开 repo 则提供推理代码和 Model_Lite / Model_Pro 权重。

需要注意 release scope：公开 GitHub 仓库是 inference-first release，不包含完整训练脚本、数据清洗 pipeline 或 distillation loss 实现。因此本笔记中关于 Stage 1 / Stage 2 的训练细节来自论文和图示；关于 streaming cache、audio embedding、latent motion recurrence、VAE decode/encode 和 Gradio streaming 的伪代码来自 main@12467cef 的公开实现。

5. Results（结果与分析）

5.1 HDTF 量化结果

在 HDTF 上，SoulX-FlashHead Pro 的 non-streaming 版本达到 FID 8.31、FVD 103.14、Sync-C 6.04、Sync-D 8.46；streaming Pro 达到 FID 9.97、FVD 111.38、Sync-C 5.73、Sync-D 8.77、FPS 10.81。Lite streaming 的速度最高，FPS 96，同时 FID 11.37、FVD 126.52、Sync-C 4.21、Sync-D 9.49。对比基线中，EchoMimic streaming 的 FID 9.00 也很强，但 FVD 155.71、Sync-C 3.56、FPS 0.81；Ditto streaming 的 FPS 45.04，但 FID 12.35、FVD 199.13、Sync-C 3.57；Sonic non-streaming 的 Sync-C 5.17、Sync-D 8.69 较好，但不支持 streaming FPS。

这个结果表明 Pro 版本是质量优先：它在 non-streaming 和 streaming 模式下都把 FVD 压到 111.38 以内，说明长视频分布和时序连贯性较好；Lite 版本是延迟优先：96 FPS 明显超过实时阈值，并且 FID/FVD 没有退化到传统 motion-based 方法的水平。论文对“无限实时”的主张主要靠 Lite 的 FPS 和 streaming protocol 支撑，对“高保真”则主要靠 Pro 的 FID/FVD/Sync 指标支撑。

5.2 VFHQ 量化结果

在 VFHQ 上，SoulX-FlashHead Pro non-streaming 达到 FID 13.67、FVD 133.69、Sync-C 5.60、Sync-D 7.81；streaming Pro 达到 FID 14.05、FVD 140.27、Sync-C 5.53、Sync-D 8.01、FPS 10.81。Lite streaming 达到 FID 16.95、FVD 167.90、Sync-C 4.70、Sync-D 8.66、FPS 96；Lite non-streaming 为 FID 15.18、FVD 156.20、Sync-C 5.33、Sync-D 8.12。

VFHQ 结果比 HDTF 更能说明 lip synchronization 和 identity preservation 的压力，因为 VFHQ 的人脸质量更高、场景更复杂。Pro streaming 的 Sync-C 5.53 高于 SadTalker 4.49、Ditto 3.31、Hallo3 4.19、Sonic 4.64，同时 Sync-D 8.01 低于这些基线。这与论文关于 Oracle-Guided Bidirectional Distillation 的叙述一致：如果长序列自回归误差被压住，嘴型和头部运动不会在 60 秒以后明显偏离音频。

5.3 定性结果与长视频稳定性

Figure 3 解读：论文在 60-second video generation at 25 fps 上比较 Ditto、SadTalker、Hallo3 和 SoulX-FlashHead。黄色虚线区域标出 Ditto / SadTalker 这类 motion-based 方法的 lip synchronization mismatch；绿色区域标出 Hallo3 中 error accumulation 和 identity drift；红框则强调缺少 unified pixel latent space modeling 时，帽子等 holistic elements 会与主体分离。SoulX-FlashHead 的定性优势是嘴型、结构和整体像素元素在长序列里都更稳定，而不是只在前几秒保持清晰。

这一定性图也暴露出论文主张的真正评估对象：不是单帧 portrait quality，而是“长时间交互过程中的可持续稳定性”。如果一个模型只在 5 秒 clip 上看起来好，但 60 秒后嘴型、脸型、头饰或衣物逐渐偏移，它无法支撑 infinite streaming talking head。SoulX-FlashHead 用 motion frame recurrence 加 oracle distillation 处理这种后期漂移，用统一 latent 表示处理局部元素与主体脱节。

5.4 速度与部署解释

速度方面，Lite 的 96 FPS 是最关键数字，因为它意味着单卡 RTX 4090 可以支持超过实时阈值的生成，README 进一步声称能支持 3 路并发实时（25+ FPS）。Pro 的 10.8 / 10.81 FPS 不够单卡实时，但质量更高；论文和 README 都把 Pro 的实时部署放到两张 RTX 5090 + SageAttention 的条件下。这个划分对实际使用很重要：如果应用要求低延迟对话，Lite 是默认选择；如果应用要求更高质感和细节，可用 Pro 但需要更强硬件或接受更高延迟。

公开代码中，gradio_app_streaming.py 按 chunk 输出 preview segment，而不是等整段完成后再返回；这与用户感知的实时性直接相关。每个 segment 由若干 chunk 合成带音频 mp4 并 yield 给前端。即便底层模型仍然按 chunk 顺序生成，前端也可以在后续 chunk 计算时播放前面的 segment，从而降低交互等待。

6. Limitations（局限与风险）

第一，训练代码未公开，所以 Oracle-Guided Bidirectional Distillation、Stochastic Truncation Strategy、DMD loss 和数据清洗 pipeline 目前只能从论文复现，无法在 public repo 中逐行验证。公开代码能验证的是 inference path：Wav2Vec2 audio embedding、8 秒 cache、DiT audio projection、VAE encode/decode、motion frame recurrence、Gradio streaming。若要精确复现论文训练，仍需要作者发布 training configs、dataset filtering scripts 和 distillation implementation。

第二，实时速度依赖硬件和 kernel stack。96 FPS 是 Lite 在单张 RTX 4090 上的结果，Pro 的实时需要两张 RTX 5090；FlashAttention、SageAttention、torch.compile、xDiT 和 VAE 编译都会影响吞吐。如果部署环境不同，FPS 不能直接外推。尤其是 Gradio streaming 的端到端体验还取决于音频切片、编码、ffmpeg 合成和前端播放缓冲，不完全等于模型 core denoising FPS。

第三，VividHead 虽然强调 15 languages、0-60+ age 和 3 ethnicity，但论文没有在公开文本中给出更细的 fairness / privacy / consent 分析。Talking-head generation 天然存在肖像权、伪造视频和身份误用风险。论文的 Ethics Statement 提醒该技术可能被滥用于 impersonation、misinformation 和 deepfake，需要 watermarking、consent verification 和 platform-level detection；实际部署应默认加入身份授权和生成内容标识。

第四，论文没有提供独立 ablation table 来逐项量化 TACC、Oracle guidance、bidirectional distillation、latent regression、VAE choice 和 acceleration stack 的贡献。读者可以从定性图和最终指标推断这些模块有效，但无法确认每个模块对 FID/FVD/Sync/FPS 的边际收益。对工程复用而言，最需要补充的是：去掉 8 秒 cache 会让 Sync-C / Sync-D 下降多少；只用 standard DMD 不用 oracle teacher 时 60 秒 identity drift 增加多少；Lite 的高压缩 VAE 在不同人物属性上是否有系统性 artifacts。

7. Takeaways（可复用结论）

对后续 audio-video generation 工作，这篇论文的可复用点有三个。第一，streaming 模型不能只在部署阶段做 sliding window；音频条件的上下文构造要在训练阶段就固定下来，否则 Wav2Vec2 hidden states 会出现 train-inference mismatch。第二，长视频自回归训练不能永远 teacher-forcing；student 必须在训练中看到自己的历史预测，否则 infinite generation 的误差累积无法被真正优化。第三，实时 talking head 的“整体感”需要 unified latent representation 支撑，局部 motion control 很难长期保持帽子、头发、眼镜、衣领和背景与主体一致。

对实际落地，SoulX-FlashHead 更像一个双档位系统：Lite 用 LTX-VAE 高压缩换速度，适合实时交互和多路并发；Pro 用 WAN VAE 和更重推理换细节，适合质量优先场景。公开 repo 已经足够支持 inference integration，但如果目标是训练新身份域、新语言域或改进 distillation，则仍需等待训练代码或自行按论文重建 Stage 1 / Stage 2。