Meta MobileLLM-Flash: ออกแบบโมเดลภาษาขนาดใหญ่สำหรับอุปกรณ์พกพาใหม่ โดยยึดหลักความหน่วงเวลาจริงเป็นพื้นฐานสำคัญ

คำสำคัญ: โมเดลขนาดใหญ่ฝั่งอุปกรณ์, การรับรู้ความหน่วงเวลา, ฮาร์ดแวร์ในวงจร, การค้นหาโครงสร้าง, ความสนใจแบบผสม

เมื่อคุณถามผู้ช่วย AI บนโทรศัพท์มือถือ แล้วรอ… 1 วินาที, 2 วินาที, 3 วินาที… จนถึงวินาทีที่ 10 จึงเห็นตัวอักษรแรกปรากฏขึ้น ตามกฎของ Nielsen ความหน่วงเวลาที่เกิน 4 วินาทีนี้เพียงพอที่จะทำให้ผู้ใช้รู้สึกหงุดหงิดหรือแม้แต่เลิกใช้ นี่คือจุดเจ็บปวดด้าน “ความเป็นมนุษย์” ที่โมเดลขนาดใหญ่ฝั่งอุปกรณ์ในปัจจุบันมักมองข้ามไปเมื่อไล่ตาม “ความฉลาด”

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

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

MobileLLM-Flash ที่ Meta AI เปิดตัวล่าสุด เกิดขึ้นมาเพื่อแก้ไขความขัดแย้งพื้นฐานนี้โดยเฉพาะ มันไม่ได้หมกมุ่นอยู่กับการแข่งขันเรื่องพารามิเตอร์ แต่เสนอข้อคิดเห็นหลักว่า: การออกแบบโมเดลขนาดใหญ่ฝั่งอุปกรณ์ ต้องใช้ความหน่วงเวลาจริงบนอุปกรณ์เคลื่อนที่เป็น “หลักการแรก” ปล่อยให้ฮาร์ดแวร์เองเป็นผู้นำทางในการออกแบบโครงสร้างโมเดล

ผ่านการค้นหาโครงสร้างแบบฮาร์ดแวร์ในวงจร MobileLLM-Flash วัดความหน่วงเวลาโดยตรงบนโทรศัพท์มือถือ Samsung Galaxy S25 และใช้สิ่งนี้เป็นเป้าหมายในการปรับให้เหมาะสม

รูปที่ 1: การเปรียบเทียบระหว่าง MobileLLM-Flash กับโมเดลภาษาขนาดใหญ่ฝั่งอุปกรณ์ที่ล้ำสมัยที่สุด บน CPU ฝั่งอุปกรณ์ ความเร็วในการเติมล่วงหน้าและการถอดรหัสเพิ่มขึ้นเป็น 1.8 เท่าและ 1.6 เท่าตามลำดับ ในขณะที่ความแม่นยำดีกว่าโมเดลในประเภทเดียวกัน

ในที่สุด พวกเขาประสบความสำเร็จในการเร่งความเร็วสูงสุด 1.8 เท่า (เติมล่วงหน้า) และ 1.6 เท่า (ถอดรหัส) บน CPU ฝั่งอุปกรณ์เคลื่อนที่ ในสามขนาดคือ 350M, 650M และ 1.4B พร้อมทั้งรักษาหรือแม้แต่เหนือกว่าความแม่นยำของโมเดลในประเภทเดียวกัน นี่ไม่ใช่เพียงชัยชนะของพารามิเตอร์เท่านั้น แต่ยังเป็นการจับคู่แนวหน้า Pareto ของ “ความหน่วงเวลา-คุณภาพ” ได้อย่างแม่นยำ

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

1. บทนำ: “บ่วงบาศ” ของโมเดลขนาดใหญ่ฝั่งอุปกรณ์ – ความหน่วงเวลาจริง

ในการสร้างแอปพลิเคชัน AI เรามักจะสนใจตัวชี้วัดสองอย่าง: คุณภาพและประสิทธิภาพ แต่สำหรับโมเดลขนาดใหญ่ฝั่งอุปกรณ์ที่ใช้งานบนอุปกรณ์ที่มีทรัพยากรจำกัด เช่น โทรศัพท์มือถือ แว่นตาอัจฉริยะ คำจำกัดความของประสิทธิภาพไม่ได้ง่ายเหมือน “จำนวนพารามิเตอร์” หรือ “FLOPs” บ่วงบาศที่แท้จริงคือความหน่วงเวลา โดยเฉพาะความหน่วงเวลาของคำแรก

เอกสารวิจัยระบุชัดเจนว่า: “While a 4s TTFT can still yield a reasonable user experience, a 10s TTFT does not (Nielsen 1994; Kim et al. 2026).” ซึ่งหมายความว่า ในการออกแบบโมเดล ภายใต้เงื่อนไขที่ต้องรักษาคุณภาพไว้ จำเป็นต้องบังคับให้ TTFT อยู่ใน “กรอบเวลา” ที่เข้มงวด ผู้เขียนพบว่าสำหรับโมเดลฝั่งอุปกรณ์ ระยะการเติมล่วงหน้าที่ประมวลผลประมาณ 2000 โทเค็น เป็น “จุดหวาน” ที่สามารถรองรับทั้งความสามารถของงานและความหน่วงเวลาได้

อย่างไรก็ตาม วิธีการปรับให้เหมาะสมแบบดั้งเดิมมักขัดแย้งกับเป้าหมายนี้:

1.1 ใช้ FLOPs/จำนวนพารามิเตอร์เป็นตัวชี้วัดทดแทน: นี่คือความเข้าใจผิดที่พบได้บ่อยที่สุด

ตารางที่ 2 เผยให้เห็นความจริงอันโหดร้าย: ค่าสัมประสิทธิ์สหสัมพันธ์ Kendall tau ระหว่างจำนวนพารามิเตอร์กับความหน่วงเวลาในการเติมล่วงหน้าคือเพียง 0.40 และค่าสัมประสิทธิ์สหสัมพันธ์ระหว่าง FLOPs กับความหน่วงเวลาในการเติมล่วงหน้าก็มีเพียง 0.46

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

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

ตารางที่ 2: ความเร็วในการเติมล่วงหน้า/ถอดรหัสที่วัดจริงกับจำนวนพารามิเตอร์/FLOPs ตารางนี้เผยให้เห็นความสัมพันธ์ที่อ่อนแอระหว่างตัวชี้วัดทางทฤษฎีกับความหน่วงเวลาจริงผ่านค่าสัมประสิทธิ์สหสัมพันธ์ Kendall tau

1.2 พึ่งพาเคอร์เนลเฉพาะทาง

การออกแบบโมเดลที่ยอดเยี่ยมหลายอย่าง เช่น Mamba2, Gated DeltaNet ฯลฯ แม้ว่าจะลดความซับซ้อนในการคำนวณได้อย่างมากในเชิงอัลกอริทึม แต่พวกมันพึ่งพาเคอร์เนล CUDA ที่ได้รับการปรับให้เหมาะสมสูงและไม่ใช่มาตรฐาน

นี่อาจไม่ใช่ปัญหาบนฝั่งเซิร์ฟเวอร์ แต่บนรันไทม์ฝั่งอุปกรณ์เคลื่อนที่ข้ามแพลตฟอร์ม (เช่น Android, iOS) (เช่น ExecuTorch) การขาดหายหรือประสิทธิภาพไม่ดีของเคอร์เนลเหล่านี้ จะกลายเป็นอุปสรรค “ไมล์สุดท้าย” ในการใช้งาน

ปรัชญาการออกแบบของ MobileLLM-Flash คือการทำลายอุปสรรคทั้งสองนี้ แนวคิดหลักคือ: วัดความหน่วงเวลาบนฮาร์ดแวร์จริง และใช้ความหน่วงเวลาจริงนี้เป็นแนวทางสำหรับกระบวนการออกแบบทั้งหมด

2. วิธีการหลัก: ให้ฮาร์ดแวร์พูด – การออกแบบสองขั้นตอนที่รับรู้ความหน่วงเวลา

วิธีการของ MobileLLM-Flash สามารถสรุปได้ว่าเป็นกรอบการค้นหาแบบสองขั้นตอนที่ขับเคลื่อนโดย “ความร่วมมือระหว่างฮาร์ดแวร์-ซอฟต์แวร์” ดังแสดงในรูปที่ 2

รูปที่ 2: ภาพรวมการออกแบบโมเดลภาษาขนาดใหญ่ฝั่งอุปกรณ์แบบสองขั้นตอน

กรอบนี้ทำการตัดแต่งโมเดลที่ฝึกไว้ล่วงหน้าผ่านการค้นหาร่วมระหว่างโครงสร้างและโหมดความสนใจโดยอิงตามการปรับให้เหมาะสมแบบเบย์เซียน (BO) หัวใจสำคัญอยู่ที่การนำตัวชี้วัดสำคัญ “ความหน่วงเวลา” ซึ่งเป็นตัวชี้วัดสำคัญในการใช้งานจริง เข้ามาในวงจรการค้นหา

• ขั้นตอนที่หนึ่ง: เรียนรู้โมเดลความหน่วงเวลา สุ่มตัวอย่างโครงสร้างที่ตัดแต่งแล้วจากพื้นที่ค้นหา และวัดความหน่วงเวลาบนโทรศัพท์มือถือโดยตรง ข้อมูลการวัดจากอุปกรณ์จริงที่มีต้นทุนต่ำเหล่านี้ ถูกใช้เพื่อฝึกโมเดลตัวแทนความหน่วงเวลาที่มีความแม่นยำสูง จึงหลีกเลี่ยงการวัดจริงที่มีค่าใช้จ่ายสูงสำหรับโครงสร้างผู้สมัครแต่ละโครงสร้างในภายหลัง
• ขั้นตอนที่สอง: การค้นหาแนวหน้า Pareto ใช้โมเดลตัวแทนความหน่วงเวลาที่ฝึกไว้ เพื่อชี้นำการปรับให้เหมาะสมแบบเบย์เซียนให้สำรวจพื้นที่ค้นหาได้อย่างมีประสิทธิภาพ สร้างแนวหน้า Pareto ของความแม่นยำ-ความหน่วงเวลา ขั้นตอนนี้มุ่งเน้นไปที่พื้นที่ที่มีศักยภาพสูงสำหรับการประเมินความแม่นยำ ทำให้กระบวนการค้นหาสามารถสะท้อนข้อจำกัดของฮาร์ดแวร์จริง (เช่น การเข้าถึงหน่วยความจำ การจัดตารางงานโอเปอเรเตอร์) ได้โดยตรง แทนที่จะพึ่งพาตัวชี้วัดทางทฤษฎีเช่น FLOPs

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

2.1 การตัดแต่งแบบมีโครงสร้าง: “ผู้สืบทอด” โครงสร้างที่มีประสิทธิภาพ

การฝึกโมเดลผู้สมัครแต่ละตัวตั้งแต่เริ่มต้นมีต้นทุนสูงเกินไปและไม่เป็นไปตามความเป็นจริง MobileLLM-Flash ใช้วิธีการตัดแต่งแบบมีโครงสร้างอย่างชาญฉลาด: เริ่มจาก “โมเดลหลัก” ที่ฝึกไว้ล่วงหน้าและค่อนข้างใหญ่ ผ่านการตัดแต่งมิติ จำนวนชั้น และโหมดความสนใจ เพื่อสร้างโครงสร้างผู้สมัครใหม่ที่เล็กกว่า

ข้อได้เปรียบหลักของวิธีนี้คือ “การสืบทอด”:

• ประสิทธิภาพ: โมเดลที่ตัดแต่งแล้วสืบทอดน้ำหนักของโมเดลดั้งเดิมโดยตรง ดังนั้นจึงต้องการเพียง “การฝึกล่วงหน้าอย่างต่อเนื่อง” น้อยมากก็สามารถบรรลุคุณภาพที่ค่อนข้างสูงได้
• การจัดอันดับอย่างรวดเร็ว: การทดลองพบว่าหลังจากฝึกเพียง 2.6B โทเค็น การจัดอันดับคุณภาพของโครงสร้างต่างๆ ก็สอดคล้องอย่างสูงกับการจัดอันดับสุดท้ายหลังจากฝึก 500B โทเค็นแล้ว (ค่าสัมประสิทธิ์สหสัมพันธ์ Kendall tau คือ 0.74) ซึ่งเร่งกระบวนการค้นหาได้อย่างมาก
• มาตรฐานการตัดแต่งตามพลังงาน: การตัดสินใจตัดแต่งขับเคลื่อนโดยข้อมูล ไม่ใช่การสุ่ม
  • มิติ FFN: ตัดแต่งตามบรรทัดฐาน L2 (พลังงาน) ของการกระตุ้นในชั้น FFN
  • มิติโมเดล: ตัดแต่งตามบรรทัดฐาน L2 ของผลลัพธ์ LayerNorm
  • จำนวนชั้น: ตัดสินใจว่าชั้นใด “ไม่สำคัญ” ตามความคล้ายคลึงโคไซน์ระหว่างการกระตุ้นอินพุตและเอาต์พุต ตัดชั้นที่มีฟังก์ชันซ้ำซ้อนออกก่อน

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

2.2 พื้นที่ค้นหาที่ถูกจำกัด: ยอมรับโอเปอเรเตอร์ที่ “พร้อมใช้งานทันที”

เพื่อให้แน่ใจว่าโมเดลสามารถใช้งานได้อย่างราบรื่นในสภาพแวดล้อมการผลิต MobileLLM-Flash จำกัดพื้นที่ค้นหาอย่างเคร่งครัด ให้รวมเฉพาะโอเปอเรเตอร์ที่ได้รับการสนับสนุนโดยธรรมชาติจากรันไทม์ฝั่งอุปกรณ์เคลื่อนที่หลัก (เช่น ExecuTorch) ซึ่งลดขั้นตอนการใช้งานได้อย่างมาก

พื้นที่ค้นหา S ถูกกำหนดให้เป็นการรวมกันของพารามิเตอร์โครงสร้าง ในนั้น สิ่งที่สำคัญที่สุดคือโหมดความสนใจ พิจารณาเพียงสามประเภทต่อไปนี้:

1. ความสนใจแบบทั่วโลก: กลไกความสนใจเต็มรูปแบบมาตรฐาน
2. ความสนใจแบบหน้าต่างเลื่อน: จำกัดว่าแต่ละโทเค็นสนใจเฉพาะโทเค็นภายในหน้าต่างที่กำหนดใกล้เคียงเท่านั้น
3. ความสนใจแบบข้าม: ข้ามการคำนวณความสนใจของชั้น Transformer บางชั้นโดยสิ้นเชิง เทียบเท่ากับว่าชั้นนั้นประกอบด้วยเครือข่ายฟีดฟอร์เวิร์ดเท่านั้น

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

2.3 การปรับให้เหมาะสมแบบเบย์เซียนสองขั้นตอน: ดนตรีคู่ของความหน่วงเวลาและคุณภาพ

เมื่อมีพื้นที่ค้นหาและวิธีการสร้างผู้สมัครแล้ว จะค้นหาคำตอบที่ดีที่สุดได้อย่างมีประสิทธิภาพอย่างไร? MobileLLM-Flash ใช้การปรับให้เหมาะสมแบบเบย์เซียน และแบ่งออกเป็นสองขั้นตอนอย่างชาญฉลาด เพื่อแก้ไขความขัดแย้งที่ว่า “การวัดความหน่วงเวลาทำได้เร็ว แต่การฝึกคุณภาพทำได้ช้า”

ขั้นตอนที่หนึ่ง: เรียนรู้โมเดลความหน่วงเวลา

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

ขั้นตอนที่สอง: การค้นหาแนวหน้า Pareto

เมื่อมีโมเดลทำนายความหน่วงเวลาแล้ว กระบวนการค้นหาจะเปลี่ยนจากการพึ่งพาการวัดฮาร์ดแวร์จริงเป็นการพึ่งพาการทำนายของโมเดล ความเร็วจึงเพิ่มขึ้นอย่างมาก

รูปที่ 3: แผนภาพแนวหน้า Pareto ของความหน่วงเวลา-ความแม่นยำ

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

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK