Edge AI คือแนวทางในการรันโมเดล AI บนตัวอุปกรณ์ (เช่น สมาร์ทโฟน, พีซี, กล้อง, อุปกรณ์อุตสาหกรรม) แทนที่จะรันบนคลาวด์ โดยในกลุ่มนี้ การรัน Large Language Model (LLM) บนอุปกรณ์โดยตรงเรียกว่า On-device LLM สำหรับงานที่มีข้อจำกัด 3 ประการ ได้แก่ "ความหน่วงต่ำ (Low Latency)", "ไม่อนุญาตให้นำข้อมูลออกนอกองค์กร (Data Residency)", และ "การเชื่อมต่อเครือข่ายไม่เสถียร" ซึ่งเป็นสิ่งที่ Cloud LLM ทำได้ยาก Edge AI กำลังกลายเป็นตัวเลือกแรกที่ใช้งานได้จริง

บทความนี้จะสรุปตั้งแต่แนวคิดพื้นฐานของ Edge AI และ On-device LLM ความแตกต่างจาก Cloud LLM กรอบการตัดสินใจเมื่อนำไปประยุกต์ใช้ในงานธุรกิจ ไปจนถึงกระบวนการติดตั้ง เพื่อให้แผนกสารสนเทศและผู้รับผิดชอบด้าน DX ที่กำลังพิจารณาการใช้ AI ในองค์กรได้เข้าใจ เมื่ออ่านจบ คุณจะสามารถแยกแยะได้ว่างานของบริษัทควรเลือกใช้ฝั่ง Edge, ฝั่ง Cloud ก็เพียงพอแล้ว หรือควรใช้แบบไฮบริด

Edge AI คือแนวคิดการออกแบบที่เน้น "การประมวลผล AI ในจุดที่ข้อมูลถูกสร้างขึ้นโดยตรง" เมื่อเปรียบเทียบกับ AI ที่ต้องอาศัยการส่งข้อมูลไปยัง Cloud แล้ว Edge AI จะแสดงพฤติกรรมที่แตกต่างกันอย่างสิ้นเชิงใน 3 ด้านหลัก ได้แก่ Latency, ค่าใช้จ่ายด้านการสื่อสาร (Communication Cost) และความเป็นส่วนตัว (Privacy)

ในส่วนนี้ เราจะมาจัดระเบียบความสัมพันธ์ระหว่างคำศัพท์ 2 คำ คือ Edge AI และ On-device LLM พร้อมทั้งระบุตำแหน่งของทั้งคู่ให้ชัดเจนเมื่อเทียบกับ Cloud LLM การมีแผนผังแนวคิดไว้ก่อนที่จะเข้าสู่รายละเอียดทางเทคนิค จะช่วยให้เข้าใจเกณฑ์การตัดสินใจเลือกใช้งานที่จะกล่าวถึงในบทต่อๆ ไปได้ง่ายขึ้น

エッジAI คือแนวคิดที่รวมเอา Edge Computing (การออกแบบที่ประมวลผลใกล้กับแหล่งกำเนิดข้อมูล) เข้ากับ AI โดยดำเนินการอนุมาน (Inference) บนอุปกรณ์ปลายทาง อุปกรณ์หน้างาน หรืออุปกรณ์เกตเวย์ แทนที่จะทำบนคลาวด์ ตัวอย่างทั่วไปของ Edge AI ได้แก่ ระบบจดจำใบหน้าในสมาร์ทโฟน กล้องตรวจสอบสินค้าในโรงงาน และระบบตรวจจับพฤติกรรมเสี่ยงในกล้องติดรถยนต์

ในบรรดาเทคโนโลยีเหล่านี้ การนำ Large Language Model (LLM) ซึ่งเป็นตัวขับเคลื่อนกระแส Generative AI มาทำงานบนอุปกรณ์ (On-device) คือสิ่งที่เรียกว่า On-device LLM เดิมที LLM ถูกออกแบบมาให้ทำงานบนคลัสเตอร์ GPU ขนาดใหญ่บนคลาวด์ แต่ด้วยการพัฒนาของเทคโนโลยีการบีบอัดโมเดล (Quantization) และโมเดลขนาดเล็ก (SLM: Small Language Model) ประกอบกับประสิทธิภาพที่สูงขึ้นของ NPU (Neural Processing Unit) ที่ติดตั้งในสมาร์ทโฟนและโน้ตบุ๊ก ทำให้ปัจจุบันสามารถรันโมเดลที่มีพารามิเตอร์หลายพันล้านตัวบนอุปกรณ์ที่อยู่ในมือได้แล้ว

แม้ว่า "ローカルLLM" (Local LLM) และ "On-device LLM" จะเป็นแนวคิดที่มีส่วนคาบเกี่ยวกันมาก แต่ในบทความนี้จะแยกทั้งสองคำออกจากกัน โดย Local LLM จะมีความหมายกว้างกว่า คือการรัน LLM บนโครงสร้างพื้นฐานที่บริษัทบริหารจัดการเอง (เช่น เซิร์ฟเวอร์ On-premise หรือเครื่อง GPU ภายในบริษัท) ส่วน On-device LLM จะหมายถึงการรันบนอุปกรณ์ที่ผู้ใช้ถืออยู่หรืออุปกรณ์หน้างานโดยตรง สำหรับการเปรียบเทียบรายละเอียดของ Local LLM ฝั่งเซิร์ฟเวอร์ สามารถดูได้ที่ การเปรียบเทียบการนำ Local LLM / SLM มาใช้งาน ดังนั้นบทความนี้จะมุ่งเน้นไปที่การตัดสินใจออกแบบในเชิง Edge เป็นหลัก

แม้ว่า Cloud LLM และ Edge AI (On-device LLM) จะมีจุดประสงค์ในการ "ใช้โมเดลภาษา" เหมือนกัน แต่ทิศทางการไหลของข้อมูลและที่ตั้งของโครงสร้างพื้นฐานนั้นแตกต่างกันโดยสิ้นเชิง

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

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

การอภิปรายเรื่อง Edge AI มีมานานแล้ว แต่ในช่วง 1-2 ปีที่ผ่านมา สถานการณ์ได้เปลี่ยนไปจนสามารถกล่าวได้ว่า "On-device LLM ได้กลายเป็นทางออกที่ใช้งานได้จริงในเชิงธุรกิจ" โดยมีปัจจัยเบื้องหลังจากการเปลี่ยนแปลงเชิงโครงสร้าง 2 ประการ

ประการแรก คือการแพร่หลายของ Cloud LLM อย่างเต็มรูปแบบ ทำให้บริษัทจำนวนมากขึ้นหันมาประเมินเรื่อง "ต้นทุน ความหน่วง (Latency) และความเป็นส่วนตัว" ใหม่ในมุมมองของการดำเนินธุรกิจ ประการที่สอง คือความก้าวหน้าของการทำ Quantization และโมเดลขนาดเล็ก (Small Models) ทำให้การประมวลผลที่เมื่อไม่กี่ปีก่อนต้องใช้เซิร์ฟเวอร์ประสิทธิภาพสูง สามารถทำงานได้บนแล็ปท็อปและสมาร์ทโฟนที่มีวางจำหน่ายทั่วไปในปัจจุบัน

ยิ่งบริษัทนำ Cloud LLM มาใช้ในงานมากเท่าไร ก็ยิ่งมีโอกาสเผชิญกับ "กำแพงที่คาดไม่ถึง" หลังเริ่มใช้งานจริงได้ง่ายขึ้นเท่านั้น ซึ่งในหลายกรณี ปัญหามักจะมาจากเรื่องต้นทุน (Cost), ความหน่วง (Latency), หรือความเป็นส่วนตัว (Privacy) อย่างใดอย่างหนึ่ง หรือรวมกันหลายปัจจัย

ต้นทุน (Cost): แชทบอทภายในองค์กรหรือระบบสรุปข้อมูลแบบแบตช์ แม้ในช่วง PoC อาจมีค่าใช้จ่ายเพียงหลักหมื่นเยนต่อเดือน แต่เมื่อขยายผลไปสู่พนักงานระดับ 1,000 คน และมีการใช้งานในรูปแบบที่ต้องส่งบันทึกข้อมูลทั้งหมดเข้าไปในโมเดลทุกครั้ง ค่าใช้จ่ายตามจำนวน Token อาจพุ่งสูงขึ้นอย่างรวดเร็ว สำหรับฝ่ายบัญชีที่ต้องการให้ค่าใช้จ่ายเป็นต้นทุนคงที่ การที่ค่า API เรียกเก็บเงินกระโดดขึ้นถึง 5 เท่าในบางเดือนถือเป็นปัญหาหนักใจในการบริหารจัดการงบประมาณ สามารถดูรายละเอียดวิธีการเพิ่มประสิทธิภาพต้นทุน LLM โดยรวมได้ที่ คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM

ความหน่วง (Latency): Cloud API มีภาระงานส่วนเกิน (Overhead) จากการรับส่งข้อมูลผ่านเครือข่าย การรอคิว และการประมวลผลแบบแบตช์ที่ฝั่งเซิร์ฟเวอร์ หากเป็นการใช้งานที่รองรับความล่าช้าในระดับวินาทีได้ก็อาจไม่มีปัญหา แต่สำหรับการใช้งานที่ต้องการความเร็วสูง เช่น "การตรวจจับทันทีที่คนปรากฏในกล้อง" หรือ "การตรวจจับเสียงผิดปกติในสายการผลิตแบบเรียลไทม์" ความล่าช้าเพียงไม่กี่ร้อยมิลลิวินาทีอาจส่งผลกระทบอย่างร้ายแรงต่อการดำเนินงาน

ความเป็นส่วนตัว / อธิปไตยของข้อมูล (Privacy / Data Sovereignty): ข้อมูลหลายประเภท เช่น เวชระเบียนผู้ป่วย, เอกสารสินเชื่อ, แบบแปลนการออกแบบ หรือภาพจากไซต์งานก่อสร้างที่กำลังดำเนินการอยู่ มีข้อจำกัดทางกฎระเบียบ สัญญา หรือกฎหมายที่ห้ามส่งข้อมูลออกภายนอก การใช้เพียงการเข้ารหัสหรือสัญญาเรื่องภูมิภาค (Region) ของผู้ให้บริการคลาวด์ อาจไม่เพียงพอที่จะทำให้ผู้รับผิดชอบด้านธรรมาภิบาลข้อมูลภายในองค์กรยอมรับได้

Edge AI จะให้ผลลัพธ์ที่มีประสิทธิภาพสูงในงานที่มีข้อจำกัดทั้ง 3 ด้านนี้อย่างเข้มงวด ในทางกลับกัน หากงานใดไม่มีข้อจำกัดที่ชัดเจนในทั้ง 3 ด้าน การใช้ Cloud LLM จะช่วยให้เริ่มต้นโครงการได้รวดเร็วกว่า

สิ่งที่สนับสนุนการทำงานของ On-device LLM ในเชิงธุรกิจ คือวิวัฒนาการ 2 ด้านจากฝั่งโมเดล

ประการแรกคือ Quantization ซึ่งเป็นเทคโนโลยีในการบีบอัดน้ำหนัก (Weight) ของโมเดลให้มีความละเอียดต่ำลง จาก 16bit เหลือ 8bit หรือ 4bit ทำให้สามารถลดการใช้ VRAM และ Bandwidth ของหน่วยความจำลงได้อย่างมหาศาล โดยแนวโน้มทั่วไปจากการตรวจสอบของชุมชนผู้ใช้งานพบว่า Q8 (8bit) แทบไม่พบการสูญเสียความแม่นยำเมื่อเทียบกับ FP16 และแม้แต่ Q4 (4bit) ก็ยังอยู่ในระดับที่ใช้งานได้จริงในบางงาน (เนื่องจากขึ้นอยู่กับงานและข้อมูล จึงจำเป็นต้องมีการตรวจสอบซ้ำสำหรับงานขององค์กร) สิ่งนี้ทำให้โมเดลที่เดิมจำเป็นต้องใช้ GPU สามารถรันบน CPU ได้ และขยายขอบเขตการทำงานไปสู่โน้ตบุ๊ก สมาร์ทโฟน และอุปกรณ์ฝังตัว (Embedded devices)

ประการที่สองคือ การพัฒนาคุณภาพอย่างรวดเร็วของ SLM (Small Language Model) ไม่ว่าจะเป็นซีรีส์ Phi ของ Microsoft, Gemma ของ Google, Llama 3.2 1B / 3B ของ Meta หรือ On-Device Foundation Models ของ Apple ต่างก็มีการเปิดตัวโมเดลที่มุ่งเน้น "คุณภาพที่ใช้งานได้จริงในงานเฉพาะทาง แม้จะมีพารามิเตอร์เพียงไม่กี่พันล้านตัว" ออกมาอย่างต่อเนื่อง โมเดลเหล่านี้ส่วนใหญ่ถูกเผยแพร่ในรูปแบบ Open-weight model ซึ่งสามารถนำมา Fine-tuning ให้เหมาะสมกับงานขององค์กรได้

ในส่วนของสมาร์ทโฟนนั้น เรากำลังเข้าสู่ขั้นตอนที่ On-device LLM มาตรฐานของระบบปฏิบัติการเริ่มทำงานแล้ว เช่น Apple Intelligence และ Gemini Nano ของ Google ข้อสันนิษฐานที่ว่า "LLM ทำงานได้บนคลาวด์เท่านั้น" กำลังกลายเป็นเรื่องของอดีตไปแล้ว

ในบทก่อนหน้า เราได้พิจารณาถึง "เหตุผลที่ได้รับความสนใจ" โดยใช้ 3 แกนหลัก ได้แก่ ต้นทุน (Cost), ความหน่วง (Latency) และความเป็นส่วนตัว (Privacy) ในส่วนนี้ เราจะเจาะลึกให้มากขึ้นโดยการเปรียบเทียบความแตกต่างของทั้งสองสิ่งผ่าน 2 มุมมอง ได้แก่ "โครงสร้างต้นทุนและความหน่วง" และ "การดำเนินงานและการทำงานแบบออฟไลน์"

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

เมื่อพิจารณาจากโครงสร้างต้นทุน Cloud LLM และ Edge AI มีคุณสมบัติที่ตรงกันข้ามกัน โดย Cloud LLM คือ "ไม่มีการลงทุนเริ่มแรก / จ่ายตามการใช้งานจริง" ส่วน Edge AI คือ "มีการลงทุนเริ่มแรก / ค่าใช้จ่ายเพิ่มเติมมีเพียงค่าไฟฟ้าเท่านั้น"

ในช่วงที่ยังไม่สามารถคาดการณ์ปริมาณการใช้งานได้ การจ่ายเงินตามการใช้งานจริงของ Cloud จะได้เปรียบอย่างมาก แต่เมื่อการใช้งานมีความเสถียรและมีปริมาณมากถึงจุดหนึ่ง TCO (Total Cost of Ownership) ของฝั่ง Edge จะกลับมาได้เปรียบกว่า สำหรับจุดคุ้มทุนของฝั่งเซิร์ฟเวอร์นั้น ได้มีการกล่าวถึงรายละเอียดไว้ใน การเปรียบเทียบการนำ Local LLM / SLM มาใช้งาน

ในด้าน Latency ฝั่ง Edge จะได้เปรียบในแง่ความเร็วในการตอบสนองเนื่องจากไม่ต้องรับส่งข้อมูลผ่านเครือข่าย Cloud API อาจมีค่า Overhead เพิ่มขึ้นหลายร้อยมิลลิวินาทีแม้จะผ่าน Region Tokyo ซึ่งถือเป็นความแตกต่างที่สำคัญในงานที่ต้องการความเรียลไทม์ ในทางกลับกัน สำหรับงานที่สามารถรอการตอบสนองได้นานหลายวินาที (เช่น การสรุปรายงานการประชุมด้วย Batch ในเวลากลางคืน) ความแตกต่างของ Latency จะไม่ใช่ปัจจัยในการตัดสินใจ

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

ในทางกลับกัน สำหรับ Edge AI จำเป็นต้องส่งน้ำหนักโมเดล (Model weights) ใหม่ไปยังอุปกรณ์ปลายทางทั้งหมดที่ติดตั้งไว้ ไม่ว่าจะเป็นการอัปเดตผ่าน App Store / Google Play สำหรับแอปพลิเคชันบนสมาร์ทโฟน, กลไกการอัปเดตแบบ OTA (Over-The-Air) สำหรับอุปกรณ์ IoT ในภาคอุตสาหกรรม หรือการ Rollout ผ่าน MDM (Mobile Device Management) สำหรับแล็ปท็อปที่แจกจ่ายภายในองค์กร ซึ่งการออกแบบ MLOps เพื่อรองรับการจัดส่งโมเดลถือเป็นสิ่งที่ขาดไม่ได้

สุดท้าย สิ่งที่ต้องเน้นย้ำคือการทำงานแบบออฟไลน์ ซึ่งเป็น "จุดแข็งที่ Cloud ไม่มี" ของ Edge AI:

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

ในกรณีของ Cloud LLM หากเกิดความขัดข้องที่ฝั่งผู้ให้บริการ API อาจมีความเสี่ยงที่การดำเนินงานทั้งหมดจะหยุดชะงัก แม้ว่าจะมีการทำสัญญา SLA ไว้ แต่บ่อยครั้งที่ความเสียหายทางธุรกิจของผู้ใช้จะไม่ได้รับการชดเชย ดังนั้น สำหรับธุรกิจที่ "ความต่อเนื่อง" มีมูลค่าสูง การทำ Redundancy ที่ฝั่ง Edge จึงเป็นคำตอบที่สมเหตุสมผลที่สุด

การตัดสินใจนำ Edge AI มาใช้ควรเริ่มจากการคำนวณย้อนกลับจาก "ความต้องการทางธุรกิจ" (Business Requirements) ไม่ใช่จากความสามารถทางเทคนิคหรือเทรนด์ หากเริ่มจากความรู้สึกที่ว่า "อยากลองทำ" มักจะนำไปสู่รูปแบบที่ว่า หลังจากลงทุนติดตั้งเซิร์ฟเวอร์และพัฒนาโมเดลไปแล้ว ก็เพิ่งมาตระหนักได้ว่า "ใช้ Cloud LLM ก็เพียงพอแล้วไม่ใช่หรือ"

ในที่นี้จะขอนำเสนอเงื่อนไข 3 ประการที่ทำให้ Edge AI เป็นตัวเลือกแรก และมุมมองในการแยกแยะกรณีที่ Cloud LLM เพียงพอต่อการใช้งาน ขอให้พิจารณาการดำเนินงานของบริษัทท่านจากทั้งสองมุมมองนี้ในขั้นตอนเริ่มต้นของการพิจารณานำมาใช้งานเสมอ

การตัดสินว่างานใดควรใช้ Edge AI เป็นตัวเลือกแรกหรือไม่นั้น ในทางปฏิบัติสามารถพิจารณาได้จาก เงื่อนไขอย่างน้อย 1 ใน 3 ข้อต่อไปนี้ หากงานใดไม่เข้าข่ายเลย การฝืนนำไปใช้บน Edge จะขาดความสมเหตุสมผลทางเศรษฐกิจ

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

ในทางกลับกัน งานสรุปบันทึกการประชุมภายในบริษัทด้วยการประมวลผลแบบ Batch ในช่วงกลางคืนนั้น ความหน่วงไม่มีผลแต่อย่างใด สามารถส่งข้อมูลจากศูนย์ข้อมูลภายในบริษัทไปยัง Cloud API แล้วรับผลกลับมาได้ทันที จึงไม่มีเหตุผลทางเศรษฐกิจที่เพียงพอจะลงทุนใน Edge AI

การใช้เงื่อนไขทั้ง 3 ข้อนี้เป็นรายการตรวจสอบ (Checklist) จะช่วยลดความคลาดเคลื่อนในการตัดสินใจ หากสามารถระบุได้ตั้งแต่ขั้นตอนการเสนอโครงการว่า "โครงการของเราเข้าข่ายเงื่อนไขใด" หรือ "หากเข้าข่ายหลายข้อ อะไรคือลำดับความสำคัญ" ไว้ในบรรทัดเดียว จะช่วยให้การตัดสินใจในภายหลังมีความสอดคล้องกันมากขึ้น

ในทางกลับกัน สำหรับงานที่เข้าข่ายเงื่อนไขต่อไปนี้ การเลือกใช้ Cloud LLM มักจะเป็นทางเลือกที่สมเหตุสมผลกว่า:

• ข้อมูลที่ใช้เป็นหลักคือข้อมูลที่เปิดเผยต่อสาธารณะหรือข้อมูลเว็บสาธารณะที่มีความลับต่ำ
• ยังไม่สามารถคาดการณ์ปริมาณการใช้งานรายเดือนได้ และต้องการเร่งดำเนินการ PoC หรือการทดสอบระบบให้รวดเร็ว
• ความรู้และความสามารถในการใช้เหตุผลของโมเดลขนาดใหญ่รุ่นล่าสุด (เช่น ตระกูล GPT-5, Claude, Gemini Pro ฯลฯ) เป็นสิ่งที่ขาดไม่ได้
• เป็นเรื่องยากที่จะจัดตั้งทีมวิศวกร ML หรือทีมปฏิบัติการโครงสร้างพื้นฐานด้านการอนุมาน (Inference) โดยเฉพาะ

สิ่งที่สำคัญ ณ ที่นี้คือ การออกแบบไม่จำเป็นต้องเลือกเพียงอย่างใดอย่างหนึ่งระหว่าง "3 เงื่อนไข vs เหมาะกับ Cloud" เสมอไป ในรูปแบบไฮบริด (Hybrid configuration) เราสามารถประมวลผลส่วนที่ละเอียดอ่อน (เช่น การปกปิดข้อมูลส่วนบุคคล, การสรุปเอกสารภายในบริษัท, การกรองข้อมูลที่จะนำไปค้นหา) ไว้ที่ฝั่ง Edge แล้วส่งผลลัพธ์นั้นไปยัง Cloud LLM เพื่อให้ประมวลผลด้วยการใช้เหตุผลขั้นสูง วิธีนี้ช่วยให้เราสามารถใช้ความฉลาดของ Cloud ได้โดยไม่ต้องส่งข้อมูลดิบออกไปภายนอก

หากเขียนขั้นตอนการตัดสินใจเป็น Flow ง่ายๆ จะได้ดังนี้:

1. เข้าเงื่อนไขข้อใดข้อหนึ่งใน 3 เงื่อนไขหรือไม่?
   • ใช่ → ออกแบบ PoC โดยให้ Edge เป็นตัวเลือกแรก
   • ไม่ใช่ → ไปที่ข้อ 2
2. ความรวดเร็วในการเริ่มระบบหรือความฉลาดของโมเดลล่าสุดเป็นหัวใจสำคัญในการตัดสินใจหรือไม่?
   • ใช่ → ดำเนินการด้วย Cloud LLM
   • ไม่ใช่ → ไปที่ข้อ 3
3. ข้อมูลมีเพียงบางส่วนที่ละเอียดอ่อน หรือมีโครงสร้างที่ทำให้ต้นทุนสูงขึ้นตามสเกลของปริมาณข้อมูลหรือไม่?
   • ใช่ → ใช้รูปแบบไฮบริด (ประมวลผลส่วนที่ละเอียดอ่อนที่ Edge, ประมวลผลส่วนที่ต้องใช้ความฉลาดที่ Cloud)
   • ไม่ใช่ → Cloud LLM เพียงพอแล้ว

การพิจารณาตามลำดับนี้จะช่วยให้หลีกเลี่ยงความผิดพลาดจากการลงทุนเกินความจำเป็น (Over-investment) หรือการลงทุนที่ไม่เพียงพอ (Under-investment) ได้ง่ายขึ้น

ここまでで、エッジAI を選ぶ理由と業務適合性の判定軸を整理した。導入を実際に進める段階では、ユースケース選定からモデル・ハードウェア・運用設計までを段階的に進めるのが安全だ。

最初から本番デプロイを目指すと投資判断が大きくなりすぎるため、PoC（Proof of Concept）で 1 つの業務に絞って効果と運用負荷を確認するアプローチを推奨する。

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

เนื่องจากการมุ่งเป้าไปที่การใช้งานจริง (Production Deployment) ตั้งแต่ต้นจะทำให้การตัดสินใจลงทุนมีขนาดใหญ่เกินไป จึงขอแนะนำแนวทางแบบ PoC (Proof of Concept) โดยให้จำกัดขอบเขตไว้ที่งานเพียงอย่างเดียว เพื่อตรวจสอบประสิทธิภาพและภาระในการปฏิบัติงานก่อน

สิ่งแรกที่ควรทำในการเลือก Use Case คือการนำรายชื่อธุรกิจที่เสนอเข้ามาในบริษัทมาให้คะแนนตาม 3 แกน ได้แก่ "ระดับความสอดคล้องกับ 3 เงื่อนไข", "สามารถวัดผลเชิงปริมาณได้หรือไม่" และ "เป็นขนาดที่สามารถทำ PoC ให้จบได้ภายใน 2-3 เดือนหรือไม่" จากนั้นให้คัดเลือกเหลือเพียง 1 รายการที่ได้คะแนนสูงสุด หากพยายามทำหลายรายการไปพร้อมกัน จะทำให้โนว์ฮาวในการดำเนินงานฝั่ง Edge กระจัดกระจาย และมักจะจบลงด้วยการทำได้ไม่เต็มที่สักอย่าง

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

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

ในทางกลับกัน บางครั้ง PoC อาจทำให้พบว่า "Cloud LLM ให้ความแม่นยำสูงกว่าอย่างเห็นได้ชัด และข้อจำกัดของ 3 เงื่อนไขก็ไม่ได้รุนแรงขนาดนั้น" PoC ที่สามารถตัดสินใจยกเลิกได้ คือ PoC ที่มีคุณค่าอย่างแท้จริง

เมื่อเห็นแนวทางที่ชัดเจนจาก PoC แล้ว ขั้นตอนถัดไปคือการเลือกองค์ประกอบ 3 ส่วนเพื่อเตรียมเข้าสู่การใช้งานจริง ได้แก่ โมเดล, ฮาร์ดแวร์ และ MLOps

โมเดล: ต้องประเมินว่าสำหรับงานที่ทำอยู่นั้น "SLM ที่เน้นเฉพาะงานเพียงพอหรือไม่ หรือจำเป็นต้องใช้ LLM แบบทั่วไป" หากเป็นงานเฉพาะทาง เช่น การสรุปเอกสาร, การจำแนกประเภท, การสกัดข้อมูล หรือการจดจำชื่อเฉพาะ (Named Entity Recognition) โมเดลกลุ่ม SLM อย่าง Phi-4, Gemma 3 หรือ Llama 3.2 1B / 3B ถือเป็นตัวเลือกที่เหมาะสม หากต้องการการใช้เหตุผลหลายขั้นตอนหรือการสนทนาที่ยาวต่อเนื่อง จำเป็นต้องใช้โมเดลที่มีขนาดใหญ่ขึ้น ทั้งนี้ สิทธิ์การใช้งานโมเดล (License) จะแตกต่างกันไปในแต่ละโมเดล (เช่น Apache 2.0, Llama Community License, Gemma Terms of Use ฯลฯ) ดังนั้นโปรดตรวจสอบสิทธิ์การใช้งานอย่างเป็นทางการโดยตรงก่อนนำไปใช้ในเชิงพาณิชย์เสมอ

ฮาร์ดแวร์: ทางเลือกสำหรับอุปกรณ์ปลายทางจะแบ่งตามลักษณะการใช้งานเป็นหลัก

MLOps: จำเป็นต้องมีการออกแบบการดำเนินงานเฉพาะสำหรับ Edge ซึ่งไม่จำเป็นในกรณีของ Cloud LLM โดยเฉพาะอย่างยิ่งในเรื่องของ Pipeline การส่งมอบโมเดล (การทำ A/B Testing, การทยอยปล่อยอัปเดตแบบค่อยเป็นค่อยไป, การย้อนกลับเวอร์ชัน), การรวบรวมและตรวจสอบ Log การอนุมาน (Inference Log) รวมถึงการประเมินเพื่ออัปเดตโมเดลเป็นระยะ สำหรับองค์กรที่ไม่มีวิศวกร ML โดยเฉพาะ การจำกัดขอบเขตงานและออกแบบให้มีภาระในการดูแลรักษาน้อยที่สุดถือเป็นทางเลือกที่สมเหตุสมผล นอกจากนี้ สำหรับงานที่เกี่ยวข้องกับการสืบค้นเอกสาร ยังมีแนวทางในการสร้าง RAG ไว้บนอุปกรณ์ในเครื่อง (Local) อีกด้วย

ขอเพิ่มเติมคำถามที่พบบ่อยอีก 2 ประเด็นเกี่ยวกับการพิจารณานำ Edge AI และ On-device LLM มาใช้งาน ซึ่งยังไม่ได้กล่าวถึงในเนื้อหาหลัก ดังนี้

หากจำกัดขอบเขตของงาน ก็มีหลายกรณีที่เทคโนโลยีนี้เข้าสู่ระดับที่ใช้งานได้จริงแล้ว ความเคลื่อนไหวในการฝัง On-device LLM ไว้ในระดับ OS เช่น Apple Intelligence และ Gemini Nano ของ Google กำลังก้าวหน้าไปอย่างต่อเนื่อง โดยการออกแบบที่ให้งานขนาดเล็ก เช่น การตรวจแก้ข้อความ การสรุปความ การแปลประโยคสั้นๆ และการจัดลำดับความสำคัญของการแจ้งเตือน เสร็จสิ้นภายในตัวอุปกรณ์กำลังกลายเป็นเรื่องปกติ

อย่างไรก็ตาม หากต้องการ "ความรู้และพลังในการอนุมานที่เทียบเท่ากับโมเดลขนาดใหญ่รุ่นล่าสุดบนคลาวด์" ในปัจจุบันยังคงมีช่องว่างอยู่ แนวทางที่สมเหตุสมผลคือการกำหนดขอบเขตของงานให้ชัดเจน และเสริมความแม่นยำด้วย Fine-tuning หรือ RAG หากจำเป็น การมองว่าเป็นเครื่องมือที่มุ่งเน้นงานเฉพาะด้านแทนที่จะเป็นการทดแทนด้วยปัญญาประดิษฐ์อเนกประสงค์ จะช่วยให้ตัดสินใจได้แม่นยำยิ่งขึ้น

เป็นไปได้และในทางปฏิบัติแล้ว รูปแบบไฮบริดมักจะเป็นจุดที่ลงตัวที่สุดสำหรับงานหลายประเภท รูปแบบที่เป็นตัวแทนชัดเจนที่สุดคือการแบ่งบทบาทระหว่าง "การประมวลผลข้อมูลที่ละเอียดอ่อนไว้ที่ Edge" และ "การประมวลผลที่ชาญฉลาดไว้ที่ Cloud"

ตัวอย่างเช่น ในการสรุปข้อมูลการซักประวัติทางการแพทย์ ข้อมูลคำพูดของผู้ป่วยจะถูกนำมาปกปิดข้อมูลระบุตัวบุคคล (Masking) และสรุปผลด้วย On-device LLM บนตัวเครื่อง จากนั้นจะส่งเฉพาะข้อความที่ผ่านการทำข้อมูลให้เป็นนิรนาม (Anonymized text) ไปยัง Cloud LLM เพื่อทำการสรุปขั้นสูงหรือเสนอแนวทางการวินิจฉัยโรค ข้อมูลดิบจะยังคงอยู่ภายในโรงพยาบาล ในขณะที่ยังสามารถใช้ประโยชน์จากพลังการประมวลผลของ Cloud ได้ โครงสร้างลักษณะนี้สามารถนำไปประยุกต์ใช้กับการสนับสนุนการตัดสินใจด้านสินเชื่อในภาคการเงิน หรือแชทบอทภายในองค์กรได้เช่นกัน

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

Edge AI และ On-device LLM เป็นแนวทางที่เปิดโอกาสในการออกแบบเพื่อแก้ปัญหา 3 ประการที่ Cloud LLM มักประสบปัญหาในเชิงโครงสร้าง ได้แก่ "ความหน่วงต่ำ (Low latency)", "การห้ามนำข้อมูลออกนอกองค์กร (Data sovereignty)", และ "การเชื่อมต่อที่ไม่เสถียร (Unstable connectivity)" แม้ในทางเทคนิคจะยังอยู่ในระหว่างการพัฒนา แต่ด้วยความก้าวหน้าของ Quantization และ SLM รวมถึงการแพร่หลายของ NPU บนอุปกรณ์ปลายทาง ทำให้ปัจจุบันเริ่มเข้าสู่ระยะที่สามารถนำไปประยุกต์ใช้ในงานธุรกิจได้อย่างเป็นรูปธรรม

ขอสรุปประเด็นสำคัญในการตัดสินใจนำไปใช้งานไว้ 4 ข้อ ดังนี้:

• Edge AI ไม่ใช่ตัวตายตัวแทนของ Cloud LLM แต่ควรพิจารณาให้เป็น "ทางเลือกที่ใช้ตามความเหมาะสมของความต้องการทางธุรกิจ"
• Edge AI จะสร้างผลลัพธ์ได้ดีที่สุดในงานที่มีเงื่อนไขชัดเจนว่าต้องใช้ "3 เงื่อนไข (ความหน่วงต่ำ / ห้ามนำข้อมูลออก / การเชื่อมต่อไม่เสถียร)"
• สำหรับงานที่ต้องการความรวดเร็วในการเริ่มต้นหรือต้องการความฉลาดของโมเดลล่าสุด การใช้ Cloud LLM จะมีความสมเหตุสมผลมากกว่า
• ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่ง แต่ควรหยุดพิจารณาและออกแบบว่า "ควรวางขอบเขตของงานในองค์กรไว้ที่จุดใด" โดยพิจารณาถึงโครงสร้างแบบไฮบริดด้วย

สำหรับรายละเอียดการเปรียบเทียบ Local LLM/SLM บนฝั่งเซิร์ฟเวอร์, ความต้องการด้าน GPU และจุดคุ้มทุน โปรดดูที่ การเปรียบเทียบการนำ Local LLM / SLM มาใช้งาน และสำหรับการเพิ่มประสิทธิภาพต้นทุน Token ในช่วงการดำเนินงาน โปรดดูที่ คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM ประกอบ

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