RSI-Jev vs Jev 1.13: Một cái bạn tải xuống, một cái bạn gọi

Đặt RSI-Jev v6.1-VL 4B và Jev 1.13 cạnh nhau và điều đầu tiên người gọi nhận ra là chúng là cùng một yêu cầu. Đưa cho một trong hai một trạng thái và một tập câu hỏi có kiểu — một câu hỏi có/không, một câu hỏi chọn một trong k, một câu hỏi đánh giá theo rubric — và cả hai đều trả về một xác suất đã hiệu chỉnh cho mọi lựa chọn, trong một lượt truyền xuôi, không có văn bản sinh ra để phân tích. Đó không phải là sự trùng hợp: RSI-Jev được xây dựng để nói định dạng truyền tải của Jev một cách có chủ đích, nên một client viết dựa trên API của TypeSafe có thể chạy với nó bằng cách thay đổi base URL. Điều không giống nhau là mọi thứ xung quanh lệnh gọi. Jev 1.13 là mô hình thương mại đóng của TypeSafe, được phục vụ từ một endpoint mà bạn phải trả tiền theo mức sử dụng; RSI-Jev v6.1-VL là một checkpoint 4,69B tham số với trọng số theo Apache-2.0 mà bạn tải về và phục vụ trên phần cứng của riêng mình. Không bên nào là bản đổi thương hiệu của bên kia, không nhà cung cấp nào chứng thực bên kia, và gần như mọi số liệu trong so sánh này đến từ bên đã tạo ra nó.

Ngày tháng trên chủ đề rất quan trọng, bởi vì dự án này cho ra một bản phát hành gần như mỗi ngày. RSI-Jev v6.1-VL 4B được công bố vào 2026-10-07 bởi dự án bên thứ ba Shanghua-Gao/RSI-Jev — một vòng nghiên cứu tự cải thiện, huấn luyện các mô hình ra quyết định kiểu Jev và công bố mọi nhánh đã thất bại cùng với những nhánh đã thắng. Đây là bản phát hành thứ tám trong mười ba ngày trên dòng đó, và nó là trung bình trọng số của bản phát hành trước với một lần tinh chỉnh thứ hai của cùng Qwen3.5-4B-Base. Jev 1.13 là mô hình của TypeSafe AI, ra mắt ngày 2026-09-15 và được đưa vào danh mục của chúng tôi từ ngày 2026-09-24. Cả hai mốc ngày này đều quan trọng ở phần dưới, bởi vì một so sánh với dự án thay đổi hằng ngày chỉ có thời hạn tính bằng ngày.

Hai thứ này thực sự là gì, mỗi thứ một dòng

Jev 1.13 là một mô hình quyết định được lưu trữ phía sau một endpoint chuyên dụng — POST /v1/systemone, không streaming, ngân sách đầu vào khoảng 64.000 token tính trên toàn bộ trạng thái và tất cả câu hỏi của bạn cộng lại, có giá $0.042 mỗi triệu token đầu vào với đầu ra được tính phí bằng không vì không có token đầu ra. Kiến trúc, số lượng tham số và compute huấn luyện của nó không được tiết lộ; TypeSafe cho biết các chi tiết đang được giữ kín và có thể sẽ có một bài báo tiếp theo. Bạn không chạy nó. Bạn gọi nó, và mỗi lần gọi là một yêu cầu mạng được đo đếm.

RSI-Jev v6.1-VL là cấu hình còn lại ở dạng đầy đủ. Đây là một tháp Qwen3.5-4B-Base được tinh chỉnh từ đầu đến cuối, với các đầu quyết định ở lớp 16, 20 và 32, được phục vụ từ một checkpoint khép kín và có dung lượng 9,7 GB ở bf16. Số lượng tham số là 4,69B và đáng để biết chúng được phân bổ ở đâu: 3,57B trong 32 lớp giải mã, 0,64B trong embedding token, 0,33B trong tháp thị giác, 0,05B trong đầu quyết định chính và 0,10B trong hai đầu thoát sớm. Không có mixture of experts và không có mô hình thứ hai. Bạn cài đặt nó bằng một lệnh pip từ kho lưu trữ, chạy máy chủ của nó, và từ thời điểm đó trở đi, quyết định không bao giờ rời khỏi hạ tầng của bạn.

• Ai vận hành nó — một endpoint lưu trữ được tính phí mà bạn không kiểm soát, so với một checkpoint 9,7 GB trên GPU, Apple Silicon hay CPU của chính bạn.

• Hình dạng giá — 0,042 USD cho mỗi triệu token đầu vào, đầu ra miễn phí, trả tiền theo từng lần gọi so với mức bằng không ở biên cộng thêm chi phí máy móc và vận hành.

• Ngân sách đầu vào — khoảng 64.000 token mỗi yêu cầu trên mô hình được lưu trữ, so với 32.768 token văn bản cộng thêm ngân sách hình ảnh trên checkpoint, với mọi nội dung dài hơn đều bị từ chối thay vì bị cắt ngắn.

• Trọng số và giấy phép — đóng, kích thước không được tiết lộ so với trọng số Apache-2.0, mã nguồn MIT, 4,69 tỷ tham số.

• Phương thức — văn bản cho hợp đồng của Jev so với văn bản cộng tối đa bốn hình ảnh mỗi yêu cầu trên các bản phát hành RSI-Jev vision.

• Quyền sở hữu — Mô hình thương mại của TypeSafe AI so với một dự án nghiên cứu của bên thứ ba, dự án này tự ghi rõ trong dòng giấy phép của mình rằng "Không liên kết với TypeSafe AI."

Điểm số trên bảng của riêng RSI-Jev, và vì sao nó chỉ là một nửa của phép so sánh

Con số mà dự án đưa ra đầu tiên là điểm Decision Index 0.3 của nó: 50.98 cho v6.1-VL 4B, tăng từ 46.23 của bản phát hành trước đó. Đó là một lần chạy đầy đủ của cấu hình mặc định — 140,178 yêu cầu, độ phủ 1.0 — và trên bảng công khai của chính dự án, ngày 2026-10-06, nó ngang bằng với mô hình 4B tốt nhất trên bảng đó (50.98 so với 50.82 của ezjev 4B s2, mà bộ công cụ coi là hòa ở mức 0.25) và đứng thứ 27 trong tổng số 113. Trên Decision Index 0.2.1 cũ hơn, nó đạt 50.74 so với 46.24 của v6.0-VL. Bộ mười lăm benchmark của nó, được báo cáo mà không có open_jev_ood tác vụ được phát hiện là trùng với các hàng huấn luyện, là 0.793, và tập giữ lại của nó là 0.729.

Mỗi một con số trong đó đều là của chính RSI-Jev, được đo trên harness của chính RSI-Jev. Decision Index là một bảng benchmark công khai, nhưng không có kết quả đọc nào của Jev 1.13 trên đó, vì bộ kiểm thử của dự án được xây dựng để chấm điểm các checkpoint quyết định mở còn Jev là một endpoint đóng. Vậy nên, cám dỗ đặt 50.98 đối chiếu với 0.727 của Jev trên benchmark typed-decisions rồi tuyên bố người thắng chính là sai lầm cần tránh: hai con số đó đến từ những harness khác nhau, kích thước mẫu khác nhau và dữ liệu khác nhau, và chưa ai chạy một harness áp dụng cho cả hai mô hình.

Cuộc đối đầu trực tiếp duy nhất hiện có là của Laya, không phải của RSI-Jev.

Có một so sánh đã được công bố thực sự đặt một con số Jev bên cạnh một checkpoint mở, và nó không do bên nào trong số này thực hiện. Convai Innovations, đơn vị tạo ra mô hình quyết định Laya, đã lập bảng đối chiếu các số liệu Jev 1.13.0 đã công bố của TypeSafe với số liệu của chính họ và tự nêu rõ các giới hạn: các con số Jev là do bên thứ ba công bố và chưa từng được Convai đo lường, kích thước mẫu và prompt khác nhau, và nhà cung cấp không liệt kê các benchmark của chính mình cho mô hình. Bảng đó đáng đọc để hiệu chỉnh, chứ không phải để đưa ra phán quyết — và nó hoàn toàn không bao gồm RSI-Jev, vì RSI-Jev chưa tồn tại vào thời điểm nó được công bố.

Điều mà nó thực sự cho thấy là hình hài của câu hỏi mô hình lưu trữ so với mô hình mở mà người đọc đang thực sự cân nhắc. Mô hình lưu trữ dẫn đầu ở những nơi không gian lựa chọn lớn và mô hình phải duy trì ổn định một tập câu trả lời rộng; các mô hình mở thắng về độ trễ thô trên mỗi lần gọi vì không có mạng trong đường truyền. Không có gì trong mô thức đó cho bạn biết mô hình cụ thể nào trong hai mô hình này làm tốt hơn nhiệm vụ của bạn, và lập trường trung thực là câu trả lời đó vẫn chưa tồn tại ở nơi công khai.

Những gì checkpoint mang lại mà endpoint không thể

Lập luận mạnh nhất cho RSI-Jev không phải là một điểm số. Đó là việc các trọng số nằm trên đĩa của bạn. Đối với một quyết định định tuyến được đưa ra trên hồ sơ y tế, tài liệu pháp lý hoặc lịch sử tài khoản của khách hàng, “dữ liệu không bao giờ rời khỏi tòa nhà” không phải là một sở thích mà bạn đánh đổi lấy một điểm chuẩn — đó là một yêu cầu nghiêm ngặt, và không có endpoint được host nào ở bất kỳ mức giá nào đáp ứng được điều đó. Chính đặc tính đó loại bỏ giới hạn tần suất: tài liệu của chính nhà cung cấp cho mô hình được host ghi nhận rằng các giới hạn của nó đang được điều chỉnh linh động và có thể thay đổi mà không cần thông báo, còn một checkpoint tự host không có mức trần như vậy ngoài phần cứng của bạn.

Điều thứ hai mà checkpoint mang lại là khả năng kiểm soát độ sâu, và điều đó thật bất thường. Bởi vì các head quyết định nằm ở ba độ sâu, một cài đặt mức nỗ lực sẽ chọn số lớp mà một yêu cầu có thể dùng: thấp dừng ở lớp 16 với trung vị khoảng 23 ms, vừa ở 20 trong 27 ms, cao ở 32 trong khoảng 40 ms, và tự động trả lời tại điểm thoát đầu tiên đủ tự tin, trung bình 19,5 trên 32 lớp trong bộ kiểm thử của dự án. Những độ trễ đó là số liệu của chính dự án, được đo trên một H200 ở bf16 và không nên trộn lẫn với bất kỳ con số nào từ dịch vụ hosted — một lượt truyền xuôi cục bộ và một lệnh gọi API có tính phí không phải là cùng một phép đo, và tài liệu của chính RSI-Jev nói rõ rằng so sánh trước đó của nó với độ trễ đã công bố của Jev đã đặt công việc GPU cục bộ đối đầu với một vòng khứ hồi qua mạng.

Điều thứ ba là hình ảnh. Hợp đồng của Jev là văn bản đầu vào, JSON có cấu trúc đầu ra. Các bản phát hành thị giác RSI-Jev nhận một đến bốn hình ảnh mỗi yêu cầu dưới dạng URL dữ liệu base64, với trạng thái tham chiếu đến từng hình ảnh bằng một điểm đánh dấu, và v6.1-VL đạt 0,834 trên tập hình ảnh giữ riêng của dự án. Nếu quyết định của bạn là "bức ảnh có cho thấy hư hỏng có thể nhìn thấy không", thì đó là một năng lực mà hợp đồng được lưu trữ hoàn toàn không cung cấp.

Những gì bạn phải đánh đổi cũng là thật, và dự án công bố điều đó. Hiệu chuẩn trở nên tệ hơn trong bản phát hành này, chứ không phải tốt hơn: sai số hiệu chuẩn kỳ vọng cuối cùng là 0,048 ở lớp 32 và 0,055 với auto, so với 0,036 và 0,024 của bản phát hành trước. Ngưỡng đơn mặc định 0,95 được phát hành rõ ràng ở trạng thái chưa được xác nhận — nó là phương án dự phòng của một quy tắc lựa chọn mà lựa chọn của chính nó, 0,85, đã không đạt giới hạn độ sâu của dự án trên một nửa dữ liệu phát triển. Các điểm thoát sớm chỉ đọc văn bản, nên bất kỳ câu hỏi nào có hình ảnh đều chạy toàn bộ 32 lớp bất kể mức độ nỗ lực. Và năm trong số các nguồn huấn luyện hình ảnh là phi thương mại hoặc chỉ dành cho nghiên cứu, với việc dự án tuyên bố thẳng rằng liệu các trọng số được huấn luyện trên dữ liệu phi thương mại có kế thừa các điều khoản đó hay không vẫn chưa được giải quyết.

Nên gọi bản hosted ở đâu và không nên gọi ở đâu

Đây là phần của so sánh mà chúng tôi có liên quan trực tiếp, nên đáng để nói cho thật chính xác. Chúng tôi phục vụ mô hình thương mại của TypeSafe dưới mã typesafe/jev-1.13 trên endpoint systemone chuyên dụng — một POST tới /v1/systemone chứ không phải dạng chat-completions của OpenAI, không streaming, dựa trên context 65.536 token mà danh mục của chúng tôi liệt kê. Đó cũng chính là dạng request và answer mà RSI-Jev triển khai, đến từ mô hình mà hợp đồng của nó được dự án sao chép nguyên vẹn. Còn bản thân RSI-Jev thì chúng tôi không host; không hề có id rsi-jev lẫn id shgao trong danh mục của chúng tôi, và ai muốn mô hình đó thì phải tự tải về.

Lý do khiến sự phân biệt này quan trọng ở đây thì hẹp và cụ thể. Một lớp quyết định hiếm khi là toàn bộ một quy trình làm việc — nó thường nằm cạnh một mô hình sinh để viết câu trả lời, bản tóm tắt hoặc mã. Trước đây, điều đó đồng nghĩa với việc phải có hai hợp đồng. Đối với phần được host, điều đó không còn cần thiết nữa: Jev 1.13 nằm trên cùng một key như hơn 200 mô hình khác ở mức giá niêm yết của nhà cung cấp được chuyển nguyên với 0% markup, nên nếu TypeSafe thay đổi mức giá, thay đổi đó sẽ có hiệu lực ở phía chúng tôi ngay trong ngày thay vì vào kỳ thanh toán tiếp theo. Phần tự host chưa bao giờ gặp vấn đề đó, vì bạn chính là nhà cung cấp. Cách rõ ràng để quyết định giữa hai lựa chọn là trước tiên hãy thử hợp đồng thương mại trên một số ít trường hợp đã gán nhãn của riêng bạn, xem liệu hành vi mặc định có đủ tốt để tự động hóa dựa trên đó không, và chỉ khi đó mới tính xem liệu việc tự chạy một checkpoint 4.69B có đáng với công sức vận hành hay không.

Bạn thực sự nên chọn cái nào

Chọn RSI-Jev v6.1-VL 4B nếu quyết định phải nằm trong vành đai của bạn, nếu bạn cần đưa ra quyết định trên cả hình ảnh lẫn văn bản, nếu các bộ lựa chọn của bạn lên tới hàng trăm (checkpoint cho phép tối đa 5.120 lựa chọn mỗi câu hỏi), hoặc nếu bạn muốn tinh chỉnh độ sâu và độ trễ cho từng yêu cầu. Hãy nhận thức rõ khi bắt đầu rằng bạn đang áp dụng một dự án đã thay đổi tám lần trong mười ba ngày, rằng bản phát hành mới nhất của nó đã đánh đổi hiệu chuẩn để lấy độ chính xác, và rằng thẻ của chính nó nêu tên những phần của chính sách thoát mà nó không thể xác nhận.

Chọn Jev 1.13 nếu bạn muốn quyết định này hoạt động mà không cần một ngăn xếp phục vụ, nếu bạn coi trọng một endpoint do người khác duy trì, và nếu mức giá 0,042 đô-la cho mỗi triệu đầu vào — không có token đầu ra để đo — là rẻ so với khối lượng gọi của bạn. Hãy tham gia với hiểu biết rằng bạn đang gọi một mô hình đóng có kích thước không được tiết lộ, có giới hạn tốc độ có thể thay đổi mà không báo trước, và có các benchmark được công bố không phải thứ bạn có thể chạy lại.

Điểm chung của cả hai hữu ích hơn những gì phân biệt chúng, và đó là lý do một so sánh như thế này đáng để viết ra. Không mô hình nào sinh văn bản, nên không mô hình nào tạo ra loại lỗi đến từ một mô hình quên đóng dấu ngoặc nhọn hoặc bịa ra một trường. Cả hai đều trả về xác suất, và trong cả hai trường hợp, xác suất chính là phần bạn phải kiểm chứng trên dữ liệu có nhãn của riêng mình trước khi tự động hóa dựa vào nó — độ trễ thì đã trở thành hàng hóa phổ thông, còn giá trị độ tin cậy là thứ phải được chứng minh cho từng lần triển khai. Dù bạn đứng ở phía nào của ranh giới tải về so với gọi, hãy kiểm tra hiệu chuẩn trước tiên.