Laya บน Apple Silicon: การพอร์ต MLX ให้อะไรกับคุณ และไม่ให้อะไร

Laya เป็นโมเดลตัดสินใจที่ไม่เคยเขียนประโยคใด ๆ Convai Innovations ได้เผยแพร่เวตของมันบน Hugging Face เมื่อวันที่ 18 กันยายน 2026 และในวันถัดมา นักพัฒนาชื่อ mizorewww ก็ได้เผยแพร่ Laya-MLX — พอร์ตอิสระที่รันเช็กพอยต์ทั้งสามของ Laya แบบเนทีฟบน Apple Silicon ผ่าน MLX โดยไม่ต้องใช้ PyTorch ไม่ต้องมีรันไทม์ Transformers และไม่มีการเรียกคลาวด์ พอร์ตดังกล่าวรายงานค่ามัธยฐาน 13.42 มิลลิวินาทีสำหรับคำถามภาษาอังกฤษสั้น ๆ หนึ่งข้อบนเช็กพอยต์ขนาด 421M, 7.39 มิลลิวินาทีบนรุ่นหลายภาษาขนาด 322M และมีโทเคนเอาต์พุตเป็นศูนย์ บน M3 Max ในขณะเดียวกัน Kev ซึ่งเป็นอีกตระกูลโอเพนซอร์สที่ไล่ตามแนวคิดการตัดสินใจแบบมีชนิดเดียวกัน ถูกสร้างบน Qwen3.5-4B-Base และต้องมีแบ็กเอนด์ที่สองเพิ่มเต็ม ๆ ก่อนจะใช้งานได้บน Mac เพราะ PyTorch ไม่มีเคอร์เนลสำหรับเลเยอร์ DeltaNet ของมันบน GPU ของ Apple สองโปรเจกต์ สัปดาห์เดียวกัน เป้าหมายเดียวกัน และมีเพียงหนึ่งในนั้นที่พอร์ตได้อย่างราบรื่น ความแตกต่างนั้นคือเรื่องราว และมันเป็นเรื่องราวของรันไทม์มากกว่าเรื่องราวของโมเดล

เหตุผลที่เรื่องนี้คุ้มค่าจะเป็นบทความในวันนี้ ไม่ใช่เพราะ Laya เป็นของใหม่ แต่เพราะจนถึงวันที่ 2026-09-19 ยังไม่มีวิธีรันโมเดลการตัดสินใจแบบมีชนิดบน Mac โดยไม่ต้องลากสแตก PyTorch ติดมาด้วย และคำถามที่ผู้อ่านมีจริง ๆ — ฉันรันสิ่งนี้บนแล็ปท็อปได้ไหม และฉันต้องแลกอะไรไป — ในที่สุดก็มีคำตอบที่วัดผลได้ ดังนั้นบทความนี้จึงว่าด้วยเส้นทางการเสิร์ฟ ตัวเลขที่อยู่เบื้องหลัง และจุดที่ตัวเลขเหล่านั้นเลิกมีความหมายอย่างที่หน้าตาของมันบอก

ก่อนอื่น สิ่งที่ Laya ไม่ใช่

Laya ไม่ใช่ LLM มันทำงานแบบ non-autoregressive: forward pass แบบสองทิศทางเพียงครั้งเดียวบน state บวกกับคำถามของคุณ แล้วส่งออกมาเป็นคำตอบที่มีชนิดข้อมูลกำกับ ไม่มีการถอดรหัสทีละโทเคน ไม่มี chain of thought ไม่มี JSON ที่สร้างขึ้นมาให้ต้องแยกวิเคราะห์ และไม่มีโทเคนเอาต์พุตให้ต้องจ่ายเงิน องค์ประกอบพื้นฐานของคำตอบมีสามแบบคือ choice (เลือกหนึ่งจาก N ตัวเลือกที่มีชื่อ) score (ระดับตามเกณฑ์แบบลำดับ) และ noul (ความน่าจะเป็นที่ปรับเทียบแล้วว่าสิ่งหนึ่งเป็นจริง)

นั่นสำคัญต่อวิธีที่คุณอ่านตัวเลขทุกตัวในบทความนี้ เมื่อพอร์ตรายงาน 13.42 มิลลิวินาที มันไม่ได้รายงาน 13.42 มิลลิวินาทีเพื่อสร้างโทเคนไม่กี่ร้อยตัวแบบที่เบนช์มาร์กการสร้างจะทำ มันกำลังรายงานการดำเนินการทั้งหมด การเปรียบเทียบเวลาแฝงของโมเดลตัดสินใจกับโทเคนต่อวินาทีของ LLM คือการเปรียบเทียบงานสองอย่างที่แตกต่างกัน และบทความใดก็ตามที่ทำเช่นนั้น — รวมถึงโพสต์ไวรัล "เร็วกว่า Jev 50 เท่า" ที่เผยแพร่หลังการเปิดตัว — กำลังสร้างคำกล่าวอ้างที่งานเบื้องหลังไม่สนับสนุน

สิ่งที่ท่าเรือวัดได้จริง

ตัวเลขเหล่านี้เป็นของผู้จัดทำพอร์ตเอง วัดบนเครื่องที่ระบุไว้ และควรอ่านควบคู่ไปกับเครื่องและวิธีการที่แนบมาด้วย Laya-MLX วัดค่าเหล่านี้บน M3 Max ที่มีแกน GPU 40 แกน และหน่วยความจำแบบรวม 128 GiB ที่ FP16 โดยไม่นับรวมการโหลดโมเดล

• หนึ่งคำถามสั้น P50 — 13.42 มิลลิวินาทีบนเช็กพอยต์ภาษาอังกฤษ 421M, 7.39 มิลลิวินาทีบนเช็กพอยต์หลายภาษา 322M

• คำถามสั้นหนึ่งข้อ, P95 — 13.92 ms และ 7.79 ms ตามลำดับ

• ปริมาณงาน 50 คำถาม — 146.8 คำถามต่อวินาที และ 395.0 คำถามต่อวินาที

• การจัดสรร MLX สูงสุด — 943.6 MiB และ 687.6 MiB

ขอบเขตการจับเวลาเป็นส่วนที่ควรอ่านซ้ำสองครั้ง โดยครอบคลุมการเตรียมพรอมต์ การแปลงเป็นโทเคน การสร้างเทนเซอร์ การอนุมานแบบซิงโครไนซ์ การคาลิเบรต และการจัดรูปแบบผลลัพธ์ แต่ไม่รวมการโหลดโมเดล การรันวัดปริมาณงานกับคำถาม 50 ข้อใช้ batch_size=64 ขณะที่ค่าเริ่มต้นของ API อยู่ที่ 16 ดังนั้นตัวเลขคู่นี้อธิบายภาระงานที่จัดเป็นแบตช์โดยเจตนา มากกว่าต้นทุนของการเรียกแบบโต้ตอบเพียงครั้งเดียว ความยาวอินพุตที่แตกต่างกัน จำนวนคำถามที่แตกต่างกัน และสภาวะรันไทม์ที่แตกต่างกัน ล้วนส่งผลให้ผลลัพธ์เปลี่ยนไป ข้อควรระวังเหล่านั้นคือความแตกต่างระหว่างตัวเลขกับการวัดมาตรฐาน และพอร์ตเองก็ระบุไว้

ค่าพื้นหน่วยความจำคือตัวเลขที่ผู้อ่านส่วนใหญ่จะนำไปใช้ตัดสินใจ และเป็นค่าที่กำกวมน้อยที่สุดในชุดนี้: การจัดสรร MLX สูงสุดต่ำกว่าหนึ่งกิกะไบต์สำหรับคำถามสั้น ๆ เพียงข้อเดียว บนทั้งสอง checkpoint นั่นไม่ใช่ข้อกล่าวอ้างเกี่ยวกับ footprint รวมของ Mac คุณ — ระบบปฏิบัติการ เทอร์มินัลของคุณ และโปรเซส Python ต่างก็อยู่เคียงข้างกัน — แต่มันเป็นค่าพื้นที่แท้จริง และต่ำกว่าสิ่งที่การรันโมเดลสร้างสรรค์ขนาดกลางในเครื่องต้องใช้ราวสามลำดับขนาด

การตรวจสอบความเที่ยงตรงเป็นผลลัพธ์ที่น่าสนใจกว่า

พอร์ตที่เร็วแต่ให้คำตอบต่างจากโมเดลที่มันพอร์ตมา ย่อมไร้ค่า และนี่คือจุดที่โครงการได้ลงมือทำงานที่สำคัญ ช็екพอยต์ทั้งสามตรงกับคำตอบที่เลือกจากต้นทางในคำถามตรวจสอบ 63 จาก 63 ข้อ ทั้งใน FP32 และ FP16 — คิดเป็นการเปรียบเทียบ 378 จาก 378 ครั้ง แต่ละการตั้งค่ายังรันการเรียกซ้ำแบบดีเทอร์มินิสติก 100 ครั้ง โดยไม่พบการเพิ่มขึ้นของหน่วยความจำที่ใช้งานอยู่เมื่อวัด และไฟล์น้ำหนักที่เผยแพร่ทั้ง 36 ไฟล์ผ่านการตรวจสอบเช็กซัมจากระยะไกลอย่างเข้มงวด

อ่านขอบเขตอย่างตรงไปตรงมา: นั่นวัดความตรงตามต้นฉบับบนฟิกซ์เจอร์เหล่านั้น ไม่ใช่ความถูกต้องต่อทุกคำถามที่เป็นไปได้ มันบอกคุณว่าพอร์ตนั้นซื่อตรงต่อ Laya มันไม่ได้บอกอะไรเลยว่า Laya ถูกต้องหรือไม่

อิสระ ดำเนินการโดยชุมชน และยังไม่อยู่ในรายการ

พอร์ตนี้พูดถึงตัวเองแบบนี้ สองครั้ง: มันเป็นพอร์ต MLX แบบอิสระ ไม่ใช่รุ่นอย่างเป็นทางการจาก Convai Innovations การฝึกและการปรับแต่ง RLCD ยังคงอยู่ที่ต้นทาง น้ำหนักให้เครดิตแก่ Convai Innovations Apache-2.0 ทั้งสองฝ่าย

วิธีที่อัปสตรีมจัดการกับเรื่องนี้เผยให้เห็นได้มากกว่าคำปฏิเสธความรับผิดใด ๆ README ของ Laya มีรายการ Community Tools และ ณ วันที่ 2026-09-23 รายการนั้นมีสี่รายการ: omp-laya-judge, laya-adk-toolkit, laya-Ascend สำหรับ NPU ของ Huawei Ascend และ laya-apple — รันไทม์ Apple Silicon ที่ใช้ MLX GPU และ Neural Engine รายการที่สี่นั้นเข้ามาผ่าน pull request #260 ซึ่งถูก merge เมื่อ 2026-09-23 พอร์ตที่บทความนี้กล่าวถึงไม่ได้อยู่ในสี่รายการนั้น รายการของอัปสตรีมตอนนี้ชี้ผู้อ่าน Apple Silicon ไปยังโปรเจกต์ชุมชนอีกโปรเจกต์หนึ่ง ซึ่งต่างจากโปรเจกต์ที่เปิดตัวก่อนและมีผลเบนช์มาร์ก

ตัวติดตามปัญหาของ Upstream เองบอกส่วนที่เหลือไว้แล้ว Issue #50 "Apple silicon ports" เปิดเมื่อ 2026-09-21 ยังคงเปิดอยู่ ผู้ดูแลตอบในวันเดียวกันว่ากำลังติดตามการรองรับ Apple Silicon และพอร์ตจากชุมชนอย่าง Laya-MLX กำลังสำรวจการอนุมาน Metal แบบเนทีฟ จากนั้นตอบอีกครั้งเมื่อ 2026-09-23 ด้วยประโยคที่ควรยกมาอ้างแบบตรงตัวว่า "The MLX port remains community-maintained." การแก้ไขฝั่ง PyTorch — MPS autocast และการแก้ไข RoPE ของ transformers 4.x — ถูกนำเข้าเป็น pull request #273 ซึ่ง merge เมื่อ 2026-09-23 โดยมีผู้รีวิวในเธรดนั้นชี้ว่ายังต้องรวมเข้ากับการ refactor autocast แยกต่างหากใน #109 ซึ่งยังเปิดอยู่ และ issue #52 ที่เปิดเมื่อ 2026-09-21 รายงานว่า sidecar ของ Laya-MLX มีหน่วยความจำ Metal เพิ่มขึ้นเป็นประมาณ 21.7 GB ภายในเวลาหลายชั่วโมงของการทำงาน โดยมี vmmapระบุว่าประมาณ 21.4 GB เป็นของระบบย่อยกราฟิกมากกว่าฮีป Python; มันเสนอให้จำกัดขนาดแคชของ allocator และล้างแคชหลังการอนุมานแต่ละครั้ง และยังเปิดอยู่

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

รันบนแล็ปท็อปของฉันได้ไหม แล้วต้องแลกกับอะไรไปบ้าง

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

pip install laya-mlx

จากนั้น import laya_mlx as laya แล้ว agent = laya.load("aac6fef/laya-mlx") และเรียก agent.predict(state, questions) โดยความต้องการขั้นต่ำคือ Apple Silicon, Python 3.11+ และ macOS 14+ สภาพแวดล้อมที่วัดได้คือ macOS 27.2, Python 3.12.13 และ MLX 0.32.2 — และบันทึกการพอร์ตระบุว่าเวอร์ชัน MLX ที่ใช้นั้นมี wheel สำหรับ macOS 14, 15 และ 26 ขณะที่ตัวติดตั้งเลือกตัว 26 และยังไม่ได้ทดสอบ macOS เวอร์ชันเก่าที่รองรับบนเครื่องนั้น

สิ่งที่คุณต้องเสียไป ทีละมิติ:

• FP16 เทียบกับ FP32 — FP16 เป็นค่าเริ่มต้นและเป็นแหล่งที่มาของตัวเลขสำคัญทั้งหมดข้างต้น FP32 ให้ความสอดคล้องทางตัวเลขที่ใกล้เคียงกับ upstream มากกว่า และความน่าจะเป็นอาจแตกต่างกันเล็กน้อยระหว่าง precision ต่างๆ แม้ว่าป้ายกำกับที่เลือกจะตรงกันก็ตาม BF16 สามารถร้องขอได้แต่ไม่ได้เป็นส่วนหนึ่งของเมทริกซ์การตรวจสอบที่เผยแพร่ ดังนั้นให้ถือว่ายังไม่ได้ทดสอบ

• พื้นหน่วยความจำเทียบกับส่วนเผื่อ — การจัดสรร MLX สูงสุดต่ำกว่า 1 GiB สำหรับคำถามสั้น ๆ ถือว่าสบายบน Mac ซีรีส์ M ทุกรุ่น นี่ไม่ใช่ข้อความเกี่ยวกับภาระเซิร์ฟเวอร์แบบต่อเนื่อง และ issue #52 คือเหตุผลที่ต้องระวัง หากคุณวางแผนจะรันสิ่งนี้เป็น sidecar ที่ทำงานยาวนานแทนที่จะเป็นการเรียกใช้ไลบรารี

• หลายภาษาเทียบกับภาษาอังกฤษ — เช็กพอยต์หลายภาษาขนาด 322M เป็นตัวที่เร็วกว่าในสองตัว และเป็นตัวที่ครอบคลุมภาษามากกว่า 100 ภาษา แต่พอร์ตนี้ตั้งใจส่งต่อคำเตือนของอัปสตรีมต่อไปโดยเจตนา: เช็กพอยต์ภาษาอังกฤษไม่ใช่ตัวใช้แทนเช็กพอยต์หลายภาษา การจัดเส้นทางระหว่างทั้งสองเป็นรูปแบบที่ตั้งใจไว้ ไม่ใช่แค่ของแถม

• ได้รับการรับรองจาก upstream เทียบกับดูแลโดยชุมชน — คำตอบคืออย่างหลัง ไม่มีอะไรในบันทึกประจำรุ่นของ upstream ที่รับประกันว่าพอร์ตนี้จะยังทำงานต่อไปได้เมื่อ upstream มีการเปลี่ยนแปลง

• ความเร็วเทียบกับการปรับคาลิเบรชัน — การพอร์ตที่เร็วไม่ได้แก้บัคเก็ตคาลิเบรชันที่ส่งออกมาอย่างมั่นใจเกินไป ต้นทางจำกัดอุณหภูมิที่ปรับให้อยู่ในช่วง [0.5, 5.0] และบัคเก็ต choice:11+ ที่ส่งออกมามีค่า 0.1006 ซึ่งจะทำให้ลอจิตรุนแรงขึ้นราวสิบเท่าและรายงานการโยนเหรียญว่าเกือบแน่นอน อุณหภูมิคาลิเบรชันที่ปรับแล้วมีอยู่ด้วยเหตุผลบางอย่าง จงปรับมันกับข้อมูลที่กันไว้ของคุณเองก่อนที่คุณจะตัดสินใจบนความน่าจะเป็น

ยังมีข้อจำกัดอีกสองข้อที่ควรจดจำไว้ ทั้งคู่มาจากตัวติดตามของ upstream เอง action.act_probabilityตอนนี้ไม่ได้ให้สัญญาณที่ใช้งานได้ — มันให้ค่า 1.0 กับอินพุตเกือบทุกตัว และ logits ดิบของมันสวนทางกับความถูกต้องที่ AUROC 0.30 จากการตัดสิน 396 รายการที่ติดป้ายกำกับ (issue #185) ให้ใช้ confidenceเป็นเกณฑ์แทน ซึ่งทำได้ถึง 0.77 กับรายการเดียวกัน และnoulคำถามสามารถยึดตามป้ายตัวเลือกของมันแทนที่จะยึดตาม state (issue #156) — การ์ดของ upstream เองรายงานคำตอบ "no" ที่มั่นใจบนอินพุตที่เป็นบวกอย่างชัดเจน โดยชัดเจนที่สุดบน checkpoint ภาษาอังกฤษ วิธีเลี่ยงปัญหาที่มันแนะนำไม่ใช่การไปหยิบโมเดลอื่นมาใช้ แต่เป็นการปรับรูปคำถามใหม่: ถามเป็นchoiceที่มีคีย์เป็นกลาง (A/B) และใช้ถ้อยคำ yes/no ของคุณเป็นคำอธิบายตัวเลือก

ทำไมโมเดลการตัดสินใจแบบหนึ่งจึงพอร์ตได้อย่างราบรื่น แต่อีกแบบหนึ่งกลับทำไม่ได้

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

แกนหลักของ Laya คือ ModernBERT-large ซึ่งเป็นเอนโคเดอร์แบบสองทิศทางที่สร้างขึ้นจาก attention ทั้งหมด attention เป็นสิ่งที่สแต็ก GPU ของ Apple เก่งที่สุด และเป็นสิ่งที่ MLX ได้ทุ่มเทความพยายามไปกับมัน ดังนั้นการพอร์ตจึงเป็นการนำเลเยอร์ที่มี fast path อยู่แล้วกลับมาสร้างใหม่: เอนโคเดอร์, เลเยอร์ Transformer ของ decision head, scoring head และ action head ทำงานทั้งหมดใน MLX และการทำโทเคนไนเซชันยังคงผ่าน Rust tokenizer ของ Hugging Face

แบ็กโบนของ Kev เป็นฐาน Qwen3.5 และ Qwen3.5 ผสมเลเยอร์ attention เข้ากับเลเยอร์ Gated DeltaNet DeltaNet เป็นแบบรีเคอร์เรนต์และไม่สนใจ attention mask สิ่งนี้ส่งผลสองประการ ประการแรก คำถามแต่ละข้อต้องรันเป็นแถวของตัวเอง แทนที่จะใช้ลำดับที่ถูกมาสก์ร่วมกันเพียงลำดับเดียว ซึ่งโปรเจกต์ Kev จัดการโดยคำนวณ state ครั้งเดียวแล้วนำแคชกลับมาใช้ซ้ำในแต่ละแถว ประการที่สอง — และนี่คือส่วนที่สร้างปัญหาบน Mac — ไม่มีเคอร์เนล PyTorch สำหรับเลเยอร์เหล่านั้นบน GPU ของ Apple PyTorch จึงถอยกลับไปใช้โค้ดอ้างอิง jaredpalmer/kev-4bการ์ดโมเดลยังคงระบุข้อจำกัดที่เป็นผลตามมาไว้อย่างตรงไปตรงมา: คำขอห้าคำถามที่ใช้เวลา 0.17 วินาทีบนบิลด์ Qwen3 ของ Kev-4B ใช้เวลา 0.78 วินาทีใน bf16 บน M5

ตรวจสอบถ้อยคำปัจจุบันก่อนจะอ้างข้อความนั้น เพราะมันเปลี่ยนไปแล้ว ตอนนี้ README ของที่เก็บ Kev ระบุว่าเซิร์ฟเวอร์รันโมเดล Qwen3.5 ผ่าน MLX บน Apple Silicon แทน และเผยแพร่ตัวเลข M5 ของตัวเองสำหรับคำขอแบบห้าคำถามที่มีสามตัวเลือกในแต่ละข้อ บนสถานะขนาดประมาณ 270 โทเคน: Kev-4B อยู่ที่ 721 มิลลิวินาทีบนสถานะใหม่ และ 136 มิลลิวินาทีบนสถานะซ้ำผ่านแคชคำนำหน้า เทียบกับ 3,302 มิลลิวินาทีและ 847 มิลลิวินาทีบนเส้นทาง PyTorch bf16 MPS Kev-0.8B อยู่ที่ 149 มิลลิวินาทีและ 28 มิลลิวินาที โมเดล Qwen3 รุ่นก่อนหน้ายังคงรันบน PyTorch MPS ธรรมดา และโครงการเรียกว่าเป็นตัวเลือกที่ดีบน Mac

ระวังอย่าทำให้สิ่งนั้นกลายเป็นผลการแข่ง นี่ไม่ใช่การวัดแบบเผชิญหน้ากันโดยตรง 13.42 ms ของ Laya-MLX คือคำถามสั้นหนึ่งข้อบน M3 Max ส่วน 721 ms ของ Kev คือคำถามห้าข้อ โดยแต่ละข้อมีสามตัวเลือก บนสเตตประมาณ 270 โทเคนบน M5 จำนวนคำถามต่างกัน จำนวนตัวเลือกต่างกัน ความยาวสเตตต่างกัน เครื่องต่างกัน รันไทม์ต่างกัน สิ่งที่ตรวจสอบได้และน่าจะนำมาเปรียบเทียบคือรูปร่างของปัญหา ไม่ใช่ผู้ชนะ เอนโคเดอร์แบบ pure-attention พอร์ตไปยัง Apple Silicon ได้อย่างราบรื่น และโมเดล hybrid linear-attention ต้องมีแบ็กเอนด์ที่สองทั้งชุดก่อนจึงจะใช้งานได้ที่นั่น

โมเดลการตัดสินใจมีไว้เพื่ออะไรกันแน่

ถ้าตัดเรื่องเกณฑ์มาตรฐานออกไป กรณีการใช้งานที่สมเหตุสมผลจริง ๆ ก็แคบลงมาก และตัวโปรเจกต์เองก็ยอมรับเช่นนั้น: Laya เป็นฐานที่เร็วสำหรับนำไปปรับแต่งเฉพาะทาง ไม่ใช่ระบบตัดสินใจแบบ zero-shot บนเกณฑ์มาตรฐาน typed-decisions ของ Convai เอง เช็กพอยต์ฐานทั้งสองตัวได้คะแนน 0.362 และ 0.342 แบบ zero-shot เทียบกับเส้นฐาน majority-class ที่ 0.461 และแบบสุ่มที่ 0.318 ทั้งสองตัวต่ำกว่าเส้นที่คุณจะได้จากการตอบป้ายที่พบบ่อยที่สุดเสมอ คะแนนพาดหัว 0.766 นั้นเป็นของ laya-typed-decisions ซึ่งเป็นเช็กพอยต์ที่ปรับละเอียดบนชุดฝึกของเกณฑ์มาตรฐานนั้นเอง และไม่ควรนำมาอ้างอิงเป็นความสามารถทั่วไปเลย

การเปรียบเทียบที่ Convai เผยแพร่กับ TypeSafe Jev 1.13.0 นั้นคุ้มค่าที่จะอ่านด้วยเหตุผลนี้พอดี และฝั่งของพวกเขาติดป้ายกำกับไว้อย่างระมัดระวัง: ตัวเลขทุกตัวของ Laya คือสิ่งที่เราเตอร์ส่งคืนจริง ขณะที่ตัวเลขของ Jev เป็นตัวเลขที่บุคคลที่สามเผยแพร่ ซึ่ง Convai ไม่เคยวัดเพราะไม่มีสิทธิ์เข้าถึง TypeSafe API ในการเปรียบเทียบนั้น Laya ที่ถูกจัดเส้นทางได้คะแนน 0.766 เทียบกับ 0.727 ของ Jev ในด้าน typed-decisions โดยมี ECE หลังปรับอุณหภูมิ 0.081 เทียบกับ 0.246 และความหน่วง p50 ที่ 32.8 ms เทียบกับ 236–276 ms บน Tesla T4 — ต่างกัน 7.8 เท่าในคำถามเดียว นั่นคือตัวเลขที่ควรอ้างอิง ตัวเลข “เร็วกว่า Jev 50 เท่า” ที่แพร่กระจายบนโซเชียลมีเดียไม่ปรากฏในเอกสารของโครงการหรือ benchmark ของโครงการ และการเปรียบเทียบที่โครงการเองเผยแพร่ก็ไม่สนับสนุนตัวเลขนั้น Jev ยังนำในจุดที่มันนำ: บน Banking77 Jev ได้คะแนน 0.870 เทียบกับ 0.425 ของ Laya เพราะตัวเลือกของ Laya ใช้โควตาโทเค็นแบบคงที่ร่วมกัน และป้ายกำกับ 77 ป้ายเหลือเพียงประมาณสามถึงสี่โทเค็นต่อป้าย

ดังนั้นรูปร่างของการดีพลอยจริงคือ decision head ที่ราคาถูก อยู่ในเครื่อง และขอบเขตแคบ — จัดเส้นทางตั๋ว ให้คะแนนความเร่งด่วน ตอบเกตใช่/ไม่ใช่ — โดยมีส่วน generative อยู่เบื้องหลังสำหรับส่วนที่ต้องเขียน โมเดลตัดสินใจเรียกแบบมีชนิดข้อมูลภายในไม่กี่มิลลิวินาทีและส่งต่อไป ครึ่ง generative เป็นโมเดลคนละตัวบนรันไทม์คนละตัว และนั่นคือจุดที่เราเตอร์เข้ามามีบทบาท: โมเดลกว่า 200 ตัวหลังคีย์เดียวในราคาตามรายการของผู้ให้บริการโดยไม่บวกเพิ่ม ดังนั้นการเปลี่ยนราคาของผู้ขายจึงมีผลในวันเดียวกัน และ การสลับสำรองอัตโนมัติเมื่อผู้ให้บริการประสิทธิภาพลดลงกลางการทำงาน OrcaRouter ไม่ได้ให้บริการ Laya และไม่ได้ให้บริการ Kev หรือ Jev — ตระกูล Qwen3.5 อยู่ในรายการโมเดลของเรา และตัวโมเดลตัดสินใจเองไม่ได้อยู่ในนั้น สิ่งที่เราครอบคลุมคือครึ่ง generative ของสแต็กนั้น ซึ่งเป็นครึ่งที่คุณเรียกใช้ในทุกคำขอที่ decision head ส่งต่อไป

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

ใครควรเป็นคนรันมัน และใครควรจะรอ

รัน Laya-MLX หากคุณใช้ Mac ซีรีส์ M การตัดสินใจของคุณถูกจำกัดให้อยู่ในรูปแบบใดรูปแบบหนึ่ง — การเลือกจากตัวเลือกที่มีชื่อกำกับ คะแนนตามรูบริก หรือเกตใช่/ไม่ใช่ — และคุณมีเลเบลสำหรับ fine-tune หรือพร้อมที่จะปรับอุณหภูมิคาลิเบรชันด้วยตัวเอง การติดตั้งใช้คำสั่งเดียว หน่วยความจำขั้นต่ำต่ำกว่าหนึ่งกิกะไบต์ และงานด้านความเที่ยงตรงได้ทำเสร็จและเผยแพร่แล้ว

รอ หากคุณต้องการการรับประกันการสนับสนุนจาก upstream หากคุณกำลังรัน sidecar ที่มีอายุการใช้งานยาวนานและต้องการให้คำถามเรื่องการเติบโตของหน่วยความจำได้รับการแก้ไขในรีลีสมากกว่าเป็น issue ที่ยังเปิดอยู่ หรือหากคำถามของคุณเป็นแบบปลายเปิด เอนโคเดอร์แบบ non-autoregressive ที่ตอบคำถามว่า "ฉันควรทำอะไรต่อไป" ไม่ใช่เวอร์ชันที่เล็กกว่าของ LLM ที่ทำสิ่งเดียวกัน มันเป็นเครื่องมือที่แตกต่าง และมันจะอ่านได้ดีก็ต่อเมื่อคำถามถูกจัดรูปมาเพื่อมันแล้ว