VideoJev: 文章の代わりに数値で答える動画モデル

VideoJevは、決して答えを書き出さない動画理解モデル群です。ある出来事のタイムスタンプを尋ねると、スコア付けされた候補スロットから組み立てた区間を返し、動画についての多肢選択問題を尋ねると、最も高いスコアの選択肢を返します。公開されているチェックポイントは2つあります — VideoJev-4B（Qwen3.5-4B ベース）とVideoJev-35B-A3B（Qwen3.6-35B-A3B ベース） — そしてそれらはローンチされませんでした。誰もプレスリリースを出していません。論文は2026-10-13にarXivに現れ、重みは2026-10-10にHugging Faceに上がり、リポジトリは4日後もまだ整理中でした：10月14日時点では、「Restore inline README video with a public attachment」や「Add arXiv paper link and official BibTeX citation」といったコミットが入っていました。これが静かなリリースの姿です — 成果物は実在し検査可能で、著者が何を重要だと考えているかを教えてくれる発表はありません。

以下はすべて、3つのうちのいずれかから来ている。arXivプレプリント（2610.18615、cs.CV、2026年10月13日投稿）、著者らが公開したモデルカードとコード、そして数値がどのように測定されたかについての論文自身の脚注である。私はこの3つを明確に分けておくように努めた。というのも、このリリースで興味深いのは見出しの数字ではなく、その数字を支える根拠がいかに薄いかということだからだ。

論文が実際に主張していること

VideoJevは、事前学習済みのマルチモーダルLLMを取り、最終MLPと言語モデルの出力ヘッドを削除し、それらの代わりに候補スコアラーを置く。2つの新しいトークン<|option_end|>と<|decide|>が読み出しを生成する。決定状態と各候補状態は512次元に射影され、正規化され、互いにドット積を取られる。時間区間はシグモイドでスコア付けされ、スパンに組み立てられ、回答選択肢はスコア付けされてソフトマックスで正規化される。両タスクは同じヘッドを通して実行される。自己回帰的にデコードされるものは何もない。なぜなら、デコードするものが何もないからだ。

論文の3つの主要な数値は、いずれもベンダー報告によるもので、かつすべて著者自身の評価ハーネスから得られたものである：

• グラウンディング品質 — VideoJev-4Bは3つの時間的グラウンディングベンチマークで平均mIoU 65.3を達成し、バックボーンであるQwen3.5-4Bを6.7ポイント上回ります。VideoJev-35B-A3Bは67.7に達し、Qwen3.6-35B-A3Bを10.8ポイント上回ります。

• 推論なしでのQA同等性 — 4つの動画QAベンチマークにおいて、この2つのモデルは平均74.3と79.5に位置し、それぞれThinkingモードのバックボーンに対して0.6ポイント下、0.7ポイント上の範囲内に収まっている。

• レイテンシ — グラウンディングにおいてこれらのバックボーンより2.8～3.1倍高速で、QAでは100倍以上です。QAの実測値は4Bで129倍、35B-A3Bで100倍です。

速度の主張を誠実に位置づけるなら、それは、タスクが要求するよりもはるかに難しいことをしている推論モデルとの比較だということになる。Qwen3.5-4BはThinkingモードで、LVBenchにおいて1問あたり144.9秒を消費して74.9を記録する。VideoJev-4Bは1.123秒で74.3を記録する。129×は、論文自身のレイテンシ表に基づく実際の計算であり、同時に、思考することを拒むどんなモデルからも得られる計算でもある。興味深い問いは、その高速化が本物かどうかではなく、そのトレードオフが正しいと言えるシステムを構築できるかどうかだ。

その根底にある主張：生成ではなく、意思決定

これがベンチマーク表よりも興味深くなるのは、アーキテクチャ上の主張の部分である。著者らは通常の自己回帰型Qwen3.5-4Bを、まったく同じポストトレーニングデータ、同じ単一ステージ、同じ設定でファインチューニングし、区間を生成させたり、文字で回答させたりした。論文の表3によれば、VideoJev-4Bはその対照を平均グラウンディングmIoUで1.3ポイント、平均QAスコアで1.9ポイント上回っている。両モデルは同一の教師信号を見ており、異なっていたのは読み出しの形状だけだった。

もしそれが成り立つなら、その利点はデータでもスケールでもない — 構造化された候補に対する確率分布をモデルに出力させることは、文字列を生成させてからその文字列を決定に戻すようにパースするよりも、構造化された決定に適しているということだ。それはTypeSafeがJev 1.13とそのSystem Oneファミリーで行ったのと同じ賭けであり、テキスト状態からビデオへ一般化されたものである。論文は、カテゴリーを発明したのではなく、その一連の研究に基づいていることを明言している。

2つの実装上の詳細は、見出しの数字よりも価値が高い。それらこそが、単に高速であるだけでなく実用的にしているものだからだ。キャッシュ推論は、動画を一度エンコードしてプリフィルし、到着したクエリをそのキャッシュされたプレフィックスから分岐させる — クエリごとに1回のフォワードパスで済む。結合推論は、複数のクエリを単一の動画プレフィックスの後ろに置き、それぞれについて個別の <|decide|> を読み出す。そのため、一群の質問は合計1回のフォワードパスで済む。1本の動画に対する10件のグラウンディングクエリについて、論文はVideoJevで0.39秒、Instructベースラインで5.98秒を測定している。QA側では、10件のクエリが1.67秒で収まる。論文はまた、結合推論の明白な失敗モード — 先行する質問がその回答を後続の質問に漏らすこと — も検証し、参照回答や予測回答が共有プレフィックスに挿入されていないことを確認したと報告している。これは著者自身による検証である点、そして結合推論が孤立したキャッシュモードよりも良いスコアを記録している点（4Bで65.3 対 64.5 mIoU）は注目に値する。彼らはこれを、同じ結合レイアウトでの訓練によるものとしている。

カードが教えてくれないこと

4つのことが際立って欠けている。これが本番環境に対応しているかどうかを見極めるなら、これらは上記の何よりも重要だ。

• 学習データは非公開です。リポジトリにはフォーマットが文書化されており、独自のJSONLを構築するためのツールも提供されていますが、コーパスやその規模、出所については明記されていません。報告対象となっている7つのベンチマークに対する汚染を評価することはできません。

• 35Bの重みはFP32から始まります。 プロジェクトページには、Cached推論ではFP32、JointではBF16と記載されています — つまり、より大きなモデルの主要な構成こそがより重いメモリフットプリントを持つものであり、ページにはどちらについてもVRAMの数値は示されていません。

• 確信度は過信している。論文は、4Bで平均キャリブレーション誤差8.65ポイント、35B-A3Bで8.13ポイントを報告している。このスコアは使えるランキング信号であり、自分で調整したしきい値なしに分岐の判断に使うべき確率ではない。

• 誰もこの数値を独自に検証していない。ここにあるすべての数値は、モデルを学習させたグループによるものだ。本稿執筆時点で、第三者による再現も、リーダーボードへの登録も、フレームワーク側のサポートも存在しない — 推論経路は独自アーキテクチャに対する trust_remote_code=True であり、最低でも PyTorch 2.8/CUDA 12.8 と FlashAttention 2 を必要とする。

その最後の点は、より小さいモデルにも当てはまり、当然の想定に反する。VideoJev-4B は、控えめなハードウェアで動くと考えたくなるモデルだが、モデルカード自体のクイックスタートは、最大2,048フレーム、2 fpsでのH200を前提としている。より安価なデモ——10秒のクリップ、10個の候補区間、出力される確率——もあるが、論文の長尺動画の結果では、フレームを640×640に制限したうえで、固定の262,144トークンコンテキストを使用している。4Bはパラメータ数が小さいのであって、サービングコストが必ずしも小さいわけではない。

それに賭けずに試してみる

実際に存在するのはチェックポイントなのだから、低リスクな導入の仕方は、VideoJev を何かの基盤にする前に、自分の映像に対してローカルで動かしてみることだ — デモの道筋はダウンロードと十数行のコードだけで、論文自体が記録している失敗例（Video-MME での小物体のカウントで、どちらのサイズも4冊の本という答えを外す）こそ、Charades ではなく自分のデータで当たりたいものそのものだ。VideoJev-4BとVideoJev-35B-A3Bは Apache-2.0 なので、止めるものは何もない。

OrcaRouterが当てはまるのは、ワークフローのもう半分だ。動画の判断インターフェースはそれ単体では珍しい。よくあるのは、要約を書くための生成モデルも必要とし、高コストな呼び出しを制御するための安価な分類器も必要とし、それらの間をルーティングする何かも必要とするパイプラインだ。OrcaRouterは200以上のモデルを1つのAPIの背後に、0%のマークアップで——プロバイダの定価をそのまま通すので、ベンダーが値下げすれば同じ日にここでも反映される——プロバイダ間の自動フェイルオーバー、複数のモデルを1回の呼び出しに組み合わせるためのルーティングDSL、そしてパネル向けのモデル融合を備えている。VideoJevのどちらのチェックポイントもここではホストされていないし、この記事はそうでないふりをするつもりもない。これがその居場所を得るのは、第一の脚がローカルモデルであるパイプラインの第二の脚としての場面と、このような研究モデルを、その周辺のすべてのために別のベンダー契約を結ぶことなく試せる理由としての場面の2つだ。

何がこれをより大きな話題にするのだろうか

この記事に設けられたゲートは異例なほどクリーンなので、はっきり述べておく価値がある：VideoJevは研究リリースであり、製品ローンチではない。 変更履歴も、料金ページも、ホストされたエンドポイントも、ウェイトリストも、ベンダーのブログ投稿もない。存在するのは、2026年10月13日に投稿されたプレプリント、10月10日にアップロードされた2つのApache-2.0チェックポイント、そして14日——この記事の前日——になお編集されていたリポジトリだ。告知がないことは問題の証拠ではないが、それは枠組みを「ベンダーが主張すること」ではなく「成果物が語ること」にしなければならないことを意味する。

3つの進展がこの状況を一変させるだろう。同じプロトコルの下で同じバックボーンに対して+6.7および+10.8 mIoUの向上を再現する第三者による評価。vLLMまたはSGLangの実装。これにより、trust_remote_codeの珍品から、スループットで提供可能なものへと移行するだろう。あるいは誰かによるホストされたエンドポイント。これにより、100×という主張は、6ページ目の表から取ってくる数字ではなく、自分のビデオで測定できる数字になるだろう。それらのうちの一つが実現するまでは、論文自体が取っている立場が有用である。つまり、direct-scoringインターフェースはビデオエージェントを構築する真に異なる方法であり、その証拠は現在のところ1つのグループによる9ページのプレプリントに過ぎない。

デモノートブックは開いたままにして、手持ちで最も見栄えのしない映像で実行し、信頼度スコアは自分で較正するまでは順位付けとして扱ってください。

リリースはまた、これまでに何がうまくいかなかったかを確認する瞬間でもあります。このクラスのモデルをめぐる、記録に残るAIインシデントやエージェントの障害はOrcaRouter AI Incident Archiveにまとめられており、各エントリには独自の情報源、重大度、信頼度グレード、係争中フラグが付いています。