Unsloth v0.1.902-beta: เทรน LoRA บนเช็กพอยต์ 4-bit (NVFP4/INT4/MXFP4) โดยไม่คลายเป็น 16-bit — Qwen3.8-27B-NVFP4 พีกลดจาก 72.9 GB เหลือ 40.2 GB

เมื่อ 1 ต.ค. 2026 (14:06 UTC) ทีม Unsloth ปล่อย v0.1.902-beta ชื่อรีลีส “Command Palette + Desktop UI/UX” แต่ของที่สำคัญที่สุดสำหรับคนทำ fine-tuning ซ่อนอยู่ในหัวข้อ Lower-memory checkpoint training คือ เช็กพอยต์ที่ถูก quantize เป็น 4-bit มาแล้ว (NVFP4, INT4 และ MXFP4) เทรน LoRA ได้โดยไม่ต้องคลายน้ำหนักออกเป็น 16-bit ก่อน release notes เขียนไว้ว่า “a loaded model needs about as much memory as its 4-bit checkpoint”

ก่อนหน้านี้ เวลาโหลดเช็กพอยต์รูปแบบ compressed-tensors (ที่ llm-compressor หรือ AutoRound เขียนออกมา) มาเทรน Unsloth จะคลายทั้งโมเดลเป็น bf16 ในหน่วยความจำก่อน ทำให้ใช้หน่วยความจำเท่ากับโมเดล 16-bit ทั้งที่ไฟล์บนดิสก์เป็น 4-bit ผลคือ GPU ใบเดียวที่ควรจะพอ กลับไม่พอ รีลีสนี้แก้ตรงนั้น ทั้งนี้แท็กยังเป็น beta (ชื่อแท็กลงท้ายด้วย -beta) และฟีเจอร์ส่วนนี้เพิ่งถูก merge เข้า main ช่วง 28–29 ก.ย. นี่เอง

ตัวเลขหน่วยความจำจากรีลีสและ PR

เช็กพอยต์ / งาน	ก่อน (คลายเป็น 16-bit)	หลัง (เก็บแบบ packed)	GPU ที่วัด
Qwen3.8-27B-NVFP4 — หน่วยความจำหลังโหลด	52.72 GB	22.22 GB	RTX PRO 6000 (96 GB)
Qwen3.8-27B-NVFP4 — พีกตอนเทรน	72.93 GB	40.15 GB	RTX PRO 6000 (96 GB)
Qwen3-8B w4a16 (INT4) — พีกตอนเทรน	18.78 GB	8.49 GB	B200
gpt-oss-120b (MXFP4) — พีกตอนเทรน	backward พัง	84.6 GB บนการ์ดใบเดียว	B200
Kimi-K2.7-Code (INT4, 595 GB)	ต้องใช้ราว 2 TB ถ้าคลายเป็น 16-bit	release notes ระบุว่าเทรนได้บน B200 6 ใบ	B200

ตัวเลขของ Qwen3.8-27B มาจาก PR #12185 ซึ่งตั้งค่า LoRA r=16 บน attention และ MLP, batch 2 × สูงสุด 1024 โทเคน และ median step ลดจาก 550.1 ms เหลือ 489.3 ms (release notes ปัดเป็น “11% shorter steps”) ส่วนของ Qwen3-8B มาจาก PR #11537 และของ gpt-oss-120b มาจาก PR #11929 (SFT 10 สเต็ป)

ข้อควรระวังเรื่อง Kimi: ตัวเลข “6 B200s” มีอยู่ใน release notes เท่านั้น ส่วนการรันที่ PR #11537 บันทึกไว้คือรันบน B200 4 ใบ แบบ LoRA เฉพาะ attention, dense MLP และ shared experts ผ่านเส้นทาง NF4 (พีกราว 139–143 GB ต่อการ์ด) ส่วนการทำ LoRA ครอบทุก routed expert นั้น OOM ตอน Adam step แรก และ PR ระบุว่าต้องใช้ทั้งโหนด 8 ใบ

ทำงานอย่างไร และอะไรเปลี่ยนสำหรับ INT4

• Triton kernel คลายน้ำหนักทีละเลเยอร์ตอนรัน ผลออกมาตรงกับตัว decompress ของ compressed-tensors ทุกบิต และตอน backward จะเก็บไว้แค่น้ำหนักแบบ packed
• NVFP4 รันแบบ W4A16 คือน้ำหนักเป็น 4-bit แต่ activation เป็น bf16 PR ระบุว่าเส้นทางเดิมทำ fake-quantize activation เป็น 4-bit ด้วย (W4A4) ทำให้ผลลัพธ์ของเลเยอร์ NVFP4 ในโมเดลทดสอบห่างจาก matmul bf16 จริงถึง 28% ส่วนเส้นทางใหม่ห่างแค่ 0.17%
• INT4 ไม่ถูกแปลงซ้ำเป็น NF4 แล้ว การแปลงซ้ำทำให้น้ำหนักทุกตัวถูกปัดสองรอบ และทำให้ perplexity ของ Qwen3-8B สูงขึ้น 1.6% (18.6957 → 19.0032 บน wikitext-2) ส่วนเส้นทาง packed ให้ logits ตรงกับน้ำหนักต้นฉบับ ใน PR รุ่นที่เล็กกว่าเสียหนักกว่านี้ (Qwen3-1.7B +4.4%)
• เส้นทาง NF4 เดิมยังเลือกได้ด้วย UNSLOTH_COMPRESSED_TENSORS_INT4=nf4 และจะถูกใช้อัตโนมัติบน ROCm, CPU หรือเครื่องที่ไม่มี Triton ผู้ใช้การ์ด AMD จึงยังไม่ได้เส้นทาง INT4 แบบ exact
• gpt-oss ที่โหลดด้วย load_in_4bit = False จะเก็บ expert แบบ MXFP4 ไว้ แต่ถ้าใช้ แค่ inference PR #11929 วัดได้ว่า prefill 2048 โทเคนช้าลง (224 → 660 ms เมื่อติดตั้ง vLLM) ให้ตั้ง UNSLOTH_MXFP4_KEEP_PACKED=0 เพื่อกลับไปใช้วิธีโหลดแบบเดิม

from unsloth import FastLanguageModel

# เช็กพอยต์ INT4 แบบ compressed-tensors: ตอนนี้ load_in_4bit=True จะเก็บน้ำหนักแบบ packed
model, tokenizer = FastLanguageModel.from_pretrained(
    "RedHatAI/Qwen3-8B-quantized.w4a16",
    load_in_4bit = True,
)

ความหมายสำหรับ GPU 24 GB และ 48 GB

Unsloth ไม่ได้วัดบนการ์ด 24 หรือ 48 GB ในรีลีสนี้ ตัวเลขด้านล่างจึงเป็นการคำนวณจากค่าที่วัดบน RTX PRO 6000 และ B200 ใช้ประเมินเบื้องต้นได้ แต่ไม่ใช่การรับประกัน

• 48 GB (เช่นการ์ดเวิร์กสเตชันรุ่น 48 GB): พีก 40.15 GB ของ Qwen3.8-27B-NVFP4 ต่ำกว่า 48 GB ที่การตั้งค่า r=16 และ 2 × 1024 โทเคน แต่เหลือที่ว่างไม่มาก ถ้าเพิ่มความยาว sequence หรือ batch ก็อาจไม่พอ อีกเรื่องที่ต้องดูคือ ตัวเลข 40.15 GB เป็นกรณีที่เลเยอร์ FP8 ในเช็กพอยต์รันบน FP8 kernel ด้วย ถ้าเลเยอร์ FP8 ถูกคลายเป็น bf16 พีกจะเป็น 51.14 GB ซึ่งเกิน 48 GB และ PR ระบุว่าการโหลดแบบ fp16 (เช่น T4/V100) จะคลายเลเยอร์ FP8 เสมอ
• 24 GB (เช่นการ์ดเกมมิ่งระดับบน): Qwen3.8-27B-NVFP4 แค่โหลดก็ใช้ 22.22 GB แล้ว จึงไม่น่าจะเหลือพอเทรน แต่ Qwen3-8B w4a16 ที่พีก 8.49 GB มีที่ว่างเหลือเยอะ ถ้าอยากเทรนบนน้ำหนัก INT4 ที่คนอื่นประเมินผลและเผยแพร่มาแล้ว ตอนนี้ทำได้โดยไม่เสียความแม่นยำจากการปัดซ้ำ
• gpt-oss-120b ต้องใช้การ์ดระดับ 96 GB ขึ้นไป (พีก 84.6 GB) และ Kimi-K2.7-Code ยังเป็นงานระดับคลัสเตอร์

ของอื่นในรีลีส

• Laya ตอบคำขอสั้นเร็วขึ้นสูงสุด 4.1 เท่า บน B200 การเช็ก guardrail 3 คำถามใช้ 2.8 ms แทน 11.6 ms แต่ input ยาวยังเร็วพอ ๆ กับเดิม โหลดเสร็จในราว 9 วินาทีแทน 17 วินาที และใช้ RAM ฝั่ง host ช่วงพีกราวครึ่งเดียว (เราเคยเขียนถึง Laya โมเดลตัดสินใจ 421M ไว้แล้ว) นอกจากนี้ยังต่อผู้ให้บริการ decision model แบบโฮสต์อย่าง TypeSafe ได้ และเปิด Unsloth Decisions เป็น decide tool ในเมนู MCP ของแชตได้
• unsloth eval รันงานจาก lm-evaluation-harness กับเช็กพอยต์หรือ LoRA adapter ได้ เช่น unsloth eval ./my-lora --tasks mmlu,hellaswag ต้องติดตั้ง pip install "unsloth[eval]" เพิ่ม
• Cmd/Ctrl+P เปิด command palette และแชร์การตั้งค่าการรันของโมเดล GGUF เป็นลิงก์ได้
• fine-tune โมเดล encoder-decoder (T5, T5Gemma, BART, Marian) ผ่าน FastModel ได้ และ Gemma 4 31B เทรนได้เมื่อแบ่งโมเดลไว้หลาย GPU

มุมมอง AI Curator

เรื่องนี้สำคัญกว่าที่ชื่อรีลีสบอก ในปี 2026 โมเดลโอเพนเวตจำนวนมากถูกปล่อยเป็นเช็กพอยต์ 4-bit ตั้งแต่ต้นทาง เช่น NVFP4, INT4 แบบ w4a16 ของ RedHatAI หรือ MXFP4 ของ gpt-oss แต่เครื่องมือเทรนยังมองเช็กพอยต์พวกนี้เป็นแค่ไฟล์บีบอัดที่ต้องคลายก่อนใช้ Unsloth เปลี่ยนให้น้ำหนัก 4-bit ที่ถูกประเมินผลและเผยแพร่มาแล้วกลายเป็นฐานของ LoRA ได้โดยตรง ผลข้างเคียงที่ดีคือ adapter ที่ได้จะถูกเทรนบนน้ำหนักเดียวกับที่ใช้ deploy จริง แทนที่จะเทรนบน NF4 ที่ห่างจากต้นฉบับไปแล้ว 1.6–4.5% ตามตาราง perplexity ใน PR

แต่ควรอ่านตัวเลขอย่างระวัง ค่าที่ดีที่สุดวัดบน Blackwell (RTX PRO 6000, B200) และส่วนที่ทำให้ Qwen3.8-27B ลงมาได้ถึง 40 GB ต้องอาศัย FP8 kernel ด้วย ส่วนตัวเลข Kimi “6 B200s” ใน release notes ก็ไม่ตรงกับการรันที่ PR บันทึกไว้ สำหรับนักพัฒนาไทยที่เช่า GPU คลาวด์รายชั่วโมง การที่งาน 27B ลงมาอยู่ในการ์ด 48 GB ได้ (ตามการคำนวณ) แทนที่จะต้องใช้ 80–96 GB ช่วยลดค่าเช่าได้จริง แต่ควรลองบนการ์ดที่จะใช้จริงก่อนจ่ายรันยาว ส่วนทีมที่ใช้การ์ด AMD ยังต้องรอ เพราะ INT4 บน ROCm ยังถูกส่งกลับไปใช้ NF4

ในระยะยาว ถ้าเทรนบนน้ำหนัก 4-bit ได้เป็นเรื่องปกติ ผู้ปล่อยโมเดลก็อาจเลิกปล่อยน้ำหนัก bf16 ขนาดใหญ่ และปล่อยแค่ 4-bit เป็นหลัก ซึ่งช่วยเรื่องค่าดาวน์โหลดและพื้นที่ดิสก์สำหรับคนในภูมิภาคที่เน็ตไปยัง Hugging Face ไม่เร็วนัก ส่วน unsloth eval ที่มาพร้อมกันก็ช่วยให้วัดผลก่อนกับหลังเทรนได้ในเครื่องมือเดียว ซึ่งทีมเล็กมักข้ามขั้นตอนนี้ไป

แหล่งข่าว

• Unsloth v0.1.902-beta release notes — GitHub (1 ต.ค. 2026)
• PR #12185: Train LoRA on NVFP4 compressed-tensors checkpoints with the weights kept packed
• PR #11537: Load compressed-tensors packed INT4 checkpoints for QLoRA without a 16-bit copy
• PR #11929: Train gpt-oss MXFP4 LoRA through packed experts