เริ่มจากฮาร์ดแวร์ ไม่ใช่กระแสของโมเดล
วิธีที่เร็วที่สุดในการเลือก Local LLM คือเริ่มจากเครื่องที่คุณมีอยู่แล้ว ความนิยมของโมเดลมีความสำคัญ แต่โมเดลที่โหลดไม่ได้หรือทำงานช้าจนใช้งานไม่ได้ก็ไม่ช่วยอะไร อินพุตแรกที่ต้องพิจารณาคือ VRAM, RAM ของระบบ, ระบบปฏิบัติการ, หน่วยความจำเป็นแบบ unified หรือไม่ และคุณยินดีใช้ CPU offload หรือไม่ หลังจากนั้นจึงค่อยเปรียบเทียบตระกูลโมเดล
โฟลว์การแนะนำ Local LLM ที่ดีจะแยกคำถามออกเป็นสามข้อ: โหลดได้หรือไม่, ใช้งานได้จริงหรือไม่ และเหมาะกับงานหรือไม่ การโหลดขึ้นอยู่กับ weights, quantization, KV cache และโอเวอร์เฮดของ runtime ความสามารถในการใช้งานขึ้นอยู่กับความเร็วและความเสถียร ความเหมาะสมกับงานขึ้นอยู่กับว่าโมเดลได้รับการปรับแต่งมาสำหรับการเขียนโค้ด, แชตทั่วไป, คณิตศาสตร์, vision หรืองาน long-context หรือไม่
เลือกกรณีการใช้งานก่อนเลือกโมเดลที่ใหญ่ที่สุด
งานที่ต่างกันให้ผลดีกับโมเดลที่ต่างกัน งานเขียนโค้ดต้องการการฝึกด้านโค้ด ความเข้าใจ repository การทำตามคำสั่ง และการจัดรูปแบบที่เสถียร งานเขียนต้องการการควบคุมน้ำเสียงและความสอดคล้องของเนื้อหาแบบยาว งาน vision ต้องการสถาปัตยกรรมแบบ multimodal และ image encoder งานคณิตศาสตร์หรือการใช้เหตุผลอาจต้องการตระกูลโมเดลที่ปรับแต่งมาสำหรับการแก้ปัญหาแบบทีละขั้นตอน
นี่คือเหตุผลที่ฮาร์ดแวร์เดียวกันอาจให้คำแนะนำที่ต่างกันเมื่อผู้ใช้เปลี่ยนจาก General ไปเป็น Coding หรือ Vision เว็บไซต์ไม่ควรจัดอันดับแบบสุ่มตามจำนวนดาวน์โหลดหรือจำนวนพารามิเตอร์เท่านั้น ควรกรองโมเดลที่เหมาะกับฮาร์ดแวร์ก่อน จากนั้นจึงจัดอันดับตัวเลือกที่เหลือตามกรณีการใช้งานและความต้องการ
ทำความเข้าใจบทบาทของ quantization
ผู้ใช้ local ส่วนใหญ่รันโมเดลแบบ quantized แทน weights แบบ full precision Quantization ช่วยลดการใช้หน่วยความจำและทำให้โมเดลใช้งานได้จริงบนฮาร์ดแวร์สำหรับผู้บริโภค Q4 มักเป็นตัวเลือกแบบเน้นให้รันได้ก่อน Q5 และ Q6 สามารถเพิ่มคุณภาพได้โดยแลกกับต้นทุนหน่วยความจำที่สูงขึ้น และ Q8 ใกล้เคียงคุณภาพเต็มรูปแบบมากกว่าแต่หนักกว่ามาก ตัวเลือกที่เหมาะสมขึ้นอยู่กับว่าเหลือ headroom มากแค่ไหนหลังจาก weights และ KV cache
ดังนั้นวลี "what can I run" จึงไม่ได้มีคำตอบเดียวต่อหนึ่งโมเดล โมเดลหนึ่งอาจรันได้ใน Q4 แต่ไม่ใช่ Q8, ใช้งานได้ที่ context 4K แต่ไม่ใช่ 32K หรือทำงานได้ดีบน GPU เต็มรูปแบบแต่ช้าด้วย offload หน้าแนะนำที่มีประโยชน์ควรแสดง quantization ที่เลือกและการแจกแจงหน่วยความจำ ไม่ใช่แค่ชื่อโมเดล
Mac, Windows, Linux และการตั้งค่าแบบ CPU-only แตกต่างกัน
ผู้ใช้ Windows และ Linux ที่มี GPU แยกมักคิดถึง VRAM ก่อน ผู้ใช้ Apple Silicon คิดถึง unified memory เพราะ GPU และ CPU ใช้ pool หน่วยความจำเดียวกัน ผู้ใช้ CPU-only ต้องระมัดระวังยิ่งกว่า เพราะหน่วยความจำระบบอาจมีมากแต่ความเร็ว token อาจต่ำ ตัวเลข 32GB เดียวกันมีความหมายต่างกันในแต่ละการตั้งค่าเหล่านี้
เครื่องมือควรสะท้อนความแตกต่างนั้น บน Mac ควรกันหน่วยความจำไว้สำหรับ macOS และแอป บน GPU แยก ควรกัน VRAM ไว้สำหรับจอแสดงผล โอเวอร์เฮดของ framework และ KV cache บนเครื่อง CPU-only ควรแนะนำโมเดลขนาดเล็กและตั้งความคาดหวังด้านความเร็ว แทนที่จะแสร้งว่า RAM ของระบบอย่างเดียวแก้ได้ทุกอย่าง
โฟลว์การตัดสินใจที่ใช้งานได้จริง
ขั้นแรก ป้อน VRAM หรือ unified memory ของคุณ ขั้นที่สอง เลือกระบบปฏิบัติการ ขั้นที่สาม เลือกกรณีการใช้งาน ขั้นที่สี่ เลือกความต้องการ: คุณภาพ, ความพอดีแบบสมดุล หรือ context headroom จากนั้นตรวจสอบเฉพาะโมเดลที่เข้ากันได้ หากผลลัพธ์เล็กเกินไป ให้เพิ่มหน่วยความจำหรือยอมรับ offload หากผลลัพธ์ช้าเกินไป ให้เลือกโมเดลขนาดเล็กที่รันบน GPU เต็มรูปแบบ
แนวทางนี้ช่วยป้องกันไม่ให้ผู้ใช้คัดลอกคำแนะนำโมเดลแบบสุ่มจากโซเชียลมีเดีย คำแนะนำที่ใช้ได้กับ GPU 24GB อาจผิดสำหรับแล็ปท็อป 8GB โมเดลที่ยอดเยี่ยมสำหรับการเขียนโค้ดอาจไม่จำเป็นสำหรับงานเขียนทั่วไป Local LLM ควรเปลี่ยน tradeoffs เหล่านี้ให้เป็นรายการจัดอันดับที่ชัดเจนพร้อมลิงก์ Hugging Face ไปยังหน้าโมเดลจริง
FAQ
ฉันสามารถรัน Local LLM โดยไม่มี GPU ได้ไหม? ได้ แต่โดยปกติจะเป็นโมเดลขนาดเล็กกว่าและความเร็วต่ำกว่า CPU-only เหมาะที่สุดสำหรับการทดสอบ โน้ตที่อ่อนไหวด้านความเป็นส่วนตัว หรืองานออฟไลน์เบา ๆ
ฉันควรเลือกโมเดลที่ใหญ่ที่สุดที่พอดีเสมอหรือไม่? ไม่ควร โมเดลขนาดเล็กกว่าที่พอดีกับ GPU เต็มรูปแบบอาจเร็วกว่าและใช้งานสบายกว่าโมเดลขนาดใหญ่ที่แทบจะพอดี
ทำไมคำแนะนำจึงเปลี่ยนไปตามเวลา? ไฟล์โมเดลบน Hugging Face, จำนวนดาวน์โหลด, quantizations และ release จากชุมชนเปลี่ยนแปลงบ่อย ดังนั้นข้อมูลโมเดลที่ cache ไว้ควร refresh เป็นประจำ