VideoJev: Một mô hình video trả lời bằng con số thay vì một câu

VideoJev là một họ các mô hình hiểu video không bao giờ viết ra câu trả lời. Hỏi nó mốc thời gian của một sự kiện thì nó trả về một khoảng được tập hợp từ các khe ứng viên đã được chấm điểm; hỏi nó một câu hỏi trắc nghiệm về một video thì nó trả về phương án có điểm cao nhất. Có hai checkpoint được phát hành — VideoJev-4B trên Qwen3.5-4B và VideoJev-35B-A3B trên Qwen3.6-35B-A3B — và chúng không hề được ra mắt. Không ai đưa ra thông cáo báo chí. Một bài báo xuất hiện trên arXiv vào ngày 2026-10-13, trọng số được đăng lên Hugging Face vào ngày 2026-10-10, và kho lưu trữ vẫn còn đang được dọn dẹp bốn ngày sau đó: tính đến ngày 14 tháng 10, nó vẫn nhận được những commit như "Restore inline README video with a public attachment" và "Add arXiv paper link and official BibTeX citation." Đó là dáng vẻ của một lần phát hành âm thầm — các sản phẩm là thật và có thể kiểm tra được, và không có thông báo nào cho bạn biết điều mà các tác giả cho là quan trọng.

Tất cả những gì dưới đây đến từ một trong ba nguồn: bản tiền in arXiv (2610.18615, cs.CV, nộp ngày 13 tháng 10 năm 2026), các thẻ mô hình và mã nguồn mà các tác giả đã công bố, và chính các chú thích cuối trang của bài báo về cách các con số được đo lường. Tôi đã cố gắng giữ ba nguồn đó tách bạch rõ ràng, bởi vì điều thú vị ở bản công bố này không nằm ở con số đáng chú ý — mà là ở chỗ nền tảng bên dưới nó mong manh đến mức nào.

Điều mà bài báo thực sự khẳng định

VideoJev lấy một LLM đa phương thức đã được huấn luyện trước, xóa MLP cuối cùng và head đầu ra của mô hình ngôn ngữ, rồi đặt một bộ chấm điểm ứng viên vào vị trí đó. Hai token mới, <|option_end|> và <|decide|>, tạo ra các kết quả đọc. Trạng thái quyết định và mỗi trạng thái ứng viên được chiếu về 512 chiều, được chuẩn hóa, rồi nhân vô hướng với nhau; các khoảng thời gian được chấm điểm bằng sigmoid và lắp ghép thành một span, các lựa chọn trả lời được chấm điểm và chuẩn hóa bằng softmax. Cả hai tác vụ đều chạy qua cùng một head. Không có gì được giải mã theo kiểu tự hồi quy, vì không có gì để giải mã.

Ba con số nổi bật của bài báo, tất cả đều do nhà cung cấp báo cáo và tất cả đều đến từ khung đánh giá của chính các tác giả:

• Chất lượng grounding — VideoJev-4B đạt mIoU trung bình 65,3 trên ba benchmark grounding theo thời gian, cao hơn 6,7 điểm so với backbone Qwen3.5-4B. VideoJev-35B-A3B đạt 67,7, cao hơn 10,8 điểm so với Qwen3.6-35B-A3B.

• Tương đương QA mà không cần suy luận — trên bốn bộ đánh giá video-QA, hai mô hình đạt mức trung bình lần lượt là 74,3 và 79,5, tức chỉ thấp hơn 0,6 điểm và cao hơn 0,7 điểm so với backbone của chúng ở chế độ Thinking.

• Độ trễ — nhanh hơn 2,8–3,1 lần so với các backbone đó trên grounding, và hơn 100 lần trên QA. Con số đo được cho QA là 129× ở 4B và 100× ở 35B-A3B.

Cách diễn đạt trung thực về tuyên bố tốc độ là: đó là so sánh với một mô hình suy luận đang làm một việc khó hơn nhiều so với yêu cầu của tác vụ. Qwen3.5-4B ở chế độ Thinking tiêu tốn 144,9 giây mỗi câu hỏi trên LVBench để đạt 74,9; VideoJev-4B mất 1,123 giây để đạt 74,3. Con số 129× là phép tính thật trên chính bảng độ trễ của bài báo, và nó cũng là phép tính bạn sẽ nhận được từ bất kỳ mô hình nào từ chối suy nghĩ. Câu hỏi thú vị không phải là liệu việc tăng tốc có thật hay không — mà là liệu có thể xây dựng một hệ thống nơi sự đánh đổi đó là đúng đắn hay không.

Lập luận bên dưới nó: những quyết định, không phải những thế hệ

Điều khiến điều này trở nên thú vị hơn cả một bảng đánh giá chuẩn nằm ở tuyên bố về kiến trúc. Các tác giả đã tinh chỉnh một Qwen3.5-4B tự hồi quy thông thường trên đúng cùng dữ liệu hậu huấn luyện, trong cùng một giai đoạn duy nhất, với cùng các thiết lập, và cho nó sinh ra các khoảng hoặc trả lời bằng chữ cái. Bảng 3 trong bài báo cho biết VideoJev-4B vượt mô hình đối chứng đó 1,3 điểm mIoU căn chỉnh trung bình và 1,9 điểm điểm QA trung bình. Cả hai mô hình đều nhận được giám sát giống hệt nhau; chỉ khác ở hình dạng đầu ra.

Nếu điều đó đúng, lợi ích không nằm ở dữ liệu và không nằm ở quy mô — mà là việc yêu cầu một mô hình đưa ra phân phối xác suất trên các ứng viên có cấu trúc phù hợp hơn cho một quyết định có cấu trúc so với việc yêu cầu nó tạo ra một chuỗi rồi phân tích chuỗi đó trở lại thành một quyết định. Đó chính là canh bạc mà TypeSafe đã đặt với Jev 1.13 và dòng System One của mình, được tổng quát hóa từ các trạng thái văn bản sang video. Bài báo nói rõ rằng nó đang xây dựng dựa trên hướng công việc đó thay vì phát minh ra phạm trù này.

Hai chi tiết triển khai đáng giá hơn cả những con số hào nhoáng, vì chính chúng khiến hệ thống dùng được chứ không chỉ nhanh. Suy luận có bộ nhớ đệm mã hoá và nạp trước video một lần rồi để các truy vấn đến sau rẽ nhánh từ tiền tố đã lưu đó — mỗi truy vấn chỉ tốn một lượt lan truyền xuôi. Suy luận kết hợp đặt nhiều truy vấn phía sau một tiền tố video duy nhất và đọc ra một <|decide|> riêng cho từng truy vấn, nhờ đó cả một nhóm câu hỏi chỉ tốn tổng cộng một lượt lan truyền xuôi. Với mười truy vấn grounding trên một video, bài báo đo được 0,39 giây cho VideoJev so với 5,98 giây cho baseline Instruct; ở phía QA, mười truy vấn mất 1,67 giây. Bài báo cũng kiểm tra chế độ thất bại hiển nhiên của suy luận kết hợp — rằng một câu hỏi trước đó làm rò rỉ đáp án của nó sang câu hỏi sau — và báo cáo rằng họ đã xác minh không có đáp án tham chiếu hay đáp án dự đoán nào bị chèn vào tiền tố dùng chung. Đáng lưu ý rằng đây là kiểm chứng của chính các tác giả, và rằng suy luận kết hợp đạt điểm tốt hơn so với chế độ đệm tách rời (65,3 so với 64,5 mIoU ở 4B), điều họ cho là nhờ huấn luyện trên cùng bố cục kết hợp.

Điều mà thẻ không nói cho bạn biết

Có bốn điều vắng mặt một cách đáng chú ý, và chúng quan trọng hơn mọi thứ ở trên nếu bạn đang cân nhắc liệu đây có phải là bản sẵn sàng cho production hay không.

• Dữ liệu huấn luyện không được tiết lộ. Repo có tài liệu mô tả định dạng và cung cấp cho bạn công cụ để tự xây dựng JSONL của riêng mình, nhưng tập ngữ liệu, kích thước và nguồn gốc của nó thì không được nêu rõ. Bạn không thể đánh giá mức độ nhiễm bẩn đối với bảy benchmark mà nó báo cáo.

• Trọng số 35B bắt đầu ở FP32. Trang dự án ghi chú FP32 cho suy luận Cached và BF16 cho Joint — vậy cấu hình được nhấn mạnh của mô hình lớn hơn chính là cấu hình có mức chiếm dụng bộ nhớ nặng hơn, và trang không đưa ra con số VRAM cho cả hai.

• Độ tự tin đang tỏ ra quá tự tin. Bài báo báo cáo sai số hiệu chuẩn trung bình là 8,65 điểm đối với 4B và 8,13 đối với 35B-A3B. Điểm số này là một tín hiệu xếp hạng dùng được, chứ không phải một xác suất mà bạn nên phân nhánh dựa vào nếu không có ngưỡng do chính bạn đã tinh chỉnh.

• Chưa có ai tự mình kiểm chứng các con số này một cách độc lập. Mọi số liệu ở đây đều đến từ nhóm đã huấn luyện các mô hình. Tính đến thời điểm viết bài này, chưa có bản sao chép độc lập nào từ bên thứ ba, chưa có mục nào trên bảng xếp hạng và chưa có hỗ trợ framework nào được triển khai — đường suy luận là trust_remote_code=True đối với một kiến trúc tùy chỉnh, đòi hỏi tối thiểu PyTorch 2.8/CUDA 12.8 và FlashAttention 2.

Điểm cuối cùng đó cũng áp dụng cho mô hình nhỏ hơn, và nó đi ngược lại giả định hiển nhiên. VideoJev-4B là mô hình mà bạn sẽ mong chạy trên phần cứng khiêm tốn, nhưng phần hướng dẫn nhanh của chính card lại giả định dùng H200 ở 2 fps với tối đa 2.048 khung hình. Có một bản demo rẻ hơn — một clip mười giây, mười khoảng ứng viên, xác suất được in ra — nhưng kết quả video dài của bài báo sử dụng ngữ cảnh cố định 262.144 token với khung hình bị giới hạn ở 640×640. 4B nhỏ về số tham số, nhưng không nhất thiết nhỏ về chi phí phục vụ.

Thử nó mà không đặt cược vào nó

Vì các checkpoint mới là thứ thực sự tồn tại, cách bắt đầu ít rủi ro là chạy VideoJev cục bộ trên chính tư liệu video của bạn trước khi bạn xây dựng bất cứ thứ gì trên nó — đường demo chỉ là một lần tải xuống và một tá dòng mã, và các trường hợp thất bại mà chính bài báo ghi lại (đếm vật thể nhỏ trên Video-MME, nơi cả hai kích cỡ đều bỏ lỡ đáp án "bốn cuốn sách") chính là những trường hợp bạn muốn gặp trên dữ liệu của mình thay vì trên Charades. VideoJev-4B và VideoJev-35B-A3B đều là Apache-2.0, nên không có gì ngăn cản bạn.

Vị trí của OrcaRouter là nửa còn lại của quy trình làm việc. Một giao diện quyết định video tự thân đã là điều hiếm gặp; điều phổ biến là một pipeline cũng cần một mô hình tạo sinh để viết tóm tắt, một bộ phân loại rẻ để kiểm soát lệnh gọi đắt đỏ, và một thứ gì đó để định tuyến giữa chúng. OrcaRouter đặt hơn 200 mô hình sau một API với 0% markup — giá niêm yết của nhà cung cấp được chuyển thẳng, nên việc nhà cung cấp giảm giá có hiệu lực ở đây ngay trong cùng ngày — với tính năng chuyển đổi dự phòng tự động giữa các nhà cung cấp, một DSL định tuyến để kết hợp nhiều mô hình vào một lệnh gọi, và tính năng hợp nhất mô hình cho các panel. Không có checkpoint VideoJev nào được lưu trữ ở đây, và bài viết này sẽ không giả vờ điều ngược lại; hai vị trí mà nó khẳng định được chỗ đứng là chặng thứ hai của một pipeline có chặng đầu là mô hình cục bộ, và là lý do một mô hình nghiên cứu như thế này có thể được thử mà không cần hợp đồng với nhà cung cấp thứ hai cho mọi thứ xung quanh nó.

Điều gì sẽ khiến đây trở thành một câu chuyện lớn hơn?

Cổng của bài này sạch một cách bất thường, nên đáng nói thẳng: VideoJev là một bản phát hành nghiên cứu, không phải một đợt ra mắt sản phẩm. Không có changelog, không có trang giá, không có endpoint được host, không có danh sách chờ và không có bài đăng blog của nhà cung cấp. Thứ tồn tại là một preprint được gửi vào ngày 13 tháng 10 năm 2026, hai checkpoint Apache-2.0 được tải lên vào ngày 10 tháng 10, và một kho lưu trữ vẫn đang được chỉnh sửa vào ngày 14 tháng 10 — một ngày trước bài viết này. Việc không có thông báo không phải là bằng chứng của một vấn đề, nhưng nó có nghĩa là cách định khung phải là "những gì các hiện vật nói", chứ không phải "những gì nhà cung cấp tuyên bố."

Ba bước phát triển sẽ thay đổi cục diện của chuyện này. Một đánh giá của bên thứ ba tái lập được mức tăng +6.7 và +10.8 mIoU so với cùng các backbone theo cùng một giao thức. Một bản triển khai vLLM hoặc SGLang, thứ sẽ đưa nó từ một thứ gây tò mò qua trust_remote_code thành một thứ có thể phục vụ ở mức thông lượng. Hoặc một endpoint được host bởi ai đó, thứ sẽ biến tuyên bố 100× thành một con số bạn có thể tự đo trên video của mình thay vì một con số lấy từ bảng ở trang sáu. Cho đến khi một trong những điều đó thành hiện thực, lập trường hữu ích chính là lập trường mà bài báo tự đưa ra: giao diện chấm điểm trực tiếp là một cách thực sự khác để xây dựng một video agent, và bằng chứng cho nó hiện tại chỉ là bản tiền in chín trang của một nhóm.

Hãy giữ notebook demo luôn mở, chạy nó trên những cảnh quay kém đẹp nhất mà bạn có, và coi điểm tin cậy như một thứ hạng cho đến khi bạn tự hiệu chỉnh chúng.

Một bản phát hành cũng là thời điểm để kiểm tra xem trước đây đã có gì sai sót: các sự cố AI và lỗi agent đã được ghi nhận liên quan đến những mô hình thuộc nhóm này đều được tập hợp trong OrcaRouter AI Incident Archive, nơi mỗi mục đều đi kèm nguồn riêng, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp.