ทำไม LLM ที่ขอบและโมเดลขนาดเล็กถึงสำคัญสำหรับแอปเรียลไทม์
โดย Win.AI Editorial
คำกล่าวของฉัน: LLM ที่ขอบกำลังกลายเป็นทางเลือกเริ่มต้นสำหรับฟีเจอร์ที่ไวต่อเวลาล่าช้าและใส่ใจในความเป็นส่วนตัว เพราะโมเดลขนาดเล็กที่ถูกสร้างปริมาณและระบบผสมผสานส่งผลให้เวลาล่าช้าสุดท้ายมีความชัดเจนและลดการเปิดเผยข้อมูล โดยไม่ทำให้ค่าใช้จ่ายของคลาวด์สูงขึ้น สิ่งนี้สามารถมองเห็นได้ในเครื่องมือต่างๆ รูปแบบโมเดล และการเคลื่อนไหวผลิตภัณฑ์ของผู้ให้บริการ
LLM ที่ขอบในการปฏิบัติ
โครงสร้างทางเทคนิคที่ทำให้การตีความบนอุปกรณ์เป็นไปได้ไม่ใช่เรื่องที่ให้เดาอีกต่อไป โครงการ llama.cpp และเครื่องมือการสร้างปริมาณ GGUF ได้รับการใช้กันอย่างแพร่หลายในการเรียกใช้โมเดล 4-bit และ 8-bit บนอุปกรณ์โทรศัพท์และแล็ปท็อป ทำให้โมเดลที่มีพารามิเตอร์ตั้งแต่ 1B ถึง 8B สามารถใช้งานได้บนฮาร์ดแวร์ทั่วไป Ollama ได้ทำให้การใช้งานของรันไทม์ท้องถิ่นและทะเบียนโมเดลที่ทำให้รันไทม์ GGUF และ MLX มาตรฐานสำหรับซิลิคอนของ Apple เป็นเชิงพาณิชย์ Apple ได้เผยแพร่การสาธิต MLX ที่ ICLR 2026 ซึ่งแสดงให้เห็นว่าโมเดลที่ถูกสร้างปริมาณทำงานได้ตามปกติบนชิป M-series การเปลี่ยนแปลงทั้งสามนี้รวมกันทำให้การวิจัยกลายเป็นการสร้างสแต็กที่นำไปใช้งานได้
ทำไมสิ่งนี้จึงสำคัญสำหรับแอปเรียลไทม์
เวลาล่าช้าไม่ใช่แค่ค่าเฉลี่ยของโทเคนต่อวินาที ผู้ใช้สังเกตเห็นความล่าช้า การเคลื่อนที่ของการเติมข้อมูลล่วงหน้าและการสร้างที่ง่ายไปยังอุปกรณ์ ทำให้การเดินทางข้อมูลที่ใช้เวลา 50 ถึง 300 มิลลิวินาที มีเวลาล่าช้าในการถอดรหัสในหลักหน่วยบน NPU และ GPU รุ่นใหม่ โดยเฉพาะบนซิลิคอนของ Apple และรุ่นเรือธงของ Snapdragon ความเป็นส่วนตัวดีขึ้นเพราะมีการส่งคำสั่งน้อยลงและการออกเอกสารน้อยลงออกจากอุปกรณ์ ตลาดการเงินกำลังติดตาม: การลงทุนในการสร้างโครงสร้างพื้นฐานสำหรับการตีความเพิ่มขึ้นในกลางปี 2026 ซึ่งแสดงให้เห็นว่ามีการลงทุนในกลยุทธ์การเพิ่มประสิทธิภาพการตีความในระดับที่ต่ำกว่า
ข้อโต้แย้ง: การสร้างปริมาณและการบีบอัดอย่างรุนแรงไม่ฟรี การประเมินล่าสุดเกี่ยวกับ GGUF และการสร้างปริมาณหลังการฝึกสอนแสดงให้เห็นว่ามีการลดคุณภาพที่วัดได้ในภาษาและงานที่ต้องใช้ทรัพยากรต่ำ นั่นหมายความว่าโมเดลบนอุปกรณ์เหมาะสำหรับการคัดกรอง การดึงข้อมูล การสรุป และการเตรียมการก่อนทำมัลติมีเดีย แทนที่จะเป็นงานสร้างสรรค์ในรูปแบบยาว
วิธีเลือก LLM ที่ขอบกับคลาวด์
ตัดสินใจโดยสามปัจจัย: ความทนทานต่อเวลาล่าช้า, ความเสี่ยงด้านความเป็นส่วนตัว และความสดใหม่ของโมเดล หากฟีเจอร์ของคุณต้องการเวลาการตอบสนองที่รับรู้ต่ำกว่า 200 มิลลิวินาทีและเกี่ยวข้องกับข้อมูลของผู้ใช้ที่ละเอียดอ่อน ให้จัดลำดับความสำคัญของโมเดลขนาดเล็กบนอุปกรณ์เป็นตัวกรองระยะเริ่มต้น หากคุณต้องการโมเดลการให้เหตุผลล่าสุดหรือหน้าต่างบริบทที่ใหญ่ที่สุด ต้องส่งคำขอที่กรองแล้วไปยังโมเดลในคลาวด์ที่มีหน่วยความจำสภาวะและความยาว
ทีมผลิตภัณฑ์ควรระวังความจริงทางวิศวกรรมสองประการ ประการแรก ความสุกงอมของโครงสร้างพื้นฐาน: รันไทม์ เช่น llama.cpp, Ollama, MLX, และ WebLLM ของเบราว์เซอร์กำลังคงที่ในด้านการนำเข้าโมเดล, การสร้างปริมาณ, และการจัดตาราง ประการที่สอง ต้นทุนของการอัปเดต: การส่งมอบโมเดลบนอุปกรณ์ที่ถูกล็อกแลกกับค่าใช้จ่ายในการทำงานที่ต่ำลงแต่มีอัตราความยุ่งยากในการอัปเดตและรอบของแอปสโตร์ ทั้งคู่สามารถแก้ไขได้แต่จะต้องเป็นส่วนหนึ่งของโรดแมพ
ในการปฏิบัติเราสังเกตเห็นรูปแบบที่พบบ่อย: โมเดลขนาดเล็กบนอุปกรณ์ช่วยลดการเรียกคลาวด์ที่ไม่จำเป็นและลดความล่าช้าสุดท้าย เราสังเกตเห็นรูปแบบอีกแบบหนึ่ง: ทีมที่ปฏิบัติต่อโมเดลบนอุปกรณ์เป็นตัวกรองที่กำหนดได้จะได้รับประสบการณ์ใช้งานที่คาดเดาได้ ปัญหาหนึ่งที่ทีมพบคือการเสื่อมสภาพของการใช้งานภาษาและโดเมนภายใต้การสร้างปริมาณที่มีบิตต่ำมาก ดังนั้นควรวางแผนการแก้ไขไว้
ลองทำด้วยตนเอง
คำสั่งด้านล่างแสดงให้เห็นถึงสองรูปแบบผสมผสานที่คุณสามารถวางลงในรันไทม์โมเดลขนาดเล็กในพื้นที่เพื่อลองทดสอบแนวคิดนี้
คำสั่งนี้คัดกรองว่าผู้ใช้สอบถามต้องการการเรียกคลาวด์หรือไม่ คาดหวังว่าจะได้รับการตอบกลับแบบ JSON ที่ระบุ call_cloud เป็นจริงหรือเท็จและเหตุผลสั้นๆ
คุณเป็นตัวแทนการคัดกรอง ให้เฉพาะข้อความของผู้ใช้ในฟิลด์ "input" ตัดสินใจว่าต้องการ LLM คลาวด์สำหรับการให้เหตุผลในรูปแบบยาวหรือว่าอุปกรณ์สามารถตอบสนองได้ในท้องถิ่น ผลลัพธ์จะต้องเป็น JSON ที่ถูกต้องโดยมีคีย์สามคีย์: call_cloud (true หรือ false), reason (ประโยคสั้นๆ หนึ่งประโยค), และ local_action (คำสั่งหนึ่งบรรทัดที่อุปกรณ์สามารถดำเนินการได้หาก call_cloud เป็น false) ข้อมูลนำเข้า: "{{user_input}}"
คำสั่งนี้ดึงข้อมูลที่มีโครงสร้างจากภาพและคำบรรยายสั้นๆ ซึ่งมีประโยชน์สำหรับตัวแทนมัลติมีเดียบนอุปกรณ์ที่ส่งข้อมูลที่จำเป็นเท่านั้นไปยังคลาวด์
คุณเป็นผู้ดึงข้อมูลภาพบนอุปกรณ์ อธิบายวัตถุหลักในประโยคเดียว จากนั้นส่งกลับวัตถุ JSON โดยมีคีย์: caption, objects (รายการชื่อ), และ sensitive (true หากภาพมี ID ส่วนบุคคล, บัตรเครดิต, หรือข้อมูลส่วนบุคคลอื่นๆ) ใช้เพียงวลีที่กระชับเท่านั้น ภาพ: [แนบข้อมูลภาพ].
ข้อสรุปสำหรับผลิตภัณฑ์: จับคู่โมเดลขนาดเล็กบนอุปกรณ์กับการสำรองข้อมูลในคลาวด์วัดการลดคุณภาพสำหรับภาษาของคุณและงานต่างๆ และจัดสรรรอบการอัปเดตแอปสำหรับการปรับปรุงโมเดล สำหรับกระบวนการที่มีตัวแทน กรุณาเห็นแนวทางของเราเกี่ยวกับตัวแทน AI และความแตกต่างระหว่างนี้กับ chatbot เพื่อรูปแบบการปฏิบัติที่ลึกซึ้งและโหมดการล้มเหลวที่แตกต่างกัน
