VideoJev: Um modelo de vídeo que responde com um número em vez de uma frase

VideoJev é uma família de modelos de compreensão de vídeo que nunca escreve uma resposta. Peça a ele o timestamp de um evento e ele retorna um intervalo montado a partir de slots candidatos pontuados; faça a ele uma pergunta de múltipla escolha sobre um vídeo e ele retorna a opção com a maior pontuação. Há dois checkpoints disponibilizados — VideoJev-4B sobre Qwen3.5-4B e VideoJev-35B-A3B sobre Qwen3.6-35B-A3B — e eles não foram lançados. Ninguém divulgou um comunicado à imprensa. Um artigo apareceu no arXiv em 13/10/2026, os pesos foram publicados no Hugging Face em 10/10/2026, e o repositório ainda estava sendo organizado quatro dias depois: em 14 de outubro, ele estava recebendo commits como "Restore inline README video with a public attachment" e "Add arXiv paper link and official BibTeX citation." É assim que um lançamento discreto se parece — os artefatos são reais e inspecionáveis, e não há anúncio para lhe dizer o que os autores acham que importa.

Tudo abaixo vem de um de três lugares: o pré-print do arXiv (2610.18615, cs.CV, submetido em 13 de outubro de 2026), os cartões de modelo e o código que os autores publicaram, e as próprias notas de rodapé do artigo sobre como os números foram medidos. Tentei manter esses três elementos claramente separados, porque o interessante neste lançamento não é o número de destaque — é como é fino o terreno sob ele.

O que o artigo realmente afirma

VideoJev pega um LLM multimodal pré-treinado, remove o MLP final e a cabeça de saída do modelo de linguagem, e coloca um pontuador de candidatos no lugar deles. Dois novos tokens, <|option_end|> e <|decide|>, produzem leituras. O estado de decisão e cada estado candidato são projetados para 512 dimensões, normalizados e combinados por produto escalar; intervalos temporais são pontuados com uma sigmoide e montados em um span, opções de resposta são pontuadas e normalizadas com uma softmax. Ambas as tarefas passam pela mesma cabeça. Nada é decodificado autorregressivamente, porque não há nada a decodificar.

Os três números de destaque do artigo, todos relatados pelos fornecedores e todos provenientes do próprio sistema de avaliação dos autores:

• Qualidade de grounding — O VideoJev-4B atinge 65,3 de mIoU médio em três benchmarks de grounding temporal, 6,7 pontos acima do seu backbone Qwen3.5-4B. O VideoJev-35B-A3B atinge 67,7, 10,8 pontos acima do Qwen3.6-35B-A3B.

• Paridade de QA sem raciocínio — em quatro benchmarks de QA de vídeo, os dois modelos ficam em 74,3 e 79,5 de média, respectivamente 0,6 ponto abaixo e 0,7 ponto acima de seus backbones no modo Thinking.

• Latência — 2,8–3,1× mais rápido que esses backbones em grounding, e mais de 100× em QA. O valor medido para QA é 129× em 4B e 100× em 35B-A3B.

O enquadramento honesto da alegação de velocidade é que ela é uma comparação com um modelo de raciocínio fazendo algo muito mais difícil do que a tarefa exige. O Qwen3.5-4B no modo Thinking consome 144,9 segundos por pergunta no LVBench para obter 74,9; o VideoJev-4B gasta 1,123 segundo para obter 74,3. O 129× é aritmética real sobre a própria tabela de latência do artigo, e também é a aritmética que você obteria de qualquer modelo que se recuse a pensar. A questão interessante não é se a aceleração é real — é se é possível construir um sistema em que essa troca seja correta.

O argumento subjacente: decisões, não gerações

Onde isso se torna mais interessante do que uma tabela de benchmark é a afirmação arquitetural. Os autores fizeram o fine-tuning de um Qwen3.5-4B autorregressivo comum em exatamente os mesmos dados de pós-treinamento, no mesmo estágio único, com as mesmas configurações, e o fizeram gerar intervalos ou responder com letras. A Tabela 3 do artigo diz que o VideoJev-4B supera esse controle em 1,3 pontos de mIoU médio de grounding e 1,9 pontos de pontuação média de QA. Ambos os modelos viram supervisão idêntica; apenas a forma de leitura diferiu.

Se isso se mantiver, o ganho não está nos dados nem na escala — está no fato de que pedir a um modelo que emita uma distribuição de probabilidade sobre candidatos estruturados se ajusta melhor a uma decisão estruturada do que pedir que ele produza uma string e depois analisar a string para convertê-la de volta em uma decisão. Essa é a mesma aposta que a TypeSafe fez com Jev 1.13 e sua família System One, generalizada de estados de texto para vídeo. O artigo é explícito ao dizer que está construindo sobre essa linha de trabalho, em vez de inventar a categoria.

Dois detalhes de implementação valem mais do que os números de destaque, porque são o que o tornam utilizável, e não apenas rápido. Inferência em cache codifica e pré-preenche o vídeo uma vez e permite que consultas que chegam se ramifiquem a partir desse prefixo em cache — uma passagem forward por consulta. Inferência conjunta coloca várias consultas atrás de um único prefixo de vídeo e lê um <|decide|> separado para cada uma, de modo que um grupo de perguntas custa uma única passagem forward no total. Em dez consultas de grounding sobre um vídeo, o artigo mede 0,39 s para o VideoJev contra 5,98 s para uma baseline Instruct; no lado de QA, dez consultas ficam em 1,67 s. O artigo também verifica o modo de falha óbvio da inferência conjunta — que uma pergunta anterior vaze sua resposta para uma posterior — e relata que verificou que nenhuma resposta de referência ou prevista é inserida no prefixo compartilhado. Vale notar que esta é a verificação dos próprios autores, e que a inferência conjunta obtém uma pontuação melhor do que o modo isolado em cache (65,3 vs 64,5 mIoU em 4B), o que eles atribuem ao treinamento no mesmo layout conjunto.

O que o cartão não lhe diz

Quatro coisas estão flagrantemente ausentes, e elas importam mais do que qualquer coisa acima se você estiver decidindo se isto está pronto para produção.

• Os dados de treinamento não são divulgados. O repositório documenta o formato e fornece as ferramentas para você criar seu próprio JSONL, mas o corpus, seu tamanho e sua proveniência não são informados. Você não pode avaliar contaminação em relação aos sete benchmarks que ele reporta.

• Os pesos de 35B começam em FP32. A página do projeto indica FP32 para inferência Cached e BF16 para Joint — portanto, a configuração de destaque do modelo maior é a que tem o maior consumo de memória, e a página não fornece um valor de VRAM para nenhuma delas.

• A confiança é confiante demais. O artigo relata erro médio de calibração de 8,65 pontos para 4B e 8,13 para 35B-A3B. A pontuação é um sinal de classificação utilizável, não uma probabilidade na qual você deva ramificar sem um limiar que você mesmo tenha ajustado.

• Ninguém analisou os números de forma independente. Todos os números aqui apresentados provêm do grupo que treinou os modelos. No momento em que escrevo, não existe replicação por terceiros, nenhuma entrada em ranking e nenhum suporte de framework implementado — o caminho de inferência é trust_remote_code=True contra uma arquitetura personalizada, exigindo PyTorch 2.8/CUDA 12.8 e FlashAttention 2, no mínimo.

Esse último ponto também se aplica ao modelo menor, e vai contra a suposição óbvia. O VideoJev-4B é o que se esperaria executar em hardware modesto, e o próprio guia de início rápido do model card pressupõe uma H200 a 2 fps com até 2.048 quadros. Há uma demonstração mais barata — um clipe de dez segundos, dez intervalos candidatos, probabilidades impressas —, mas os resultados de vídeos longos do artigo usam um contexto fixo de 262.144 tokens, com quadros limitados a 640×640. O 4B é pequeno em parâmetros, não necessariamente no custo de serving.

Experimentar sem apostar nisso

Como os checkpoints são o que de fato existe, a forma de baixo risco de entrar é rodar o VideoJev localmente com suas próprias filmagens antes de construir qualquer coisa em cima dele — o caminho da demo é um download e uma dúzia de linhas, e os casos de falha que o próprio artigo documenta (contagem de objetos pequenos no Video-MME, onde ambos os tamanhos erram a resposta de quatro livros) são exatamente os que você quer encontrar nos seus dados em vez de no Charades. VideoJev-4B e VideoJev-35B-A3B são Apache-2.0, então nada te impede.

Onde o OrcaRouter se encaixa é a outra metade do fluxo de trabalho. Uma interface de decisão em vídeo é rara por si só; o que é comum é um pipeline que também precisa de um modelo generativo para escrever o resumo, de um classificador barato para condicionar a chamada cara e de algo que faça o roteamento entre eles. O OrcaRouter coloca mais de 200 modelos por trás de uma única API com 0% de margem — o preço de tabela do provedor é repassado, então um corte de preço de um fornecedor entra em vigor aqui no mesmo dia — com failover automático entre provedores, uma DSL de roteamento para compor vários modelos em uma única chamada, e fusão de modelos para painéis. Nenhum dos checkpoints do VideoJev está hospedado aqui, e este artigo não vai fingir o contrário; os dois pontos em que ele ganha seu lugar são o de ser a segunda etapa de um pipeline cuja primeira etapa é um modelo local, e o de ser o motivo pelo qual um modelo de pesquisa como este pode ser testado sem um segundo contrato de fornecedor para tudo ao seu redor.

O que tornaria isso uma história maior?

A barreira deste artigo está invulgarmente limpa, por isso vale a pena afirmar claramente: O VideoJev é um lançamento de investigação, não um lançamento de produto. Não há changelog, nem página de preços, nem endpoint alojado, nem lista de espera e nem publicação no blogue do fornecedor. O que existe é um pré-print submetido a 13 de outubro de 2026, dois checkpoints Apache-2.0 carregados a 10 de outubro, e um repositório que ainda estava a ser editado a 14 de outubro — o dia anterior a este artigo. A ausência de um anúncio não é prova de um problema, mas significa que o enquadramento tem de ser "o que os artefactos dizem", não "o que o fornecedor afirma".

Três desenvolvimentos mudariam a forma disto. Uma avaliação por terceiros que reproduzisse os ganhos de +6,7 e +10,8 mIoU contra os mesmos backbones sob o mesmo protocolo. Uma implementação em vLLM ou SGLang, que o faria passar de uma curiosidade de trust_remote_code para algo servível com throughput. Ou um endpoint hospedado por alguém, que tornaria a alegação de 100× um número que você pode medir no seu próprio vídeo, em vez de um número tirado de uma tabela na página seis. Até que um desses se materialize, a posição útil é a que o próprio artigo assume: a interface de pontuação direta é uma forma genuinamente diferente de construir um agente de vídeo, e a evidência para isso é, atualmente, um pré-print de nove páginas de um único grupo.

Mantenha o notebook de demonstração aberto, execute-o com as filmagens menos lisonjeiras que você tiver e trate as pontuações de confiança como um ranking até você mesmo calibrá-las.

Um lançamento também é o momento de verificar o que deu errado antes: os incidentes documentados de IA e as falhas de agentes envolvendo modelos dessa classe estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de contestação.