AI Server
บล็อก

Jev และ System One Model: AI ที่ตัดสินใจโดยไม่พูด — และวิธีที่ชาวเน็ตทำเลียนแบบภายใน 4 วัน

serverอ่าน 23 นาที

15 ก.ย. 2026 บริษัท TypeSafe AI (ก่อตั้งโดยอดีตนักวิจัย OpenAI) เปิดตัวโมเดลชื่อ Jev พร้อมคำโฆษณาแรงๆ: “เร็วกว่า LLM 40–200 เท่า” “ถูกกว่า 100 เท่า” และ “hallucinate ไม่ได้” ภายใน 4 วัน GitHub มีโปรเจกต์ทำเลียนแบบเปิดโค้ดหลายสิบตัว บางตัวอ้างว่าเทียบเท่า Jev ได้ด้วยโมเดลขนาด 150 ล้านพารามิเตอร์ที่เทรนบน Colab ฟรี 30 นาที บทความนี้จะอธิบายว่า Jev คืออะไรจริงๆ ทำไมมันเร็วขนาดนั้น คำว่า “hallucinate ไม่ได้” หมายความว่าอะไรกันแน่ แล้วไล่ดูวิธีทำเลียนแบบทั้ง 3 ท่าที่ชุมชนใช้ พร้อมข้อสรุปว่าอันไหนเอามาใช้บนเครื่องของเราได้เลยวันนี้

ตอนที่ 1: LLM ทำงานยังไง (ทวนสั้นๆ เพื่อให้เห็นว่า Jev ต่างตรงไหน)

โมเดลภาษาที่เราใช้กันทุกวัน (Qwen, DeepSeek, Claude, GPT) ทำงานแบบ autoregressive แปลว่า “ผลิตทีละคำ โดยเอาคำที่เพิ่งผลิตไปเป็นอินพุตของรอบถัดไป”

ลองนึกภาพเราถามว่า “ข้อความนี้เป็นสแปมไหม” โมเดลจะทำแบบนี้:

  1. อ่านทั้ง prompt หนึ่งรอบ (เรียกว่า prefill) — ขั้นนี้เร็ว เพราะทุกคำถูกประมวลผลพร้อมกันขนานได้
  2. ผลิตคำตอบทีละ token: “ข้อ” → “ความ” → “นี้” → “เป็น” → “สแปม” → “ครับ” (เรียกว่า decode) — ขั้นนี้ช้า เพราะแต่ละ token ต้องรอ token ก่อนหน้า และแต่ละรอบต้องอ่านน้ำหนักทั้งโมเดลจากหน่วยความจำอีกครั้ง

ถ้าโมเดล 27B ตอบ 30 token บนเครื่อง DGX Spark ก็ประมาณ 1.5–2 วินาที ทั้งที่ข้อมูลที่เราต้องการจริงๆ คือ บิตเดียว: ใช่ หรือ ไม่ใช่

แล้วยังมีปัญหาซ้อน: คำตอบเป็นข้อความอิสระ โมเดลอาจตอบว่า “น่าจะเป็นสแปมนะครับ แต่ไม่แน่ใจ” แล้วโปรแกรมเราต้องมาแกะเอาเองว่าตกลงใช่หรือไม่ใช่ ถ้าโมเดลตอบนอกรูปแบบ โปรแกรมพัง นี่คือสิ่งที่นักพัฒนาเจอทุกวันเวลาเอา LLM มาใส่ในซอฟต์แวร์

ตอนที่ 2: Jev คืออะไร

TypeSafe เรียก Jev ว่า System One Model ยืมคำจากหนังสือ Thinking, Fast and Slow ของ Kahneman: System 1 คือความคิดแบบเร็ว อัตโนมัติ ไม่ต้องไตร่ตรอง (เห็นหน้าคนแล้วรู้ว่าโกรธ) ส่วน System 2 คือคิดช้าๆ เป็นขั้นตอน (คูณเลขสามหลัก) LLM ปกติคือ System 2 ส่วน Jev ตั้งใจเป็น System 1

สิ่งที่ Jev รับและตอบต่างจาก LLM ตรงนี้:

อินพุต = “state” (ข้อความอะไรก็ได้ที่บรรยายสถานการณ์ เช่น อีเมลหนึ่งฉบับ, ประวัติแชต, สถานะเกม) + รายการคำถามแบบมี type ซึ่งมีแค่ 3 ชนิด:

ชนิด ตัวอย่าง สิ่งที่ได้กลับ
ใช่/ไม่ใช่ (TypeSafe เรียก “noul”) “อีเมลนี้เป็นสแปมไหม” ความน่าจะเป็น เช่น 0.93
เลือกจากตัวเลือก (choice) “เรื่องนี้เป็นหมวด: บิล / เทคนิค / ยกเลิก / อื่นๆ” ความน่าจะเป็นของแต่ละตัวเลือก
คะแนน (score) “ความเร่งด่วน 1–5” การกระจายความน่าจะเป็นบนสเกล

เอาต์พุต = คำตอบของ ทุกคำถามพร้อมกันใน forward pass เดียว ไม่มีการผลิตข้อความเลย โมเดลไม่เคย “พูด” มันแค่ “ชี้”

เพราะฉะนั้น 3 คำโฆษณาจึงมีที่มา:

  • “เร็ว 40–200 เท่า” เพราะมีแต่ขั้น prefill (ขั้นที่ขนานได้) ไม่มีขั้น decode ที่ต้องวนทีละ token ถ้าถาม 20 คำถามกับ state เดียวกัน ก็ยังเป็น pass เดียว
  • “ถูก 100 เท่า” เพราะคิดเงินเฉพาะ input token ($0.042 ต่อล้าน token) ส่วน output ฟรี เพราะไม่มี output token
  • “hallucinate ไม่ได้” เพราะโมเดลเลือกได้เฉพาะตัวเลือกที่เรากำหนด มันตอบ “หมวด: ค้างคาว” ไม่ได้ถ้าเราไม่ได้ให้ตัวเลือกนั้น และไม่มีทางตอบผิดรูปแบบ (type error) — แต่ มันยังเลือกผิดได้ตามปกติ คำว่า hallucinate ไม่ได้ในที่นี้จึงหมายถึง “ผิดรูปแบบไม่ได้” ไม่ใช่ “ตัดสินใจถูกเสมอ” อันนี้ต้องอ่านโฆษณาให้ขาด

อีกจุดที่ TypeSafe เน้นมากคือ calibration: ถ้า Jev บอกว่า 0.80 ของที่มันบอก 0.80 ควรถูกจริงราว 80% ไม่ใช่โมเดลมั่นใจเกินจริงแบบ LLM ทั่วไปที่ตอบว่า “แน่นอน!” ทั้งที่ผิด เขาบอกว่าเทรนด้วยวิธีที่เรียกว่า RLCD (Reinforcement Learning for Calibrated Decisions) รายละเอียดไม่เปิดเผย

ข้อจำกัดใหญ่: Jev เป็นโมเดลปิด ใช้ผ่าน API ของ TypeSafe เท่านั้น ไม่มี weights ให้โหลด รันในเครื่องตัวเองไม่ได้ และตอนนี้ยังต้องต่อคิว waitlist

ตอนที่ 3: ทำไมเรื่องนี้น่าสนใจ (แม้จะไม่ได้ใช้ Jev)

เพราะงาน AI ในซอฟต์แวร์จริงส่วนใหญ่ ไม่ใช่การแชต แต่เป็นการตัดสินใจเล็กๆ จำนวนมาก:

  • คัดแยกอีเมล/ตั๋วซัพพอร์ตเข้าหมวด
  • ให้คะแนนความเสี่ยงของธุรกรรม
  • ตัดสินว่าคำขอนี้ควรส่งให้โมเดลใหญ่ (แพง) หรือโมเดลเล็ก (ถูก) — นี่คือ routing
  • ตรวจว่าคำตอบที่ AI อีกตัวสร้างมา ปลอดภัย/ตรงประเด็นไหม (guardrail)
  • ในเกมหรือ agent: ตัดสินใจก้าวถัดไปจากสถานะปัจจุบัน

งานพวกนี้ถ้าใช้ LLM ตอบเป็นข้อความ ทั้งช้า ทั้งแพง ทั้งต้องแกะข้อความ Jev เลยเสนอว่า “แยกโมเดลสำหรับตัดสินใจออกจากโมเดลสำหรับพูด” ซึ่งเป็นแนวคิดที่ดี ไม่ว่า Jev เองจะเก่งจริงหรือไม่

และคำถามที่ชุมชนถามทันทีคือ: แนวคิดนี้ต้องมีโมเดลลับพิเศษจริงหรือ หรือทำได้จากของที่มีอยู่แล้ว? คำตอบคือทำได้ และมี 3 วิธี

ตอนที่ 4: วิธีที่ 1 — ใช้ LLM ที่มีอยู่แล้ว แต่ไม่ให้มันพูด (prompt-logprob)

นี่คือวิธีที่ฉลาดที่สุดและไม่ต้องเทรนอะไรเลย หลักการมีแค่นี้:

ตอน LLM ทำขั้น prefill มันคำนวณ การกระจายความน่าจะเป็นของ “token ถัดไป” ที่ทุกตำแหน่ง อยู่แล้ว ปกติเราใช้แค่ตำแหน่งสุดท้ายเพื่อผลิตคำต่อไป แต่จริงๆ ตำแหน่งอื่นก็มีค่าเหล่านี้ทั้งหมด แค่เราไม่เคยดู

วิธีทำ (ตามโปรเจกต์ open-alternative-jev ซึ่งเป็นตัวที่ทำได้เรียบร้อยที่สุด):

  1. เขียน state ไว้ข้างบน
  2. ต่อท้ายด้วยคำถามทุกข้อในรูปแบบ “คำถาม: … ตัวเลือก: A) … B) … C) … คำตอบ: X” โดยที่ X เป็น ตัวอักษรหลอก (placeholder) แล้วต่อคำถามถัดไปทันที
  3. ส่งทั้งก้อนเข้าโมเดล หนึ่งครั้ง ในโหมด prefill
  4. ที่ตำแหน่งของ X แต่ละตัว ไปอ่านค่า logit ของ token “A” “B” “C” แล้วทำ softmax เฉพาะตัวเลือกเหล่านั้น → ได้ความน่าจะเป็นของแต่ละตัวเลือกทันที

ทำไมถึงถูกต้อง: เพราะโมเดลตอนอยู่ที่ตำแหน่ง X ของคำถามข้อ 1 มันเห็น state และคำถามข้อ 1 ครบแล้ว การกระจายของ token ถัดไปที่ตำแหน่งนั้นก็คือ “ถ้าให้ตอบ จะตอบอะไร” นั่นเอง ส่วนคำถามข้อ 2 ที่ต่อท้าย ก็อ่านที่ตำแหน่ง X ตัวที่ 2 (ค่าหลอกที่เราใส่ในข้อ 1 อาจรบกวนข้อ 2 นิดหน่อย โปรเจกต์นี้วัดแล้วว่าน้อยมาก)

ผลที่เขาวัดได้ด้วย Qwen3.6-27B (8-bit) และ Qwen3.5-4B:

ชุดทดสอบ ความแม่น ความเร็ว
RACE-H (อ่านจับใจความ 1,000 ข้อ state เดียวกัน) 92.9% 4.6 คำถาม/วินาที
MMLU (1,200 ข้ออิสระ แพ็กรวมกัน) 84.2% 6.7 คำถาม/วินาที

และเรื่อง calibration ใช้เทคนิคเก่าแก่ชื่อ temperature scaling: เอาชุดข้อมูลที่รู้เฉลยมาปรับตัวเลขตัวเดียว (อุณหภูมิ) ให้ความมั่นใจของโมเดลตรงกับความถูกจริง ผลคือ ECE (ค่าที่บอกว่าความมั่นใจ “โกหก” แค่ไหน) ลดจาก 5.4% เหลือ 2.1%

ข้อดี: ใช้โมเดลอะไรก็ได้ที่มี (Qwen, Gemma, Llama) รองรับ vLLM ผ่านฟีเจอร์ prompt_logprobs ที่มีอยู่แล้ว ไม่ต้องเทรน ได้ความรู้ทั่วไปของ LLM เต็มๆ (zero-shot) ข้อจำกัด: ยังต้องรัน LLM ทั้งตัวหนึ่งรอบ (แต่เป็น prefill ซึ่งเร็ว) ตัวเลือกต้องแทนด้วย token สั้นๆ ที่โมเดลมองเป็นหน่วยเดียว (A/B/C ทำงานดีกว่าคำเต็มยาวๆ) และคำถามหลายข้อในก้อนเดียวรบกวนกันได้เล็กน้อย

โปรเจกต์ตระกูลนี้: ikermoel/open-alternative-jev (pip ชื่อ so1), Abhi001vj/system-one-open, ekzhang/openjev-sglang (ใช้ SGLang แบบ prefill อย่างเดียว), bnsd55/openjev (Apple Silicon/MLX)

ตอนที่ 5: วิธีที่ 2 — โมเดลจิ๋ว + หัวให้คะแนน (เทรนเอง)

วิธีนี้ใกล้เคียง “สร้าง Jev ของตัวเอง” ที่สุด และเป็นกลุ่มที่ใช้ Gemma กันมาก:

  1. เอาโมเดลเล็กมาก เช่น Gemma 3 270M (270 ล้านพารามิเตอร์ ไฟล์ไม่ถึง 1 GB รันบน CPU ได้) หรือ encoder แบบ ModernBERT ขนาด ~150M
  2. ต่อ “หัวให้คะแนน” (scoring head) เป็นชั้น linear เล็กๆ ที่รับ hidden state ของ token สุดท้ายแล้วออกเป็นตัวเลขหนึ่งค่า
  3. ต่อ state + คำถาม + ตัวเลือกแต่ละตัวเป็นข้อความ ป้อนเข้าโมเดล ได้คะแนนต่อตัวเลือก แล้ว softmax
  4. เทรน head (และ LoRA ของโมเดลนิดหน่อย) ด้วยชุดข้อมูลหลาย task ที่มีเฉลย แล้ว calibrate ด้วย temperature scaling

ตัวอย่างจริง:

  • akash-kamat/system-one-gemma: Gemma 3 270M + LoRA rank 16 (พารามิเตอร์ที่เทรนแค่ 2.6 ล้าน) เทรนบน 12,913 ข้อ 6 งาน (จัดหมวดธนาคาร, อารมณ์, หัวข้อข่าว, MMLU, คะแนนรีวิว, routing ตั๋ว) ได้ ~50 ms ต่อการตัดสินใจ, ความแม่นรวม 64.4%, ECE 0.047
  • intikhab49/open-jev-typed-decision-engine: encoder 150M เทรนบน Colab T4 ฟรี 30 นาที อ้างคะแนน 0.697 เทียบ Jev 0.727 บน benchmark ที่ทำขึ้นเอง และ calibrate ดีกว่า 2.5 เท่า
  • Heman10x-NGU/openJev-verdict-2.0: ModernBERT 151M ได้ 77% acc, ECE 0.014 มี playground รันในเบราว์เซอร์ผ่าน WebGPU
  • wfzyx/von: ต่ำกว่า 15 ms และทำ HTTP API ให้เข้ากับ Jev ตรงตัว (ใช้ SDK ของ TypeSafe ชี้มาได้เลย)
  • Laya: เทรนด้วยวิธีเลียน RLCD ตอบใน ~35 ms

ข้อดี: เร็วที่สุด ถูกที่สุด รันได้แม้บน CPU หรือในเบราว์เซอร์ เหมาะกับงานปริมาณมหาศาลที่โจทย์ตายตัว ข้อจำกัด: แม่นเฉพาะงานที่คล้ายชุดเทรน ความแม่น zero-shot ต่ำกว่า LLM ใหญ่มาก (64–77% กับ 84–93% ของวิธีที่ 1) และหลายตัวมีเงื่อนไขสัญญาอนุญาตของชุดข้อมูลเทรนติดมา (เช่น ใช้เชิงพาณิชย์ไม่ได้)

ที่น่าสังเกต: ไม่พบโปรเจกต์ที่ใช้ Nemotron เป็นฐาน ในกลุ่มนี้เลย ที่นิยมคือ Gemma 270M, Gemma 4 E2B, Qwen เล็ก และ ModernBERT

ตอนที่ 6: วิธีที่ 3 — ใช้โมเดล diffusion แทน (structured read)

วิธีนี้ต่างจากสองวิธีแรกตรงตัวโมเดล: ใช้ DiffusionGemma 26B-A4B ของ Google (Apache-2.0) ซึ่งเป็น LLM แบบ discrete diffusion — แทนที่จะผลิตข้อความซ้ายไปขวา มันเริ่มจาก “ผืนผ้าใบ” ที่เต็มไปด้วย token สุ่ม แล้ว “ลบ noise” ทั้งผืนพร้อมกันหลายรอบจนกลายเป็นข้อความ

โปรเจกต์ razorback16/openjev ใช้คุณสมบัตินี้อย่างชาญฉลาด:

  1. เขียนแม่แบบคำตอบเช่น “สแปม: [ช่องว่าง] หมวด: [ช่องว่าง] เร่งด่วน: [ช่องว่าง]” โดยช่องว่างคือ token noise
  2. ให้โมเดล denoise แค่ 1 รอบ
  3. อ่านการกระจายความน่าจะเป็นที่แต่ละช่องว่าง → ได้คำตอบทุกข้อพร้อมกัน

เพราะ diffusion model มองทั้งผืนผ้าใบด้วย attention สองทิศทาง ทุกช่องจึงเห็นทั้ง state และคำถามอื่นพร้อมกัน ไม่มีปัญหาคำถามข้อแรกรบกวนข้อหลังแบบวิธีที่ 1

ผลที่วัดบน RTX PRO 6000: 94 ms ต่อคำขอ (3 คำถาม) ที่ 1 ผู้ใช้ และ 57 คำขอ/วินาทีเมื่อ 64 ผู้ใช้พร้อมกัน API เข้ากันกับ Jev ตรงตัว (POST /v1/systemone) รับรูปภาพได้ถึง 8 ใบด้วย

ข้อดี: ได้ความรู้ระดับโมเดล 26B (แต่ active แค่ 3.8B เพราะเป็น MoE) รองรับ 35+ ภาษา รับภาพ ข้อจำกัด: ต้องมี VRAM 24 GB ขึ้นไป และต้องใช้ vLLM ที่แก้ให้รองรับ “structured read” (ยังไม่ใช่ของมาตรฐาน)

ตอนที่ 7: เทียบ 3 วิธี

วิธีที่ 1 prompt-logprob วิธีที่ 2 โมเดลจิ๋ว+head วิธีที่ 3 diffusion
ต้องเทรนไหม ไม่ ต้อง (30 นาที–ชั่วโมง) ไม่
ความรู้ทั่วไป (zero-shot) สูง (ตามโมเดลที่ใช้) ต่ำ สูง
ความเร็ว/การตัดสินใจ ~150–250 ms (27B บน GPU เดี่ยว) 15–50 ms (CPU ได้) ~100 ms
ฮาร์ดแวร์ GPU ที่รัน LLM ตัวนั้นได้ อะไรก็ได้ VRAM ≥24 GB
ภาษาไทย ตามโมเดลฐาน (Qwen ทำได้) ต้องเทรนด้วยข้อมูลไทย DiffusionGemma อ้าง 35+ ภาษา
ใช้บน DGX Spark ได้เลย ได้ (vLLM มี prompt_logprobs) ได้ น่าจะได้ ต้องเทส

ตอนที่ 8: บทเรียนและสิ่งที่เราจะทำต่อ

  1. “hallucinate ไม่ได้” = บังคับรูปแบบคำตอบ ไม่ใช่รับประกันความถูก ทุกวิธีข้างบนให้คุณสมบัตินี้เหมือน Jev เพราะแก่นคือ “อ่านความน่าจะเป็นเฉพาะตัวเลือกที่กำหนด” ไม่ได้อยู่ที่โมเดลลับ
  2. ความเร็วมาจากการตัดขั้น decode ไม่ใช่จากสถาปัตยกรรมพิเศษ LLM ที่คุณมีอยู่แล้วก็ทำได้ทันทีถ้าใช้ให้เป็น
  3. calibration คือของจริงที่ต้องลงแรง temperature scaling ง่ายและได้ผล แต่ต้องมีชุดข้อมูลที่มีเฉลยในโดเมนและภาษาของเรา ถ้าอยากใช้กับภาษาไทย ต้อง calibrate ด้วยข้อมูลไทย
  4. สำหรับเครื่อง DGX Spark ที่รัน AI Server Suite: วิธีที่ 1 ทำได้ทันทีกับโมเดลที่โหลดอยู่แล้วผ่าน vLLM แนวคิดคือเพิ่ม endpoint แบบ “ส่ง state + คำถาม → ได้ความน่าจะเป็น” ไว้ในเครื่อง ใช้คัดแยก/ให้คะแนน/ตัดสินใจก่อนส่งงานให้โมเดลใหญ่ ซึ่งเป็นหัวใจของเรื่อง routing ที่เราสอนในคอร์ส
  5. ของแถมที่น่าตื่นเต้นไม่แพ้กันคือ DiffusionGemma 26B-A4B เอง: โมเดลเปิดที่ผลิตข้อความเร็วกว่า 1,000 token/วินาทีบน H100 รองรับหลายภาษาและรับภาพ ถ้ารันบน GB10 ได้ดี จะเปลี่ยนโจทย์ “โมเดลเล็กที่เร็ว” ไปอีกแบบ เราจะเทสและมาเล่าให้ฟัง

สรุปประโยคเดียว: Jev พิสูจน์ว่าตลาดต้องการ “AI ที่ตัดสินใจ ไม่ใช่ AI ที่พูด” และชุมชนพิสูจน์ภายใน 4 วันว่าสิ่งนั้นสร้างได้จากโมเดลเปิดที่มีอยู่แล้ว — โมเดลลับไม่ใช่ส่วนที่สำคัญที่สุดของไอเดียนี้

แหล่งอ้างอิง: TypeSafe AI blog “Introducing System One Models & Jev” · latent.space AINews (Jev) · GitHub: ikermoel/open-alternative-jev, akash-kamat/system-one-gemma, intikhab49/open-jev-typed-decision-engine, razorback16/openjev, wfzyx/von, Heman10x-NGU/openJev-verdict-2.0 · Hugging Face Space multimodalart/jev-reproductions-tracker · Hugging Face google/diffusiongemma-26B-A4B-it