การปรับใช้ SLM (Small Language Models) ที่ Edge คือวิธีการนำไปใช้งานโดยการรันโมเดลภาษาขนาดเล็กบนอุปกรณ์หรือเซิร์ฟเวอร์ภายในองค์กร (On-premise) โดยตรง แทนที่จะพึ่งพา API บนคลาวด์ ในสภาพแวดล้อมที่มีข้อจำกัด เช่น โรงงานผลิตที่เครือข่ายไม่เสถียร, ภาคการเงินหรือการแพทย์ที่ไม่สามารถนำข้อมูลออกไปภายนอกได้, หรือการประมวลผลความถี่สูงที่ต้องการลดค่าใช้จ่ายด้าน API การกำหนดค่าให้ SLM ขนาดหลายพันล้านพารามิเตอร์ทำงานในเครื่อง (Local) จึงเป็นทางเลือกที่ใช้งานได้จริง

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

SLM ไม่ใช่แค่ "LLM ขนาดเล็ก" แต่เป็นกลุ่มโมเดลที่มีแนวคิดการออกแบบที่แตกต่างออกไป โดยมีพื้นฐานมาจากการทำงานภายใต้ทรัพยากรที่จำกัด ก่อนอื่นเรามาทำความเข้าใจความแตกต่างระหว่าง SLM กับ LLM และเหตุผลว่าทำไม SLM จึงเป็นตัวเลือกที่เหมาะสมสำหรับสภาพแวดล้อมที่มีข้อจำกัดด้านทรัพยากร

โดยทั่วไปแล้ว LLM จะมีพารามิเตอร์ตั้งแต่หลายหมื่นล้านถึงหลายแสนล้านตัว ซึ่งต้องอาศัย GPU ประสิทธิภาพสูงและ VRAM ความจุสูง ในขณะที่ SLM มักจะมีขนาดพารามิเตอร์อยู่ที่ประมาณ 1B ถึง 10B (1 พันล้านถึง 1 หมื่นล้าน) ซึ่งหากผ่านการทำ Quantization แล้ว ก็สามารถทำงานบน CPU ทั่วไป, GPU ขนาดเล็ก หรือในบางกรณีอาจทำงานบน Single-board computer ได้

ความแตกต่างนี้ส่งผลโดยตรงต่อความเร็วในการอนุมาน (Inference) และต้นทุน สำหรับ LLM บนระบบคลาวด์นั้นจะมีค่า Overhead จากการรับส่งข้อมูลผ่านเครือข่ายและการรอคิว ทำให้เวลาที่ใช้ในการสร้างโทเค็นแรก (TTFT: Time To First Token) มีความผันผวนสูงตามสภาพแวดล้อม ส่วน SLM ที่ทำงานในเครื่อง (Local) ไม่จำเป็นต้องผ่านเครือข่าย หากโมเดลและฮาร์ดแวร์ทำงานสอดคล้องกัน การตอบสนองจะมีความเสถียรและสามารถใช้งานแบบออฟไลน์ได้โดยไม่หยุดชะงัก

อย่างไรก็ตาม ยิ่งพารามิเตอร์มีขนาดเล็ก ความสามารถในการใช้เหตุผลที่ซับซ้อน ความต่อเนื่องของข้อความยาวๆ และประสิทธิภาพด้านภาษาต่างๆ ก็มักจะลดลง "ความเร็วและเบา" กับ "ความฉลาด" จึงเป็นสิ่งที่ต้องแลกเปลี่ยนกัน (Trade-off) ดังนั้น แนวคิดในการเลือกโมเดลขนาดเล็กที่สุดที่ยังคงให้คุณภาพเพียงพอต่อการใช้งาน จึงเป็นจุดเริ่มต้นของการปรับใช้บน Edge Computing

เบื้องหลังการเลือกใช้ SLM ที่ Edge มีความต้องการ 3 ประการที่ LLM บนคลาวด์มักไม่สามารถตอบโจทย์ได้ ดังนี้:

1. อธิปไตยของข้อมูลและความเป็นส่วนตัว (Data Sovereignty and Privacy): เนื่องจากข้อมูลอินพุตจะไม่ถูกส่งไปยัง API ภายนอก ข้อมูลส่วนบุคคล แบบแปลน หรือสัญญาต่างๆ จึงถูกเก็บไว้ภายในอุปกรณ์ ซึ่งถือเป็นข้อได้เปรียบสำคัญสำหรับหน้างานที่ต้องจัดการกับข้อมูลที่เป็นความลับ
2. การทำงานแบบออฟไลน์และความหน่วงต่ำ (Offline Operation and Low Latency): สามารถทำงานได้ในสภาพแวดล้อมที่การเชื่อมต่อไม่เสถียรหรือไม่มีสัญญาณ เช่น โรงงาน คลังสินค้า ร้านค้า ยานพาหนะ หรือพื้นที่ห่างไกล ทำให้ปัญหาเครือข่ายไม่ส่งผลให้การบริการหยุดชะงัก
3. การปรับเปลี่ยนโครงสร้างต้นทุน (Cost Structure Transformation): การเรียกเก็บเงินตามการใช้งาน (Usage-based) ของ API จะเพิ่มขึ้นตามปริมาณการประมวลผล แต่การรันบนเครื่อง (Local execution) จะมีต้นทุนส่วนเพิ่ม (Marginal cost) ใกล้เคียงกับศูนย์หลังจากลงทุนด้านฮาร์ดแวร์ในระยะแรกแล้ว ซึ่งมักจะคุ้มค่ากว่าสำหรับการประมวลผลที่ต้องทำเป็นประจำและมีปริมาณโทเค็นสูง

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

SLM หลักๆ ที่เปิดให้ใช้งานสำหรับ Edge นั้นมีลักษณะเฉพาะแตกต่างกันไปตามผู้พัฒนา:

• ตระกูล Phi ของ Microsoft: แม้จะมีขนาดเล็กแต่มีความสามารถสูงในการใช้เหตุผลและการสร้างโค้ด โดยออกแบบมาเพื่อมุ่งเน้นคุณภาพระดับสูงด้วยจำนวนพารามิเตอร์ที่จำกัด
• ตระกูล Gemma ของ Google: มีน้ำหนักเบา ใช้งานง่าย และมีเอกสารประกอบรวมถึงเครื่องมือสนับสนุนที่ครบครัน
• ตระกูล Qwen ของ Alibaba: โดดเด่นด้วยการรองรับหลายภาษา (รวมถึงภาษาญี่ปุ่น) และมีขนาดให้เลือกหลากหลาย ทำให้ง่ายต่อการเลือกขนาดให้เหมาะสมกับการใช้งาน
• รุ่นขนาดเล็กของตระกูล Llama จาก Meta: มีระบบนิเวศขนาดใหญ่ ทำให้มีการแจกจ่ายโมเดลที่ผ่านการทำ Quantization และการรองรับเครื่องมือต่างๆ ได้อย่างรวดเร็ว

ในการเลือกโมเดล นอกจากขนาดของพารามิเตอร์แล้ว ต้องตรวจสอบใบอนุญาต (License) จากแหล่งข้อมูลปฐมภูมิเสมอ เนื่องจากเงื่อนไขการอนุญาตให้ใช้งานเชิงพาณิชย์และเงื่อนไขเพิ่มเติมตามขนาดการใช้งานจะแตกต่างกันไปในแต่ละโมเดล ซึ่งอาจก่อให้เกิดปัญหาในภายหลังได้ หากเน้นการใช้งานภาษาญี่ปุ่นเป็นหลัก การตรวจสอบว่าโมเดลนั้นได้รับการฝึกฝนและประเมินผลด้วยข้อมูลภาษาญี่ปุ่นหรือไม่ จะส่งผลต่อคุณภาพอย่างมากเช่นกัน

ก่อนเริ่มงานติดตั้ง ให้ทำการตรวจสอบรายการฮาร์ดแวร์ ซอฟต์แวร์ และเครือข่ายทั้ง 3 ส่วน หากดำเนินการโดยปล่อยให้ส่วนนี้ไม่ชัดเจน จะส่งผลให้เกิดปัญหาหน่วยความจำไม่เพียงพอหรือข้อผิดพลาดด้านความเข้ากันได้ (compatibility error) ในขั้นตอนถัดไป ซึ่งจะทำให้ต้องย้อนกลับมาแก้ไขงานใหม่

ทรัพยากรที่จำเป็นจะแตกต่างกันไปอย่างมากตามขนาดของโมเดลและวิธีการทำ Quantization แต่สามารถสรุปเป็นแนวทางเบื้องต้นได้ดังนี้:

• หน่วยความจำ (RAM/VRAM): สำหรับโมเดลที่ทำ Quantization แล้ว จะต้องใช้พื้นที่เท่ากับ "ขนาดไฟล์ + Overhead ในขณะประมวลผล (เช่น KV Cache)" โดยประมาณการเบื้องต้นสำหรับโมเดลระดับ 3B ที่ทำ INT4 Quantization จะอยู่ที่ประมาณ 2-3GB และระดับ 7B จะอยู่ที่ประมาณ 4-6GB อย่างไรก็ตาม ควรระวังว่ายิ่งขยายความยาวของ Context มากเท่าใด KV Cache ก็จะยิ่งเพิ่มขึ้นตามไปด้วย
• CPU/GPU: แม้ไม่มี GPU ก็สามารถประมวลผลด้วย CPU ได้ แต่ความเร็วจะขึ้นอยู่กับจำนวนคอร์และแบนด์วิดท์ของหน่วยความจำ ประสบการณ์การใช้งานจะแตกต่างกันไปตามการรองรับชุดคำสั่ง SIMD เช่น AVX2 หากสามารถใช้ GPU ขนาดเล็กหรือ NPU ได้ ควรนำมาใช้งานด้วย
• พื้นที่จัดเก็บข้อมูล (Storage): เพื่อความปลอดภัย ควรเตรียมพื้นที่ไว้ประมาณ 2-3 เท่าของขนาดโมเดล โดยเผื่อไว้สำหรับไฟล์โมเดล ไฟล์ตัวกลางในการแปลง และไฟล์บันทึก (Log)

ตัวเลขเหล่านี้เป็นเพียงแนวทางทั่วไปเท่านั้น ปริมาณที่จำเป็นจริงจะต้องวัดผลจากโมเดลที่ใช้และความยาวของ Context เสมอ เพื่อหลีกเลี่ยงปัญหา "ใช้งานได้ในสภาวะปกติแต่หน่วยความจำเต็มในช่วงที่มีโหลดสูงสุด" ควรประเมินโดยอ้างอิงจากโหลดการทำงานสูงสุดเป็นหลัก

เนื่องจาก Edge device มีความหลากหลายทั้งในด้าน OS และสถาปัตยกรรม จึงต้องตรวจสอบก่อนว่า Runtime นั้นรองรับสภาพแวดล้อมเป้าหมายหรือไม่

Runtime ตระกูล llama.cpp มักจะสามารถ Build บน Linux, Windows, macOS รวมถึง Single-board computer ที่ใช้ ARM และ Embedded Linux ได้ ส่วน ONNX Runtime นั้นมี Execution Provider แยกตามตัวเร่งความเร็ว (Accelerator) แต่ละประเภท (CPU, GPU, NPU) จึงต้องตรวจสอบว่ามี Provider ที่รองรับฮาร์ดแวร์ที่ต้องการใช้งานหรือไม่

ในกรณีที่ใช้ Python ความเข้ากันได้ระหว่างเวอร์ชันของ Python บนอุปกรณ์กับไลบรารีที่จำเป็น (เช่น ไลบรารีคำนวณตัวเลขหรือ Binding ของ Runtime) ก็เป็นจุดที่มองข้ามได้ง่าย ในสภาพแวดล้อมแบบ Embedded การใช้งานผ่าน Native implementation ของ C/C++ โดยไม่ใช้ Python อาจให้ความเสถียรมากกว่า การตรวจสอบล่วงหน้าด้วย OS และสถาปัตยกรรมเดียวกันกับที่ใช้ในงานจริง (Production) คือทางลัดที่ดีที่สุดในการหลีกเลี่ยงปัญหาความเข้ากันได้

แรงจูงใจส่วนใหญ่ของการทำ Edge Deployment คือ "การไม่นำข้อมูลออกไปภายนอก" ด้วยเหตุนี้ จึงจำเป็นต้องกำหนดสมมติฐานด้านเครือข่ายและความปลอดภัยให้ชัดเจนเป็นลายลักษณ์อักษร

โครงสร้างพื้นฐานจะเปลี่ยนไปตามรูปแบบการใช้งาน ไม่ว่าจะเป็นการทำงานแบบ Offline เต็มรูปแบบ หรือการอนุญาตให้มีการสื่อสารอย่างจำกัดเฉพาะการอัปเดตโมเดลและการส่ง Log หากตั้งสมมติฐานว่าต้องทำงานแบบ Offline จำเป็นต้องรวมวิธีการแจกจ่ายและอัปเดตไฟล์โมเดลรวมถึงแพ็กเกจที่เกี่ยวข้อง (เช่น การใช้ USB, Internal Mirror หรือช่องทางการดาวน์โหลดที่จำกัด) ไว้ในการออกแบบการปฏิบัติงานด้วย

นอกจากนี้ การที่ระบบทำงานแบบ Local ไม่ได้หมายความว่าจะปลอดภัยเสมอไป จำเป็นต้องมีการควบคุมการเข้าถึง Endpoint ของ Inference Server, การทำ Input Sanitization และการตรวจจับการแก้ไขไฟล์โมเดลแยกต่างหาก การหารือกับแผนกที่เกี่ยวข้องตั้งแต่เนิ่นๆ ว่าแนวทางดังกล่าวขัดกับนโยบายความปลอดภัยของบริษัทหรือไม่ (เช่น ขอบเขตของข้อมูลที่นำออกได้ หรือข้อกำหนดด้าน Audit Log) จะช่วยให้กระบวนการอนุมัติในภายหลังไม่ติดขัด

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

การเลือก "โมเดลที่ฉลาดที่สุดไว้ก่อน" มักจะล้มเหลวเมื่อนำไปใช้ที่ Edge ให้คำนวณย้อนกลับจากความสามารถขั้นต่ำที่จำเป็นต่อการใช้งานจริง

• การจำแนกประเภท การสกัดข้อมูล และการสรุปความแบบมาตรฐาน: โมเดลขนาดค่อนข้างเล็ก (ระดับ 1B–3B) มักจะใช้งานได้จริง ยิ่งงานเฉพาะเจาะจงมากเท่าไร โมเดลขนาดเล็กก็เพียงพอเท่านั้น
• การสนทนา การสร้างข้อความ และการใช้เหตุผลอย่างง่าย: ระดับ 7B เป็นช่วงที่สมดุลที่สุดระหว่างคุณภาพและความเบา
• การเขียนโค้ดและการใช้เหตุผลหลายขั้นตอนที่ซับซ้อน: โมเดลขนาดเล็กมักมีความแม่นยำต่ำ ในบางกรณีควรพิจารณาใช้ร่วมกับคลาวด์ (ประมวลผลงานหนักภายนอก) แทนการใช้ที่ Edge เพียงอย่างเดียว

ในการคัดเลือก จำเป็นต้องจำกัดตัวเลือกให้เหลือเพียง 2–3 โมเดล และทดสอบในสเกลเล็กด้วยข้อมูลจริงของบริษัท อันดับจากเกณฑ์มาตรฐาน (Benchmark) สาธารณะใช้เป็นข้อมูลอ้างอิงได้ แต่ผลลัพธ์จะเปลี่ยนไปหากภาษา โดเมน หรือรูปแบบ Prompt ที่ใช้แตกต่างกัน การตัดสินใจขั้นสุดท้ายควรพิจารณาจากการวัดผลจริงด้วยอินพุตที่ใกล้เคียงกับการใช้งานจริงมากที่สุด

การทำ Quantization คือเทคนิคที่ช่วยลดขนาดและหน่วยความจำของโมเดล โดยการลดบิตของน้ำหนัก (Weights) จาก FP16 เป็นต้น ไปเป็น INT8 หรือ INT4

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

ขั้นตอนการทำงานคือ (1) ดึงน้ำหนักของโมเดลเป้าหมายออกมา (2) แปลงเป็นความกว้างบิตที่ต้องการด้วยเครื่องมือทำ Quantization (เช่น quantize ของ llama.cpp หรือไลบรารีต่างๆ) และ (3) ป้อนข้อมูลชุดเดียวกันเข้าสู่โมเดลทั้งก่อนและหลังการแปลงเพื่อเปรียบเทียบผลลัพธ์

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

สำหรับการรันบน Edge จะต้องแปลงรูปแบบการแจกจ่าย (Distribution format) ให้อยู่ในรูปแบบที่ Runtime สามารถอ่านได้ โดยรูปแบบที่เป็นตัวแทนหลักคือ GGUF และ ONNX

GGUF เป็นรูปแบบที่จัดการโดย Runtime ตระกูล llama.cpp ซึ่งรวมข้อมูลการทำ Quantization ไว้ในไฟล์เดียว ทำให้สะดวกต่อการใช้งานบน CPU Inference หรือบอร์ดคอมพิวเตอร์ขนาดเล็ก (Single-board computer) โดยทั่วไปขั้นตอนการแปลงจะเริ่มจากการใช้สคริปต์ของ llama.cpp เพื่อแปลงโมเดลให้เป็น GGUF แล้วจึงทำ Quantization ในลำดับถัดไป

ONNX เป็นรูปแบบมาตรฐานที่ไม่ขึ้นกับ Framework ใดๆ ซึ่งสามารถนำไปปรับใช้กับ Accelerator ที่หลากหลาย ไม่ว่าจะเป็น CPU, GPU หรือ NPU ผ่านทาง ONNX Runtime ในกรณีที่ต้องการใช้งาน NPU ของแต่ละบริษัท การเลือกใช้ผ่าน ONNX มักจะเป็นทางเลือกที่ใช้งานได้จริงมากกว่า

การเลือกว่าจะใช้รูปแบบใดขึ้นอยู่กับ "Runtime และฮาร์ดแวร์ที่ใช้" โดยมีจุดเริ่มต้นในการพิจารณาคือ หากเน้น CPU หรือบอร์ดขนาดเล็กให้เลือก GGUF แต่หากต้องการใช้ประโยชน์จาก Accelerator เฉพาะทางให้เลือก ONNX หลังจากแปลงเสร็จแล้ว ต้องตรวจสอบการทำงานและผลลัพธ์บนเครื่องจริงเสมอ เพื่อยืนยันว่าความแม่นยำหรือการจัดการ Token พิเศษต่างๆ ไม่ผิดเพี้ยนไปในระหว่างการแปลง

เมื่อเตรียมโมเดลเรียบร้อยแล้ว ให้ติดตั้งรันไทม์ (Runtime) สำหรับประมวลผลโมเดลลงในอุปกรณ์ ในส่วนนี้จะครอบคลุมถึงการติดตั้ง การรับรองความสามารถในการทำซ้ำ (Reproducibility) และข้อควรระวังสำหรับสถาปัตยกรรมแต่ละแบบ

llama.cpp โดยพื้นฐานแล้วใช้วิธีการ build จากซอร์สโค้ด โดยให้ทำการดึง repository มาและคอมไพล์โดยระบุ build options ให้เหมาะสมกับฮาร์ดแวร์เป้าหมาย (เช่น การเปิดใช้งาน CPU SIMD, การระบุ GPU/Metal backend เป็นต้น) หากมีการแจกจ่าย binary ที่ build ไว้แล้วหรือ bindings ให้เลือกใช้ตัวที่ตรงกับสถาปัตยกรรมเป้าหมาย

สำหรับ ONNX Runtime ให้ติดตั้งแพ็กเกจที่รองรับ Execution Provider ที่ต้องการใช้งาน (สำหรับ CPU, CUDA หรือ NPU ต่างๆ) หากใช้ Python ให้ติดตั้ง build ที่เกี่ยวข้องผ่านเครื่องมือจัดการแพ็กเกจ และหากใช้งานแบบ native ให้ทำการลิงก์ไลบรารีที่รองรับ

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

สิ่งที่ช่วยได้มากในการใช้งานแบบ Edge Deployment คือการทำซ้ำสภาพแวดล้อม (Reproducibility) ได้ ซึ่งไม่ใช่เรื่องแปลกที่การตั้งค่าที่ทำงานได้บนอุปกรณ์เครื่องหนึ่ง จะไม่สามารถทำงานได้บนอุปกรณ์คนละล็อตหรือบน OS ที่ผ่านการอัปเดตแล้ว

หากใช้ Docker (หรือ Container Runtime ที่เข้ากันได้) ในการรวม Runtime, ไลบรารีที่จำเป็น และการจัดวางโมเดลไว้ในอิมเมจ ก็จะสามารถนำ "สถานะที่ทำงานได้" ไปปรับใช้ในวงกว้างได้ทันที โดยให้กำหนดเวอร์ชันของ Base Image และไลบรารีให้คงที่ ส่วนไฟล์โมเดลนั้นให้เลือกตามนโยบายการดำเนินงานว่าจะรวมไว้ในอิมเมจหรือจะ Mount ผ่าน Volume

อย่างไรก็ตาม คอนเทนเนอร์มี Overhead เล็กน้อย และหากมีการใช้ GPU/NPU จำเป็นต้องมีการตั้งค่าการเชื่อมต่อกับไดรเวอร์ฝั่ง Host ในสภาพแวดล้อมแบบฝังตัว (Embedded) ที่มีทรัพยากรจำกัดมาก อาจมีการตัดสินใจที่จะไม่ใช้คอนเทนเนอร์แต่ใช้วิธีติดตั้งแบบ Native แทน ทั้งนี้ขึ้นอยู่กับการเลือกว่าจะให้ความสำคัญกับความสามารถในการทำซ้ำ (Reproducibility) หรือความเบาของระบบมากกว่ากัน

อุปกรณ์ Edge มีการใช้งานผสมผสานกันระหว่าง ARM (Single Board, ระบบฝังตัว และเซิร์ฟเวอร์บางประเภท) และ x86 หากสถาปัตยกรรมต่างกัน ผลลัพธ์จากการ Build และการปรับแต่ง (Tuning) ก็จะเปลี่ยนไปด้วย

สำหรับ x86 การเปิดใช้งานคำสั่ง SIMD เช่น AVX2 หรือ AVX-512 ในระหว่างการ Build จะช่วยให้การประมวลผล Inference เร็วขึ้น ส่วนใน ARM กุญแจสำคัญคือการรองรับ NEON หรือการใช้ประโยชน์จาก NPU Accelerator ขึ้นอยู่กับแต่ละบอร์ด

ข้อควรระวังคือ การนำ Binary หรือ Container Image ที่ Build จาก x86 ไปใช้บน ARM โดยตรง หากสถาปัตยกรรมไม่ตรงกันจะไม่สามารถรันได้ ในกรณีที่ใช้ Container ควรเตรียม Image แบบ Multi-architecture หรือทำการ Build บนสถาปัตยกรรมเป้าหมายโดยตรง หากยึดหลักการ "Build และตรวจสอบบนสถาปัตยกรรมเดียวกับที่ใช้ในงานจริง (Production)" อย่างเคร่งครัด ก็จะสามารถป้องกันปัญหาประเภทนี้ได้เกือบทั้งหมด

เมื่อรันไทม์ทำงานแล้ว ให้ปรับปรุงให้เป็นไปป์ไลน์การอนุมาน (Inference Pipeline) ที่พร้อมสำหรับการใช้งานจริง โดยมี 3 ปัจจัยสำคัญที่ส่งผลต่อคุณภาพประสบการณ์การใช้งานที่ Edge ได้แก่ การออกแบบ Prompt, รูปแบบการตอบกลับ และการจัดการหน่วยความจำ

SLM มีความยาวบริบท (context length) ค่อนข้างสั้น ยิ่งใส่ข้อความยาวมากเท่าไร ทั้งความเร็วและหน่วยความจำก็จะยิ่งแย่ลง ดังนั้นการออกแบบ Prompt จึงมีพื้นฐานอยู่ที่ "สั้นและมีโครงสร้าง"

โมเดลแต่ละตัวจะมี Chat Template ที่กำหนดไว้ (วิธีแบ่งส่วน System, User, Assistant) หากไม่ใช้งานให้ถูกต้อง ประสิทธิภาพของโมเดลจะลดลง ขั้นแรกจึงต้องปรับให้ตรงกับ Template ที่แนะนำของโมเดลนั้นๆ

นอกจากนี้ ต้องคำนึงถึงจำนวน Input Token อยู่เสมอ ให้ตัดคำเกริ่นนำที่ไม่จำเป็นหรือคำสั่งที่ซ้ำซ้อนออก และหากจำเป็นให้สรุปหรือแบ่งส่วนข้อมูลก่อนส่งเข้าไป ในกรณีที่ใช้ RAG เพื่อเพิ่มความรู้ภายนอก ให้คัดเลือกเฉพาะส่วนที่มีความเกี่ยวข้องสูงเท่านั้น เพื่อป้องกันปัญหา Token เกินและลดความแม่นยำที่เกิดจากสัญญาณรบกวน (noise) ไปพร้อมกัน เนื่องจากจำนวน Token ในส่วนของ "Input + Output + KV Cache" เป็นปัจจัยที่กินหน่วยความจำ จึงควรตัดสินใจกำหนดขีดจำกัดไว้ตั้งแต่ขั้นตอนการออกแบบ

วิธีการตอบกลับควรเลือกใช้ตามวัตถุประสงค์การใช้งาน

การตอบกลับแบบสตรีมมิ่ง (Streaming response) เป็นวิธีการส่งคืนโทเค็นที่สร้างขึ้นทีละส่วน เหมาะสำหรับสถานการณ์ที่ต้องการลด "ความรู้สึกรอคอย" เช่น ใน UI ของการสนทนา เนื่องจากโทเค็นแรกจะปรากฏขึ้นอย่างรวดเร็ว แม้เวลาในการสร้างทั้งหมดจะเท่าเดิม แต่ประสบการณ์การใช้งานจริงจะดีขึ้นอย่างมาก

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

บนอุปกรณ์ Edge เนื่องจากจำนวนการทำงานพร้อมกัน (Concurrency) มักจะถึงขีดจำกัดของฮาร์ดแวร์อย่างรวดเร็ว การแยก "คำขอที่ต้องการความเรียลไทม์" กับ "งานที่สามารถประมวลผลรวมกันได้" ออกจากกันด้วยคิว (Queue) และกำหนดลำดับความสำคัญจะช่วยให้ระบบมีเสถียรภาพมากขึ้น หากพยายามประมวลผลทุกอย่างแบบซิงโครนัสและทันทีทันใด ระบบมักจะประสบปัญหาหน่วยความจำและความเร็วไม่เพียงพอในช่วงที่มีการใช้งานสูงสุด (Peak time)

การออกแบบแคชมีผลอย่างมากต่อการใช้งานที่เสถียรในสภาวะที่หน่วยความจำมีจำกัด

• KV Cache: เป็นกลไกสำหรับเก็บสถานะระหว่างการประมวลผลในขณะสร้างข้อความ ซึ่งจะขยายตัวมากขึ้นตามความยาวของบริบท (Context) สามารถลดการใช้หน่วยความจำได้ด้วยมาตรการต่างๆ เช่น การจำกัดความยาวสูงสุดของบริบทให้เท่าที่จำเป็นต่อการใช้งาน หรือการใช้ KV Cache ที่รองรับการทำ Quantization
• Model Residency: การโหลดโมเดลเป็นกระบวนการที่ใช้ทรัพยากรสูง จึงควรโหลดโมเดลทิ้งไว้ในหน่วยความจำแทนการโหลดใหม่ทุกครั้งที่มีคำขอเข้ามา อย่างไรก็ตาม การโหลดหลายโมเดลพร้อมกันจะทำให้หน่วยความจำเต็ม จึงควรจำกัดจำนวนโมเดลที่โหลดไว้ในเวลาเดียวกัน
• Response Cache: หากมีการป้อนข้อมูลที่เหมือนกันหรือคล้ายกันเข้ามาซ้ำๆ การเก็บผลลัพธ์ไว้ในแคชเพื่อนำกลับมาใช้ใหม่จะช่วยลดขั้นตอนการอนุมาน (Inference) ลงได้

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

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

ปัญหาที่พบบ่อยที่สุดคือหน่วยความจำไม่เพียงพอ (OOM) ในระหว่างการเริ่มต้นระบบหรือการโหลด สาเหตุส่วนใหญ่มักเกิดจาก "การประมาณขนาดโมเดลผิดพลาด" หรือ "การประเมินค่า Overhead ขณะรันไทม์ต่ำเกินไป"

การแก้ไขปัญหาควรทำเป็นขั้นตอนดังนี้: (1) ลดขนาดโมเดลด้วยการทำ Quantization ที่บิตต่ำลง (จาก INT8 เป็น INT4), (2) ลดความยาว Context สูงสุดเพื่อลด KV Cache, (3) ลดจำนวนโมเดลที่รันค้างไว้หรือลดจำนวนการประมวลผลพร้อมกัน และ (4) หากยังไม่เพียงพอ ให้เปลี่ยนไปใช้โมเดลที่มีขนาดเล็กลง

เคล็ดลับในการแยกแยะปัญหาคือ ให้ลองรันเพียง 1 คำขอโดยตั้งค่าความยาว Context ให้ต่ำที่สุด หากทำได้แสดงว่าเป็นปัญหาที่การออกแบบหน่วยความจำ (ความยาว Context/การประมวลผลพร้อมกัน) แต่ถ้ายังคงเกิดข้อผิดพลาด แสดงว่าโมเดลมีขนาดใหญ่เกินกว่าที่ฮาร์ดแวร์นั้นจะรองรับได้

หากพบปัญหา "การทำงานช้า" ให้ทำการแยกแยะและระบุจุดที่ใช้เวลาไปกับส่วนใด

ขั้นแรก ให้แยกวัดค่า TTFT (Time To First Token) และ ความเร็วในการสร้างโทเค็น (tokens/sec) ออกจากกัน หาก TTFT นาน มีความเป็นไปได้สูงว่าพรอมต์ยาวเกินไปหรือการประมวลผลล่วงหน้าหนักเกินไป แต่หากความเร็วในการสร้างช้า ให้สงสัยเรื่องแบนด์วิดท์หน่วยความจำของฮาร์ดแวร์ ประสิทธิภาพการคำนวณ หรือการตั้งค่าการควอนไทซ์ (Quantization) และการบิลด์ (Build)

ลำดับการตรวจสอบเบื้องต้นคือ (1) คำสั่ง SIMD หรือแบ็กเอนด์ของ GPU/NPU เปิดใช้งานอยู่หรือไม่ (ตรวจสอบการตั้งค่าการบิลด์) (2) หากเป็นการอนุมานด้วย CPU จำนวนเธรดเหมาะสมหรือไม่ (3) ความยาวของบริบท (Context length) ยาวเกินความจำเป็นหรือไม่ และ (4) มีกระบวนการอื่นแย่งใช้ CPU หรือแบนด์วิดท์หน่วยความจำอยู่หรือไม่

ในอุปกรณ์ Edge ไม่ใช่เรื่องแปลกที่การตั้งค่าซอฟต์แวร์ผิดพลาดเพียงเล็กน้อย (เช่น แบ็กเอนด์ไม่ได้เปิดใช้งาน หรือจำนวนเธรดไม่เหมาะสม) จะทำให้ประสิทธิภาพต่างกันหลายเท่าตัว ก่อนที่จะเพิ่มสเปกฮาร์ดแวร์ การทบทวนการตั้งค่าก่อนจะให้ความคุ้มค่ามากกว่า