Kandinsky 6.0 Video 登陸 vLLM-Omni：服務層能為開源模型帶來什麼

拉取請求 #8537 已於今日 UTC 07:55 合併至 vLLM-Omni，而它只做一件事：讓 Kandinsky 6.0 Video可供服務。模型本身同一天由 Sber 的 Kandinsky Lab 以成對形式問世——Kandinsky 6.0 Video Pro為 29B 參數，以及Kandinsky 6.0 Video Lite為 3B——可依文字提示或參考圖像生成五秒片段，並附有同步的 44 kHz 音訊，包含唇形同步，而程式碼、權重與 diffusers 整合全都在 MIT 授權下。直到今早之前，它還缺少一種方式，能在推論伺服器內執行，而非只能使用一次性命令列。

那個區別比聽起來更有價值，而這也是為什麼這件事是與那次發布分開的獨立報導。一個你能在自己的顯示卡上執行的開放檢查點，是一項研究產物；一個具備伺服器端管線、共用進入點和服務配方的開放檢查點，則是你可以放到佇列後方運作的東西。本週的發布給了你前者；今天的發布則是後者的開端。

實際上合併了什麼？

這個 PR 從檢查點 kandinskylab/Kandinsky-6.0-Pro-5s-Diffusers，為 vLLM-Omni 加入了文字轉影片與音訊，以及圖像轉影片與音訊的功能。真正有意思的是其中的工程取捨，因為它們揭示出：當得由作者以外的人來服務這套系統時，這個架構實際上長什麼樣子。

• 單一 DiT 為兩種模態去雜訊。此管線註冊為 Kandinsky6TI2VAPipeline，而影片潛在表徵與音訊潛在表徵是由單一 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 卸載、864×480、125 幀、50 步、CFG 5.0、種子 42。那是略低於 HD 的 5 秒短片，並非 Full HD 渲染，而該 PR 也沒有宣稱並非如此。

檢查點不是服務

關心像這樣的合併，理由在於它能從你的清單中移除什麼。執行參考實作意味著要複製儲存庫、只執行 setup、讓它在任何低於 Hopper 的裝置上編譯 SageAttention、把檢查點下載到快取目錄，並叫用 generate 指令，而其輸出會落在帶時間戳記的資料夾中。這對初步查看來說沒問題，對產品而言卻很彆扭。

vLLM-Omni 讓你在服務程序內取得模型，並具備該專案用於其他擴散模型的相同離線推論進入點（examples/offline_inference/text_to_video/text_to_video.py 及其影像轉影片的對應版本），以及位於 recipes/Kandinsky/Kandinsky6-TI2VA.md 的服務配方。隨之而來有兩個實際影響。你的部署方式會變成一個說 HTTP 介面的容器，而不是你得看管的腳本；而且模型不再是你技術堆疊中的特例——它會與你在該伺服器中執行的其他任何東西並列。

注意這不是什麼。它不是託管端點，不是價格，也不是獨立的品質衡量。它只是模型能運行的又一個地方，由實驗室外部的人在權重出現三天後貢獻。

在真實顯卡上，一段五秒片段的實際耗時是多少

儲存庫自己的表格是誠實的起點。這些是非蒸餾基礎模型在暖機後、單一 5 秒短片的執行時間，且不含權重載入與 MP4 編碼。這裡的 Full HD 表示超解析度處理也同時在執行。

• Full HD（Pro）— 在 H100 上 402 秒，在 RTX 6000 上 765 秒，在 A100 80GB 上 1,106 秒，在 RTX 4090 上 1,247 秒，以及在 RTX 5060 Ti 上 3,530 秒。

• Full HD（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 發布的是一整個模型家族，而非附帶示範的論文。