minmax h3 的当前阶段测试已经跑完对固定角色“甜美款南宫阙”的生成效果有了初步结论在常规表情和小幅动作场景里角色一致性保持得不错但一旦进入“大动作生成”场景比如快速起身、旋转、挥手、身体倾斜画面仍会出现可感知的形变和不稳定。这也正好把下一阶段测试方向指向两个关键词更多测试场景以及更可控的大动作生成。本文是对这一阶段测试的工程化整理内容包含测试方法、环境准备、用例设计、结果评估、本地部署探索和问题排查适合正在做视频生成模型评测或者准备把 H3 接入自有流程的开发者参考。1. 先弄清 minmax h3 的测试边界1.1 H3 在视频生成任务里的定位H3 是一个视频生成模型至少从当前测试用途看它的输入是文本提示词和可选的角色参考图输出是一段视频或一组视频帧。和大语言模型不同视频生成模型不只判断“文字是否被理解”还要同时处理角色外貌、动作时序、镜头运动和光影变化所以评测难度更高。这里需要特别说明“大动作生成”的含义。它并不只是简单的“动作幅度大”而是指提示词中出现大幅度肢体动作、快速位移、剧烈镜头切换或高动态场景。这类任务对视频生成模型是难点因为动作幅度越大中间帧之间的运动估计越容易出错容易出现肢体扭曲、闪烁、丢帧或角色身份漂移。当前阶段测试的对象是“甜美款南宫阙”这个固定角色。固定角色测试的意义在于视频生成模型最容易出现角色不一致同一个角色在不同镜头里如果脸型、发色、服装发生变化视频就无法用于实际项目。所以我们把角色信息固定在提示词中并发给模型一张参考图用来检验它在多帧动作过程中是否还能记得角色基础属性。1.2 为什么“大动作生成”值得单独测试很多人第一次使用视频生成模型时会先测试“角色从站着到坐下”这类简单动作。这种测试能跑通并不代表模型能完成复杂动作。真正的考验是“快速转身、跳跃、奔跑、舞蹈旋转”这类需要多个关节协同、大幅度位移的动作。大动作生成之所以难是因为视频模型需要在一段连续时间步中同时保证三件事角色外观稳定前后帧不串脸。运动轨迹合理肢体关节不扭曲。动态模糊和画面细节不过度劣化。如果只测试静态画面或微动作这些问题很难暴露出来。把“大动作生成”作为专门的测试维度后才能准确判断 H3 的真实能力边界。1.3 在线 API 测试和本地部署要分开看在线 API 测试速度快适合快速验证 prompt 效果但生产环境不能一直依赖第三方接口。一是成本二是批量生成时并发和排队不可控三是某些视频数据可能不适合上传到外部服务。所以测试规划里要把 API 测试和本地部署分开先用 API 调通效果再评估本地部署的硬件成本和技术难度。2. 测试环境准备2.1 接入方式选择在开始前必须确认 H3 有哪些接入方式。常见可能包括官方云端 API适合快速验证、批量测试、无需 GPU。本地权重推理适合定制化流程、离线处理、数据不出域但依赖 GPU 资源。本文测试流程先走 API因为阶段目标是跑通测试用例本地部署放在后续章节单独说明。无论使用哪种方式都需要向接口提供提示词、可选参考图、生成时长、分辨率、随机种子等。具体字段名以实际接口文档为准。2.2 硬件与软件依赖清单如果只使用 API机器要求较低CPU没有特殊要求。内存8GB 以上。Python3.10 以上。网络能够访问 API 域名。如果要做本地部署要求会高很多GPU建议 NVIDIA 显卡显存 24GB 以上。CUDA 与 PyTorch 环境。模型权重文件通常包括 config、模型权重和 tokenizer 等。足够大的磁盘空间视频生成权重通常较大。下面给一个环境检查命令参考python --version nvidia-smi pip list | grep torch如果nvidia-smi输出正常并且 PyTorch 能识别 GPU本地推理才有基础。注意这里只是环境预检查并不代表 H3 一定能跑通这类标准环境。2.3 测试项目结构与配置示例为了后续测试可复现建议把测试工程组织成统一目录h3-test/ prompts/ case_001.txt case_002.txt images/ character_reference.png outputs/ case_001_result.mp4 scripts/ run_test.py records/ test_results.csv配置文件用 YAML 记录测试参数方便批量跑用例时保持一致character: name: nan_gong_que style: sweet reference_image: images/character_reference.png generation: duration_seconds: 4 resolution: 1280x720 steps: 30 seed: 42 cfg_scale: 7.5 output: dir: outputs save_frames: true这只是一个示例结构关键是把每次生成的参数、提示词、输出文件关联起来。没有记录参数就没有办法复盘问题。3. 设计大动作测试用例3.1 提示词的结构化写法视频生成模型对提示词非常敏感。为了做对比提示词不能随意写要拆成固定部分和变化部分。固定部分包括角色外貌描述。画风。光线。镜头位置。变化部分只替换动作描述。例如一个甜美风格的年轻女孩长发浅色裙子柔和光线半身镜头。她站立后快速转身裙摆飘起动作幅度大。同一个角色把动作换成“用力挥手后跑向画面右侧”或“从椅子上跳起并旋转一圈”就成了不同测试用例。在实际测试中固定部分不要随意改动否则无法判断画面差异是动作引起的还是角色描述引起的。3.2 分组测试从轻微动作到大动作大动作不能直接测“剧烈动作”否则无法判断模型是动作能力不足还是提示词缺细节。建议分三组动作等级示例动作预期难度微动作眨眼、微笑、头发微动低中动作转头、挥手、缓慢站起中大动作快速转身、跳跃、奔跑、舞蹈旋转高每组至少生成 4 个视频使用相同 seed 或不同 seed 进行对比。如果只生成一次就下结论很容易遇到随机噪声带来的误判。3.3 固定测试参数为了控制变量所有用例尽量使用相同分辨率、时长、种子等。这样出现差异时可以归因于提示词中的动作描述而不是参数漂移。参数本次测试值说明分辨率1280x720高清模式便于观察细节时长4 秒大动作在 4 秒内更容易出现形变种子42固定种子便于复现总步数30稳定性和生成速度折中采样器以默认配置为准不在本次测试中调整参数表的作用是让团队里任何人都能按同一组配置跑出一致结果。如果 API 不支持某参数则忽略该行并记录到测试备注中。4. 运行测试与结果评估4.1 最小调用脚本如果走 API最小脚本可以这样写import requests import base64 import time API_ENDPOINT https://your-api.example.com/v1/generations API_KEY your-api-key def generate_video(prompt, image_path, duration4, seed42): with open(image_path, rb) as f: image_base64 base64.b64encode(f.read()).decode() payload { model: h3, prompt: prompt, image: image_base64, duration_seconds: duration, seed: seed, } headers {Authorization: fBearer {API_KEY}} response requests.post(API_ENDPOINT, jsonpayload, headersheaders, timeout300) if response.status_code ! 200: print(response.text) return None task response.json() # 根据接口设计轮询结果 for _ in range(60): result requests.get(task.get(url), headersheaders, timeout30) if result.status_code 200 and result.json().get(status) succeeded: return result.json().get(video_url) time.sleep(5) return None这段代码演示的是“上传参考图、发起任务、轮询结果”的通用流程。不要把其中出现的示例域名或字段名称当作真实接口定义具体字段名和回调方式要按实际 API 调整。4.2 评估维度视频生成不能只看单张画面建议从四个维度打分角色一致性前后帧中角色脸型、发色、服装是否一致。动作幅度动作是否真正达到提示词要求的幅度。动作连贯性相邻帧之间是否流畅有没有跳帧或形变。画面质量清晰度、噪点、闪烁情况。每个维度可以按 1 到 5 分打分最后记录到表格。打分时建议由至少两个人独立看片后取平均避免单人主观偏差。4.3 测试结果记录表推荐用 CSV 保留原始记录case_id,prompt,seed,duration,resolution,char_consistency,action_range,motion_smoothness,visual_quality,notes A001,quick turn,42,4,1280x720,4,3,3,4,裙摆有轻微闪烁 A002,run right,43,4,1280x720,3,4,2,4,第五帧出现肢体扭曲记录时还要保存原始视频文件名和日志文件方便后续定位问题。不要只保存最终评分因为评分只能说明“好或坏”无法解释“问题出在哪一帧”。5. 本地部署 minmax h3 的落地路径5.1 什么时候才需要本地部署API 测试稳定后如果遇到以下情况才需要考虑本地部署视频数据包含敏感信息不能上传到外部服务。线上接口成本过高批量生成任务量大。需要深度定制模型后处理流程。本地部署不是必须的。如果只是阶段测试继续用 API 效率更高。很多项目从 API 切换到本地部署时最先遇到的不是模型效果问题而是推理资源不足导致的性能回退。5.2 本地部署的一般步骤本地部署 H3 模型并没有固定模板需要按官方发布包操作。通用过程如下确认模型仓库文件从指定的模型来源下载权重至少包含模型配置文件、权重文件和推理脚本。准备 Python 推理环境安装 PyTorch、transformers、diffusers 或其他依赖。加载模型使用脚本或 pipeline 加载权重到 GPU。执行推理传入提示词和参考图生成视频。保存结果并清理显存。以 diffusers 风格代码为例但要注意 H3 未必支持该库。import torch from diffusers import DiffusionPipeline pipe DiffusionPipeline.from_pretrained(./models/h3) pipe.to(cuda) result pipe( prompt一个甜美风格的女孩快速转身, num_frames32, height720, width1280, seed42, ) result.frames[0].save(output.mp4)这段代码只是用于说明思路真正落地时依赖包名、模型目录和接口参数都要以模型发布说明为准。如果直接照搬很可能因为缺少依赖或参数不一致而报错。5.3 显存、推理时长和并发控制本地部署最容易低估的是推理资源消耗。视频生成是逐帧扩散模型一张 720p 的图已经需要较大显存视频相当于多帧联合生成显存占用会成倍增长。建议先做一次资源摸底项目建议显存24GB 起步大模型建议 40GB 以上磁盘预留 200GB 以上保存权重和缓存单次推理以分钟级起步不建议在线实时调用并发本地单卡最多 1 到 2 个并发如果显存不足可以降低分辨率或减少帧数不要一开始就追求 4K。在实际项目中先把 720p 跑稳定再逐步提高画质比一开始就挑战最大分辨率更稳妥。6. 测试中的常见问题与排查思路6.1 大动作场景下肢体扭曲现象当角色快速转身或跳跃时某几帧手臂或腿部明显变形。原因大动作情况下运动幅度过大模型对中间帧的预测不稳定。排查先降低动作强度改成中动作测试再对比不同 seed最后调整提示词补充动作细节。处理将“快速转身”改成“缓慢转身然后快速甩头”把动作拆成多个阶段模型更容易理解。这种写法在视频生成测试里很常见本质是降低生成器的预测难度。6.2 生成速度慢或超时现象API 调用长时间无返回或本地推理占用全部显存后进程被杀。原因视频生成任务本身耗时较长本地显存不足导致 OOM。排查nvidia-smi dmesg | tail -20如果出现CUDA out of memory需要降低分辨率、减少帧数或换更大显存显卡。如果是 API 超时先查看接口返回的错误码和日志不要反复重试相同参数。6.3 本地部署加载模型失败现象from_pretrained报错提示缺少配置文件或权重文件不完整。原因下载中断、版本不匹配、依赖库版本不对。排查检查目录里是否有config.json、模型权重文件、分词器文件确认所有依赖版本与模型要求一致。常见错误是 PyTorch 版本和 CUDA 版本不匹配导致模型加载到一半就崩溃。6.4 多场景生成不一致现象同样角色在不同场景中形象漂移。原因模型只通过参考图约束外观对复杂动作场景中角色身份保持能力有限。处理固定参考图使用相同风格后缀。如果接口支持风格描述可以加入“同一人物”约束提示。例如在提示词末尾统一加“保持角色外观一致”作为固定后缀能减少一部分随机漂移。7. 测试收尾与后续扩展建议7.1 当前阶段可以得出的结论从当前测试来看H3 对固定角色“甜美款南宫阙”的中低动作场景表现稳定基本满足小场景内容生成需要。大动作生成仍是下一阶段重点需要继续投入用例设计和评估。7.2 后续大动作生成场景的扩展方向下一步可以尝试的方向包括舞蹈动作组合连续旋转、踢腿、挥臂。运动镜头推近、拉远、跟随人物移动。多人交互角色与道具、角色与角色之间的动作衔接。局部动作控制通过遮罩或关键帧引导模型。每种方向都需要单独建测试集不能靠一两个 prompt 下结论。建议下一阶段建立“动作词库”把常用动作动词拆成“动作主体 动作类型 动作幅度 镜头配合”四个部分方便批量生成对比视频。7.3 可复用的测试检查清单发布或继续测试前按这个清单过一遍提示词是否包含角色固定信息、动作描述、镜头描述。测试参数是否统一记录。是否保存原始视频和日志。是否对比至少 3 个 seed。是否检查角色一致性、动作幅度、连贯性、画质四个维度。本地部署前是否确认 GPU 显存和磁盘空间。是否保留一份接口调用失败截图和错误日志。这个清单也可以作为后续新增测试用例的准入标准一条用例如果连记录表都没有就不应该进入正式评估。当前 H3 测试刚结束一个阶段接下来真正有价值的不是继续堆数量而是把“大动作生成”场景的 prompt 设计、评估标准和部署方案沉淀成一套可持续复用的流程。