รูปแบบ GGUF: คู่มือฉบับสมบูรณ์สำหรับการทำ Inference LLM ในเครื่อง

GGUF คืออะไร?

GGUF ย่อมาจาก GGML Unified Format เป็นรูปแบบไฟล์ไบนารีที่บรรจุน้ำหนักโมเดล ข้อมูลตัวแบ่งหน่วยคำ เมตาดาตาด้านสถาปัตยกรรม และข้อมูลการควอนไทซ์ไว้ในไฟล์พกพาไฟล์เดียวเพื่อใช้ทำ inference กับรันไทม์ที่อิง GGML โดยเฉพาะ llama.cpp.

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

ไฟล์ GGUF โดยทั่วไปประกอบด้วย:

• เทนเซอร์ของโมเดล
• น้ำหนักที่ผ่านหรือไม่ผ่านการควอนไทซ์
• คลังคำของตัวแบ่งหน่วยคำ
• คอนฟิกของตัวแบ่งหน่วยคำ
• เมตาดาตาด้านสถาปัตยกรรมของโมเดล
• การตั้งค่าความยาวคอนเท็กซ์
• มิติของเวกเตอร์ embedding
• จำนวนหัวของ attention
• การตั้งค่า RoPE
• ชื่อตัวเทนเซอร์ รูปร่าง และชนิดข้อมูล

แนวคิดสำคัญคือไฟล์อธิบายตัวมันเองได้ รันไทม์สามารถอ่านเมตาดาตา ทำความเข้าใจสถาปัตยกรรม โหลดตัวแบ่งหน่วยคำ และแมปเทนเซอร์ได้ โดยไม่ต้องพึ่งพา config.json หรือโฟลเดอร์ tokenizer แยกต่างหาก

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

คุณลักษณะสำคัญสี่ประการของ GGUF ได้แก่:

1. ดีพลอยแบบไฟล์เดียว
2. รองรับ memory mapping เพื่อการโหลดที่มีประสิทธิภาพ
3. เมตาดาตาแบบคีย์-แวลูชนิดข้อมูลขยายได้
4. รองรับชนิดการควอนไทซ์หลายแบบ ตั้งแต่แบบบิตต่ำเชิงรุกไปจนถึงความละเอียดเต็ม

GGUF เปิดตัวในปี 2023 เป็นส่วนหนึ่งของระบบนิเวศ llama.cpp และ GGML ปัจจุบันเป็นรูปแบบหลักในการแจกจ่าย LLM แบบควอนไทซ์เพื่อใช้งานในเครื่องบน Hugging Face.

GGUF เทียบกับ GGML

รูปแบบ GGML (Georgi Gerganov Machine Learning) เป็นรุ่นก่อนของ GGUF มีความสำคัญเพราะช่วยให้การทำ inference ในเครื่องยุคแรกเป็นไปได้ แต่มีข้อจำกัดเชิงปฏิบัติเมื่อระบบนิเวศขยายเกินโมเดล LLaMA ดั้งเดิม

จุดเจ็บปวดของ GGML ที่พบบ่อย ได้แก่:

• การจัดการเมตาดาตาที่ยืดหยุ่นน้อยกว่า
• สมมติฐานการโหลดที่ผูกกับสถาปัตยกรรมมากกว่า
• การจัดการ tokenizer และคอนฟิกที่รวมตัวเองได้น้อยกว่า
• ขยายความสามารถได้ยากเมื่อมีตระกูลโมเดลใหม่ ๆ

GGUF แก้ข้อจำกัดเหล่านั้นด้วยรูปแบบที่มีโครงสร้างมากขึ้น มีเมตาดาตาแบบระบุชนิด ดีกว่าในการฝัง embedding ของ tokenizer และเลย์เอาต์ไฟล์ที่ชัดเจนขึ้น ช่วยให้ llama.cpp และเครื่องมือที่เกี่ยวข้องรองรับสถาปัตยกรรมเพิ่มเติมได้ง่ายขึ้น โดยไม่ต้องออกแบบท่อโหลดใหม่ตลอดเวลา

สำหรับผู้ใช้ ข้อแตกต่างที่สำคัญมีง่าย ๆ คือ: GGUF คือรูปแบบสมัยใหม่ หากกำลังดาวน์โหลดโมเดลในวันนี้ แทบทุกครั้งควรเลือก GGUF มากกว่ารูปแบบ GGML เก่า

GGUF เทียบกับ GPTQ และ AWQ

ขณะศึกษารูปแบบไฟล์ คุณน่าจะพบ GGUF, GPTQ (Generative Post-Training Quantization) และ AWQ (Activation-Aware Weight Quantization) มักถูกพูดถึงร่วมกันเพราะทั้งสามอย่างช่วยให้การทำ inference ของ LLM มีประสิทธิภาพขึ้น อย่างไรก็ตาม พวกมันไม่ใช่หมวดหมู่เดียวกัน

GGUF เป็นรูปแบบไฟล์และคอนเทนเนอร์สำหรับดีพลอยเป็นหลัก รองรับการควอนไทซ์หลายประเภท และเชื่อมโยงใกล้ชิดกับการ inference ในเครื่องแบบ llama.cpp

GPTQ และ AWQ เป็นวิธีการควอนไทซ์และระบบนิเวศที่มักใช้สำหรับ inference ที่ปรับแต่งเพื่อ GPU โดยเฉพาะบนฮาร์ดแวร์ NVIDIA ผ่านเฟรมเวิร์กอย่าง Transformers, ExLlama, AutoGPTQ และเวิร์กโฟลว์ที่รองรับ vLLM

หากเป้าหมายคือความเข้ากันได้สูงสุดระหว่างแล็ปท็อป เดสก์ท็อป Apple Silicon และฮาร์ดแวร์ผสม GGUF มักเป็นตัวเลือกที่ปลอดภัยกว่า

หากเป้าหมายคืออัตราการประมวลผลสูงสุดบนเซิร์ฟเวอร์ inference แบบ NVIDIA เฉพาะทาง GPTQ, AWQ, FP8 หรือรูปแบบการให้บริการที่ปรับแต่งเพื่อ GPU อื่น ๆ อาจเหมาะสมกว่า

เหตุผลที่ควรใช้ GGUF

GGUF ได้รับความนิยมเพราะแก้ปัญหาการดีพลอยที่พบจริงในการใช้งาน ส่วนตัวยังพบว่าสะดวกมากเมื่อต้องดีพลอยในเครื่องโดยไม่ต้องปวดหัวกับการตั้งค่ามั่วซั่ว

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

แทนที่จะต้องคิดถึงไฟล์และสคริปต์โหลดมากมาย ผู้ใช้สามารถโฟกัสที่การเลือกโมเดล เลือกระดับควอนไทซ์ และรัน inference

รันโมเดลในเครื่อง

GGUF ช่วยให้รัน LLM บนเครื่องของตนเองได้ ซึ่งหมายถึง:

• ไม่มีค่าใช้จ่ายแบบคิดตามโทเคนสำหรับ API
• ไม่ต้องพึ่งผู้ให้บริการ inference แบบโฮสต์
• ไม่ต้องส่งพรอมป์ต์ไปยัง API ของบุคคลที่สาม
• สามารถทำ inference แบบออฟไลน์หลังดาวน์โหลดโมเดลแล้ว

สิ่งนี้มีประโยชน์เป็นพิเศษสำหรับเวิร์กโฟลว์ที่อ่อนไหวต่อความเป็นส่วนตัว นักพัฒนามักไม่อยากส่งโค้ดกรรมสิทธิ์ เอกสารภายใน ข้อมูลลูกค้า หรือพรอมป์ต์ลับ ไปยัง API ภายนอก

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

หากอยากฝึกปฏิบัติรันโมเดลในเครื่อง ดูคู่มือของเราที่ การให้บริการ Mistral Medium 3.5 ด้วย SGLang, รัน DeepSeek V4 Flash ในเครื่อง, รันโมเดล Bonsai 1-bit ที่มีประสิทธิภาพบนแล็ปท็อปเก่า และ รัน MiniMax M2 ในเครื่องเป็นผู้ช่วยเขียนโค้ด

ยืดหยุ่นด้านฮาร์ดแวร์

GGUF มีประโยชน์เพราะทำงานได้กับการจัดวางฮาร์ดแวร์ที่หลากหลาย

ขึ้นกับรันไทม์และแบ็กเอนด์ โมเดล GGUF สามารถรันบน:

• เครื่องที่ใช้เฉพาะ CPU
• GPU ของ NVIDIA ผ่าน CUDA
• Apple Silicon ผ่าน Metal
• GPU ของ AMD ผ่าน HIP หรือ Vulkan
• GPU ของ Intel ผ่าน SYCL หรือ Vulkan
• บางสภาพแวดล้อม ARM และมือถือ

ความยืดหยุ่นนี้คือเหตุผลหลักที่ llama.cpp ทรงอิทธิพล มันไม่ได้ถูกออกแบบมาเพื่อ GPU เซิร์ฟเวอร์ระดับไฮเอนด์เท่านั้น แต่เพื่อให้การ inference ในเครื่องทำได้บนฮาร์ดแวร์หลากหลาย

เช่น ผู้ใช้ Mac อาจพึ่งการเร่งด้วย Metal ขณะที่ผู้ใช้เดสก์ท็อป Linux อาจใช้ CUDA หรือ Vulkan ผู้ใช้เฉพาะ CPU ก็ยังรันโมเดลควอนไทซ์ที่เล็กลงได้ แม้ความเร็วการสร้างข้อความจะช้ากว่า

ระบบนิเวศที่รองรับกว้างขวาง

GGUF ได้รับการรองรับจากเครื่องมือ inference ในเครื่องจำนวนมาก ตัวอย่างเช่น:

• llama.cpp สำหรับการใช้งานผ่านคอมมานด์ไลน์และเซิร์ฟเวอร์
• Ollama สำหรับการจัดการโมเดลผ่าน CLI และการเข้าถึง API
• LM Studio สำหรับอินเทอร์เฟซเดสก์ท็อปแบบ GUI
• GPT4All สำหรับแชทในเครื่องที่เน้นความเป็นส่วนตัว
• KoboldCpp สำหรับเวิร์กโฟลว์ roleplay และการสร้างข้อความในเครื่อง
• Jan และ Open WebUI สำหรับอินเทอร์เฟซ AI ในเครื่อง

สิ่งนี้สำคัญเพราะผู้ใช้ไม่ถูกล็อกให้อยู่กับอินเทอร์เฟซเดียว รูปแบบโมเดลเดียวกันสามารถใช้ในเวิร์กโฟลว์ต่างกันได้

นักพัฒนาอาจ benchmark โมเดลด้วย llama.cpp แชทกับมันใน LM Studio ให้บริการผ่าน Ollama และเชื่อมต่อกับ UI บนเบราว์เซอร์ผ่าน Open WebUI

การแจกจ่ายบน Hugging Face

Hugging Face กลายเป็นศูนย์กลางสำคัญในการแจกจ่ายโมเดล GGUF

ที่มา: Hugging Face

โมเดล open-weight ยอดนิยมจำนวนมากจะมีชุมชนอัปโหลดเวอร์ชัน GGUF ตามออกมาไม่นานหลังเปิดตัว โดยมักมีตัวเลือกการควอนไทซ์หลายแบบให้ผู้ใช้เลือกให้เหมาะกับฮาร์ดแวร์

เวอร์ชันอัปโหลดที่พบบ่อย ได้แก่:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0
• IQ4_XS
• IQ3_M
• IQ2_XXS

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

คุมขนาด-คุณภาพได้ละเอียด

GGUF ให้ผู้ใช้ควบคุมสมดุลขนาด-คุณภาพได้ละเอียด เลือกได้ว่า:

• ควอนไทซ์เล็กลงสำหรับเครื่องหน่วยความจำน้อย
• ควอนไทซ์ระดับกลางสำหรับการใช้งานประจำที่สมดุล
• ควอนไทซ์บิตสูงขึ้นสำหรับงานเขียนโค้ด การให้เหตุผล หรือเอาต์พุตเชิงโครงสร้าง
• ความละเอียดเต็มหรือใกล้เต็มเมื่อหน่วยความจำไม่ใช่ข้อจำกัด

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

GGUF ทำงานอย่างไร?

ไฟล์ GGUF ถูกจัดเป็นสามส่วนหลัก:

1. เฮดเดอร์
2. เมตาดาตาและข้อมูลเทนเซอร์
3. ข้อมูลเทนเซอร์

โครงสร้างที่แน่นอนถูกกำหนดโดยสเปค GGUF แนวคิดสำคัญคือเมตาดาตาและข้อมูลเทนเซอร์จะมาก่อนข้อมูลเทนเซอร์ดิบ ทำให้รันไทม์เข้าใจสิ่งที่กำลังจะโหลดได้

เฮดเดอร์

เฮดเดอร์ระบุว่าไฟล์เป็น GGUF และบอกวิธีที่รันไทม์จะพาร์สส่วนที่เหลือของไฟล์ ประกอบด้วย:

• Magic number ของ GGUF
• เวอร์ชันของรูปแบบ
• จำนวนเทนเซอร์
• จำนวนคีย์-แวลูของเมตาดาตา

ไฟล์ GGUF สมัยใหม่มักใช้เวอร์ชัน GGUF 3

เอนจิน inference จะเช็ก magic number ก่อน หากไฟล์ไม่ได้เริ่มด้วยตัวระบุ GGUF ที่คาดไว้ รันไทม์จะปฏิเสธก่อนที่จะพยายามพาร์สเทนเซอร์หรือจองหน่วยความจำ

นี่เป็นขั้นตอนง่าย ๆ แต่สำคัญต่อความปลอดภัยและความเชื่อถือได้ ป้องกันไม่ให้รันไทม์เผลอปฏิบัติต่อไฟล์ไบนารีที่ไม่เกี่ยวข้องว่าเป็นโมเดล

คู่คีย์-แวลูของเมตาดาตา

เมตาดาตาใน GGUF เป็นสโตร์คีย์-แวลูแบบระบุชนิด สามารถอธิบายได้ว่า:

• ข้อมูลทั่วไปของโมเดล
• ตระกูลสถาปัตยกรรม
• ความยาวคอนเท็กซ์
• ขนาด embedding
• จำนวนเลเยอร์
• จำนวนหัวของ attention
• พารามิเตอร์ RoPE
• คลังคำของ tokenizer
• โทเคนพิเศษ
• ข้อมูลการควอนไทซ์

คีย์โดยมากถูกเนมสเปซ ตัวอย่างเช่น:

• general.architecture
• general.alignment
• llama.context_length
• tokenizer.ggml.tokens

การเนมสเปซสำคัญเพราะช่วยให้ GGUF รองรับสถาปัตยกรรมหลายแบบได้โดยไม่ต้องเปลี่ยนทั้งรูปแบบไฟล์ โมเดลตระกูล LLaMA ใช้คีย์ llama.* ขณะที่ตระกูลอื่นใช้เมตาดาตาเฉพาะของตนเอง

นี่เป็นเหตุผลหนึ่งที่ GGUF ปรับตัวได้ดีกับโมเดลนอกตระกูล LLaMA ดั้งเดิม รวมถึงสถาปัตยกรรมอย่าง Qwen, Mistral, Gemma, DeepSeek, Phi และอื่น ๆ

ข้อมูลเทนเซอร์และข้อมูลเทนเซอร์จริง

หลังเมตาดาตา ไฟล์จะเก็บข้อมูลเทนเซอร์และข้อมูลเทนเซอร์จริง

ข้อมูลเทนเซอร์อธิบายว่า:

• ชื่อเทนเซอร์
• รูปร่าง
• ชนิดข้อมูล
• ออฟเซ็ตไปยังส่วนข้อมูลเทนเซอร์

ส่วนข้อมูลเทนเซอร์ประกอบด้วยน้ำหนักโมเดลจริง ๆ น้ำหนักเหล่านี้อาจถูกเก็บในความละเอียดเต็มหรือหนึ่งในชนิดเทนเซอร์แบบควอนไทซ์ที่ GGUF รองรับ

GGUF ใช้ค่า alignment ที่ระบุในเมตาดาตา โดยทั่วไปคือ general.alignment ไฟล์ GGUF จำนวนมากใช้ alignment 32 ไบต์ แต่ที่ถูกต้องคือต้องอธิบายว่า alignment ถูกควบคุมด้วยเมตาดาตา ไม่ได้ฮาร์ดโค้ดถาวร

alignment สำคัญเพราะช่วยให้รันไทม์เข้าถึงบล็อกเทนเซอร์ได้อย่างมีประสิทธิภาพ

Memory mapping

ข้อได้เปรียบเชิงปฏิบัติอย่างหนึ่งของ GGUF คือ memory mapping หรือ mmap

ด้วย memory mapping ระบบปฏิบัติการสามารถแมปไฟล์โมเดลเข้าสู่หน่วยความจำเสมือน แทนที่จะบังคับให้รันไทม์คัดลอกไฟล์ทั้งหมดเข้า RAM ล่วงหน้า

สิ่งนี้ทำให้เริ่มต้นโมเดลได้เร็วขึ้นมาก โดยเฉพาะบน SSD และยังเปิดโอกาสให้ระบบปฏิบัติการเพจข้อมูลโมเดลเข้าออกตามความจำเป็น

อย่างไรก็ตาม memory mapping ไม่ใช่เวทมนตร์ โมเดลยังต้องการแบนด์วิดท์หน่วยความจำและ RAM หรือ VRAM ที่เพียงพอ หากระบบต้องเพจจากดิสก์ตลอดเวลา inference อาจช้าลง

วิธีคิดเกี่ยวกับ mmap ที่ดีกว่า:

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

ทำความเข้าใจชนิดการควอนไทซ์ของ GGUF

การควอนไทซ์ บีบอัดน้ำหนักโมเดลให้เป็นตัวแทนความละเอียดต่ำลง

แทนที่จะจัดเก็บทุกน้ำหนักเป็นค่า floating-point 16 บิต โมเดลที่ควอนไทซ์จะเก็บค่าประมาณโดยใช้บิตน้อยลง ลดขนาดไฟล์บนดิสก์ การใช้ RAM และ VRAM รวมถึงแรงกดดันต่อแบนด์วิดท์หน่วยความจำ

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

การตั้งชื่อการควอนไทซ์ของ GGUF

ชื่อการควอนไทซ์ของ GGUF มักเป็นรูปแบบนี้:

• Q หมายถึง quantized
• ตัวเลขสื่อถึงจำนวนบิตต่อหนึ่งน้ำหนักโดยประมาณ
• K หมายถึงตระกูล k-quant
• S, M, และ L โดยมากหมายถึงเวอร์ชันเล็ก กลาง และใหญ่

ตัวอย่างเช่น:

• Q4_K_M
• Q5_K_M
• Q6_K
• Q8_0

ชื่อนั้นช่วยเป็นแนวทาง แต่ไม่ใช่คำบอกขนาดไฟล์จริงเสมอไป ขนาดจริงขึ้นกับส่วนผสมเทนเซอร์ สถาปัตยกรรม เมตาดาตา ขนาด tokenizer และว่าบางเทนเซอร์ถูกเก็บในความละเอียดสูงกว่าอยู่หรือไม่

ชนิดการควอนไทซ์ของ GGUF ที่พบบ่อย

ตัวเลขเหล่านี้เป็นค่าประมาณสำหรับโมเดล dense ชั้น 7B สถาปัตยกรรมใหม่ ๆ โมเดลแบบmixture-of-experts โทเคไนเซอร์ที่ใหญ่ขึ้น และเลย์เอาต์เทนเซอร์ที่ต่างกัน อาจทำให้ขนาดไฟล์จริงเปลี่ยนไป

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

Q5_K_M และ Q6_K มักเป็นตัวเลือกที่ดีกว่าสำหรับงานโหดขึ้น เช่น การเขียนโค้ดหรือการทำตามคำสั่งหลายขั้น

เหตุผลง่าย ๆ คือ งานเหล่านี้ไวต่อการเสื่อมคุณภาพเล็กน้อยมากกว่า

K-quants เทียบกับ I-quants

K-quants เป็นตระกูลการควอนไทซ์ที่ใช้กันอย่างกว้างขวาง อยู่เบื้องหลังรูปแบบอย่าง Q4_K_M, Q5_K_M และ Q6_K

พวกมันใช้สคีมควอนไทซ์แบบจัดกลุ่ม พร้อมข้อมูลสเกลที่ช่วยคงพฤติกรรมโมเดลไว้ขณะลดความต้องการหน่วยความจำ ได้รับความนิยมเพราะเชื่อถือได้ รองรับกว้าง และหาได้ง่ายในรีลีส GGUF ของชุมชน

I-quants มักเขียนเป็นรูปแบบ IQ เป็นชนิดการควอนไทซ์ใหม่ ๆ เช่น:

• IQ4_XS
• IQ3_M
• IQ2_XXS
• IQ1_S

I-quants ถูกออกแบบมาเพื่อให้คุณภาพดีกว่าที่ขนาดเล็กมาก โดยอาจใช้เทคนิคอย่างการควอนไทซ์แบบตระหนักถึงความสำคัญ และโค้ดบุ๊กการควอนไทซ์ไม่เชิงเส้น บางเวิร์กโฟลว์ใช้เมทริกซ์ความสำคัญ (imatrix) เพื่อช่วยคงน้ำหนักที่สำคัญมากกว่าไว้ระหว่างการควอนไทซ์

ข้อแลกเปลี่ยนคือความซับซ้อน I-quants สามารถให้ผลลัพธ์ขนาด-คุณภาพที่ยอดเยี่ยม โดยเฉพาะที่บิตเรตต่ำมาก แต่ต้องการเวิร์กโฟลว์การควอนไทซ์ที่พิถีพิถันและการรองรับจากรันไทม์

สำหรับผู้เริ่มต้น K-quants ยังคงเป็นจุดเริ่มที่ง่ายที่สุด

การเลือกระดับควอนไทซ์ให้เหมาะกับฮาร์ดแวร์

ตารางต่อไปนี้ให้จุดเริ่มเชิงปฏิบัติ ควรมองเป็นกฎคร่าว ๆ ไม่ใช่รับประกันแน่นอน ความยาวคอนเท็กซ์ โอเวอร์เฮดของระบบปฏิบัติการ การ offload ไป GPU ขนาดแคช KV และสถาปัตยกรรมโมเดลเฉพาะ ล้วนเปลี่ยนความต้องการหน่วยความจำได้

กฎคร่าว ๆ ทั่วไป:

• ใช้ Q4_K_M เป็นค่าเริ่มต้นที่ปลอดภัยสำหรับการ inference ในเครื่องส่วนใหญ่
• ใช้ Q5_K_M เมื่อคุณภาพสำคัญกว่าการประหยัดทุกกิกะไบต์
• ใช้ Q6_K หรือ Q8_0 เมื่อมีหน่วยความจำเพียงพอและต้องการความเที่ยงตรงที่ดีกว่า
• หลีกเลี่ยง Q2_K สำหรับงานจริงจัง เว้นแต่กำลังทดสอบสถานการณ์จำกัดหน่วยความจำขั้นสุด
• เผื่อหน่วยความจำให้แคช KV โดยเฉพาะเมื่อใช้หน้าต่างคอนเท็กซ์ยาว

แคช KV มักถูกมองข้าม โมเดลอาจพอดี RAM ที่ความยาวคอนเท็กซ์สั้น แต่ล้มเหลวหรือช้าลงมากที่ความยาวคอนเท็กซ์ยาว เพราะแคชเติบโตตามความยาวลำดับ

ระบบนิเวศของ GGUF

การนำ GGUF มาใช้ได้รับแรงขับจากเครื่องมือพอ ๆ กับตัวรูปแบบเอง

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

1. llama.cpp

llama.cpp คือรันไทม์ GGUF ดั้งเดิมและสำคัญที่สุด เป็นเอนจิน inference แบบ C/C++ น้ำหนักเบาที่สร้างโดย Georgi Gerganov และดูแลโดยชุมชน GGML เป้าหมายหลักคือทำให้ inference ของ LLM มีประสิทธิภาพด้วยการตั้งค่าน้อยที่สุดบนแพลตฟอร์มฮาร์ดแวร์หลากหลาย

llama.cpp สมัยใหม่รองรับหลายแบ็กเอนด์ รวมถึง:

• CPU
• CUDA สำหรับ GPU ของ NVIDIA
• Metal สำหรับอุปกรณ์ Apple
• Vulkan
• HIP สำหรับ GPU ของ AMD ผ่าน ROCm
• SYCL สำหรับ GPU ของ Intel
• OpenCL ในบางสภาพแวดล้อม
• แบ็กเอนด์เฉพาะทางอื่น ๆ เช่น CANN, OpenVINO และ WebGPU ขึ้นกับแพลตฟอร์ม

ยังมีเครื่องมือสำหรับแปลง ควอนไทซ์ ให้บริการ ทดสอบประสิทธิภาพ และ inference ผ่านคอมมานด์ไลน์ เครื่องมือที่พบบ่อย ได้แก่:

• convert_hf_to_gguf.py
• llama-quantize
• llama-cli
• llama-server
• llama-bench

คำสั่งเพื่อสร้าง CMake build แบบ CPU พื้นฐานคือ:

cmake -B build
cmake --build build --config Release

สำหรับบางคอนฟิก ต้องเพิ่มแฟล็กบางตัวในคำสั่งแรก:

• ปิด Apple Metal บน macOS (เปิดค่าเริ่มต้น): -DGGML_METAL=OFF
• บิลด์ Vulkan: -DGGML_VULKAN=1
• บิลด์ CUDA สำหรับ GPU NVIDIA: -DGGML_CUDA=ON

โปรดสังเกตว่าบิลด์ปัจจุบันใช้ตัวเลือก CMake แบบ GGML_* เช่น GGML_CUDA, GGML_VULKAN และ GGML_HIP

2. Ollama

Ollama เป็นหนึ่งในวิธีที่ง่ายที่สุดในการรันโมเดลในเครื่อง มอบสิ่งต่อไปนี้:

• CLI ที่เรียบง่าย
• การดึงและจัดการโมเดล
• REST API ในเครื่อง
• ไลบรารี Python และ JavaScript อย่างเป็นทางการ
• อินทิเกรตกับหน้าอินเทอร์เฟซ AI ในเครื่องมากมาย

Ollama จะจัดเก็บและจัดการโมเดลให้ ผู้ใช้จึงมักไม่ได้ยุ่งกับไฟล์ .gguf โดยตรง อย่างไรก็ดี Ollama ถูกสร้างบนการ inference ในเครื่องที่เข้ากันกับ llama.cpp และยังสามารถนำเข้าไฟล์ GGUF ผ่านเวิร์กโฟลว์ Modelfile ได้

Ollama เปิดเผย API ในเครื่องที่:

http://localhost:11434/api

เอ็นด์พอยต์ที่ใช้บ่อยสองรายการคือ:

• /api/generate สำหรับการเติมพรอมป์ต์
• /api/chat สำหรับข้อความแบบแชท

สำหรับผู้เริ่มต้น Ollama มักเป็นเส้นทางที่เร็วที่สุดจากศูนย์สู่การ inference ในเครื่อง

3. LM Studio

ที่มา: LM Studio

LM Studio คือแอปเดสก์ท็อปสำหรับค้นหา ดาวน์โหลด และแชทกับโมเดลในเครื่อง มีประโยชน์สำหรับผู้ใช้ที่ชอบอินเทอร์เฟซแบบกราฟิกมากกว่าเครื่องมือคอมมานด์ไลน์

4. GPT4All

ที่มา: GPT4All

GPT4All เป็นแอป AI ในเครื่องข้ามแพลตฟอร์มอีกตัวที่โฟกัสเวิร์กโฟลว์แชทในเครื่องและความเป็นส่วนตัว รองรับโมเดล GGUF และมอบสภาพแวดล้อมที่เป็นมิตรกับผู้เริ่มต้นสำหรับการ inference ในเครื่อง

เครื่องมือเหล่านี้ทำให้ GGUF เข้าถึงได้สำหรับผู้ที่ไม่เชี่ยวชาญ ผู้ใช้ไม่จำเป็นต้องเข้าใจ CMake เลย์เอาต์เทนเซอร์ หรือรายละเอียดภายในของการควอนไทซ์เพื่อจะลองโมเดลในเครื่อง

เริ่มต้นใช้งานโมเดล GGUF อย่างไร

มีสองวิธีปฏิบัติที่ใช้งานได้จริง:

1. ใช้ Ollama เพื่อประสบการณ์ที่ง่ายที่สุด
2. ใช้ llama.cpp โดยตรงเพื่อการควบคุมที่มากขึ้น

รันโมเดลด้วย Ollama

เวิร์กโฟลว์ที่ง่ายที่สุดคือดาวน์โหลดโมเดลและเริ่มเซสชันแชทแบบอินเทอร์แอกทีฟ:

ollama pull llama3.3
ollama run llama3.3

เรียกโมเดลจาก Python ผ่าน REST API ได้ดังนี้:

import requests

payload = {
    "model": "llama3.3",
    "prompt": "Give me three practical use cases for GGUF.",
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/generate",
    json=payload
)

print(response.json()["response"])

สำหรับแอปสไตล์แชท ให้ใช้ /api/chat:

import requests

payload = {
    "model": "llama3.3",
    "messages": [
        {"role": "user", "content": "What is GGUF used for?"}
    ],
    "stream": False
}

response = requests.post(
    "http://localhost:11434/api/chat",
    json=payload
)

print(response.json()["message"]["content"])

ฟิลด์ stream: false สำคัญสำหรับสคริปต์ง่าย ๆ หากไม่ตั้งค่านี้ Ollama จะส่งสตรีมของอ็อบเจ็กต์ JSON กลับมาแทนการตอบกลับ JSON สุดท้ายเพียงรายการเดียว

ยังสามารถใช้ ไลบรารี Python อย่างเป็นทางการของ Ollama ได้ด้วย:

from ollama import chat

response = chat(
    model="llama3.3",
    messages=[
        {"role": "user", "content": "Explain GGUF quantization simply."}
    ]
)

print(response.message.content)

รันไฟล์ GGUF ด้วย llama.cpp

หากมีไฟล์ .gguf อยู่แล้ว สามารถรันโดยตรงด้วย llama.cpp หลังจากบิลด์โปรเจ็กต์

ตัวอย่าง:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Explain the difference between GGUF and GPTQ." \
  -n 256

หากเปิดการรองรับ GPU ไว้ สามารถ offload เลเยอร์ไปยัง GPU ได้:

./build/bin/llama-cli \
  -m models/model.Q4_K_M.gguf \
  -p "Summarize GGUF in five bullet points." \
  -n 256 \
  -ngl 99

แฟล็ก -ngl ควบคุมจำนวนเลเยอร์ที่ offload ไปยัง GPU ค่าที่สูงอย่าง 99 มักใช้เพื่อ offload ให้มากที่สุดเท่าที่จะทำได้ หากโมเดลพอดีใน VRAM

สำหรับการให้บริการผ่าน API ให้ใช้ llama-server:

./build/bin/llama-server \
  -m models/model.Q4_K_M.gguf \
  -ngl 99 \
  --host 127.0.0.1 \
  --port 8080

สิ่งนี้จะให้ส่วนต่อประสานเซิร์ฟเวอร์ในเครื่องเพื่ออินทิเกรต llama.cpp เข้ากับแอปพลิเคชัน

การแปลงโมเดลจาก Hugging Face เป็น GGUF

ผู้ใช้ส่วนใหญ่ไม่จำเป็นต้องแปลงโมเดลเอง เพราะมีรีลีส GGUF ของชุมชนให้เลือกใช้อย่างแพร่หลาย

แต่การแปลงเองมีประโยชน์เมื่อ:

• ได้ไฟน์จูนโมเดลของตนเอง
• ยังไม่มีเวอร์ชัน GGUF
• ต้องการควบคุมกระบวนการควอนไทซ์เอง
• ต้องการชนิดการควอนไทซ์เฉพาะ

เวิร์กโฟลว์ทั่วไปคือ:

1. ดาวน์โหลดโมเดลจาก Hugging Face
2. แปลงเป็น GGUF
3. ควอนไทซ์ไฟล์ GGUF

ตัวอย่าง:

huggingface-cli download mistralai/Mistral-7B-Instruct-v0.3 \
  --local-dir mistral-7b

จากนั้นแปลงเป็น GGUF:

python convert_hf_to_gguf.py mistral-7b \
  --outfile mistral-f16.gguf \
  --outtype f16

จากนั้นควอนไทซ์:

./build/bin/llama-quantize \
  mistral-f16.gguf \
  mistral-q4_k_m.gguf \
  Q4_K_M

ในเวิร์กโฟลว์ llama.cpp ปัจจุบัน convert_hf_to_gguf.py และ llama-quantize เป็นเครื่องมือที่เกี่ยวข้อง บทความเก่าอาจอ้างถึงสคริปต์แปลงที่เลิกใช้แล้วหรือชื่อไบนารีเก่า

ข้อดีและข้อจำกัดของรูปแบบ GGUF

GGUF ถูกปรับให้เหมาะกับการ inference ในเครื่องเชิงปฏิบัติ ไม่ได้เป็นตัวแทนสากลสำหรับทุกรูปแบบโมเดลหรือสแตกการให้บริการ

สำหรับการ inference ที่เน้น CPU เป็นหลัก Apple Silicon ฮาร์ดแวร์แบบผสม และความเป็นส่วนตัว GGUF มักเป็นตัวเลือกที่ยอดเยี่ยม

สำหรับการให้บริการบนเซิร์ฟเวอร์ NVIDIA ที่ต้องการอัตราสูง รูปแบบและเอนจินอื่นอาจเร็วกว่าขึ้นกับโมเดล ขนาดแบตช์ วิธีควอนไทซ์ และเฟรมเวิร์กการให้บริการ

ข้อคิดทิ้งท้าย

GGUF ทำให้การ inference ของ LLM ในเครื่องเป็นเรื่องที่ทำได้จริง ด้วยการบรรจุทุกอย่างที่รันไทม์ต้องใช้ (น้ำหนัก ตัวแบ่งหน่วยคำ เมตาดาตา ข้อมูลการควอนไทซ์) ไว้ในไฟล์พกพาเพียงไฟล์เดียว จุดแข็งที่แท้จริงคือระบบนิเวศรอบตัว: llama.cpp, Ollama, LM Studio และ Hugging Face ต่างทำให้มันเป็นรูปแบบมาตรฐานสำหรับการดีพลอย AI ในเครื่อง

สำหรับผู้ใช้ส่วนใหญ่ เส้นทางง่าย ๆ คือ: ติดตั้ง Ollama ดึงโมเดล แล้วรัน Q4_K_M เป็นค่าเริ่มต้นที่ดี; ขยับไป Q5_K_M หรือ Q6_K เมื่อจำเป็นต้องได้ผลลัพธ์ด้านเหตุผลหรือการเขียนโค้ดที่ดีกว่าและมีหน่วยความจำเพียงพอ

หาก ต้องการเจาะลึกการดีพลอย LLM การปรับแต่งโมเดล และเวิร์กโฟลว์ inference ในเครื่อง ควรสำรวจเส้นทางอาชีพ Associate AI Engineer for Data Scientists หรือ Associate AI Engineer for Developers