2026-09-29 #ai#llm#jev#open-source

Jev — khi AI chỉ ra quyết định, không viết văn

TypeSafe AI ra mắt Jev — model chỉ trả về quyết định có kiểu dữ liệu và xác suất, không sinh text. Cơ chế hoạt động và các bản open-source thay thế.

Gần như mọi “AI mới” từ 2022 tới giờ đều là biến thể của LLM — sinh văn bản từng từ một. Mạnh cho việc viết, nhưng lại thừa và chậm khi thứ phần mềm cần chỉ là một quyết định: tin nhắn này có phải yêu cầu hoàn tiền không, ticket này thuộc phòng ban nào, bug này nghiêm trọng cỡ nào.

Ngày 15/9/2026, TypeSafe AI (founder Diogo Almeida, cựu kỹ sư OpenAI làm RLHF/ChatGPT/GPT-4) ra mắt Jev — model đầu tiên trong một class họ gọi là “System One Model”, đi kèm vòng seed $40M do DCVC dẫn đầu. Jev không viết văn. Nó chỉ trả lời câu hỏi có sẵn tập câu trả lời, kèm xác suất.

Cơ chế hoạt động

Cách dễ hình dung nhất: Jev là một if thông minh. Bạn định nghĩa trước toàn bộ không gian câu trả lời có thể (tập nhãn, thang điểm, hoặc yes/no), Jev chỉ chọn trong tập đó — nghĩa là nó không bao giờ trả lời sai kiểu dữ liệu.

LLM thông thường:  input text → sinh text tự do → code parse lại
Jev:                state + câu hỏi có kiểu → giá trị đúng kiểu + xác suất

Lấy mẫu song song, không tự hồi quy

Đây là khác biệt kiến trúc quan trọng nhất. LLM thường sinh từng token một, token sau phụ thuộc token trước — muốn câu trả lời N từ thì chạy N lần suy luận tuần tự. Jev dùng parallel sampler: sinh toàn bộ câu trả lời trong một lượt duy nhất. Gửi 13 câu hỏi cùng share một state, Jev trả lời cả 13 song song, và một câu trả lời không trở thành context cho câu khác. TypeSafe đo được: cách này nhanh hơn 10x, rẻ hơn 12.2x so với 13 lệnh gọi tuần tự.

RLCD thay vì RLHF

LLM thường train bằng RLHF — tối ưu cho câu trả lời nghe hợp lý với người. Jev train bằng RLCD (Reinforcement Learning for Calibrated Decisions) — tối ưu cho xác suất đúng về mặt thống kê: nếu Jev nói “90% tin điều này đúng”, thì trên một tập lớn dự đoán cùng gắn 90%, khoảng 90% trong số đó phải thực sự đúng.

Đây là ý tưởng lõi của toàn bộ sản phẩm — mọi thứ còn lại (ba loại câu hỏi, dùng confidence để route, các giới hạn) đều là hệ quả của việc “con số xác suất phải đáng tin”, không phải “câu trả lời phải nghe hay”.

Ba loại câu hỏi

LoạiTrả vềVí dụ
Noul (yes/no)1 xác suất 0–1{"type":"noul","instructions":"Khách có yêu cầu hoàn tiền không?"} → {"noul": 0.93}
Choice (chọn 1/N)nhãn + phân phối xác suất + confidence{"type":"choice","criteria":{"billing":"Thanh toán","technical":"Lỗi kỹ thuật"}} → {"choice":"billing","confidence":0.84}
Score (thang có thứ tự)vị trí trên thang, trung bình có trọng số{"type":"score","criteria":["Cosmetic","Broken có workaround","Blocking"]} → {"score":1.43,"confidence":0.35}
const { answers } = await client.systemOne({
  state: userMessage,
  questions: {
    category: choice('Phân loại tin nhắn này', {
      bug: 'Báo lỗi',
      billing: 'Vấn đề thanh toán'
    })
  }
})

if (answers.category.confidence < 0.5) {
  routeToHuman(userMessage)
} else if (answers.category.choice === 'bug') {
  handleBugReport()
}

Pattern hay dùng: gộp nhiều Score thành điểm ưu tiên tổng hợp ngay trong code, không tốn thêm lệnh gọi AI nào:

const priority =
  0.6 * normalized(answers, 'severity') +
  0.3 * normalized(answers, 'frustration')

Hiệu năng, chi phí, use case

  • Độ trễ: 70–500ms end-to-end, trung bình ~100ms
  • Giá: $0.042/triệu token input — output miễn phí
  • Rate limit: 250.000 token/giây, 1.200 request/phút
  • So với LLM tương đương: nhanh hơn 40x–200x, rẻ hơn 5x–240x cho tác vụ phân loại

Use case thực tế đáng chú ý: routing/triage ticket, content moderation, data labeling quy mô lớn (1.018 bài báo nghiên cứu gắn nhãn với $0.08), verification (dùng Jev làm “trọng tài” kiểm tra output của LLM khác), search re-ranking, fraud scoring, và — thú vị nhất với ai đang build coding agent — guardrail: phân loại trước một lệnh shell là read-only / reversible / destructive trước khi agent thực thi nó.

Jev cố tình yếu ở đâu

Vì đánh đổi khả năng sinh text tự do lấy tốc độ và calibration, Jev không đáng tin ở: toán học & đếm số lần xuất hiện, ngày tháng khi format lẫn lộn, phủ định kép, context dài chứa nhiều nhiễu, và nội dung mang tính thao túng (adversarial). Khuyến nghị chính thức: khi định “trích xuất X”, đổi cách hỏi thành “đây là các ứng viên cho X, cái nào đúng?” — luôn đưa Jev về bài toán chọn trong tập hữu hạn.

Loạt open-source alternative mọc lên chỉ sau vài ngày

Điều thú vị nhất không phải bản thân Jev, mà là tốc độ cộng đồng open-source phản ứng. Chưa đầy hai tuần sau launch, đã có cả chục project public weights làm cùng việc — “typed, calibrated decision trong một forward pass” — không cần đóng gói dưới dạng API trả phí.

ProjectSizeCấu hình cần để hostĐặc điểm
Laya322M–421MCPU-only vẫn chạy tốt; GPU thì CUDA/Apple MPS/Intel XPU đều được — nhẹ, không cần VRAM lớn. Cài pip install layaModernBERT-large + mmBERT, 100+ ngôn ngữ
Kev0.8B–27B0.8B: ~4GB VRAM (GPU L4 hoặc Mac bất kỳ). 4B/9B: ~17GB (L40S, H100, hoặc Mac 32GB). 27B: 55–66GB weights, cần GPU 80GB (H100/H200/B200)Qwen + LoRA + pointer head, implement thẳng /v1/systemone, tương thích SDK TypeSafe
Nimble9B~18GB VRAM ở BF16. Cần GPU CUDA hỗ trợ BF16, hoặc Mac Apple Silicon (MLX) — bước merge adapter chạy CPU nên RAM càng nhiều càng tốt (khuyến nghị ≥64GB)Qwen3.5-9B + LoRA rank-16, đọc logit token candidate thay vì generate
NanoJev0.6BCần môi trường CUDA (README chưa xác nhận chạy CPU-only) — nhưng 0.6B nên GPU phổ thông là đủQwen3-0.6B + decision heads, có full training pipeline để tự train lại
SemIftuỳ model nềnKhông cố định — dùng baseline Qwen3.5-4B thì cần ~8GB VRAM (BF16); hoặc chạy CPU-only qua llama.cpp với checkpoint GGUF (Q8_0/Q4_K_M)Đọc logit trực tiếp từ LLM open-weight có sẵn, không cần fine-tune
Von~395MNhẹ nhất trong danh sách — CPU (qua OpenVINO) đủ dùng thực tế (p50 ~0.36s/request), có GPU rẻ như A10G thì xuống ~23ms. Hỗ trợ thêm CUDA, ROCm, Apple MPSModernBERT + OptionMarker, tự chọn device qua --device auto
Rizzo Flow1.7B–4B4B bản Q8_0 (mặc định): ~5.6GB VRAM; Q4_K_M: ~3.9GB. Chạy qua llama.cpp nên không cần cài GPU toolkit riêng — tự chọn Metal/CUDA/Vulkan/ROCm/CPUSpark-X2.5, local-first, cache lại state giữa các câu hỏi

Đáng chú ý nhất là open-alternative-jev (Apache-2.0) — thư viện Python so1, cơ chế gần giống hệt Jev nhưng chạy trên bất kỳ model open-weights nào (Qwen2.5/3.5/3.6, qua HF Transformers hoặc vLLM):

  1. Render mỗi câu hỏi thành 1 chat turn
  2. Ghép nhiều câu hỏi vào chung 1 token sequence, xen placeholder answer giữa các câu
  3. Chạy một forward pass duy nhất, chỉ đọc logit tại đúng vị trí câu trả lời
  4. Softmax normalize logit của các nhãn (A, B, C…) → xác suất luôn nằm trong tập bạn định nghĩa
  5. Temperature scaling tuỳ chọn để hiệu chỉnh xác suất

Cấu hình để host so1: phụ thuộc hoàn toàn vào model nền bạn chọn — thư viện chỉ đọc logit, không thêm overhead đáng kể. Ví dụ trong benchmark bên dưới dùng Qwen3.6-27B với load_in_8bit=True (qua bitsandbytes) — cần khoảng 27GB VRAM, vừa một GPU 32GB. Muốn nhẹ hơn thì đổi sang Qwen2.5-1.5B hoặc 3B, chạy được cả CPU (chậm hơn) hoặc GPU phổ thông 8-12GB.

from so1 import Decider, Choice, yes_no

decider = Decider.from_pretrained("Qwen/Qwen3.6-27B", backend="hf", load_in_8bit=True)
decisions = decider.decide(
    state="Support ticket describing an issue...",
    questions=[
        Choice("Category", ["bug", "feature", "billing", "question"]),
        Choice("Urgency", ["low", "medium", "high"]),
        yes_no("Escalate?"),
    ],
)

Số benchmark do tác giả công bố trên bộ typed-decisions (400 case, 2.000 decision) còn thú vị hơn: Qwen3.6-27B chạy qua thư viện này đạt 73.7% accuracy, KL-to-gold 0.27, ECE 0.020, 582ms/case — so với Jev 1.13.0 đo được 72.7% accuracy, KL 1.44, ECE 0.144, 710ms/case. Tức là bản open-source, zero-shot, không fine-tune riêng, vẫn nhỉnh hơn cả về độ chính xác lẫn độ hiệu chỉnh xác suất (ECE thấp hơn = ước lượng xác suất đáng tin hơn), và nhanh hơn.

Nhận định

Core concept cần nhớ: Jev không phải “LLM nhỏ hơn/nhanh hơn” — nó là một lớp model khác hẳn về mục tiêu huấn luyện. LLM tối ưu để nghe hợp lý; Jev tối ưu để con số xác suất đúng về thống kê, đánh đổi bằng việc bỏ hẳn khả năng sinh text tự do.

Nhưng chính vì cơ chế lõi (forward pass 1 lần, đọc logit tại vị trí câu trả lời, softmax normalize trên tập nhãn cố định) không có gì bí mật — nó không cần một model được train riêng từ đầu, chỉ cần đọc đúng logit từ một LLM open-weight sẵn có — nên rào cản kỹ thuật để clone lại gần như bằng 0. Đó là lý do khoảng cách từ “TypeSafe ra mắt sản phẩm độc quyền” đến “cộng đồng có bản open-source nhỉnh hơn cả về accuracy lẫn calibration” chỉ mất chưa đầy hai tuần.

Với một dự án thực tế: nếu hệ thống đang dùng GPT-4/Claude chỉ để làm việc có tập câu trả lời cố định biết trước (spam/không-spam, ticket thuộc phòng ban nào, mức độ nghiêm trọng bug) — đang trả tiền cho một cỗ máy sinh văn bản để làm việc của một bộ phân loại. Giờ có cả API trả phí (Jev) lẫn thư viện tự host miễn phí (open-alternative-jev và tương tự) để tách phần đó ra thành một tầng riêng, rẻ và nhanh hơn hẳn — chạy trước tầng LLM “nặng”, chỉ gọi LLM khi thực sự cần sinh nội dung.