คู่มือการ Fine-tuning Qwen3.5

 (unsloth.ai)
16 คะแนน โดย GN⁺ 2026-03-06 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตระกูลโมเดล Qwen3.5 (0.8B~122B) สามารถทำ การ fine-tuning แบบข้อความและวิชัน ได้ด้วย Unsloth ซึ่งเป็นโอเพนซอร์สเฟรมเวิร์กสำหรับ LLM fine-tuning และ reinforcement learning
  • Unsloth ให้ ความเร็วในการเทรนมากกว่า FlashAttention-2 1.5 เท่า และ ลดการใช้ VRAM ลง 50% พร้อมรองรับการเทรนอย่างมีประสิทธิภาพด้วยการตั้งค่า bf16 LoRA
  • สามารถทดลองโมเดล 0.8B, 2B, 4B ได้ฟรีผ่าน Colab notebook และยังมี notebook สำหรับโมเดล 27B·35B บนสภาพแวดล้อม A100 ให้ด้วย
  • โมเดล MoE (35B, 122B เป็นต้น) รองรับ การเทรนเร็วขึ้น 12 เท่า, ใช้ VRAM น้อยลง 35%, และ ความยาวคอนเท็กซ์มากขึ้น 6 เท่า ด้วยเคอร์เนลรุ่นล่าสุด
  • หลังเทรนเสร็จ สามารถส่งออกโมเดลไปเป็นฟอร์แมตสำหรับดีพลอยได้หลากหลาย เช่น GGUF, vLLM, Ollama, LM Studio, SGLang

ภาพรวมการปรับจูน Qwen3.5

  • ตระกูลโมเดล Qwen3.5 (0.8B, 2B, 4B, 9B, 27B, 35B‑A3B, 122B‑A10B) สามารถทำการปรับจูนด้วย Unsloth ได้
    • รองรับทั้งข้อความและวิชัน
    • Qwen3.5‑35B‑A3B bf16 LoRA ทำงานได้บน VRAM 74GB
  • Unsloth ให้ ความเร็วในการเทรน 1.5 เท่า และ ใช้ VRAM น้อยลง 50%
    • การใช้ VRAM: 0.8B(3GB), 2B(5GB), 4B(10GB), 9B(22GB), 27B(56GB)
  • สามารถทดลองโมเดล 0.8B, 2B, 4B ได้ผ่าน Google Colab notebook ฟรี
  • เพื่อ คงความสามารถด้านการให้เหตุผล แนะนำให้จัดชุดข้อมูลที่มีตัวอย่าง reasoning มากกว่า 75%
  • รองรับ Full Fine-Tuning(FFT) เช่นกัน แต่การใช้ VRAM จะเพิ่มขึ้น 4 เท่า

สภาพแวดล้อมและการตั้งค่าสำหรับการเทรน

  • Qwen3.5 เป็นโมเดลหลายภาษาที่รองรับ 201 ภาษา
  • รองรับ Reinforcement Learning(RL) และ Vision RL(VLM RL) ผ่าน Unsloth
  • มี A100 Colab notebook สำหรับ Qwen3.5‑27B, Qwen3.5‑35B‑A3B
  • หากเทรนบนเครื่องโลคัล ต้องอัปเดตเป็นเวอร์ชันล่าสุด
    • คำสั่ง: pip install --upgrade --force-reinstall --no-cache-dir unsloth unsloth_zoo
  • จำเป็นต้องใช้ transformers v5 โดยเวอร์ชันเก่าจะไม่ทำงาน
  • การคอมไพล์ Mamba Triton kernel อาจทำให้การเทรนช่วงแรกช้าลง (โดยเฉพาะ GPU T4)
  • ไม่แนะนำการเทรนแบบ QLoRA(4-bit)

การปรับจูนโมเดล MoE (35B, 122B)

  • รองรับโมเดล Qwen3.5‑35B‑A3B / 122B‑A10B / 397B‑A17B
    • เทรนเร็วขึ้น 12 เท่า, ใช้ VRAM น้อยลง 35%, คอนเท็กซ์ยาวขึ้น 6 เท่า
  • แนะนำให้ใช้ bf16 LoRA หรือ Full Fine-Tuning
  • ไม่แนะนำ MoE QLoRA 4-bit เนื่องจากข้อจำกัดของ BitsandBytes
  • Unsloth MoE kernel เปิดใช้งานเป็นค่าเริ่มต้น และสามารถสลับแบ็กเอนด์ได้ด้วย UNSLOTH_MOE_BACKEND
  • Router-layer fine-tuning ถูกปิดไว้เป็นค่าเริ่มต้นด้วยเหตุผลด้านเสถียรภาพ
  • Qwen3.5‑122B‑A10B bf16 LoRA ต้องใช้ VRAM 256GB
    • หากใช้หลาย GPU ให้ตั้งค่า device_map = "balanced" หรือดูคู่มือ multiGPU

Quickstart

  • มีตัวอย่าง SFT สำหรับข้อความอย่างเดียว (การปรับจูนแบบมีผู้สอน)
  • Qwen3.5 ใช้โครงสร้าง Causal Language Model + Vision Encoder
    • จำเป็นต้องติดตั้ง dependency สำหรับวิชัน (torchvision, pillow)
  • แนะนำให้ใช้ Transformers เวอร์ชันล่าสุด
  • การเทรนแบบ GRPO สามารถทำได้ด้วย Unsloth inference หลังปิด fast vLLM
  • หากเกิด OOM(หน่วยความจำไม่พอ)
    • ตั้งค่า per_device_train_batch_size=1 และลด max_seq_length
    • คงค่า gradient_checkpointing="unsloth" ไว้เพื่อลด VRAM และขยายคอนเท็กซ์
  • มีตัวอย่าง loader สำหรับ MoE bf16 LoRA

การปรับจูนวิชัน

  • รองรับการปรับจูนวิชันของ โมเดล Qwen3.5 แบบมัลติโมดัล
    • สามารถใช้ Qwen3-VL GRPO/GSPO RL notebook ได้ (เปลี่ยนแค่ชื่อโมเดล)
  • เลือกได้ว่าจะเทรนเฉพาะ วิชัน/ข้อความ
    • สามารถเลือกปรับจูนเฉพาะเลเยอร์ Vision, Language, Attention, MLP
    • ค่าเริ่มต้นคือเปิดทั้งหมด
  • สำหรับ การเทรนหลายภาพ ให้ดูคู่มือ multi-image vision แยกต่างหาก

การบันทึกและดีพลอยโมเดล

  • รองรับวิธีดีพลอยหลากหลาย เช่น llama.cpp, vLLM, llama-server, Ollama, LM Studio, SGLang

การบันทึกเป็น GGUF

  • Unsloth รองรับ การบันทึกเป็นฟอร์แมต GGUF โดยตรง และ อัปโหลดไปยัง Hugging Face
  • หากประสิทธิภาพระหว่าง inference ลดลง สาเหตุหลักมักมาจาก chat template หรือ EOS token ที่ไม่ถูกต้อง

การบันทึกสำหรับ vLLM

  • vLLM 0.16.0 ยังไม่รองรับ Qwen3.5
    • ต้องใช้ 0.170 ขึ้นไป หรือ Nightly เวอร์ชัน
  • สามารถบันทึกแบบ 16-bit และ บันทึกเฉพาะ LoRA adapter ได้
  • รายละเอียดเพิ่มเติมให้ดู คู่มือ inference ของ Unsloth

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

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

 
hmmhmmhm 2026-03-06

ครั้งก่อนตอนลองรัน fine-tuning ผ่านเอเจนต์ ดูเหมือนว่าปัญหา overfitting จะเกิดขึ้นบ่อยตามลักษณะของข้อมูล เลยสงสัยว่าในโน้ตบุ๊กครั้งนี้จะทำได้ด้วยการผสม LoRA/QLoRA ไหม
 
GN⁺ 2026-03-06
ความคิดเห็นบน Hacker News

  • เคยลอง fine-tune โมเดล Qwen บนฮาร์ดแวร์ NVIDIA Jetson แล้วประสิทธิภาพดีจนน่าประหลาดใจ
    เคยนำโมเดลสาย 7B หลายตัวไป deploy สำหรับงาน edge AI และพบว่ามีประโยชน์มากโดยเฉพาะในสภาพแวดล้อมอย่างการตรวจสอบในอุตสาหกรรมหรือการวิเคราะห์ค้าปลีก ที่ latency สำคัญกว่าความแม่นยำ
    ด้วยการ fine-tune แบบ LoRA ทำให้โมเดลเล็กลง พอดีกับ unified memory และความเร็วในการ inference แบบเรียลไทม์ก็เร็วพอ
    สิ่งที่น่าประหลาดใจที่สุดคือ ประสิทธิภาพด้านพลังงาน — Jetson Orin สามารถรัน inference ต่อเนื่องได้ที่ต่ำกว่า 15W และประหยัดพลังงานกว่าการวิ่งไปกลับกับคลาวด์มาก

    • คอมเมนต์นี้ดูเหมือน AI สร้างขึ้นมา
      ช่วงนี้ใน Twitter หรือ Reddit ก็เห็นคอมเมนต์แนว รูปแบบเล่าเกร็ดปลอมๆ แบบนี้บ่อย เหมือนคนจริงแต่ดูเหมือนเป็นเรื่องแต่งทั้งหมด
    • น่าสนใจ อยากรู้ว่ามี ตัวอย่างงานอุตสาหกรรม อะไรบ้างที่ยอมให้ความแม่นยำลดลงเล็กน้อยได้
    • อยากรู้ กรณีใช้งานแบบเฉพาะเจาะจง ว่าในทางปฏิบัติเขาเอาโมเดลแบบนี้ไปใช้ทำงานอะไร
    • เป็นคำถามพื้นฐาน แต่ก็อดคิดไม่ได้ว่าสำหรับงานแบบนี้ neural network แบบเดิมก็อาจเพียงพอแล้วหรือเปล่า
    • บอกว่ารันโมเดล 7B ที่ 15W เลยสงสัยว่าเป็น Orin รุ่นไหนในซีรีส์
      ระหว่าง Nano(40 TOPS), NX(100), AGX(275) ใช้ตัวไหน แล้วเคยลองโมเดลใหญ่กว่านี้บน Thor(2070) บ้างหรือไม่

  • อยากรู้กรณีใช้งานจริงที่ผู้คน fine-tune โมเดลขนาดเล็ก/กลาง แล้วนำไปใช้เอง

    • มีโพสต์สรุปเรื่องนี้บน X
      โพสต์ที่เกี่ยวข้อง
      ตัวอย่างเช่น
      1. Cursor เพิ่ม approval rate ได้ 28% ด้วย online RL (ลิงก์)
      2. Vercel ใช้ RFT กับโมเดล AutoFix (ลิงก์)
      3. Perplexity Sonar เป็นโมเดลที่ fine-tune สำหรับ Deep Research Reasoning (ลิงก์)
      4. DoorDash สร้างโมเดลดึงคุณลักษณะด้วย LoRA/QLoRA (ลิงก์)
      5. โมเดลตรวจจับน้ำท่วมของ NASA (ลิงก์)
      6. online RL สำหรับงานหุ่นยนต์
      7. รวมกรณีใช้งาน OpenAI RFT (ลิงก์)
      8. Mercor ปรับปรุงประสิทธิภาพโมเดลด้วยข้อมูลจากผู้เชี่ยวชาญ (ลิงก์)
    • เคย benchmark งานจัดหมวดหมู่เอกสารง่ายๆ กับหลายโมเดล
      เปรียบเทียบความแม่นยำและต้นทุนของโมเดลอย่าง Llama-70B, Gemma-4B, Ministral-14B
      และพบว่าโมเดล 4B ก็ให้ประสิทธิภาพที่ใช้ได้ดีทีเดียว
      แต่รู้สึกว่า สัญชาตญาณเรื่องความสัมพันธ์ระหว่างปริมาณข้อมูลกับการเพิ่มขึ้นของประสิทธิภาพ หายไปแล้ว
      กำลังลังเลว่าจะลอง fine-tune เองดีไหม
    • กำลังพิจารณา fine-tune เพื่อเพิ่มความแม่นยำในการรู้จำลายมือของตัวเอง
      โมเดลพื้นฐานก็ทำงานได้ดีอยู่แล้ว แต่เพราะ ลายมืออ่านยาก ของตัวเองจึงยังมีการอ่านผิดบ้างเป็นครั้งคราว
    • ขอแนะนำ คู่มือฝึก LLM ของบล็อก Atredis เป็นตัวอย่างที่ดี

  • ช่วงนี้ดูเหมือน ความจำเป็นของการ fine-tune LLM จะลดลงเรื่อยๆ
    โมเดลรุ่นใหม่ทำงานซับซ้อนได้ดีมากด้วยแค่ few-shot learning
    โมเดลอย่าง Qwen3.5 ที่มี context window ขนาดใหญ่ ก็ดูเหมือนใช้การออกแบบ prompt ที่ดีแทนได้เพียงพอ
    สำหรับโมเดลภาพหรือ LLM รุ่นเก่ายังมีความหมายอยู่ แต่กับ LLM ข้อความล้วนมันเริ่ม ไม่มีประสิทธิภาพคุ้มค่า มากขึ้นเรื่อยๆ

    • ถ้า fine-tune โมเดลเล็กให้เข้ากับ structured output เฉพาะทาง ก็สามารถรัน inference ปริมาณมากได้ในต้นทุนต่ำ
      การขยาย context ของโมเดลใหญ่มีต้นทุนสูงเกินไป
    • แม้ LLM จะพัฒนาไปมาก แต่ในด้านอย่าง การเรียนรู้อย่างต่อเนื่องของหุ่นยนต์ หรือ multimodal LoRA fine-tuning ก็ยังมีโอกาสอยู่อีกมาก
      การ fine-tune vision+text ก็ทำได้เหมือนใน คู่มือ Unsloth
      ต่อไปน่าจะเห็น model routing กลายเป็นเรื่องปกติ โดยในเครื่องใช้ LoRA โมเดลเล็ก แล้วโยนงานซับซ้อนไปที่คลาวด์
      ในทางปฏิบัติ DoorDash, Vercel, NASA, Cursor ฯลฯ ก็ทำ fine-tune ของตัวเองกันอยู่แล้ว
    • ฉันเคยพยายาม fine-tune โมเดลให้เข้ากับสไตล์การเขียนของตัวเอง
      ลองทั้ง Claude, Qwen, Llama, Gemma แต่ การถ่ายทอดสไตล์ ไม่ค่อยได้ผล
      แม้จะใช้คอมเมนต์ของตัวเองหลายร้อยชิ้นเป็นข้อมูลฝึก แต่ โมเดล Instruct ถูกปรับจูนมาแรงเกินไป จนแทบฝึกต่อเพิ่มไม่ได้เลย
    • สรุปสั้นๆ คือเพราะ ข้อมูลเนื้อหาผู้ใหญ่
      Qwen กรองข้อมูลประเภทนี้ออกระหว่างการฝึก จึงกู้กลับมาได้ด้วยการ fine-tune เท่านั้น
      ตัวอย่างงานที่เกี่ยวข้อง: โมเดล Qwen3 LoRA ของ chenrm
    • ในบริการจริง fine-tune ก็ยังสำคัญอยู่
      การผสมผสานระหว่าง พฤติกรรมที่กำหนดได้แน่นอนและตรวจสอบย้อนหลังได้, การลด hallucination, และ LoRA/QLoRA เพื่อลดต้นทุน มีประโยชน์มาก
      ถ้าใช้ร่วมกับ RAG และ FAISS vector DB ก็ช่วยป้องกัน context บวมเกินได้
      ในระยะยาว การจัดการ adapter ขนาดเล็ก มีประสิทธิภาพกว่าการคอยปรับ prompt มาก

  • น่าเสียดายที่มีการเปลี่ยนตัวหัวหน้าบางคนในทีม Qwen
    กังวลว่าฝ่ายบริหารใหม่ที่ เน้นธุรกิจ มากขึ้นอาจทำให้จิตวิญญาณโอเพนซอร์สอ่อนลง

  • ถ้าใช้แนวทาง RAG ที่เน้นเอกสารอย่างเดียวก็เหมือนจะพอแล้ว เลยสงสัยว่า fine-tune ให้ผลลัพธ์ดีกว่าจริงหรือไม่

    • โมเดลเฉพาะทาง เอาชนะ SOTA ได้อย่างชัดเจน
      ตัวอย่าง: FlashCheck
    • ก่อนหน้านี้ โมเดล tab-next-action ของ Cursor เป็นที่พูดถึงมาก แต่จริงๆ แล้วมันคือเวอร์ชัน fine-tune ของโมเดล 70B

  • เอกสารชุดนี้ดูเหมือนจะพูดถึงแต่ โมเดล MoE ขนาดใหญ่
    แต่ผู้ใช้ส่วนใหญ่น่าจะเล็ง โมเดลขนาดเล็ก (เช่น 9B) มากกว่า
    และโมเดลนี้ใช้ สถาปัตยกรรม Mamba แบบไฮบริด จึงน่าจะต้องพิจารณาแยกต่างหาก