เริ่มจากตระกูลโมเดล แล้วค่อยตรวจไฟล์ที่รันได้
Local LLM ไม่ได้เป็นแค่ชื่อแบรนด์อย่าง Qwen, Llama, Mistral, Gemma, DeepSeek, Phi หรือ Yi เท่านั้น ชื่อมักบอกถึงตระกูลโมเดล ส่วนไฟล์ที่คุณรันจริงอาจเป็น instruct tune, coding tune, รุ่น vision, การแปลงเป็น GGUF หรือ build ที่ quantized โดยผู้เผยแพร่ในชุมชน ไฟล์สองไฟล์ที่อยู่ในตระกูลโมเดลเดียวกันอาจทำงานต่างกัน เพราะอาจใช้ prompt template, ความยาวบริบท, วิธี quantization และสมมติฐานของ runtime ที่ต่างกัน
สำหรับเครื่องมือแนะนำ คำถามที่มีประโยชน์ไม่ใช่แค่ “โมเดลนี้เป็นที่นิยมหรือไม่?” คำถามที่ดีกว่าคือ “รุ่นที่รันได้รุ่นไหนเหมาะกับหน่วยความจำ ความคาดหวังด้านความเร็ว และงานของผู้ใช้คนนี้?” Hugging Face อาจแสดงไฟล์จำนวนมากสำหรับโมเดลเดียวกัน และเครื่องมือ local อาจรองรับเพียงบางไฟล์เท่านั้น ดังนั้น Local LLM ควรมองตัวตนของโมเดล รูปแบบไฟล์ quantization และความเหมาะสมกับฮาร์ดแวร์เป็นสัญญาณแยกกัน แทนที่จะรวมทุกอย่างไว้ในชื่อโมเดลเดียว
จำนวนพารามิเตอร์เป็นสัญญาณคุณภาพคร่าว ๆ ไม่ใช่คำตอบทั้งหมด
จำนวนพารามิเตอร์ช่วยให้เห็นขนาดโดยรวมได้อย่างรวดเร็ว โมเดล 1B หรือ 3B รันได้ง่ายกว่า และมีประโยชน์สำหรับแชตเบา ๆ การเขียนใหม่ การสรุป และการอธิบายโค้ดง่าย ๆ โมเดล 7B หรือ 8B มักเป็นจุดเริ่มต้นที่ใช้งานได้จริงสำหรับคำตอบประจำวันที่แข็งแรงขึ้น โมเดล 14B มักต้องใช้หน่วยความจำมากกว่า แต่ให้ความรู้สึกมีความสามารถมากขึ้น ส่วนโมเดล 30B, 70B และใหญ่กว่านั้นอาจดีกว่ามากสำหรับการให้เหตุผลยาก ๆ หรือการเขียนโค้ด แต่จะเข้าสู่ขอบเขตของ VRAM สูง หน่วยความจำรวมขนาดใหญ่ หรือ multi-GPU
ข้อจำกัดคือจำนวนพารามิเตอร์ไม่ได้บอกทุกอย่าง โมเดล 7B รุ่นใหม่อาจชนะโมเดล 13B รุ่นเก่าในหลายงาน โมเดล 7B ที่ tune สำหรับเขียนโค้ดอาจมีประโยชน์ต่อการพัฒนามากกว่าโมเดลแชตทั่วไปที่ใหญ่กว่า โมเดล MoE เพิ่มความซับซ้อนอีกชั้น เพราะพารามิเตอร์รวมและพารามิเตอร์ที่ active นั้นแตกต่างกัน นี่คือเหตุผลที่คำแนะนำควรรวมคุณภาพจาก benchmark, use case, พารามิเตอร์ที่ active, ความต้องการบริบท และความเหมาะสมกับหน่วยความจำ แทนที่จะจัดอันดับโมเดลที่ใหญ่ที่สุดไว้ก่อนเสมอ
GGUF, safetensors และการรองรับของเครื่องมือเป็นตัวกำหนดว่าคุณรันอะไรได้จริง
ผู้ใช้เดสก์ท็อป local จำนวนมากมองหาไฟล์ GGUF เพราะทำงานได้ดีกับเครื่องมือที่อิง llama.cpp และมีให้ใช้แพร่หลายใน Hugging Face GGUF บรรจุ weights และ metadata ของโมเดลในรูปแบบที่ออกแบบมาสำหรับ local inference และ Hugging Face รองรับการเรียกดูและโฮสต์ไฟล์ GGUF repository อื่น ๆ เผยแพร่ weights แบบ safetensors ซึ่งอาจมีไว้สำหรับ Transformers, vLLM หรือการแปลงก่อนใช้งานบนเดสก์ท็อป local ทั้งสองแบบถูกต้องได้ แต่รองรับ workflow คนละแบบ
เรื่องนี้สำคัญต่อผู้ใช้ เพราะหน้าโมเดลอาจดูน่าสนใจแต่ยังไม่สะดวกต่อการรันแบบ local Ollama, LM Studio, llama.cpp, MLX, Transformers และ vLLM ไม่ได้มีเส้นทางการโหลดโมเดลเหมือนกันทุกประการ ผลลัพธ์คำแนะนำที่ดีควรลิงก์ไปยังหน้าต้นทาง แสดงว่าโมเดลมีไฟล์ที่เป็นมิตรกับการใช้งาน local หรือไม่ และหลีกเลี่ยงการสื่อว่า repository ทุกอันบน Hugging Face รันบนแล็ปท็อปได้ง่ายเท่ากัน
Quantization เปลี่ยนการใช้หน่วยความจำและคุณภาพ
Quantization ลดความละเอียดของ weights ของโมเดล ทำให้ไฟล์เล็กลงและโหลดง่ายขึ้น Q8 ใกล้เคียงคุณภาพสูงแต่ใช้หน่วยความจำมากกว่า Q6 และ Q5 มักเป็นจุดกึ่งกลางที่มีประโยชน์ Q4 เป็นจุดเริ่มต้นทั่วไปสำหรับการใส่โมเดลขนาดใหญ่ลงในฮาร์ดแวร์ผู้บริโภค Q3 และต่ำกว่านั้นมีประโยชน์ในสถานการณ์ที่หน่วยความจำจำกัดมาก แต่ข้อแลกเปลี่ยนด้านคุณภาพจะเห็นชัดขึ้น โดยเฉพาะงานเขียนโค้ด คณิตศาสตร์ การใช้เครื่องมือ และคำตอบยาว ๆ
Quantization ที่เหมาะสมขึ้นอยู่กับทั้งโมเดลและงาน หากผู้ใช้ต้องการแชตทั่วไปที่รวดเร็ว Q4 อาจยอมรับได้ หากต้องการเขียนโค้ดหรือให้เหตุผลอย่างรอบคอบ Q5, Q6 หรือ Q8 อาจคุ้มกับหน่วยความจำที่เพิ่มขึ้น หากต้องการบริบทยาว ไฟล์โมเดลที่เล็กที่สุดอย่างเดียวไม่พอ ระบบยังต้องใช้หน่วยความจำสำหรับ KV cache และ overhead ของ runtime ด้วย Local LLM ควรแสดง quantization ที่เลือกและรายละเอียดการใช้หน่วยความจำ เพื่อให้ผู้ใช้เข้าใจว่าทำไมคำแนะนำนั้นจึงเหมาะสม
ความยาวบริบท vision และการ tune เฉพาะทางเปลี่ยนคำแนะนำ
ความยาวบริบทขึ้นอยู่กับโมเดล แต่บริบทที่ใช้งานได้จริงขึ้นอยู่กับฮาร์ดแวร์ โมเดลอาจโฆษณาว่ามี context window ขนาดใหญ่ แต่ KV cache จะเพิ่มขึ้นเมื่อบทสนทนาหรือเอกสารยาวขึ้น หน่วยความจำเพิ่มเติมนี้อาจทำให้โมเดลจากที่รันเต็มบน GPU กลายเป็นต้อง offload บางส่วนไปยัง CPU สำหรับ RAG การวิเคราะห์ codebase หรือการอ่านเอกสารยาว โมเดลที่เล็กกว่าแต่มีพื้นที่หน่วยความจำเหลือมากกว่า อาจดีกว่าโมเดลที่ใหญ่กว่าแต่โหลดได้แบบเฉียดฉิว
ความสามารถเฉพาะทางก็สำคัญเช่นกัน โมเดล vision ต้องใช้ image encoder และการรองรับ multimodal ดังนั้นไม่ควรแนะนำโมเดล text-only สำหรับงานภาพ แม้จะมีคะแนนทั่วไปสูงก็ตาม โมเดลเขียนโค้ดควรถูกประเมินต่างจากโมเดล roleplay โมเดลคณิตศาสตร์และการให้เหตุผลอาจต้องมีเกณฑ์คุณภาพที่รอบคอบกว่า ดังนั้นโมเดล local ที่ดีที่สุดคือการจับคู่ระหว่างความสามารถของโมเดล รุ่นไฟล์ quantization เป้าหมายบริบท และฮาร์ดแวร์ของผู้ใช้
FAQ
โมเดล GGUF ดีกว่าสำหรับ local LLM เสมอหรือไม่? ไม่เสมอไป GGUF สะดวกมากสำหรับ local inference แบบ llama.cpp แต่ safetensors หรือรูปแบบอื่นอาจดีกว่าสำหรับ workflow ฝั่ง server, การ training หรือ runtime เฉพาะทาง
ควรเลือกโมเดลที่ใหญ่ที่สุดที่รันได้หรือไม่? ไม่ใช่โดยอัตโนมัติ หากมันรันได้แบบเฉียดฉิว ความเร็วและเสถียรภาพของบริบทอาจแย่ โมเดลที่เล็กลงเล็กน้อยพร้อม Q5 หรือ Q6 และมีพื้นที่หน่วยความจำเหลือพอ อาจรู้สึกดีกว่าในการใช้งานประจำวัน
ทำไมเครื่องมือต่างกันจึงแนะนำโมเดลต่างกัน? เครื่องมือเหล่านั้นอาจรองรับรูปแบบไฟล์ ระดับ quantization, GPU backend, ค่าเริ่มต้นของบริบท และแค็ตตาล็อกโมเดลที่ต่างกัน การรองรับของเครื่องมือเป็นส่วนหนึ่งของคำแนะนำ
หลังอ่านบทความนี้ควรใช้ Local LLM อย่างไร? ใส่ VRAM, RAM, ระบบปฏิบัติการ, use case และความชอบของคุณ จากนั้นเครื่องมือจะจัดอันดับรุ่นโมเดลปัจจุบัน แทนที่จะบังคับให้คุณจำชื่อโมเดลเอง