Microsoft Mage-VL：発表なしでリリースされたコーデックネイティブな4Bビデオモデル

マイクロソフトのブログ記事にはMage-VLに関するものは存在しない。Azureニュースルームへの掲載も、Foundryカタログへの掲載も、ローンチスレッドもない。マイクロソフトが通常モデルを紹介する製品チャネルには何もない。代わりに存在するのは、Hugging Faceのリポジトリ（microsoft/Mage-VL、6コミット、10.8 GBの重み、Apache-2.0）、推論スクリプトを格納したGitHubフォルダ、Microsoft Mage Teamと名乗る何者かが管理するプロジェクトページ、そして23人の著者によるarXivレポートである。これらをまとめて読むと、4B規模の視覚言語モデルが記述されている。その中心的なアイデアは実に異例だ：動画を等間隔のフレームにデコードし、Webで事前学習されたエンコーダにパッチの密なグリッドを入力する代わりに、Mage-VLは圧縮ビットストリーム自体を読み取り、コーデックがビットを費やしたパッチだけを保持するために、Mage-ViTと呼ばれるゼロから構築されたエンコーダを使用する。マイクロソフトは、これにより視覚トークンが75%以上削減され、実時間で最大3.5倍の高速化を実現し、静止画像ではQwen3-VL-4Bに匹敵し、動画ではマイクロソフト自身の15B Phi-4-Reasoning-Visionを上回ると報告している。

最後の一文は、疑ってかかるべき部分だ。この記事に登場するあらゆる性能数値は、マイクロソフト自身の論文、モデルカード、またはプロジェクトページに遡る。ウェイトが公開されてから10日が経った今も、独立した第三者による再現は一切行われておらず、サードパーティのリーダーボードにもこのモデルは載っていない。そして、Hugging Faceのページが率直に述べているように、このモデルは「どのInference Providerによってもデプロイされていない」。つまり、誰かが気軽にベンチマークを実行できるホスト型エンドポイントすら存在しないのである。以下では、リポジトリが実際に証明していることと、マイクロソフトが単に主張しているに過ぎないこととを切り分ける。発表もなしに行われたリリースにおいて、この二つはまったく異なるカテゴリーだからだ。

十日経って、実際に存在するもの

このリリースの検証可能な範囲は小さく、正確に列挙する価値がある。

• ウェイト、2026年7月26日付。 4.97 GBと4.52 GBの2つのsafetensorsシャード、さらにstreammind_gate.safetensorsという名前の別の1.07 GBファイル。Hugging Face自身のリーダーは、BF16で5Bパラメータを報告している — 言語デコーダに4B、残りは視覚エンコーダとそのゲートに分割されている。

• 技術報告、2026年7月27日提出（arXiv 2607.24904）、1版、23人の著者、タイトルは「Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model」。

• 実行可能なコードであり、単なる重みではありません。このリポジトリには、modeling_mage_vl.py、processing_mage_vl.py、専用のcodec_video_processing_mage_vl.pyを含む2つのビデオプロセッサ、そしてstreammind_gate.pyが含まれており、カスタムPythonコードは約175KBです。config.json内のauto_mapは、6つのTransformersクラスをこれらのファイルにルーティングしているため、このリポジトリにはcustom_codeタグが付けられています。

• ライセンスは2つ、1つではありません。 Mage-VLはApache-2.0です。スタンドアロンのMage-ViTエンコーダーは、別途MITライセンスで公開されています。

• インストール不要で動作するデモ。Microsoft は microsoft/mage-vl-demo を ZeroGPU 上の Hugging Face Space として実行しており、2 つのコミュニティ Space がすでにこのモデルを使用しています。

• コミュニティでの初期の勢いが、ベンダー自身の発表よりも速く形成されています。 先月は268件のいいね、435,784件のダウンロードが記録され、モデルツリーには9件のコミュニティ量子化と2件のファインチューンが追加されました。ダウンロードカウンターには自動取得やミラープルが含まれるため、この数値は導入状況ではなく注目度の指標として捉えるべきです。

• きょうだいモデル。Mage-Flowは、テキストから画像を生成し、指示に基づいて編集するモデルで、同じ固定4B予算で構築され、7月22日に4日早く登場した。GitHubリポジトリはMageを「軽量で研究に適したマルチモーダルモデルのファミリー」として紹介しており、これは誰もが発表したポジショニングステートメントに最も近いものだ。

一方で、存在しないもののリストも同様に示唆に富む。Microsoftのブログ記事やプレスリリースは存在しない。Azure AI Foundryにも掲載がない。つまり、エンタープライズサポートの道筋も、SLAも、マネージドエンドポイントもないということだ。推論プロバイダーもこのモデルを提供していない。vLLMやSGLangのサポートもない。Mage-VLをSGLangに追加してほしいというコミュニティからのリクエストは7月28日にissue #32646として提出されたが、本書き込み時点ではまだオープンのままで、リンクされたプルリクエストもメンテナーからの応答もない。そして、いかなる種類の独立した評価も存在しない。「ビデオで15Bモデルに勝つ」といった主張が通常テストされるであろう中立的なリーダーボードに、このモデルは載っていない。

たった一つの考え：コーデックを読め、フレームを読むな。

実運用されているほぼすべての動画対応VLMは同じことを行う。動画をRGBフレームにデコードし、それらを一様にサンプリングする——1秒ごと、またはクリップ全体で32枚、あるいは予算の許す範囲で——そして各サンプリングフレームを、パッチの高密度グリッドとしてビジョントランスフォーマーに通す。サンプリングされた各フレームの各パッチはトークンになる。静止した背景の壁は、その前を歩く人物とまったく同じ数のトークンを消費し、次のフレームでも、その次のフレームでも、同じコストがかかる。

それは膨大な冗長計算ですが、現代のビデオコーデックは何十年も前にその根本的な問題をすでに解決しています。H.264やHEVCはすべてのフレームを保存するわけではなく、時々アンカー（I）フレームだけを完全に保存し、その間のフレームは動きベクトルと残差として記述します——「このブロックはここに移動し、そしてここが変化した部分です。」動画の興味深い部分は、ほぼ構造上、エンコーダーがビットを費やした部分なのです。

Mage-ViTはその特性を直接的に活用する。16×16パッチ粒度で動作し、アンカーフレームのすべてのパッチを保持する一方、予測フレームについては、コーデック自身の動きベクトルと残差エネルギーによって重要と判定されたパッチのみを保持する——実際の情報、動き、またはシーンチェンジを含む領域——そして、冗長性の低いパッチと完全に冗長なパッチは破棄する。Microsoftは、これにより視覚トークンが75%以上削減されるとしつつも、アンカーフレームがシーン全体を保持しているため時空間コンテキストは維持されると述べている。この設計はコーデックに依存しない。従来型パスはH.264またはHEVCに対応し、ニューラルパスはDCVC-RTに対応する。

この優雅さは、動き推定がすでに完了している点にある。インターネット上のあらゆる圧縮動画には、エンコーダーが計算し、アップロードした誰かが費用を負担した「どこで動きが起きているか」のマップが付いてくる。従来のパイプラインはRGBへデコードした瞬間にそのマップを捨て、同じ情報を再発見するためにGPU時間を費やす。Mage-VLは単にそれを捨てないだけだ。ベンチマークの数値がどうであれ、この観察こそがここでの永続的な貢献であり、たとえ重みをダウンロードしなくても、このリリースを読む価値がある理由なのだ。

この実験で一番すっきりしている点

埋もれているのは、{{1}}このリリースの結果を典型的なモデル発表よりもはるかに解釈しやすくする設計判断であり、{{2}}このリリースを報じたほとんど誰も指摘していないが、{{3}}言語モデルが固定されているということだ。

Mage-VLのデコーダはQwen3-4B-Instruct-2507をそのまま使用しており、変更は加えられていない。比較ベースラインのQwen3-VL-4Bは、同じ4BのQwen3バックボーンに、従来のウェブ事前学習済みビジュアルエンコーダを組み合わせている。したがって、Mage-VLがQwen3-VL-4Bを上回った場合、その差分はエンコーダとコーデックネイティブなトークン化に起因するものであり、より大規模またはより優れた学習済み言語モデルに起因するものではない。これは製品比較を装った統制されたアブレーションであり、本リリースの方法論上の最大の強みである。

逆の方向にも作用する。そして誠実さのためにはそのことを言わなければならない。同一バックボーンでの比較は、エンコーダーというアイデアにとって最も公平な試金石であり、同時にそれを最も有利に見せがちな枠組みでもある——マイクロソフトは自社の貢献だけを切り出せるベースラインを選んだのだ。Phi-4の比較にはその性質はない。Phi-4-Reasoning-Vision-15BとPhi-4-MM-5.6Bは、バックボーンもトレーニングレシピもポストトレーニングも異なる。「ビデオで当社の15Bモデルに勝つ」というのは実際の結果ではあるが、はるかに緩い比較であり、しかもそれはマイクロソフト自身の過去の作品との比較であって、最も勝ちやすい類のものだ。

訓練規模は、この論文が真に驚くべき主張を行っているもう一つの点である。Mage-ViTは、約5億6000万枚のラベルなし画像と1億フレームのラベルなしビデオフレームを用いて、ゼロから事前学習された。絶対的な規模では大きなコーパスだが、競合するエンコーダーの背後にある数十億の厳選された画像-テキストペアには遠く及ばない。この論文が最初に述べている発見は、強力なVLMエンコーダーにはウェブ規模の教師ありデータは必要ないということである。その主張が独立した精査に耐えるなら、それはどの単一のベンチマークの行よりもはるかに重要な意味を持つ。

その数字、そしてそれらが誰の数字であるか

以下はすべてMicrosoftによる報告であり、Microsoft自身の評価環境で、Microsoftが選択したベースラインに対して行われたものです。ここに記載された内容は、第三者によって再現されたものは一切ありません。これは、異例に具体的な誤差範囲を伴う仮説として読むべきであり、スコアボードとして読むべきではありません。

• Video-MME — Mage-VL-4B 64.0 vs Qwen3-VL-4B 59.7 vs Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 vs 79.8 vs 69.0

• LongVideoBench — 61.3 vs 57.7 vs 51.2

• VideoEval-Pro — 45.2 対 Phi-4 の 20.7

• Timelens-QVHighlight（時間的グラウンディング） — 57.4 vs 34.9 vs 11.6

• Ref-DAVIS17（参照追跡） — 25.83 vs 7.48 vs 2.15

• DocVQA-val — 95.14 対 94.69 対 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 vs 81.60 vs 81.70

• ChartQA — 84.88 vs 83.96 vs 83.40

• MMStar — 67.32 対 62.04 対 59.63

• RealWorldQA — 70.46 vs 70.85 vs 70.72、Mage-VLが負ける行の1つ

• MMBench-EN-dev — 84.02 vs 83.25、Phi-4-Reasoning-Vision-15B は 84.19 で両者を上回る

• CV-Bench-3D / CV-Bench-2D — 94.75 対 92.30、および 82.13 対 81.00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 総合64.00で、ストリーミングアーキテクチャの中でも最先端とされる。リアルタイム視覚認識サブセットは、1fpsで平均79.84%を記録し、Qwen3-VL-4Bの72.8%を上回る

• スタンドアロンエンコーダとしてのMage-ViT — 676トークンのバジェットでImageNet上で86.3%以上、Food-101上で96.1%以上

「あの表を三度読むことは、表そのものより価値がある。」

画像に関して言えば、「互角」という言葉が正直な表現だ。 DocVQAは0.45、OCRBenchは0.20、ChartQAは0.92、MMBenchは0.77 — これらの差は、プロンプトテンプレートやデコードシードが変われば順位が逆転し得る範囲内であり、RealWorldQAでは実際にQwen3-VL-4Bが勝っている。マイクロソフトもその点を認めており、画像性能を勝利ではなく互角と位置づけているが、その捉え方は正しい。もしあなたのワークロードが文書や画像の質問応答であれば、このリリースに乗り換える理由はない。

ビデオおよび時間的グラウンディングに関しては、ギャップは大きく、一貫しています。 Timelens-QVHighlight はベースラインをほぼ倍増させます。Video-MME、NExT-QA、LongVideoBench はすべて、バックボーンを固定したまま、同じ方向に3.6〜4.3ポイント動きます。異なる側面を検証するベンチマーク間での一貫性は、エンコーダの変更がチューニングによるアーティファクトではなく実際の効果である場合に期待されるパターンです。

2つの行は、文脈なしに引用すべきではありません。Ref-DAVIS17は7.48に対して25.83であり、3.5倍の圧勝のように見えます。そして、この論文の主要な空間デルタには、VSI-Benchでの+11.0とCrossPointでの+53.1が含まれます。あるタスクでベースラインが最低点に近いスコアを出す場合、そのデルタは主に、どちらのモデルがタスク形式を理解するよう訓練されたかを測るものであり、どちらのモデルがより有能かを測るものではありません。同じ注意は、ストリーミング結果を絶対値で見る場合にも当てはまります。SoccerNetでは、Mage-VLの報告値はTimVal 55.54、ROC-AUC 83.14、F1スコア16.35です。F1スコア16.35は、新しい評価における最先端の数値であり、解決済みの問題を示すものではありません。プロアクティブなストリーミング知覚は初期段階にあり、リーダーの絶対スコアがそれを物語っています。

ゲート：いつ話すかを決めるモデル

2つ目のアーキテクチャのアイデアは、製品への影響が最も明確で、あの謎の1.07 GBファイルを説明するものです。

Mage-VLはストリーミングを2つのプロセスに分割し、論文ではSystem 1とSystem 2として位置づけています。System 1は軽量な「認知ゲート」であり、コーデック特徴量の各ローリングウィンドウを監視し、発言する価値のある何かがちょうど起こり終えた確率を推定します。閾値を下回る場合、それは沈黙を保ち、モデルの高コストな部分は実行されません。閾値を上回ると、完全なデコーダが呼び出されて応答が生成されます。デモ構成は1 fpsで30秒の因果ウィンドウを使用し、CLIは閾値を--gate_thresholdとして直接公開し、ストリーミングエントリポイントはビデオをセグメントごとに処理します(inference_streaming.py --video_backend codec --segment_sec 8)。最終段階では、3.35Mのストリーミングサンプルでゲートのみが訓練されます。

それについて注目に値する点が2つある。第一に、このゲートは上部に貼り付けられた小さな分類ヘッドではない。1.07GBのBF16重みはおよそ5億パラメータに相当し、それ自体が本格的なモデルとして、独立したチェックポイントとして提供されている。第二に、ファイル名はstreammind_gate.safetensorsである。この命名は、このコンポーネントが本論文のために新たに考案されたものではなく、以前のストリーミング知覚研究の系譜を汲むものであることを示唆している。ただし、リポジトリ自体はその系統を明示していない。

なぜ商業的に重要か：常時稼働のビデオでは、支配的なコストは呼び出しあたりのレイテンシではなく、呼び出し頻度である。従来のVLMに24時間365日、毎秒1フレームでカメラフィードを通すと、何かが起きたかどうかに関係なく、1日あたり86,400回のフォワードパスが発生する。何も起きていない99%の映像の間は静かにしているゲートがあれば、その請求額の規模だけでなく、形状そのものが変わる。マイクロソフトのゲートが、その判断を任せられるだけの精度を持つかどうかこそ、研究室の外では誰もテストしていないまさにその点である。

実際に今日それを実行できますか？

はい、GPUと忍耐があれば可能です。障壁は現実にあり、そのほとんどはモデルではなくビデオパイプラインにあります。

メモリ。 Microsoft は VRAM 要件を公開していません。重みインデックスから: 9.49 GB のシャードと 1.07 GB のゲートで約 10.6 GB の BF16 パラメータになります。そのため、画像処理には 16 GB カードが現実的な最低ラインであり、長い動画やストリーミングウィンドウに対応する KV キャッシュを追加するなら、24 GB 以上が妥当な目標です。これはファイルサイズからの計算であり、ベンダー仕様ではありません。プロビジョニングする前に測定してください。

カスタムコードは必須です。 auto_mapは、Transformersのすべてのエントリポイントをリポジトリ自身のモジュールに向けるため、trust_remote_codeが必要です。単にテンソルをロードするのではなく、MicrosoftのPythonコードを実行しています。vLLMやSGLangのパスはまだなく、ページドアテンションも継続的バッチ処理も本番向けサービングスタックもありません。このモデルをエンドポイントの背後に置こうと考えていた場合、これは大きなギャップです。

コーデックパスにはシステムツールが必要です。FFmpeg と ffprobe が PATH に含まれている必要があります。従来のコーデックバックエンドは、cv-preinfer ステップを提供する codec-video-prep パッケージに依存します。ニューラルパスには DCVC-RT が必要です。プレーンなフレームバックエンドには Decord が必要です。また、依存関係として flash-attn と mamba-ssm が含まれ、これらは CUDA 拡張をコンパイルします。そのため、まずツールキットに一致する PyTorch ビルドをインストールするか、ビルドに午後を費やす計画を立ててください。

コンフィグが教えてくれるが、カードは教えてくれないこと。最大位置埋め込みは262,144なので、デコーダーはQwen3-4Bの長いコンテキストを引き継いでいます。視覚側は448ピクセル入力、16x16パッチ、24層・隠れ幅1024のエンコーダー、2x2の空間マージ、動画1秒あたり1トークン、4フレームのウィンドウで動作します。トレーニングはステージ3で時間長384フレームに達しました。262Kの上限は、検証された262Kの動作と同じではありません。そして384フレームが、モデルが実際に処理するよう教えられた長さです。

既知の粗い部分。リポジトリ上のオープンなディスカッション（8月4日投稿、まだ回答なし）では、画像と動画を同じリクエストで渡すとトークンの位置ずれが発生すると報告されています。10日目のソフトウェアは、10日目のソフトウェアらしい振る舞いをします。こうした問題を避けて試してみたい場合は、Microsoftが運営するZeroGPU上のSpaceが、インストール不要の選択肢です。

ライセンス行は「Apache-2.0」ほど単純ではありません

モデルカードにはApache-2.0とある。Mage-ViTエンコーダーはMITだ。どちらもオープンウェイトとしてこれ以上ないほど寛容なライセンスである。ところが、ファミリーリポジトリには「これらのモデルは研究目的のみで公開されている」とあり、責任あるAIのレビューと人間による監督が強調されている。この一文は、商用利用を制限しないApache-2.0許諾の隣にあると、どこか居心地が悪い。さらに依存関係を考えると、DCVC-RTとコーデック準備ツールは、モデルの条件とは別途、それぞれ独自の条件を伴っている。

趣味のプロジェクトであれば、これはノイズにすぎない。顧客に出荷するものであれば、本番投入前に法務相談へ回すべき種類の曖昧さであり、リポジトリ自体で問いかける価値のある類の疑問でもある——そこには、注目すべきことに、現在マイクロソフトの担当者からの回答はない。

これを基に構築すべきでしょうか？

この判断は、問題がストリームなのかリクエストなのかという一点で、明確に分かれます。

If you are doing always-on perception — a camera feed, a live broadcast, a robot's field of view, a meeting that runs for an hour — Mage-VL is pointed exactly at you, and the economics of self-hosting are on your side. Per-token API pricing scales with frames, which is a brutal model for continuous video; a 4B model on your own hardware with a gate that stays silent through uneventful footage is a fundamentally different cost curve. The catch is that you are also signing up to be the first person outside Microsoft to find out whether the gate's judgment is any good.

問題がリクエスト型——ユーザーがドキュメント、PDF、スクリーンショット、短いクリップをアップロードして回答を期待する——の場合、セルフホスティングを選ぶ根拠ははるかに弱くなります。まさにそうしたタスクでは、Mage-VL は自前でホストしなければならないモデルと同等の性能であり、ホスト型マルチモーダルエンドポイントは、GPU も ffmpeg ビルドも trust_remote_code も不要で、API コール1つで利用できます。OrcaRouter では、Gemini 3.6 Flashは、入力トークン100万あたり1.50ドル、出力トークン100万あたり7.50ドルで、これはプロバイダーの定価をそのまま適用したものです。当社はマークアップ0%のため、ベンダーが価格を引き下げた場合、その値下げは価格改定を待つことなく当日中に当社側にも反映されます。1つのキーで200以上のモデルにアクセスでき、プロバイダーの性能が低下した場合には自動フェイルオーバーが発生します。これが、ホスト型エンドポイントをデフォルトに据え、本当に必要なワークロードにのみセルフホスティングを取っておく実際的な理由です。

はっきり言っておくと、この区別は重要です：私たちはMage-VLをホストしていませんし、他の誰もホストしていません。Hugging Face自身のモデルページには、どの推論プロバイダーもそれをデプロイしていないと書かれています。現在、実行するには、自分で実行するしかありません。

何がこの読みを変えるだろうか

4つのこと、重要度が高いと思われる順に。

独立した評価こそが最も重要なものです。上記のすべての数字は主張であり、最も検証が必要なのはベンチマークスコアではなく、3.5倍の高速化という主張です。この数値は、NExT-QAにおいて均一フレームサンプリングと比較して測定されたものですが、ハードウェア、解像度、フレーム数に関する詳細は公開されていません。コーデックの前処理は、実際の処理をCPUとffmpegに移します。他の誰かの環境でエンドツーエンドに測定されたウォールクロック時間での勝利のみが、計画を立てる際に基準とすべき数字です。

次に、サービングのサポートです。vLLMまたはSGLangの実装がマージされれば、これは研究用チェックポイントから、ロードバランサーの背後に配置できる本番運用可能なものへと変わります。SGLangのissueはオープンのままで、まだ誰も着手していません。そこが注目すべきスレッドです。

第三に、Azure AI Foundryでのリスト掲載です。これは、マイクロソフトがこれを論文ではなく製品として意図していることを示すものとなるでしょう。現在のリリースには、それが間近であることを示唆するものは何もありません。

第四に、そして最も奇妙なことに：マイクロソフトが何か言及するかどうか。23人の著者によるテクニカルレポート、維持されたプロジェクトページ、ホストされたデモスペース、そして4日前の姉妹生成モデルは、リークや事故を説明するものではない——これらは、製品向けの拡声器を完全にスキップした意図的な研究発表を説明している。それでもコミュニティは沈黙を埋め、10日以内に9つの量子化と2つのファインチューンを生み出した。

ほとんどのチームにとって正しい選択は、重みをダウンロードするのではなく論文を読むことだ。コーデックネイティブなアイデアが要点であり、それは移植可能だ。エンコーダがすでに計算した動きベクトルを再利用することで、精度を同等に保ったままトークン数を75%削減できるのであれば、その手法は、ローンチ記事、プロバイダのサポート、再現されたベンチマークを伴うモデルに登場するだろう。現在、連続ビデオを運用しているなら、判断基準は異なる。リポジトリをクローンし、自分のクリップを両方のバックエンドに通して、速度向上を自分で測定してみてほしい。なぜなら、今それを実行するなら、あなたが最初になるからだ。

実際に尋ねる価値のある質問

Mage-VL は、Microsoft のラベルを貼っただけの Qwen3-VL ですか？

いいえ、混乱はもっともですが。言語デコーダはQwen3-4B-Instruct-2507をそのまま使用しており、Microsoftが新しいLLMを訓練したわけではありません。それ以外はすべて新規です。Mage-ViTはゼロから事前学習され、コーデックネイティブなトークナイゼーションはQwen3-VLには対応するものがなく、ストリーミングゲートは追加の5億パラメータモデルです。オープンバックボーンを再利用してビジュアルフロントエンドを交換するのは、正当かつますます一般的になっている研究戦略であり、ここでもそれが直接比較を解釈可能にしています。モデルの来歴に関するコンプライアンス要件がある場合は、系統がAlibabaのQwen3ウェイトを通ることに留意し、両方のライセンスを確認してください。

「3.5x faster」とは、提供コストが3.5倍安いという意味ですか？

確実には言えません。この数値は、NExT-QAにおける均一フレームサンプリングに対するウォールクロック高速化であり、Microsoftも「最大」という言い方をしています。実際には2つの点がこれを薄めます。コーデックネイティブ推論には準備パスが必要です — ffmpeg、ffprobe、cv-preinferステップ、またはニューラルパス用のDCVC-RT再エンコード — これらは単純なフレームパイプラインではかからないCPU時間を消費し、GPU側の測定には現れません。また、その利得はトークン削減によるものなので、映像の冗長性に応じてスケールします。ほぼ静止したセキュリティカメラであれば記載の数値より良い結果が出るはずですが、ほぼすべてのパッチが変化する高速カット編集のビデオでは悪い結果になるはずです。ご自身のクリップで測定してください。

コーデックパスを使用するには、特別なビデオファイルが必要ですか？

ほとんど必要ありません。これが嬉しい驚きです。通常のMP4ファイルはすでにH.264またはHEVCであり、これは従来のコーデックバックエンドが消費する形式と正確に一致します。必要なモーションベクターは、あなたがすでに持っているファイルの中に存在しています。追加で必要となるのはツール類です。PATHにFFmpegとffprobeを用意し、さらにコーデック準備パッケージをインストールしてください。ニューラルバックエンドは例外です。DCVC-RTはそのコーデックでエンコードされた動画を前提としているため、再エンコードが必要になります。また、プレーンフレームバックエンドは、他のVLMと同様に動作するフォールバックとして引き続き利用可能です。これは、コーデックに関する主張を自分自身でA/B検証するための誠実な方法でもあります。

商用利用できますか？

ライセンスにはApache-2.0と記載されており、商用利用、改変、再配布が許可されている。一方、リポジトリにはモデルが「研究目的のみで公開されている」とも書かれている。この2つの記述は異なる方向を指しており、その食い違いはマイクロソフトの誰によっても明確にされていない。アナウンスもなく、製品リストにも載らず、リポジトリの議論にベンダーが参加していないリリースとしては、驚くには当たらない。もしこの答え次第で金銭が左右されるのであれば、ライセンスバッジだけを信じるのではなく、弁護士に両方の文書と依存ライセンスを読んでもらうべきだ。