部署 Kandinsky 视频生成前先算吞吐

假设你的产品经理希望在应用里加入“生成一段带声音的短视频”功能。Kandinsky 6.0 是一个候选方案：Kandinsky Lab 于 10 月 6 日在 GitHub 上发布了它，代码和权重均采用 MIT 许可证。输入文本，或者文本加图片，就能输出一段 5 秒的视频，并配上匹配的音轨。它有两个规格：Lite 的参数量为 3B，Pro 为 29B（参数是模型内部通过训练学到的数值，可以粗略衡量模型的规模）。真正棘手的是任务调度、硬件，以及一项缺失的测量数据。

本文所有数字都来自 Kandinsky Lab 的代码仓库和模型卡，我们在 Kandinsky 6.0 单条视频成本分析中对它们做了汇总。我们没有实际运行模型，也没有看过它生成的内容，因此本文不评价生成质量。

把它当作批处理任务

Kandinsky Lab 的耗时表测量的是标准版模型。这些模型要经过 50 轮迭代，将随机噪声逐步去噪成画面。计时在预热运行之后进行，不包含模型加载和文件写入：

每条视频需要 5 到 45 分钟，这显然不适合做成同步 API 调用。仓库中使用 vLLM-Omni（通过 HTTP 提供模型服务的服务器）部署 Pro 的指南，已经采用了批处理模式：提交视频任务，拿到 ID，轮询状态，再下载结果。沿用这个流程，按每小时能生成多少条视频来规划容量，而且实际吞吐量要预期低于表格对应的水平，因为被排除在外的耗时从未得到量化。

显存更多，生成反而更慢

RTX PRO 6000 配备 96 GB 显存，比 H100 多 16 GB，但生成同一条 Pro HD 视频需要 561 秒。

模型的下载体积解释了其中的原因。Pro 在磁盘上约占 90 GB，其中约 70 GB 属于生成视频帧的组件。因此，随项目提供的所有 GPU 预设都启用了 offload：权重保留在主机 RAM 中，生成视频时再分批复制到 GPU。H100、A100 和 RTX PRO 6000 的预设使用 module 模式，每次搬运一整个组件。消费级显卡则使用 block 模式，在 GPU 上保留帧生成器的两个分块，同时复制下一个分块。CLI 虽然提供了 --offload none 参数，但没有任何预设使用它，而且 vLLM-Omni 指南明确表示，80 GB 显卡“必须”使用 offload。

这会从两个方面影响你的机器配置：首先，主机 RAM 成了必需资源，但官方没有公布最低容量要求；其次，这张表无法区分 GPU 计算速度和数据复制开销。每一行都启用了 offload，没有任何一行是在模型完全驻留显卡的情况下运行的，而且只有 H100 使用 FlashAttention 3，其他显卡使用的都是 SageAttention。这两个库都用于 attention，也就是模型建立视频各部分之间关联的计算步骤。我们认为 H100 的优势来自芯片本身的计算速度，但表中没有任何测量能够证明这一点。至于那些暗示相反结论的显卡对比，我们在 H100 与 RTX PRO 6000 的 offload 分析中做了讨论。

默认模型没有耗时数据

所有预设，以及 Hugging Face 上的公开演示，加载的都是蒸馏版 Pro：这个版本经过训练，只需 10 轮迭代就能生成成片，而不是 50 轮，体积也从约 90 GB 缩小到约 81 GB。但耗时表完全没有覆盖它。迭代轮数变成五分之一，很容易让人直接填上“提速 5 倍”；在有人实际测量之前，先把这一格留空。

性能分析默认关闭；复制一份预设，再追加一个配置块，就能开启：

cp kandinsky/configs/devices/rtx-5090.yaml my-5090.yaml
printf 'profile:\n  mode: time_mem_module\n' >> my-5090.yaml
just generate "a cat on a mat" --config my-5090.yaml --warmup --out clip.mp4

使用 --warmup 后，第一次生成会被丢弃，只对第二次生成计时，这与耗时表的测量方式大致相同。性能分析包裹的是整个 pipeline 调用，因此 total_time 还包括 MP4 编码、将音轨合入视频，以及 Qwen2.5-VL 编码器默认执行的 prompt 改写。耗时表则排除了编码时间。因此，应当比较各组件的耗时：DiT（帧生成器）、video VAE 和 audio VAE（将结果解码为视频帧和声音），以及 vocoder（将其转换为波形）。

Full HD 会丢掉音轨

视频生成分辨率为 864 × 480。一个独立的超分辨率模型会逐个图块重绘细节，将视频放大到 Full HD。与生成视频相比，这一步的成本不高：在 H100 上，它的 2 步版本完成 2 倍放大需要 41 秒，4 倍放大需要 118 秒，测量所用输入的尺寸略小于基础视频。它只处理视频帧，因此你的任务流程必须把原始生成结果中的音频重新合入。官方没有提供它在消费级显卡上的耗时数据。

正式投入前的检查清单

用同一组 prompt 分别运行 Lite 和 Pro，再比较结果。Pro 占用的 GPU 时间是 Lite 的 1.4 到 2.8 倍，但我们读过的资料都没有说明，多花这些时间究竟能换来什么。

在你自己的 GPU 上，对默认的蒸馏版逐个组件进行性能分析。

检查 Hugging Face 对非蒸馏版 Pro 设置的访问门槛：申请会自动获批，但条款只有登录后才能看到，我们尚未阅读这些条款。

Kandinsky Lab 构建了模型、超分辨率模型、预设和耗时表，并提供了一份技术报告。它们基于 Alibaba 的 Qwen2.5-VL、OpenAI 的 CLIP、Tencent 的 HunyuanVideo 解码器设计、MMAudio、NVIDIA 的 BigVGAN、π-Flow 蒸馏方法、FlashAttention 3（Tri Dao 及其合作者）和 SageAttention（清华大学 thu-ml 团队）。Diffusers、ComfyUI、vLLM-Omni、SGLang 和 FastVideo 在发布当天就提供了支持，社区账号 realrebelai 也发布了面向小显存显卡的实验性压缩版 Pro。我们所做的，是阅读仓库并计算这些数字。

七款 GPU 的耗时、文件体积、配置方法，以及所有已知限制，都收录在 InferenceKey 关于 Kandinsky 6.0 有声视频的文章中。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报其滥用行为。