AesCode-8B vs MathForm-8B: ทั้งคู่เป็นโมเดลไฟน์จูนขนาด 8B ที่เครื่องสามารถตรวจสอบผลลัพธ์ได้

AesCode-8B และ MathForm-8B เปิดตัวห่างกันภายในแปดสัปดาห์ ทั้งคู่มาจาก repository ไม่ใช่ press release และความบังเอิญนี้ก็น่าสนใจกว่าที่เห็นในตอนแรก ทั้งคู่เริ่มจาก checkpoint ในตระกูล Qwen3 ทั้งคู่ใช้งบประมาณการเทรนทั้งหมดไปกับรูปร่างของเอาต์พุตที่แคบเฉพาะทาง และทั้งคู่ถูกสร้างขึ้นโดยมีตัวตรวจสอบเป็นแกนกลาง: MathForm-8B ถูกเทรนให้สอดคล้องกับคำตัดสินของคอมไพเลอร์ Lean 4 ส่วน AesCode-8B ถูกให้คะแนนโดยการเรนเดอร์หน้าเว็บแต่ละหน้าประเภทนั้นในเบราว์เซอร์แบบ sandbox แล้วอ่านค่า DOM, computed styles และภาพหน้าจอกลับมา ทั้งคู่ไม่ใช่แชตบอต และไม่มีตัวใดพยายามจะเป็นแชตบอต สิ่งที่แยกสองตัวนี้ออกจากกันคือสิ่งที่เครื่องจักรตรวจสอบได้กับสิ่งที่ตรวจสอบไม่ได้ — และในกรณีของตัวที่ใหม่กว่า นั่นหมายถึงสิ่งที่เกิดขึ้นเมื่อคะแนนครึ่งหนึ่งมาจากผู้ตัดสินที่ไม่มีใครเอ่ยชื่อ

บันทึกการเผยแพร่ไม่สมมาตรกัน MathForm-8B มาจาก OpenBMB และการ์ดโมเดลของมันลงวันที่เผยแพร่เป็น 2026-08-14; มันสร้างขึ้นบน Qwen3-8Bและถูกฝึกบน FormalVerse ซึ่งเป็นคลังข้อมูลตัวอย่าง Lean 4 ที่ผ่านการตรวจสอบแล้วราว 367,000 ตัวอย่าง โดยมีการปรับละเอียดแบบมีผู้สอน (supervised fine-tuning) ตามด้วยการเรียนรู้แบบเสริมกำลัง (reinforcement learning) ที่ใช้การคอมไพล์ Lean และการตรวจสอบความสอดคล้องเชิงความหมายเป็นสัญญาณรางวัล AesCode-8B ไม่มีวันที่เผยแพร่ที่ใดในไฟล์ของมันเลย ไมโครซอฟต์สร้างที่เก็บ Hugging Face เมื่อวันที่ 2026-09-29, คอมมิตน้ำหนักเมื่อเวลา 03:35 UTC วันที่ 2026-10-07 ภายใต้ข้อความ "Release AesCode-8B", และเผยแพร่โค้ดการฝึกบน GitHub เมื่อวันที่ 2026-10-08 ไม่มีประกาศใด ๆ ประกอบทั้งสองเหตุการณ์ การอ้างอิงในการ์ดโมเดลระบุว่า "Under review, 2027" และที่เก็บแสดงยอดดาวน์โหลดสองครั้ง ณ เวลาที่เขียนนี้ มันถูกปรับละเอียดจาก Qwen3-VL-8B-Instruct ซึ่งน่าสังเกตอย่างยิ่งเพราะมันไม่ใช่บรรพบุรุษเดียวกันกับของ MathForm-8B

เชื้อสายอธิบายการแบ่งแยกส่วนใหญ่

Qwen3-8B และ Qwen3-VL-8B-Instruct อยู่ในเจนเนอเรชันเดียวกันและมีชื่อตระกูลร่วมกัน แต่ไม่ได้ทำงานเดียวกัน Qwen3-8B เป็นโมเดลอเนกประสงค์เฉพาะข้อความ โดยมีพารามิเตอร์ทั้งหมดประมาณ 8.2 พันล้านตัว ราว 7 พันล้านตัวในนั้นเป็น non-embedding ใช้ grouped-query attention มีบริบทเนทีฟ 32K โทเคนที่ขยายได้ถึง 131K ผ่าน YaRN และฝึกครอบคลุม 119 ภาษาและภาษาถิ่น Qwen3-VL-8B-Instruct เป็นโมเดลพี่น้องสายวิชัน-ภาษา และเป็น checkpoint ที่ AesCode-8B เริ่มต้นจาก — คอนฟิก AesCode ที่เผยแพร่เป็นสูตร Qwen3-VL ตรง ๆ ที่มี 36 hidden layers, hidden size 4,096, 32 attention heads โดยมี 8 key-value heads และ vocabulary ขนาด 151,936 โทเคน

การแยกสาขานั้นเป็นตัวกำหนดฝั่งอินพุตของโมเดลเฉพาะทางทั้งสองก่อนที่ทั้งคู่จะได้รับการฝึก MathForm-8B รับข้อความและสร้างข้อความในรูปแบบวากยสัมพันธ์ทางการ AesCode-8B รับข้อความพร้อมภาพอ้างอิง (ไม่บังคับ) และสร้างเอกสาร

• ฐาน — MathForm-8B: Qwen3-8B, ข้อความเท่านั้น. AesCode-8B: Qwen3-VL-8B-Instruct, อินพุตรูปภาพและข้อความ.

• พารามิเตอร์ — MathForm-8B: ประมาณ 8.2B. AesCode-8B: ประมาณ 8.8B ใน bf16 โดยแบ่งเป็นสี่ชาร์ด ซึ่ง Hugging Face ปัดเป็น 9B

• ข้อมูลการฝึก — MathForm-8B: FormalVerse ตัวอย่าง Lean 4 ที่ผ่านการตรวจสอบแล้วประมาณ 367K รายการ AesCode-8B: การสาธิตแบบ cold-start จำนวน 3,000 รายการ จากนั้นเป็นการเรียนรู้แบบเสริมกำลัง GDPO บนพรอมป์ต์ 7,408 รายการ เป็นเวลา 400 สเต็ป

• อะไรเป็นตัวตรวจสอบผลลัพธ์ — MathForm-8B: คอมไพเลอร์ Lean 4 พร้อมการตรวจสอบความสอดคล้องเชิงความหมายเทียบกับโจทย์ต้นฉบับ AesCode-8B: การเรนเดอร์ Playwright ในแซนด์บ็อกซ์ พร้อมตัวตรวจสอบแบบดีเทอร์มินิสติกหกตัว และรูบริกที่ให้คะแนนโดยโมเดลหนึ่งรายการ

• สัญญาอนุญาต — ทั้งคู่ใช้ Apache 2.0 ทั้งคู่ไม่มีข้อจำกัดการเข้าถึง ทั้งคู่สืบทอดมาจากแกนหลักของตระกูล Qwen3

• โฮสต์ไว้ที่ใดก็ได้ — ไม่ใช่ทั้งสองอย่าง เท่าที่เราหาเจอ

ความหมายที่แตกต่างกันสองประการของคำว่า “verifiable”

นี่คือความแตกต่างที่ควรค่าแก่การพิจารณาอย่างรอบคอบ เพราะคำว่า "ตรวจสอบได้ด้วยเครื่อง" ถูกใช้กับทั้งสองสิ่ง และมันไม่ได้หมายความเหมือนกัน

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

ตัวตรวจสอบของ AesCode-8B เป็นตัวเรนเดอร์ แคนดิเดตจะถูกเรนเดอร์ในเบราว์เซอร์ Playwright ในแซนด์บ็อกซ์โดยบล็อกคำขอภายนอก และฮาร์เนสอ่านกลับ DOM สไตล์ที่คำนวณแล้ว กล่องขอบเขต สถานะคอนโซล และภาพหน้าจอ ช่องทางกำหนดผลได้หกช่องให้คะแนนสิ่งที่แยกวิเคราะห์ได้ — การรัน ข้อความที่ตรงตามจริง พฤติกรรมขอบเขต ข้อมูลตารางและแผนภูมิ เลย์เอาต์เชิงความหมาย ช่องว่าง — และช่องที่เจ็ด ซึ่งก็คือ Visual Graph Rubric ให้คะแนนเรขาคณิตและการจัดวางผ่านคำถามใช่/ไม่ใช่ที่ผูกกับกราฟ ตารางต้องเป็นตาราง HTML จริงและแผนภูมิต้องเป็นสเปก ECharts ซึ่งเป็นข้อจำกัดที่ทำงานจริง: มันบังคับให้เอาต์พุตอยู่ในรูปร่างที่ผู้ตรวจสอบสามารถแยกวิเคราะห์ได้ ครึ่งที่กำหนดผลได้นั้นทำซ้ำได้จริง ครึ่งที่เกี่ยวกับภาพตัดสินโดยโมเดลภาษา-ภาพซึ่งเอกสารไม่ได้ระบุชื่อ ซึ่งหมายความว่าไม่มีใครนอกห้องแล็บสามารถทำซ้ำได้

ดังนั้น การเปรียบเทียบที่ตรงไปตรงมาจึงไม่ใช่ “อันหนึ่งได้รับการตรวจสอบยืนยันและอีกอันไม่ใช่” แต่เป็นว่า สัญญาณหลักของ MathForm-8B คือคอมไพเลอร์ และสัญญาณรองของมันคือการตรวจสอบความสอดคล้อง ขณะที่สัญญาณหลักของ AesCode-8B คือชุดการยืนยัน DOM แบบดีเทอร์มินิสติก และสัญญาณรองของมันคือความคิดเห็นของโมเดล ซึ่งถูกบรรจุไว้ภายในคะแนนรวมเดียวกัน

แต่ละอันรายงานว่าอะไร และสิ่งนั้นมีค่าเพียงใด

MathForm-8B รายงานค่าเฉลี่ย Pass@8 ที่ 88.06% ภายใต้การตรวจสอบไวยากรณ์ และ 72.37% ภายใต้การตรวจสอบความสอดคล้องใน benchmark ทั้งหกชุด ส่วนที่น่าสนใจคือการกระจายตัวในแต่ละ benchmark: ความสอดคล้อง 95.06% บน FormalIMATH และ 94.83% บน ProverBench จากนั้น 63% บน FATE-H และ 37% บน FATE-X สองรายการหลังเป็นข้อความที่ยากและสมจริง และการลดลงจากระดับกลาง ๆ ของช่วง 90% มาสู่ระดับกลาง ๆ ของช่วง 30% คือภาพที่ตรงไปตรงมาของขีดความสามารถนี้ ตัวเลขทั้งหมดนี้เป็นข้อมูลที่ผู้ขายรายงานและยังไม่ได้รับการทำซ้ำ และการผสม benchmark เอนเอียงไปทางชุดที่ง่ายกว่า

AesCode-8B รายงานคะแนน Overall 82.94 จาก rubric อินโฟกราฟิก 300 ตัวอย่างของ Microsoft — Text 94.06, Boundary 88.36, Chart 87.79, Rule 90.07, Content 86.41, Layout 87.80, Style 53.21, Visual 75.80 — โดยสร้างสามครั้งต่อพรอมป์และไม่มีการเลือกคำตอบ Microsoft ยังรายงานว่ามันเอาชนะ GPT-5.5 ที่ปรับด้วยข้อมูลอ้างอิงซึ่งได้ 81.28 และ Claude Opus 4.8 ซึ่งได้ 80.39 บน rubric เดียวกัน ว่ามีความล้มเหลวร้ายแรงแบบ canvas ล้นเกิดซ้ำใน 4.3% ของ 300 ตัวอย่าง และว่า 22.4 คะแนน Visual แยกคู่หู 32B ออกจาก backbone ของมันเอง ทุกตัวเลขเป็นของผู้ขาย บนงานของผู้ขาย ให้คะแนนเทียบกับมิติที่ผู้ขายออกแบบเอง

ชุดตัวเลขสองชุดนี้ไม่สามารถนำมาเปรียบเทียบกันได้เลย ไม่มีงานเดียวกัน ไม่มีตัวชี้วัดเดียวกัน และไม่มีผู้ตัดสินเดียวกัน การนำ 88.06% ไปวางไว้ข้าง 82.94% ก็เท่ากับเอา อัตราการผ่านของ Lean formalization ไปเปรียบเทียบกับคะแนนรวมของอินโฟกราฟิก และไม่มีโมเดลใดเลยที่เคยถูกประเมินในสิ่งที่อีกโมเดลทำ

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

การรันพวกมันเป็นคนละประเด็นกับคะแนนไม่ว่าคะแนนใด

ทั้งสองเป็นการตัดสินใจเรื่อง self-host ณ วันนี้ MathForm-8B เป็นตัวที่ถูกกว่าแบบทิ้งห่างมาก: เช็กพอยต์แบบข้อความล้วนขนาดประมาณ 8.2B ที่มีงบประมาณการสร้างราว 16K โทเค็นของเอาต์พุต Lean ซึ่งควอนไทซ์ลงบนการ์ดระดับกลางใบเดียวได้ AesCode-8B เป็นโมเดลภาพ-ภาษา 8.8B ที่เส้นทางการให้บริการมีทั้งภาพและข้อความ คำสั่งของการ์ดเองคือ vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576 และน้ำหนัก bf16 17.5 GB บวก KV cache สำหรับ 24,576 โทเค็นและสองภาพ หมายความว่าการ์ด 24 GB นั้นคับแคบ และ 40-48 GB คือพื้นขั้นต่ำที่เป็นจริง ควรจัดงบสำหรับสแต็กการเรนเดอร์ด้วยหากคุณต้องการให้คะแนนเอาต์พุตของคุณเอง เพราะนั่นคือวิธีที่ทุกข้อกล่าวอ้างเรื่องคุณภาพเกี่ยวกับโมเดลนี้ถูกสร้างขึ้น

ต้นทุนแฝงที่ใหญ่กว่าก็คือ โมเดลทั้งสองเป็นโมเดลเฉพาะทางที่คุณจะต้องรับมาใช้อย่างถาวร ทีมที่ต้องทำงานจัดรูปแบบและสร้างเอกสาร ตอนนี้ต้องเดินระบบเสิร์ฟขนาด 8B ถึงสองเส้นทาง พร้อมชุดรูปแบบพรอมป์ต์สองชุด โปรไฟล์ความล้มเหลวสองแบบ และไม่มีโมเดลใดรับงานของอีกโมเดลได้ นั่นคือกรณีที่เลเยอร์จัดเส้นทางถูกสร้างขึ้นมาเพื่อรองรับ: เก็บโมเดลเฉพาะทางไว้ในจุดที่ความคุ้มค่าทางเศรษฐศาสตร์และการจัดการข้อมูลสมเหตุสมผลพอที่จะเป็นเจ้าของ GPU เอง แล้วส่งทราฟฟิกทั่วไปไปยังสิ่งที่โฮสต์อยู่หลังปลายทางเดียวกัน พูดให้ชัดเจนก็คือ โมเดลพี่น้องแบบทั่วไปของฐานทั้งสองนี้เรียกใช้ได้ — Qwen3-VL-8B-Instruct ในราคา 0.18 ดอลลาร์ต่ออินพุตหนึ่งล้านโทเคน และ 0.70 ดอลลาร์ต่อเอาต์พุตหนึ่งล้านโทเคน บนหน้าต่างบริบท 131,072 โทเคน เคียงข้างกับตระกูล Qwen 3.8 และเช็กพอยต์เปิดอื่น ๆ — ทั้งหมดผ่านAPI เดียวของ OrcaRouter ที่ครอบคลุมโมเดลกว่า 200 รุ่น โดยส่งต่อราคาตามรายการของผู้ให้บริการด้วยมาร์กอัป 0% พร้อมการสลับไปยังผู้ให้บริการรายอื่นอัตโนมัติเมื่อเกิดปัญหา โมเดลเฉพาะทางทั้งสองตัวนี้ไม่สามารถจัดเส้นทางได้ที่นี่หรือที่อื่นใดที่เราหาเจอ ส่วนสิ่งที่จัดเส้นทางได้คือโมเดลทั่วไปที่คุณถอยกลับไปใช้เมื่องานเฉพาะเสร็จสิ้น ซึ่งเป็นความแตกต่างระหว่างการลองใช้เช็กพอยต์งานวิจัยกับทำให้มันกลายเป็น dependency ที่เป็นเสาหลักจริง ๆ

ถ้าจำเป็นต้องเลือกระหว่าง两者จริงๆ

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

เลือก AesCode-8B เมื่ออาร์ติแฟกต์จำเป็นต้องเรนเดอร์ ใส่บรีฟเข้าไป ได้เอกสาร HTML ที่แก้ไขได้ออกมา ตารางก็ยังเป็นตาราง และแผนภูมิก็เป็นสเปกของแผนภูมิ และทั้งชิ้นสามารถทำ diff ใน Git ได้ ยอมรับ Style ceiling — 53.21 ซึ่งเป็นมิติที่นิยามว่าต้องไม่มีการแก้ไขภาพเพิ่มเติมก่อนส่งมอบ — เป็นตัววัดที่ตรงไปตรงมาว่ายังเหลือการแก้ไขอีกเท่าใด และยอมรับว่าคอนเท็กซ์ 24,576 โทเคนได้รับการตรวจสอบความถูกต้องเฉพาะบนหน้าอินโฟกราฟิกเดี่ยวเท่านั้น ไม่ใช่เด็คสไลด์หลายหน้าที่ผู้คนต้องการจริง ๆ

แต่จริง ๆ แล้ว ทางเลือกที่ทีมส่วนใหญ่จะต้องเผชิญนั้นไม่ใช่ทั้งสองอย่างนี้ มันคือคำถามว่าผู้เชี่ยวชาญเฉพาะทางแคบ ๆ เหล่านี้สักตัวคุ้มค่าที่จะนำไปดีพลอยหรือไม่ หรือว่าโมเดลเอนกประสงค์ที่อยู่เบื้องหลัง ซึ่งเรียกใช้ผ่าน API นั้นใกล้เคียงพอสำหรับปริมาณงานที่คุณมีหรือไม่ นั่นคือการทดสอบพรอมป์ต์สักครึ่งวันมากกว่าการซื้อ GPU และตัวเลขของทั้งสองการ์ดเองก็ให้เหตุผลแก่คุณในการลองทำ: ความสอดคล้องบนชุดโจทย์ยากของ MathForm-8B อยู่ที่ 37% และคะแนน Style ของ AesCode-8B อยู่ที่ 53% ดังนั้นจึงไม่มีตัวไหนเป็นโมเดลที่คุณจะเอาไปใส่ในไปป์ไลน์โดยไม่มีคนดูแล

สิ่งที่การเปิดตัวทั้งสองครั้งบอกคุณเกี่ยวกับวิธีการปล่อยโมเดลในปัจจุบัน

ไฟน์จูนขนาด 8B สองตัว ห่างกันแปดสัปดาห์ จากสองแล็บที่แตกต่างกัน เปิดตัวโดยไม่มีประกาศ ไม่มีหน้าสินค้า และไม่มีการประเมินอิสระ ทั้งคู่สร้างขึ้นรอบลูปการตรวจสอบยืนยัน ทั้งคู่ใช้ Apache 2.0 และไม่มีใครให้บริการทั้งสองตัว รูปแบบนี้คือเนื้อเรื่องมากกว่าตัวโมเดลใดโมเดลหนึ่ง วิธีการวิจัยได้เคลื่อนเข้าสู่ฟังก์ชันรางวัลแล้ว — สัญญาณคอมไพเลอร์ของ OpenBMB ช่องทางข้ามโมดัลแบบแยกส่วนของ Microsoft — และชิ้นงานที่เผยแพร่ได้กลายเป็นสูตรการฝึกบวกกับเวตต์ โดยมีเปเปอร์ตามมาทีหลัง ถ้ามีเสียด้วยซ้ำ

สิ่งที่หมายความสำหรับใครก็ตามที่อ่านการเปรียบเทียบแบบนี้ก็คือ ตัวเลขของผู้ขายเองคือทั้งหมดที่คุณมีในระยะหนึ่ง และคำถามที่มีประโยชน์ไม่ใช่ว่ามันสูงแค่ไหน แต่คือมันตรวจสอบได้แค่ไหน อัตราการโอเวอร์โฟลว์ของ AesCode-8B และ Style ceiling ของมันคือข้อกล่าวอ้างที่ตรวจสอบได้ซึ่งถูกทำให้ดูเหมือนความล้มเหลว ตัวเลขความสอดคล้อง FATE-X ของ MathForm-8B ก็เป็นสิ่งเดียวกัน นั่นคือตัวเลขที่ต้องอ่าน และเป็นตัวเลขที่ต้องกลับไปรันเองอีกครั้งในทันทีที่ตัวตรวจสอบสามารถทำซ้ำได้ตั้งแต่ต้นจนจบ