LFM3 หลุด: ตระกูลถัดไปของ Liquid AI คือโมเดล Omni ขนาดเล็กสี่รุ่น

pull request ที่เปิดบน GitHub เมื่อวันที่ 27 ตุลาคม 2026 ต้องการสอน SGLang ให้รู้วิธีให้บริการตระกูลโมเดลที่ยังไม่มีอยู่ต่อสาธารณะ โดยระบุชื่อ checkpoint สี่รายการ — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B และ LFM3-Omni-2B — และเมื่ออ่านเทียบกับ LFM2.5-2.6B และ LFM2.5-24B-A2B ที่เปิดตัวแล้ว ก็ดูราวกับพิมพ์เขียวสำหรับสิ่งที่ Liquid AI จะสร้างต่อไป PR นี้ยังไม่ถูก merge การตรวจ CI ทั้งสามรายการของมันล้มเหลวทั้งหมด Liquid AI ยังไม่ได้ประกาศสิ่งใดเกี่ยวกับเรื่องนี้ diff ที่ยังไม่ถูก merge นี้คือบันทึกสาธารณะทั้งหมดของ LFM3 ณ วันนี้ และให้ข้อมูลได้มากกว่าโพสต์เปิดตัวส่วนใหญ่ — หากคุณอ่านมันอย่างที่มันเป็น

ดังนั้นขอให้เราพูดถึงหลักฐานอย่างแม่นยำ เพราะหลักฐานมีน้อยในแง่หนึ่ง แต่กลับละเอียดผิดปกติในอีกแง่หนึ่ง ไม่มีสิ่งใดในนี้ที่เป็นวันวางจำหน่าย ราคา เงื่อนไขสัญญาอนุญาต หรือคะแนนจากเบนช์มาร์ก ไม่มีโมเดลการ์ดของ LFM3 ไม่มีรีโพซิทอรีบน Hugging Face ไม่มีโพสต์บล็อก ไม่มีรายการ API สิ่งที่มียู่คือผลงานจาก tugot17 — Piotr Mazurek ซึ่งในช่วงสองเดือนที่ผ่านมาได้นำการรองรับรันไทม์ของ LFM ไปลงใน SGLang, llama.cpp และ mlx-vlm — บวกกับเนื้อหาที่ Liquid เองเผยแพร่เกี่ยวกับเจเนอเรชัน LFM2.5 ที่กำลังจะถูกแทนที่ ทุกสิ่งด้านล่างนี้ถูกติดป้ายกำกับตามความเหมาะสม

สิ่งที่ pull request นี้วางไว้บนโต๊ะจริง ๆ

ชื่อ PR คือ [Feat] lfm3: เพิ่มการรองรับข้อความ ภาพ เสียง และ Omni และมีป้ายกำกับสองป้ายที่บอกว่าการเปลี่ยนแปลงนี้เป็นประเภทใด: jit-kernel และ Multi-modal โดยเพิ่มการสร้างข้อความแบบเนทีฟสำหรับตระกูลที่มีสี่รุ่น แต่ละรุ่นมีเส้นทางเช็กพอยต์ของตัวเอง:

• LFM3-1.7B — ข้อความเข้า ข้อความออก โมเดลภาษาธรรมดาที่เป็นรากฐานของตระกูล

• LFM3-VL-2B — อินพุตเป็นข้อความ รูปภาพ และวิดีโอ เอาต์พุตเป็นข้อความ

• LFM3-Audio-2B — รับข้อความและเสียงเป็นอินพุต ส่งออกเป็นข้อความ และยังเชื่อมต่อกับ endpoint /v1/audio/transcriptions อีกด้วย

• LFM3-Omni-2B — รับข้อความ รูปภาพ เสียง และวิดีโอเป็นอินพุต รวมถึงแทร็กเสียงของวิดีโอเอง และส่งออกเป็นข้อความ

มีรายละเอียดหนึ่งในรายการนั้นที่ควรหยุดคิดสักหน่อย ทุกตัวแปรให้เอาต์พุตเป็นข้อความ ไม่มีเส้นทางเสียงออกที่ใดเลยใน PR และความสามารถที่ไม่ใช่แชตของโมเดลเสียงคือการถอดความ — เสียงเข้า ข้อความออก ซึ่งแคบกว่าสายผลิตภัณฑ์เสียงปัจจุบันของ Liquid ที่ LFM2.5-Audio-1.5B มีเอกสารระบุว่ารองรับ ASR, TTS และการสนทนาด้วยเสียงแบบสลับไปมาในโมเดลเดียว อาจเป็นได้ว่าเวอร์ชัน SGLang แรกครอบคลุมเพียงครึ่งที่สร้างข้อความของ LFM3-Audio หรือไม่ก็ตระกูล omni ตัดการสังเคราะห์เสียงออกจริง ๆ PR ไม่สามารถสรุปได้ว่าเป็นอย่างไหน และใครที่บอกว่าสรุปได้ก็แค่เดา ให้ถือว่า “LFM3 speaks” ยังไม่ได้รับการพิสูจน์

ส่วนที่เหลือของ diff เป็นรายละเอียดการนำไปใช้งานซึ่งถึงกระนั้นก็บ่งบอกช่วงเวลาของงานนี้ เอนโคเดอร์ภาพและเสียงพร้อมโปรเจกเตอร์ของตน แบ็กโบนที่ใช้ร่วมกัน การผสานรวมแคชแบบไฮบริด เคอร์เนลคอนโวลูชัน CuTe DSL ที่มี PyTorch เป็นทางเลือกสำรอง และหมายเหตุว่า FlashInfer ใช้เพจพรีฟิลเป็นค่าเริ่มต้นเพื่อให้แอตเทนชันแบบหน้าต่างเลื่อนทำงานได้ตามที่ควร การตรวจสอบความถูกต้องรันบน H100s ใน FP16 โดยใช้สิ่งที่คำอธิบายเรียกว่า เช็กพอยต์สำหรับการพัฒนา — สี่คำที่สำคัญในภายหลัง

ประโยคเกี่ยวกับสถาปัตยกรรม และตัวเลขที่ผู้คนจะอ่านผิด

PR อธิบายว่า LFM3 เป็นแกนหลักร่วมของคอนโวลูชันสั้นแบบมีเกตพร้อม attention แบบเต็มและแบบหน้าต่างเลื่อน นั่นคือสายตระกูล LFM2 ที่สืบทอดต่อมา ไม่ใช่การแทนที่ โดยมีเอกสารระบุว่า LFM2.5-24B-A2B เป็นลูกผสมของคอนโวลูชันสั้นแบบมีเกตและ attention แบบ grouped-query ตลอด 40 เลเยอร์ สิ่งที่ดูเหมือนใหม่ในข้อมูลที่รั่วไหลคือองค์ประกอบหน้าต่างเลื่อนที่ระบุไว้อย่างชัดเจนซึ่งอยู่เคียงข้าง attention แบบเต็ม

บันทึกการตรวจสอบกล่าวถึงพรอมต์ที่ทำงานเกินหน้าต่างเลื่อนขนาด 256 โทเคน และนี่คือตัวเลขที่จะถูกยกไปอ้างแบบหลุดบริบทตลอดทั้งสัปดาห์ มันไม่ใช่ความยาวบริบทของ LFM3 ในการออกแบบแบบไฮบริด เลเยอร์แอตเทนชันจำเป็นต้องมองเฉพาะในท้องถิ่น เพราะเลเยอร์คอนโวลูชันแบกรับสัญญาณระยะไกล นั่นคือสมมติฐานหลักทั้งหมดของสถาปัตยกรรม และเป็นเหตุผลที่ตระกูลนี้รองรับบริบทได้ 131,072 โทเคนบน LFM2.5-24B-A2B ในขณะที่เลเยอร์ส่วนใหญ่ไม่ได้ทำแอตเทนชันแบบกำลังสองเลย หน้าต่างแอตเทนชันขนาด 256 โทเคนเป็นข้อความเกี่ยวกับว่ามอดัลมองที่ใดภายในเลเยอร์เดียว ไม่ใช่ปริมาณข้อความที่รับได้ PR ไม่ได้ระบุบริบททั้งหมดของ LFM3 และยังไม่มีใครนอก Liquid ที่รู้

ทำไม pull request ใน runtime จึงเป็นสัญญาณ ไม่ใช่เสียงรบกวน

การตั้งข้อสงสัยต่อการอนุมานกลยุทธ์ผลิตภัณฑ์จาก diff ของโครงสร้างพื้นฐานนั้นเป็นเรื่องสมเหตุสมผล ในกรณีเฉพาะนี้ รูปแบบมีความสม่ำเสมอเกินกว่าจะมองข้ามได้ เพราะ Liquid ส่งมอบการรองรับเอนจินพร้อมน้ำหนักโมเดล แทนที่จะตามมาทีหลัง LFM2.5-2.6B ระบุ llama.cpp, MLX, vLLM, SGLang, ONNX และ Transformers 5.0+ เป็นเป้าหมายตั้งแต่วันแรก LFM2.5-24B-A2B ได้รับการรองรับใน llama.cpp, MLX, vLLM, SGLang และ ONNX ตั้งแต่เปิดตัว ตระกูลโมเดลที่มาพร้อมรันไทม์ที่พร้อมใช้ห้ารายการจะต้องมีการเขียนเคอร์เนลก่อนการประกาศ ซึ่งหมายความว่า PR ถูก merge ก่อน แล้วบล็อกโพสต์จึงตามมา

ผู้เขียนสอดคล้องกับลำดับเวลานั้นพอดี ประวัติสาธารณะของ Mazurek คือชุดงานผสานรวม LFM ต่อเนื่องกัน: การถอดรหัสเชิงคาดเดา DSpark สำหรับ LFM2-VL ใน SGLang เมื่อเดือนกันยายน, การแก้ไข draft-model ของ LFM2.5-VL-3B และ DSpark ใน llama.cpp ในเดือนเดียวกัน, การถอดรหัสเชิงคาดเดาที่สืบทอดมาจากโมเดลข้อความใน mlx-vlm และการใช้คอนฟิกูเรชัน LFM2-MoE ซ้ำใน SGLang เมื่อวันที่ 13 ตุลาคม LFM3 คือรายการถัดไปในลำดับดังกล่าว ซึ่งถูกยื่นในสุดสัปดาห์ที่ตระกูลโมเดลนี้เปลี่ยนชื่อ

การไม่มีอยู่สองอย่างบอกอะไรได้พอๆ กับการมีอยู่ ไม่มี pull request ที่ตรงกันใน Hugging Face Transformers สำหรับ LFM3 — การค้นหาในที่เก็บนั้นไม่ให้ผลลัพธ์ใดเลย — และ PR ของ SGLang โหลดเช็กพอยต์ผ่าน Transformers 5.19.0 แบบมาตรฐานด้วย --trust-remote-code ซึ่งเป็นสิ่งที่คุณทำเมื่อสถาปัตยกรรมยังไม่เป็นเนทีฟของไลบรารี ยังมีคอมมิตที่ปฏิเสธ speculative decoding สำหรับ LFM3 อย่างชัดเจน ดังนั้นงาน DSpark ที่ส่งมอบสำหรับรุ่น 2.5 จึงยังไม่ถูกนำต่อ ยังเร็ว และไม่สมบูรณ์โดยเจตนา

คำถามเรื่องขนาดที่ไม่มีใครตอบ

ในจุดนี้ การรั่วไหลและความทะเยอทะยานที่ระบุไว้ต่างดึงไปในทิศทางที่ตรงกันข้าม และความตึงเครียดนี้คือสิ่งที่น่าสนใจที่สุดในเอกสาร

Maxime Labonne หัวหน้าฝ่าย Pretraining ของ Liquid อธิบายเป้าหมายของ LFM3 ว่าเป็นการทดสอบว่าแนวทาง short-convolution ที่ได้ผลในระดับ 350M ถึง 1.2B พารามิเตอร์จะยังคงทำได้ดีเมื่อเกิน 10B พารามิเตอร์หรือไม่ — ช่วงที่สถาปัตยกรรมแบบ attention ได้เปรียบมาโดยตลอด นั่นเป็นคำถามด้านการขยายขนาด และบ่งชี้ถึงโมเดลขนาดใหญ่

เช็กพอยต์ที่รั่วไหลมีขนาด 1.7B หนึ่งตัว และ 2B สามตัว ไม่มีตัวใดเลยที่สูงกว่าเกณฑ์ที่คำถามนั้นกล่าวถึง

ยังมีคำอธิบายที่เป็นไปได้สองแบบ แบบแรกคือสิ่งเหล่านี้คือกลุ่มแรกที่กะทัดรัด — ตระกูล omni สำหรับโทรศัพท์และรถยนต์ ก่อนที่รุ่นพี่ขนาดใหญ่จะมาถึง ซึ่งสอดคล้องกับวิธีที่ Liquid นำด้วยโมเดลเล็กมาโดยตลอด และวิธีที่ PR อธิบายสิ่งเหล่านี้ว่าเป็น checkpoint สำหรับการพัฒนา ไม่ใช่รุ่นวางจำหน่ายสุดท้าย แบบที่สองคือ 1.7B และ 2B เป็นเพียงขนาดที่สะดวกในการตรวจสอบ kernel เทียบกับ และไม่ได้บอกอะไรเราเกี่ยวกับสิ่งที่จะวางจำหน่าย จุดยืนที่ซื่อตรงคือการรั่วไหลนี้พิสูจน์ว่าตระกูลนี้มีอยู่จริงและพิสูจน์รูปร่างของมัน แต่ไม่ได้พิสูจน์เพดานสูงสุดของมัน หากคุณกำลังรอโมเดล Liquid ที่มีขนาด >10B PR นี้ไม่ได้สัญญาว่าจะมี และไม่ได้ตัดความเป็นไปได้นั้นออก

สิ่งที่ LFM3 สืบทอดมา ไม่ว่าจะดีหรือร้าย

เกณฑ์มาตรฐานที่มันต้องเอาชนะนั้นใหม่และมีเอกสารประกอบอย่างดี LFM2.5-24B-A2B เปิดตัวเมื่อวันที่ 13 ตุลาคม 2026 ด้วยพารามิเตอร์รวม 24B โดยมี 2B ที่ใช้งานจริง, 40 เลเยอร์, 64 ผู้เชี่ยวชาญ และการกำหนดเส้นทางแบบ top-4, บริบท 131,072 โทเค็น, คำศัพท์ 128K และโทเค็นก่อนการฝึก 33T LFM2.5-2.6B จากต้นเดือนสิงหาคม มีขนาดไม่ถึง 2.5GB พร้อมบริบท 128K LFM2.5-VL-3B จับคู่ฐาน 2.6B กับตัวเข้ารหัสภาพ SigLIP2

ควรกล่าวให้ชัดเจนว่า ทุกเบนช์มาร์กที่ Liquid เผยแพร่สำหรับโมเดลเหล่านี้เป็นการรันโดยผู้ขายบนฮาร์เนสของ Liquid เอง โดยไม่มีผลการประเมินอิสระแนบมาด้วย ตัวเลขพาดหัวของ LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — เป็นตัวเลขของ Liquid และตารางเดียวกันยังแสดงว่าโมเดลแพ้ให้กับ Qwen3.6-35B-A3B ใน WebArena Verified (26.75 เทียบกับ 37.62), GPQA Diamond และ SWE-Bench Verified ตารางของผู้ขายที่รวมข้อมูลการแพ้ไว้ด้วยนั้นน่าเชื่อถือกว่าตารางที่ไม่มีข้อมูลดังกล่าว แต่ความน่าเชื่อถือไม่เหมือนกับการยืนยันแล้ว ยังไม่มีตัวเลข LFM3 ใด ๆ ในรูปแบบใดเลย ดังนั้นจึงยังไม่มีสิ่งใดให้เปรียบเทียบในตอนนี้

การอนุญาตจะยังมีผลสืบเนื่องต่อไปเช่นกัน เช็กพอยต์ LFM ล่าสุดของ Liquid บน Hugging Face แต่ละรายการมีแท็ก license: other — เป็นสัญญาอนุญาต LFM แบบเฉพาะตัว ไม่ใช่ Apache-2.0 หรือ MIT ไม่ว่า LFM3 จะเผยแพร่ภายใต้สัญญาใด ให้ถือว่าเป็นข้อกำหนดแบบกำหนดเองเดียวกันจนกว่าการ์ดโมเดลจะระบุเป็นอย่างอื่น และอ่านข้อกำหนดเหล่านั้นก่อนที่คุณจะสร้างผลิตภัณฑ์บนเวตของโมเดล

เมื่อไหร่ที่มันอาจจะเกิดขึ้นจริง

ไม่มีใครรู้กำหนดวันที่แน่ชัด รวมถึงคนที่คาดเดากันเป็นอาชีพด้วย คำถามบน Manifold Markets เกี่ยวกับว่า LiquidAI LFM3 จะเปิดตัวเมื่อใดให้ Q4 2026 อยู่ที่ 40%, Q1 2027 ที่ 21%, Q2 2027 ที่ 21%, Q3 2026 ที่ 11% และ Q2 2026 ที่ 7% — จากปริมาณซื้อขายรวมประมาณ Ṁ160 ซึ่งน้อยพอที่เปอร์เซ็นต์เหล่านั้นจะสะท้อนเพียงเทรดเดอร์ไม่กี่รายมากกว่าจะเป็นฉันทามติ ควรอ่านว่า "น่าจะสักช่วงหนึ่งในสองไตรมาสข้างหน้า" และไม่แม่นยำไปกว่านั้น

กลไกทางเทคนิคชี้ว่าควรเร็วมากกว่าช้า การที่งานเคอร์เนลจะถูกนำเข้าไปอยู่ใน runtime หลักนั้นเป็นงานวิศวกรรมช่วงท้าย ไม่ใช่ช่วงเริ่มต้น คุณไม่เขียน convolution kernel ด้วย CuTe และต่อ hybrid cache สำหรับโมเดลที่อีกปีกว่าจะออก ชื่อตระกูลนิ่งเป็น LFM3 แล้วในสี่ variant และสี่เส้นทาง checkpoint แต่ PR ยังไม่ถูก merge โดย check ทั้งสามตัวแดง ต้องการ approving review ที่ยังไม่มี และ omni validation check 2 จาก 22 รายการ กับ vision check 2 จาก 16 รายการยังไม่ผ่านการเปรียบเทียบ ROUGE นั่นคือ branch ที่อยู่ระหว่างดำเนินการ ไม่ใช่ release candidate

สิ่งนี้หมายความว่าอย่างไรหากคุณกำลังเลือกโมเดลในสัปดาห์นี้

ไม่มีสิ่งใดเกี่ยวกับ LFM3 ที่ควรเปลี่ยนการตัดสินใจของคุณในวันนี้ มันยังไม่พร้อมใช้งาน ไม่มีการประกาศราคา ไม่มีผลการทดสอบมาตรฐาน และไม่มีการให้สิทธิ์ใช้งานต่อสาธารณะ หากคุณต้องการโมเดลมัลติโหมดขนาดเล็กตอนนี้ LFM2.5 เจเนอเรชันคือคำตอบที่แท้จริง และข้อจำกัดของมัน — คะแนนที่ผู้จำหน่ายรายงานเอง สัญญาอนุญาตใช้งานแบบกำหนดเอง และโปรไฟล์ด้านการเขียนโค้ดที่ทั้งตารางของ Liquid เองและการรายงานจากภายนอกชี้ว่าเป็นจุดอ่อน — คือสิ่งที่ต้องนำมาชั่งน้ำหนัก

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

ความกระจัดกระจายของรันไทม์คือปัญหาที่เกิดขึ้นจริงที่ตระกูลโมเดลนี้จะสร้างขึ้น นิสัยของ Liquid ในการปล่อยโมเดลไปยัง llama.cpp, MLX, vLLM, SGLang และ ONNX พร้อมกันนั้นดีต่อการพอร์ต แต่ไม่สะดวกสำหรับใครก็ตามที่ต้องการ endpoint เดียว: ห้าเอนจินหมายถึงรูปแบบการดีพลอยห้าแบบ ชุดความแปลกประหลาดของการประมวลผลล่วงหน้าห้าชุด และวันที่การแก้ไขจะถูกปล่อยแตกต่างกันห้าวัน และแคตตาล็อกของ OrcaRouter ที่มีโมเดลมากกว่า 200 รายการยังไม่มี LFM checkpoint เพียงรายการเดียวในวันนี้ จึงไม่มีทางเรียก LFM3 ผ่านแคตตาล็อกนั้นได้ และไม่ควรตีความสิ่งใดในที่นี้ว่าเป็นคำสัญญาว่าจะมีในอนาคต สิ่งที่เลเยอร์เราเตอร์ทำจริงในสถานการณ์นี้คือรอยต่อระหว่างโมเดลที่ยังไม่ได้รับการพิสูจน์กับเส้นทางโปรดักชัน — การส่งทราฟฟิกส่วนหนึ่งไปยังสิ่งใหม่ ขณะที่โมเดลที่รู้จักยังคงอยู่เบื้องหลัง โดยมี failover คอยรับช่วงช่องว่าง คือวิธีที่คุณประเมินผู้สืบทอดของตระกูลที่ยังไม่เปิดตัว โดยไม่ต้องเอาฟีเจอร์ที่ลูกค้าเห็นมาเดิมพันกับตลาดพยากรณ์ที่ให้โอกาส 40%

คำถามที่ยังไม่มีคำตอบที่น่าจับตา

สี่สิ่งจะคลี่คลายเรื่องนี้ได้เร็วกว่าการคาดเดาเพิ่มเติมใด ๆ ไม่ว่าพาธเช็กพอยต์ทั้งสี่จะกลายเป็นรีโพซิทอรี Hugging Face จริงที่ดาวน์โหลดได้หรือไม่ — ตอนนี้การค้นหาในองค์กร LiquidAI ไม่คืนผลลัพธ์ใด ๆ ภายใต้ LFM3 และรีโพซิทอรีที่ระบุชื่อใน PR ก็ไม่สามารถเข้าถึงได้แบบสาธารณะ ไม่ว่า PR ของ Transformers จะปรากฏหรือไม่ ซึ่งจะบ่งชี้ว่าสถาปัตยกรรมกำลังถูกอัปสตรีมอย่างถูกต้อง แทนที่จะรันผ่านรีโมตโค้ด ไม่ว่าการตรวจสอบความถูกต้องที่ไม่ผ่านจะปิดลงหรือไม่ เนื่องจากความล้มเหลว omni 2 จาก 22 ครั้งคือความแตกต่างระหว่างเดโมกับการ merge และไม่ว่าสมาชิกในตระกูลที่มีขนาด >10B จะปรากฏขึ้นหรือไม่ ซึ่งเป็นคำถามที่ Labonne กล่าวว่า LFM3 มีอยู่เพื่อตอบ

จนถึงตอนนั้น ประโยคที่แม่นยำที่สุดที่ใครก็เขียนเกี่ยวกับ LFM3 ได้คือประโยคที่บทความนี้เปิดด้วย: มี pull request อยู่ฉบับหนึ่ง ซึ่งยังไม่ถูก merge และมันระบุชื่อโมเดล omni ขนาดเล็กสี่ตัวที่ Liquid AI ยังไม่ได้ประกาศ นั่นคือสัญญาณจริง — เพียงแต่เป็นสัญญาณระยะแรก และสัญญาณระยะแรกก็สมควรถูกอ่านในฐานะสัญญาณระยะแรกเช่นนั้น