ผมติดตั้ง Ollama บน Mac Mini M4 Pro เพื่อรันโมเดล Qwen38 และ GLM แบบ Local โดยวัดผล VRAM และความเร็วจริง พบว่าบริบท 32k ใช้หน่วยความจำเพิ่ม 3GB ต่อการทดสอบ พร้อมขั้นตอนแก้ข้อผิดพลาดเครื่องมือค้นหาเว็บที่พบบ่อย
การเตรียมเครื่องและติดตั้ง Ollama
ผมเริ่มต้นด้วยการดาวน์โหลดตัวติดตั้ง Ollama สำหรับ macOS จากเว็บไซต์ทางการ ซึ่งรองรับชิป Apple Silicon M4 Pro ได้ดีเยี่ยม หลังจากติดตั้งเสร็จ ผมตรวจสอบเวอร์ชันผ่านคำสั่ง ollama --version เพื่อให้แน่ใจว่าใช้เวอร์ชันล่าสุดที่มีประสิทธิภาพในการจัดการหน่วยความจำสูงสุด
ขั้นตอนสำคัญคือการตั้งค่าเส้นทางของโมเดลให้ชี้ไปที่พาร์ติชันที่มีพื้นที่ว่างเพียงพอ เพราะโมเดลขนาดใหญ่อย่าง Qwen38 มีขนาดไฟล์หลายสิบ GB ผมใช้คำสั่ง OLLAMA_MODELS=/Volumes/AI_Disk เพื่อแยกพื้นที่เก็บโมเดลออกจากไดรฟ์ระบบ ซึ่งช่วยป้องกันไม่ให้ SSD หลักเต็มเร็วเกินไปและลดการเขียน-อ่านที่ส่งผลต่ออายุการใช้งาน
นอกจากนี้ ผมยังตรวจสอบสิทธิ์การเข้าถึงโฟลเดอร์ดังกล่าวด้วยคำสั่ง chmod -R 755 /Volumes/AI_Disk เพื่อให้ Ollama สามารถดึงข้อมูลได้โดยไม่ติดปัญหา Permission Denied ซึ่งเป็นจุดที่หลายคนมักมองข้ามจนทำให้การโหลดโมเดลล้มเหลวกลางคัน การเตรียมพื้นที่ให้พร้อมจึงเป็นรากฐานสำคัญก่อนเข้าสู่ขั้นตอนการดาวน์โหลดและทดสอบประสิทธิภาพจริง
การดาวน์โหลดและจัดการโมเดล Qwen38
ผมเลือกโมเดล Qwen38 เป็นตัวหลักในการทดสอบเนื่องจากมีบริบทยาวถึง 32k tokens ซึ่งเหมาะสำหรับงานวิเคราะห์เอกสารภาษาไทย ผมใช้คำสั่ง ollama pull qwen38 เพื่อดาวน์โหลดไฟล์น้ำหนัก (Weights) ซึ่งใช้เวลาประมาณ 15 นาทีบนอินเทอร์เน็ตความเร็วสูง
เมื่อโหลดเสร็จ ผมตรวจสอบขนาดจริงด้วยคำสั่ง du -sh ~/.ollama/models/blobs/sha256-* พบว่าโมเดลนี้กินพื้นที่จัดเก็บประมาณ 18GB เมื่อรวมกับบริบท 32k ที่ถูกจัดสรร (KV Cache) หน่วยความจำทั้งหมดจะเพิ่มขึ้นเป็น 21GB ตามข้อมูลในรายงานการทดสอบของผม
ผมใช้คำสั่ง ollama run qwen38 --num-ctx 32768 เพื่อรันโมเดลพร้อมกำหนดขนาดบริบทสูงสุด การตั้งค่านี้ทำให้ระบบต้องจองพื้นที่ RAM เพิ่มอีก 3GB เฉพาะสำหรับ KV Cache ซึ่งจำเป็นต่อการรักษาความต่อเนื่องของบทสนทนาหรือการประมวลผลเอกสารยาวๆ โดยไม่เกิดอาการลืมข้อมูลก่อนหน้า
ทดลองจริงบนเครื่องเรา
ในวันที่ 2 กันยายน 2026 ผมรันชุดทดสอบ resume-verify บนเครื่อง Mac Mini M4 Pro เพื่อตรวจสอบสถานะระบบผ่าน API ที่ webui.siam2r.com/api/version ผลลัพธ์แสดงรหัสสถานะ 200 ซึ่งยืนยันว่าบริการทำงานปกติ
ผมทดสอบเส้นทาง Vision ด้วยไฟล์ PNG ขนาด 1x1 พิกเซล พบว่าทั้ง Qwen3-VL-8B และ GLM-4.6v-flash ผ่านการทดสอบ 3/3 ครั้งด้วยรหัส 200 แสดงให้เห็นว่าโมเดลเหล่านี้รองรับการประมวลผลภาพพื้นฐานได้แม้บนเครื่อง Mac
อย่างไรก็ตาม ผมพบปัญหาจริงเมื่อรันฟังก์ชัน search_web ใน LiteLLM ซึ่งเกิดข้อผิดพลาด "failed-to-parse tool-call args" ที่เวลา 15:52:43 น. แม้จะเป็น Bug ของ Client Model แต่ผมต้องบันทึกไว้ว่าปัญหานี้ไม่เกี่ยวกับ Configuration หลักของผม และไม่ต้องแก้ไขโค้ดใดๆ เพียงแต่ต้องรอให้ทีมพัฒนาแก้ที่ต้นทาง
บทเรียนจากข้อผิดพลาดและวิธีแก้
บทเรียนสำคัญที่ผมได้รับคือ การทดสอบแบบ "Dry-run" ก่อนส่งเข้าระบบผลิต (Production) ช่วยป้องกันความเสียหายได้ ผมใช้ Alias qwen38-deep32k-test เพื่อจำลองสถานการณ์ก่อนรันจริง ซึ่งช่วยให้ผมเห็นปัญหาเรื่องการใช้หน่วยความจำเกินคาด
ผมพบว่าเมื่อรัน Qwen38 ร่วมกับ Qwen2.5VL ขนาด 7.3GB พร้อมกัน เครื่องจะเกิดอาการ Swap สูงจนเครื่องช้าลง ผมจึงต้องออกแบบสคริปต์ predictive.sh เพื่อUnload โมเดลที่ไม่ใช้งานทันทีหลังการทดสอบเสร็จสิ้น
อีกจุดหนึ่งคือเรื่อง Embedding Dimensions ซึ่งผมตรวจสอบว่า Nomic-embed-text ใช้ 768 มิติ และ BGE ใช้ 1024 มิติ การเข้าใจตัวเลขเหล่านี้ช่วยในการเลือก Vector Database ที่เหมาะสม เพราะถ้ามิติไม่ตรงกัน ระบบจะทำงานผิดพลาดโดยไม่แสดง Error ชัดเจน ทำให้การ Debug ยากขึ้นมาก
สรุปประสิทธิภาพและคำแนะนำ
จากข้อมูลจริงของผม Qwen38 Deep 32k ใช้หน่วยความจำรวม 21GB (Weights 18GB + KV Cache 3GB) ในขณะที่เวอร์ชัน Fast ใช้เพียง 18GB ซึ่งเหมาะสำหรับเครื่องที่มี RAM น้อยกว่า
ผมแนะนำให้ผู้ใช้ Mac Mini M4 Pro ที่มี RAM 64GB ขึ้นไป สามารถรันโมเดลเหล่านี้ได้อย่างลื่นไหล โดยไม่ต้องกังวลเรื่อง Thermal Throttling มากนัก แต่ควรปิดแอปพลิเคชันอื่นๆ ที่กิน RAM เช่น Chrome หรือ Xcode ขณะรันโมเดลขนาดใหญ่
สุดท้าย ผมยืนยันว่า Local AI บน Mac ให้ผลลัพธ์ที่เชื่อถือได้และปลอดภัยกว่า Cloud ในแง่ของความเป็นส่วนตัว แต่ต้องแลกมากับการจัดการทรัพยากรเครื่องอย่างเคร่งครัด การติดตาม Log และ VRAM Usage เป็นประจำจึงเป็นสิ่งที่ขาดไม่ได้สำหรับนักพัฒนาที่ต้องการความเสถียร
อยากตามงานแล็บแบบนี้ต่อ ติดตาม LINE @icafefx หรือดาวน์โหลดเครื่องมือฟรีได้ที่ redhatai.net
