OmniChar .char模型：让AI视频角色的脸、身、衣保持一致

在AI图像与视频生成中，角色一致性始终是最棘手的问题之一。同一个人物，换个场景、换个动作，脸就变了、衣服也乱了。一位Reddit开发者围绕这个痛点，构建了一个名为 OmniChar 的开源方案，用一个可移植的 .char 文件封装角色的面部、身体与服装特征，并将其接入 Minimax H3 视频生成流程，实现跨镜头的角色稳定输出。

什么是 .char 模型

.char 是作者设计的一种角色封装文件，核心思路是把一个虚拟人物的所有关键特征——面部、身体、服装——编码进一个单一、可携带的文件里。生成时，只需引用这个文件，配合简单的提示词即可复现同一角色。

作者建议在构建时最多放入 9 张参考图，并推荐按 2:2:1（脸:衣服:身体） 的比例分配。其中面部参考是必需项，身体和服装参考则是可选的。这种结构化的分槽设计，是为了让模型清楚地知道每一类特征该从哪里取样。

底层技术如何运作

从技术栈看，.char 的构建过程串联了几个成熟的视觉模型：

• YuNet 负责在参考图中定位人脸；
• SFace 为每张参考图提取一个人脸签名（face signature）；
• DINOv2 提取主体（subject）的整体特征签名；
• 参考图经过清洗与归一化后，全部打包进单个 .char 文件。

生成阶段，这个文件会把参考图喂入 Flux 的原生多参考通道（native multi-reference channel），并在提示词前面自动拼接一段锁定的角色描述。这种“描述前置 + 多参考图注入”的组合，是保证角色不漂移的关键机制。

值得关注的是，SFace 会自动对面部图像做交叉校验，从而在多张参考图之间维持面部签名的一致性。

这几个模型各有其技术背景。YuNet 是由中科院计算所开发的轻量级人脸检测网络，以极低的计算开销实现高精度的人脸定位，适合在流水线中快速处理批量参考图。SFace 是一种基于球面约束的人脸识别模型，其核心优势在于能够在开放集场景（即训练集中未见过的人脸）下仍保持稳定的特征提取，这使它在处理用户自定义角色时特别可靠。DINOv2 则是 Meta 研究院推出的自监督视觉基础模型，无需标注数据即可学习通用的视觉表征，对人物整体轮廓、姿态和服装纹理的编码能力显著优于传统有监督模型。将三者串联——局部人脸定位、跨图人脸一致性校验、整体主体特征提取——构成了 .char 文件能够稳定复现角色的特征工程基础。

提示词使用要点

作者给出的提示词指南相当实用，也反映出这类工具的一个反直觉之处：描述越少，越准确。

给角色命名并用名字触发

在 encode character 节点里给角色起个名字，比如作者用的 sia。之后生成时只需写 sia walking on the beach，模型就会自动调用该角色的全部特征。

不要重复描述已编码的特征

这是最容易踩的坑。如果在生成提示词里再写“a woman”或“black hair”这类已经编码进 .char 的特征，反而会误导生成结果。所有角色特征应集中写在 encode character 的提示词里，生成时只负责“调度”，不负责“重复”。

处理服装漂移

如果想指定特定款式（如短袖、无袖），需要把它加到生成提示词中。作者坦言服装可能出现轻微漂移——因为身体参考图上本身也带有衣服，会与服装参考产生干扰。解决办法是让每张参考图“职责单一”：脸的图不带身体，身体的图不带脸，服装图同理。

硬件门槛与工作流

这套方案对本地运行的硬件要求不低：

• NVIDIA GPU：24GB+ 显存
• 系统内存：64GB RAM

工作流方面，静态图使用 Flux 2 Klein，视频生成使用 Minimax H3。作者特别提到 Minimax H3 现已支持 int8 量化模型变体，这对显存吃紧的用户是个好消息。案例中的面部由 Flux Klein 9b 生成，而服装图直接取自 Zara 官网——这也侧面说明该方案对真实电商素材的兼容性。

项目以 GPLv3 协议开源，仓库地址为 github.com/omnichar/OmniChar。

int8 量化是一种将模型权重从32位或16位浮点数压缩为8位整数的推理优化技术。量化后模型体积和显存占用通常可减少约50%，推理速度也有所提升，代价是精度上存在轻微损失。对于 Minimax H3 这类参数量较大的视频生成模型，int8 量化意味着原本需要48GB或更高显存才能运行的模型，在消费级 24GB 显卡上也可以加载。Flux 2 Klein 则是 Black Forest Labs 推出的 Flux 系列蒸馏变体，通过流匹配（Flow Matching）框架和减少采样步数来加速静态图像生成，同时保留了 Flux 原生的多参考图注入通道，这是 OmniChar 能够将 .char 文件中的多张参考图直接喂入生成流程的技术前提。

局限与实践建议

作者对方案的边界很诚实。最主要的限制是 参考图冲突：如果两张参考/输入图包含不同的脸，生成时可能产生冲突。因此提供裁剪良好的身体与服装图至关重要——让模型精准取到所需的部位，避免脸槽里混入衣服、衣服槽里混入脸这类“串槽”问题。

一旦角色构建完成，.char 文件即具备可移植性：换一套简单提示词和生成图，同一角色就能在不同场景中复用。这正是这类封装方案相较于每次重新调参的价值所在——把一次性的特征工程，沉淀成可复用的资产。

小结

OmniChar 提供了一条务实的角色一致性路径：用 YuNet、SFace、DINOv2 做特征提取，用 .char 做封装，用 Flux 多参考通道和 Minimax H3 做生成。它不追求“一键出片”，而是通过结构化的参考图管理和克制的提示词策略，把角色漂移控制在可接受范围内。对于需要批量产出同一虚拟人物内容的创作者，这种开源、可移植的思路值得一试。