การปรับแต่ง LLM บนอุปกรณ์สำหรับ AI Agent บนมือถือ: เร็วขึ้น ประหยัดขึ้น และใช้ได้จริงบน Android

ทำไมคุณภาพ phone agent เริ่มจากความรู้สึกว่าเร็วและควบคุมได้

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

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

Android Developers: Gemini Nano อธิบายว่า Gemini Nano ทำงานผ่าน Android AICore เพื่อรองรับ on-device generative AI, latency ต่ำ, กรณีใช้งานที่ให้ความสำคัญกับข้อมูลส่วนตัว และประสบการณ์ที่ทำงานได้แม้ไม่มีเครือข่ายในเครื่องที่รองรับ ประเด็นนี้สำคัญมากสำหรับ phone agent เพราะงานบางอย่างควรตอบสนองใกล้มือผู้ใช้ก่อน แล้วค่อยส่งต่อสิ่งที่ต้องคิดลึกขึ้นในขั้นถัดไป

ที่ FoneClaw เราวัดคุณค่าจาก action ที่ผู้ใช้เห็นบน Android: เปิดแอปที่ถูกต้อง ร่างข้อความที่ตรวจได้ ตั้ง reminder ที่ปรากฏจริง หรือพาผู้ใช้ไปยังหน้าที่ต้องตัดสินใจ หากต้องการเห็นภาพรวมของการเปลี่ยนเจตนาให้เป็นงานบนมือถือ อ่านเพิ่มได้ที่ AI Agent ควบคุมโทรศัพท์อย่างไร ส่วนบทความนี้จะโฟกัสชั้นที่ทำให้เวิร์กโฟลว์เหล่านั้นเร็วขึ้นและเสถียรขึ้น

ขนาดโมเดล quantization และโมเดลเล็กที่เหมาะกับงานบนมือถือ

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

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

Apple ก็เดินในทิศทางคล้ายกันในระบบของตัวเอง โดย Apple Foundation Models framework เปิดทางให้แอปใช้ on-device language model สำหรับงาน Apple Intelligence, structured output และ tool calling ภายในแอป ขณะที่ Apple foundation models 2025 updates พูดถึงงานเพิ่มประสิทธิภาพอย่าง KV cache sharing, quantization, adapters และการแบ่งงานระหว่างโมเดลบนเครื่องกับโมเดลฝั่ง server

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

AICore, Gemini Nano, ML Kit GenAI, LiteRT และ LiteRT-LM บนเส้นทาง Android

คำว่า “โมเดลอยู่ในเครื่อง” ฟังดูง่าย แต่ในทางปฏิบัติ นักพัฒนาต้องมีทางเรียกใช้โมเดล จัดการความพร้อมของอุปกรณ์ ดาวน์โหลดโมเดล ตรวจโควตา และทำให้คำสั่งตอบสนองในจังหวะที่แอปต้องการ บน Android เส้นทางสำคัญจึงอยู่ที่ runtime และ API ที่ทำให้ local AI และ hybrid AI ใช้ได้จริงในแอป

Google ML Kit GenAI Prompt API ระบุขั้นตอนอย่างการตรวจว่าอุปกรณ์รองรับหรือไม่ การดาวน์โหลด Gemini Nano การ warmup เพื่อลดเวลาหน่วงของการเรียกครั้งแรก รวมถึง token limits และ per-app quota รายละเอียดเหล่านี้ไม่ใช่เรื่องหลังบ้านล้วน ๆ เพราะผู้ใช้จะรู้สึกทันทีเมื่อฟีเจอร์ AI เปิดช้า ใช้ไม่ได้ในเครื่องนั้น หรือถึงโควตาแล้วต้องเปลี่ยนพฤติกรรม

Google AI Edge วางภาพรวมของ on-device ML และ AI ข้ามแพลตฟอร์ม รวมถึง MediaPipe task APIs, LiteRT และ LiteRT-LM ส่วน LiteRT-LM overview แสดงตัวอย่าง local LLM และมิติด้านประสิทธิภาพ เช่น prefill, decode, time to first token, CPU/GPU backends, memory และ offline local model execution

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

KV cache, prefill, decode และ warmup ทำให้เวิร์กโฟลว์ซ้ำ ๆ ลื่นขึ้นอย่างไร

หลายคนรู้สึกว่า AI ช้าหรือเร็วจากวินาทีแรกที่เห็นคำตอบ ไม่ใช่จากเวลารวมทั้งหมด ใน LLM มีช่วงสำคัญอย่าง prefill ซึ่งเป็นการอ่านบริบทตั้งต้น และ decode ซึ่งเป็นการสร้างคำตอบทีละส่วน หากช่วงแรกนานเกินไป ผู้ใช้จะรู้สึกว่าระบบไม่ทันใจ แม้คำตอบสุดท้ายจะดีมากก็ตาม

KV cache ช่วยให้โมเดลไม่ต้องคำนวณบริบทเดิมซ้ำในบางสถานการณ์ โดยเฉพาะเวิร์กโฟลว์ที่มีบริบทต่อเนื่อง เช่น ผู้ใช้ถามต่อจาก notification เดิม หรือทำงานหลายขั้นในแอปเดียวกัน ส่วน warmup คือการเตรียมระบบก่อนเรียกใช้งานจริง เพื่อให้คำสั่งแรกไม่ช้าเกินไป ML Kit GenAI Prompt API ระบุเรื่อง warmup สำหรับลด latency ของการเรียกครั้งแรก ซึ่งเป็นรายละเอียดที่มีผลกับความรู้สึกของผู้ใช้โดยตรง

ใน phone agent เวิร์กโฟลว์ซ้ำ ๆ เกิดตลอดเวลา เช่น “สรุปแจ้งเตือน”, “ร่างตอบกลับ”, “ตั้ง reminder”, “เปิดแอปนี้”, “อ่านสถานะบนหน้าจอ” หากระบบใช้ cache และการเตรียมพร้อมได้ดี ผู้ใช้จะรู้สึกว่าโทรศัพท์เข้าใจลำดับงานเดิมเร็วขึ้น โดยยังต้องรักษาความถูกต้องของข้อมูลล่าสุดและให้ผู้ใช้ตรวจ action สำคัญ

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

เมื่อไรใช้ AI ในเครื่อง และเมื่อไรให้ cloud reasoning ช่วยคิดต่อ

งานบนมือถือมีหลายระดับ บางอย่างเหมาะกับ AI ในเครื่อง เช่น จัดรูปประโยคสั้น สรุปแจ้งเตือนเฉพาะหน้า เลือก action ถัดไป หรือช่วยเปิดแอปที่เกี่ยวข้อง งานเหล่านี้ต้องการความไวและความใกล้กับบริบทโทรศัพท์ ส่วนงานที่ต้องวิเคราะห์ยาว เทียบข้อมูลจำนวนมาก หรือใช้ความรู้ที่กว้างขึ้น อาจเหมาะกับ cloud reasoning มากกว่า

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

เราอธิบายภาพกว้างของการเลือกแนวทางไว้ใน AI Agent แบบ local กับ cloud ส่วนในบทความนี้ ประเด็นอยู่ที่การจัดเส้นทางให้ phone agent รู้ว่าต้องตอบเร็วในเครื่อง ตอนไหนต้องใช้เหตุผลลึกขึ้น และตอนไหนต้องหยุดให้ผู้ใช้ยืนยันก่อนเกิด action สำคัญ

ที่ FoneClaw เราเชื่อมผลลัพธ์เหล่านี้กับ Android actions ที่รองรับ เช่น เปิดแอป ร่างข้อความ ตั้ง reminder หรือพาไปยังหน้าที่ต้องตรวจ เมื่อ local inference ช่วยเตรียมงานได้เร็ว ผู้ใช้ได้ความต่อเนื่อง เมื่อ cloud reasoning ช่วยคิดลึกขึ้น ผู้ใช้ได้คำตอบที่รอบขึ้น จุดสุดท้ายยังกลับมาที่หน้าจอและการยืนยันในมือผู้ใช้

เช็กลิสต์ประเมินฟีเจอร์ on-device LLM บนโทรศัพท์

เวลาฟีเจอร์ AI บนมือถือบอกว่าใช้ LLM ในเครื่อง ให้ประเมินจากประสบการณ์จริงก่อนคำโฆษณา เริ่มจากถามว่าเครื่องรุ่นใดรองรับ ต้องดาวน์โหลดโมเดลเพิ่มหรือไม่ ใช้งานได้ในสถานะไม่มีเครือข่ายแค่ไหน ใช้เวลาตอบครั้งแรกนานเท่าไร และมี quota ต่อแอปหรือข้อจำกัด token อย่างไร

• Device support: ตรวจรุ่น Android, ชิป, RAM, storage และ API ที่ฟีเจอร์ต้องใช้
• Latency: ดูทั้งเวลาคำตอบแรก เวลารวม และความลื่นหลังใช้ซ้ำหลายครั้ง
• Battery และความร้อน: งาน local AI ที่ดีควรใช้งานได้ในชีวิตประจำวันโดยไม่ทำให้เครื่องอึดอัด
• Offline behavior: ดูว่างานใดทำในเครื่องได้ และงานใดรอเครือข่ายหรือเส้นทางอื่น
• Privacy และ permission: ตรวจว่าข้อมูลใดอยู่บนเครื่อง ข้อมูลใดส่งต่อ และผู้ใช้จัดการสิทธิ์ได้ตรงไหน
• Recovery: เมื่อโมเดลยังไม่พร้อม ดาวน์โหลดไม่ครบ หรือถึง quota ระบบควรพาผู้ใช้ไปทางเลือกที่เข้าใจง่าย
• Visible action: สำหรับ phone agent ให้ดูว่า AI พาไปสู่แอป ข้อความ reminder หรือขั้นตอนบนหน้าจอที่ตรวจได้จริงหรือไม่

มุมมองระบบปฏิบัติการและชั้นต่าง ๆ ของ agent มีรายละเอียดแยกใน รากฐานสามชั้นของ OS Agent แต่สำหรับผู้ใช้ FoneClaw สิ่งสำคัญคือฟีเจอร์ AI ต้องลดแรงเสียดทานของงานบน Android ได้จริง ไม่ใช่เพิ่มหน้าจอใหม่ให้ต้องจัดการ

สรุปสั้น ๆ: on-device LLM optimization มีคุณค่าเมื่อมันทำให้ phone agent ตอบเร็วขึ้น ใช้แบตเหมาะสม เคารพบริบทของผู้ใช้ และพาไปสู่ action ที่มองเห็นได้บน Android ที่ FoneClaw เรานำหลักนี้มาใช้กับเวิร์กโฟลว์ที่รองรับ เพื่อให้เสียง เจตนา และการกระทำบนมือถือเดินต่อกันอย่างเป็นธรรมชาติ