
Kandinsky 6.0 Video 落地 vLLM-Omni:服务层为开源模型带来了什么
- openai新OpenAI: GPT-6.1 Sol2026-09-2952智能
- anthropic新Anthropic: Claude Sonnet 5.52026-09-2856智能
- typesafe新TypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百万 tokens · 150 tok/s
- OpenAI新OpenAI: GPT-6 Luna2026-09-2238智能
- OpenAI新OpenAI: GPT-6 Sol2026-09-2248智能
- Anthropic新Anthropic: Claude Opus 5.52026-09-2258智能
- xAIGrok 4.72026-09-2146智能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 每百万 tokens · 126 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百万 tokens · 1202 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- OpenAIOpenAI: GPT-6 Astra2026-09-0453智能77代码
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241智能76代码
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245智能76代码
- AnthropicAnthropic: Claude Fable 5.12026-09-0153智能82代码
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 每百万 tokens · 52 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百万 tokens · 250 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72代码
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百万 tokens · 230 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845智能75代码
- obsidianQwen3.8 27B2026-08-1534智能68代码
今天早上 UTC 07:55,拉取请求 #8537 合并进了 vLLM-Omni,而它只做一件事:让 Kandinsky 6.0 Video 能够以服务形式运行。模型本身则在同一天从 Sber 的 Kandinsky Lab 成对登场——Kandinsky 6.0 Video Pro拥有 290 亿参数,Kandinsky 6.0 Video Lite拥有 30 亿参数——可依据文本提示或参考图像生成五秒片段,并配有同步的 44 kHz 音频,且包含唇形同步,代码、权重和 diffusers 集成全部采用 MIT 许可。而在今天早上之前,它还缺少一种方式,让它在推理服务器内部运行,而不是只能靠一次性的命令行。
这个区别比听起来更有价值,也正是它让本文成为一篇与那次发布分开的独立报道。一个你能在自己的显卡上运行的开放检查点,是一件研究成果;而一个配有服务端流水线、共享入口点和部署方案的开放检查点,才是你能放到队列后面运行的东西。本周的发布给了你前者。今天的合并是后者的开端。
实际合并的是什么
该 PR 基于检查点 kandinskylab/Kandinsky-6.0-Pro-5s-Diffusers,为 vLLM-Omni 添加了文本到视频与音频、以及图像到视频与音频功能。工程上的选择才是有意思的部分,因为它们能告诉你,当作者以外的人必须为它提供服务时,这个架构实际上是什么样子。
• 单个 DiT 同时对两种模态去噪。该 pipeline 注册为 Kandinsky6TI2VAPipeline,视频 latent 和音频 latent 由单个 transformer 联合去噪,而不是由两个模型按顺序运行。这与论文中的双流 CrossDiT 相呼应:预训练的视频流与从零开始训练的音频流通过双向交叉注意力相连。
• 权重按文件夹逐个加载。Hub 检查点以 transformer/、vae/、text_encoder/、text_encoder_2/ 和 audio_vae/ 的形式读取。已发布检查点的内部名称——videoT 和 audioT——会在加载时映射到 video_dec_block 和 audio_dec_block 上,这种细节要是自己发现,得耗掉一整天。
• 音频默认开启。该管线输出 44.1 kHz AAC,而不是将声音视为需要主动启用的标志,因此即使请求中没有任何音频参数,返回的结果仍会带有同步的语音、音乐或环境声。
• 图像输入是一个经过掩码的尾部帧,而不是一种单独的模式。参考图像条件化通过掩码来施加,因此同一条流水线无需分支即可同时服务 T2AV 和 I2AV。
提交者的冒烟测试是一个有用的下限:单块 NVIDIA H100 80GB,启用 FlashAttention-3,开启 CPU offload,864×480 分辨率,125 帧,50 步,CFG 5.0,seed 42。这是一段时长 5 秒、略低于高清分辨率的片段,并非 Full HD 渲染,而 PR 也并未声称相反。
检查点并非服务
值得关心这样一次合并的理由,在于它从你的清单里移除了什么。运行参考实现意味着你要克隆仓库、运行 just setup、在任何低于 Hopper 的环境上让它编译 SageAttention、把检查点下载到缓存目录,再调用一条生成命令,而它的输出会落进一个带时间戳的文件夹。对初次一瞥来说这没什么,对一款产品来说却很别扭。
vLLM-Omni 让你在服务进程内直接使用该模型,并提供与该项目用于其他扩散模型相同的离线推理入口点(examples/offline_inference/text_to_video/text_to_video.py 及其图生视频的同类文件),以及位于 recipes/Kandinsky/Kandinsky6-TI2VA.md 的服务配方。由此带来两个实际影响。你的部署形态变成了一个对外提供 HTTP 接口的容器,而不再是一个需要你照管的脚本;并且该模型在你的技术栈中不再是特例——它与你在这台服务器上运行的其他任何东西并排共存。
注意这不是什么。它不是一个托管端点,不是一个价格,也不是一项独立的质量衡量。它只是模型可以运行的又一个地方,由实验室之外的某个人在权重出现三天后贡献出来。
在真实显卡上,一段五秒的片段实际耗时多少
仓库自己的表格才是诚实的起点。这些是非蒸馏基础模型在预热后处理单个 5 秒片段的实际耗时,不计权重加载和 MP4 编码。这里的全高清意味着超分辨率处理也在运行。
• 全高清(Pro)— 在 H100 上为 402 秒,在 RTX PRO 6000 上为 765 秒,在 RTX 5090 上为 854 秒,在 A100 80GB 上为 1,106 秒,在 RTX 4090 上为 1,247 秒,在 RTX 5060 Ti 上为 3,530 秒。
• 全高清(Lite)——在 H100 上为 284 秒,在 RTX PRO 6000 上为 387 秒,在 RTX 5090 上为 406 秒,在 A100 80GB 上为 664 秒,在 RTX 4090 上为 578 秒,以及在 RTX 5060 Ti 上为 1,774 秒。
• SD(Pro)——在 H100 上耗时 356 秒,而在 RTX 4090 上耗时 936 秒,这是消费级显卡劣势最小、经济性最不差的情况。
那张表的整体形态比任何单个单元格都重要。在 Pro Full HD 下,H100 大约比 4090 快三倍,在同样任务上大约比 5060 Ti 快六倍——但无论模型规模如何,SR 阶段的成本都相同,在 5090 上,HD 下约为 64 秒,Full HD 下约为 96 秒。Lite 并不会带来更短的超分辨率过程,因为 SR 模型是单独训练的,并不关心是哪个基础模型为它提供输入。
16 GB 之路,以及那个能改变你画面的设置
在一次 Pro SD 运行中,峰值分配内存达到 72.8 GiB,这已经超出了所有消费级显卡。该代码库以块卸载作为应对——一次只有两个 Transformer 块驻留在 GPU 上,其余从主机内存流式传输——外加针对 32 GB、24 GB 和 16 GB 显卡的三种预设。32 GB 和 24 GB 预设完全相同,因为在 24 GB 以上,额外的余量并不会转化为速度。
这个注意事项被埋没了,值得重复一遍:在 16 GB 预设下,文本编码器被量化为 NF4,论文明确指出,这是唯一一个会改变片段本身的预设变更。不同的文本表示会产生不同的视频。其他所有设置——片段长度、空间条带、卸载——对输出的改变都处于舍入噪声的水平,大约 12% 的像素有一个亮度级别的差异,PSNR 约为 57 dB。如果你在 16 GB 显卡上复现别人的结果却对不上,那这是首先要检查的地方。
发行说明未能解决的三件事
• 五秒是上限,而非默认值。该模型是在 121 帧和 24 fps 下训练的,论文和服务方案都是围绕这一点构建的。发布版本中没有扩展模式。任何更长的内容都是需要你自己负责的拼接问题。
• 你实际要提供服务的是蒸馏检查点,而且经测量它与原模型持平。论文的消融实验表明,在大多数标准上,蒸馏模型要么更受偏好,要么与之打平,且没有任何单项差异达到显著水平,平均偏好为 51% 对 49%。这就是你为速度所接受的取舍。
• 论文中有两个词错误率数字,它们之间并不可比。伴随强化学习阶段出现的生成语音 WER 下降 47%,是用 Whisper-large-v3 评测得出的,而它是 RL 奖励模型之一;与 VABench 一同报告的那个 WER,则是在语音子集上使用 Qwen3-ASR-1.7B 得到的。作者自己也说明了这一点。拿其中一个当作另一个来引用,是这次发布中最容易犯的错误。
路由器在这样的堆栈中所处的位置
OrcaRouter 不提供 Kandinsky 6.0 Video,此处任何内容都不应被解读为声称它提供该服务——该模型需要你从 Hub 自行运行,或通过实验室自己的渠道访问。像这样的流水线需要路由器提供的,是它周边的文本。把镜头描述转成模型训练所依据的长、中或短描述文本的提示词扩展环节,为图生视频环节提供输入的字幕与转录工作,决定四次生成结果中保留哪一次的评审摘要:这些都是普通文本调用,它们通过一个兼容 OpenAI 的端点、在 200 多个模型上运行,供应商目录价以 0% 加价透传,因此供应商价格一变,当天就会生效。在这里,自动故障转移比平常更重要,因为一段在字幕阶段失败的五分钟渲染,应当重新路由,而不是重启任务。
下一个要关注的不是又一次合并,而是一个数字。Kandinsky 6.0 Video Pro 有厂商报告的 VABench 结果,以及实验室进行的、针对 Kling 2.6、Veo 3.1 Fast、MiniMax H3 和 Seedance 2.0 的人工评估——但还没有独立竞技场评分。当它出现时,开放权重的主张就不再是关于可及性的争论,而开始成为关于质量的争论,而正是这种比较决定了这是一个团队会下载的模型,还是一个他们只会欣赏的模型。


该仓库还附带两个 ComfyUI 节点——kandinsky6 和 kandinsky6-sr——可通过 ComfyUI Manager 安装,以及两个 Hugging Face Spaces:一个用于 Pro 蒸馏检查点,一个用于视频超分辨率演示。从 CLI、ComfyUI 节点、diffusers 包到如今的 vLLM-Omni 流水线,其部署覆盖面在第三天就已比大多数开源视频模型一个季度所能达到的更广。这种广度才是本周真正的重点:Sber 发布的是一个系列,而不是一篇附带演示的论文。

