Local LLM ใชจริงในองค์กร: อ่าน Model Size อย่างไร ประเมิน RAM เท่าไร และปลอดภัยแค่ไหน

จากบทสนทนาในคลิป Local LLM คืออะไร? ของ 9Expert
Source-ref: คลิป 9Expert + ประสบการณ์ตรงจากการรัน Local LLM, AI Agent และ DGX Spark จริง

หลายคนเริ่มสนใจ Local LLM เพราะไม่อยากส่งข้อมูลบริษัทให้ AI บนบริการสาธารณะ แต่พอเริ่มเลือกโมเดลจริงก็เจอศัพท์เต็มไปหมด เช่น 7B, 35B-A3B, MoE, Quantization, KV Cache, LoRA และ RAG

คำถามที่สำคัญจึงไม่ใช่แค่ "โมเดลไหนฉลาดที่สุด?" แต่คือ

โมเดลนี้ต้องใช้ทรัพยากรเท่าไร?
เครื่องของเรารันได้จริงหรือไม่?
ภาษาไทยจะมีคุณภาพแค่นั้น?
ข้อมูลจะปลอดภัยจริงหรือแคื่อย้ายความเสี่ยงจาก Cloud มาที่เครื่องเรา?
ควรใช้ Local LLM, API, Private Cloud หรือ Hybrid?

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

1. Local LLM คืออะไร?

Local LLM คือการนำ Large Language Model มารันบนทรัพยากรที่เราเป็นผู้ควบคุมเอง เช่น

เครื่อง Desktop หรือ Workstation
Server ภายในสำนักงาน
Private Cloud
เครื่องเฉพาะสำหรับ AI เช่น NVIDIA DGX Spark หรือระบบ GPU Server

แทนที่จะส่ง prompt และข้อมูลทั้งหมดไปประมวลผลบนบริการ API ภายนอก

อย่างไรก็ตาม คำว่า "Local" ไม่จำเป็นต้องหมายถึงเครื่องที่ตั้งอยู่ข้างโต๊ะเราเสมอไป จุดสำคัญคือ เราควบคุมสภาพแวดล้อม การเข้าถึงข้อมูล และเส้นทางของ request ได้มากแค่ไหน

ดังนั้นองค์กรหนึ่งอาจเลือกได้หลายแบบ:

รูปแบบ	เหมาะกับกรณี
Public API	ต้องการเริ่มต้นเร็ว ไม่อยากดูแล Infrastructure และข้อมูลไม่อ่อนไหวมาก
Local LLM	ต้องการควบคุมข้อมูล ใช้งานซ้ำสูง หรือมีเครื่องพร้อม
Private Cloud	ต้องการ control และ governance แต่ไม่อยากดูแล Hardware เองทั้งหมด
Hybrid	ข้อมูลสำคัญใช้ Local ส่วนงานทั่วไปใช้ API ที่เก่งกว่า

Local LLM จึงไม่ใช่คำตอบเดียวสำหรับทุกองค์กร แต่เป็นหนึ่งในทางเลือกของสถาปัตยกรรม AI

2. Open Weight ไม่ใช่ Open Source

ศัพท์สองคำนี้มักถูกใช้ปนกัน

Open Weight

หมายถึงผู้พัฒนาเปิดเผย model weights ให้ดาวน์โหลดไปใช้งานได้ในภายใต้เงื่อนไขของ license นั้น ๆ

เราจึงอาจนำโมเดลไป:

รันบนเครื่องตัวเอง
Quantize ให้เล็กลง
ทำ Fine-tuning หรือ LoRA
เชื่อมกับ RAG หรือ AI Agent
เปิดเป็น API ภายในองค์กร

แต่ต้องอ่าน license ก่อนเสมอ เพราะบางโมเดลอาจมีข้อจำกัดเรื่องการใช้งานเชิงพาณิชย์ การนำไปฝึกต่อ หรือการใช้งานในบางขนาดขององค์กร

Open Source

โดยความหมายที่เข้มงวดกว่า ควรมีส่วนประกอบที่เปิดกว้างมากกว่าแค่ weights เช่น source code, วิธีฝึก, training recipe หรือรายละเอียดของข้อมูล

สรุปสั้น ๆ:

ดาวน์โหลดโมเดลได้ ไม่ได้แปลว่าเรามีสิทธิ์ใช้ได้ทุกกรณี และไม่ได้แปลว่าโมเดลนั้น Open Source อย่างสมบูรณ์

ก่อนนำโมเดลเข้า Production ให้ตรวจ model card และ license ของ checkpoint ที่จะใช้จริง ไม่ใช่ดูเฉพาะชื่อโมเดล

3. ตัวเลข 7B, 35B หรือ 2.8T บอกอะไรเรา?

ตัวอักษร B และ T หมายถึงจำนวน parameters โดยประมาณ:

7B = 7 billion parameters
35B = 35 billion parameters
2.8T = 2.8 trillion parameters

จำนวน parameters เป็นตัวบอกขนาดความจุของโมเดล แต่ไม่ใช่คะแนนความฉลาดแบบตรง ๆ และไม่ใช่ตัวเลข RAM ที่ต้องใช้แบบตายตัว

ตัวประมาณที่เข้าใจง่ายคือ:

Memory สำหรับ weights ≈ จำนวน parameters × bytes ต่อ parameter

ตัวอย่างเฉพาะส่วน weights แบบคร่าว ๆ:

รูปแบบ	Bytes ต่อ parameter	โมเดล 10B ใช้กับ weights ประมาณ
FP16	2	20 GB
FP8 / INT8	1	10 GB
4-bit	0.5	5 GB

ตัวเลขนี้ยังไม่รวม:

KV Cache
Runtime overhead
Context ที่ผู้ใช้ป้อนเข้ามา
Memory สำหรับระบบปฏิบัติการและโปรแกรมอื่น
Memory สำหรับผู้ใช้หลายคนเรียกร่วมกัน

จึงไม่ควรจำแบบตายตัวว่า "1B เท่ากับ RAM 1 GB" แต่ควรใช้เป็นจุดเริ่มต้นในการประมาณ แล้วทดสอบกับ runtime และ context ที่เราจะใช้จริง

เอกสารของ Hugging Face มี Model Memory Estimator สำหรับช่วยประเมินขนาดโมเดล ส่วน Quantization Guide อธิบายว่าการลด precision ช่วยลด memory footprint และ computational cost ได้อย่างไร

4. Dense Model กับ Mixture of Experts (MoE)

Dense Model

Dense Model จะใช้ parameters ของโมเดลในการคำนวณทุกครั้งเมื่อประมวลผล token

ถ้าโมเดลมี 27B parameters เราจึงมักมองว่า computation ต่อ token อิงกับขนาดประมาณ 27B ทั้งหมด

Mixture of Experts

MoE แบ่งความสามารถออกเป็นกลุ่มย่อย ๆ หรือ Experts และมี Router เลือก Experts ที่เหมาะกับ input แต่ละส่วน

ตัวอย่างเชิงแนวคิด:

Total parameters: 35B
Active parameters ต่อ token: 3B

เมื่อ input เป็นโจทย์คณิตศาสตร์ Router อาจเลือก Experts ที่เก่งด้าน reasoning หรือ numerical pattern มากกว่า Experts ที่เกี่ยวข้องกับภาษา

ข้อดีของ MoE คือสามารถมีความจุสูง แต่ลด compute ที่ต้องใช้ต่อ token ได้

แต่จุดที่ต้องระวังคือ:

Active Parameters มีผลกับ compute ต่อ token ไม่ได้แปลว่า memory ที่ต้องเตรียมจะเท่ากับ Active Parameters เสมอไป

Weights ของ Experts ทั้งหมดอาจยังต้องอยู่ใน memory หรือ storage บางระดับ ขึ้นอยู่กับ runtime วิธีการ offload และการจัดการ model loading ของระบบนั้น ๆ

ดังนั้นโมเดล 35B-A3B อาจประมวลผลต่อ token คล้ายโมเดลเล็กกว่า แต่ไม่ได้หมายความว่าใช้เครื่องเหมือนโมเดล 3B ทุกกรณี

นี่คือเหตุผลที่การเลือก Local LLM ต้องดูทั้ง:

Total parameters
Active parameters
รูปแบบ quantization
RAM/VRAM ที่ runtime ต้องการจริง
ความเร็วที่ได้จาก workload ของเรา

5. Quantization: ทำให้โมเดลเล็กลง แต่ต้องวัดคุณภาพด้วย

Quantization คือการลดความละเอียดของตัวเลขที่ใช้เก็บ weights เช่น จาก FP16 ไปเป็น INT8, 4-bit หรือรูปแบบเฉพาะของ Hardware อย่าง NVFP4

ผลที่คาดหวังได้คือ:

ใช้ memory น้อยลง
โหลดโมเดลบน Hardware ขนาดเล็กลงได้
อาจเพิ่ม throughput หรือความเร็ว
ลดต้นทุนการรันบางรูปแบบ

แต่การลด precision อาจทำให้คุณภาพลดลง โดยเฉพาะกับ:

ภาษาไทย
งาน reasoning ที่ซับซ้อน
JSON หรือ structured output
การเรียกใช้ tools
บริบทที่ยาวมาก
งานที่ต้องรักษารูปแบบคำตอบอย่างเคร่งครัด

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

Base model มีภาษาไทยมากน้อยแค่ไหน
Checkpoint นั้นถูก fine-tune มาเพื่ออะไร
Quantization method และ calibration เป็นแบบไหน
Runtime รองรับ chat template ถูกต้องหรือไม่
Prompt และ tokenizer ทำงานถูกต้องหรือไม่

สำหรับ NVFP4 นั้น NVIDIA ระบุว่าเป็็น low-precision format ที่ใช้ประโยชน์จากความสามารถของสถาปัตยกรรม Blackwell และมีผลต่อประสิทธิภาพของการคำนวณ แต่ต้องใช้บน Hardware และ software stack ที่รองรับ ไม่ใช่ format ที่หยิบไปใช้กับเครื่องใดก็ได้

วิธีเลือกที่ถูกต้องคือวัดด้วยชุดทดสอบของเราเอง เช่น:

คำถามภาษาไทย 20 ข้อ
เอกสารจริง 5 ชุด
งานสรุปและ extraction
การคืนค่า JSON
Tool-calling 10 เคส
ความเร็ว token ต่อวินาที
Memory peak

อย่าเลือกจากตัวเลขบน model card เพียงอย่างเดียว

6. KV Cache คืออะไร และทำไม Context ยาวทำให้ RAM เพิ่ม?

ระหว่างการสร้างคำตอบ โมเดลต้องเก็บข้อมูลบางส่วนของ token ที่ประมวลผลไปแล้วไว้ใน KV Cache เพื่อไม่ต้องคำนวณซ้ำทั้งหมดในทุก token ใหม่

เมื่อ context ยาวขึ้น หรือมีผู้ใช้หลายคนเรียกร่วมกัน KV Cache ก็มีโอกาสเพิ่มขึ้นตาม

นี่คือเหตุผลที่โมเดลอาจ:

โหลดขึ้นเครื่องได้ แต่ตอบ context ยาวไม่ได้
ใช้ได้กับผู้ใช้คนเดียว แต่ช้าเมื่อบ่อย request
ดูเหมือนมี RAM พอ แต่ memory เต็มเมื่อเปิด agent หลายตัว

เวลาประเมิน Local LLM จึงต้องถามให้ครบว่า:

เราจะรันโมเดลตัวนี้กับ context length เท่าไร และมีผู้ใช้ร่วมกันกี่คน?

สำหรับ AI Agent คำถามนี้ยิ่งสำคัญ เพราะหนึ่งงานอาจมี system prompt, tool definitions, conversation history, retrieved documents และผลลัพธ์จาก tools อยู่พร้อมกัน

7. LoRA กับ RAG ใช้แทนกันไม่ได้

LoRA เหมาะกับอะไร?

LoRA หรือ Low-Rank Adaptation เป็นเทคนิค Parameter-Efficient Fine-Tuning ที่ลดจำนวน parameters ที่ต้อง train ทำให้ fine-tuning ใช้ memory และทรัพยากรน้อยลงกว่า full fine-tuning ในหลายกรณี

เหมาะกับการปรับ:

รูปแบบการตอบ
Tone of voice
รูปแบบ output
ความสามารถเฉพาะด้านบางชนิด
พฤติกรรมในการทำงานตามตัวอย่าง

รายละเอียดเพิ่มเติมดูได้จาก Hugging Face PEFT LoRA Guide

RAG เหมาะกับอะไร?

RAG หรือ Retrieval-Augmented Generation คือการค้นเอกสารหรือข้อมูลที่เกี่ยวข้อง แล้วส่งเข้า context ของโมเดลตอนตอบ

เหมาะกับ:

คู่มือบริษัท
Policy ที่เปลี่ยนบ่อย
Product catalog
เอกสารโครงการ
Knowledge Base ภายในองค์กร
ข้อมูลที่ต้องอ้างอิงแหล่งที่มา

ถ้าต้องการให้ AI รู้ข้อมูลบริษัทที่เปลี่ยนทุกสัปดาห์ การทำ RAG มักเหมาะกว่าการทำ fine-tune ใหม่ทุกครั้ง

จำง่าย ๆ:

อยากเปลี่ยน "วิธีตอบ"     → พิจารณา LoRA / Fine-tuning
อยากเพิ่ม "ข้อมูลอ้างอิง" → พิจารณา RAG

ในระบบจริงอาจใช้ทั้งสองอย่างร่วมกันได้

8. Local LLM กับ AI Agent

Local LLM ไม่ได้มีประโยชน์แค่การเปิด Chat UI แล้วถามตอบ

ถ้า runtime เปิดเป็น OpenAI-compatible API ได้ เครื่องมืออื่นก็สามารถเรียกใช้งานผ่าน endpoint เดียวกับที่หลาย application familiar เช่น llama.cpp มี server สำหรับให้ application เรียกโมเดลผ่าน API ที่มีรูปแบบใกล้เคียง OpenAI API

สถาปัตยกรรมจะหน้าตาประมาณนี้:

AI Agent / Coding Agent / n8n
              |
              v
     OpenAI-compatible API
              |
              v
       Local LLM Runtime
              |
              v
       Private company data

ผลที่ได้คือเราสามารถใช้ Local LLM เป็น model backend ให้กับ:

Internal Assistant
RAG Application
Coding Agent
Document Processor
Multi-Agent Workflow
n8n Automation
Tool-calling Service

แต่ต้องออกแบบ permission แยกให้ชัดเจน อย่าให้ Agent มีสิทธิ์เข้าถึงทุกไฟล์หรือทุกระบบเพียงเพราะโมเดลรันอยู่ในเครือข่ายภายใน

9. Local LLM ไม่ได้ปลอดภัยโดยอัตโนมัติ

ข้อดีด้าน privacy ของ Local LLM คือข้อมูลไม่จำเป็นต้องออกไปยัง public API แต่คำว่า Local ไม่ได้แปลว่าปลอดภัยทันที

สิ่งที่องค์กรต้องทำต่อคือ:

จำกัด network access ของ inference server
ไม่เปิด endpoint ออก Internet โดยตรง
ใช้ Authentication และ Authorization
แยกสิทธิ์ของแต่ละ Agent
ปิด telemetry ที่ไม่จำเป็น
กำหนด retention ของ prompt และ response logs
ตรวจว่า logs มีข้อมูลลับหรือไม่
ตรวจ model license และ dependency license
แยกข้อมูลที่จำเป็นต่อ task ออกจากข้อมูลทั้งหมด
บังคับ human approval ก่อน destructive action

การมี Local LLM แล้วเปิด API แบบไม่มี authentication ไว้บน public IP อาจทำให้ความเสี่ยงเพิ่มขึ้นแทนที่จะลดลง

สำหรับองค์กรไทย เราแนะนำให้เริ่มจากคำถามเหล่านี:

ข้อมูลอะไรห้ามออกนอกองค์กร?
Use case ไหนมีการใช้งานสูงและคุ้มค่ากับการดูแลเครื่อง?
ต้องการ latency เท่าไร?
ต้องรองรับผู้ใช้พร้อมกันกี่คน?
ใครเป็นเจ้าของ model update และ security patch?
ค่า Hardware, ไฟฟ้า, support และ maintenance เทียบกับ API แล้วเป็นอย่างไร?

คำตอบจะช่วยตัดสินใจได้ว่าควรใช้ Local, Private Cloud หรือ Hybrid

10. Decision Framework: ควรเลือกแบบไหน?

เลือก Public API เมื่อ

ต้องการเริ่มต้นทดลองเร็ว
ทีมยังไม่มีคนดูแล Infrastructure
งานไม่ใช่ข้อมูลอ่อนไหว
ต้องการความสามารถของ frontier model
ปริมาณการใช้งานยังไม่สูงมาก

เลือก Local LLM เมื่อ

มีข้อมูลที่ไม่น่าออกนอกองค์กร
ต้องการควบคุมระบบและ network
มีงานซ้ำจำนวนมาก
ต้องการลดความผันผวนของค่า API ระยะยาว
มี Hardware และทีมดูแลพร้อม

เลือก Hybrid เมื่อ

งานทั่วไปใช้ API ได้
งาน confidential ใช้ Local
ต้องการ fallback เมื่อ Cloud ใช้งานไม่ได้
ต้องการ balance ระหว่างคุณภาพ ต้นทุน และ privacy

อย่าเริ่มจากคำถามว่า "ซื้อ GPU รุ่นไหนดี?"

ให้เริ่มจาก:

ข้อมูลอะไร → งานอะไร → ผู้ใช้กี่คน → latency เท่าไร
→ ต้องการคุณภาพแค่ไหน → ต้นทุนรวมเท่าไร

แล้วค่อยย้อนกลับไปเลือกโมเดลและ Hardware

11. บทเรียนจากการลองรันจริง

จากการทดลอง Local LLM สิ่งที่ได้เห็นชัดคือโมเดลที่เร็วที่สุดไม่จำเป็นต้องเหมาะกับงานที่สุด

โมเดลหนึ่งอาจเร็วมาก แต่ภาษาไทยไม่ดี โมเดลหนึ่งอาจฉลาดกว่า แต่ใช้ RAM สูงเกินไป โมเดลหนึ่งอาจเหมาะกับการคุย แต่ทำ tool-calling ไม่เสถียร โมเดลหนึ่งอาจรันได้บนเครื่อง แต่ช้าเกินกว่าจะให้หลายคนใช้งานได้พร้อมกัน

ดังนั้นการเลือกโมเดลควรวัด 4 มิติพร้อมกัน:

Quality — ตอบถูกต้องและทำงานที่เราต้องการได้ไหม
Resource — RAM/VRAM และ storage พอไหม
Latency — เร็วพอสำหรับผู้ใช้จริงไหม
Governance — คุมข้อมูล สิทธิ์ และ license ได้ไหม

นี่คือเหตุผลที่ hands-on benchmark สำคัญกว่า leaderboard เพียงอย่างเดียว

สรุป

Local LLM ไม่ใช่แค่การเอา ChatGPT มารันบนเครื่องตัวเอง แต่เป็น architectural choice ที่กระทบทั้ง:

Data privacy
Cost
Latency
Hardware
AI Agent design
Security และ governance

ประเด็นสำคัญที่ต้องการให้จำมี 6 ข้อ:

LLM = Large Language Model
Open Weight ไม่ใช่ Open Source
จำนวน Parameters ไม่ได้เท่ากับ RAM แบบ 1:1
Active Parameters ของ MoE ไม่ได้แปลว่า memory ที่ใช้เท่ากัน
LoRA เหมาะกับการปรับพฤติกรรม ส่วน RAG เหมาะกับการเพิ่มข้อมูลอ้างอิง
Local ลดการส่งข้อมูลออกไป แต่ไม่ได้ทำให้ระบบปลอดภัยโดยอัตโนมัติ

ถ้ากำลังเริ่มทำ Local LLM ในองค์กร อย่าเริ่มจากการซื้อ Hardware ก่อน ให้เริ่มจาก use case และข้อมูลที่ปกป้อง แล้วค่อยเลือก architecture ที่เหมาะสม

ถ้าตองการตอ่อยอดจาก Local LLM สู่ RAG, AI Agent หรือ Multi-Agent Workflow ติดตามซีรียส์ AI Agent 101 ได้คราบ เราจะพาไล่ตั้งแต่การเลือกโมเดล การเปิด API การเชื่อม Tools ไปจนถึงการวาง Guardrails สำหรับใช้งานจริง

คำถาม: ตอนนี้คุณสนใจ Local LLM เพราะเรื่องใดมากที่สุด — Privacy, Cost, ความเร็ว, หรืออยากเอาไปต่อกับ AI Agent?

Source-ref: - คลิป Local LLM คืออะไร? — 9Expert - Hugging Face Model Memory Estimator - Hugging Face Quantization Concept Guide - Hugging Face PEFT LoRA Guide - NVIDIA NVFP4 Documentation - llama.cpp