"System One" như một Loại Mô hình: Vị trí của Jev 1.13 trong đó

"System One" là thuật ngữ chỉ nhóm mà TypeSafe dùng để nói về sự phân tách của mình giữa một mô hình đưa ra quyết định và một mô hình viết nội dung, và Jev 1.13 (typesafe/jev-1.13) là thành viên đầu tiên của nhóm — một mô hình trả về câu trả lời có kiểu dữ liệu thay vì những câu văn. Đây không phải là một mô hình mới. TypeSafe đã phát hành Jev vào ngày 2026-09-15, và trang này không phải là một bài giới thiệu ra mắt: mô hình đã ra đời được mười lăm ngày và nằm ngoài cửa sổ bảy ngày mà blog này hướng tới. Điều đã xảy ra trong cửa sổ đó là việc OrcaRouter thêm mô hình này vào danh mục của mình vào ngày 2026-09-24 và mở thẻ mô hình cho Jev 1.13 tại https://www.orcarouter.ai/models/typesafe/jev-1.13 — lần đầu tiên nó có thể được gọi thông qua một cổng kết nối của bên thứ ba thay vì chỉ qua endpoint riêng của TypeSafe. Ý tưởng về nhóm phân loại là lý do trang này tồn tại; thay đổi trong cách phục vụ là lý do nó mang ngày hôm nay.

Phiên bản đơn giản của phạm trù này: một LLM được hỏi một câu hỏi và viết ra câu trả lời để một người đọc. Một mô hình System One được hỏi một câu hỏi và trả về một giá trị để chương trình rẽ nhánh dựa vào. Cách diễn đạt của chính TypeSafe là "các LLM tạo ra từ ngữ cho con người" trong khi "Jev tạo ra các quyết định có kiểu và giống mã hơn: đáng tin cậy, nhanh, tự nhất quán và an toàn về kiểu." Câu đó là toàn bộ phạm trù được nén vào một mệnh đề, và đáng để mổ xẻ từ từ, vì bốn tính từ đang đảm nhiệm những lượng công việc khác nhau và một trong số chúng đang làm nhiều hơn những cái còn lại.

Điều mà “giống mã hơn” thực sự khẳng định

Hãy xem xét bốn luận điểm theo đúng thứ tự, bởi vì chúng không phải là bốn cách nói lại cùng một ý "điều đó tốt hơn".

• Đáng tin cậy — dạng đầu ra được cố định trước. Bạn khai báo câu hỏi; câu trả lời chỉ có thể trả về dưới dạng một trong những giá trị bạn cho phép. TypeSafe nói thẳng rằng "mô hình không bao giờ mắc lỗi kiểu," và lưu ý đây là tuyên bố duy nhất của họ "về mặt toán học là không thể" bác bỏ bằng một phản ví dụ, bởi vì một giá trị không nằm trong tập bạn đã khai báo không phải là giá trị mà mô hình có thể phát ra.

• Nhanh — tất cả câu trả lời được tạo ra trong một lượt duy nhất thay vì từng token một. Bài đăng ra mắt của TypeSafe diễn đạt điều đó như sau: "Jev xuất tất cả xác suất song song thay vì sinh tự hồi quy theo từng token." Trong cửa sổ phục vụ bảy ngày của riêng chúng tôi kết thúc vào 2026-09-30, thời gian trung vị đến token đầu tiên trên typesafe/jev-1.13 là 151 ms và p95 là 247 ms.

• Tự nhất quán — cùng một trạng thái với cùng những câu hỏi thường tạo ra cùng những câu trả lời. Một ví von từ lập trình là thứ khiến điều này dễ hiểu, nhưng cũng chính ở đó phép ví von không còn là một chứng minh: tính tất định của trình biên dịch là một thuộc tính trong cách nó được tạo dựng, còn đây là một khẳng định về hành vi. Các phép đo của chính chúng tôi là cách đọc trung thực về điều đó — tỷ lệ lỗi trên lưu lượng playground của chúng tôi trong cùng cửa sổ bảy ngày là 0,49%, nên nó tự nhất quán theo cách một hàm tốt tự nhất quán, chứ không phải theo cách của số học.

• An toàn kiểu — và đây là yếu tố có sức nặng nhất. An toàn kiểu ở đây không phải là một tính từ chỉ chất lượng; nó là một phát biểu về việc mô hình nằm ở đâu so với một trình kiểm tra kiểu. Trong một pipeline sinh thông thường, hệ thống kiểu bắt đầu sau khi mô hình hoàn tất: mô hình viết văn bản, một trình phân tích đoán hình dạng, một trình xác thực kiểm tra nó, và một luồng xử lý lỗi xử lý những trường hợp mà phỏng đoán sai. Một mô hình System One chuyển khai báo kiểu lên trước lời gọi. Ba nguyên thủy mà thẻ của chúng tôi ghi lại chính là hệ thống kiểu: noul, một phán đoán đúng/sai được trả về kèm xác suất đã hiệu chỉnh; choice, một nhãn được chọn từ tối đa 255 lựa chọn có nhãn; và score, một đánh giá trên thang có thứ tự từ 2 đến 10 mức. Bạn chọn nguyên thủy, bạn cung cấp nhãn hoặc tiêu chí, và giá trị trả về được rút ra từ tập hợp đó.

TypeSafe có công bố một điểm khác biệt giữa tài liệu của họ và tài liệu của chúng ta, đáng để nêu ra hơn là giải quyết: tài liệu của nhà cung cấp đưa ra ví dụ về Score được đánh chỉ số từ 0, trong khi thẻ của chúng ta ghi thang đo là từ 2 đến 10 mức. Cả hai đều đang mô tả cùng một primitive. Nếu bạn đang xây dựng một ngưỡng, hãy đọc trang của nhà cung cấp để biết chính xác cách đánh chỉ số mà SDK của bạn đang dùng.

Hai dạng lỗi không còn tồn tại

Hệ quả thú vị của "không văn xuôi" không nằm ở khía cạnh thẩm mỹ. Mà ở chỗ hai thất bại vốn chi phối các pipeline tạo sinh trong vận hành sản xuất lại vắng mặt trong thiết kế này, thay vì được nó giảm thiểu.

Sai lệch định dạng là vấn đề đầu tiên. Một LLM được yêu cầu trả về JSON thì phần lớn thời gian sẽ trả về JSON, còn những lần còn lại là một thứ gì đó gần giống JSON — một chú thích ở cuối, một hàng rào markdown, một trường bị đổi tên thành từ đồng nghĩa, một đối tượng lồng nhau trong khi schema yêu cầu một chuỗi. Các cách khắc phục ở cấp độ prompt (chỉ dẫn mạnh mẽ hơn, ví dụ few-shot, một schema trong thông điệp hệ thống) đều là những nỗ lực nhằm giữ một hình dạng mà mô hình có thể tùy ý từ bỏ, bởi vì hình dạng đó là một yêu cầu, chứ không phải một ràng buộc. Cách đặt vấn đề của TypeSafe làm nổi bật sự tương phản này: với chuỗi, "các đầu ra khả dĩ và cấu trúc" được yêu cầu và các phản hồi "cần được phân tích cú pháp + xác thực", với "luôn có một số rủi ro rằng AI đi chệch hướng." Khi các đầu ra khả dĩ được khai báo trước, sự sai lệch không còn chỗ nào để đi.

Đầu ra không thể phân tích cú pháp là trường hợp thứ hai, và nó thực chất vẫn là cùng một kiểu thất bại nhưng xảy ra vào thời điểm tồi tệ hơn — không phải một trường trả về hơi sai, mà là một phản hồi mà trình phân tích cú pháp hoàn toàn không đọc được, ập đến đúng vào thời điểm bất tiện nhất trong một quy trình làm việc. Một mô hình phát ra giá trị có kiểu dữ liệu thì không có trạng thái như vậy.

Đây là một lập luận mang tính cấu trúc, và nó nên được phát biểu như vậy. Nó không nói gì về việc liệu một câu trả lời riêng lẻ có đúng hay không — một câu hỏi trắc nghiệm có thể chọn sai nhãn, và một noul có thể trả về true với độ tin cậy cao khi câu trả lời trung thực là sai. Điều biến mất là loại thất bại mà một trình phân tích cú pháp lẽ ra đã bắt được. Đó là một sự giảm bớt thực sự và hữu ích, và nó không phải là cùng một khẳng định như "các câu trả lời là đúng."

Vì sao giá là một hình dạng, không phải là một khoản giảm giá

Mô hình được định giá ở mức $0,042 mỗi triệu token đầu vào, với đầu ra được tính phí bằng không — và số không đó không phải là mức khuyến mãi, mà là hệ quả của thiết kế. Một mô hình phát ra ba token câu trả lời có cấu trúc thì không có khối lượng đầu ra để đo đếm, nên cách tính giá theo token đầu ra chẳng có gì để gắn vào. Cấu trúc tính phí gồm một khoản phí theo token đầu vào và một quyết định. Danh mục của chúng tôi chuyển tiếp nguyên giá niêm yết của nhà cung cấp với mức markup 0%, vì vậy $0,042 là con số của TypeSafe chứ không phải con số do chúng tôi đặt ra, và nếu nhà cung cấp thay đổi giá thì thay đổi đó sẽ có hiệu lực ngay trong cùng ngày.

Đặt hai hình dạng cạnh nhau và sự khác biệt không phải là một con số phần trăm. Chi phí của một pipeline sinh tăng theo lượng mà mô hình nói ra: một câu trả lời dài dòng tốn kém hơn một câu trả lời ngắn gọn cho cùng một quyết định, và một mô hình suy luận theo chuỗi tư duy tính phí cho những token mà nó dùng để suy nghĩ trước khi trả lời, bất kể câu trả lời có tốt hơn hay không. Chi phí của một lệnh gọi System One tăng theo lượng thông tin bạn đưa cho nó — trạng thái và các câu hỏi. Hỏi một câu hỏi dựa trên một tài liệu dài thì bạn phải trả tiền cho cả tài liệu. Nhồi bốn mươi câu hỏi vào cùng một trạng thái (ngân sách đầu vào trên thẻ của chúng tôi là 65.536 token cho cả trạng thái và câu hỏi cộng lại, khoảng 64K; nếu bạn từng thấy con số "khoảng 32.000 token" trong các bài viết trước đây của OrcaRouter, thì đó chỉ là ngân sách trạng thái, không phải một tổng số khác đối chọi lại) thì bạn chỉ trả tiền cho tài liệu một lần và nhận lại bốn mươi quyết định.

Đó là lý do vì sao chi phí trên mỗi quyết định, chứ không phải chi phí trên mỗi token, mới là đơn vị đúng cho lớp này — và vì sao đồng hồ đo lại chạy theo hướng ngược lại với điều mà hầu hết các đội ngũ mong đợi. Cách giảm chi phí điển hình của mô hình sinh là "làm cho mô hình nói ít hơn." Ở đây không có gì để nói ít hơn cả.

Các con số của chính TypeSafe, vốn do nhà cung cấp tự báo cáo và chưa được tái lập một cách độc lập, nhắm thẳng vào so sánh đó: "Nhanh hơn 193,6 lần, Rẻ hơn 444,6 lần," với chú thích là "dựa trên quy trình cho các tác vụ System One (bằng chứng)," cùng một ví dụ tính toán cụ thể ghi rằng "Chi phí TypeSafe AI $0,000081 Hoàn thành trong 0,114 giây / Chi phí LLM $0,013880 Hoàn thành trong 8,566 giây." Trang chủ cũng liệt kê "$42 mỗi tỷ token đầu vào" so với "Giá đầu vào thấp hơn 238 lần so với Claude Fable 5.1." Hãy coi tất cả những điều đó là lập luận của nhà cung cấp, chứ không phải kết quả đo lường: bài đăng ra mắt thừa nhận rằng "các đánh giá được công bố của chúng tôi thường được chạy từ laptop của chúng tôi ở Bờ Tây" và rằng "chúng tôi không thể chứng minh rằng nó không được trợ giá; chúng tôi sẽ cần thời gian dài hạn để chứng minh tính bền vững của mức giá của mình (mà chúng tôi kỳ vọng sẽ giảm, chứ không tăng)." Hai nhượng bộ đó là của chính nhà cung cấp, và chúng là khung phù hợp cho mọi hệ số nhân trên trang.

Hiệu chuẩn là nửa sau của ý tưởng

Nếu hạng mục chỉ là “đầu ra có cấu trúc”, thì nó sẽ mô tả việc gọi hàm kèm thêm vài bước. Phần khiến nó trở thành một thứ riêng biệt là mọi câu trả lời đều đến kèm một xác suất, và các xác suất chính là mục tiêu huấn luyện. TypeSafe gọi phương pháp này là Reinforcement Learning for Calibrated Decisions (RLCD) — thuật ngữ của họ, không phải một từ viết tắt chung — và bảng so sánh trong bài đăng ra mắt đặt nó bên cạnh RLHF và RLVR: RLHF tối ưu hóa theo điều mà người đánh giá con người ưa thích, RLVR tối ưu hóa cho các đầu ra có thể kiểm tra bằng chương trình, còn RLCD tối ưu hóa cho “các câu trả lời với xác suất trung thực về mặt nhận thức luận trên các tác vụ System One.”

Khác biệt thực tế nằm ở chỗ xác suất đó nhằm để làm gì. Trong một pipeline sinh tạo, ước lượng độ tin cậy là một lần sinh thứ hai: bạn hỏi mô hình rằng nó chắc chắn đến đâu và nó viết ra một con số, bản thân con số đó là văn xuôi với cùng những kiểu lỗi. Ở đây, xác suất quay về cùng với quyết định, trong cùng một lượt, và nó chính là thứ bạn dùng để rẽ nhánh. Cách diễn giải của chính TypeSafe về lợi ích là: một mô hình có thể làm một tác vụ 95% thời gian nhưng “không cho biết khi nào nó rơi vào 5%” thì không thể được dùng để tự động hóa tác vụ đó; độ tin cậy cho bạn một chỗ để đặt việc chuyển lên xử lý, cho một người hoặc cho một mô hình suy luận.

Trang chủ của TypeSafe tuyên bố điều này là "Zero Hallucinations", giải thích rằng mọi quyết định đều mang một ước lượng độ tin cậy để phần mềm có thể "hành động khi độ tin cậy cao và chuyển lên xử lý cao hơn khi độ tin cậy không cao." Hãy đọc kỹ điều đó: đây là một tuyên bố về các ước lượng độ tin cậy, không phải tuyên bố rằng không có câu trả lời nào là sai. Thẻ của chính chúng tôi đóng vai trò đối trọng — tỷ lệ lỗi 0,49% trong bảy ngày kết thúc ngày 2026-09-30, trên lưu lượng truy cập của chúng tôi, do chúng tôi đo lường. Con số đó là một cửa sổ trượt, không phải một tập kiểm thử cố định: vài ngày trước đó, nó đang ghi nhận 0,57% trên cùng cửa sổ, và nó sẽ lại thay đổi.

Nơi System One nằm cạnh System Two

Từ vựng nhanh/chậm đã xuất hiện từ rất lâu trước TypeSafe. Nó bắt nguồn từ cuốn Tư duy nhanh và chậm của Kahneman, và các nhà nghiên cứu AI đã mượn dùng nó từ nhiều năm trước đó — nhãn "Hệ thống 2" đã được gắn cho chuỗi tư duy (chain-of-thought) và các mô hình lý luận có chủ đích từ lâu trước khi TypeSafe ra đời, và TypeSafe không tuyên bố mình đã đặt ra thuật ngữ nào trong hai thuật ngữ đó. Điều họ làm là áp dụng sự phân biệt này vào một ranh giới sản phẩm thay vì vào một chế độ gợi lệnh.

• Một mô hình suy luận System Two dành nhiều tính toán hơn trước khi trả lời, và trở nên giỏi hơn ở những bài toán cần điều đó. Đầu ra của nó vẫn là văn xuôi, và phần tính toán thêm đó được tính phí như token đầu ra.

• Mô hình System One theo nghĩa của TypeSafe không suy nghĩ lâu hơn để trả lời tốt hơn. Nó trả lời trong một lượt, và thứ nó đánh đổi để có được tốc độ là khả năng tạo ra bất kỳ thứ gì khác ngoài một giá trị có kiểu.

• Hai thứ này bổ trợ cho nhau trong một quy trình công việc, chứ không phải là đối thủ trong một cuộc so sánh. Một lời gọi System One xử lý những quyết định cần phải nhanh, rẻ và dễ hiểu; mô hình suy luận nhận những trường hợp mà điểm tin cậy đánh dấu là không chắc chắn. Đầu ra có kiểu chính là thứ giúp việc bàn giao trở nên gọn gàng — bạn đang chuyển một giá trị và một xác suất đến giai đoạn tiếp theo, chứ không phải một câu để phân tích lại.

Chỗ từ ngữ trở nên khó nắm bắt là ở việc coi “System One model” như một hạng mục đã được thiết lập mà các nhà cung cấp khác đã tiếp nhận. Không có bằng chứng nào cho điều đó, và không nên đọc trang này như thể đang khẳng định điều ấy. TypeSafe dùng thuật ngữ này cho lớp mô hình của riêng mình; lời miễn trừ trong card của chính chúng tôi cũng nói lên điều tương tự bằng cách lược bỏ, khi chỉ liệt kê một loại endpoint duy nhất cho một mô hình duy nhất. Nếu một phòng thí nghiệm khác bắt đầu dùng cụm từ này cho cùng kiến trúc, đó sẽ là một sự thật đáng đưa tin, và sẽ cần chính lời của họ để đưa tin về nó.

Thẻ của chúng tôi cũng liệt kê tính răng cưa như một phần của ranh giới trung thực thay vì coi đó là một điều bất ngờ: chín kiểu thất bại được đặt tên. Các mục đọc theo nghĩa đen và gián tiếp là những mục theo trực tiếp từ phép loại suy “giống mã hơn” — một mô hình trả lời câu hỏi bạn đã viết thay vì câu hỏi bạn thực sự muốn hỏi đang hành xử giống như một hàm đã làm đúng hệt những gì mã lệnh nói. Mục đếm thì không. Một mô hình “nhận diện hình dạng của một câu trả lời thay vì đếm” thì chẳng giống mã chút nào, đó là lý do khuyến nghị của chính TypeSafe là hãy đếm bằng mã, và khi thực sự cần một phán đoán, hãy hỏi một câu cho mỗi mục rồi tự cộng các câu trả lời lại.

Hai giới hạn định hình thiết kế, không phải điểm số

Cả hai đều bắt nguồn từ cùng một lý do: không có chuỗi nghĩa là không có gì để truyền phát và không có gì để gửi từng phần.

• Không truyền phát — đầu ra đầu tiên chính là câu trả lời hoàn chỉnh, vì vậy một lệnh gọi System One là một phản hồi duy nhất, không phải một luồng. Câu hỏi không phải là liệu nó có thể truyền phát hay không, mà là cái gì sẽ được truyền phát.

• Một dạng yêu cầu duy nhất — mô hình được phục vụ thông qua POST /v1/systemone trên danh mục của chúng tôi thay vì dạng chat-completions, và đó là phiên bản trung thực của một tuyên bố cũ rằng nó "nói bằng dạng yêu cầu riêng của mình." Đây là một khác biệt thực sự trong cách bạn gọi nó: một đối tượng trạng thái và một map các câu hỏi được đặt tên đi vào; một câu trả lời có cấu trúc cho mỗi câu hỏi đi ra. Bạn sẽ viết một mapper cho nó, và vì đầu ra đã được định kiểu, mapper chính là toàn bộ phần tích hợp — không có lớp phân tích phòng vệ nào bên dưới nó.

Điều đáng biết trước khi bạn kiểm thử tải: độ trễ không đồng đều giữa các loại câu hỏi. TypeSafe giải thích lý do, bằng chính lời của họ — "Đối với các lựa chọn có số lượng lớn hơn, chúng tôi thực hiện hệ thống 2 giai đoạn: chấm điểm độc lập sau đó đưa ra lựa chọn rõ ràng, do đó đôi khi có sự chậm lại." Một quyết định định tuyến 4 lựa chọn và một phân loại 200 lựa chọn là cùng một nguyên thủy về mặt lý thuyết và khối lượng công việc khác nhau trong thực tế. Trung vị hàng ngày của chúng tôi trong bảy ngày kết thúc vào 2026-09-30 lần lượt là 175, 170, 163, 161, 170, 147, 143 ms. Một ngày trong chuỗi đó, 2026-09-28, có p95 là 2.448 ms — một điểm ngoại lai thực sự của một ngày duy nhất nằm trong chuỗi một cách trung thực, nhưng không phải là hình dạng của dịch vụ.

Điều khác cần biết trước lần tích hợp đầu tiên là bạn đang kết nối tới cái gì. Bộ công cụ quanh Jev là mã nguồn mở theo các giấy phép MIT và Apache-2.0 — các SDK Python và JavaScript, một adapter trình bày cùng một client nhưng được chống lưng bởi các API LLM thông thường, mã workflow-evals, và một bộ kỹ năng agent, tất cả đều nằm trong các kho lưu trữ công khai của TypeSafe, với số sao và ngày push mới nhất vào tận 2026-09-26 và 2026-09-29. Còn mô hình thì không. Không có kho lưu trữ trọng số nào: kiến trúc, số lượng tham số, compute huấn luyện và trọng số của Jev đều chưa được công bố, và người đọc kiểm tra điều đó không nên bị đánh lừa bởi ba kho lưu trữ trong tổ chức đó vốn là các bản fork của những dự án không liên quan — một bản fork vLLM, một bản phát hành diffusion-language-model từ năm 2025, và một provider Pulumi. Không cái nào trong số đó nói lên điều gì về cách Jev được xây dựng. Câu trả lời trong một dòng là: bộ công cụ thì mở, còn mô hình thì không.

Chạy nó hôm nay và điều gì thay đổi đối với người đọc

Jev 1.13 có mặt trên OrcaRouter với tên typesafe/jev-1.13, truy cập được bằng cùng một key như hơn 200 mô hình khác, với giá niêm yết của nhà cung cấp được chuyển nguyên ở mức 0% markup. Giá trị thực tiễn của điều đó trên một trang nói về một hạng mục thì hẹp, và đáng được nói chính xác: việc dùng thử một mô hình System One không còn đòi hỏi một tài khoản riêng, một key riêng và một hóa đơn riêng cho một mô hình mà có thể bạn chưa biết là mình muốn. Nó nằm bên cạnh nửa sinh tạo của cùng một quy trình — bộ phân loại và người viết trên cùng một thông tin xác thực, ở cùng một nơi, kèm theo số liệu về những gì bạn thực sự đã gọi.

Không có gì ở đây thay đổi bản chất của mô hình. Nó ra mắt vào 2026-09-15 và TypeSafe vẫn mô tả nó là bản truy cập sớm; bản chất của nó kể từ đó không hề thay đổi. Điều đã thay đổi vào 2026-09-24 là giờ đây người đọc có thể biết được chi phí thực tế của nó mà không cần cam kết với mối quan hệ nhà cung cấp thứ hai trước. Nếu bạn đã chờ xem liệu danh mục này có đáng để làm nguyên mẫu hay không, thì đó chính là điều đã thay đổi.