pplx-decider vs Kev: สองระบบ หนึ่งโมเดลที่คุณสามารถดึงมาใช้ได้แล้ว

อุบัติเหตุที่มีประโยชน์ในการจับคู่นี้คือคุณสามารถตัดสินมันให้จบได้บนฮาร์ดแวร์ของคุณเองภายในบ่ายวันนี้ pplx-decider โมเดลตัดสินใจขนาด 27B ของ Perplexity ปรากฏขึ้นเมื่อ 2026-10-01 โดยไม่มีประกาศแนบมาด้วย และมีเรวิชัน v1.1 เมื่อ 2026-10-05 และทั้งคู่อยู่ในไลบรารี Ollama Kev สายงาน reproduction ของ Jared Palmer อยู่บน Ollama ตั้งแต่ v2 เปิดตัวเมื่อ 2026-09-30 และครอบคลุมตั้งแต่ 0.5B ถึง 27B พวกมันใช้รูปแบบการเรียกเดียวกัน — สถานะหนึ่งรายการบวกรายการคำถามที่มีชื่อ, forward pass หนึ่งครั้ง, ได้ค่าความน่าจะเป็นกลับมา, ไม่มีข้อความที่สร้างขึ้น — ซึ่งหมายความว่าฮาร์เนสเดียวกันสามารถรันทั้งคู่ได้ สิ่งที่แตกต่างคือทุกอย่างที่อยู่ข้างใต้: เอาต์พุตถูกผลิตอย่างไร ผู้เขียนจัดทำเอกสารอะไรไว้ และต้องใช้ GPU มากแค่ไหน

เริ่มจากสิ่งที่ทำให้การเปรียบเทียบ (bake-off) เป็นไปได้เลย โมเดลทั้งสองไม่เขียนข้อความ คุณส่งเอกสารและถามคำถามตามชื่อ โดยแต่ละคำถามระบุประเภทคำตอบ — ตัวเลือกจาก 2 ถึง 255 ตัวเลือกที่มีป้ายกำกับ, การอ่านค่าใช่/ไม่ใช่/ไม่ทราบ, หรือคะแนนตั้งแต่ 2 ถึง 10 ระดับที่อธิบายไว้ คำตอบจะมาในรูปของความน่าจะเป็น ตามลำดับที่คุณถาม ตั๋วที่มีหกสิบคำถามคือการประมวลผลครั้งเดียวบนโมเดล ไม่ใช่การเรียกใช้หกสิบครั้ง

แต่ละโมเดลมีส่วนในการตัดสินใจจริง ๆ แค่ไหน

การ์ดของ Kev ระบุรายละเอียดการสร้างโมเดลไว้อย่างชัดเจนในแบบที่หาได้ยากนอกเอกสารภายใน และรายละเอียดเหล่านั้นคุ้มค่าที่จะอ่านก่อนที่คุณจะเชื่อตัวเลขใด ๆ จากมัน เช็คพอยต์ 27B เป็นการไฟน์จูนแบบ supervised ด้วยน้ำหนักเต็มบน Qwen/Qwen3.8-27B จากนั้นจึงเฉลี่ยน้ำหนัก โดยผสม 0.85 ของโมเดลใหม่เข้ากับ 0.15 ของ v1 ใน fp32 ส่วนขนาดที่เล็กกว่า ตั้งแต่ 0.8B ถึง 9B จะจัดส่งเป็น LoRA adapter บนฐาน Qwen3.5 แทนที่จะเป็นเช็คพอยต์เต็ม

ส่วนที่ตัดสินว่าเอาต์พุตจะมีรูปร่างอย่างไรนั้นแยกออกจากแกนกลางภาษา Kev มี pointer head — พารามิเตอร์ประมาณ 2.6M ใน fp32 วางอยู่บน backbone ขนาด 25.6B รวมเป็น 26B — ซึ่งเป็นสิ่งที่เปลี่ยน hidden state ให้เป็นความน่าจะเป็นเหนือตัวเลือกที่คุณตั้งชื่อไว้ ส่วน pplx-decider ทำงานแบบเดียวกันด้วย readout head ที่เผยแพร่แล้วขนาด [255, 5120]: ตัวเลือก 255 รายการบน hidden state กว้าง 5,120 ใน bf16

สถาปัตยกรรมสองแบบ ความคิดเดียว: โมเดลภาษาทำหน้าที่อ่าน ส่วนหัวขนาดเล็กเป็นตัวตัดสินใจ นั่นคือเหตุผลที่ทั้งสองไม่ได้สร้างข้อความร้อยแก้ว และยังเป็นเหตุผลที่คะแนน benchmark จากตัวหนึ่งไม่สามารถถ่ายโอนไปยังอีกตัวได้ แม้ว่าทั้งคู่จะถูกอ้างอิงเทียบกับโมเดลอ้างอิงเดียวกันก็ตาม

การเผชิญหน้าตัวต่อตัวเพียงครั้งเดียวที่มีบันทึกไว้ และเหตุใดคุณจึงไม่อาจหักลบมันออกไปได้

ทั้งสองโปรเจกต์รายงานเทียบกับ Jev ซึ่งชวนให้อยากจับมาเทียบเคียงกัน อย่าทำ

การ์ดของ Kev เองมีแถว Decision Index 0.2 ที่จัดให้ Kev-27B v2 อยู่ที่ 52.3 เทียบกับ 50.2 ของ v1, Jev ที่ 54.0 และ AutoJev-27B ที่ 50.0 นั่นเป็นการเปรียบเทียบที่ชัดเจน ในชุดทดสอบเดียวกัน เวอร์ชันเดียวกัน และบอกว่า Kev v2 ดีขึ้นประมาณสองจุด แต่ก็ยังตามหลัง Jev อยู่

การ์ดของ pplx-decider รายงานคะแนนรวมถ่วงน้ำหนักตามชุดทดสอบที่ 61.56 สำหรับ v1.1 เทียบกับ 56.4 สำหรับ v1 และ 57.9 สำหรับ Jev จากตัวเลขของพวกเขาเอง นั่นคือการเพิ่มขึ้นมากกว่าห้าคะแนนในการแก้ไขหนึ่งครั้ง และนำหน้า Jev อยู่มากกว่าสามจุดครึ่ง

สองย่อหน้านั้นไม่สามารถนำมาลบกันได้ ชุดทดสอบต่างกัน การผสมงานต่างกัน การถ่วงน้ำหนักต่างกัน — และไม่มีโครงการใดเปิดเผยการถ่วงน้ำหนัก สิ่งที่คุณพูดได้นั้นแคบกว่าและยังมีประโยชน์: ทั้งคู่เคลื่อนไปในทิศทางเดียวกันในช่วงเวลาเดียวกัน ทั้งคู่ทำเช่นนั้นโดยเปลี่ยนวิธีการฝึกส่วนอ่านผลแทนที่จะสลับแบ็กโบน และส่วนต่างที่ pplx-decider อ้างว่าเหนือกว่า Jev นั้นมากกว่าส่วนที่ขาดที่วัดได้ของ Kev นั่นเป็นเหตุผลที่จะทดสอบ pplx-decider ไม่ใช่เหตุผลที่จะเชื่อมัน

มีเพียงหนึ่งในสองเท่านั้นที่มีการทำซ้ำโดยอิสระผูกอยู่กับตัวเลขใด ๆ ของมัน แท็ก Ollama ของ Kev เผยแพร่จำนวนการผ่าน JevBench ต่อแท็ก — 205 จาก 231 สำหรับ kev:27b-nvfp4 รวม 86 จาก 111 ในชุดข้อมูลแบบยาก ลดลงเหลือ 146 จาก 231 สำหรับ kev:0.8b — พร้อมหมายเหตุชัดเจนว่าตัวเลขเหล่านี้ไม่รวมงานที่ไม่พร้อมใช้งานจำนวน 303 งานซึ่งเป็นงานที่ปิดผนึกหรือถูกให้คะแนนโดยผู้ตัดสิน และไม่ใช่คะแนนกระดานผู้นำอย่างเป็นทางการ มันเป็นการรันเอง แต่เป็นการรันเองที่คุณทำซ้ำได้ ไม่มีสิ่งใดเทียบเคียงได้สำหรับ pplx-decider

สิ่งที่ Kev บันทึกเป็นเอกสาร แต่ pplx-decider ไม่ได้บันทึก

• Temperature — Kev มาพร้อมค่า T = 1.32 โดยมีช่วง 90% ที่ [1.20, 1.45] และถูกนำไปใช้ตอนโหลด ดังนั้นความน่าจะเป็นที่คุณได้ออกมาจึงถูกปรับสเกลไว้เรียบร้อยแล้ว ส่วนการ์ดของ pplx-decider ไม่ได้เปิดเผยค่า temperature ไว้เลย ซึ่งหมายความว่าการคาลิเบรตแบบใดก็ตามที่คุณต้องการนั้นเป็นหน้าที่ของคุณที่จะต้องฟิตเอง

• บันทึกการฝึก — Kev v2 ใช้ 129 ชั่วโมง GPU บน 8× H200, หนึ่ง epoch บน 145,840 ระเบียนและ 337,130 คำถาม, ป้ายกำกับที่สร้างโดย GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b และ MiMo-V2.6-Pro โดยไม่มีการใช้เอาต์พุตของ Jev และการคัดกรองการปนเปื้อนที่ลบ 6,388 ระเบียนจาก 102 พาร์ติชันการประเมิน pplx-decider อธิบายไปป์ไลน์ที่สร้างบน Bespoke Nimble ของ Bespoke Labs โดยมีชุดย่อยของ benchmark ที่ปักหมุดด้วยรหัสระเบียนและ checksum และให้เครดิตการปรับปรุงของ v1.1 ว่าเกิดจากการลบ causal mask บวกกับข้อมูลการฝึกที่เพิ่มขึ้น — แต่ไม่ได้เผยแพร่จำนวนระเบียน ไม่มีชั่วโมง GPU และไม่มีรายชื่อผู้ติดป้ายกำกับ

• การรายงานการถดถอยอย่างตรงไปตรงมา — การ์ดของ Kev แสดงจุดที่พลาดของตัวเอง: transfer-v4 ลดลง 0.8 คะแนน, CUAD ลดลง 1.6, ค่าความคลาดเคลื่อนการปรับเทียบที่คาดหวังบน breadth-v1 อยู่ที่ 0.015 เทียบกับ 0.053 บน CUAD, แย่กว่า v1 สองถึงสี่เท่า, และมันระบุถึงความมองในแง่ดีจากการคัดเลือกในการประเมินของตัวเอง. ตาราง v1.1 ของ pplx-decider แสดงให้เห็นว่า tools ลดลงจาก 79.3 เป็น 78.88 ในขณะที่หมวดหมู่อื่น ๆ เพิ่มขึ้น, และไม่มีอะไรในการ์ดที่กล่าวถึงเรื่องนี้.

• โหมดความล้มเหลว — การ์ดของ Kev ระบุขอบเขตการคัดกรองการปนเปื้อนและเงื่อนไขที่ตัวเลขซึ่งเผยแพร่ของมันถูกสร้างขึ้น ตระกูล Decider ซึ่งเป็นสายของ Mapika ไปไกลกว่านั้นและระบุรูปแบบอินพุตเฉพาะที่ทำให้มันพัง; pplx-decider เงียบต่อคำถามนี้

ไม่มีอะไรในนี้บอกว่า pplx-decider แย่กว่า เอกสารไม่ใช่ความสามารถ — แล็บที่มีโพสต์เปิดตัวฉบับร่างมีแรงจูงใจต่างจากบุคคลที่เผยแพร่บันทึกไปยัง Hugging Face แต่เมื่อโมเดลสองตัวอ้างผลลัพธ์ระดับเดียวกัน และมีเพียงตัวเดียวที่บอกอุณหภูมิของมันให้คุณรู้ ตัวที่บอกคุณคือตัวที่คุณนำไปใช้งานจริงในเดือนนี้ได้

การบัญชีบริบท ซึ่งเป็นจุดที่ทั้งสองแยกจากกันมากที่สุด

• Kev — สถานะ 65,536 โทเคน บวกอย่างน้อย 8,192 โทเคนต่อคำถาม โดยฝึกได้สูงสุดถึง 32,768 โทเคน เมื่อสถานะ 64k หน่วยความจำที่คงอยู่จะสูงถึงประมาณ 87.1 GB ที่จุดสูงสุด เวลาของโมเดล 9.4 วินาที, 733 มิลลิวินาทีเมื่อแคชฮิต และ 21.1 คำขอต่อวินาทีเมื่อมีไคลเอนต์เดียว เทียบกับ 36.4 เมื่อมี 64 ไคลเอนต์

• pplx-decider — 8,192 โทเคนสำหรับข้อความและรูปภาพรวมกัน โดยอินพุตที่มีขนาดใหญ่เกินจะถูกปฏิเสธแทนที่จะถูกตัดทอน บิลด์ Ollama ระบุหน้าต่างบริบท 256K ซึ่งไม่มีสิ่งใดในรีโพซิทอรีอธิบาย และไม่สอดคล้องกับขีดจำกัดของตัวการ์ดเอง

ช่องว่างนั้นคือความแตกต่างที่มีผลตามมามากที่สุดเพียงหนึ่งเดียวระหว่างสองตัวนี้สำหรับภาระงานจริง Kev ถูกสร้างมาสำหรับสถานะยาว ๆ และคำถามจำนวนมากที่ถามกับสถานะเหล่านั้น ส่วน pplx-decider เป็นโมเดล dense ขนาด 27B ที่มีงบอินพุตค่อนข้างเล็ก ซึ่งผลักมันไปทางเอกสารสั้น รูปภาพ และคำถามที่พอดีภายในไม่กี่พันโทเคน

• ภาษา — ภาษาอังกฤษเท่านั้นบนทั้งสอง โดยระบุไว้เป็นข้อจำกัดบนทั้งสอง

• วิชัน — pplx-decider รับข้อความ JSON และรูปภาพ โดยโทเคนวิชันมีค่าใช้จ่ายประมาณ width × height / 1024 และการตั้งค่าการประเมินถูกจำกัดไว้ที่ 512×512 Kev ไม่มีวิชันในสาย 27B

• พื้นฐานการให้บริการ — Kev-27B ต้องการ GPU ระดับ 80 GB: น้ำหนัก bf16 จำนวน 51.3 GB, ใช้หน่วยความจำ resident ประมาณ 65.5 GB, 87.1 GB ที่สถานะ 64k, และเซิร์ฟเวอร์ของมันจะผูกแบบเปิด เว้นแต่จะตั้งค่า KEV_API_KEY น้ำหนัก bf16 ของ pplx-decider อยู่ที่ประมาณ 49 GiB ดังนั้นพื้นฐานจึงคล้ายกัน; บิลด์ Ollama แบบควอนไทซ์อยู่ที่ 17 GB ซึ่งเป็นเครื่องที่แตกต่างกันมาก

• Rungs — Kev ครอบคลุมขนาด 0.5B, 0.6B, 0.8B, 4B, 8B, 9B และ 27B โดยขนาดเล็กใช้เป็น LoRA adapters pplx-decider มีขนาดเดียว แก้ไขแล้วสองครั้ง

การจัดแข่งขันอบขนมโดยไม่ลงเดิมพันกับงานนี้

ทั้งสองโมเดลเข้าถึงได้ในฐานะเวตโลคอล ซึ่งเป็นสถานการณ์ที่เลเยอร์การจัดเส้นทางจะพิสูจน์คุณค่าของตัวเองได้พอดี OrcaRouter ไม่ได้ให้บริการ pplx-decider และไม่ได้ให้บริการ Kev — ทั้งสองไม่มีอยู่ในแค็ตตาล็อก และไม่ควรตีความสิ่งใดในที่นี้ว่าเป็นข้ออ้างว่าเราโฮสต์โมเดลเหล่านั้น สิ่งที่เราให้บริการในคลาสนี้คือ typesafe/jev-1.13 ซึ่งเปิดให้ใช้งานผ่านรูปแบบการเรียก POST /v1/systemone เดียวกัน ในราคา $0.042 ต่อโทเคนอินพุตหนึ่งล้านโทเคน และมันเป็นกลุ่มควบคุมตามธรรมชาติ: อินเทอร์เฟซเดียวกัน ประเภทคำถามเดียวกัน ไม่ต้องมี GPU ของคุณเอง

นั่นทำให้การทดสอบเปรียบเทียบแบบสามทางตั้งค่าได้อย่างประหยัด วาง pplx-decider แบบโลคอลและ Kev แบบโลคอลไว้หลังฮาร์เนสเดียวกัน เพื่อเทียบกับ typesafe/jev-1.13 แบบ routed ให้คะแนนทั้งสามกับเอกสารของคุณเอง แล้วให้ความไม่ลงรอยกันระหว่างพวกมันบอกคุณว่าเกณฑ์ของคุณอยู่ตรงไหนจริง ๆ การสลับไปใช้ระบบสำรองอัตโนมัติสำคัญกว่าปกติในการจัดแบบนี้ เพราะ 27B แบบโลคอลบนการ์ดใบเดียวเป็นองค์ประกอบที่เชื่อถือได้น้อยที่สุดในเชน; การส่งเส้นทาง fallback ผ่าน API เดียวสำหรับ 200+ โมเดล — ราคาตามรายการของผู้ให้บริการส่งผ่านโดยบวกเพิ่ม 0% — ช่วยให้การทดลองไม่กลายเป็นการหยุดให้บริการ และเมื่อโมเดลอย่าง pplx-decider ไปถึงเอนด์พอยต์แบบโฮสต์ในที่สุด คีย์เดียวกันที่รันกลุ่มควบคุมก็รันมันด้วย โดยไม่มีสัญญาที่สองและไม่มีการแก้โค้ด

อะไรจะเปลี่ยนคำตอบ

สี่เรื่อง และทั้งหมดล้วนเป็นสิ่งที่ตรวจสอบได้ ไม่ใช่เรื่องของรสนิยม

หาก pplx-decider ไปถึงผู้ให้บริการ inference ตาราง benchmark ที่ยังไม่ได้ตรวจสอบของมันก็จะกลายเป็นคำถามเรื่องราคาเทียบกับ latency และช่องว่างด้านเอกสารก็จะไม่สำคัญอีกต่อไป — คุณจะจ่ายสำหรับ readout ที่โฮสต์ไว้ ไม่ใช่จ่ายเพื่อดูแลรักษามันเอง หากหน่วยงานอิสระทำซ้ำตัวเลข JevBench ของโมเดลใดโมเดลหนึ่งบน harness ที่เผยแพร่ การเปรียบเทียบทั้งหมดก็จะแคบลงเหลือเพียงชุดเดียว แทนที่จะเป็นสองชุดที่เข้ากันไม่ได้

ถ้าจุดอ่อน ECE ที่มีบันทึกไว้ของ Kev บน CUAD กลายเป็นว่าแก้ได้ด้วยการรีฟิตแทนการรีเทรน ข้อโต้แย้งเรื่องการคาลิเบรตที่ต่อต้านมันก็แทบจะหายไปเกือบทั้งหมด เพราะ Kev มี temperature ติดมาให้อยู่แล้ว และโหมดความล้มเหลวของมันก็เป็นสิ่งที่รู้ค่าแน่นอนแล้ว และถ้าคุณต้องการโมเดลสำหรับตัดสินใจบนการ์ดใบเดียวแทนที่จะเป็นสองใบ บิลด์ควอนไทซ์ขนาด 17 GB ของ pplx-decider ก็เป็นตัวเลือกเดียวในที่นี้ — ไม่ใช่เพราะมันดีกว่า แต่เพราะมันพอดีในที่ที่ 27B ที่ bf16 ไม่พอดี

จนกว่าหนึ่งในสิ่งเหล่านั้นจะเกิดขึ้น ข้อสรุปเชิงปฏิบัติก็ไม่หวือหวาอะไร Kev คือตัวที่คุณนำตัวเลขไปทำซ้ำได้วันนี้ และเป็นตัวที่คุณมั่นใจได้ว่าการปรับเทียบของมันจะมีเอกสารบันทึกไว้ให้ตรวจสอบ ส่วน pplx-decider คือตัวที่อ้างเพดานความสามารถได้ดีกว่า แต่มีร่องรอยเอกสารที่บางกว่า ถ้าคุณจะส่งของเดือนนี้ เลือกตัวแรก ถ้าทีมของคุณเป็นแบบที่อยากวัดผลการปล่อยแบบเงียบ ๆ มากกว่ารอโพสต์เปิดตัว ก็ดึงตัวที่สองเข้ามาใน harness เดียวกัน

การกำหนดเส้นทางสำรองผ่าน ราคาตามรายการของผู้ให้บริการที่ส่งผ่านโดยมีมาร์กอัป 0% ช่วยป้องกันไม่ให้การทดสอบเปรียบเทียบแบบสามทางกลายเป็นเหตุขัดข้อง เมื่อเช็กพอยต์ภายในเครื่องเป็นองค์ประกอบที่เชื่อถือได้น้อยที่สุดในสายโซ่

การทดสอบเปรียบเทียบแบบสามทางยังเป็นจังหวะที่เหมาะสมในการถามว่ามีอะไรที่ล้มเหลวไปแล้วบ้างในคลาสนี้: เหตุการณ์ AI และความล้มเหลวของเอเจนต์ที่เกิดขึ้นจริงซึ่งเกี่ยวข้องกับโมเดลตัดสินใจ ได้รับการรวบรวมไว้ใน the OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง เกรดความเชื่อมั่น และธงระบุว่าเป็นกรณีที่ถูกโต้แย้ง เป็นของตัวเอง