MobileLLM: การเพิ่มประสิทธิภาพโมเดลภาษาขนาดต่ำกว่าพันล้านพารามิเตอร์สำหรับกรณีใช้งานบนอุปกรณ์

 (github.com/facebookresearch)
3 คะแนน โดย GN⁺ 2024-07-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คลัง MobileLLM มีโค้ดฝึกจากงานวิจัย ICML 2024 เรื่อง “MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases” และกล่าวถึงการออกแบบเพื่อยกระดับคุณภาพของโมเดลภาษาที่มีพารามิเตอร์ต่ำกว่า 1 พันล้าน
  • การออกแบบโมเดลผสาน SwiGLU, โครงสร้างที่ลึกและแคบ, การแชร์ embedding และ grouped-query attention เพื่อสร้าง MobileLLM
  • MobileLLM-125M/350M ทำได้ดีกว่าโมเดล SoTA เดิมขนาด 125M/350M ในงานให้เหตุผลเชิงสามัญสำนึกแบบ zero-shot โดยมี ความแม่นยำเพิ่มขึ้น 2.7%/4.3% ตามลำดับ และเวอร์ชันอัปเดตยังแสดงผลลัพธ์ระดับ SoTA ในขนาด 600M/1B/1.5B
  • โค้ดฝึกต้องใช้ Python 3.9 และ PyTorch 2.0 ขึ้นไป โดย pretrain.sh เริ่มผ่าน torchrun บน โหนด 1x8 GPU และหากเพิ่มจำนวนโหนดหรือขนาดแบตช์ต้องเพิ่ม learning rate แบบเชิงเส้น
  • ต้นทุนการฝึกที่อิง 1T โทเค็นบน GPU NVIDIA A100 80G จำนวน 32 ตัว ใช้เวลาประมาณ 3 วันสำหรับ 125M, 6 วันสำหรับ 350M, 8 วันสำหรับ 600M, 12 วันสำหรับ 1B และ 18 วันสำหรับ 1.5B

เป้าหมายและขอบเขตการเผยแพร่ของ MobileLLM

  • MobileLLM เป็นคลังที่เก็บโค้ดฝึกสำหรับการเพิ่มประสิทธิภาพ โมเดลภาษาขนาดต่ำกว่าพันล้านพารามิเตอร์ สำหรับกรณีใช้งานบนอุปกรณ์
  • งานวิจัยต้นฉบับคือ MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases และได้รับการตีพิมพ์ใน ICML 2024
  • เป้าหมายหลักคือการพิจารณาองค์ประกอบการออกแบบหลายด้านร่วมกัน เพื่อสร้าง LLM คุณภาพสูงแม้มีพารามิเตอร์ต่ำกว่า 1 พันล้าน

องค์ประกอบการออกแบบโมเดล

  • MobileLLM ผสานองค์ประกอบการออกแบบต่อไปนี้
    • ฟังก์ชันกระตุ้น SwiGLU
    • สถาปัตยกรรม แบบลึกและแคบ

    • การแชร์ embedding

      • grouped-query attention
      • ในเวอร์ชันอัปเดตระบุว่าแนวคิดการออกแบบนี้ขยายไปยังโมเดลขนาดใหญ่ขึ้นได้ด้วย และแสดงผลลัพธ์ระดับ SoTA ใน MobileLLM-600M/1B/1.5B

ข่าวการเผยแพร่และโมเดลต่อยอด

  • วันที่ 30 ตุลาคม 2024 โมเดล MobileLLM ถูกเผยแพร่บน HuggingFace
  • เดือนกันยายน 2025 มีการเผยแพร่งานต่อยอด MobileLLM-R1
    • ด้วยโทเค็น pretraining ราว 2T และรวมทั้งหมดน้อยกว่า 5T โทเค็น ทำผลลัพธ์บน MATH, GSM8K, MMLU และ LiveCodeBench ได้ทัดเทียมหรือดีกว่าผลลัพธ์ของ Qwen3-0.6B ที่ใช้ 36T โทเค็น
    • มีการเปิดเผยโค้ด, โมเดล, ข้อมูล และสูตรการฝึก
    • มีคอลเลกชัน HuggingFace
  • เดือนพฤศจิกายน 2025 มีการเผยแพร่ MobileLLM-R1.5
    • MobileLLM-R1.5-950M เหนือกว่า DeepSeek-R1-Distill-Qwen-1.5B ในทุกเบนช์มาร์กคณิตศาสตร์และการเขียนโค้ดที่มีการประเมิน
    • จำนวนพารามิเตอร์น้อยกว่า คือ 0.95B เทียบกับ 1.5B
  • เดือนมกราคม 2026 MobileLLM-R1 ได้รับการตอบรับเข้า ICLR 2026

การรันและการตั้งค่าการฝึก

  • ข้อกำหนดคือ Python 3.9, PyTorch 2.0 ขึ้นไป, และ pip install -r requirement.txt
  • การเตรียมข้อมูลใช้วิธีแบ่งชุดข้อมูลที่ tokenize แล้ว หรือ tokenize ชุดข้อมูลของตนเอง จากนั้นกระจายตามจำนวนโหนดฝึกทั้งหมด
    • แต่ละโหนดประกอบด้วย 1x8 GPU
    • โครงสร้างข้อมูลเป็นการวางไฟล์ xxx.jsonl ไว้ใต้ basepath/1, basepath/2, ..., basepath/#nodes
    • แต่ละบรรทัดของ jsonl เป็นคู่คีย์-ค่าของข้อมูลที่ tokenize แล้วในรูปแบบ {"token_ids": [1,2,3,4,...]}
    • โค้ดฝึกเข้ากันได้กับวิธีเตรียมข้อมูลของ LLM360/amber-data-prep
  • pretrain.sh เป็นสคริปต์ที่เริ่มการฝึกด้วย torchrun ในการตั้งค่า โหนด 1x8
    • สามารถแก้ --nnodes และการตั้งค่าอื่นเพื่อให้เหมาะกับการตั้งค่าแบบหลายโหนด เช่น Slurm หรือ TorchX
    • learning rate ในสคริปต์อ้างอิงการตั้งค่าโหนด 1x8 และขนาดแบตช์ 32
    • หากเพิ่มจำนวนโหนดหรือขนาดแบตช์ ต้องเพิ่ม learning rate แบบเชิงเส้น
  • ขั้นตอนการรันคือกำหนด --train_data_local_path ใน pretrain.sh ให้ชี้ไปยังข้อมูลที่เตรียมไว้ กำหนด --input_model_filename เป็น ./configs/{model_size}/ แล้วรัน bash pretrain.sh
  • การประเมิน Wiki ทำได้โดยดาวน์โหลดโมเดล อัปเดตพาธ checkpoint ใน eval.sh แล้วรัน bash eval.sh

ต้นทุนการฝึก

  • เมื่อฝึก MobileLLM ด้วย 1T โทเค็น เวลาที่ใช้บน NVIDIA A100 80G GPU จำนวน 32 ตัวมีดังนี้
    • 125M: ประมาณ 3 วัน
    • 350M: ประมาณ 6 วัน
    • 600M: ประมาณ 8 วัน
    • 1B: ประมาณ 12 วัน
    • 1.5B: ประมาณ 18 วัน

ผลลัพธ์ zero-shot ด้านการให้เหตุผลเชิงสามัญสำนึก

  • MobileLLM-125M ทำคะแนนเฉลี่ย 46.3 บน arc_easy, arc_challenge, boolq, piqa, siqa, hellaswag, obqa, winogrande
    • OPT-125M ได้ 42.6, GPT-neo-125M ได้ 42.9, Pythia-160M ได้ 42.5
    • MobileLLM-LS-125M ได้ค่าเฉลี่ย 47.0
  • MobileLLM-350M ทำคะแนนเฉลี่ย 51.3
    • OPT-350M ได้ 43.9, Pythia-410M ได้ 46.6
    • MobileLLM-LS-350M ได้ค่าเฉลี่ย 52.1
  • MobileLLM-600M ทำคะแนนเฉลี่ย 54.3
    • Qwen1.5-500M ได้ 48.8, BLOOM-560M ได้ 44.2, MobiLlama-800M ได้ 50.7
  • MobileLLM-1B ทำคะแนนเฉลี่ย 57.3
    • Pythia-1B ได้ 48.7, MobiLlama-1B ได้ 55.2, Falcon-1B ได้ 56.3, BLOOM-1.1B ได้ 46.9, TinyLlama-1.1B ได้ 54.2
  • MobileLLM-1.5B ทำคะแนนเฉลี่ย 59.4
    • GPT-neo-1.3B ได้ 50.6, OPT-1.3B ได้ 52.3, BLOOM-1.7B ได้ 49.6, Qwen1.5-1.8B ได้ 56.5
    • GPT-neo-2.7B ได้ 52.8, OPT-2.7B ได้ 55.1, Pythia-2.8B ได้ 55.8, BLOOM-3B ได้ 52.3

โปรเจกต์ที่เกี่ยวข้องและไลเซนส์

  • โค้ดอ้างอิงบางส่วนจากคลัง HuggingFace Transformers และคลังดังกล่าวใช้ Apache License
  • มีการระบุโปรเจกต์ที่เกี่ยวข้องดังนี้
    • SpinQuant: LLM Quantization with Learned Rotations, ICLR 2025 — Paper, Code
    • LLM-QAT: Data-Free Quantization Aware Training for Large Language Models — Paper, Code
  • ขั้นถัดไปมีการระบุ MobileLLM-R1 และโมเดล MobileLLM-R1.5
  • ปัจจุบัน MobileLLM ใช้ FAIR NC License

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-11
ความคิดเห็นจาก Hacker News

  • โมเดลขนาดเล็ก ดีขึ้นเล็กน้อย แต่ยังดูไม่พอสำหรับใช้ในงานแบบเดียวกับโมเดลออนไลน์ ถึงอย่างนั้น การพัฒนาแบบค่อยเป็นค่อยไปเองก็ถือว่าโอเค
    โมเดล 1.5 พันล้านพารามิเตอร์ ดูเหมือนเป็นก้าวกระโดดที่ค่อนข้างใหญ่ และยังชนะโมเดลที่ใหญ่กว่าด้วยส่วนต่างมาก ไม่รู้ว่าทำไมถึงไม่ทำให้ใหญ่กว่านี้ โมเดลที่มีประสิทธิภาพกว่านี้ซึ่งใส่ลงในฮาร์ดแวร์ระดับ Raspberry Pi ได้อาจเปลี่ยนเกมได้เลย เท่าที่จำได้ TinyLlama 7B ก็แค่พอรันได้เท่านั้น

    • โมเดลภาษาที่เล็กกว่านี้ก็น่าจะมีประโยชน์ในฐานะส่วนหนึ่งของระบบ รู้จำเสียงพูด ได้เช่นกัน ในสถานการณ์ที่คลุมเครือหรือมีเสียงรบกวน โมเดลภาษาสามารถช่วยตีวงให้แคบลงได้ว่าคำไหนถูกพูดออกมา
    • ลองจินตนาการว่าโมเดลแบบนี้ถูกฝังไว้ในแอป Instagram และใช้การประมวลผลบนเครื่องผู้ใช้เพื่อ กำหนดเป้าหมายโฆษณา แบบนั้น Facebook ก็จะมองเห็นข้อมูลได้มากขึ้นมาก ด้วยต้นทุนที่ต่ำกว่าและความเสี่ยงจากคดีความที่ต่ำกว่ามาก
      สำหรับกรณีใช้งานนี้ การเปรียบเทียบโมเดลเล็กกับโมเดลบนคลาวด์ไม่ค่อยยุติธรรม ความแม่นยำของโมเดลเล็กที่เพิ่มขึ้นแม้เพียงเล็กน้อยก็มีความหมาย และอาจแปลงเป็นรายได้ได้ทันที
    • ไม่แน่ใจว่า Raspberry Pi เป็นเป้าหมายที่เหมาะสำหรับ LLM โลคัลขั้นถัดไปหรือไม่ และการเผยแพร่ผ่านเว็บโดยใช้เอนจินอย่าง WebLLM ก็น่าพิจารณาเช่นกัน https://github.com/mlc-ai/web-llm
      แม้โมเดล 7B จะ “รันได้ดี” บน Raspberry Pi แต่โดยส่วนตัวแล้ว โมเดล 7B ค่อนข้างใหญ่ไปหน่อยสำหรับการดาวน์โหลดและรันในอินเทอร์เฟซบนเว็บ ในทางกลับกัน โมเดล 125M ที่พอใช้ได้สามารถรันบนเว็บเพจได้ และเวลาในการดาวน์โหลดไปยังเบราว์เซอร์โลคัลกับต้นทุนแบนด์วิดท์ก็ไม่มากเกินไป
    • Llama-3-8b รันได้ดีบน Raspberry Pi

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

    • บทสนทนานั้นจะน่าสนใจจริงไหม? ปริมาณบทสนทนาอาจเพิ่มขึ้นได้ แต่สงสัยว่าจะมีฐานอะไรให้ผู้เล่นรู้สึกสนใจหรือเปล่า เช่น ชาวบ้านอาจพูดถึงทิวทัศน์ท้องถิ่นหรือความสัมพันธ์กับ NPC อื่น ๆ ได้ แต่สิ่งที่พวกเขาอธิบายอาจไม่ได้มีอยู่จริงในเกม โดยส่วนตัวแล้ว ถ้า NPC เริ่มแต่งเรื่องสิ่งที่ไม่มีอยู่ขึ้นมา คงรู้สึกแปลก ๆ
      พอนึกภาพได้ว่าจะฝึก LLM ด้วยข้อมูลเกมเพื่อให้ NPC อธิบายโลกของเกมจริง ๆ แต่ไม่รู้ว่าต้องมีขนาดระดับไหนถึงจะถูกกว่าการให้คนเขียนบทพูด ถ้าเป็นระดับ Ubisoft อาจเป็นไปได้ เท่าที่รู้ Ubisoft ก็ศึกษาการเขียนด้วย AI มาเหมือนกัน แต่ส่วนใหญ่เป็นการใช้งานที่ซ้ำมาก ๆ และแทบเหมือนเสียงรบกวน เช่น เสียงตะโกนระหว่างต่อสู้
    • ถ้า NPC มี เรื่องราวเบื้องหลัง มากขึ้นและมีพฤติกรรมซับซ้อนขึ้นก็น่าจะน่าสนใจ อย่างไรก็ดี อะไรก็อาจส่งผลต่อพฤติกรรมได้ ดังนั้นการทดสอบคงแทบเป็นไปไม่ได้

  • ตอนนี้มีแอปอะไรบ้างที่รันโมเดลแบบนี้บน iPhone ได้? ที่รู้จักมีแค่ MLC แต่ในนั้นมีแค่โมเดลเก่า 3 ตัว

    • APK Android ของ MLC อัปเดตบ่อยพร้อมโมเดลรุ่นใหม่ที่ฝังมาให้ บน Samsung S24+ สามารถรัน โมเดล 7~8B ได้สบาย ๆ ด้วยความเร็วสมเหตุสมผล ประมาณ 10 โทเคนต่อวินาที
      https://llm.mlc.ai/docs/deploy/android.html
    • ได้อัปโหลด แอปที่ใช้ mlc-llm ขึ้น App Store แล้ว และรองรับโมเดลมากกว่า 20 ตัว รวมถึงโมเดลรุ่นใหม่ ๆ
    • cnvrs รัน GGUF บน iOS: https://testflight.apple.com/join/ERFxInZg
    • โมเดล MLC ก็มีอยู่ที่นี่ด้วย: https://huggingface.co/mlc-ai

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

    • งานวิจัยอีกชิ้นของ Meta FAIR ชี้ว่า หากต้องการเพิ่มประสิทธิภาพโดยยังรักษาความแม่นยำไว้ กลับต้อง ตัดแต่งเลเยอร์ลึก ๆ ออก https://arxiv.org/html/2403.17887v1
      ถ้าอย่างนั้นก็น่าจะมีขีดจำกัดของเครือข่ายขนาดเล็กที่แนวทางนี้ใช้ได้ ไม่เช่นนั้นผลลัพธ์ก็ขัดแย้งกัน หรือไม่ก็อาจหมายความว่าโมเดลใหม่เหล่านี้ยังปรับปรุงได้อีกมาก
    • นึกถึงผลลัพธ์จาก论文 EfficientT5 ของ Google https://arxiv.org/abs/2109.10686 ที่นั่นเรียกสิ่งนี้ว่า “DeepNarrow”

  • ไม่รู้ว่าผมพลาดอะไรไปหรือเปล่า แต่สิ่งอย่าง การกลั่นความรู้ ไม่ช่วยตรงนี้หรือ?

    • ใน论文บอกว่าได้ลองทำแล้ว: https://arxiv.org/abs/2402.14905
      ดีปลิงก์ HTML ของส่วนที่เกี่ยวข้อง: https://ar5iv.labs.arxiv.org/html/2402.14905#S3.SS5
      “จนถึงตอนนี้ เราฝึกโมเดลขนาดเล็กตั้งแต่ต้นโดยใช้โทเคนถัดไปเป็นฮาร์ดเลเบล เรายังสำรวจการกลั่นความรู้ (KD) ด้วย... น่าเสียดายที่ KD ทำให้เวลาในการฝึกเพิ่มขึ้น (ช้าลง 2.6~3.2 เท่า) และให้ความแม่นยำใกล้เคียงหรือ ต่ำกว่าการฝึกแบบใช้เลเบล (รายละเอียดเพิ่มเติมอยู่ในภาคผนวก)”

  • ตอนนี้ต้องการ การรู้จำเสียงพูดแบบคล้าย wake-word บนอุปกรณ์จริง ๆ โมเดลไหนที่รันบน Raspberry Pi 4B ได้และมี WER ต่ำที่สุด? กำลังดู openWakeWord สำหรับระบบสต็อกสินค้าแบบ DIY

  • โมเดลขนาดเล็กดูเหมือนจะลดขนาดได้มากที่สุดด้วย การใช้ embedding ร่วมกัน/การผูกน้ำหนัก ระหว่าง linear head กับ token embedding เลยสงสัยว่ามีงานวิจัยที่กำลังลดขนาดจากจุดนั้นต่อไปอีกหรือไม่

    • ถ้าหมายถึงว่า LM-head เป็นแค่เมทริกซ์ embedding ที่กลับด้าน นั่นก็เป็นสิ่งที่ทำกันมาตั้งแต่ GPT-2 แล้ว
      น่าเสียดายที่สิ่งที่เจอเกี่ยวกับเรื่องนี้มีแค่ประมาณว่าโมเดลขนาดใหญ่ได้ประโยชน์จากเลเยอร์แยกต่างหากเท่านั้น แต่ก็เป็นคำพูดที่เห็นจากที่ไหนสักแห่งใน Discord จึงไม่มีเปเปอร์ให้อ่าน และตามสัญชาตญาณส่วนตัว ผมคิดว่ามันควรจะใช้ได้กับโมเดลใหญ่ด้วยอยู่ดี สุดท้าย GPT-3 ก็เป็นการขยาย GPT-2 ขึ้นมา
      จากการทดลองส่วนตัว เมื่อให้โจทย์ที่ยากขึ้นกับโมเดล มันเรียนรู้ได้ดีกว่า น้ำหนักที่ถูกผูกกันอาจเป็นหนึ่งในนั้น การทำนายหลายโทเคนก็อาจใช่ และ bitnet ก็อาจมองแบบนั้นได้ dropout ก็เช่นกัน

  • ถ้าไม่ใช่ generative AI บนเดสก์ท็อป แต่เป็นแค่ เดสก์ท็อป AI ล่ะ ให้มันจัดระเบียบไฟล์ อีเมล โน้ตทั้งหมดของฉัน และค้นข้อมูลจากข้อมูลของฉันได้ก็น่าจะดี

  • ดีเลย แล้วใช้สิ่งนี้กับการฝึก โมเดลสำหรับ Windows PC ได้ไหม? RAM ไม่ได้เยอะนัก

    • การฝึกโมเดลไม่ได้ขึ้นกับระบบปฏิบัติการ RAM ขึ้นกับขนาด และผมคิดว่าขนาดประมาณนี้จะทำให้ fine-tuning ด้วย GPU RAM ที่น้อยลงทำได้ง่ายขึ้นมาก
      ถึงอย่างนั้น เป้าหมายสุดท้ายน่าจะเป็นการดาวน์โหลดโมเดลแบบนี้มาใช้ หรือจ่ายค่าทำ fine-tuning แล้วรับมาใช้ผ่านชิป neural network ที่ปรับแต่งมาโดยเฉพาะมากกว่า
      ตอนนี้เป็นเรื่องว่าเมื่อไรจะไปถึงจุดนั้นมากกว่า การรับรอง Windows รุ่นล่าสุดก็เริ่มต้องการชิป neural network บางประเภทแล้ว และ Google Pixel 8 Pro ของผมก็โฮสต์โมเดลขนาดเล็กได้ Pixel ไม่ใช่มือถือราคาถูกก็จริง แต่โปรเซสเซอร์เสริมแบบนี้น่าจะถูกกว่า GPU ขนาดใหญ่มาก

  • น่าสนใจอยู่ แต่สงสัยว่าเอาไปใช้อะไรได้บ้างนอกจาก autocomplete ที่ดีขึ้น

    • น่าจะ fine-tune ให้เหมาะกับงานเฉพาะขอบเขตแคบ ๆ แบบ tiny-agent ได้ https://bair.berkeley.edu/blog/2024/05/29/tiny-agent/
      ผมชอบแนวทางที่ดูเหมือน Apple กำลังไป งานประจำวันให้โมเดลเล็กที่ fine-tune แล้วจัดการ ส่วนสิ่งที่มันจัดการได้ไม่มั่นใจค่อยส่งต่อไปยังโมเดลใหญ่ที่อยู่นอกอุปกรณ์ น่าจะสร้างชุดฝึกที่รวมตัวอย่างคำตอบที่ควรมีความเชื่อมั่นต่ำ แล้วเพิ่มเอาต์พุตที่เทียบได้กับ “ขอความช่วยเหลือ” เพื่อฝึกให้มันเลือกตัวเลือกนั้นได้ ถ้าเป็นโมเดลเล็กก็อาจรันหลายตัวแบบขนาน แล้วให้อีกโมเดลหนึ่ง route คำขอไปยังผู้เชี่ยวชาญที่เหมาะสมได้ด้วย
    • อย่างการอ่านอีเมล ตอบอีเมล นัดหมาย ใช้ API ของบริการต่าง ๆ
      โดยพื้นฐานคือทุกงานที่ต้องการการกระทำ ไม่ใช่ความรู้ เช่นถ้าพูดว่า “บอกภรรยาว่าฉันจะไปสาย” ก็ให้มันคุยกับบริการบางอย่างด้วยวิธีมหัศจรรย์ที่ตั้งค่าไว้แล้วจัดการให้
      Siri ทำ home automation ได้ค่อนข้างดีแม้ไม่มีอินเทอร์เน็ต แต่ Google Assistant รุ่นก่อน ๆ กับ Alexa ไม่เป็นแบบนั้นเลย และดูเหมือนไม่เคยทำแบบออฟไลน์ได้ สิ่งนี้ทำให้ผู้ช่วยที่ทำงานแบบ local-first ได้ดีเป็นไปได้
    • เอเจนต์ในเครื่อง แบบ Siri สามารถจัดการงานง่าย ๆ และ route คำขอที่ซับซ้อนกว่าได้
    • สามารถ fine-tune ให้เหมาะกับงานที่เกี่ยวกับอุปกรณ์ได้ กล่าวอีกอย่างคือโมเดลเล็กก็สามารถใช้ฟังก์ชันทั้งหมดที่แอปพลิเคชันหรือบริการบนอุปกรณ์มีได้ในทางปฏิบัติ
      มันสามารถส่งคำขอของผู้ใช้ในรูปภาษาธรรมชาติไปยังแอปพลิเคชันนั้น ๆ และประสานงานระหว่างแอปต่าง ๆ ได้ คำขอที่เกินความสามารถของอุปกรณ์ก็ส่งไปยังโมเดลบนคลาวด์ได้ วิธีนี้ทรงพลังเพราะสามารถเปลี่ยนวิธีที่เราโต้ตอบกับอุปกรณ์ได้
    • ผมลองทดสอบ Google AI บนมือถือ โดยเปิดเบราว์เซอร์ไว้แล้วขอให้มันอ่านข้อความในหน้าเว็บให้ฟัง แต่มันตอบว่าเข้าถึงอินเทอร์เน็ตไม่ได้
      ผู้ช่วย AI ที่ต้องการคือ 1) เข้าใจภาษาอังกฤษและภาษาแม่ของผม 2) รู้ว่าตัวเองกำลังทำงานอยู่บน Android หรือ KDE/Linux และเข้าใจคำสั่งอย่าง “เปิดส่วนแอปพลิเคชันในการตั้งค่า Android ให้หน่อย”, “อ่านข้อความในหน้าเว็บที่เปิดอยู่ในเบราว์เซอร์ให้หน่อย”, “อ่านข้อความในป๊อปอัปที่เปิดอยู่ตอนนี้ให้หน่อย” พร้อมทั้งต้องผสานกับระบบปฏิบัติการผ่าน API สาธารณะ บริษัท AI รายใหญ่สามารถแข่งขันกันได้ด้วยการขายผู้ช่วยที่ดีกว่า โดยเฉพาะสำหรับผู้ใช้หลายภาษา
      3) โมเดลต้องเล็ก และไม่จำเป็นต้องรู้ความรู้เรื่องภูมิศาสตร์ ประวัติศาสตร์ หรือวงดนตรีก็ได้ แค่มีตัวเลือกส่งต่องานที่ผู้ใช้ถามไปยังเสิร์ชเอนจินหรือ LLM ออนไลน์ก็พอ