เมื่อ LLM ไม่จำเป็นต้องอยู่บน Cloud
ปัจจุบันการใช้งาน Large Language Model หรือ LLM ส่วนใหญ่มักอยู่ในรูปแบบ Cloud API ไม่ว่าจะเป็น Chatbot, Document Analysis, Translation หรือ AI Agent
สถาปัตยกรรมแบบนี้มีข้อดีคือไม่ต้องลงทุน Hardware ขนาดใหญ่ และสามารถใช้โมเดลที่มีขนาดใหญ่มากได้
แต่ก็มีข้อจำกัดสำคัญ
- ต้องพึ่งพา Internet
- มี Network Latency
- มีค่า API ตามการใช้งาน
- ข้อมูลต้องเดินทางออกจากอุปกรณ์
- อาจไม่เหมาะกับข้อมูลที่มีความละเอียดอ่อน
- ไม่เหมาะกับพื้นที่ที่ Internet ไม่เสถียร
Case Study นี้จึงทดลองเปลี่ยนแนวคิดจาก
Cloud LLM
มาเป็น
Offline LLM บน Raspberry Pi 5
โดยใช้โมเดลขนาดเล็กที่ผ่าน Quantization และรันผ่าน Local Inference Runtime
1. เป้าหมายของระบบ
โจทย์ของเราคือสร้าง Offline AI Assistant ขนาดเล็กที่สามารถทำงานได้โดยไม่ต้องเชื่อมต่อ Internet
ระบบต้องสามารถ
- รับข้อความจากผู้ใช้
- ส่ง Prompt เข้า Local LLM
- ประมวลผลบน Raspberry Pi
- ส่งคำตอบกลับมา
- ทำงานต่อได้แม้ไม่มี Internet
ในระยะต่อไปสามารถเพิ่ม
- Voice Input
- Speech-to-Text
- Translation
- Text-to-Speech
- RAG
- Local Database
- IoT Control
เข้าไปได้
2. Hardware Architecture
Hardware ที่ใช้ใน Case Study ประกอบด้วย
Compute
Raspberry Pi 5
แนะนำ RAM 8GB ขึ้นไปสำหรับการทดลอง Local LLM หลายรูปแบบ
Storage
NVMe SSD
ใช้สำหรับเก็บ
- LLM Model
- GGUF Files
- Vector Database
- Documents
- Application
- Logs
Cooling
Active Cooling
มีความสำคัญเมื่อ CPU ต้องทำ Inference ต่อเนื่องเป็นเวลานาน
Input / Output
- USB Keyboard
- USB Microphone
- Speaker
สำหรับเวอร์ชัน Voice AI
3. Software Architecture
โครงสร้าง Software สามารถออกแบบได้ดังนี้
User
│
▼
Application UI
│
▼
Python API
│
▼
Local LLM Runtime
┌────────┴────────┐
│ │
llama.cpp Ollama
│ │
└────────┬────────┘
▼
GGUF Model
│
▼
Raspberry Pi 5
จุดสำคัญคือ
ทุกอย่างทำงานภายในเครื่อง
ไม่มีความจำเป็นต้องเรียก OpenAI API, Gemini API หรือ Cloud LLM ในขั้นตอน Inference
4. เลือกโมเดลอย่างไร?
การเลือก LLM สำหรับ Edge Device แตกต่างจากการเลือกโมเดลสำหรับ GPU Server
เราไม่ควรคิดว่า
“โมเดลใหญ่ที่สุด = ดีที่สุด”
แต่ต้องพิจารณา
Model Quality + RAM + CPU + Quantization + Latency
สำหรับ Raspberry Pi 5 สามารถเริ่มต้นจากโมเดลขนาดเล็ก เช่น
- Gemma 3 1B
- Qwen3 0.6B
- Qwen3 1.7B
- Llama 3.2 1B
- Llama 3.2 3B
และใช้โมเดลที่ผ่าน 4-bit Quantization
5. ทำไมต้องใช้ GGUF?
สำหรับระบบ Local LLM รูปแบบโมเดลที่พบได้บ่อยคือ GGUF
ตัวอย่างเช่น
model.gguf
ข้อดีคือสามารถจัดเก็บ Weight ที่ผ่าน Quantization และนำไปใช้งานกับ Runtime อย่าง llama.cpp ได้
แนวคิดคือ
Original Model
│
▼
Quantization
│
▼
4-bit / 8-bit
│
▼
GGUF
│
▼
llama.cpp
│
▼
Raspberry Pi 5
ทำให้โมเดลที่มีขนาดใหญ่เกินไปสำหรับ Edge Device สามารถลด Memory Footprint ลงได้อย่างมาก
6. ติดตั้ง Local LLM Runtime
หนึ่งใน Runtime ที่ได้รับความนิยมสำหรับ Local LLM คือ llama.cpp
หลังจากติดตั้ง Runtime แล้ว เราสามารถนำโมเดล GGUF มาโหลดเข้าสู่ระบบ
ตัวอย่างแนวคิดการทำงาน:
./llama-cli \
-m ./models/model.gguf \
-p "Explain Edge Computing"
จากนั้น Raspberry Pi จะประมวลผล Prompt ภายในเครื่อง
ไม่มีการส่ง Prompt ไปยัง Cloud
7. เชื่อมต่อกับ Python
เมื่อ Local LLM ทำงานได้แล้ว เราสามารถสร้าง Application Layer ด้วย Python
ตัวอย่าง Architecture:
Python Application
│
▼
Prompt Manager
│
▼
LLM Runtime
│
▼
GGUF Model
│
▼
CPU
│
▼
Response
Python สามารถทำหน้าที่เป็น Orchestrator เช่น
- รับ User Input
- สร้าง Prompt
- เรียก LLM
- จัดการ Context
- บันทึก Conversation
- เรียก Database
- เชื่อม RAG
- เชื่อม IoT
ดังนั้น Raspberry Pi ไม่ได้เป็นเพียงเครื่องรันโมเดล แต่สามารถกลายเป็น Edge AI Gateway ได้
8. Case: Offline Translation
หนึ่งใน Use Case ที่น่าสนใจคือเครื่องแปลภาษาแบบ Offline
ระบบสามารถออกแบบเป็น
🎤 Microphone
│
▼
Speech-to-Text
│
▼
Local LLM
│
▼
Translation
│
▼
Text-to-Speech
│
▼
🔊 Speaker
ตัวอย่าง
ผู้ใช้พูดภาษาไทย:
“พรุ่งนี้ผมจะเดินทางไปกรุงเทพ”
ระบบแปลงเสียงเป็นข้อความ
พรุ่งนี้ผมจะเดินทางไปกรุงเทพ
จากนั้น Local LLM แปลเป็น
Tomorrow I will travel to Bangkok.
แล้ว Text-to-Speech อ่านออกเสียงผ่าน Speaker
ทั้งหมดสามารถทำงานแบบ Offline ได้ หากเลือก STT, LLM และ TTS ที่รองรับการประมวลผล Local
9. Case: Private Document Assistant
อีก Use Case ที่มีมูลค่าสูงกว่า Translation คือ Private RAG
สมมติองค์กรมีเอกสารภายใน
/company-documents
├── policy.pdf
├── manual.pdf
├── meeting.pdf
├── research.pdf
└── specification.pdf
เราสามารถสร้างระบบ
Documents
│
▼
Text Extraction
│
▼
Embedding
│
▼
Vector Database
│
▼
Semantic Search
│
▼
Relevant Context
│
▼
Local LLM
│
▼
Answer
ผู้ใช้สามารถถามว่า
“นโยบายการลาของบริษัทกำหนดไว้อย่างไร?”
ระบบค้นหาเอกสารที่เกี่ยวข้อง แล้วส่งเฉพาะ Context ที่จำเป็นให้ Local LLM
ข้อมูลทั้งหมดสามารถเก็บอยู่ใน Network ภายในองค์กร
นี่คือจุดที่ Local LLM + RAG + Edge Computing เริ่มมีความน่าสนใจในงานจริง
10. Case: Edge AI + IoT
ขั้นต่อไปคือการเชื่อม Local LLM เข้ากับ IoT
ตัวอย่าง
Local LLM
│
┌──────┴──────┐
│ │
MQTT API
│ │
▼ ▼
Sensors IoT Devices
│ │
└──────┬──────┘
▼
Raspberry Pi 5
ผู้ใช้สามารถสั่งงานด้วยภาษาธรรมชาติ เช่น
“เปิดไฟห้องประชุม”
LLM ทำหน้าที่แปลง Intent
{
"device": "meeting_room_light",
"action": "on"
}
จากนั้นระบบส่งคำสั่งผ่าน MQTT ไปยังอุปกรณ์
นี่คือจุดเริ่มต้นของ Edge AI Agent
11. จุดแข็งของระบบ Offline
Privacy
ข้อมูลสามารถประมวลผลภายในระบบ
Availability
ไม่จำเป็นต้องพึ่ง Internet สำหรับ Inference
Cost
ไม่มีค่า API ต่อ Request
Latency
ไม่ต้องส่งข้อมูลไป Cloud และรอ Response กลับ
Control
เจ้าของระบบสามารถควบคุม Model, Runtime, Data และ Infrastructure ได้เอง
12. แต่ Offline LLM ไม่ได้ฟรีในทุกมิติ
แม้ไม่มีค่า API แต่ต้นทุนจะย้ายไปอยู่ที่ Hardware และ Engineering
ตัวอย่าง
Hardware
+
Electricity
+
Storage
+
Cooling
+
Model Optimization
+
Software Maintenance
+
Security
ดังนั้นคำถามที่ถูกต้องไม่ใช่
“Offline AI ถูกกว่า Cloud หรือไม่?”
แต่ควรถามว่า
“Workload แบบไหนที่ Offline AI มีต้นทุนรวมและความเสี่ยงที่เหมาะสมกว่า Cloud?”
สำหรับงานที่มี Request จำนวนมากและใช้โมเดลขนาดเล็ก Local AI อาจมีความคุ้มค่าอย่างมาก
13. สิ่งที่ต้องวัดในการทดลอง
หากต้องการทำ Case Study ในระดับ Engineering ไม่ควรวัดเพียงว่า
“รันได้หรือไม่?”
แต่ควร Benchmark อย่างเป็นระบบ
Model Performance
- Tokens/second
- Time to First Token
- Total Generation Time
- Context Length
Hardware
- CPU Utilization
- RAM Usage
- Temperature
- Power Consumption
Application
- Response Latency
- Accuracy
- Translation Quality
- RAG Retrieval Accuracy
ตัวอย่างตาราง Benchmark
|
Model |
Quantization |
RAM |
Tokens/s |
Temperature |
Quality |
|
Gemma 1B |
Q4 |
— |
— |
— |
— |
|
Qwen 0.6B |
Q4 |
— |
— |
— |
— |
|
Qwen 1.7B |
Q4 |
— |
— |
— |
— |
|
Llama 3.2 1B |
Q4 |
— |
— |
— |
— |
ค่าจริงควรวัดจาก Hardware และ Configuration ที่ใช้จริง ไม่ควรนำตัวเลขจากคนละระบบมาเปรียบเทียบโดยตรง
14. จาก Raspberry Pi สู่ Edge AI Platform
สิ่งที่น่าสนใจที่สุดของ Case นี้ไม่ได้อยู่ที่ Raspberry Pi 5 เพียงอย่างเดียว
แต่คือ Architecture ที่สามารถขยายต่อได้
เริ่มจาก
Local LLM
↓
Voice AI
↓
RAG
↓
Tool Calling
↓
AI Agent
↓
IoT
↓
Edge AI Platform
ในอนาคต Raspberry Pi อาจทำหน้าที่เป็น Local AI Gateway ที่เชื่อมระหว่างผู้ใช้ อุปกรณ์ IoT และระบบ AI ภายในองค์กร
บทสรุป
การสร้าง LLM Offline บน Raspberry Pi 5 เป็นมากกว่าการทดลองรัน Chatbot บน SBC
มันเป็น Case Study ที่ทำให้เราเข้าใจองค์ประกอบสำคัญของ Edge AI ตั้งแต่
LLM → Quantization → GGUF → Inference Runtime → CPU → RAM → Thermal → Power → Privacy
และเมื่อเพิ่ม
RAG + Voice + Tool Calling + IoT
ระบบเล็ก ๆ บน Raspberry Pi ก็สามารถพัฒนาไปสู่ Private Edge AI Agent ได้
แนวคิดสำคัญจึงไม่ใช่การพยายามทำให้ Raspberry Pi แข่งขันกับ GPU Server
แต่คือการถามว่า
“งาน AI ประเภทใดที่เราสามารถย้ายจาก Cloud มาไว้ใกล้ข้อมูลและผู้ใช้งานได้?”
เมื่อคำตอบคือบางงานไม่จำเป็นต้องใช้ Cloud เราก็สามารถออกแบบระบบใหม่ที่มีทั้ง Privacy, Offline Capability, Low Latency และ Control ได้มากขึ้น
และนี่อาจเป็นหนึ่งในทิศทางสำคัญของ AI ยุคถัดไป:
AI ไม่ได้อยู่เฉพาะใน Data Center อีกต่อไป — AI กำลังเคลื่อนเข้ามาอยู่ที่ Edge
ความคิดเห็น
แสดงความคิดเห็น