Ember-1 กับ MathForm-8B: สองโมเดลที่สร้างขึ้นโดยการจำกัดขอบเขตบนฐานที่ยืมมา

Ember-1 และ MathForm-8B ใช้กลยุทธ์เดียวกันโดยไม่มีแล็บใดโฆษณาว่าเป็นเช่นนั้น ทั้งคู่คือการทำให้โมเดลที่คนอื่นฝึกมาแล้วแคบลงเฉพาะทาง Ember-1 เป็นเวอร์ชันต่อยอดเฉพาะทางของ Kimi K3 จาก Moonshot AI ที่พัฒนาโดย Fireworks Research เผยแพร่เมื่อวันที่ 23 กันยายน 2026 และฝึกใหม่เพื่อให้ได้ความแม่นยำระดับเดียวกับ K3 โดยใช้โทเคนน้อยลงราว 40% MathForm-8B เป็นโมเดล autoformalization ขนาด 8B ของ OpenBMB เปิดตัวเงียบ ๆ เมื่อวันที่ 14 สิงหาคม 2026 ในฐานะไฟน์จูน Apache-2.0 ของ Qwen3-8B จาก Alibaba ที่เปลี่ยนคณิตศาสตร์แบบไม่เป็นทางการให้เป็นข้อความทฤษฎีบท Lean 4 ซึ่งคอมไพเลอร์ตรวจสอบได้ การทำให้แคบลงแบบหนึ่งกำจัดความครุ่นคิดที่สูญเปล่าออกไปและรักษาความสามารถทั่วไปไว้ครบถ้วน ส่วนอีกแบบกำจัดความสามารถทั่วไปเกือบทั้งหมดและแลกมาด้วยความสามารถในการตรวจสอบยืนยันแทน การนำทั้งสองมาไว้ด้วยกันเป็นวิธีที่ชัดเจนที่สุดในการดูว่าการเฉพาะทางมีต้นทุนที่แท้จริงเท่าใด เพราะโมเดลทั้งสองใช้ทุนการฝึกไปกับคนละด้านของบัญชีนั้น

การจำกัดสองประเภท

การแทรกแซงของ Fireworks Research เป็นการปรับเปลี่ยนเชิงพฤติกรรม Ember-1 ยังคงรักษาสถาปัตยกรรมของ Kimi K3 และความกว้างของมันไว้ — คณิตศาสตร์ การเขียนโค้ด การทำตามคำสั่ง การสนทนา การค้นหา การใช้เครื่องมือ และวิศวกรรมซอฟต์แวร์ ต่างปรากฏอยู่ในส่วนผสมของการฝึก — และเปลี่ยนแปลงเพียงว่าโมเดลจะไตร่ตรองนานแค่ไหนก่อนตอบเท่านั้น ผลลัพธ์ที่มีการรายงานคือความยาวในการให้เหตุผลลดลง 35–50% โดยไม่สูญเสียความแม่นยำ across เจ็ดเบนช์มาร์กและ A/B tests ในสภาพแวดล้อมการผลิตของลูกค้าสองราย โดยภาระงานเขียนโค้ดในสภาพแวดล้อมการผลิตหนึ่งงานลดลงจาก 49.3K เหลือ 29.9K โทเคนเอาต์พุต ขณะที่คะแนนของมันยังคงอยู่ที่ 0.753 เทียบกับ 0.751 ตัวเลขทุกตัวเป็นข้อมูลที่ผู้ขายรายงานเองและยังไม่มีการทำซ้ำ

การแทรกแซงของ OpenBMB เป็นไปในเชิงสัญญา MathForm-8B นำ Qwen3-8B มาใช้ และทุ่มงบประมาณการฝึกทั้งหมดไปที่รูปแบบผลลัพธ์เดียว: ข้อความสั่งใน Lean 4 ที่มีส่วนหัว imports และทฤษฎีบทที่ตั้งชื่อไว้ ไปป์ไลน์คือการปรับแต่งแบบมีผู้สอนบน FormalVerse — คอร์ปัสตัวอย่าง Lean 4 ที่ผ่านการตรวจสอบแล้วประมาณ 367,000 ตัวอย่าง ซึ่ง OpenBMB สร้างและเผยแพร่พร้อมกับโมเดล — ตามด้วยการเรียนรู้แบบเสริมกำลังที่ใช้การคอมไพล์ Lean และฟีดแบ็กความสอดคล้องเชิงความหมายเป็นสัญญาณรางวัล โมเดลไม่ได้พิสูจน์ทฤษฎีบท มันเขียนข้อความสั่งที่ตัวพิสูจน์จะทำให้เสร็จ และกรอบของบทความเองก็อธิบายว่าการประเมินบนเบนช์มาร์กหกชุดคือจุดมุ่งหมายของการทดลองนี้

สิ่งที่แต่ละคนยอมสละไป

Ember-1 แทบไม่ได้สูญเสียอะไรเลยบนกระดาษ ซึ่งนั่นคือคำกล่าวอ้างทั้งหมด ตารางที่เผยแพร่ของมันแสดงชัยชนะบน Terminal Bench 2.1 ที่ 82.0% เทียบกับ 80.9% ของ Kimi K3 Max และบน DeepSWE 1.1 ที่ 75.2% เทียบกับ 66.4% พร้อมกับความพ่ายแพ้เพียงเล็กน้อยบน SWE-bench Verified ที่ 92.2% เทียบกับ 93.2% และ SWE-Interact ที่ 20.0% เทียบกับ 21.3% นั่นเป็นตัวเลขจากผู้ขายบนชุดทดสอบที่ผู้ขายเลือกเอง แต่รูปแบบยังสอดคล้องกัน: โมเดลที่ไม่ได้สูญเสียความสามารถมากนัก หากแต่เปลี่ยนทิศทางว่ามันใช้ความพยายามไปที่ไหน อย่างไรก็ตาม การประหยัดโทเคนอยู่ในช่วงตั้งแต่ 51.9% บน Terminal Bench ลงไปถึง 5.9% บน τ-2 Bench Airline ดังนั้น “ประมาณ 40%” จึงเป็นค่าเฉลี่ยที่คลุมการกระจายที่กว้างมาก

MathForm-8B ยอมสละสิ่งที่ Qwen3-8B ขึ้นชื่อเป็นส่วนใหญ่ มันไม่สามารถสนทนาทั่วไปได้ ไม่ครอบคลุม 119 ภาษาและภาษาถิ่นที่ Qwen3-8B ถูกฝึกมา และไม่รับภาพหรือเสียง งบประมาณการสร้างของมันถูกกำหนดขนาดสำหรับเอาต์พุต Lean ไม่ใช่สำหรับการให้เหตุผลแบบผสมผสานที่ขยายออกไป สิ่งที่มันเก็บไว้คือสัญญาอนุญาตแบบเปิดกว้างและขนาดที่เล็ก: safetensors สี่ชาร์ดใน BF16 ทำงานภายใต้ Transformers, vLLM หรือ SGLang หลังเอนด์พอยต์ที่เข้ากันได้กับ OpenAI พร้อมเส้นทางการคอมไพล์ที่คาดหวัง Kimina Lean Server บน Lean 4.21.0

ตัวเลขเหล่านั้นวัดสิ่งที่แตกต่างกัน และช่องว่างนั่นแหละคือประเด็น

ตัวเลขพาดหัวของ Ember-1 คือเปอร์เซ็นต์ของงานที่เอเจนต์ทำงานสำเร็จอย่างถูกต้อง — Terminal Bench 2.1, 89 ตัวอย่าง, 82.0% ตัวเลขพาดหัวของ MathForm-8B คือคะแนน Pass@8 เฉลี่ยจากเกณฑ์มาตรฐานการทำให้เป็นทางการอัตโนมัติ 6 รายการ: 88.06% ภายใต้การตรวจสอบไวยากรณ์ และ 72.37% ภายใต้การตรวจสอบความสอดคล้องที่เข้มงวดกว่า สิ่งเหล่านี้ไม่ได้อยู่บนแกนเดียวกัน ตัวหนึ่งวัดว่าเอเจนต์ทำงานในเทอร์มินัลเสร็จหรือไม่ ส่วนอีกตัววัดว่าข้อความทฤษฎีบทที่สร้างขึ้นสามารถแยกวิเคราะห์ได้หรือไม่ และมีความหมายเหมือนกับปัญหาแบบไม่เป็นทางการที่มันมาจากหรือไม่

ช่องว่าง 88.06 เมื่อเทียบกับ 72.37 ภายในผลลัพธ์ของ MathForm เองคือตัวเลขที่ให้ข้อคิดมากกว่า ช่องว่างระหว่าง "อันนี้คอมไพล์ผ่าน" กับ "อันนี้คอมไพล์ผ่านและสื่อความหมายตรงกับที่ฉันตั้งใจ" อยู่ที่ประมาณสิบหกคะแนน และนี่คือรูปแบบความล้มเหลวที่ทำให้ autoformalization เป็นเรื่องยาก: ข้อความที่ผ่านการตรวจชนิด (type-check) แต่แอบลดทอนข้อกล่าวอ้างเดิมลง กลับแย่กว่าข้อผิดพลาดที่เห็นได้ชัด เพราะไม่มีอะไรในขั้นถัดไปคอยชี้ว่ามันผิด ในชุดที่ยากที่สุด การตรวจสอบความสอดคล้องลดลงเหลือ 63% บน FATE-H และ 37% บน FATE-X ขณะที่ชุดง่ายอย่าง FormalIMATH อยู่ที่ 95.06% และ ProverBench อยู่ที่ 94.83% นั่นคือการที่ผู้เชี่ยวชาญซื่อสัตย์เกี่ยวกับจุดที่ผู้เชี่ยวชาญอ่อนแอ และมีประโยชน์มากกว่าค่าเฉลี่ยเพียงค่าเดียว

ความแตกต่าง ทีละมิติ

• โมเดลฐาน — Ember-1: Kimi K3. MathForm-8B: Qwen3-8B.

• สิ่งที่การฝึกเปลี่ยนไป — Ember-1: ระยะเวลาที่โมเดลใช้ในการให้เหตุผล โดยที่ความสามารถคงเดิม MathForm-8B: สิ่งที่โมเดลส่งออก โดยที่ความเป็น generality ถูกยอมสละไปเป็นส่วนใหญ่

• พารามิเตอร์ — Ember-1: ไม่เปิดเผย. MathForm-8B: ~8B, dense, BF16.

• สัญญาผลลัพธ์ — Ember-1: ข้อความธรรมดาและการเรียกเครื่องมือ ที่คุณภาพระดับ K3. MathForm-8B: ข้อความ Lean 4 ที่มีส่วนหัวและทฤษฎีบทที่ตั้งชื่อ

• สัญญาอนุญาตและเวต — Ember-1: ไม่มีการเผยแพร่; เป็นพรีวิวเพื่อการวิจัยผ่านแพลตฟอร์มของผู้จำหน่ายเอง MathForm-8B: Apache 2.0, ทั้งเวตและชุดข้อมูลสามารถดาวน์โหลดได้

• พาดหัวข่าวที่รายงาน — Ember-1: 82.0% บน Terminal Bench 2.1 โดยใช้โทเค็นน้อยลง 51.9% MathForm-8B: Pass@8 เฉลี่ย 88.06% ภายใต้การตรวจสอบไวยากรณ์, 72.37% ภายใต้การตรวจสอบความสอดคล้อง

• การตรวจสอบยืนยันโดยอิสระ — ไม่มีทั้งสองรายการ ทั้งคู่เป็นข้อมูลที่ผู้ขายรายงานเองและยังไม่มีการทำซ้ำผล

บรรทัดสัญญาอนุญาตตัดสินใจได้มากกว่าผลการทดสอบมาตรฐาน

แม้ตัวเลขจะต่างกันเพียงใด ความต่างในทางปฏิบัติระหว่างสองรุ่นนี้ก็คือวิธีเผยแพร่ MathForm-8B คือไฟล์ OpenBMB เผยแพร่น้ำหนักโมเดล ชุดข้อมูล FormalVerse และเปเปอร์ในวันเดียวกัน ภายใต้ Apache 2.0 โดยไม่มีการประกาศและไม่มี hosted API — การ์ดโมเดลคือการเปิดตัว คุณดาวน์โหลดมันได้บ่ายนี้และรันบน GPU ตัวเดียว และไม่มีใครเอากลับคืนได้ Ember-1 คือบริการ ไม่มีน้ำหนักโมเดล ไม่มีราคาที่ประกาศ และหน้าต่างการเข้าถึงถูกอธิบายว่าเป็นช่วงเวลาเซิร์ฟเวอร์เลสสองสัปดาห์ ซึ่งจะดำเนินต่อไปหรือไม่นั้นขึ้นอยู่กับความต้องการ คุณเรียกใช้มันวันนี้ได้ และคุณไม่อาจแน่ใจว่าจะเรียกใช้มันได้ในเดือนพฤศจิกายน

ความแตกต่างนั้นยังกำหนดว่าแต่ละโมเดลสามารถนำไปใช้ทำอะไรได้ด้วย คอมโพเนนต์สำหรับการทำให้เป็นทางการควรอยู่ภายในไปป์ไลน์ที่คุณควบคุม ตรึงไว้กับเวอร์ชันหนึ่ง โดยมีชุดเครื่องมือ Lean อยู่บนเครื่องเดียวกัน — ซึ่งเป็นเหตุผลว่าทำไมเช็กพอยต์ Apache-2.0 แบบไม่มีการควบคุมการเข้าถึงจึงเป็นรูปแบบที่เหมาะสมกับงานของ MathForm-8B และทำไมลิงก์โค้ด GitHub ที่หายไปบน README ของมัน (ยังเป็นเพียงตัวยึดตำแหน่ง ณ เวลาที่เขียน) จึงเป็นช่องโหว่ที่น่ารำคาญยิ่งกว่าตัวเลข benchmark ใด ๆ โมเดลที่มีต้นทุนการให้เหตุผลควรอยู่หลัง API โดยที่ค่าใช้จ่ายโทเค็นคือสิ่งที่ถูกปรับให้เหมาะสม และเป็นที่ที่ผู้ให้บริการแข่งขันกันในด้านราคาและความหน่วง รูปแบบของ Ember-1 ก็เหมาะกับงานของมันเช่นกัน เพียงแต่หมายความว่าการพึ่งพาเป็นเชิงพาณิชย์มากกว่าเชิงเทคนิค

ในกรณีที่ไปป์ไลน์จะใช้ทั้งสองอย่าง

สองโมเดลนี้เสริมกันมากกว่าแข่งขันกัน และการประกอบกันนี้อธิบายได้ง่าย: ผู้เชี่ยวชาญด้านการทำให้เป็นทางการจะแปลงปัญหาให้เป็นข้อความที่ตรวจสอบได้ และโมเดลการให้เหตุผลจะทำงานกับข้อความนั้นหรืองานวิศวกรรมที่เกี่ยวข้อง ทั้งสองไม่ได้อยู่บน OrcaRouter — MathForm-8B เป็นแบบโฮสต์เองเท่านั้น และ Ember-1 อยู่ในพรีวิวของผู้จำหน่ายเอง — แต่การประกอบกันนี้เองคือแพตเทิร์นที่ routing DSL ของเรามีไว้รองรับ การประกอบโมเดลหลายตัวให้เป็นการเรียกครั้งเดียวคือวิธีที่ไปป์ไลน์จะได้ทั้งโมเดลเฉพาะทางและโมเดลอเนกประสงค์ โดยไม่ต้องดูแลเส้นทางผสานรวมสองเส้นทางและสัญญาสองฉบับ และการหลอมรวมโมเดลยังไปได้อีกขั้นหนึ่งด้วยการเปิดให้กลุ่มโมเดลตอบร่วมกันเมื่อโหมดความล้มเหลวของโมเดลเพียงตัวเดียวมีต้นทุนสูง

โดยเฉพาะอย่างยิ่งสำหรับสแตกการทำฟอร์มัลไลเซชัน เหตุผลสนับสนุนการประกอบ (composition) นั้นแข็งแรงกว่าปกติ โหมดความล้มเหลวที่มองเห็นได้คือข้อความที่คอมไพล์ผ่านแต่มีความหมายต่างออกไปเล็กน้อย และการป้องกันที่ประหยัดที่สุดต่อข้อผิดพลาดแบบเงียบคือโมเดลตัวที่สองที่อ่านปัญหาเดียวกัน ซึ่งเป็นการตัดสินใจด้านการจัดเส้นทาง ไม่ใช่การตัดสินใจด้านการฝึก

อันไหนน่าซื้อกว่ากัน

หากคุณต้องการคณิตศาสตร์ที่ตรวจสอบได้ด้วยเครื่อง MathForm-8B เป็นตัวเดียวในสองตัวที่ให้ผลลัพธ์แบบนั้นได้ และต้นทุนหลักของมันคือความทั่วไปที่คุณไม่ได้จะใช้สำหรับงานนี้อยู่แล้ว ดาวน์โหลดมันมา กันงบไว้สำหรับ Lean server และสร้าง evaluation ของคุณเอง — เปเปอร์ของ OpenBMB จะไม่บอกคุณว่ามันทำงานได้แค่ไหนบน distribution ของคุณ

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

ข้อสรุปที่ชวนอึดอัดสำหรับใครก็ตามที่หวังว่าโมเดลใดโมเดลหนึ่งในนี้จะยุติคำถามได้ก็คือ ไม่มีตัวใดเลยที่ได้รับการประเมินโดยอิสระ MathForm-8B เปิดเผยต่อสาธารณะมาแล้วหกสัปดาห์ และยังไม่มีบุคคลที่สามรายใดเผยแพร่ผลการทำซ้ำ ส่วน Ember-1 เพิ่งเปิดเผยต่อสาธารณะมาได้หนึ่งวัน ทั้งคู่ต่างผลักให้คุณเป็นผู้ประเมิน ซึ่งเป็นสภาวะปกติของการเลือกโมเดลเฉพาะทางในปี 2026

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