图像转视频与文本转视频接入评测指南

本文是一份面向接入与评测的工程指南，适合开发者、运维人员和技术负责人使用。它既适用于把视频生成能力接入自有系统、评测平台或内容生产流程，也适用于为模型上线建立可复现、可验证的验收标准。如果读者只关心概念，可重点阅读“接入前如何选择任务模式”“如何配置提示词与参数”和“总结”；如果需要落地实现，建议按照“环境准备—接口调用—结果验证—问题排查”的顺序完成。

一、接入前如何选对任务模式与能力边界？

图像转视频和文本转视频是两类常见任务，接入前必须先确认业务使用的是哪一种。

图像转视频适合已有静态图片、产品图、海报、分镜图或角色图的场景。输入通常是图片，输出是带动态变化的视频。它适合做产品展示、图片动效、广告素材扩展和分镜预演。

文本转视频适合直接从提示词生成内容的场景。输入是结构化提示词，输出是画面与音频组合的视频。它适合做短视频脚本预演、创意验证、批量素材生成和自动化内容生产。

接入前需要确认模型或服务的能力边界，包括是否支持原生音频、是否支持5至15秒时长、是否支持720P或768P级输出、是否支持图像与文本混合输入、是否支持负面提示词、是否支持固定随机种子。

这里需要规范说明“768P”。本文所称768P级输出，指输出画面高度约为768像素，或平台文档中定义的768P档位。不同服务可能采用768×1280、768×1344或其他画幅，具体应以服务方接口文档为准。若服务只支持720P，应在配置和验收标准中明确改为720P，避免口径不一致。

二、怎么搭建最小可运行推理环境？

为了让接入步骤可执行，下面给出一个最小可运行环境示例。该示例以本地HTTP推理服务为核心，模型后端可替换为贵司自研模型或开源模型。

推荐基础环境如下：

• 操作系统：Ubuntu 22.04 LTS
• Python：3.10.12
• GPU：NVIDIA A10、L20、A100或其他支持CUDA的显卡
• GPU驱动：535.104.05或同系列稳定版本
• CUDA Runtime：12.1
• 深度学习框架：PyTorch 2.2.2
• Web服务框架：FastAPI 0.110.0
• ASGI服务器：Uvicorn 0.29.0
• 数据校验：Pydantic 2.6.3
• 异步任务队列：Redis 7.2.5
• 对象存储：MinIO、S3兼容存储或自建存储
• 示例服务名：video-gen-service
• 示例模型名：demo-i2v-v1。若仅验证接口链路，可先用占位模型；正式评测必须替换为真实模型。

示例服务提供以下接口：

1. 健康检查：GET /healthz
2. 创建任务：POST /v1/video/tasks
3. 查询任务：GET /v1/video/tasks/{task_id}
4. 下载结果：GET /v1/video/tasks/{task_id}/result

鉴权方式示例为Bearer Token。开发环境可从环境变量读取：

VIDEO_API_TOKEN=dev-token-123

调用时需要在请求头中携带：

Authorization: Bearer dev-token-123

生产环境建议使用JWT、OAuth2、内部签名或网关统一鉴权，不应将长期密钥写入代码仓库。

三、如何提交并轮询视频生成任务？

视频生成任务耗时较长，不建议用完全同步接口处理。推荐采用异步任务模型：

1. 客户端提交任务；
2. 服务返回任务ID；
3. 推理任务进入队列；
4. 客户端轮询状态或接收回调；
5. 生成完成后结果上传对象存储；
6. 客户端下载视频或获取访问地址。

创建任务示例：

curl -X POST http://127.0.0.1:8080/v1/video/tasks \
-H “Authorization: Bearer dev-token-123” \
-H “Content-Type: application/json” \
-d ‘{
“mode”: “image_to_video”,
“image”: “s3://input-bucket/product.png”,
“prompt”: “白色产品盒缓慢旋转，柔和光线，正面固定镜头，轻微推进，画面稳定”,
“negative_prompt”: “闪烁，结构变形，低清晰度，画面抖动，文字乱码”,
“duration_seconds”: 8,
“resolution”: “768p”,
“with_audio”: true,
“seed”: 42
}’

查询任务示例：

curl -X GET http://127.0.0.1:8080/v1/video/tasks/task_20240601_001 \
-H “Authorization: Bearer dev-token-123”

客户端设计建议：

• 轮询间隔建议设置为5秒至15秒，避免高频请求；
• 对网络错误和服务端5xx错误进行有限重试；
• 对参数错误不应重试，例如非法分辨率、空提示词、超长时长；
• 任务必须支持幂等，避免重复提交导致重复计费；
• 失败任务应进入死信队列或异常队列；
• 结果文件应写入对象存储，并设置访问有效期。

四、怎样配置提示词与参数？

视频生成模型对提示词结构化程度较敏感。建议不要写成长段自然语言，而是拆成固定字段。

推荐提示词结构：

主体：需要出现的对象或角色；
动作：对象如何运动；
镜头：推进、拉远、环绕、固定等；
环境：场景、背景、空间关系；
光线：自然光、室内光、柔和光、轮廓光等；
风格：写实、插画、动画、电影感等；
节奏：缓慢、稳定、快速切换等；
音频：环境音、拟音、背景音乐、语音描述等；
负面约束：不希望出现的元素或缺陷。

示例：

主体：白色产品盒；
动作：缓慢旋转；
镜头：正面固定镜头，轻微推进；
环境：简洁桌面，浅灰色背景；
光线：柔和侧光；
风格：商业产品展示；
节奏：稳定；
音频：轻微环境音，无音乐；
负面约束：文字乱码，结构变形，闪烁，低清晰度。

提示词对照案例：

原始提示词：“产品旋转，背景简洁。”

常见问题：主体容易漂移，镜头运动不明确，背景可能出现闪烁，生成结果不稳定。

结构化后：“主体为白色产品盒，动作是缓慢旋转，镜头为正面固定并轻微推进，环境为浅灰色桌面，光线为柔和侧光，风格为商业产品展示，节奏稳定，音频为轻微环境音，负面约束为闪烁、结构变形、低清晰度。”

这种写法有助于提升提示词遵循度，也便于后续做批量评测和效果对比。

参数配置建议：

• mode：image_to_video或text_to_video；
• prompt：正向提示词；
• negative_prompt：负面提示词；
• duration_seconds：建议5至15秒；
• resolution：720P或768P；
• with_audio：是否生成原生音频；
• seed：用于复现和对比；
• timeout_seconds：长任务应适当增大；
• max_retries：建议从2开始；
• batch_size：建议从1开始；
• max_concurrency：根据GPU显存和耗时设置。

参数与资源消耗的经验关系可参考下表。以下数值为经验值，具体取决于硬件、模型、分辨率、时长、音频开关和并发配置：

配置场景 | 显存占用参考 | 单任务耗时参考 | 成本风险
720P、5秒、关闭音频 | 8GB至12GB | 20秒至60秒 | 较低
720P、10秒、开启音频 | 12GB至20GB | 40秒至120秒 | 中等
768P、10秒、开启音频 | 16GB至24GB | 60秒至180秒 | 较高
768P、15秒、开启音频 | 20GB以上 | 90秒至240秒 | 高

五、如何验证结果并建立可核验验收标准？

结果验证应覆盖服务健康、单条样例、批量评测和性能压测。

基础健康检查：

• 健康检查接口是否返回成功；
• 模型是否完成加载；
• GPU显存是否正常分配；
• 对象存储是否可读写；
• 日志是否可写入；
• 监控指标是否上报。

单条样例验证可使用固定输入完成一次生成，并检查任务是否成功、视频时长是否符合预期、分辨率是否符合预期、是否包含音轨、音频是否与画面匹配、是否存在黑帧或花屏。

推荐使用通用媒体检查工具进行可核验检查。例如使用ffprobe检查视频流：

ffprobe -v error -select_streams v:0 \
-show_entries stream=width,height,avg_frame_rate,duration \
-of json output-video.mp4

检查音频轨：

ffprobe -v error -select_streams a \
-show_entries stream=codec_name,sample_rate,channels \
-of json output-video.mp4

批量评测建议固定样例集，避免每次随机提示词导致结果不可比较。人工评分可包括提示词遵循度、画面美学、主体一致性、动作自然度、音频质量、负面约束遵守情况。自动检查可包括视频时长、分辨率、音轨、解码状态、黑帧比例、文件大小、任务成功率、平均耗时和P95延迟。

验收标准示例如下，具体阈值应结合业务和硬件调整：

• 基础任务成功率不低于98%；
• P95生成耗时不高于180秒，具体取决于GPU、模型、时长、分辨率和音频开关；
• 分辨率匹配配置的任务比例不低于99%；
• 开启音频的任务必须包含有效音轨；
• 黑帧比例低于0.1%，特殊场景可另行约定；
• 高频提示词场景的人工语义遵循评分不低于内部基线；
• 失败任务可自动重试，重试仍失败后进入异常队列；
• 所有生成结果均可追踪到任务记录、请求参数和日志。

六、怎么排查常见问题？

1. 任务失败并提示显存不足

可能原因包括分辨率过高、时长过长、并发过高、批处理过大、多个任务同时占用显存。排查时可降低分辨率、缩短时长、将并发调整为1或2、将批处理降为1，并增加显存监控与告警。

1. 生成视频不包含音频

可能原因包括未开启音频参数、模型不支持原生音频、结果文件编码异常、下游转码丢失音轨。排查时使用ffprobe确认音轨是否存在，检查请求中with_audio是否为true，并对比开启音频与关闭音频的任务差异。

1. 音画不同步

可能原因包括音频描述过多、音频与画面节奏冲突、长任务帧率不一致、转码时间戳异常。排查时可缩短视频时长、简化音频描述、固定随机种子对比多次结果，并检查转码参数。

1. 提示词遵循度不足

可能原因包括提示词过长、多个主体或动作冲突、正面描述与负面约束矛盾、缺少镜头和光线信息。排查时使用结构化提示词，拆分主体、动作、镜头、环境、光线、风格和音频，并固定随机种子进行对比。

1. 画面闪烁或结构错误

可能原因包括输入图片质量不足、运动幅度过大、分辨率与显示尺寸不匹配、模型场景不稳定。排查时使用更清晰输入图片、降低运动复杂度、缩短时长、使用固定镜头，并对同一输入多次生成后选择稳定结果。

1. 任务长时间排队

可能原因包括并发过低、队列堆积、单任务耗时过长、推理资源不足。排查时检查队列长度，增加推理副本，将普通任务与高优先级任务分队列，并对长任务设置独立超时。

1. 成本异常升高

可能原因包括高分辨率任务占比过高、长时长任务过多、失败重试过多、结果文件长期占用存储。排查时按分辨率、时长、音频开关统计成本，对失败任务设置最大重试次数，对结果文件设置生命周期，对高频重复请求启用缓存。

七、上线前如何做灰度、优化与合规？

评测完成后不建议直接全量上线。建议先进行灰度发布：小流量开放、观察失败率和显存使用率、收集真实提示词分布、调整模板和超时配置，再逐步扩大流量。灰度期间应保留回滚机制，出现显存溢出、任务堆积、质量下降或成本异常时及时回退。

性能优化可从异步队列、模型预热、结果缓存、合理轮询间隔、短任务独立队列等方向入手。质量优化可建立固定提示词模板、维护最佳样例、定期回归评测。稳定性优化可设置最大重试次数、区分网络错误与服务端错误、保留完整日志和请求快照。

安全与隐私方面需要特别注意：输入图片可能包含个人信息、人脸、肖像或敏感场景。接入方应确认已获得授权，对输入图片和提示词进行内容审核，对生成结果进行安全检测，对访问密钥进行权限收敛，对结果文件设置访问有效期，对日志和敏感提示词进行脱敏，并按合规要求保存和删除数据。

八、总结

本指南的核心不是简单调用一次视频生成接口，而是建立一套可复现、可观测、可评测、可扩展的视频生成服务。实践中应重点关注：明确图像转视频与文本转视频的任务差异；固定推理环境、依赖版本和运行参数；采用异步任务队列处理长耗时生成；使用结构化提示词提升遵循度；根据业务优先级分级配置分辨率、时长和音频能力；建立质量、性能、成本和稳定性的评测闭环；针对显存、超时、音画同步和成本异常建立标准排查流程。完成上述步骤后，团队可以将视频生成能力稳定纳入内容生产、模型评测和自动化流水线中，为后续更高并发、更复杂场景和更精细的成本控制打下基础。