คู่มือการรัน Qwen3.5 บนเครื่องโลคัล

 (unsloth.ai)
33 คะแนน โดย GN⁺ 2026-03-09 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซีรีส์โมเดล Qwen3.5 ของ Alibaba มีหลายขนาดตั้งแต่ 0.8B ถึง 397B และรองรับ การให้เหตุผลแบบไฮบริดหลายโมดัล พร้อม คอนเท็กซ์ 256K
  • Unsloth เผยแพร่โมเดล Qwen3.5 ทั้งหมดในรูปแบบ Dynamic 2.0 GGUF quantization และสามารถรันบนเครื่องโลคัลผ่าน llama.cpp หรือ LM Studio ได้
  • สามารถสลับระหว่างโหมด thinking และ non-thinking ได้ โดยโมเดลขนาดเล็ก (0.8B~9B) จะถูกตั้งค่าเป็นโหมด non-thinking ตามค่าเริ่มต้น
  • มีการระบุ ปริมาณ RAM/VRAM ที่ต้องใช้ และ ค่าตั้งแนะนำ (temperature, top_p ฯลฯ) สำหรับแต่ละโมเดลอย่างชัดเจน และสามารถรันโมเดล 27B และ 35B ได้แม้ในสภาพแวดล้อม Mac 22GB
  • Unsloth GGUF ปรับปรุงประสิทธิภาพด้วย อัลกอริทึม quantization ที่ปรับปรุงแล้ว และ ข้อมูล imatrix แต่ ไม่รองรับกับ Ollama

ภาพรวมของ Qwen3.5

  • Qwen3.5 เป็น ซีรีส์ LLM ใหม่ ที่ Alibaba เปิดตัว ครอบคลุมตั้งแต่ 0.8B·2B·4B·9B (ขนาดเล็ก) ไปจนถึง 27B·35B·122B·397B (ขนาดใหญ่)
    • รองรับ การให้เหตุผลแบบไฮบริดหลายโมดัล และประมวลผลได้ถึง 201 ภาษา กับ ความยาวคอนเท็กซ์ 256K
    • ให้ประสิทธิภาพสูงในงาน agent coding, vision, conversation และงานบริบทระยะยาว
  • โมเดล 35B และ 27B สามารถรันได้แม้บน Mac ที่มี RAM 22GB
  • ไฟล์ GGUF ทั้งหมดใช้ อัลกอริทึม quantization ที่ปรับปรุงแล้ว และ ข้อมูล imatrix แบบใหม่
    • ปรับปรุงประสิทธิภาพในงานแชต โค้ดดิ้ง บริบทยาว และการเรียกใช้เครื่องมือ (tool-calling)
    • เลเยอร์ MXFP4 ถูกนำออกจาก GGUF บางรุ่น (Q2_K_XL, Q3_K_XL, Q4_K_XL)

ข้อกำหนดด้านฮาร์ดแวร์

  • ตามตาราง มีการระบุความต้องการหน่วยความจำขั้นต่ำตามขนาดโมเดลไว้อย่างชัดเจน
    • ตัวอย่าง: โมเดล 0.8B~2B ต้องใช้ 3GB, 9B ต้องใช้ 5.5GB (เกณฑ์ 3-bit), และ 35B-A3B ต้องใช้ 17GB
    • 397B-A17B ต้องใช้ 180GB ที่ 3-bit และ 214GB ที่ 4-bit
  • หน่วยความจำรวม (RAM+VRAM) ควรมากกว่าขนาดไฟล์โมเดลเพื่อให้ได้ประสิทธิภาพที่ดีที่สุด
    • หากไม่พอ ยังสามารถรันได้ด้วยการ offload ไปยัง SSD/HDD แต่ความเร็วจะลดลง
  • 27B เหมาะสำหรับผู้ที่เน้นความแม่นยำ ส่วน 35B-A3B เหมาะสำหรับผู้ที่เน้นความเร็ว

ค่าตั้งแนะนำ

  • หน้าต่างคอนเท็กซ์สูงสุด: 262,144 (ขยายได้ถึง 1M ด้วย YaRN)
  • presence_penalty: 0.0~2.0 (ใช้ลดการซ้ำ แต่หากตั้งสูงอาจทำให้ประสิทธิภาพลดลงเล็กน้อย)
  • ความยาวเอาต์พุต: แนะนำ 32,768 โทเค็น
  • ค่าตั้งจะแตกต่างกันตามโหมด Thinking และ Non-thinking
    • โหมด Thinking: งานทั่วไปใช้ temperature=1.0, งานโค้ดดิ้งใช้ 0.6
    • โหมด Non-thinking: งานทั่วไปใช้ temperature=0.7, งานให้เหตุผลใช้ 1.0
  • โมเดลขนาดเล็ก (0.8B~9B) จะปิด reasoning ไว้ตามค่าเริ่มต้น
    • หากต้องการเปิดใช้ ให้ใช้ --chat-template-kwargs '{"enable_thinking":true}'

ทิวทอเรียลการรันและการอนุมาน

  • ทุกโมเดลมีเวอร์ชัน Dynamic 4-bit MXFP4_MOE GGUF ให้ใช้งาน
  • ขั้นตอนการอนุมานบนเครื่องโลคัลด้วย llama.cpp
    • ติดตั้งเวอร์ชันล่าสุดจาก GitHub แล้วเลือก GPU/CPU ด้วยตัวเลือก -DGGML_CUDA
    • ดาวน์โหลดโมเดลจาก Hugging Face (hf download unsloth/Qwen3.5-XXB-GGUF)
    • รันด้วยคำสั่ง llama-cli หรือ llama-server
  • สามารถรันบน LM Studio ได้เช่นกัน
    • ค้นหาโมเดลแล้วดาวน์โหลด GGUF จากนั้นเปิดใช้งาน Thinking toggle ด้วยไฟล์ YAML
    • หลังรีสตาร์ตจะสามารถใช้ฟังก์ชัน toggle ได้

สรุปการรันแยกตามโมเดล

  • Qwen3.5-35B-A3B: รันแบบ Dynamic 4-bit ได้เร็วบน Mac/เครื่องที่มี RAM 24GB
  • Qwen3.5-27B: รันได้บน Mac/เครื่องที่มี RAM 18GB
  • Qwen3.5-122B-A10B: ทำงานได้ในสภาพแวดล้อม Mac/เครื่องที่มี RAM 70GB
  • Qwen3.5-397B-A17B:
    • 3-bit: ต้องใช้ RAM 192GB, 4-bit: ต้องใช้ RAM 256GB
    • เมื่อใช้ร่วมกับ GPU 24GB + RAM 256GB สามารถสร้างได้มากกว่า 25 โทเค็นต่อวินาที
    • อยู่ในระดับประสิทธิภาพใกล้เคียง Gemini 3 Pro, Claude Opus 4.5 และ GPT-5.2

เซิร์ฟเวอร์อนุมานและการเชื่อมต่อ API

  • สามารถดีพลอยผ่าน llama-server ในรูปแบบ OpenAI-compatible API ได้
    • ใช้ไลบรารี Python openai เพื่อส่งคำขอไปยังเซิร์ฟเวอร์โลคัลได้
    • ตัวอย่าง: ใช้ endpoint "http://127.0.0.1:8001/v1";
  • รองรับฟังก์ชัน Tool Calling
    • เรียกใช้ฟังก์ชันอย่างการรันโค้ด Python, คำสั่งเทอร์มินัล, การคำนวณทางคณิตศาสตร์ ฯลฯ ได้
    • มีตัวอย่างโค้ด unsloth_inference() ให้

ผลลัพธ์เบนช์มาร์ก

  • เบนช์มาร์ก Unsloth GGUF
    • Qwen3.5-35B Dynamic quant ให้ ประสิทธิภาพระดับ SOTA ในช่วงบิตส่วนใหญ่
    • มีการทดสอบ KL Divergence มากกว่า 150 ครั้ง และใช้ข้อมูล GGUF รวม 9TB
    • ที่ 99.9% KLD ให้ประสิทธิภาพสูงสุดบน Pareto Frontier
  • Qwen3.5-397B-A17B
    • ในการทดสอบภายนอกโดย Benjamin Marie
      • ต้นฉบับ 81.3%, UD-Q4_K_XL 80.5%, UD-Q3_K_XL 80.7%
      • ความแม่นยำลดลงไม่ถึง 1 จุด แต่ประหยัดหน่วยความจำได้ราว 500GB
    • Q3 ถูกเสนอเป็นตัวเลือกประหยัดหน่วยความจำ ส่วน Q4 เป็นตัวเลือกที่เสถียรกว่า

ฟีเจอร์อื่น ๆ

  • มีคำสั่งสำหรับเปิด/ปิด Reasoning (--chat-template-kwargs)
  • เชื่อมต่อกับ Claude Code / OpenAI Codex ได้
  • สามารถตั้งค่าการเรียกใช้เครื่องมือของ LLM บนเครื่องโลคัลผ่าน Tool Calling Guide ได้
  • ไม่รองรับ Ollama รองรับเฉพาะแบ็กเอนด์ที่อิงกับ llama.cpp

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
tensun 2026-03-09

ผมใช้ 27b บน hx370 อยู่ ผลลัพธ์ถือว่าใช้ได้เลย
 
GN⁺ 2026-03-09
ความคิดเห็นจาก Hacker News

  • ลองรัน Qwen3.5 9B บน ASUS 5070ti 16G ด้วย lm studio แล้วได้ประมาณ 100 tok/s ทำงานได้เสถียรมาก
    เร็วกว่าบริการ LLM ออนไลน์ส่วนใหญ่ และคุณภาพเอาต์พุตก็สอดคล้องกับระดับในเบนช์มาร์ก
    นี่เป็นครั้งแรกที่ได้รัน โมเดลที่ใช้งานจริงได้ บนฮาร์ดแวร์ฝั่งผู้บริโภคแบบนี้

    • อยากรู้ว่าที่บอกว่า “ดีกว่าบริการออนไลน์” หมายถึงเรื่องความเร็ว หรือเปรียบเทียบคุณภาพของตัวโมเดลเอง
      คิดว่าคงไม่ได้หมายถึง การเปรียบเทียบการใช้งานจริง กับโมเดลระดับบนอย่าง Sonnet หรือ Opus
    • อยากรู้ว่าในการตั้งค่านี้ ความยาว context และประสิทธิภาพอยู่ในระดับไหน
      งานเขียนโค้ดต้องการอย่างน้อย 100k context
    • แก้ปัญหา Thinking mode ได้หรือยัง?
      ของฉันมันติดลูปไม่รู้จบจนต้องปิดไป และต่อให้เปลี่ยนพารามิเตอร์หลายอย่างก็ยังไม่หาย
    • ถ้าทำ 4bit quantization ให้ Qwen3.5 27B ก็ใส่ใน VRAM 16G ได้
      คุณภาพอยู่ระดับ Sonnet 4.0 ช่วงฤดูร้อนปี 2025 และใน ik_llama.cpp ความเร็วก็ถือว่าดีมาก
    • ใช้งานร่วมกับ Claude Code หรือเปล่า?
      ดูเหมือนว่า orchestration จะสำคัญพอสมควร

  • มีข้อความว่า “All uploads use Unsloth Dynamic 2.0” แต่ในตัวเลือกจริงกลับมีทั้ง IQ4_XS, Q4_K_S, Q4_K_M และอื่น ๆ
    เลยสับสนเพราะไม่มี คำอธิบาย trade-off ของแต่ละแบบ
    ปกติฉันใช้ Qwen3-4B-Instruct-2507-Q4_K_M บน Mac mini M4 16GB เป็นหลัก แต่ Qwen3.5-4B-UD-Q4_K_XL ช่างพูดกว่ามาก
    แม้ว่าความต้องการของแต่ละคนจะต่างกัน แต่ถ้ามี ตารางสรุปการตั้งค่าตามโมเดล/ฮาร์ดแวร์และการใช้หน่วยความจำ ก็คงดีมาก
    ใน Reddit เองก็แทบไม่มีตัวอย่างการตั้งค่าที่เจาะจง
    ฉันตามประเด็นนี้มาตลอด 3 เดือนล่าสุด แต่ยิ่งเจอความสับสนมากกว่าข้อมูลที่ชัดเจน
    ตอนนี้เลยใช้ coder-model ของ qwen CLI บนคลาวด์ไปก่อน และกำลังรอ โมเดลโลคัลกินไฟต่ำ ออกมา

    • Unsloth Qwen3.5 GGUF benchmarks อาจช่วยได้
      มีการเปรียบเทียบ KL Divergence ต่อพื้นที่ดิสก์ ของ Q4_K_XL กับ Q4_K_M
      Q4_0 กับ Q4_1 เร็วก็จริงแต่ความแม่นยำตก เลยไม่ค่อยแนะนำแล้ว
      Q4_K_M กับ UD-Q4_K_XL แทบจะเหมือนกัน โดย _XL จะใหญ่กว่านิดหน่อย
    • LocalScore.ai เป็นเว็บที่ Mozilla Builders ทำขึ้นมา โดยตั้งเป้าจะทำ mapping แบบโมเดล/ฮาร์ดแวร์ลักษณะนี้
      แต่ตอนนี้ยังไม่มีข้อมูลที่เกี่ยวกับ Qwen3.5
    • ฉันลองรัน qwen3.5:4b ด้วย ollama บน Mac M1 แล้ว การเรียกใช้ทูลพอใช้ได้ แต่ช้า และจะเริ่มสับสนเมื่อเจองานซับซ้อน
      อาจเป็นเพราะต้องจัดการกับโค้ด Rust
      ตอนรัน qwen3.5-35b-a3b แบบ quantized 6bit บน 4090 กลับได้ผลค่อนข้างดี
      ตอนนี้ใช้ qwen3.5-27b แบบ 8bit เป็นเอนจินหลักอยู่และค่อนข้างพอใจ
    • คู่มือเลือก model quantization ก็เป็นอีกแหล่งที่น่าอ้างอิง

  • ทุกครั้งที่มีโอเพนโมเดลใหม่ออกมา ฉันจะทดสอบความเร็ว PP (prompt processing) และ TG (token generation) ด้วย llama-cpp/server
    ทดลองบน M1 Max 64GB MacBook ในสภาพแวดล้อม Claude Code (context 15~30K)
    Qwen3.5-30B-A3B มีความเร็ว TG แค่ประมาณครึ่งเดียวของ Qwen3-30B-A3B
    Qwen3.5 ใช้ RAM น้อยเพราะมี sliding window attention และคุณภาพคำตอบก็ดี แต่ที่ context 33k ความเร็วจะช้า
    รายละเอียดการตั้งค่าถูกรวบรวมไว้ในเอกสารนี้

  • ในเบนช์มาร์กส่วนตัว ใช้ Claude Opus เป็นผู้ประเมินโดยอ้างอิงจาก DeepSeek API
    Qwen3.5 35B A3B(q8_0, thinking) ได้ 92.5% และ Q4_K_M(thinking) อยู่ที่ประมาณ 90%
    แปลกใจเหมือนกัน เพราะคิดว่าโมเดล dense 27B น่าจะได้สูงกว่า
    แต่ตัวเลขนี้เป็นการประเมิน คำตอบแบบ one-shot เลยยังไม่สะท้อนสถานการณ์ที่มีการวนลูปแบบเอเจนต์

    • ที่ 35B A3B ออกมาสูงกว่า 27B น่าสนใจดี
      เป็นไปได้ว่า ความไม่สอดคล้องเชิงตรรกะ ในพรอมป์ต์ไปรบกวนการให้เหตุผลของ 27B
      ถ้าดู thinking trace ก็น่าจะช่วย debug สาเหตุได้
    • อยากรู้เหมือนกันว่ามี โมเดล thinking ที่แทบไม่เพิ่ม latency หรือไม่

  • ฉันลองใช้ Qwen3.5 9B บน CPU สำหรับงาน OCR และจัดระเบียบข้อความ แล้วพบว่าใช้ได้ค่อนข้างดี
    แต่ GPU offloading ทำงานไม่ถูกต้อง ทำให้บน 1650 Ti ที่มี VRAM 4GB เกิดหน่วยความจำล้น

    • ฉันก็เจอปัญหาเดียวกัน แต่แก้ได้ด้วย การอัปเดตไดรเวอร์
      ใช้คำสั่ง sudo apt install nvidia-driver-570 ได้เลย
    • บนชุด 1660ti + cachyos + llama.cpp-cuda มันทำงานได้ดี
      โมเดล 35B ทำงานด้วยความเร็วใกล้กับโมเดล 4B แต่ทรงพลังกว่ามาก
      เพียงแต่ qwen3.5 มี ความเร็วแค่ครึ่งเดียว ของ qwen3
      ถึงอย่างนั้นโดยรวมก็ยังพอใจ
    • ถ้าคอมไพล์จากซอร์ส Vulkan backend คือวิธีที่ง่ายที่สุดสำหรับ GPU offloading

  • ฉันกำลังรัน Qwen3.5:0.8b บน Orangepi Zero 2w โดยใช้ CPU อย่างเดียวได้ดี
    ถ้าอยากใช้ Vulkan GPU ก็จะรัน qwen3.5:2b บน Meta Quest 3 ผ่าน zeroclaw
    ทำให้ประหยัดเงินไปได้หลายร้อยดอลลาร์ในสภาพแวดล้อมพลังงานต่ำ
    แนะนำให้ลองรันโมเดลโลคัลบน มือถือ Android มือสอง

  • อยากรู้ว่ามีที่ไหน ให้บริการโฮสต์ โมเดล 9B บ้างไหม
    ในสภาพแวดล้อมธุรกิจที่เช่า GPU ยาก OpenRouter เลยไม่มีโมเดลเล็ก
    ถ้ามีเทมเพลต runpod serverless ก็น่าจะดี
    และก็อยากรู้ว่าโมเดล 9B บน 4090 จะรันแบบ 8bit หรือ 6bit ด้วย latency ต่ำ ได้ไหม

  • ฉันลองรัน Qwen3.5 35B-A3B บน RTX 3050 8GB แล้วพบว่าตอบสนองค่อนข้างดีและจัดการงานเขียนโค้ดได้ด้วย
    เวอร์ชันก่อนหน้านี้มีปัญหาติดลูประหว่างใช้ทูล แต่ดูเหมือนเวอร์ชันใหม่จะแก้แล้ว

    • มีการ offload ไปยัง RAM ของระบบหรือเปล่า
      อยากรู้ค่า tok/s ด้วย
      บนโน้ตบุ๊ก RTX 3060 ก็น่าจะใช้เป็นเซิร์ฟเวอร์โลคัลได้ดีเหมือนกัน
    • อยากรู้ว่าลองกับ ตัวอย่างงานเขียนโค้ด แบบไหนบ้าง
      ไม่คิดว่าโมเดลโลคัลจะทำได้ดีขนาดนั้น
    • ช่วยบอก ชื่อโมเดล ที่ใช้แบบเจาะจงได้ไหม

  • อยากรู้ว่าโมเดล 397B-A17B เทียบกับ Frontier เป็นอย่างไร
    คิดว่าคงต้องใช้ฮาร์ดแวร์หนักมากจนคนส่วนใหญ่รันไม่ได้

    • ฉันลองใช้ผ่าน OpenRouter แล้ว ดีมาก แต่ในบางงาน Frontier ก็ยังเหนือกว่าอยู่
      สำหรับฉัน โมเดล 122B ก็ น่าพอใจเพียงพอในแง่ความเป็นส่วนตัวและการประหยัดค่าใช้จ่าย

  • อยากรู้ว่าโมเดลนี้จะรันได้ไหมบนเซิร์ฟเวอร์ 4xV100 Tesla รุ่นเก่า
    การตั้งค่าที่เกี่ยวกับ fp ค่อนข้างซับซ้อนจนสำหรับมือใหม่แล้วเข้าใจยาก