wan2.7-image-standard 上手指南：能力边界、API 参数与定价实践

这个模型解决什么问题，又不管什么

wan2.7-image-standard 是 Alibaba 提供的图像生成模型，输出类型为图像，能力范围明确落在两类任务上：文生图（text-to-image） 与 图生图（image-to-image）。换句话说，它擅长把一段文字描述转成一张图，或者在一张已有图的基础上做受控的再生成——这两条路径覆盖了大部分内容生产、素材补全与风格调整场景。

需要提前明确的是它不覆盖什么。图像编辑里的局部重绘（inpainting）、遮罩外扩（outpainting）、超分辨率放大、背景抠除等任务，都不在这两类能力之内；如果你的业务链路里这些环节占比很高，应当为它们单独选型，而不是指望用一个模型全包。视频生成、3D 资产生成同样不属于它的范畴。

因此接入判断可以简化为三个问题：

• 你的核心需求是不是「从文本或参考图得到一整张新图」？如果是，它属于候选。
• 你是否需要像素级的局部编辑能力？如果是，需另配模型。
• 你的下游是否对生成结果的尺寸、内容有严格约束？这决定了在图生图路径上要做多少预处理工作。

把边界想清楚再谈参数和成本，能避免「先接进来再发现用不上」的返工。

按张计费意味着什么

wan2.7-image-standard 采用按张计费的口径：每成功产出一张图计一次费用。这个口径本身很直观，但对预算的实际影响取决于你的调用策略，而不是单价本身。

关键变量有三个：

• 多候选图：如果你为同一个 prompt 请求多张候选再挑选，每张都计入成本。候选数翻倍，单次请求的成本也翻倍。
• 失败重试：超时、参数错误、内容被判不合规后的重试，只要产生了有效输出，就会累积成成本。工程上重试策略越激进，预算越难估。
• 灰度与压测：上线前的对比测试、A/B 实验都会真实产生图片。这部分往往被漏算进预算。

建立一个简单的成本模型：预估月成本 ≈ 日均有效请求数 × 平均每次请求产出的图数 × 30。这里的「平均每次请求产出的图数」要把候选图和重试的成功率折算进去，而不是理想情况的 1。

对于高频调用场景，建议在业务侧设置每日产出上限，并对同一 prompt 做结果缓存——相同输入短时间内重复请求在演示、回放、测试环境中非常常见，缓存能直接抹掉这部分开销。具体单价与最新计费口径请以站点价格面板为准，不要以本文或历史邮件中的数字做长期预算依据。

接入前的参数与调用清单

接入 HiAPI.ai 统一接口调用 wan2.7-image-standard，需要在联调前把输入输出口径固定下来，否则容易在细节上反复返工。

输入侧要确认的要素

• prompt 表达规范：先用目标语言的描述做基线测试，确认模型对长描述、否定句、风格词的实际反应，再决定是否做 prompt 模板化。团队内部最好维护一份 prompt 约定（主体、场景、风格、负面约束的顺序），减少个人写法差异带来的效果波动。
• 任务类型：显式区分文生图与图生图调用，图生图必须提供输入图像；不要把参考图混在 prompt 里靠文字描述替代。
• 尺寸与比例：确认模型支持的尺寸范围，并在业务侧固定几档常用比例（如竖版、方版、横版），避免每次请求都用任意尺寸，导致后续排版和存储逻辑复杂化。
• 输入图像的格式与体积：图生图路径上要明确可接受的格式、分辨率上限与文件大小，必要时在调用前做一次本地压缩或格式转换。

输出侧要确认的要素

• 返回结果的形态：是直接返回可访问的图像资源，还是需要额外下载落盘。这决定了你是否要在调用层封装一个「取图 + 存储」的函数。
• 结果有效期：如果返回的是临时链接，必须在有效期内完成转存，否则数据会失效；这一点务必在上线前实测。
• 错误与限流的返回结构：提前确认错误码字段，便于在客户端做分类处理，而不是把所有失败都当成同一种异常重试。

建议把上述要素写成一份接入 checklist，联调时逐项勾选，比事后排查要省时间得多。

图生图流程中的工程注意点

图生图比文生图多出一整段输入处理链路，工程复杂度也主要集中在这里。

输入预处理

参考图很少是模型能直接吃的理想素材。常见处理包括：统一为模型支持的格式、把分辨率调整到合理区间、必要时裁切到目标比例。预处理要在服务端完成并做好幂等，避免同一张原图被反复处理。同时建议保留原图与处理后图像的对应关系，便于效果回溯。

一致性校验

图生图的核心预期是「保留参考图的部分特征，同时按 prompt 做变化」。上线前需要定义什么算合格：主体是否保留、构图是否接近、风格偏移是否可接受。常见做法是抽样人工评估加一个轻量的自动指标（如与原图的相似度阈值）做初筛，把明显跑偏的结果拦下来，减少人工看的量。

输入内容的合规前置

参考图来自用户上传时，需要在调用模型之前做一次内容校验，避免把明显不合规的输入送进生成环节。这一层放在你的服务端比放在生成之后更省成本，也更符合业务流程。

元数据留存

每张生成结果建议记录：原始输入图标识、prompt、尺寸、模型名与调用时间。图生图的结果和输入强绑定，没有这层元数据，后续既难复现问题，也难做效果归因。

用对比压测决定它承担哪类任务

判断是否接入，不建议用「全量替换现有方案」的思路，而是把它放进候选模型池，按任务类型分组压测，看它在哪一类任务上性价比最高。

分组方式

按业务真实分布切分测试集，而不是用精心挑选的漂亮 prompt：

• 文生图：商品图、插画风素材、场景概念图等，按你的实际品类分组。
• 图生图：参考图占比、风格迁移幅度、主体复杂度各取几档。
• 难度分层：把简单描述、长描述、含具体文字要求、含复杂空间关系的描述分开统计。

评估维度

• 可用率：首轮结果无需修改即可使用的比例，这是最能反映真实成本的一项。
• 一致性：同一 prompt 多次调用结果的稳定程度，影响用户体验。
• 图生图保真度：参考图特征保留与 prompt 遵从之间的平衡。
• 端到端时延与失败率：决定是否需要异步队列。

组合结论

把模型结果与现有方案在同一测试集上对齐打分，通常会出现「某几类任务明显更好、某几类持平、少数场景不如现有方案」的分布。结论应写成任务分派规则：哪些任务路由到 wan2.7-image-standard，哪些保留原方案或另选模型。这样上线风险最小，也便于后续单独调整。

把图像调用纳入工程链路

模型效果只是上线的一部分，真正影响长期体验的是调用层的工程化程度。

重试与超时

为图像调用设置明确的超时上限，并按错误类型区分处理：网络类错误可指数退避重试，参数类错误直接失败并告警，不要重试。重试次数要有上限，并与成本监控联动——重试率异常升高通常是链路问题的早期信号。

异步与队列

图像生成耗时通常高于普通文本接口。面向用户的场景建议走异步：提交任务、返回任务标识、轮询或回调取结果，避免长连接被拖住。批量场景用队列削峰，并限制并发，防止瞬时流量触发限流而放大重试。

结果存储

生成结果必须在有效期内转存到你自己的对象存储，并记录元数据（prompt、任务类型、尺寸、模型版本、时间戳）。存储层建议做内容去重，相同输入的结果可复用，既省存储也省调用。

成本与质量监控

上线后持续跟踪三组指标：每日产出图数、失败与重试比例、人工返工比例。前两项对应成本，第三项对应质量。当返工比例上升而产出平稳时，往往意味着业务输入分布变了，需要重新评估 prompt 规范或任务分派规则。

把模型能力、按张计费的成本口径和工程链路放在一起看，接入决策就不再是一次性的效果对比，而是一套可持续运营的方案。需要查看模型参数细节与最新计费口径时，以 HiAPI.ai 的模型页与价格面板为准。