Kandinsky 6.0 VideoがvLLM-Omniに登場：サービングレイヤーがオープンモデルに何をもたらすか

今朝07:55 UTCにプルリクエスト#8537がvLLM-Omniにマージされ、それが行うのはただ一つ：Kandinsky 6.0 Videoをサービス提供可能にすることだ。モデル自体は同じ日にSberのKandinsky Labからペアとして登場した——Kandinsky 6.0 Video Proは290億パラメータ、Kandinsky 6.0 Video Liteは30億パラメータ——テキストプロンプトまたは参照画像から、同期した44 kHz音声、リップシンク付きの5秒クリップを生成し、コード、重み、diffusers統合はすべてMITの下にある。今朝まで欠けていたのは、ワンショットのコマンドラインではなく推論サーバー内で実行する方法だった。

その区別は、聞こえ以上に価値がある。そして、これが今回のリリースとは別の話である理由でもある。自分のカードで実行できるオープンチェックポイントは研究成果物だ。サーバーサイドのパイプライン、共有エントリーポイント、サービングレシピを備えたオープンチェックポイントは、キューの背後に置けるものになる。今週のリリースが与えたのは前者だ。今日のマージは後者の始まりだ。

実際に何がマージされたのか

PRは、チェックポイントkandinskylab/Kandinsky-6.0-Pro-5s-Diffusersから、テキスト-to-ビデオ-and-オーディオおよびイメージ-to-ビデオ-and-オーディオをvLLM-Omniに追加する。興味深いのはエンジニアリング上の選択であり、なぜならそれらは、著者以外の誰かがこれを提供しなければならないときに、アーキテクチャが実際にどのような姿になるかを教えてくれるからだ。

• 1つのDiTが両モダリティをデノイズします。パイプラインはKandinsky6TI2VAPipelineとして登録されており、動画潜在と音声潜在は、2つのモデルを順次実行するのではなく、単一の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 1台、FlashAttention-3、CPUオフロード有効、864×480、125フレーム、50ステップ、CFG 5.0、シード42。これはHDをわずかに下回る5秒のクリップであり、フルHDレンダリングではない。PRもそれ以上のことは主張していない。

チェックポイントはサービスではありません。

このようなマージに注目すべき理由は、それがあなたのリストから何を取り除くかにある。リファレンス実装を動かすには、リポジトリをクローンし、just setup を実行し、Hopper 未満の環境では SageAttention をコンパイルさせ、チェックポイントをキャッシュディレクトリにダウンロードし、出力がタイムスタンプ付きフォルダに保存される generate コマンドを呼び出すことになる。それは最初の確認には向いているが、製品としては扱いにくい。

vLLM-Omni は、モデルをサービングプロセス内で利用できるようにし、プロジェクトがほかの拡散モデル向けに使っているのと同じオフライン推論エントリポイント（examples/offline_inference/text_to_video/text_to_video.py とその image-to-video 版）と、recipes/Kandinsky/Kandinsky6-TI2VA.md にあるサービングレシピを提供します。そこから実用的な帰結が2つあります。デプロイの話は、自分で管理するスクリプトではなく、HTTP インターフェースを話すコンテナになります。そして、モデルはあなたのスタックにおける特殊ケースではなくなります — そのサーバーで実行するほかの何かの隣に位置するのです。

これが何ではないかに注意してください。これはホスト型エンドポイントではなく、価格でもなく、独立した品質測定でもありません。重みが登場してから3日後に、ラボの外部の誰かによって提供された、モデルを実行できるもう一つの場所です。

実カード上で、5秒のクリップが実時間でどれだけのコストになるか

リポジトリ自身の表が正直な出発点だ。これらは、ウォームアップ後の単一の5秒クリップに対する非蒸留ベースモデルの処理時間で、重みの読み込みとMP4エンコードは除外されている。ここでのフルHDは、超解像パスも実行されていることを意味する。

• Full HD (Pro) — H100 で 402 秒、RTX PRO 6000 で 765 秒、RTX 5090 で 854 秒、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 秒。ここはコンシューマー向けカードのペナルティが最も小さく、経済性も最もマシな領域だ。

その表の形は、個々のセルよりも重要だ。H100はPro Full HDにおいて4090より約3倍速く、同じ処理で5060 Tiより約6倍速い。しかしSR段階はどちらのモデルサイズでも同じコストで、5090ではHDで約64秒、Full HDで約96秒だ。Liteを使っても超解像パスが短くなるわけではない。SRモデルは別々に訓練されており、どのベースモデルから入力されたかは関係ないからだ。

16 GBの道、そして写真を変えるたった一つの設定

Pro SD 実行時のピーク割り当てメモリは 72.8 GiB に達し、これはあらゆるコンシューマー向けカードを超えている。リポジトリはブロックオフロードで応える——同時に GPU に常駐する Transformer ブロックは 2 つだけで、残りはホストメモリからストリーミングされる——さらに 32 GB、24 GB、16 GB のカード向けの 3 つのプリセットを用意している。32 GB と 24 GB のプリセットは同一である。24 GB を超えると、追加の余裕は速度にはつながらないためだ。

注意点は埋もれているが、繰り返す価値がある。16 GB プリセットではテキストエンコーダーが NF4 に量子化されており、論文はこれがクリップ自体を変える唯一のプリセット変更であると明言している。異なるテキスト表現は異なる動画を生成する。それ以外のすべて — セグメント長、空間ストリップ、オフロード — は、丸めノイズのレベルで出力を変える。およそ 12% のピクセルが、約 57 dB PSNR で明るさ 1 段階だけ異なる。16 GB カードで他者の結果を再現していて一致しないなら、まず確認すべきはこれだ。

リリースノートでは決着がつかない3つのこと

• 5秒は上限であり、デフォルトではありません。モデルは121フレームと24 fpsで学習されており、論文とサービングレシピの両方ともそれを前提に構築されています。このリリースには拡張モードはありません。それより長いものは、あなた自身が対処すべきスティッチングの問題です。

• 蒸留済みチェックポイントこそが、実際に提供するものとなり、同等であると測定されています。論文のアブレーションでは、蒸留モデルは大多数の基準で好まれるか同等であり、個々の差は有意に達しておらず、平均選好率は51%対49%です。それが、速度と引き換えに受け入れるトレードオフです。

• 論文には単語誤り率（WER）の数値が2つあり、両者は比較できません。強化学習段階に伴う生成音声WERの47%削減は、RL報酬モデルの1つであるWhisper-large-v3で評価されたものです。一方、VABenchと併記されているWERは、音声サブセットに対してQwen3-ASR-1.7Bを用いたものです。著者自身がそう述べています。このリリースでは、一方を他方として引用するのが最も犯しやすい間違いです。

このようなスタックの中でルーターがどこに位置するか

OrcaRouterはKandinsky 6.0 Videoを提供していません。ここにある記述は、提供しているという主張として読まれるべきものではありません——このモデルはHubから自分で実行するものであり、あるいはラボ自身のサーフェスを通じてアクセスできます。このようなパイプラインがルーターに求めるのは、その周辺にあるテキストです。ショットの説明を、モデルが学習した長尺・中尺・短尺のキャプションに変換するプロンプト拡張パス、画像から動画へのパスに供給されるキャプションと文字起こしの作業、4つの生成のうちどれを残すかを決めるレビュー要約——これらはごく普通のテキスト呼び出しであり、プロバイダーの定価を0%のマークアップでそのまま反映した200以上のモデルにまたがる1つのOpenAI互換エンドポイントで実行されるため、ベンダーの価格変更はその日のうちに反映されます。ここでは自動フェイルオーバーがいつも以上に重要になります。なぜなら、キャプション段階で失敗した5分間のレンダリングは、ジョブを再起動するのではなく再ルーティングされるべきだからです。

次に注目すべきは、また別のマージではなく、ある数字だ。Kandinsky 6.0 Video Pro には、VABench におけるベンダー報告の結果と、Kling 2.6、Veo 3.1 Fast、MiniMax H3、Seedance 2.0 に対するラボ実施の人間評価がある — だが、独立したアリーナスコアはまだない。それが現れたとき、オープンウェイトという主張はアクセスをめぐる議論ではなくなり、品質をめぐる議論になり始める。そしてそれこそが、これがチームがダウンロードするモデルなのか、それとも称賛するだけのモデルなのかを決める比較なのだ。

リポジトリには2つの ComfyUI ノード — kandinsky6 と kandinsky6-sr — も同梱されており、ComfyUI Manager 経由でインストールできる。さらに2つの Hugging Face Spaces も提供されている。1つは Pro 蒸留チェックポイント用、もう1つは動画超解像デモ用だ。CLI、ComfyUI ノード、diffusers バンドル、そして今回の vLLM-Omni パイプラインまで含めると、デプロイ面は3日目にして、ほとんどのオープン動画モデルが四半期かけても実現できないほど広い。この広がりこそが今週の本当の話題だ。Sber がリリースしたのは、デモが付いた論文ではなく、モデルファミリーなのだ。