Recursive Flint 40B-A2.5B: โมเดลเขียนโค้ดที่สร้างมาเพื่อความเร็วเป็นอันดับแรก

ตัวเลขที่ตัดสินว่าRecursive Flint 40B-A2.5Bคุ้มค่ากับพื้นที่ดิสก์ของคุณหรือไม่ ไม่ใช่ 54.9% แต่คือ 2.5 โมเดลเขียนโค้ดแบบ open-weight ตัวแรกของ Recursive บรรจุพารามิเตอร์ 39.8 พันล้านตัว และจะปลุกให้ทำงานราว 2.5 พันล้านตัวในแต่ละโทเคนที่มันเขียน และแทบทุกการตัดสินใจอื่นในการเปิดตัวครั้งนี้ — การจัดวาง attention, สูตรการควอนไทซ์, เคอร์เนล Metal ที่เขียนขึ้นเอง, อินเฟอเรนซ์เอนจิน — ล้วนเป็นผลสืบเนื่องมาจากอัตราส่วนนั้นเพียงค่าเดียว Flint เปิดตัวเมื่อ21 ตุลาคม 2026ภายใต้สัญญาอนุญาต Apache 2.0 ซึ่งทำให้ตอนที่เขียนบทความนี้มันเพิ่งมีอายุได้หนึ่งวัน และยังอยู่ในช่วงที่การเปิดตัวยังถือเป็นข่าวมากกว่าประวัติศาสตร์ เนื่องจากตารางเบนช์มาร์กที่เพิ่งมีอายุหนึ่งวันเป็นเพียงคำสัญญามากกว่าการวัดจริง เราจึงแยกบันทึกการใช้งานจริงไว้อีกที่หนึ่ง: AI Incident Archiveบันทึกว่าคำกล่าวอ้างของโมเดลและผู้ให้บริการยังคงเป็นจริงแค่ไหนเมื่อต้องให้บริการกับทราฟฟิกจริงแล้ว

ฉบับสั้นสำหรับใครที่กำลังตัดสินใจอยู่ตอนนี้: มันเป็นโมเดลแบบ sparse mixture-of-experts ที่ถูกสร้างมาให้เป็นสิ่งที่เร็วที่สุดในกลุ่มขนาดเดียวกันเมื่อใช้บนแล็ปท็อป มันเปิดเผยคะแนน agentic coding สามรายการ ซึ่งทั้งหมดเป็นข้อมูลที่ผู้ขายรายงานเองและยังไม่มีการทำซ้ำ และมันเป็นโมเดลแรกจากบริษัทที่มีจุดมุ่งหมายระบุไว้ชัดเจนว่าจะทำงานวิจัยที่ใช้สร้างโมเดลให้เป็นอัตโนมัติ ข้อเท็จจริงทั้งสามข้อนี้ล้วนสำคัญ และข้อที่สามคือข้อที่จะยังน่าสนใจอยู่แม้ผ่านไปหนึ่งปี

สิ่งที่ส่งมอบจริง

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

• ข้อมูลอ้างอิง BF16 — 79.59GB ใน 37 ไฟล์ โดยแบ่งเป็น 15 shard ของ safetensors ขนาดประมาณ 5.37GB ต่อ shard นี่คืออาร์ติแฟกต์สำหรับ fine-tuning และเป็นตัวที่คุณไม่ต้องการดาวน์โหลดสำหรับการ inference

• NVFP4 GGUF — 22.86GB ในไฟล์เดียว เป็นบิลด์สำหรับการอนุมานที่สมบูรณ์และเล็กที่สุดที่เผยแพร่

• Int4 GGUF — 25.99GB เป็นการควอนไทซ์แบบ q4_1 ที่มีขนาดใหญ่กว่าไฟล์ NVFP4 ซึ่งย้อนกลับจากลำดับการตั้งชื่อ และควรรู้ไว้ก่อนเลือกตามชื่อไฟล์

• Int4 safetensors — 22.58GB สำหรับรันไทม์ที่ต้องการเวตแบบแบ่งชาร์ดมากกว่า GGUF ไฟล์เดียว

สัญญาอนุญาตคือ Apache 2.0 โดยการ์ดโมเดลได้เพิ่มความแตกต่างว่า ข้อกำหนดของ API ที่โฮสต์และการปฏิบัติด้านข้อมูลนั้นแยกจากสัญญาอนุญาตน้ำหนักโมเดล — เป็นการแยกแบบปกติที่ระบุไว้อย่างชัดเจนแทนที่จะซ่อนไว้

สถาปัตยกรรมนี้เป็นข้อโต้แย้งเกี่ยวกับแบนด์วิดท์ของหน่วยความจำ

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

• ความเบาบาง (sparsity) — ผู้เชี่ยวชาญแบบ routed จำนวน 256 คนต่อชั้น MoE โดยเลือก 6 คนต่อ token พร้อมผู้เชี่ยวชาญแบบ shared ที่ทำงานตลอดเวลาอีกหนึ่งคน จากทั้งหมด 49 ชั้น มี 2 ชั้นที่เป็นแบบ dense และ 47 ชั้นเป็น MoE ดังนั้นทุกชั้นยกเว้นสองชั้นแรกจึงทำงานแบบมีเงื่อนไข

• พารามิเตอร์ที่ใช้งานอยู่ — รวมทั้งหมด 39.8B โดยมีพารามิเตอร์ที่ใช้งานประมาณ 2.5B ต่อโทเค็นเมื่อนับรวม output head ซึ่งเป็นที่มาของชื่อ "40B-A2.5B" ส่วนเฉพาะตัวหลักที่ใช้งานอยู่มีประมาณ 2.2B

• Attention — เลเยอร์ sliding-window จำนวน 35 ชั้นที่หน้าต่างขนาด 513 โทเคน (โทเคนปัจจุบันบวกกับ 512 โทเคนก่อนหน้า) สลับกับเลเยอร์ full-attention จำนวน 14 ชั้น มีเพียง 32 query head และ 4 key-value head ที่มิติ head เท่ากับ 128 ดังนั้น KV cache จึงยังเล็กพอที่จะทำให้เซสชันของเอเจนต์ที่ยาวนานใช้งานได้จริง

• การเข้ารหัสตำแหน่ง — ใช้ rotary embeddings ในเลเยอร์แบบ sliding-window และไม่ใช้เลยในเลเยอร์แบบ full-attention ซึ่งเป็นการเลือกที่การ์ดโมเดลระบุไว้โดยไม่มีการอธิบาย QK RMSNorm ต่อหัวและ attention sinks ต่อหัวแบบเรียนรู้ได้กำลังรับหน้าที่รักษาเสถียรภาพซึ่งปกติแล้วการเข้ารหัสตำแหน่งมีส่วนช่วยแบกรับไว้

• บริบท — มีการระบุไว้ 262,144 โทเค็น และ model card ระบุชัดเจนว่าจำนวนนี้ครอบคลุมทั้งพรอมป์ต์และเอาต์พุตที่สร้างขึ้นรวมกัน ประกาศโฆษณาว่า "สูงสุด 512k" แล้วแนะนำให้อยู่ในช่วงไม่เกิน 256k สำหรับการเขียนโค้ด ทั้งสองข้อความมาจากผู้จำหน่ายรายเดียวกัน ห่างกันเพียงหนึ่งย่อหน้า

รายละเอียดที่น่าสนใจคือรูปร่างถูกเลือกอย่างไร Recursive กล่าวว่า Eureka Machine ของตน — วงจรการวิจัยอัตโนมัติที่เสนอไอเดีย นำไปใช้งาน ทดสอบ และรวมสิ่งที่ได้ผล — เริ่มจากฐานขนาด 35,000 ล้านพารามิเตอร์ที่มี 3,000 ล้านพารามิเตอร์ที่ใช้งานอยู่ และค้นหาทั่วการกำหนดค่าของผู้เชี่ยวชาญและความกว้าง การกำหนดค่า 40B/2.5B ที่เป็นผลลัพธ์นั้น ตามถ้อยคำในประกาศเอง คือ “คาดว่าจะให้การผสมผสานที่ดีที่สุดของความเร็วและประสิทธิภาพการเขียนโค้ดในบรรดาการกำหนดค่าที่ Eureka Machine ของเราทดสอบ” คาดการณ์ ไม่ได้พิสูจน์ด้วยการแข่งแบบ bake-off ของโมเดลที่เสร็จสมบูรณ์ นั่นเป็นวิธีปกติในการเลือกสถาปัตยกรรมเมื่อการฝึกมีค่าใช้จ่ายสูง และยังเป็นการอ้างสิทธิ์ที่เช็กพอยต์ในภายหลังอาจขัดแย้งอย่างเงียบ ๆ

คะแนนทั้งสาม และเชิงอรรถที่เกี่ยวข้อง

Flint ได้คะแนน 54.9% ใน Terminal-Bench 2.1, 89.7% ใน SWE-bench Pro v2 และ 74.2% ใน SWE-bench Verified ตัวเลขเหล่านี้ปรากฏอยู่ใน model card ในฐานะการประเมินตอนเปิดตัว และยังไม่มีบุคคลที่สามรายใดเผยแพร่ผลการวัดของโมเดลนี้ — ดัชนีโมเดล Artificial Analysis ซึ่งปกติทำหน้าที่เป็นผู้ตัดสินอิสระสำหรับการเปิดตัวลักษณะนี้ ยังไม่มีรายการ Flint เลย ณ วันที่ 22 ตุลาคม ดังนั้นทุกอย่างด้านล่างนี้คือ Recursive วัด Recursive เอง

สิ่งที่ผู้ขายเปิดเผยเกี่ยวกับวิธีการของตนเองนั้นมากกว่าที่โพสต์เปิดตัวส่วนใหญ่ยอมเปิดเผย และมันเปลี่ยนวิธีที่ควรอ่านตัวเลขเหล่านั้น:

• Terminal-Bench 2.1 — รันด้วยฮาร์เนส Terminus 2 โดยเปิดการเข้าถึงอินเทอร์เน็ต และโซลูชันที่ได้มาจากการค้นคืนผ่านเว็บจะถูกนับเป็นความล้มเหลว การปรับครั้งล่าสุดนี้เป็นอุปสรรคที่ตั้งใจไว้ และการ์ดโมเดลระบุว่าคะแนนที่เผยแพร่โดยนักพัฒนารายอื่นอาจไม่ได้ใช้การปรับนี้ ซึ่งทำให้การเปรียบเทียบแบบเท่าเทียมกับตัวเลขของบุคคลที่สามยากขึ้นแทนที่จะง่ายขึ้น

• SWE-bench Pro v2 และ SWE-bench Verified — รันด้วย mini-swe-agent และไม่มีการเข้าถึงอินเทอร์เน็ตเลย ซึ่งเป็นเงื่อนไขที่ยากกว่าสำหรับเอเจนต์ที่สามารถค้นหาเอกสารระหว่างทำงานได้

• จำนวนครั้งที่ลองและเวลาหมดเวลา — ค่าเฉลี่ย pass@1 จากอย่างน้อยห้าครั้ง โดยมีเวลาหมดเวลาของเอเจนต์สูงสุดถึงห้าชั่วโมง การเฉลี่ยจากการลองห้าครั้งถือเป็นโปรโตคอลที่สมเหตุสมผล; เวลาหมดเวลาห้าชั่วโมงหมายความว่าคะแนนเหล่านี้เป็นของเอเจนต์ที่คุณยินดีปล่อยให้ทำงานต่อไป ไม่ใช่สำหรับ autocomplete

• การสุ่มตัวอย่าง — temperature 1.0, top-p 0.95, top-k 20 ในการประเมินทุกครั้ง และชุดให้บริการจะใช้ค่าเริ่มต้นเหล่านี้เมื่อคำขอไม่ได้ระบุค่าเหล่านี้ไว้

ตาราง benchmark ของผู้จำหน่ายยังบอกบางอย่างเกี่ยวกับคู่เทียบที่เลือกมาด้วย แผนภูมิของ Recursive เองเปรียบเทียบ Flint กับ Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer และ Gemma 4 — โมเดลโลคัลที่ใช้งานได้กับฮาร์ดแวร์ระดับใกล้เคียงกัน ซึ่งเป็นกลุ่มคู่เทียบที่ตรงไปตรงมาสำหรับโมเดลระดับแล็ปท็อป และยังเป็นกลุ่มที่ถูกคัดเลือกมาเพื่อทำให้ข้อโต้แย้งเรื่อง sparsity ดูดี ข้อกล่าวอ้างที่นำเสนอมีขอบเขตแคบและป้องกันได้: Flint นำหน้าโมเดล MoE ที่มีพารามิเตอร์รวมต่ำกว่า 50 พันล้านในงานเขียนโค้ดแบบ agentic และเทียบชั้นได้กับโมเดล dense ขนาด 25 ถึง 40 พันล้าน ขณะที่ทำงานได้เร็วกว่ามาก นี่ไม่ใช่ข้อกล่าวอ้างเกี่ยวกับโมเดลเขียนโค้ดระดับ frontier และ Recursive ก็ไม่ได้กล่าวอ้างเช่นนั้น — ประกาศระบุตรง ๆ ว่า Flint “อาจต้องได้รับคำแนะนำมากกว่าโมเดลเขียนโค้ด closed-source ขนาดใหญ่ที่คุณคุ้นเคย”

ความเร็ว: จริง ๆ แล้ว 2× วัดเทียบกับอะไร

Recursive รายงานว่าทำได้มากกว่า 125 โทเคนต่อวินาทีบน M4 Pro MacBook Pro และมากกว่า 150 โทเคนต่อวินาทีบน NVIDIA RTX Spark ขนาด 64GB ที่บริบทสั้น โดยอธิบายว่าสูงถึงสองเท่าของโมเดลที่เทียบเคียงได้ และเร็วกว่าโมเดลแบบ dense ขนาด 25 ถึง 40 พันล้านพารามิเตอร์ที่มีคะแนนการเขียนโค้ดใกล้เคียงกันมากกว่าห้าเท่า บันทึกเชิงวิธีวิทยาในแผนภูมิความเร็วคือส่วนที่ควรอ่าน: ค่าเฉลี่ยโทเคนต่อวินาทีตลอดเซสชัน 128,000 โทเคน โดยไม่นับ prefill และมีคู่แข่งรายหนึ่งถูกวัดที่ 124k แทนที่จะเป็นความยาวเต็ม

การไม่นับ prefill เป็นแนวปฏิบัติมาตรฐานสำหรับการวัดประสิทธิภาพการ decode และยังสำคัญในบริบทนี้ เพราะ prefill คือช่วงที่ coding agent ใช้เวลาเต็มที่เมื่อมันทุ่มทั้ง repository ลงใน context window ตัวเลขที่วัดเพียงครึ่งเดียวที่เป็น decode ของเซสชัน 128k จะทำให้โมเดลใดก็ตามที่มี sparse activation ดูดีเกินจริง และการออกแบบทั้งหมดของ Flint ก็คือ sparse activation ทั้งหมดนั้นไม่ได้ทำให้ตัวเลขผิดแต่อย่างใด มันทำให้ตัวเลขนั้นเป็นตัวเลข decode และควรนำไปเปรียบเทียบกับตัวเลข decode อื่น ๆ มากกว่าจะเปรียบเทียบกับเวลาที่ agent ของคุณใช้จนทำงานเสร็จ

สูตรการควอนไทซ์เป็นส่วนที่ถ่ายทอดได้มากที่สุด

บทความเกี่ยวกับควอนไทเซชันส่วนใหญ่มักพูดถึงว่าความแม่นยำสูญเสียไปมากแค่ไหน แต่บทความนี้พูดถึงการตัดสินใจที่สวนทางกับแนวปฏิบัติทั่วไป

Recursive ทำการควอนไทซ์เลเยอร์เอาต์พุต — คือ lm_head — ให้เหลือ 4 บิต ซึ่งขัดกับแนวปฏิบัติทั่วไป และเหตุผลนั้นจำเพาะกับโมเดลแบบสแาร์ส: เมื่อมีพารามิเตอร์ที่ใช้งานอยู่เพียง 2.5 พันล้านตัว เลเยอร์เอาต์พุตจึงเป็นสัดส่วนใหญ่ของน้ำหนักที่ถูกอ่านสำหรับทุกโทเคน ดังนั้นการคงไว้ที่ 16 บิตจะจำกัดความเร็วสูงสุดที่โมเดลทำได้ การกู้คืนความแม่นยำต้องอาศัยขั้นตอนการกลั่นแบบออฟไลน์ ซึ่งโมเดลที่ถูกควอนไทซ์จะฝึกกับresponses ที่ถูกสุ่มตัวอย่างไว้ล่วงหน้าของตัวเองจาก coreset ที่มันค้นพบเอง โดยมีโมเดล 16 บิตเป็นครู — การตั้งค่าที่ Recursive กล่าวว่าเกือบลดจำนวนขั้นตอนการฝึกลงครึ่งหนึ่งเมื่อเทียบกับ baseline การฝึกแบบคำนึงถึงการควอนไทซ์ของตน

ผลลัพธ์ที่เผยแพร่คือโมเดล NVFP4 ขั้นสุดท้ายมีคะแนนต่างจากโมเดล 16-bit ไม่เกิน 0.7 คะแนนในชุดการทดสอบทั้งหมด นี่เป็นคำกล่าวอ้างของผู้จำหน่าย และเป็นคำกล่าวอ้างประเภทที่ตรวจสอบย้อนหลังได้ง่ายแต่มีต้นทุนสูงหากจะปลอมแปลง จึงเป็นคำกล่าวอ้างที่มีประโยชน์ในการใช้ตรวจสอบให้พวกเขารับผิดชอบตามนั้น ผลที่ตามมาในทางปฏิบัติคือขนาดไฟล์ข้างต้น: ไฟล์ดาวน์โหลดขนาด 22.86GB ที่รันโมเดล 39.8 พันล้านพารามิเตอร์บนเครื่องที่มีหน่วยความจำแบบรวม 48GB

บน Apple Silicon ยังมีอีกชั้นหนึ่ง Eureka Machine ของ Recursive ได้สร้างเคอร์เนลเฉพาะทางสำหรับการฉายภาพแบบบิตต่ำ การดำเนินการ MoE แอตเทนชัน และการประมวลผลพรอมต์ รวมถึงเมกะเคอร์เนล Metal ที่หลอมรวม forward pass ของการถอดรหัสทั้งหมดให้เป็นการ dispatch ครั้งเดียวบนชิป M4 และ M5 การหลอมรวมรอบการถอดรหัสเป็นรูปแบบการปรับแต่งที่ให้ผลตอบแทนก็ต่อเมื่อคุณควบคุมสถาปัตยกรรมโมเดล รูปแบบการควอนไทซ์ และเคอร์เนลไปพร้อมกัน ซึ่งนั่นคือข้อเสนอหลักที่แท้จริงของการเปิดตัวนี้ มากกว่าตัวเลข benchmark ใด ๆ

คุณรันมันอย่างไร และแต่ละเส้นทางต้องแลกมาด้วยอะไร

มีเรื่องราวการติดตั้งใช้งานที่แตกต่างกันสองแบบ และทั้งสองแบบไม่อาจใช้แทนกันได้

• GPU สำหรับเซิร์ฟเวอร์ — เช็กพอยต์ BF16 มาพร้อมชุดให้บริการของ SGLang ซึ่งกำหนดเป้าหมายเป็น B300 หนึ่งตัวหรือ H200 หนึ่งตัวต่อรีพลิกา เปิดเอนด์พอยต์ที่เข้ากันได้กับ OpenAI บนพอร์ต 30000 โดยใช้ชื่อโมเดล flint และมีไคลเอนต์ตัวอย่างสำหรับการให้เหตุผลและการเรียกใช้เครื่องมือ นี่เป็นเส้นทางเดียวที่รองรับสำหรับน้ำหนักแบบความแม่นยำเต็ม โดยบัตรโมเดลระบุไว้อย่างชัดเจนว่ายังไม่มีการรวมโค้ดสำหรับการสร้างโมเดลแบบ Transformers

• เครื่องโลคอล — llama.cpp, Ollama, Unsloth, LM Studio, vLLM และ SGLang ถูกระบุว่าฮองรับทั้งหมด ซึ่งถือว่ากว้างอย่างผิดปกติสำหรับโมเดลวันเปิดตัว และเป็นความแตกต่างระหว่างเช็กพอยต์กับอาร์ติแฟกต์ที่ใช้งานได้จริง

• rec เอนจิน — เอนจินอนุมานของ Recursive เอง ติดตั้งไว้ที่ ~/.local/bin ต้องใช้ M4 Pro, M5 Pro หรือ M5 Max ที่มีหน่วยความจำรวมอย่างน้อย 48GB และพื้นที่ดิสก์ว่างประมาณ 30GB และให้บริการ API ที่เข้ากันได้กับ OpenAI ภายในเครื่อง README ของมันอ้างว่ามีอัตราทรูพุตโทเคนเป็น 1.4× ถึง 2.6× ของ llama.cpp บน M4 Pro ที่ใช้น้ำหนัก 4 บิต ครอบคลุมพรอมต์ขนาด 1,000 ถึง 252,000 โทเคน โดยมีโทเคนเอาต์พุต 1,024 โทเคน วัดห้ารอบต่อความยาวบริบท ไม่รวมพรีฟิลล์ ถูกปรับแต่งมาโดยเฉพาะสำหรับการใช้งานแบบเซสชันเดียว — หากเรียกใช้เอเจนต์หลายตัวพร้อมกัน เอกสารจะแนะนำให้ไปใช้ที่อื่น

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

สิ่งใดที่ยังไม่ได้รับการพิสูจน์อย่างแท้จริง

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

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

ประการที่สองคือ โมเดลที่มีพารามิเตอร์ที่ใช้งานอยู่ 2.5 พันล้านตัวจะรับมือกับงานระยะยาวซึ่งเป็นจุดประสงค์จริง ๆ ของเอเจนต์เขียนโค้ดได้หรือไม่ โปรโตคอลการทดสอบมาตรฐานอนุญาตให้ลองได้ห้าครั้งและตั้งเวลาหมดได้ห้าชั่วโมง ซึ่งเป็นกรอบที่กว้างมาก โมเดลที่ต้องลองหลายครั้งและต้องปล่อยยาวจึงอาจทำคะแนน pass@1 ออกมาได้ดี แต่กลับให้ความรู้สึกว่าไม่น่าเชื่อถือเมื่อใช้ในเอดิเตอร์ ข้อแม้ของ Recursive เองที่ว่าต้องได้รับคำแนะนำมากกว่าโมเดลปิดขนาดใหญ่กว่า ก็ชี้ไปที่เรื่องเดียวกัน

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

สิ่งนี้จะเข้ากับตรงไหนหากสแตกเอเจนต์ของคุณเป็นแบบโลคอลเพียงครึ่งเดียว

เหตุผลที่โมเดลอย่าง Flint สำคัญก็คือมันตัดออกเพียงหนึ่งบรรทัดจากบิล ไม่ใช่ทั้งหมด การประมวลผลในเครื่องจัดการงานที่คุณรันบนเครื่องของตัวเองได้ และไม่ได้ช่วยอะไรกับงานที่คุณทำไม่ได้ — งานบริบท längd ที่ไม่พอดี งานที่พุ่งเกินกำลังแล็ปท็อปเครื่องเดียว งานที่โมเดลใหญ่กว่าดีกว่าอย่างชัดเจน สิ่งนี้ทำให้ทีมส่วนใหญ่ต้องรันสองระบบ

OrcaRouter คือส่วนที่โฮสต์ของรูปแบบนั้น และเพื่อให้ชัดเจนเกี่ยวกับขอบเขต: เราไม่ได้ให้บริการ Flint และไม่มีส่วนใดในบทความนี้ที่เป็นการโน้มน้าวให้ใช้เช็กพอยต์ที่เราโฮสต์ Flint เป็นไฟล์ดาวน์โหลดจาก Recursive ไม่ใช่เอนด์พอยต์ของเรา สิ่งที่เราทำคือวาง API หนึ่งตัวไว้หน้าโมเดลที่โฮสต์กว่า 200 โมเดลในราคาตามรายการของผู้ให้บริการเอง โดยไม่มีการบวกกำไร และกำหนดเส้นทางข้ามโมเดลเหล่านั้นด้วยเชนสำรองที่อิงตามการกำหนดค่า และสลับไปใช้ระบบสำรองโดยอัตโนมัติ เมื่อผู้ให้บริการมีปัญหาในระหว่างการประมวลผลคำขอ หากคุณต้องการเปรียบเทียบว่าการรัน Flint ในเครื่องคุ้มค่าแค่ไหนเมื่อเทียบกับโมเดล mixture-of-experts แบบโฮสต์ที่มีขนาดใกล้เคียงกัน — Qwen3.6-35B-A3B และ Gemma 4 26B-A4B ต่างเรียกใช้ได้ผ่านคีย์เดียวนั้น — การเปรียบเทียบต้องใช้คำขอหนึ่งครั้งแทนการดีพลอย

การตีความที่สมเหตุสมผล

Flint เป็นรีลีสจริงที่มีจุดศูนย์ถ่วงเฉพาะและไม่ธรรมดา Recursive ไม่ได้ปล่อยโมเดลเขียนโค้ดที่แข็งแกร่งที่สุดเท่าที่จะทำได้ แต่ปล่อยโมเดลที่เร็วที่สุดเท่าที่สร้างได้ในขนาดที่ใส่แล็ปท็อปได้ แล้วเผยแพร่สแตกการควอนไทซ์และเคอร์เนลที่ออกแบบมาเพื่อให้ข้อได้เปรียบนั้นคงอยู่เมื่อต้องทำงานกับน้ำหนัก 4 บิต ตัวเลข 54.9% บน Terminal-Bench 2.1 และ 89.7% บน SWE-bench Pro v2 เป็นตัวเลขที่แข็งแกร่งสำหรับโมเดลแบบ sparse ขนาด 4 หมื่นล้านพารามิเตอร์ และในตอนนี้เป็นตัวเลขจากผู้ขายเพียงลำพัง

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

หากคุณมีหน่วยความจำแบบรวม 48GB และเครื่อง Apple Silicon ค่าใช้จ่ายในการหาคำตอบก็คือการดาวน์โหลด 22.86GB และใช้เวลาหนึ่งบ่าย หากคุณไม่มี จุดยืนที่ซื่อสัตย์คือการรอการประเมินอิสระครั้งแรก เพราะตาราง benchmark ที่มีอายุเพียงหนึ่งวันเป็นเพียงคำสัญญา ไม่ใช่ผลการวัด