图像、视频与音频模型

核验日期：2026-11-04。这是面向远端自部署的主流候选目录，覆盖不同地区的主要开放模型家族，不是全球统一排名。 本文核查了发布方模型卡、权重目录、许可证和推理文档；没有下载模型权重、执行推理、调用付费 API，表中的路径不代表目标机器已经验收。

入口见 知识库首页，框架、部署分层及通用验收口径见 推理技术栈选型，文本与视觉理解模型见 语言模型目录。 这里重点回答“实际开放了什么、能生成什么、从哪里开始验证”，再给出媒体任务特有的速度与并发测法。

阅读口径

• 主候选：值得进入当前选型池的具体开放版本；不表示它在所有任务、硬件和许可证条件下最优。
• 专项候选：面向分层编辑、角色动画、全双工语音等特定用途，不能直接替代通用生成模型。
• 生态参考：适合复用成熟工作流、插件、适配器或复现实验；保留它们不等于称其为最新旗舰。
• 已核推理入口：发布方或框架方提供了对应模型的代码、示例或配方。未逐模型确认的其他框架支持，均属于待核对候选。
• 开放权重与开源许可分开：研究许可、非商用许可、社区许可也可能允许下载权重，但不等同于 Apache-2.0 / MIT；以下仅摘录关键范围，实际按所选产物及其组件许可证核对。

图像生成与编辑

当前主候选

这里的“5.6B”“7B”等宣传口径可能仅指视觉主干，完整部署还要计算文本/视觉编码器、VAE、提示词增强器和工作区。 例如 FLUX 3 Image Klein 模型卡明确把图像 Transformer 与文本编码器分开；不能据主干大小直接承诺单卡显存或并发。官方组件说明

Qwen-Image-2.1-Turbo 的采样时间表随检查点保存，模型卡明确说明仅修改步数字段不一定覆盖它；应按相同采样配置比较质量与速度。 Z-Image-Turbo 的示例调用步数与实际 DiT 前向次数也不完全相同，测试记录应同时保存调度器、步数和实际前向次数。Qwen Turbo 配方、Z-Image-Turbo 配方

专项与成熟生态

保留旧生态的理由是现有资产、控制能力、产出稳定性和迁移成本，而不是仅比较一张演示图。 服务化时先用原厂或 Diffusers 路径建立质量基线，再比较已确认支持该检查点的 SGLang Diffusion、vLLM-Omni 或其他后端；框架有“图像生成”模块不代表已经支持新一代模型。

视频与联合音视频

当前主候选及重要专项

H3 的开放范围需要单独说明。 官方开放的是 H3-Base FL2VA / Ref2VA，纯本地基线为 768p。 H3-Context-IR 是托管前处理系统，H3-Regenerate-2K 也未随该开放版本提供；模型卡的完整 2K 流程会结合官方 API。 因此，“本地跑通 H3 Base”与“复现官方完整 2K 工作流”是不同验收目标。H3 模块与发布范围

Wan2.2 的开放权重与 Wan2.6 云视频 API也不能按名字互换。 本表按已读到的具体权重收录，不将云端更新的系列号自动当成可自部署版本。

蒸馏效率路线与旧生态

FastVideo 是推理/蒸馏工具链，FastH3 是其发布的具体产物；二者不能作为“模型量化选项”的同义词。 基础模型已做 CFG 蒸馏，也不等于任意少步蒸馏权重在全部输入任务上可互换。H3 Base 说明、FastH3 任务范围

语音识别与语音翻译

语音翻译输出的“文本译文”与“合成另一语言的声音”必须分开验收。 例如 Canary 的上述检查点输出文本，而 TTS 或语音到语音模型承担声音输出；不能把两段组合的效果写成单个 ASR 模型能力。Canary 输入/输出定义

Nemotron Transcribe 的模型能力与具体服务实现必须分开：上述 SGLang-Omni 配方暂不含时间戳、说话人归属、翻译和实时 PCM 输入，且披露了长录音重复至 token 上限的情况；完整任务验收优先按 NVIDIA 模型卡的原厂路径进行。不能把上传完成后的 SSE 文本增量视为实时听写。服务边界

语音合成

TTS 的“streaming”至少要拆为流式文本输入、流式音频输出和服务协议三个层面。 模型能逐块产声，但应用等全文完成才发送文本、等 WAV 完整封装才返回，用户仍会感到延迟。 首包快也不足以保证连续可播放：后续块间隔、分段断句、爆音、重复和漏读都要测。

实时语音对话与全模态输入

Qwen3.8-Omni 的云服务名称不等于已经存在对应公开权重；本页收录的是已核权重的 Qwen3-Omni。 云端非实时版本与实时版本的输出也不同，应按接口分别识别。Qwen 云 Omni 输入/输出说明

级联的 ASR → LLM → TTS 仍是可行工程路线，但须分别统计各阶段排队和计算时间。 端到端 Omni 也不自动消除传输、VAD、回声消除、播放缓冲和打断调度造成的延迟；“流式输出”与“全双工交互”不能合并成一个勾选项。

音乐、音效与后期配声

Music3 的 SGLang-Omni 服务虽复用 /v1/audio/speech，输入语义仍是歌词与音乐描述，不是普通 TTS；其 CUDA 串行 offload 模式一次处理一首，不能从接口并发数推断 GPU 同时生成量。Music3 服务与内存配置

给 Wan / HunyuanVideo 等结果再加 TTS、Foley 或音乐，并封装成带音轨的视频，是组合流水线。 H3、LTX-2.5、Kandinsky 6、MAGI-2 则有模型本身联合生成音视频的证据；最终写入容器文件的 mux 操作不改变这一模型层面的区别。 两种路线都可以评估，但口型、事件同步、人物声线连续性、修改单一音轨的成本应分别记录。

面向远端低延迟与高并发的测法

下面是建议的验收设计，尚无本项目实测数字；不能把发布方某张 GPU 的演示延迟转写为服务承诺。

图像与视频

1. 固定任务输入：图像尺寸、参考图数量；视频的分辨率、帧数/FPS、时长、首尾帧/参考素材、音轨和采样配置都入记录。
2. 分开计算原始输入上传、提示词处理、编码器、生成主干、图像/视频/音频解码、封装与结果下载的时间。
3. 用户侧记录请求发出至可用结果的 P50/P95；视频另记首个可播放片段和全片完成时间，预览帧不算完整结果。
4. 按并发逐级增加，记录排队、超时、OOM、取消后资源释放及后续请求恢复。用混合时长与长短任务混跑检查队头阻塞。
5. 质量验收包括文字正确、身份保持、动作/镜头连续、参考素材遵循；联合音视频另测口型、声音内容和事件同步。
6. 统计每 GPU 小时的合格图片数、合格视频秒数及成本。超分、补帧、提示词增强、失败重试的资源都纳入最终结果成本。

对短视频请求，优先检查哪些阶段真正占时；增加多卡切分可能降低单次生成时间，也可能占用更多卡而减少独立副本数。 比较“多卡处理一项任务”与“多个副本处理多项任务”时，应使用相同总 GPU 数和质量门槛，分别看单用户等待与总体合格吞吐。

ASR、TTS 与实时对话

这里统一 RTF = 生成/处理耗时 ÷ 音频时长，越小越快；若报告用其倒数，应另命名，避免混排。 TTFA 应区分服务端第一音频块、客户端收到首块、客户端真正开始播放，必要时同时报告。

真实会话按真实采样率持续送入音频，保留停顿、网络抖动和用户打断；离线文件瞬间送完的 batch 吞吐不能替代实时会话容量。 TTS 从已知全文生成与从 LLM 持续收到文本，是两个不同负载；将文本分块等待、声码器排队与网络播放一并统计。 若合成器速度快于实时，但某些用户持续缺块，应以用户可听的服务质量为限制，而不是继续提高平均吞吐。

语音链路的瓶颈可能落在音频解码/声码器阶段；分离阶段到不同 GPU 是实验选项，不是默认更优。 例如 Drama 3 官方报告专门对比声码器放置位置，但其 H200、输入预编码和并发条件只能作为实验线索，不能代替本机结果。Drama 3 测试条件

量化、缓存、蒸馏的媒体能力边界

LTX-2.5 模型卡明确标出某些 int8 文件仅供 ComfyUI，不能交给 ltx-pipelines 按普通 PyTorch 权重加载；NVFP4 也有对应内核和硬件路径。 同理，第三方 GGUF、FP8、NVFP4 只是某个发布者的具体转换/训练产物，不能继承另一个仓库的质量与速度结论。LTX-2.5 文件与加载说明

扩散中间特征近似缓存、稀疏注意力、量化和少步蒸馏改变的对象不同；任何组合都要重新验证质量，不能把单项加速倍数相乘。 语音模型还应关注 codec / 声码器精度与音频接缝，视频模型还应关注时序一致性，不能只验单帧或首段声音。

实际选型顺序

1. 先按输入/输出与许可筛选：文生图、编辑、无声视频、联合音视频、ASR、TTS、双工对话分别建任务集。
2. 每类选少量质量候选和速度候选：例如图像用 FLUX / Qwen / Z-Image 对照，联合音视频用 H3 / LTX / Kandinsky，语音按实际语言覆盖选 ASR 与 TTS。
3. 先固定原厂或正式支持入口作为质量基线，再替换框架、量化、缓存或蒸馏中的一个变量；已有官方加速检查点可作为独立候选。
4. 以目标远端硬件的合格吞吐、P95 等待、实时播放连续性和成本决定部署，保留原始请求、结果与失败样本。

后续更新应重查模型仓库的实际权重、任务清单、运行配方和 LICENSE，尤其留意模型卡中“计划支持”、自动生成示例与正文不一致的情况。 目录中的链接是本次证据入口；上线前应进一步固定权重 revision、组件版本与镜像版本，才能形成可复现的验收记录。