ใช้ MLX Framework ผ่าน Ollama บน Mac โดยรุ่น qwen38-deep ต้องการ RAM 21GB สำหรับ Context 32k Token แนะนำให้ตั้งค่า Alias และตรวจสอบ KV Cache เพื่อป้องกันการ Unload โมเดลโดยอัตโนมัติ
เตรียมเครื่องและติดตั้งผ่าน Terminal
สำหรับการนำ Qwen3 มาใช้งานบน Mac ผมเลือกใช้วิธีการติดตั้งผ่าน Ollama เพราะเป็นเครื่องมือที่รองรับ MLX Framework ของ Apple ได้ดีที่สุดในตอนนี้ ขั้นตอนแรกคือการติดตั้ง Ollama แล้วทำการดึงโมเดล qwen38-chat มาทดลองใช้งานด้วยคำสั่งพื้นฐาน จากการตรวจสอบระบบของผมที่ผ่านมา พบว่าเวอร์ชัน API ของโมเดลนี้ตอบสนองสถานะ 200 ได้ดี ทำให้มั่นใจได้ว่าการเชื่อมต่อระหว่าง Local Host และโมเดลทำงานได้สมบูรณ์ สำหรับผู้ที่ต้องการความลึกของการคิด (Reasoning) มากกว่านี้ ผมแนะนำให้ดึงรุ่น qwen38-deep ซึ่งจะใช้ทรัพยากรมากกว่าแต่ให้ผลลัพธ์ที่แม่นยำกว่าในงานเชิงเทคนิค การใช้งานผ่าน Terminal ช่วยให้เราเห็น Log การทำงานได้ชัดเจนและสามารถ Debug ปัญหาได้ง่ายกว่าการใช้ GUI บางตัวที่ซ่อนรายละเอียดเหล่านี้ไว้ คุณสามารถดาวน์โหลดและติดตั้งได้จาก หน้าเว็บไซต์อย่างเป็นทางการ
การจัดการ VRAM และ Context Window ให้เหมาะกับงาน
การจัดการหน่วยความจำบน Mac ที่ใช้ระบบ Unified Memory เป็นเรื่องที่ต้องให้ความสำคัญอย่างยิ่ง เพราะเราแบ่งปันหน่วยความจำระหว่าง CPU และ GPU จากข้อมูลการทดสอบของผม โมเดล qwen38-deep มีขนาดไฟล์น้ำหนัก (Weights) อยู่ที่ 18GB ซึ่งถือว่าใหญ่พอสมควร แต่เมื่อผมพยายามจองบริบทหน้าต่าง (Context Window) ไว้สูงสุดที่ 32k token เพื่อใช้งานเอกสารขนาดใหญ่ พบว่าหน่วยความจำรวมที่ใช้งานจริงพุ่งไปถึง 21GB ส่วนที่เพิ่มขึ้นมานั้นคือ KV Cache ขนาดประมาณ 3GB ที่ต้องใช้เก็บข้อมูลการคำนวณระหว่างการสนทนา หากคุณมี Mac ที่มี RAM 16GB คุณอาจจำเป็นต้องลดความยาวบริบทลงเหลือ 16k หรือ 8k เพื่อให้เครื่องยังคงทำงานได้ลื่นไหลโดยไม่ต้อง Swap ข้อมูลไปยัง SSD ซึ่งจะทำให้ความเร็วในการ Gen Token ตกลงอย่างเห็นได้ชัด
ทดลองจริงบนเครื่องเรา
ผมได้ทำการทดสอบระบบอย่างหนักแน่นบน Mac Mini M4 Pro ในวันที่ 2 กันยายน 2026 เพื่อตรวจสอบขีดจำกัดของรุ่น qwen38-deep32k-test โดยตั้งค่าให้รองรับ Context Window ถึง 32k และใช้งาน KV Cache ขนาด 3GB ผมได้ลอง Feed Prompt ข้อมูลเข้าไปจำนวน 20049 tokens ซึ่งเป็นปริมาณข้อมูลที่ค่อนข้างมาก ผลปรากฏว่าโมเดลสามารถประมวลผลได้สำเร็จและใช้หน่วยความจำพอดีที่ 21GB ตามที่คำนวณไว้ แต่ที่น่าสนใจคือบทเรียนจากความล้มเหลวที่พบ คือ ระบบ Script predictive.sh ของผมได้ทำการสั่ง Unload โมเดลนี้ทิ้งโดยอัตโนมัติ เพราะตรวจพบว่าไม่มี Production Route ใดเรียกใช้งานโมเดลนี้โดยตรงในขณะนั้น ทำให้เสียเวลาในการโหลดโมเดลใหม่เมื่อมีคำสั่งเข้ามา นอกจากนี้ผมยังพบคำเตือนจากระบบ LiteLLM เรื่องการ Parse Tool-call args ที่ล้มเหลว ซึ่งบ่งชี้ว่าการ Config ระบบ Tools ยังต้องปรับแต่งอีกเล็กน้อยเพื่อให้รองรับคำสั่งที่ซับซ้อน
ทดสอบความสามารถภาษาไทยและ Vision
นอกเหนือจากการสนทนาข้อความแล้ว ผมยังได้ทดสอบความสามารถด้าน Vision และการรับรู้ภาษาไทยของ Qwen3 โดยเฉพาะอย่างยิ่ง ผมใช้ชุดทดสอบ Thai 5-key กับรุ่น qwen38-chat และพบว่าโมเดลสามารถตอบสนองและเข้าใจบริบทภาษาไทยได้ดีมาก พร้อมกับส่งค่ากลับมาเป็น HTTP 200 สำเร็จ ในส่วนของ Embeddings ผมทดสอบทั้ง nomic-embed-text ที่มีขนาด 768 และ embed-bge ที่ 1024 พบว่าทั้งคู่ยังคงใช้คำนำหน้า ollama/ อยู่ ซึ่งต้องระวังในการเรียกใช้งานผ่าน API สำหรับฟีเจอร์ Vision ผมได้ทำการรวมโมเดล qwen38-fast ขนาด 18GB (MLX) เข้ากับ qwen2.5vl ขนาด 7.3GB (GGUF) เพื่อให้สามารถประมวลผลภาพได้ใน Workflow เดียว การทดสอบ Smoke Vision Routes ด้วยไฟล์ PNG ขนาด 1x1 พิกเซลผ่านระบบสำเร็จ แสดงให้เห็นว่าการผสมผสานระหว่าง Framework ต่างกันอย่าง MLX และ GGUF บน Mac ทำได้จริงและยังคงเสถียรภาพไว้ได้ แม้ว่าจะต้องแลกกับการใช้พื้นที่จัดเก็บบนเครื่องเก็บข้อมูลส่วนตัวเพิ่มขึ้นก็ตาม
อยากตามงานแล็บแบบนี้ต่อ ติดตาม LINE @icafefx หรือดาวน์โหลดเครื่องมือฟรีได้ที่ redhatai.net
