Meta เปิดตัว Muse Glimmer ซึ่งเป็นโมเดล Agent แบบมัลติโมดัลที่มีพารามิเตอร์ประมาณ 30B รองรับบริบทระดับ 128K และสามารถทำงานได้บนอุปกรณ์ที่มีหน่วยความจำ GPU 24GB โมเดลนี้เปิดให้ใช้งานภายใต้ใบอนุญาต Apache 2.0 โดยใช้ GQA เพื่อลดการใช้งาน KV Cache รวมกับสถาปัตยกรรมผสมระหว่าง Local และ Global Attention เพื่อลดต้นทุนการคำนวณสำหรับบริบทยาว และมีเวอร์ชันควอนไทซ์สองแบบเพื่อรองรับอุปกรณ์ที่มีหน่วยความจำต่างกัน โมดูลภาพมี ViT Perception Encoder แบบแยกต่างหากสำหรับประมวลผลภาพหน้าจอและข้อมูลหน้าจอ ในขั้นตอนการฝึกอบรมมีการใช้ On Policy Distillation เพื่อครอบคลุมสถานการณ์ที่งานยาวเบี่ยงเบนจากสถานะเดิม องค์ประกอบ DFlash สำหรับเร่งความเร็วการให้เหตุผลใช้ Block Diffusion เพื่อทำนาย Token แบบขนาน และสามารถเพิ่มความเร็วในการถอดรหัสประมาณ 3 เท่าบน RTX 5090 โมเดลนี้แสดงประสิทธิภาพที่ยอดเยี่ยมใน Agent Benchmark เช่น MCP Atlas และ DeepSearch QA แต่ยังมีพื้นที่สำหรับการปรับปรุงในสถานการณ์ GUI บริสุทธิ์เช่น OSWorld Verified

ผู้เขียนบทความ แหล่งที่มา: LeFeng.com

เมื่อวานนี้ Meta ได้เปิดตัว Muse Glimmer ซึ่งเป็นโมเดล Agent แบบหลายโมดัลที่มีพารามิเตอร์ประมาณ 30B รองรับบริบทระดับ 128K สามารถเรียกใช้เครื่องมือ รันโค้ด รวมถึงจัดการข้อมูลรูปภาพและหน้าจอได้

โมเดลนี้เปิดให้ใช้งานภายใต้ใบอนุญาต Apache 2.0 พร้อมด้วยเวอร์ชันการลดความละเอียด 4bit สองชุด เอ็นโค้ดเดอร์ภาพแบบอิสระ และส่วนประกอบ DFlash สำหรับเร่งความเร็วการให้บริการ พร้อมรองรับการติดตั้งแบบโลคัลผ่าน llama.cpp, MLX, ExecuTorch เป็นต้น

แม้ขนาดพารามิเตอร์ 30B และบริบท 128K จะดูไม่ได้แปลกใหม่ในวันนี้ แต่ปัญหาคือ Meta ต้องการให้มันทำมากกว่าการพูดคุยทั่วไป คือการสร้างรูปแบบการดำเนินการ Agent แบบท้องถิ่นที่สมบูรณ์

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

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

การออกแบบทางเทคนิคของ Muse Glimmer มุ่งเน้นไปที่คำถามเหล่านี้เป็นหลัก มันไม่ได้แก้ไขทุกอย่างด้วยสถาปัตยกรรมใหม่ที่โดดเด่นเพียงอย่างเดียว แต่ได้ทำการตัดสินใจอย่างรุนแรงในเรื่อง Attention, KV Cache, วิธีการฝึกอบรม, การลดความละเอียด และ Decode

หากโมเดลท้องถิ่นในอดีตเป็นเพียง “ทำงานได้” เป้าหมายของ Muse Glimmer คือ “ใช้งานได้ดีและทำงานต่อเนื่องเหมือนบนคลาวด์”

การดูส่วนเหล่านี้ร่วมกัน จะช่วยให้เข้าใจได้ง่ายกว่าการดูเพียง 30B หรือ 128K เดี่ยวๆ ว่าทำไม Meta จึงออกแบบมันให้เป็นแบบนี้

จะบีบข้อมูลบริบท 128K ให้อยู่ในหน่วยความจำ GPU 24GB ได้อย่างไร

Muse Glimmer ใช้ Dense Transformer 52 ชั้น โดยมี Hidden Size เท่ากับ 6656 มี 32 Query Head แต่มีเพียง 2 KV Head

Attention ไม่ได้จัดการบริบททั้งหมดในทุกระดับ แต่ใช้วิธีวนลูปโดยใช้ Local Attention สามครั้ง ตามด้วย Global Attention หนึ่งครั้ง

Local Attention จัดการเฉพาะโทเค็นใกล้เคียง 2048 ตัว เท่านั้น ในขณะที่ Global Attention รับผิดชอบการแลกเปลี่ยนข้อมูลระยะไกล

การออกแบบทั้งสองอย่างนี้แท้จริงแล้วเพิ่มต้นทุนในการจัดการบริบทที่ยาวขึ้น เมื่อโมเดลสร้าง Token ใหม่ จะเก็บ Key และ Value ของ Token ก่อนหน้าไว้ในหน่วยความจำชั่วคราว หรือที่เรียกว่า KV Cache ยิ่งบริบทยาวเท่าใด ส่วนนี้ก็จะใช้พื้นที่มากขึ้นเท่านั้น

Muse Glimmer แต่ละชั้นมีเพียง 2 KV Head โดยแต่ละ Head Dimension มีค่าเท่ากับ 128 ตามการคำนวณคร่าวๆ ด้วย BF16 หนึ่ง Token ในแต่ละชั้นจะใช้หน่วยความจำ KV ประมาณ 1024 Byte

หากเก็บข้อมูลแบบครบถ้วน 128K Context ไว้ทั้ง 52 ชั้น KV Cache จะต้องใช้ประมาณ 6.5 GiB แต่ Muse Glimmer มีชั้น Local 39 ชั้น และชั้น Global 13 ชั้น ชั้น Local จำเป็นต้องเก็บหน้าต่างเลื่อนเพียงประมาณ 2048 Token เท่านั้น โดยมีเพียงชั้น Global เท่านั้นที่ต้องเก็บบริบทยาวแบบครบถ้วน

โดยการประมาณในลักษณะเดียวกัน ค่า KV Cache สามารถลดลงเหลือประมาณ 1.7 GiB นี่ไม่ใช่หน่วยความจำ GPU ที่ประกาศอย่างเป็นทางการ แต่เป็นการประมาณเชิงทฤษฎีจากพารามิเตอร์สถาปัตยกรรมที่เปิดเผย แต่ก็เพียงพอที่จะอธิบายได้ว่าทำไมโครงสร้างนี้ถูกออกแบบมาเช่นนี้

หากมันไม่ใช้ 2 KV Head แต่เก็บ KV แยกสำหรับแต่ละหัว 32 หัวเหมือน MHA แบบดั้งเดิม ในเงื่อนไขเดียวกัน KV Cache จะขยายเพิ่มขึ้นประมาณ 16 เท่า โดยจะอยู่ที่กว่า 20 GiB

KV Cache แบบเดี่ยวเองก็เกินการ์ดจอ 24GB แล้ว ที่นี่ใช้วิธีสองแบบจริงๆ GQA ลดจำนวน KV ที่ต้องบันทึกต่อโทเค็น ในขณะที่ Local Attention ลดจำนวนชั้นที่ต้องบันทึก KV แบบเต็มในระยะยาว

หลังจากทำขั้นตอนนี้เสร็จแล้ว การลดน้ำหนักจึงมีความหมาย MUSE GLIMMER ที่มีน้ำหนัก K Quant 17GB ประมาณ 16.8GB โมดูลภาพประมาณ 1.4GB DFlash ประมาณ 1.6GB ทั้งสามส่วนรวมกันใกล้เคียงกับ 20GB เวอร์ชันนี้ออกแบบสำหรับอุปกรณ์ที่มีหน่วยความจำ GPU 24GB ส่วนชุดที่มีน้ำหนักประมาณ 20GB แบบ Dynamic K Quant ออกแบบสำหรับอุปกรณ์ 32GB

การควอนตัมสองแบบไม่ได้แตกต่างกันแค่ขนาดไฟล์เท่านั้น ใน 15 แบบทดสอบที่ Meta ให้มา ค่าเฉลี่ยการสูญเสียความแม่นยำของ Dynamic K Quant อยู่ที่ประมาณ 0.2% ส่วน K Quant 17GB อยู่ที่ประมาณ 1.0%

กล่าวคือ รุ่น 24GB ลดหน่วยความจำกราฟิกให้น้อยลงและใช้พื้นที่น้อยกว่า แต่ต้องยอมรับการสูญเสียประสิทธิภาพเล็กน้อย ขณะที่รุ่น 32GB พยายามรักษาประสิทธิภาพของโมเดลเดิมไว้ให้มากที่สุด

บริบท 128K ของ Muse Glimmer ถูกสร้างขึ้นภายใต้การรวมกันนี้ โดย Attention ลดปริมาณการคำนวณก่อน ตามด้วย GQA ที่ลด KV Cache และสุดท้ายใช้การควอนไทซ์เพื่อลดน้ำหนักของโมเดล

แนวทางนี้ยังมีค่าใช้จ่ายอยู่ 39 ชั้น Local สามารถเข้าถึง Token ใกล้เคียงได้เพียง 2048 ตัวเท่านั้น ข้อมูลระยะไกลต้องผ่านชั้น Global เพื่อแพร่กระจาย ดังนั้น การรับข้อมูลได้ 128K จึงไม่เหมือนกับการใช้งานอย่างมั่นคงตลอดทั้ง 128K

ผลลัพธ์ของ Beam128K จาก Meta แสดงให้เห็นว่าโครงสร้างแบบผสมระหว่าง Local และ Global ยังคงมีความสามารถในการใช้ข้อมูลระยะไกลได้ดี แต่มันแก้ปัญหาเกี่ยวกับ Long Context ไม่ใช่ Long-term Memory ข้อมูลใดควรเก็บไว้ ข้อมูลใดล้าสมัย และเมื่อใดควรอัปเดตสถานะ ยังคงต้องได้รับการจัดการโดย Agent Runtime

ปัญหานี้จะชัดเจนยิ่งขึ้นเมื่อถึงวิชวลเอเจนต์

128K ไม่ใช่พื้นที่ไม่จำกัด

Muse Glimmer ยังมี ViT G 14 Perception Encoder ที่มีพารามิเตอร์ประมาณ 1.8 พันล้านตัว ใช้สำหรับประมวลผลภาพหน้าจอ เว็บเพจ แผนภูมิ และเอกสาร รูปภาพหนึ่งภาพสามารถแปลงเป็น Visual Token ได้สูงสุด 4,096 ตัว

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

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

ดังนั้นข้อมูลภาพจะถูกส่งเข้าสู่บริบทอย่างต่อเนื่อง หากเก็บภาพหน้าจอทั้งหมดจากงานที่มีหลายสิบขั้นตอนไว้ครบถ้วน แม้จะมีความจุ 128K บริบทก็จะถูกเติมเต็มด้วย Visual Token อย่างรวดเร็ว ภาพหน้าจอเก่าอาจขัดแย้งกับสถานะปัจจุบัน หน้าเว็บได้เปลี่ยนไปแล้ว แต่ปุ่มและหน้าต่างก่อนหน้ายังคงอยู่ในบริบท ทำให้โมเดลต้องใช้เวลาเพิ่มเติมในการตัดสินว่าสถานะใดคือสถานะล่าสุด

Meta ยังไม่ได้เก็บประวัติหน้าจอทั้งหมดในการประเมินของ OSWorld Verified แต่เก็บเฉพาะหน้าจอที่เพิ่งถูกถ่ายไว้เท่านั้น ซึ่งแสดงให้เห็นว่า Perception Encoder และ Context Management เป็นปัญหาที่แตกต่างกัน

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

แต่เมื่อตัวแทนมีการโต้ตอบกับสภาพแวดล้อมอย่างต่อเนื่อง ปัญหาเริ่มเปลี่ยนจากสิ่งที่โมเดลเห็น เป็นสิ่งที่โมเดลเพิ่งทำไป

นี่คือส่วนการฝึกอบรมของ Muse Glimmer

หลังจากตัวแทนเบี่ยงเบนไปแล้ว จะดำเนินการต่ออย่างไร

Muse Glimmer ถูกกลั่นออกมาจาก Muse Spark ที่ใหญ่กว่า

เมตาแบ่งการฝึกออกเป็น Pre Training, Mid Training และ Post Training โดย Pre Training ใช้ Logit Distillation, Mid Training เพิ่มข้อมูลบริบทยาวมากขึ้น, Reasoning Trace และข้อมูล Agent และ Post Training เพิ่ม SFT, On Policy Distillation และ RL

Logit Distillation มีความแตกต่างเล็กน้อยจากการใช้คำตอบจากโมเดลขนาดใหญ่เพื่อฝึกโมเดลขนาดเล็กทั่วไป เมื่อ Teacher ทำนาย Token ถัดไป จะให้การแจกแจงความน่าจะเป็นแก่ทั้ง Vocabulary ซึ่ง Student จะเรียนรู้ไม่เพียงแต่ Token ที่ถูกเลือกสุดท้าย แต่ยังเห็นการเปรียบเทียบเชิงสัมพัทธ์ของ Teacher ต่อตัวเลือกอื่นๆ

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

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

สมมติว่าเส้นทางที่ถูกต้องของ Teacher คือ A ไป B แล้วไป C สุดท้ายไป D หาก Student เรียนรู้เฉพาะข้อมูลของ Teacher เสมอ มันจะเห็นการเปลี่ยนจาก A ไป B และ B ไป C ซ้ำๆ แต่ในสถานการณ์จริง Student อาจก้าวขั้นแรกไปยังสถานะ B ที่ต่างออกไป

ตั้งแต่ขณะนี้ สภาพแวดล้อมได้เปลี่ยนไปแล้ว การเรียนรู้จาก B ถึง C ในชุดข้อมูลการฝึกไม่สามารถบอกมันได้โดยตรงว่าควรจัดการอย่างไรในขณะนี้ On Policy Distillation มีบทบาทที่นี่ นักเรียนจะทำการ Rollout เองก่อน เพื่อเข้าสู่สถานะที่มันจะเกิดขึ้นจริง จากนั้นจึงรับการกำกับดูแลจากโมเดลที่แข็งแกร่งกว่าในสถานะเหล่านั้น

ข้อมูลการฝึกจึงไม่ได้มีเพียงเส้นทางที่ครูแนะนำเท่านั้น แต่ยังครอบคลุมสถานการณ์ผิดพลาดที่นักเรียนสร้างขึ้นเองด้วย ซึ่งเชื่อมโยงกับแนวคิดการฟื้นตัวจากความล้มเหลวที่ Muse Glimmer เน้นย้ำ

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

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

อย่างไรก็ตาม การที่งานสามารถเสร็จสิ้นได้ ไม่ได้หมายความว่าการรันในท้องถิ่นจะไม่มีปัญหาอีกเลย หากงานที่ซับซ้อนหนึ่งครั้งต้องสร้าง Reasoning Token จำนวนมาก ข้อจำกัดใหม่จะเร็วๆ นี้กลายเป็น Decode

สองคำถามที่อยู่ก่อนและหลัง

Muse Glimmer รองรับสี่ระดับของ Reasoning Strength: low, medium, high และ xhigh การตั้งค่านี้สามารถเข้าใจได้ว่าเป็นงบประมาณการให้เหตุผลในระหว่างการดำเนินการ

ระดับที่สูงขึ้นมักจะทำให้โมเดลสร้าง Reasoning Token มากขึ้น ซึ่งอาจเพิ่มอัตราความสำเร็จในงานเขียนโค้ดที่ซับซ้อนและงานแบบ Agent แต่ค่าใช้จ่ายก็ชัดเจน: Context จะเพิ่มขึ้นเร็วขึ้น และเวลาในการ Decode ก็ยาวนานขึ้น

Meta ใช้ high Reasoning Strength ใน Benchmark ที่เปิดเผย ซึ่งนำไปสู่ DFlash

การถอดรหัสของ Transformer เป็นแบบอัตโนมัติ ตัวถอดรหัสที่สองต้องรอตัวถอดรหัสที่หนึ่ง ตัวถอดรหัสที่สามจึงขึ้นอยู่กับตัวถอดรหัสที่สอง สำหรับคำตอบที่มีหลายร้อยตัวถอดรหัสอาจยอมรับได้ แต่ภารกิจหนึ่งครั้งของตัวแทนอาจสร้างตัวถอดรหัสหลายพันหรือหลายหมื่นตัว

วิธีการ Speculative Decoding คือการเพิ่ม Drafter ที่มีขนาดเล็กกว่า Drafter จะทำนายชุด Token ถัดไปก่อน แล้วให้โมเดลหลักตรวจสอบทีละชุด หากมีตัวเลือกหลายตัวที่สามารถรับได้อย่างต่อเนื่อง จะช่วยลดจำนวนขั้นตอน Decode ที่โมเดลหลักขนาด 30B ต้องดำเนินการ

ปัญหาของวิธีการแบบดั้งเดิมคือ Drafter มักจะเป็นโมเดลแบบอัตโนมัติเชิงถอยหลังเช่นกัน หากต้องการ Draft 16 โทเค็น ก็ยังต้องสร้างทีละตัว

DFlash ได้เปลี่ยนส่วนนี้เป็น Block Diffusion

ขนาดบล็อก DFlash ของ Muse Glimmer คือ 16 ซึ่งสามารถทำนายชุดโทเค็นที่เป็นไปได้แบบขนานกันได้ แต่ Drafter ไม่ได้แค่ต้องเร็วเท่านั้น หากการคาดเดาไม่แม่นยำ โมเดลหลักจะปฏิเสธโทเค็นที่คาดเดาไว้จำนวนมาก ข้อได้เปรียบด้านความเร็วที่ได้มาก่อนจะหายไปอย่างรวดเร็ว

ดังนั้น DFlash จะอ่านคุณสมบัติที่ซ่อนอยู่ของ Muse Glimmer ที่ชั้นที่ 1, 13, 25, 37 และ 49 โดยส่งการแทนค่ากลางเหล่านี้ไปยัง Drafter ที่มีเพียง 5 ชั้น ทำให้ Drafter ไม่จำเป็นต้องเข้าใจบริบททั้งหมดอีกครั้ง แต่สามารถใช้การแทนค่าภายในที่โมเดลหลัก 30B ได้สร้างไว้แล้ว

คุณลักษณะเหล่านี้ไม่ได้ใช้เพียงครั้งเดียวที่ปลายป้อน แต่จะถูกฉีดอย่างต่อเนื่องเข้าไปใน Key และ Value ของแต่ละชั้นของ Drafter เพื่อป้องกันไม่ให้อ่อนลงเมื่อเครือข่ายลึกขึ้น

ในการฝึกยังมีรายละเอียดอีกประการหนึ่ง ในบล็อก Token ขนาด 16 ตัว ตัว Token ด้านหน้ามีความสำคัญมากกว่าตัวด้านหลัง หากตัว Token ตัวที่ 1 ผิด แม้จะทายถูกต่อจากนั้น ความยาวของการรับต่อเนื่องก็จะสั้นมาก

ดังนั้น DFlash จะให้ Loss Weight สูงกว่าแก่ Token ที่อยู่ด้านหน้าของ Block และค่อยๆ ลดลงตามลำดับที่ตามมา มันมุ่งปรับปรุงความยาวของคำนำหน้าที่ยอมรับได้ให้มากที่สุด แทนที่จะเน้นแค่ความแม่นยำเฉลี่ยใน 16 ตำแหน่ง ในชุดข้อมูล K Quant 17GB ที่ Meta เผยแพร่ ความเร็วในการ Decode บน RTX 5090 เพิ่มขึ้นจากประมาณ 74.9 Token/s เป็น 233.4 Token/s

หากงานของ Agent สร้าง Token สะสมทั้งหมด 10,000 ตัว โดยพิจารณาเฉพาะ Decode งานแรกจะใช้เวลาประมาณ 134 วินาที ในขณะที่งานหลังใช้เวลาประมาณ 43 วินาที งานจริงยังรวมถึง Prefill การดำเนินการเครื่องมือ และการรอเครือข่าย แต่สำหรับ Agent ที่มีความแข็งแรงด้านการให้เหตุผลสูง ช่องว่างนี้จะส่งผลกระทบอย่างชัดเจนต่อประสบการณ์ของงานทั้งหมด

High Reasoning Strength จะเพิ่มจำนวน Token ที่สร้างขึ้น ส่วน DFlash รับผิดชอบในการลดระยะเวลาส่วนนี้ บริบทที่ยาวจะเพิ่ม KV Cache ส่วน GQA และ Local Attention ช่วยลดการใช้หน่วยความจำ การควอนไทซ์ยังคงควบคุมน้ำหนักโมเดลให้อยู่ในขอบเขตที่การ์ดจอสำหรับผู้บริโภคสามารถรองรับได้

นอกจากนี้ Muse Glimmer ยังแสดงประสิทธิภาพที่ดีบน Agent Benchmark ต่างๆ เช่น MCP Atlas, DeepSearch QA และ Gaia2 ซึ่งงานเหล่านี้ต้องการโซ่การดำเนินการที่ยาวนาน

MCP Atlas ต้องการให้โมเดลเลือกและเรียกใช้เครื่องมือระหว่างเซิร์ฟเวอร์ MCP หลายตัว DeepSearch QA ต้องค้นหาอย่างต่อเนื่อง เปิดหน้าเว็บ ค้นหาข้อมูล และดำเนินการต่อตามผลลัพธ์ใหม่ Gaia2 จำลองแอปพลิเคชันที่มีสถานะ เช่น อีเมล ปฏิทิน และผู้ติดต่อ โดยสภาพแวดล้อมเองจะเปลี่ยนแปลงไปในระหว่างกระบวนการงาน

งานเหล่านี้สอดคล้องกับวิธีการฝึก Muse Glimmer อย่างมาก แต่เมื่อถึง OSWorld Verified, TerminalBench และ SWE Bench Verified มันไม่สามารถรักษาข้อได้เปรียบเดียวกันไว้ได้ ตัวอย่างเช่น ใน OSWorld Verified Muse Glimmer ได้คะแนน 65.9 ในขณะที่ Qwen3.6 27B ได้ 75.6 ส่วนใน TerminalBench 2.1 Muse Glimmer ได้ 51.7 ขณะที่คู่แข่งได้ 60.7

การกระจายความสามารถของมันจึงค่อนข้างชัดเจน: Research Agent, การร่วมมือกับเครื่องมือ และงานที่มีกระบวนการยาวนานมีประสิทธิภาพดีกว่า ขณะที่บริบทแบบ GUI บริสุทธิ์, เทอร์มินัล และบางส่วนของ Coding Agent ยังมีพื้นที่ในการปรับปรุงอย่างชัดเจน คะแนนเหล่านี้ไม่สามารถตีความได้ตามรายการโมเดลแบบดั้งเดิมอย่างสมบูรณ์

ผลลัพธ์ของ Agent Benchmark ยังได้รับอิทธิพลจาก System Prompt, Tool Definition, Scaffold, จำนวนขั้นตอนการดำเนินการสูงสุด, พารามิเตอร์การสุ่มตัวอย่าง และแม้แต่ Judge Model ด้วย Meta ยังระบุเองว่า เครื่องมือและ System Prompt ที่โมเดลของบุคคลที่สามใช้อาจไม่ได้รับการปรับแต่งให้เหมาะสมที่สุดสำหรับโมเดลเหล่านั้น

ดังนั้นเมื่อถึงขั้นตอน Agent การเปรียบเทียบ Checkpoint แบบแยกเดี่ยวจึงยากขึ้นที่จะอธิบายสถานการณ์ทั้งหมดได้อย่างครบถ้วน ความปลอดภัยก็เป็นปัญหาในลักษณะเดียวกัน

การรันในท้องถิ่นสามารถลดการส่งไฟล์ ภาพหน้าจอ และบริบทส่วนตัวไปยังคลาวด์บ่อยครั้ง แต่สิ่งนี้แก้ไขเพียงเส้นทางข้อมูลเท่านั้น ยังคงมีความเสี่ยงจากการโจมตีด้วย Prompt Injection, การเรียกใช้เครื่องมือผิดพลาด, การเกินสิทธิ์ และการดำเนินการที่ไม่สามารถย้อนกลับได้ Meta ยังได้ประเมินความเสี่ยงด้าน Agentic, ความเป็นส่วนตัว และ Prompt Injection อย่างเป็นอิสระ และแนะนำให้ในการปรับใช้งานจริงยังคงเพิ่ม Guardrail และการมีมนุษย์เข้ามาเกี่ยวข้อง (Human in the Loop) อย่างจำเป็น

เส้นทางความสามารถที่ชัดเจน

เส้นทางเทคโนโลยีทั้งหมดของ Muse Glimmer สุดท้ายสามารถเชื่อมต่อกันเป็นเส้นทางที่ชัดเจนกว่า

ควบคุมขนาดโมเดลให้อยู่ที่ประมาณ 30B โดยใช้ GQA และ Local Attention เพื่อลดต้นทุนหน่วยความจำ GPU สำหรับบริบท 128K การทำควอนไทซ์ช่วยให้โมเดลสามารถทำงานได้บนอุปกรณ์ 24GB และ 32GB Perception Encoder รับผิดชอบในการอ่านสภาพแวดล้อมเชิงภาพ On-Policy Distillation ครอบคลุมสถานะที่เบี่ยงเบนในงานระยะยาว Reasoning Strength ให้ผู้พัฒนาควบคุมงบประมาณการให้เหตุผล DFlash จัดการความล่าช้าในการถอดรหัสที่เกิดจากโทเค็นการให้เหตุผลจำนวนมาก

Muse Glimmer ไม่ได้พิสูจน์ว่าโมเดลท้องถิ่นขนาด 30B สามารถแทนที่โมเดล Frontier บนคลาวด์ได้ แต่มันพิสูจน์ว่าจุดสุดท้ายของโมเดลท้องถิ่นขนาด 30B ไม่ได้อยู่ที่ขนาดเพียงอย่างเดียว แต่อยู่ที่การออกแบบระบบระดับระบบเพื่อจัดการกับข้อจำกัดทางฮาร์ดแวร์ต่างๆ อย่างรวมศูนย์ มันได้นำข้อจำกัดที่ยากที่สุดสี่ประการใน Agent ท้องถิ่น ได้แก่ หน่วยความจำ GPU บริบท ความรับรู้สถานะสภาพแวดล้อม และความเร็วในการประมวลผล มาไว้ในระบบออกแบบเดียวกัน

Muse Glimmer แม้ยังไม่สามารถแทนที่โมเดลระดับพรีเมียมบนคลาวด์ได้อย่างสมบูรณ์ แต่ได้เปิดทางให้กับเป้าหมาย “ทุกคนมี Agent ส่วนตัว” ด้วยแนวทางที่สามารถนำไปใช้งานในระดับอุตสาหกรรมได้แล้ว