Jev có phải là mã nguồn mở không? Trọng số thì đóng, còn công cụ thì không

Không. Jev 1.13 (typesafe/jev-1.13) không phải mã nguồn mở, không có kho trọng số nào để tìm, và dù có cuộn bao nhiêu qua tổ chức GitHub của TypeSafe cũng sẽ không thấy một checkpoint, một tài liệu kiến trúc hay một con số tham số. Thứ hiện diện là phần mềm quanh mô hình: mười một kho công khai, tất cả đều theo MIT hoặc Apache-2.0, không kho nào chứa chính Jev. Đó là câu trả lời trung thực gói trong một dòng — bộ công cụ mở, mô hình thì không — và đó là nửa câu chuyện mà người đọc không bao giờ nhận được chỉ từ "đóng, được lưu trữ, chưa công bố". Hai mốc thời gian định hình điều này. TypeSafe phát hành mô hình vào 2026-09-15, nằm ngoài cửa sổ bảy ngày mà blog này viết tới, nên đây không phải bài ra mắt và không nên đọc bất cứ điều gì trong đó như vậy. Sự kiện có ngày tháng là 2026-09-24, khi OrcaRouter thêm typesafe/jev-1.13 vào danh mục của chính mình: lần đầu tiên Jev có thể được gọi qua một cổng của bên thứ ba thay vì chỉ qua endpoint của chính TypeSafe. Đó là ngoại lệ mà trang này vận hành dựa trên — một mô hình trở nên có thể chạy được ở nơi nó vốn không thể.

Điều đó thay đổi gì đối với người đọc thì hẹp và mang tính thực tiễn. Trước 2026-09-24, việc đánh giá Jev đồng nghĩa với việc phải mở một mối quan hệ nhà cung cấp thứ hai trước khi bạn có thể thử nghiệm một quyết định duy nhất. Sau đó, Jev nằm trên cùng một khóa với nửa tạo sinh của cùng một quy trình: một API cho hơn 200 mô hình, 0% phụ phí (giá niêm yết của nhà cung cấp được chuyển nguyên, nên việc nhà cung cấp giảm giá có hiệu lực ở đây ngay trong ngày), với mô hình có thể truy cập tại typesafe/jev-1.13. Bạn vẫn gọi nó theo hình dạng riêng của nó — POST /v1/systemone, không streaming — vì đó không phải là tuyến chat-completions của OpenAI, nhưng hợp đồng bạn ký và khóa bạn luân chuyển vẫn chính là những thứ bạn đã có.

Câu trả lời là hai câu trả lời, và cả hai đều cần thiết.

“Jev có mã nguồn mở không?” đọc lên thì giống một câu hỏi có/không, nhưng lại hành xử như một câu hỏi gồm hai phần. Phần một: mô hình. Nó đóng. TypeSafe đã không công bố trọng số, kiến trúc, số liệu tính toán huấn luyện hay số lượng tham số nào cho Jev 1.13, và không có kho lưu trữ nào mang tên nó. Phần hai: phần mềm xung quanh. Nó mở, được bảo trì tích cực và thực sự hữu ích, và đó là lý do một độc giả đang tìm một kho lưu trữ không hẳn là hoàn toàn không có cơ hội.

Nhầm lẫn hai thứ này sẽ dẫn đến kết luận sai theo cả hai hướng. Giả sử toàn bộ là mở, bạn sẽ dành cả buổi chiều để tìm một checkpoint không hề tồn tại. Giả sử toàn bộ là đóng, bạn sẽ bỏ lỡ phần thực sự quan trọng nếu bạn lo ngại về lock-in — một adapter được cấp phép MIT cho phép bạn xây dựng dựa trên giao diện typed-decision và thay đổi thứ nằm phía sau nó.

Những gì TypeSafe thực sự xuất bản

Đọc ngày 2026-09-30, tổ chức có mười một kho lưu trữ công khai. Số sao và ngày push thay đổi, nên hãy coi đây là ảnh chụp nhanh chứ không phải thuộc tính cố định của dự án. Mọi giấy phép đều là MIT hoặc Apache-2.0 trừ khi có ghi chú khác.

• skills — MIT, khoảng 2,4k sao, lần push cuối cùng 2026-09-12. "Kỹ năng agent để xây dựng với API System One của TypeSafe."

• system-one-adapter-python — MIT, 356 sao, lần push cuối 2026-09-22. "Bản thay thế TypeSafeClient dùng ngay, được hỗ trợ bởi các API LLM."

• typesafe-sdk-js — MIT, 257 sao, lần push gần nhất 2026-09-15. Thư viện TypeScript/JavaScript chính thức cho TypeSafe API.

• typesafe-sdk-python — MIT, 254 sao, lần đẩy cuối cùng vào 2026-09-26. Thư viện Python chính thức; v0.7.2 đã thêm extra `http2` vào ngày hôm đó, và v0.7.1 vào 2026-09-21 đã thêm các ví dụ để sử dụng với cổng AI.

• daggerverse — Apache-2.0, 23 sao, lần đẩy cuối 2026-09-25. Một bộ sưu tập các mô-đun Dagger.

• WorkflowEvals — Apache-2.0, 7 sao, lần push cuối cùng 2026-09-29. "mã workflow của evals.typesafe.ai đã được công bố."

• n8n-nodes-typesafe-ai — MIT, 1 sao, đẩy lần cuối 2026-09-29.

• typesafe-ai.github.io — không công bố giấy phép, 2 sao, lần push cuối cùng 2026-06-04.

Ba mục nữa là các bản fork của những dự án không liên quan và được xử lý bên dưới: pulumi-clickhouse, LLaDA và vllm.

Không có gì trong danh sách đó là mô hình. Không có kho Jev, không có tệp trọng số, không có tokenizer, không có cấu hình phục vụ — không có gì cho phép bạn dựng lên một bản sao hoạt động được. Các repo chỉ là đồ nội thất phía máy khách: hai SDK chính thức, một gói kỹ năng agent, một bộ sưu tập mô-đun CI, một bộ eval đã công bố, một nút n8n, site của tổ chức, và adapter. Đó là một bề mặt thực sự và được bảo trì tốt, và nó không phải là mô hình.

Kho lưu trữ duy nhất thực sự quan trọng nếu bạn đang cố tránh tình trạng bị khóa chặt.

system-one-adapter-python là mục có ảnh hưởng lớn nhất đối với bất kỳ ai đang đưa ra quyết định áp dụng, và mô tả của chính nó đã nêu rõ điểm mấu chốt: một "bản thay thế TypeSafeClient dùng ngay, được hỗ trợ bởi các API LLM."

Hãy đọc kỹ điều đó, vì nó đang làm một việc cụ thể. Tài sản bền vững trong một tích hợp System One là giao diện, chứ không phải endpoint phía sau nó: bạn định nghĩa một mảnh trạng thái và một tập câu hỏi có tên, và một thứ gì đó trả về một câu trả lời có kiểu cho mỗi câu hỏi. Chính hợp đồng đó là thứ mà cơ sở mã của bạn cuối cùng được định hình xoay quanh. Adapter tách hợp đồng khỏi phần triển khai — bạn tiếp tục xây dựng dựa trên giao diện quyết định có kiểu, và thứ tạo ra các quyết định là một lệnh gọi API LLM có thể hoán đổi ở bên dưới.

Hai điều cần nói rõ một cách trung thực. Một adapter không phải là model: những câu trả lời do một LLM tổng quát tạo ra qua đường dẫn này không phải là các xác suất đã hiệu chỉnh mà Jev trả về, nên nó là một cách để giữ cho giao diện khả chuyển, chứ không phải một cách để có được hành vi của Jev mà không cần Jev. Và đây rõ ràng là một dự án TypeSafe — lối thoát được xây dựng bởi chính nhà cung cấp mà bạn có thể muốn thoát khỏi, điều đó tốt hơn là không có gì và không giống như một lối thoát độc lập.

Hai ngã rẽ, và suy luận mà chúng mời gọi

Ba trong số mười một kho lưu trữ là fork. pulumi-clickhouse là một nhà cung cấp Pulumi cho ClickHouse Cloud, Apache-2.0, 3 sao, lần đẩy cuối 2026-07-08. Hai cái còn lại là những cái thường được đọc như bằng chứng, và cả hai cách đọc đều sai.

• vllm — Apache-2.0, 3 sao, lần push cuối 2025-05-23. Một bản fork của engine suy luận và phục vụ có thông lượng cao.

LLaDA — MIT, 12 sao, lần push gần nhất 2025-06-17. Một bản fork của bản triển khai PyTorch chính thức cho “Large Language Diffusion Models.”

Suy luận lười biếng tự nó hiện ra: họ đã fork một repository diffusion-language-model, nên Jev hẳn phải dựa trên diffusion. Không phải vậy, và việc fork chẳng cho bạn biết gì về kiến trúc của Jev. Một fork là bản sao mã của người khác dưới giấy phép của người khác, nằm trong một tổ chức vì những lý do mà chính ngày push cuối cùng của nó khiến trở nên hiển nhiên — tháng 5 và tháng 6 năm 2025, hơn một năm trước khi Jev được phát hành công khai, và không hề được đụng tới kể từ đó. Cả hai repository đều không thuộc phần mà TypeSafe đã phát hành vào tháng 9. Nếu bạn muốn biết Jev hoạt động như thế nào, TypeSafe chưa công bố điều đó, và không có fork nào trong tổ chức của họ lấp đầy khoảng trống đó.

Việc đóng các trọng số thực sự khiến bạn tốn những gì

Bốn điều, và chúng mang tính cụ thể chứ không phải triết lý.

• Bạn không thể tự vận hành. Không có artefact nào để chạy, nên sự cố từ nhà cung cấp hoặc thay đổi quyền truy cập không phải là điều bạn có thể lách qua bằng cách dựng bản sao của riêng mình.

• Bạn không thể kiểm toán. TypeSafe có công bố một trang về độ lởm chởm cho Jev 1.13 — được đánh giá lần cuối vào 2026-09-17 — nêu rõ những chỗ mà mô hình không đáng tin cậy: đọc chữ nghĩa theo nghĩa đen thay vì ý định, bất cứ thứ gì liên quan đến số học, so sánh ngày và giờ, sự gián tiếp và phủ định kép, các trạng thái lớn đầy chi tiết không liên quan, nội dung đối kháng trong trạng thái, các chỉ dẫn và tiêu chí mâu thuẫn, và những bất biến cấu trúc mà nó không bảo đảm, chẳng hạn như câu trả lời đúng/sai và lựa chọn có/không tương đương của nó mâu thuẫn với nhau. Trang đó thẳng thắn một cách bất thường, và nó vẫn là việc nhà cung cấp tự chấm bài của chính mình. Không ai ngoài TypeSafe đã kiểm tra các trọng số.

• Bạn không thể tinh chỉnh. Không có mô hình nền nào để thích ứng, nên một tác vụ ra quyết định mà Jev xử lý kém sẽ vẫn bị xử lý kém cho đến khi nhà cung cấp thay đổi nó — các biện pháp khắc phục của chính trang jaggedness chỉ là cách xử lý tạm trong mã của bạn, không phải các lần chạy huấn luyện.

• Bạn không thể ghim một phiên bản vượt ra ngoài bí danh của nhà cung cấp. typesafe/jev-1.13 là một tên được lưu trữ, nên thứ trả lời một lệnh gọi vào tháng sau là bất cứ thứ gì TypeSafe đang phục vụ dưới tên đó vào lúc đó.

Không có điều nào trong số đó là duy nhất đối với Jev và không có điều nào là một vụ bê bối; đó là sự đánh đổi mà một mô hình quyết định được host thực hiện, và đối trọng là bạn không bao giờ phải mang theo checkpoint, hóa đơn GPU hay một ngăn xếp suy luận. Đáng để biết mình đang ở phía nào của sự đánh đổi trước khi bạn xây dựng dựa trên nó.

Jev là gì, giờ đây bạn đã có thể gọi nó

Jev không phải là một mô hình trò chuyện và không tạo ra văn xuôi. Bạn gửi một trạng thái — tư liệu cần được đánh giá, dưới dạng văn bản, một đối tượng hoặc một mảng — cùng với một tập hợp các câu hỏi có tên, và nó trả về một câu trả lời có cấu trúc cho mỗi câu hỏi. Mỗi câu hỏi thuộc một trong ba dạng nguyên thủy:

• noul — một phán đoán đúng/sai, được trả về kèm theo một xác suất đã được hiệu chỉnh.

• choice — chọn một trong tối đa 255 tùy chọn có nhãn.

• điểm — đánh giá trên thang đo có thứ tự từ 2 đến 10 mức.

Tài liệu của chính TypeSafe đưa ra một ví dụ điểm số có chỉ mục bắt đầu từ 0; thẻ mô hình Jev 1.13 công bố các mức từ 2–10. Cả hai đều là tài liệu của chính nhà cung cấp và trang này không tự tạo ra sự dung hòa giữa chúng.

Phương pháp huấn luyện này là thuật ngữ do chính TypeSafe đặt ra: Học tăng cường cho các quyết định được hiệu chỉnh (Reinforcement Learning for Calibrated Decisions - RLCD), được mô tả trong bài đăng ra mắt đối chiếu với RLHF và RLVR trên trục các quyết định được hiệu chỉnh với xác suất trung thực. RLCD là thuật ngữ của TypeSafe, không phải một từ viết tắt chung chung trong học máy, và nó nên được hiểu như một mô tả từ nhà cung cấp hơn là một kỹ thuật được mô tả độc lập.

Quyền truy cập không còn bị hạn chế nữa: Jev đã được cung cấp rộng rãi kể từ ngày 2026-09-21, và "waitlisted" đã bị loại bỏ. "Early access" vẫn là cách diễn đạt hiện tại của chính TypeSafe trên trang chủ của họ, vì vậy đó không phải là một tuyên bố để bác bỏ — đó chỉ đơn thuần là nhãn của nhà cung cấp, và các giới hạn vận hành mà họ công bố kèm theo là cụ thể.

Các con số trên thẻ của chúng tôi: ngữ cảnh 65.536 token, với nhà cung cấp ghi nhận khoảng 64K đầu vào trên tổng thể trạng thái kết hợp cộng với các câu hỏi. Nếu bạn đã thấy một con số nhỏ hơn được đưa ra cho Jev, đó chỉ là ngân sách trạng thái đơn thuần chứ không phải một phép đo cạnh tranh, và hai con số này không nên được trình bày như một mâu thuẫn. Giá là $0,042 mỗi triệu token đầu vào, với đầu ra được tính phí bằng không — không có token đầu ra nào để đo đếm, vì một quyết định được gõ ra không phải là văn xuôi.

Dữ liệu phục vụ của chính chúng tôi, lấy từ lưu lượng của chúng tôi chứ không phải từ benchmark của nhà cung cấp, trong bảy ngày tính đến 2026-09-30: p50 151 ms, p95 247 ms, khoảng 349 token đầu ra mỗi giây, tỷ lệ lỗi 0,49% và 76,2 triệu token được phục vụ. p50 theo ngày trong khoảng đó lần lượt là 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, với một điểm ngoại lai thực sự — p95 2.448 ms vào ngày 2026-09-28, nằm trong chuỗi này nhưng không phải là mức điển hình.

Các tuyên bố hàng đầu của TypeSafe, được ghi nhãn là của nhà cung cấp và không được tái tạo độc lập: "Nhanh hơn 193,6 lần, Rẻ hơn 444,6 lần", với chú thích dẫn đến các quy trình làm việc của System One; một ví dụ minh họa về 0,000081 đô la trong 0,114 giây so với 0,013880 đô la trong 8,566 giây đối với LLM; "42 đô la cho mỗi tỷ token đầu vào"; và "Không có ảo giác", vốn là một tuyên bố về các ước tính độ tin cậy chứ không phải bằng chứng về việc không có lỗi — tỷ lệ lỗi 0,49% trong thẻ của chúng tôi là đối trọng trung thực. TypeSafe cũng nói thẳng rằng họ không thể chứng minh mức giá của mình không được trợ cấp, và rằng các đánh giá được công bố của họ thường được chạy từ máy tính xách tay ở Bờ Tây, nơi dịch vụ đặt trụ sở. Thẻ đánh giá của chính họ vẫn đang được đánh dấu là chờ xử lý.

Các kho lưu trữ của bên thứ ba tồn tại và chúng tôi không bảo đảm cho chúng.

Việc tìm kiếm "jev github" cuối cùng sẽ làm hiện ra những kho lưu trữ không phải của TypeSafe: các wrapper, bộ sưu tập prompt, thử nghiệm adapter, và danh sách "awesome" quen thuộc vốn xuất hiện quanh bất kỳ mô hình mới nào. Chúng không thuộc phần mà nhà cung cấp công bố, chúng không có sự thẩm định nào từ nhà cung cấp, và số sao của chúng đo lường sự tò mò hơn là tính đúng đắn. Chúng có thể hữu ích; chúng không phải là tài liệu, và không có gì trong chúng là một phát biểu về cách Jev hoạt động.

Điều gì sẽ làm thay đổi câu trả lời này?

Một bản phát hành trọng số, một kiến trúc được công bố, hoặc một đánh giá độc lập về chất lượng quyết định thay vì độ trễ. Bất kỳ điều nào trong ba điều đó cũng sẽ lật ngược từ đầu tiên của trang này. Cho đến lúc đó, tìm kiếm vẫn có một câu trả lời ổn định, và phần đáng để hành động trong đó là chuỗi công cụ: nếu giao diện quyết định có kiểu là thứ bạn đang xây dựng hướng tới, thì một bộ điều hợp được cấp phép MIT có thể hoán đổi mô hình nền tảng chính là sự khác biệt giữa một quyết định bạn có thể xem xét lại và một quyết định bạn không thể.

Jev 1.13 có trong danh mục của chúng tôi dưới typesafe/jev-1.13, trên cùng khóa với phần còn lại của một stack và được định tuyến qua endpoint systemone chuyên dụng thay vì dạng chat-completions. Mô hình thì đóng, bộ công cụ thì mở, và cả hai nửa đó hiện đều có thể truy cập được từ một nơi.