Recursive Flint v1.0: โมเดลเขียนโค้ดขนาด 40B ที่สร้างขึ้นส่วนใหญ่ด้วยลูปการวิจัยของมันเอง

ประโยคที่น่าสนใจที่สุดในRecursive Flint v1.0 รีลีส ไม่ใช่คะแนนเบนช์มาร์ก แต่เป็นประโยคที่ Recursive กล่าวว่าทีมเล็ก ๆ สร้างโมเดลเขียนโค้ดขนาด 40,000 ล้านพารามิเตอร์ขึ้นมาจากศูนย์ภายในเวลาไม่ถึงสี่เดือน โดยมีระบบวิจัยอัตโนมัติชื่อ Eureka Machine ช่วยในเกือบทุกขั้นตอน Flint ถูกประกาศออกมาในฐานะโมเดลเขียนโค้ดโลคัลที่แข็งแกร่ง — มีพารามิเตอร์ทั้งหมด 39,800 ล้านตัว เปิดใช้งานประมาณ 2,500 ล้านตัวต่อโทเคน ใช้ Apache 2.0 และทำงานได้สบายบนแล็ปท็อป แต่การเปิดตัวครั้งนี้ยังเป็นการทดสอบต่อสาธารณะครั้งแรกของข้อเสนอที่ต่างออกไป นั่นคือกระบวนการสร้างโมเดลเองสามารถถูกทำให้เป็นอัตโนมัติได้เป็นส่วนใหญ่ ทั้งสองการตีความอยู่ในประกาศ มีเพียงหนึ่งเดียวเท่านั้นที่คุณสามารถทำซ้ำได้

Flint เปิดตัวเมื่อ 21 ตุลาคม 2026 ภายใต้สัญญาอนุญาต Apache 2.0 โดยมีน้ำหนักโมเดลอยู่บน Hugging Face ในชื่อ RecursiveSI/flint เป็นโมเดลแรกจาก Recursive ห้องปฏิบัติการที่ก่อตั้งโดย Richard Socher อดีตหัวหน้านักวิทยาศาสตร์ของ Salesforce และเพิ่งเปิดตัวเมื่อสี่วันก่อน — ใหม่พอที่แทบจะไม่มีอะไรเกี่ยวกับโมเดลนี้ได้รับการทดสอบภายนอกห้องแล็บที่สร้างมันขึ้นมา

สิ่งที่ Recursive ปล่อยออกมาจริง ๆ

มีสี่รีโพซิทอรี ไม่ใช่เพียงหนึ่ง รีโพซิทอรี checkpoint หลักเก็บน้ำหนัก BF16 การกำหนดค่า โทเคไนเซอร์ เทมเพลตแชต และชุดสำหรับให้บริการ SGLang และถูกสร้างเมื่อวันที่ 21 ตุลาคม 2026 เวลา 14:20 UTC มีบิลด์แบบควอนไทซ์สามรายการอยู่ข้างเคียง ซึ่งทั้งหมดลงเวลาในช่วงบ่ายวันเดียวกัน ได้แก่ บิลด์ int4 safetensors, int4 GGUF และ NVFP4 GGUF ขนาดด้านล่างมาจากรายการไฟล์ของรีโพซิทอรีเอง ไม่ใช่จากประกาศ

• ข้อมูลอ้างอิง BF16 — 79.59 GB ใน 37 ไฟล์ นี่คือไฟล์ที่คุณใช้หากมี H200 หรือ B300 และต้องการโมเดลแบบเต็มที่ไม่ถูกเจือจาง

• NVFP4 GGUF — 22.86 GB. นี่คือบิลด์ที่ทำให้คำกล่าวอ้างที่ว่า “รันบนแล็ปท็อปได้” กลายเป็นความจริงตามตัวอักษร และเป็นบิลด์ที่คนส่วนใหญ่จะดาวน์โหลดกันจริง

• int4 GGUF — 25.99 GB ซึ่งมีขนาดใหญ่กว่าไฟล์ NVFP4 แม้จะมีความกว้างบิตที่ใกล้เคียงกันตามที่ระบุไว้ หากคุณกำลังเลือกระหว่างสองตัวนี้โดยพิจารณาจากพื้นที่ดิสก์เพียงอย่างเดียว NVFP4 ชนะ

• int4 safetensors — 22.58 GB สำหรับสแตกที่ใช้ให้บริการซึ่งต้องการเช็กพอยต์ safetensors แทน GGUF

Recursive อ้างว่าการฝึกแบบ low-bit ของตัวเองและ output head แบบ 4-bit ซึ่งถูก distill กลับไปยังโมเดล 16-bit นั้นทำคะแนนได้ภายใน 0.7 คะแนนจากความแม่นยำเต็ม ตัวเลขนั้นเป็นของ Recursive ซึ่งวัดจากการประเมินของ Recursive แต่ขนาดไฟล์ไม่ใช่แบบนั้น — ใครก็อ่านมันได้จากรีโพซิทอรี

ตัวเลขทั้ง 4 ตัว และแต่ละตัววัดค่าอะไร

Recursive เผยแพร่ชุดคะแนนพร้อมกับการเปิดตัว และสิ่งสำคัญที่สุดที่ต้องเข้าใจเกี่ยวกับคะแนนเหล่านี้คือ คะแนนทั้งหมดถูกสร้างขึ้นภายในฮาร์เนสของ Recursive เอง ไม่มีบุคคลที่สามรายใดรันซ้ำเลย ดัชนี Artificial Analysis ซึ่ง normalmente ทำหน้าที่เป็นผู้ตัดสินอิสระสำหรับโมเดลแบบนี้ กลับไม่มีรายการของ Flint อยู่เลย

• SWE-bench Verified — 74.2% เป็นเบนช์มาร์กที่ผู้อ่านส่วนใหญ่จะรู้จัก โดยวัดว่าโมเดลสามารถแก้ไข issue จริงบน GitHub ได้หรือไม่ Recursive รันผ่าน mini-swe-agent โดยไม่มีการเข้าถึงอินเทอร์เน็ตเลย และเฉลี่ย pass@1 จากการลองอย่างน้อยห้าครั้ง ที่ temperature 1.0, top-p 0.95, top-k 20

• SWE-bench Pro v2 — 89.7% โปรดสังเกตคำว่า "v2" นี้ไม่ใช่ benchmark เดียวกับ SWE-bench Pro ที่ห้องปฏิบัติการอื่นเผยแพร่ และไม่สามารถนำตัวเลขทั้งสองมาลบกันได้ ความแตกต่างนี้สำคัญกว่าที่เห็น และจะเกิดขึ้นซ้ำทุกครั้งที่มีการนำ Flint ไปเปรียบเทียบกับโมเดลที่รายงานผลเป็น SWE-bench Pro แบบธรรมดา

• Terminal-Bench 2.1 — 54.9% ในกรณีนี้ Recursive ทำสิ่งที่ตรงไปตรงมาอย่างผิดปกติและกระอักกระอ่วนอย่างผิดปกติ: มันรัน Terminus 2 โดยเปิดใช้งานอินเทอร์เน็ต แล้วนับวิธีแก้ปัญหาใด ๆ ที่ได้มาจากการค้นคืนผ่านเว็บว่าเป็นความล้มเหลว ข้อจำกัดนั้นเป็นเจตนา และยังหมายความว่าคะแนนนี้ไม่สามารถนำไปเปรียบเทียบโดยตรงกับตัวเลข Terminal-Bench ที่ได้มาโดยไม่มีกฎนั้นได้

• LiveCodeBench v6 — 80.3% เป็น benchmark สำหรับการเขียนโปรแกรมเชิงแข่งขันมากกว่าที่จะเป็น benchmark แบบ agentic และด้วยเหตุนี้จึงเป็นตัวที่ไวต่อการเลือก harness น้อยที่สุดในบรรดาทั้งสี่ตัว

• IFBench — 89.2% การปฏิบัติตามคำสั่ง ซึ่งมักเป็นจุดแรกที่โมเดลขนาดเล็กเริ่มเสียเปรียบ

ข้อกล่าวอ้างที่ Recursive ระบุไว้จริงนั้นแคบกว่าที่การรายงานข่าวชวนให้เข้าใจ: Flint เป็นผู้นำในกลุ่มโมเดล mixture-of-experts ที่มีพารามิเตอร์รวมต่ำกว่า 5 หมื่นล้าน บน SWE-bench Pro v2, Terminal-Bench 2.1 และ SWE-bench Verified นั่นเป็นการอ้างอิงตามกลุ่มโมเดล ไม่ใช่การอ้างแบบสัมบูรณ์ โมเดลแบบ dense ที่มีขนาดใกล้เคียงถูกตัดออกจากขอบเขตนี้โดยผลของนิยามเอง ซึ่งเป็นเหตุผลพอดีว่าทำไม Qwen3.8 27B ซึ่งเป็นโมเดลแบบ dense จึงปรากฏอยู่ในแผนภูมิเดียวกันโดยทำคะแนนได้สูงกว่าบนค่าเฉลี่ยจากการทดสอบหกชุดของ Recursive เอง Recursive เผยแพร่ข้อมูลนั้นไว้ และสมควรได้รับเครดิตที่กล้าเปิดเผยมัน

ข้อกล่าวอ้างของ Eureka Machine คือส่วนที่อยู่ยืนยาวกว่าตัวโมเดล

ถ้าตัดการวัดประสิทธิภาพออกไป จะเหลือเรื่องราวที่แปลกกว่าปกติ Recursive กล่าวว่าระบบวิจัยอัตโนมัติของบริษัทสร้างแนวคิด ดำเนินการทดลอง และใช้ผลลัพธ์เพื่อเลือกว่าจะทำการทดลองใดต่อไป บริษัทให้เครดิตระบบนี้ว่ามีส่วนสนับสนุนด้านการฝึกก่อน การฝึกหลัง การอนุมาน การควอนไทซ์ และเคอร์เนลฮาร์ดแวร์ ผลงานสามรายการจากนั้นมีความเฉพาะเจาะจงพอที่จะตรวจสอบกับอาร์ติแฟกต์ได้:

• รูปร่างของโมเดล การออกแบบเริ่มจากฐาน 35B-A3B และลงเอยที่ 40B ทั้งหมด โดยมี 2.5B ที่ทำงานอยู่ นี่เป็นการเคลื่อนไหวโดยเจตนาไปสู่ความจุรวมที่มากขึ้นด้วยต้นทุนการเปิดใช้งานเท่าเดิม — เบาบางกว่า ไม่ใช่ใหญ่ขึ้นในแบบที่สำคัญต่อการอนุมาน

• การควอนไทซ์ การย้ายเฮดเอาต์พุตไปเป็น 4 บิต และการกลั่นความรู้ตัวเองกลับจากโมเดล 16 บิต คือสูตรที่อยู่เบื้องหลังคำกล่าวอ้าง 0.7 จุด และเป็นเหตุผลว่าทำไมโมเดล 39.8B จึงมีบิลด์ที่แจกจ่ายได้ขนาด 22.86 GB

• เคอร์เนล Recursive เขียน Metal เมกะเคอร์เนลที่มุ่งเป้าไปยังชิป M4 และ M5 ซึ่งเป็นรายการที่น่าแปลกใจน้อยที่สุดในรายการ เมื่อพิจารณาจากข้อกล่าวอ้างเรื่องทรูพุต และเป็นรายการที่เป็นรูปธรรมมากที่สุด

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

สี่วันของการทดสอบแบบลงมือปฏิบัติจริงบอกอะไรคุณได้ และบอกอะไรคุณไม่ได้

การมอง Flint จากภายนอกที่ครอบคลุมที่สุดจนถึงตอนนี้คือ Will Knight จาก Wired ซึ่งรันมันบน Mac ที่มีความจำ 48 GB และสร้างแอป to-do เครื่องมือค้นคว้าเว็บ และเว็บไซต์อธิบายขนาดเล็ก ทั้งสามอย่างทำงานได้ นั่นเป็นผลลัพธ์จริง และไม่ใช่เบนช์มาร์ก เป็นเพียงสามงาน เครื่องหนึ่งเครื่อง และคนหนึ่งคน

สัญญาณที่มีประโยชน์กว่าสำหรับใครก็ตามที่วางแผนจะใช้งานจริงมาจากนักรีวิวที่วัดทรูพุตเป็นเวลานานต่อเนื่อง แทนที่จะวัดแค่ช่วงเริ่มต้นเซสชัน การทดสอบอิสระรายหนึ่งรายงานว่าประมาณ 110 โทเค็นต่อวินาทีที่พรอมป์ตสั้น ๆ และลดลงเหลือราว 9 โทเค็นต่อวินาทีเมื่อบริบทประมาณ 115,000 โทเค็น นั่นคือการเสื่อมลงมากกว่าห้าเท่า และเป็นตัวเลขที่ควรใช้วางแผนหากเอเจนต์ของคุณอ่านรีโพซิทอรีขนาดใหญ่ก่อนที่จะเขียนอะไรลงไป ตัวเลขความเร็วพาดหัวของ Recursive — มากกว่า 125 โทเค็นต่อวินาทีบน M4 Pro และมากกว่า 150 บน RTX Spark 64 GB — ถูกวัดอย่างชัดเจนที่บริบทสั้น โดยไม่รวม prefill

นอกจากนี้ยังมีบั๊ก chat-template ที่เป็นที่รู้กันในเส้นทาง GGUF ของ llama.cpp หากคุณโหลดบิลด์แบบควอนไทซ์แล้วโมเดลมีพฤติกรรมเหมือนหลุดออกจากเรื่อง ให้ตรวจสอบเทมเพลตก่อนจะโทษน้ำหนักโมเดล

รันมันโดยไม่เอาเส้นทางโปรดักชันมาเสี่ยงกับมัน

Flint เป็นไฟล์สำหรับดาวน์โหลด ไม่ใช่ปลายทาง (endpoint) OrcaRouter ไม่ได้ให้บริการไฟล์นี้ และไม่ควรตีความข้อความใดในที่นี้ว่าเราให้บริการดังกล่าว

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

อีกเรื่องที่ควรรู้ก่อนดาวน์โหลด: Flint ใช้งานได้ฟรี แต่ไม่ได้ฟรีในแง่การเป็นเจ้าของ การดาวน์โหลดขนาด 22.86 GB เป็นเพียงค่าผ่านประตู และเครื่องที่รองรับมันได้อย่างสบาย ๆ ต่างหากคือต้นทุนจริง หากคุณกำลังเทียบราคากับโมเดลที่โฮสต์และคิดตามโทเคน ก็อย่าลืมคิดราค�าฮาร์ดแวร์ด้วย

สิ่งที่ควรจับตามองในเดือนหน้า

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

ประการแรกคือการรันเบนช์มาร์กที่เป็นอิสระ จนกว่า Artificial Analysis หรือบุคคลกลางที่เทียบเท่ากันจะให้คะแนน ทุกการเปรียบเทียบที่เกี่ยวข้องกับ Flint จะเป็นการเปรียบเทียบระหว่างการวัดตนเองของแล็บหนึ่งกับการวัดตนเองของอีกแล็บหนึ่ง ประการที่สองคือปัญหาทรุปพุตในบริบทขนาดยาวจะกลายเป็นอาร์ติแฟกต์ของ llama.cpp ปัญหาของเอนจิน หรือคุณสมบัติของโมเดล ซึ่งแต่ละอย่างมีวิธีแก้ที่ต่างกันมาก ประการที่สามคือจะประเมินการมีส่วนร่วมของ Eureka Machine ได้หรือไม่ Recursive กล่าวว่ากระบวนการนี้มีมนุษย์กำกับดูแล คำถามที่น่าสนใจคือสัดส่วนมนุษย์ต่อเอเจนต์เป็นเท่าใด และนั่นคือคำถามที่โพสต์เปิดตัวไม่ได้ออกแบบมาเพื่อตอบ

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