不同任务需要不同服务类型
创意预览需要较短等待时间。动作迁移需要在更长的输出中保留源素材的动作表现。高分辨率视听请求可能同时占用多张 GPU。优化这些服务，需要综合决定精度、注意力、显存常驻、并行方式、编译和质量。
ProsGrow 在一台配备八张 RTX PRO 6000 Blackwell GPU 的节点上评估了这些服务类型。MiniMax-H3 对比中，在相同八张 GPU 上执行相同 BF16 Turbo 请求，服务端推理从 19.392 秒降至 8.913 秒，即延迟降低 54.0%。独立的 Wan 和 Animate 研究展示了交付时限、总需求与质量要求如何改变适合采用的配置。
我们的方法是明确工作负载约定，分析瓶颈，对比候选运行方案，并验证最终结果。这些研究将每项实测提升与相应的资源和质量限制联系起来。
MiniMax-H3：延迟、显存与质量
MiniMax-H3 暴露了在 PCIe 节点上分布大型视听工作负载的开销。改变并行任务的划分方式后，在相同八张 GPU 上，服务端推理由 19.392 秒降至 8.913 秒：相同 BF16 Turbo 请求的延迟降低 54.0%。
张量并行与序列并行产生不同的通信和显存需求。受控测量支持了该工作负载的通信开销有所降低这一判断，但没有可用的内核跟踪在内核层面确立原因。所选低延迟配置占用约每 GPU 84.2 GB；留有更多显存余量的配置则付出了延迟代价。
上游 SGLang MiniMax-H3 软件栈提供模型服务与并行机制的基础组件。ProsGrow 的贡献是在这套硬件上评估其表现，并围绕服务目标选择配置。
另一项独立的近似计算实验复用了中间计算结果，将服务端推理从 8.913 秒降至 7.092 秒，进一步降低 20.44%。API 完成时间从 10.045 秒降至 8.040 秒，仍由全部八张 GPU 处理一个请求。解码耗时基本不变。
这一额外增益具有不同的验收条件：近似计算需要质量门槛。所选候选方案在一个场景上通过了有限的数值一致性检查。这为候选运行方案提供了证据，但不能证明广泛的感知质量等价，也不代表适用于所有客户工作负载。
Wan2.2：受控的四步对比
| 指标 | 蒸馏 BF16 基线 | 所选 LightX2V 配置 |
|---|---|---|
| 热态流水线 | 22.164 s | 9.062 s · 降低 59.1% |
| 去噪 | 19.164 s | 6.076 s |
| VAE 解码 | 约 2.37 s | 约 2.36 s |
所选路径结合了降低精度、稀疏注意力和 GPU 常驻。这些能力来自上游 LightWan2.2 模型及 LightX2V 运行时，其中包括量化感知步数蒸馏。ProsGrow 集成并验证了执行路径，建立本地对照，并测量由此带来的服务权衡。
一次标准的 40 步 BF16 运行耗时 357.640 秒。与这一参考值的差异很大程度上来自上游步数蒸馏。四步 BF16 对照测得了额外 2.45× 的综合运行时增益，与步数蒸馏本身的收益分开计算。
精度、注意力与显存常驻相互影响
优化机会跨越了执行路径的多个层次：
- 精度与注意力：更小的数值表示和稀疏注意力减少了去噪工作量。二者的综合收益取决于模型及受支持的执行路径；仅改变格式并不能保证服务更快。
- GPU 常驻：更小的专家权重可以保留在 GPU 显存中，从关键路径中移除主机到设备的数据传输。显存节省既改变了计算的位置，也改变了所需算术运算量。
- 流水线平衡：解码保持在约 2.36 秒。随着去噪加快，这个基本未变的阶段在请求中占比越来越大，限制了进一步优化去噪器所能带来的收益。
- 热态与冷态服务：优化后的独立进程总耗时 72.12 秒，包含模型加载、预热和关闭。因此，较短的热态推理耗时依赖于能够管理启动工作与常驻状态的服务。
受控结果测量的是这些变化的整体效果，并未为每一层分配独立的因果加速比例。因此，优化既需要分阶段计时，也需要端到端交付边界。
一次同步节点测试显示各 GPU 的热态延迟相近。按最慢完成时间换算，这一预览约定对应约每小时 3,138 个片段。这是由一轮实测换算的容量，并非持续一小时的 API 测试。质量同样限制了结果：生成构图存在差异，尚未建立感知等价性。
Animate-2：异步服务的吞吐量
Animate-2 根据参考图像和源视频生成 11.21 秒的动作迁移视频。这类较长任务适合放入异步队列，其中已完成输出和单任务能耗，比交互式预览的交付时限更重要。
ProsGrow 将经过验证的 FP8 执行路径与持久化编译缓存结合。复用已编译代码减少了重复启动工作，精度则改变了稳定执行阶段的成本。两者都在该服务采用的完整启动边界内测量。
| 指标 | BF16 基线 | FP8 + 编译缓存 |
|---|---|---|
| 节点输出速率 | 24.382 个输出/小时 | 28.678 个输出/小时 · +17.62% |
| 整节点平均功耗 | 6.581 kW | 6.575 kW |
| 每个输出的能耗 | 0.270 kWh | 0.229 kWh |
服务器功耗几乎不变，而吞吐量提高，使每个输出的能耗降低约 15.1%。所选配置仅留下约 4 GiB GPU 显存余量，因此输出尺寸和并发工作成为重要的部署约束。
编译缓存也是需要运维管理的产物：硬件、运行时、模型形状或编译设置变化时，必须进行版本管理或重建。有价值的结果应把这一生命周期决策与吞吐量和视觉回归检查一起考虑。
根据客户需求选择运行方案
使用整个节点可以缩短单个请求的时间。将容量划分为更小的副本，可以在总体上完成更多独立任务。另一项 MiniMax 研究采用上游模型剪枝和 Turbo 适配器，由一轮同步测试得到每小时 478.14 个片段的速率，每个请求约 30.1 秒。其模型和服务形态发生了变化，需要独立质量评估。
| 服务类型 | 主要目标 | 需要持续考虑的约束 |
|---|---|---|
| 交互式预览 | 较短的请求完成时间 | 热态常驻、排队和可接受的视觉变化 |
| 总体生成吞吐 | 每个节点通过验收的片段数量 | 副本显存、单请求等待和质量 |
| 异步动作迁移 | 已完成任务与每个输出的能耗 | 编译生命周期、显存余量与源素材保真度 |
这些目标之间不存在一个始终胜出的设置。有价值的结果是一组经过测量的选择，体现延迟、吞吐量、显存、能耗和质量之间的权衡。这些研究提供了选择服务类型所需的证据；后续客户试点还必须在代表性媒体素材上验证输出验收、排队和交付时限。
方法与局限
| 研究 | 输出约定 | 测量边界 |
|---|---|---|
| Wan2.2 / LightWan2.2 | 81 帧、832×480、16 FPS、5.0625 s；受控提示词和种子 | LightX2V；预热后的同步流水线，计时至编码/保存；不含模型加载和预热 |
| Wan2.2 Animate-2 14B | 269 帧、713×1264、24 FPS、11.2083 s，源音频；相同参考媒体，四个片段 × 十步 | LightX2V；完整启动的实际耗时，所选结果已填充编译缓存 |
| MiniMax-H3 FL2VA Turbo | 1344×768、124 帧、24 FPS、文件时长 5.175 s，生成音频；相同提示词和种子，观测到四次去噪器计算 | SGLang；分别测量服务端推理与完整 API 完成时间 |
- 硬件与重复测试：一台配备八张 RTX PRO 6000 Blackwell GPU 的节点，每张 GPU 标称显存 96 GB。Wan 每个工作进程记录一次热态生成测量。Animate 所选速率取两次节点运行中较慢的一次。每个 H3 延迟候选方案执行一次预热和一次实测请求；副本速率来自一轮同时运行。这些短时研究不能确立持续负载 SLA 或延迟百分位数。
- Wan 质量：通过缩略图拼版审阅发现片段整体连贯，但在唯一测试场景中，标准 40 步参考结果对提示词字面要求的遵循更清晰。蒸馏、稀疏和精度变化不能证明感知等价性。
- Animate 质量：全部 269 帧均与 BF16 对比，得到 SSIM 0.9534 和 PSNR 31.74 dB。这些是针对单个输入的视觉回归检查。
- H3 质量：所选近似方案相对参考结果的 SSIM 为 0.8128，略高于本地各并行配置中观测到的 0.8102 下限。这次数值检查不能取代针对多个提示词的动作、提示词遵循、音频同步或人类偏好评审。独立的剪枝模型吞吐量研究相对其原始模型参考结果的 SSIM 为 0.8815。
- 归因与计时：上游模型和运行时提供优化的基础组件。组合调整并未隔离每个组件的影响。H3 服务端推理不含客户端轮询和下载；对比时必须区分 8.913 秒的服务端结果与 10.045 秒的 API 结果。
Wan 测量于 2026年8月12日至18日进行，MiniMax 后续测试于 2026年9月1日至2日进行。结果适用于所述媒体和输出约定。
私有 MiniMax-H3 与 Wan 视频生成
对于使用 MiniMax-H3 或 Wan2.2 的私有视频生成，部署时首先要明确服务更看重快速预览，还是一段时间内完成的任务量。服务器推理延迟、完整 API 响应完成时间和生成吞吐量描述的是不同的测量边界。客户评估时，应始终将输出尺寸规格、源媒体和可接受的视觉变化与每项结果一同考虑。