TypeSafe ra mắt Jev ngày 15/09/2026 với hai con số rất to: nhanh hơn 40 đến 200 lần, rẻ hơn tới 444 lần so với LLM. Năm ngày sau tôi đo nó trên chiếc M3 Max ở nhà, đặt cạnh Gemini 2.5 Flash-Lite qua cùng một gateway, cho cùng một quyết định. Jev nhanh hơn 1.2 lần và rẻ hơn 1.4 lần.
Tôi không nghĩ TypeSafe nói dối. Con số của họ và con số của tôi đều đúng, chỉ là đo hai thứ khác nhau. Bài này kể tôi đo thế nào, vì sao phép đo được thiết kế như vậy, và vì sao con số về Jev dao động dữ dội theo ba thứ: model đem ra so, độ dài input, và câu hỏi có được tách nhỏ hay không. Nhưng tôi cũng không định viết một bài bênh Jev. Ngay cả khi dùng đúng cách, nó vẫn thua model frontier vài điểm phần trăm ở bài toán phân loại nhiều lớp, và thua một classifier truyền thống khá xa khi bạn có sẵn dữ liệu gán nhãn.
Cách làm cũng đáng kể một chút. Tôi cho một Claude Code session chạy các phép đo, một session khác đọc toàn bộ docs chính chủ và các bản eval độc lập, một session thứ ba tính lại từng con số từ raw data, rồi Codex soát chéo lần cuối. Các bên bắt được của nhau ít nhất sáu lỗi. Hai trong số đó mà lọt lên bài thì thành sai sót công khai. Lỗi thứ sáu thú vị nhất: nó do chính quá trình review sinh ra. Hai reviewer cùng nghiêng về một hướng, người đo sửa theo, và chỉ khi quay lại đọc payload đã gửi thật thì mới thấy bản sửa sai. Tôi nhắc chuyện này vì nó chính là thông điệp của bài: con số về model rất dễ sai theo những cách rất bình thường, và hiện vật gốc là thứ duy nhất phân xử được.
Jev là gì
Jev là thứ TypeSafe gọi là “System One model”. Nó không sinh text. Bạn gửi một state (text hoặc JSON) cùng một danh sách câu hỏi, và nó trả về quyết định có kiểu kèm xác suất. Mọi câu hỏi được đánh giá song song trong cùng một lượt.
Có ba loại câu hỏi (primitive):
| Primitive | Hỏi gì | Trả về |
|---|---|---|
choice | Chọn một trong N lựa chọn (tối đa 255) | lựa chọn, phân phối xác suất, confidence |
score | Chấm trên thang có thứ tự (2 đến 10 mức) | điểm kỳ vọng, phân phối xác suất, confidence |
noul | Xác suất một mệnh đề là đúng | một số từ 0 đến 1, không có confidence |
Theo trang Models: model id jev-1.13.0 (alias jev-latest, jev-preview), giá $0.042 cho mỗi triệu token input, output miễn phí, context 64k token mỗi request và 32k cho state cộng câu hỏi dài nhất. Chỉ dùng qua API hosted, không fine-tune hay LoRA được. Endpoint gốc là POST https://api.typesafe.ai/v1/systemone.
Nếu bạn quen LLM, cách nghĩ gần nhất là: một classifier zero-shot rất nhanh, nhận câu hỏi bằng ngôn ngữ tự nhiên, và không bao giờ trả về JSON hỏng vì nó không sinh JSON.
Những gì bài này không đo
Tôi nói trước, không để cuối bài:
- Head-to-head chỉ có một task, một prompt, 12 vòng. Đây là phép đo latency, chi phí và độ ổn định, không phải phép đo accuracy.
- Ba model trả cùng đáp án ở task này, nhưng điều đó không nói gì về case khó hay case bị tấn công.
- Prompt của chat model là một prompt viết một lần, không tune.
- Tất cả đi qua Vercel AI Gateway free tier, request của Jev đi vòng qua Frankfurt, và free tier có thể bị bóp rate limit.
- Không so được với Claude Haiku 4.5, vì free tier của Vercel trả 403 cho model đó.
- Phép đo token dùng một câu tiếng Anh lặp lại, chưa phủ tiếng Việt hay nội dung đa dạng.
- Tổng chi phí cho mọi phép đo trong bài dưới $0.002.
Đường truy cập: vì sao phải qua Vercel
Tôi vẫn đang nằm trong waitlist của TypeSafe, chưa có key trực tiếp. Cloudflare Workers AI có route cho typesafe/jev, nhưng tài khoản của tôi nhận về 402 Insufficient balance: đây là model đối tác trả phí, phải nạp credit hoặc dùng BYOK với key TypeSafe mà tôi chưa có. Đường duy nhất chạy được với tôi là Vercel AI Gateway free tier:
curl https://ai-gateway.vercel.sh/typesafe/v1/systemone \
-H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "typesafe-ai/jev",
"state": "Deploy step failed: connection refused to 127.0.0.1:41700",
"questions": {
"is_network": {"type": "noul", "instructions": "This is a network or connectivity failure"}
}
}'Trường model ở top level là bắt buộc. Thiếu nó, gateway trả 400 model: Invalid input: expected string, received undefined.
Case cụ thể: một quyết định định tuyến
Tôi không muốn đo trên câu hỏi đồ chơi, nên lấy một quyết định có thật trong hệ agent của tôi: một task code mới vào, nên giao cho worker nào, rủi ro cỡ nào nếu merge không review, và có cần cập nhật docs không. State nguyên văn:
{"task": "Add a --json flag to the sweep script and update USAGE.md", "files_touched": 2, "diff_lines": 47}Jev nhận ba câu hỏi trong một call:
{
"worker": {
"type": "choice",
"instructions": "Which worker class should handle this task",
"criteria": {
"cheap_loop": "A small mechanical edit, no design judgement",
"cli_agent": "Needs repo context and multi-file edits",
"frontier": "Ambiguous spec or cross-module design work"
}
},
"risk": {
"type": "score",
"instructions": "How risky is landing this change without review",
"criteria": ["Trivial, safe to auto-merge", "Ordinary, a glance is enough", "Needs a careful read", "Do not land without a human"]
},
"needs_docs": {"type": "noul", "instructions": "This change requires a USAGE.md update"}
}Hai chat model nhận đúng ba quyết định đó, viết thành schema JSON trong system prompt, với temperature: 0 và max_tokens: 80. State được gửi nguyên văn làm user message. System prompt (xuống dòng cho dễ đọc, bản gốc là một dòng):
You route coding tasks. Reply with ONLY a JSON object, no prose, no markdown fence.
Schema: {"worker":"cheap_loop|cli_agent|frontier","risk":0|1|2|3,"needs_docs":true|false}.
worker: cheap_loop=small mechanical edit no design judgement; cli_agent=needs repo context and multi-file edits;
frontier=ambiguous spec or cross-module design work. risk of landing without review: 0=trivial safe to auto-merge,
1=ordinary a glance is enough, 2=needs a careful read, 3=do not land without a human.
needs_docs: does this require a USAGE.md update.Phương pháp, và vì sao thiết kế như vậy
Cùng một gateway cho cả ba model. Đây là quyết định quan trọng nhất. Cả ba đi chung đoạn đường từ máy tôi tới Vercel, nên khác biệt ở đoạn đó được giảm tối đa (dù latency mạng vẫn dao động theo thời điểm, việc gọi xen kẽ bên dưới xử lý phần đó). Nó không san bằng mọi thứ: từ gateway, mỗi request vẫn đi tới hạ tầng riêng của TypeSafe, Google hay OpenAI. Vì vậy phần chênh còn lại là của model cộng hạ tầng phục vụ của từng hãng, đúng thứ một người dùng gateway sẽ trải nghiệm. Tác giả ickma2311/jev-baselines-eval, bản eval chặt chẽ nhất tôi đọc được, ghi thẳng rằng đây là control họ biết là cần nhưng chưa chạy. Tôi chưa tìm thấy bản công bố nào khác chạy control này, nhưng không dám khẳng định mình là người đầu tiên.
Gọi xen kẽ. 12 vòng, mỗi vòng gọi Jev, rồi Flash-Lite, rồi nano. Nếu chạy hết 12 call của model này rồi mới tới model kia, một đợt mạng chậm lúc 3 giờ sáng có thể rơi trọn vào một model và biến thành “model đó chậm”.
Chỉ tính latency trên HTTP 200. Một call bị 429 trả về trong khoảng 290ms, nhanh hơn call thật. Trộn vào là kéo trung vị xuống một cách giả tạo.
Báo trung vị và max, không báo p95. Với 12 mẫu, p95 gần như là mẫu lớn nhất hoặc lớn thứ nhì, tùy công thức. Ở vòng đầu, session đo báo p95 của Flash-Lite là 957ms. Tính lại từ raw data thì call chậm nhất là 1,479ms, còn p95 nội suy là 1,192ms. Cùng dữ liệu, ba công thức, ba câu chuyện. Ở cỡ mẫu này trung vị và max trung thực hơn.
Bốn kích thước state cho phép đo token. Phần này tôi giải thích ở phép đo 3, vì nó là phần đáng đọc nhất của bài.
Phép đo 1: latency từ Việt Nam
Payload một câu Noul (request ở mục trên), gọi liên tục:
| Cách đo | n (HTTP 200) | Trung vị | Max |
|---|---|---|---|
| Kết nối mới mỗi call | 25 | 670ms | 818ms |
| Tái sử dụng kết nối, bỏ call đầu (call đầu phải bắt tay TLS) | 13 | 530ms | 708ms |
| Riêng thời gian tới khi bắt tay TLS xong | 25 | 125ms |
TypeSafe viết trong bài ra mắt: “End-to-end response time is 70ms-500ms for TypeSafe.” Từ nhà tôi, Jev nằm trên mép trên của khoảng đó. Header response của Jev gợi ý một lý do:
x-vercel-id: hkg1::fra1::...Request vào edge Hong Kong rồi đi ra qua Frankfurt trước khi tới TypeSafe. Để so, jev-phishing-bench đo từ Pháp được 239ms trung vị, trong đó riêng nền mạng đã là 163ms. Trừ mạng đi, phần còn lại ở đó chỉ khoảng 76ms. Cùng bảng đó, Haiku 4.5 là 687ms với nền mạng 18ms.
Vậy con số 530ms của tôi đo “Jev đi qua Vercel từ Việt Nam”, không đo “Jev”. Tôi chưa chứng minh được đường vòng Frankfurt là nguyên nhân duy nhất, nhưng viết lẫn hai thứ này là oan cho model.
Một phép đo nhỏ khác đáng biết: ickma2311 ghi 0.448s cho một câu boolean với khoảng 5 token input, và 0.432s cho một câu choice 151 nhãn với khoảng 3,000 token (6 và 8 call). Input tăng khoảng 600 lần mà latency gần như không đổi, dù loại câu hỏi cũng đổi theo. LLM thì chậm dần theo số token phải sinh ra, còn Jev không sinh token.
Phép đo 2: head-to-head
Cả ba model đi tới cùng một quyết định: worker = cli_agent, risk = 1, needs_docs = true, với điều kiện làm tròn risk của Jev và coi needs_docs trên 0.5 là có. Call Jev đầu tiên trả risk = 1.22 và needs_docs = 0.94, vì score là điểm kỳ vọng tính từ phân phối xác suất trên bốn mức, còn noul là xác suất.
| Model | OK | Trung vị | Max | Token in | Token out | $ / 100k call |
|---|---|---|---|---|---|---|
typesafe-ai/jev | 11/12 | 667ms | 734ms | 462 | 74 (miễn phí) | $1.94 |
google/gemini-2.5-flash-lite | 12/12 | 820ms | 1,479ms | 185 đến 186 | 17 đến 21 | $2.65 |
openai/gpt-4.1-nano | 12/12 | 1,110ms | 1,607ms | 185 | 16 | $2.49 |
Mỗi call chứa cả ba quyết định. Giá dùng để tính: hai chat model $0.10 input và $0.40 output mỗi triệu token (khớp với chi phí gateway báo về từng call); Jev $0.042 input, output miễn phí. Chi phí của Flash-Lite là trung bình, vì 3 trong 12 call trả ít token hơn.
Kết quả: Jev nhanh hơn Flash-Lite 1.2 lần và rẻ hơn 1.4 lần. So với nano: nhanh hơn 1.7 lần, rẻ hơn 1.3 lần.
Call hỏng duy nhất của Jev (vòng 5) là TimeoutError phía client sau 45 giây, không phải 429 và không phải model từ chối. Nguyên nhân thì tôi không biết. Với người dùng, đó vẫn là một call thất bại, và nó nằm cách xa mức 734ms của mọi call còn lại. Tôi ghi nó ra đây thay vì lặng lẽ loại khỏi bảng.
Vì sao không phải 40 lần
Câu nguyên văn của TypeSafe: “This can range from 40x-200x faster for the same levels of frontier intelligence for System One shaped queries.” Họ so với model frontier, loại “End-to-end response time is 3 to 329 seconds”. Và họ tự viết thêm một câu mà ít người trích: “This is where the claims of 193.6x faster, 444.6x cheaper on our home page comes from, and we expect that these are on the higher end of real world gains.”
Tỷ lệ là thuộc tính của một cặp model, không phải của riêng Jev:
| Jev so với | Nhanh hơn | Rẻ hơn | Nguồn |
|---|---|---|---|
| Model frontier, theo hãng | 40 đến 200 lần | 444.6 lần | TypeSafe |
| GPT-5.6 Terra | khoảng 5 lần | 41 đến 50 lần | 4esv/jev-eval |
| Claude Haiku 4.5, cùng 5 câu hỏi tín hiệu | khoảng 5 lần | khoảng 27 lần | jev-phishing-bench |
| Gemini 2.5 Flash-Lite, cùng 3 quyết định | 1.2 lần | 1.4 lần | bài này |
Cả bốn dòng đều đúng trong điều kiện của nó. Con số của hãng đến từ các workflow của họ, so với model frontier có reasoning và yêu cầu model trả về xác suất, còn chat model của tôi chỉ trả quyết định rời rạc. Nếu hệ thống của bạn đang gọi một model frontier cho mỗi quyết định nhỏ, khoảng cách có thể lớn cỡ hãng nói, nhưng hãy đo trên workload của chính bạn. Nếu bạn đã dùng một flash model rẻ, khoảng cách còn lại nhỏ hơn nhiều, và phép đo 3 cho thấy về chi phí nó khó vượt quá khoảng 2.4 lần.
Phép đo 3: overhead cố định hay tỉ lệ
Nhìn bảng head-to-head, Jev bị tính 462 token input trong khi chat model chỉ 185. Câu hỏi là phần chênh đó đến từ đâu. Có hai khả năng, và chúng dẫn tới hai kết luận ngược nhau về giá:
- Cố định: Jev cộng thêm một khoản framing mỗi call. State càng lớn, khoản này càng bị pha loãng, và Jev càng rẻ tương đối.
- Tỉ lệ: Jev đếm cùng một đoạn text ra nhiều token hơn. Khi đó chênh lệch lớn dần theo state và không bao giờ được pha loãng.
4esv từng ghi nhận Jev đếm gần gấp đôi token trên cùng một câu (340 so với 162), đọc lên nghe như khả năng thứ hai. Cách duy nhất để phân biệt là đo ở nhiều kích thước. Tôi gửi cùng một câu tiếng Anh lặp lại 1, 8, 40 và 160 lần. Phía Jev là một Noul "The text mentions a failure". Phía Gemini Flash-Lite là prompt "The text mentions a failure. Answer yes or no." đặt trước đoạn văn, và nó trả đúng một token Yes ở cả bốn lần. Hai bên hỏi cùng một câu hỏi.
| State | Ký tự | Gemini in | Jev in | Chênh | Tỷ lệ | Ai rẻ hơn |
|---|---|---|---|---|---|---|
| tiny | 161 | 39 | 298 | 259 | 7.64 | Gemini, 2.9 lần |
| small | 1,288 | 221 | 480 | 259 | 2.17 | Jev, 1.1 lần |
| medium | 6,440 | 1,053 | 1,312 | 259 | 1.25 | Jev, 1.9 lần |
| large | 25,760 | 4,173 | 4,432 | 259 | 1.06 | Jev, 2.2 lần |
Chênh lệch đúng 259 token ở cả bốn kích thước, trên một dải rộng 160 lần. Mỗi lần lặp câu văn, cả hai bên đều cộng thêm đúng 26 token. Overhead là cố định, không có “phạt tokenizer” nào ở đây.
Bài học phương pháp ở đây là lý do tôi viết bài này. Cột tỷ lệ là cột đánh lừa: nó trượt từ 7.64 xuống 1.06, và nếu bạn chỉ đo một điểm, bạn sẽ thấy “Jev tốn gấp 7 lần” hoặc “gần như ngang nhau” tùy may rủi. Chỉ cột chênh, đứng yên qua dải kích thước rộng 160 lần, mới cho biết overhead là cố định. Một điểm đo đơn lẻ không bao giờ phân biệt được cố định với tỉ lệ. Quan sát 340 so với 162 của 4esv khớp với cách giải thích overhead cố định áp lên một câu ngắn, nhưng tôi không nói nó được giải thích trọn vẹn: 162 là số token của Terra với prompt của họ, và khoản chênh của họ là 178 chứ không phải 259.
Hai điều cần đi kèm con số 259. Thứ nhất, nó là hằng số cho một bộ câu hỏi cụ thể (một Noul) so với một prompt chat cụ thể, không phải hằng số chung của Jev. Ở head-to-head với ba câu hỏi, khoản chênh là 276 đến 277 token. Thứ hai, việc hai bên đếm cùng số token cho câu văn này chỉ đúng với câu văn này. Tôi chưa đo với tiếng Việt hay nội dung khác, nên không suy rộng thêm.
Hệ quả: lợi thế giá có sàn và có trần
Cột cuối của bảng là chỗ tôi thấy thú vị nhất. Cùng một câu hỏi yes/no, cùng một đoạn text, ở kích thước nhỏ nhất Jev đắt hơn Flash-Lite 2.9 lần: 298 token nhân $0.042, so với 39 token nhân $0.10 cộng 1 token output. Phía chat chỉ cần khoảng 40 token cho cả câu hỏi lẫn text, trong khi Jev báo nhiều hơn 259 token cho cùng câu hỏi và cùng text.
Viết thành công thức, với D là khoản chênh token và out là số token output của chat model, Jev rẻ hơn khi tổng input phía chat vượt:
chat_in > (0.042 × D − 0.40 × out) / 0.058Với một câu yes/no (D = 259, out = 1), điểm hoà là khoảng 181 token input phía chat. Với task định tuyến (D = 277, out = 21), điểm hoà là 56 token. Request chat của task này có 185 token, trong đó state chỉ chiếm vài chục, phần còn lại là system prompt. Riêng system prompt đã vượt xa điểm hoà, nên nếu khoản chênh giữ nguyên và output vẫn ngắn khi state lớn lên, với ba quyết định có cấu trúc, Jev rẻ hơn ở mọi kích thước state. Tôi mới đo task này ở một kích thước state, nên đây là suy ra từ công thức chứ chưa phải số đo. Hai kết quả không mâu thuẫn. Chúng khác nhau ở chỗ phía chat cần bao nhiêu token để diễn đạt câu hỏi.
Ở chiều ngược lại có trần. Khi state lớn dần, khoản chênh bị pha loãng và tỷ lệ tiến về tỷ lệ giá gốc: $0.100 chia $0.042 bằng 2.38 lần. Tính theo công thức ở khoảng 32k token (giới hạn context của Jev cho state cộng câu hỏi dài nhất), tỷ lệ là khoảng 2.36 đến 2.37 lần. Đây là ngoại suy, và có điều kiện: hai bên đếm token như nhau và output của chat model ngắn. Nó là trần khi so với một flash model giá $0.10. So với model đắt hơn, trần cao hơn tương ứng, như bảng ở phép đo 2.
Quy luật tôi rút ra: hai cấu hình tôi đo có khoản chênh 259 và 276 đến 277 token so với một prompt chat gọn tương đương. Với khoản chênh cỡ đó, Jev thắng về giá khi tổng input phía chat vượt khoảng 50 đến 200 token, tùy output dài hay ngắn. Sàn có thật, nhưng thấp. Kiểm tra yes/no một câu trên text rất ngắn là trường hợp duy nhất trong các phép đo của tôi mà Jev thua về giá.
Hai kết quả phụ đi ngược kỳ vọng
Độ ổn định. Tôi gửi cùng một request 12 lần:
| Model | Số output khác nhau |
|---|---|
gpt-4.1-nano | 1 |
gemini-2.5-flash-lite | 2, chỉ khác khoảng trắng trong JSON |
jev (11 call thành công) | choice luôn là cli_agent, nhưng risk nhận 7 giá trị (1.19 đến 1.28), needs_docs nhận 2 (0.93, 0.94), confidence của worker chạy từ 0.62 đến 0.75 |
Trang docs của TypeSafe viết Jev “extremely consistent, meaning you should expect quantitatively similar outputs for semantically similar inputs”. Theo nghĩa đó thì đúng: dao động chỉ khoảng ±0.05. Nhưng nó không tất định. Một ngưỡng đặt ở 1.25 trên điểm risk sẽ lật qua lật lại trên cùng một input. Các bản đo khác thấy cùng hiện tượng ở mức nhãn: 4esv ghi 1.7% (intent) và 3.3% (sentiment) nhãn bị đổi trên input giống hệt; jev-phishing-bench ghi 2.2% giữa hai lượt chạy liền nhau và 1.0% trên 200 email chạy lại sau 12 giờ, trong khi Haiku 4.5 là 0.7% trên 300 email.
Lỗi parse. Cả hai chat model trả JSON hợp lệ 12/12, không lần nào phải gỡ markdown fence. Luận điểm “dùng Jev thì xóa được code xử lý lỗi parse” không mua được gì đo đếm được trong phép đo này. 4esv cũng thấy tương tự ở quy mô lớn hơn: 0 lỗi trên 1,800 call của Jev, và cũng 0 lỗi trên 1,800 call của Terra khi dùng strict JSON schema. Muốn chứng minh lợi thế này phải dùng schema khó hơn hoặc model ồn hơn. Tôi nói thẳng là mình chưa chứng minh được.
Accuracy: phần dễ trích sai nhất
Tôi không đo accuracy. Nhưng đây là phần người ta trích nhiều nhất, và cũng trích sai nhiều nhất.
Con số 67.8% của hãng không phải accuracy
Bảng trên evals.typesafe.ai, bốn workflow (security incidents, agent trace observability, invoice processing, customer service):
| Model | Điểm |
|---|---|
| Sol | 74.1% |
| Opus 5 | 73.1% |
| Terra | 67.9% |
| Jev | 67.8% |
| Sonnet 5 | 67.8% |
| Luna | 66.8% |
| DS v4 pro | 65.5% |
| DS v4 flash | 64.4% |
| Haiku 4.5 | 53.6% |
Câu quan trọng nằm trong phần phương pháp: “the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking”. Đáp án chuẩn do hai LLM khác sinh ra. Con số này đo mức đồng thuận với hai model đó, không đo mức đúng. Chỗ cả hai model frontier cùng sai, model trả lời đúng lại bị trừ điểm. Vì vậy bài dev.to trích “Jev hơn Luna 1 điểm” và bản research trích “ngang Terra” đều đúng với bảng, nhưng cả hai chưa xác lập được accuracy theo nhãn kiểm chứng độc lập. TypeSafe có tự ghi giới hạn: các workflow do chính team họ viết nên “some bias could exist”, và riêng query demo trong bài ra mắt thì “highly simplified”. Tôi ghi nhận sự minh bạch đó, nhưng nó không sửa được bộ đáp án.
Các bản đo độc lập, xếp theo cách đặt câu hỏi
| Nguồn | Cách hỏi Jev | Kết quả | Đối chứng |
|---|---|---|---|
| jev-phishing-bench, 2,000 email | Một câu verdict duy nhất | 62.6% | Haiku 4.5: 81.3% |
| jev-phishing-bench, nửa tập kiểm tra | 5 câu hỏi tín hiệu, ghép bằng logistic regression | 95.0% | Haiku cùng 5 tín hiệu: 93.2% (p = 0.063); regex hai feature: 91.8% |
| scienthoon/jev-ood-calibration | 3 benchmark công khai | 86.1% đến 94.2%, ECE 0.024 đến 0.032 | |
| scienthoon, 900 ticket tổng hợp | Queue (choice) / tức giận (noul) / độ ưu tiên (score) | 89.0% / 91.7% / 44.7% | Chance của độ ưu tiên: 25% |
| simonmesmith/jev-bbq-experiment, 58,492 câu | Choice 3 lựa chọn | 97.28% | Tác giả không so với model khác |
| ickma2311, Banking77 (n = 208) | Choice 77 lựa chọn | 83.2% | Terra 87.5%, gpt-5.4-nano 79.3%, bge-small + LR 93.3% |
| ickma2311, CLINC150 zero-shot (n = 200) | Choice 151 lựa chọn (150 intent và oos) | 87.0% | Terra 91.5%, gpt-5.4-nano 79.5% |
| 4esv, Banking77 / SST-5 / IMDB | Choice / Score / Noul | 78% / 57% / 97% | Terra 85% / 59% / 97% |
Ba câu chuyện đáng kể ra từ bảng này.
Phishing: 62.6% nói về cách hỏi nhiều hơn về năng lực. Nếu chỉ trích dòng đầu, bạn kết luận Jev thua Haiku 19 điểm. Nhưng 62.6% là kết quả của một câu verdict duy nhất. Tác giả hỏi Jev chín câu trong cùng một call, trong đó có năm câu tín hiệu hẹp (domain người gửi khác domain link, link trỏ tới hosting miễn phí, có yêu cầu đăng nhập…). Ghép năm tín hiệu đó bằng một logistic regression được fit trên nửa tập kia, Jev đạt 95.0% trên nửa tập giữ riêng để kiểm tra. Công bằng mà nói, phần tăng này có đóng góp của classifier được fit, và năm câu tín hiệu được viết sau khi tác giả đọc taxonomy của chính tập dữ liệu. Haiku dùng cùng năm câu hỏi đạt 93.2%, chênh lệch không có ý nghĩa thống kê (p = 0.063), và AUROC của Haiku còn nhỉnh hơn. Kết luận nguyên văn của tác giả: “about 27 times cheaper and 5 times faster than Haiku for signals of comparable quality, on a dataset that a regex already separates at 91.8%.” Chú ý vế cuối: tập dữ liệu này dễ, regex đã tách được 91.8%. Trang jaggedness của TypeSafe cũng ghi rõ việc cần tránh: “Hiding several judgments inside one question.”
Độ ưu tiên 44.7% đo chuyện khác. Trong tập ticket của scienthoon, nhãn độ ưu tiên được định nghĩa bằng một luật tổ chức không có trong text (khách hàng gold hoặc enterprise được cộng một bậc). README viết thẳng “No zero-shot model can recover it”. Nên 44.7% không phải “Jev kém”. Câu hỏi thật là Jev có biết mình không biết hay không, và câu trả lời là không: ở câu hỏi này nó gán trung bình 0.74 xác suất cho lựa chọn của mình, và cần nhiệt độ 3.4 để xác suất trở nên trung thực. Chiều sai còn đổi theo loại câu hỏi: noul thì thiếu tự tin (T = 0.66), choice và score thì quá tự tin (T 3.3 đến 3.4). Bạn phải calibrate riêng cho từng loại câu hỏi. Cũng README đó mở đầu bằng một kết quả tích cực: “On three public benchmarks Jev is very accurate and its probabilities need almost no correction.” Và một lời khuyên thực dụng: đừng đặt ngưỡng trên trường confidence, vì nó “never better than the max probability and sometimes much worse”.
Có điểm yếu thật, ngay trong đúng hình dạng thiết kế. Tôi từng suýt viết rằng mọi con số xấu về Jev đều do dùng sai cách. Không đúng. Banking77 là một câu Choice 77 lựa chọn, đúng pattern intent routing mà chính TypeSafe giới thiệu, vậy mà Jev vẫn thấp hơn Terra 4 đến 7 điểm tùy bản đo. CLINC150 thấp hơn Terra 4.5 điểm, dù cao hơn nano 7.5 điểm. Và khi có sẵn 10,003 mẫu gán nhãn, một encoder bge-small-en-v1.5 cộng logistic regression chạy trên laptop trong 9ms, không mất phí API mỗi call, thắng Jev 10 điểm. Nếu bạn có nhãn cùng phân phối với dữ liệu thật, hãy thử một baseline supervised trước khi nghĩ tới Jev.
Hai con số của BBQ (99.96% ở câu mơ hồ, 94.60% ở câu đủ thông tin) rất ấn tượng, nhưng tác giả nói rõ họ không so với model khác chạy dưới prompt và giao thức khác. Tôi cũng không so. Một chi tiết nhỏ đáng giữ: trong 13 lần Jev đoán khi không đủ căn cứ, 12 lần đi theo hướng khuôn mẫu.
Trang hãng tự khai chỗ yếu
Tôi phải khen TypeSafe một điểm: họ có hẳn trang Jev 1.13 jaggedness (review lần cuối 17/09/2026) liệt kê chín chế độ hỏng. Ba chỗ tôi thấy ai định dùng Jev cũng nên đọc.
Nội dung đối kháng. Nguyên văn: “State is data, and jev-1.13 does not treat it as hostile by default. Content written to adversarially steer the model, whether that is an injected instruction, a deliberately misleading framing, or text that argues for its own classification, can move the answer.” Trong khi một trong những use case được quảng bá nhiều nhất là làm guardrail chặn tool call nguy hiểm, và docs có hẳn một cookbook LLM guardrails. Một guardrail có thể bị chính input nó đang canh bẻ lái thì không nên là lớp bảo vệ duy nhất.
Không có bất biến cấu trúc. Ví dụ của chính hãng: câu “Is the customer asking for a refund?” hỏi bằng Noul ra 0.22, hỏi bằng Choice yes/no ra yes 0.01 với confidence 0.97. Một câu và phủ định của nó hỏi bằng hai Noul cho ra 0.72 và 0.47, cộng lại 1.19. Ngưỡng đã tune trên Noul thì đừng mang sang Choice.
Context rot. “Accuracy falls as the state grows with content unrelated to the decision.” Lọc trong code trước khi gửi.
Trang đó còn ghi Jev “does not count reliably”, so sánh ngày tháng thì “unreliable”, toán nên để code làm, và nó “not trained to generate text”. Mấy việc này code làm tốt hơn và miễn phí.
Những con số đừng đóng đinh
Rate limit. Trang Models ghi 1,200 request mỗi phút, kèm cảnh báo “Rate limits are adjusting dynamically” và “can change without notice”. Header của Vercel free tier ghi 30 request mỗi phút, nhưng 20 call liên tiếp của tôi đã dính 6 lần 429. Có thể do các request trước đó còn nằm trong cùng cửa sổ 60 giây, tôi không loại trừ được. ickma2311 chạy ngày 18/09 bị bóp còn khoảng 1 request mỗi phút sau đợt đầu, 200 mục mất khoảng 3.5 giờ. Viết “đang biến động, đo lại khi bạn dùng” là trung thực nhất.
Throughput của BBQ. 58,492 câu trong 7.75 phút nghe như hơn 7,500 request mỗi phút. Thật ra họ gói tối đa 16 câu hỏi độc lập vào một request, chạy 4 request song song: 3,656 request, khoảng 470 request mỗi phút, vẫn dưới mức 1,200 trong docs. Đó là throughput câu hỏi, không phải tốc độ request.
Phiên bản model. Qua Vercel, response chỉ trả typesafe-ai/jev, không có số phiên bản. scienthoon cảnh báo model đằng sau id này có thể đổi mà không báo. Phép đo của tôi chạy ngày 20/09/2026; các benchmark tôi trích chạy vào những ngày khác, từ 17 đến 19/09.
Chạy lại
Toàn bộ payload nằm trong script repro.py, chỉ dùng thư viện chuẩn của Python:
AI_GATEWAY_API_KEY=vck_... python3 repro.py latency
AI_GATEWAY_API_KEY=vck_... python3 repro.py headtohead
AI_GATEWAY_API_KEY=vck_... python3 repro.py overhead
AI_GATEWAY_API_KEY=vck_... python3 repro.py promptsizeChạy hết tốn dưới $0.002 theo giá niêm yết. Free tier có thể trả 429 sớm hơn giới hạn ghi trong header, nên có khi phải chạy lại. Script chứa đúng các payload đã gửi. Có một khác biệt về cách đo latency: số trong bài đo bằng curl với -w để in timing từng call, bản “kết nối mới” gọi curl riêng cho mỗi request, bản “tái sử dụng kết nối” gửi 20 request trong một lệnh curl. repro.py latency dùng urllib và mở kết nối mới mỗi call, nên chỉ tương ứng với bản đầu. Raw data, đóng băng đúng bản tôi dùng để viết bài, gồm cả bản ghi lỗi phía client của call bị timeout:
headtohead.json: mọi response của 36 call head-to-headtoken-overhead.json: request và response đầy đủ của phép đo 3latency-cold-n25.txt,latency-warm-n20.txt: timing từng call của curl (giây), gồm cả 6 lần 429
Nếu bạn tính lại từ raw data ra con số khác tôi, số của bạn thắng. Nhắn tôi, tôi sửa bài.
Tôi sẽ dùng Jev vào đâu
Tôi sẽ thử Jev cho những quyết định hẹp, lặp lại hàng nghìn lần mỗi ngày, trên state dài hơn vài trăm token: định tuyến task cho agent, lọc đoạn RAG, gắn tín hiệu cho log. Mỗi phán đoán tách thành một câu hỏi nhỏ, ghép trong code, calibrate riêng cho từng loại câu hỏi trên dữ liệu của chính tôi, và đo độ dao động trên dữ liệu đó trước khi chọn ngưỡng. Tôi sẽ không dùng nó làm lớp guardrail duy nhất trước input không tin cậy, không dùng khi đã có nhãn cùng phân phối mà chưa thử một classifier supervised, và không dùng cho kiểm tra yes/no một câu trên text ngắn, chỗ mà một flash model rẻ còn rẻ hơn.
Tôi vẫn đang chờ key TypeSafe. Có key rồi, việc đầu tiên tôi làm là chạy lại phép đo 1 không qua Frankfurt. Khi đó bài này sẽ có thêm một dòng.