คู่มือ
คำศัพท์และแนวคิดสำคัญที่ใช้ในเว็บ AiNaiDee อธิบายแบบเข้าใจง่าย
Parameters
เวลาเห็นตัวเลขแบบ "7B" หรือ "70B" นั่นคือจำนวนพารามิเตอร์ (weights) ของโมเดล หน่วยเป็นพันล้าน ยิ่งพารามิเตอร์เยอะ โมเดลก็มักจะฉลาดและมีความสามารถมากขึ้น แต่ก็ต้องใช้หน่วยความจำมากขึ้นและรันช้าลงด้วย โมเดล 7B เหมาะกับงานพื้นฐาน 13B–34B คือจุดสมดุลที่ลงตัว ส่วน 70B ขึ้นไปให้คุณภาพใกล้เคียงระดับ frontier แต่ต้องใช้ฮาร์ดแวร์ที่แรงจริงจัง
ขนาดโมเดล vs ความสามารถ (tradeoff)
Quantization
Quantization คือการลดความละเอียด (precision) ของน้ำหนักโมเดล เพื่อให้ไฟล์เล็กลงและรันเร็วขึ้น แลกกับคุณภาพที่ลดลงบ้าง ชื่อของแต่ละฟอร์แมตจะบอกจำนวนบิตที่ใช้:
คุณภาพ vs ขนาดไฟล์ (สำหรับโมเดล 7B)
| รูปแบบ | บิต | คุณภาพ | หมายเหตุ |
|---|---|---|---|
| Q2_K | 2 | ต่ำ | ไฟล์เล็กที่สุด แต่คุณภาพลดลงเห็นได้ชัด |
| Q4_K_M | 4 | ดี | สมดุลระหว่างขนาดกับคุณภาพดีที่สุด — นิยมใช้มากที่สุด |
| Q6_K | 6 | ดีมาก | แทบไม่เสียคุณภาพ ขนาดไฟล์เพิ่มขึ้นพอประมาณ |
| Q8_0 | 8 | ยอดเยี่ยม | คุณภาพแทบไม่ลด แต่ไฟล์ใหญ่ขึ้น |
| F16 | 16 | ต้นฉบับ | ความละเอียดเต็ม ไฟล์ใหญ่ที่สุด |
VRAM
VRAM คือหน่วยความจำบนการ์ดจอ (GPU) การจะรันโมเดลได้ ไฟล์ที่ quantized แล้วทั้งไฟล์ต้องใส่ลงใน VRAM ได้พอดี (หรือใน unified memory บน Apple Silicon) ถ้าโมเดลต้องการ VRAM 8 GB แต่การ์ดจอมีแค่ 6 GB มันจะรันไม่ได้ดี — อาจรันไม่ได้เลย หรือต้องถอยไปใช้ CPU inference ซึ่งช้ากว่ามาก
MoE (Mixture of Experts)
โมเดลแบบ Mixture of Experts (MoE) จะแบ่งพารามิเตอร์ออกเป็นกลุ่มที่เรียกว่า "experts" ในแต่ละโทเคนจะมีแค่บาง expert ที่ทำงาน — เช่น Mixtral 8x7B มีพารามิเตอร์รวม 46.7B แต่ใช้งานจริงแค่ราว 12.9B ต่อโทเคน นั่นแปลว่าคุณได้คุณภาพระดับโมเดลใหญ่ แต่ความเร็วระดับโมเดลเล็ก ข้อแลกเปลี่ยนคือโมเดลทั้งก้อนยังต้องใส่ลงในหน่วยความจำให้ได้ ถึงแม้ตอนประมวลผลจะใช้แค่บางส่วนก็ตาม
การกระจายงานให้ expert ใน MoE (ตัวอย่าง Mixtral)
Dense vs MoE Architecture
โมเดลแบบ dense จะเปิดใช้พารามิเตอร์ทั้งหมดในทุกโทเคน — เห็นเท่าไหร่ก็ได้เท่านั้น ส่วนโมเดลแบบ MoE มีพารามิเตอร์รวมมากกว่า แต่ใช้แค่บางส่วนต่อโทเคน โมเดลแบบ dense เข้าใจง่ายและคาดเดาเรื่องหน่วยความจำ/ความเร็วได้แม่นยำกว่า ส่วนโมเดลแบบ MoE ให้คุณภาพเกินตัวได้ แต่ต้องใช้ VRAM มากกว่าที่จำนวนพารามิเตอร์ที่ทำงานจริงจะบ่งบอก
Context Length
Context length คือจำนวนโทเคนที่โมเดลประมวลผลได้ในครั้งเดียว — รวมทั้งอินพุตและเอาต์พุต โมเดลที่มี "context 128K" จะรับข้อความได้ประมาณ 100,000 คำในการสนทนาเดียว context ที่ยาวขึ้นเหมาะกับการวิเคราะห์เอกสารหรือบทสนทนายาวๆ แต่ใช้หน่วยความจำมากขึ้นด้วย การใช้งานทั่วไปบนเครื่องส่วนตัวส่วนใหญ่ใช้ context แค่ 4K–8K ก็เพียงพอแล้ว
Tokens per Second (tok/s)
นี่คือความเร็วในการประมวลผล — โมเดลสร้างข้อความได้เร็วแค่ไหน แนวทางคร่าวๆ มีดังนี้:
- 60+ tok/s — เร็วปรี๊ดเหมือนไม่มีดีเลย์ เหมาะกับการใช้งานแบบโต้ตอบ
- 30–60 tok/s — เร็วและลื่นไหล
- 15–30 tok/s — ใช้งานได้ รอนิดหน่อย
- 5–15 tok/s — พอใช้ได้กับงานแบบ batch
- <5 tok/s — ทรมานถ้าใช้งานแบบโต้ตอบ
GGUF Format
GGUF คือฟอร์แมตไฟล์ที่ใช้โดย llama.cpp และเครื่องมืออื่นๆ อย่าง Ollama, LM Studio และ GPT4All มันเก็บน้ำหนักโมเดลที่ quantized แล้วไว้ในไฟล์เดียว พร้อมรันบน CPU หรือ GPU เวลาดาวน์โหลดโมเดลจาก HuggingFace มาใช้บนเครื่อง ปกติแล้วคุณจะมองหาเวอร์ชัน GGUF
Memory Bandwidth
Memory bandwidth (วัดเป็น GB/s) กำหนดว่าอ่านข้อมูลจาก VRAM ได้เร็วแค่ไหน ระหว่างการประมวลผล คอขวดหลักคือการอ่านน้ำหนักโมเดลจากหน่วยความจำ — ดังนั้นยิ่ง bandwidth สูง ก็ยิ่งได้ tok/s มากขึ้น นี่คือเหตุผลที่ Mac ตระกูล Apple Silicon (ที่มี unified memory bandwidth สูง) รันโมเดลใหญ่ได้ดีอย่างน่าประหลาดใจ และทำไม RTX 4090 ถึงสร้างข้อความได้เร็วกว่า RTX 4060 แม้จะใช้ VRAM เท่ากัน
เปรียบเทียบ memory bandwidth (GB/s)