Unsloth Studio v0.1.811: ไล่ AMD ย้อนถึง RDNA1–RDNA2, มีอิมเมจ ROCm แยก, เพิ่มบัญชีผู้ใช้หลายคนแยกงานกัน และแซนด์บ็อกซ์ระดับ OS สำหรับ tool

18 ก.ย. 2026 ทีม Unsloth ปล่อย v0.1.811-beta ซึ่งเป็นรีลีสที่ดูเผิน ๆ เหมือน point release ปกติ แต่ถ้าอ่านรายการ PR จะเห็นว่าโครงการกำลังเปลี่ยนรูป: จากไลบรารี fine-tuning ที่รันในสมุดโน้ต Colab ไปเป็น แอป/เซิร์ฟเวอร์ที่ทีมทั้งทีมแชร์เครื่องเดียวกันได้ และจากการรองรับ AMD ที่จำกัดเฉพาะการ์ดรุ่นใหม่ ไปเป็นการไล่เก็บ การ์ดเก่าย้อนถึงปี 2019

(เราเขียนถึง Unsloth ตอนประกาศรองรับ AMD ครั้งแรกเมื่อ 24 ก.ค. 2026 — รอบนั้นครอบคลุม Radeon รุ่นใหม่, Instinct MI300X/MI325X และ Ryzen รีลีสนี้คือการต่อยอดไปที่สถาปัตยกรรมเก่ากว่านั้นและเปลี่ยนวิธีติดตั้ง ไม่ใช่การประกาศรองรับ AMD ครั้งแรก)

AMD: ย้อนไปถึง RDNA1 และมีอิมเมจ ROCm ของตัวเอง

ของใหญ่ที่สุดคือ การ์ด AMD เก่าที่เคยถูกทิ้งไว้บน CPU torch ตอนนี้ใช้งานได้:

• รองรับ RDNA1 และ RDNA2 — ครอบคลุมสาย Radeon RX 5000 (2019) และ RX 6000 (2020) ที่อยู่ในเครื่องนักพัฒนาจำนวนมากและก่อนหน้านี้ไม่ได้อะไรเลย
• มี PR เฉพาะที่ไล่แก้ให้ RX 6950 XT, 6850M XT และ 6550M ถูกตรวจเจอ แทนที่จะถูกปล่อยให้ตกไปใช้ torch แบบ CPU
• RDNA1 เข้าถึงได้ผ่านการยอมให้ pinned torch index พก package extra ไปด้วย เพื่อให้ไปหยิบ build จาก TheRock ได้
• ฝั่งใหม่กว่า gfx1102 และ RDNA4 ถูกตั้งพื้นไว้ที่ ROCm 6.4
• โฮสต์ Windows ที่เป็น AMD แต่ ROCm ใช้ไม่ได้ จะตกไปใช้ Vulkan ไม่ใช่ CPU bundle — ต่างกันมากในทางปฏิบัติ
• เปิด fast ROCm attention kernels ของ PyTorch ตั้งแต่ import unsloth แทนที่จะให้ตัวติดตั้งไป export ตัวแปรทั้งเครื่อง

และมาพร้อม อิมเมจ Docker แยกสำหรับ AMD: unsloth/unsloth-rocm วางคู่กับอิมเมจ CUDA เดิม ครอบคลุม RDNA2 ถึง RDNA4 และ CDNA บนโฮสต์ Linux ที่รองรับ นี่คือจุดที่ช่วยได้จริง เพราะปัญหาใหญ่ของการเทรนบน AMD ไม่เคยเป็นเรื่องโค้ดโมเดล แต่เป็นเรื่อง การประกอบสแตก ROCm + PyTorch + ไดรเวอร์ให้เวอร์ชันตรงกัน — การมีอิมเมจที่ทีมดูแลเองย้ายภาระนั้นออกจากผู้ใช้

หมายเหตุที่ควรรู้ถ้าใช้ Windows: มี PR ที่ต้อง ล็อก accelerate ให้ต่ำกว่า 1.15 บน Windows เพราะ 1.15 ทำให้การเทรนบน ROCm พังทั้งหมด — เป็นสัญญาณว่าเส้นทาง AMD-on-Windows ยังเปราะกว่าฝั่ง Linux อยู่พอสมควร

บัญชีหลายคนบนเครื่องเดียว — Unsloth กลายเป็นเซิร์ฟเวอร์ของทีม

ฟีเจอร์ที่เปลี่ยนวิธีใช้งานมากที่สุดคือ Multi-user accounts ใน Settings > Accounts:

• สร้างบัญชีด้วย one-time setup code และรหัสผ่านแยกของแต่ละคน
• งานของแต่ละบัญชีแยกกัน (per-account isolation ทั้งแบบติดตั้งแบบแชร์และแบบแอปเดสก์ท็อป)
• แต่ ยังแชร์โมเดลที่โหลดไว้ร่วมกันได้เมื่อการตั้งค่าตรงกัน — จุดนี้สำคัญ เพราะหมายถึงสามคนใช้โมเดล 27B ตัวเดียวบน VRAM ก้อนเดียว ไม่ใช่โหลดสามชุด
• พฤติกรรมเดิมของผู้ใช้คนเดียวไม่เปลี่ยน

สำหรับแล็บมหาวิทยาลัยหรือทีมเล็กที่มีเครื่อง GPU กลางเครื่องเดียว นี่คือความต่างระหว่าง “ต้องนัดคิวกันใช้” กับ “เข้าใช้พร้อมกันได้”

ความปลอดภัยของ tool — แซนด์บ็อกซ์ระดับ OS (พรีวิว)

เมื่อแอปเริ่มรันโค้ดและคำสั่งเทอร์มินัลแทนผู้ใช้ เรื่องการกันขอบเขตก็ตามมา รีลีสนี้เพิ่ม:

• แซนด์บ็อกซ์ระดับ OS แบบพรีวิว สำหรับ Python tool และ Terminal tool บนโฮสต์ Linux และ macOS ที่รองรับ
• ถามก่อน เมื่อ chat tool จะอ่านหรือเขียนไฟล์นอกแซนด์บ็อกซ์
• อุดช่องเลี่ยงแซนด์บ็อกซ์ผ่าน command-position substitution ใน terminal tool
• เสริมการป้องกัน credential และการตรวจสอบ tool call

แต่ต้องอ่านข้อจำกัดให้ชัด — release note ระบุตรง ๆ ว่า “การเข้าถึงเครือข่ายยังไม่ถูกจำกัด” และเมื่อโฮสต์ไม่มี OS isolation ให้ใช้ ระบบจะถอยกลับไปใช้มาตรการเดิมของโหมดอัตโนมัติ แปลว่านี่คือการกันความผิดพลาด ไม่ใช่การกันผู้ไม่หวังดี — อย่าเอาไปใช้แทนคอนเทนเนอร์จริง

ของอื่นที่น่าสนใจในรีลีสเดียวกัน

• ARM64 Windows CUDA สำหรับทั้งเทรนและ inference พร้อม ตัวติดตั้งเดสก์ท็อป Windows ARM64 แบบ native
• Qwen3.8-Flash-Next MTP hotfix เร็วขึ้น 2 เท่า (ติดมาจาก v0.1.810-beta)
• INT8/FP8 image diffusion inference เร็วขึ้น 2 เท่า
• GRPO รองรับ Qwen3.5, ตาม TRL และ vLLM รุ่นล่าสุด และ forward vision kwarg ทุกตัว พร้อมรับคอลัมน์ภาพที่เป็นลิสต์
• ตรวจจับ Ascend NPU เป็น device type ของตัวเอง — อีกหนึ่งสัญญาณว่าสแตกนอก CUDA กำลังถูกไล่รองรับจริงจัง
• MLX รับอินพุตวิดีโอ พร้อมออปชันเร่ง MoE และ decode
• /v1/chat/completions รับอินพุตวิดีโอ และเข้าถึงโมเดล Ollama ที่ติดตั้งไว้ผ่าน API ได้
• GGUF ได้ reasoning budget, การประเมินหน่วยความจำแม่นขึ้น, จัดการ DGX Spark, ตรวจ NVLink และเคารพลำดับ GPU ที่ผู้ใช้เลือก

มุมมอง AI Curator

สิ่งที่ผมคิดว่าน่าสนใจกว่าฟีเจอร์แต่ละตัว คือ ทิศทางรวมของรีลีสนี้ — Unsloth กำลังไล่เก็บสิ่งที่ทำให้ “เทรนโมเดลในเครื่องตัวเอง” ยังเป็นเรื่องของคนกลุ่มเล็ก: ฮาร์ดแวร์ที่ไม่ใช่ NVIDIA, การประกอบสแตกไดรเวอร์, และการที่เครื่องหนึ่งเครื่องใช้ได้ทีละคน ไม่มีข้อไหนเป็นงานวิจัย ทุกข้อเป็นงานน่าเบื่อ — และนั่นแหละคือเหตุผลที่มันมีค่า เพราะไม่มีใครอยากทำ

เรื่อง RDNA1/RDNA2 ผมคิดว่าถูกประเมินต่ำเกินไป การ์ดอย่าง RX 6800 หรือ RX 6700 XT ที่มี VRAM 12–16 GB ตอนนี้ราคามือสองในไทยอยู่ในระดับที่นักศึกษาหรือทีมสตาร์ตอัปซื้อได้จริง ขณะที่การ์ด NVIDIA ที่มี VRAM เท่ากันยังแพงกว่าชัดเจนเพราะดีมานด์จากงาน AI เอง การที่เครื่องมือ fine-tuning ที่คนใช้มากที่สุดตัวหนึ่ง ยอมลงแรงรองรับสถาปัตยกรรมอายุหกปี เปลี่ยนสมการต้นทุนของการเริ่มต้นเรียนรู้ fine-tuning ในภูมิภาคที่งบฮาร์ดแวร์เป็นข้อจำกัดจริง — และมันไปในทิศทางเดียวกับที่เราเห็นจากอิมเมจ ROCm และการรองรับ Ascend คือโลกหลัง-CUDA ค่อย ๆ เป็นรูปเป็นร่างจากงานวิศวกรรมเล็ก ๆ หลายร้อยชิ้น ไม่ใช่จากการประกาศครั้งเดียว

ส่วน multi-user accounts คือฟีเจอร์ที่ผมอยากให้แล็บไทยลองจริง ๆ รูปแบบที่พบบ่อยในมหาวิทยาลัยบ้านเราคือ “เครื่องเทรนกลางหนึ่งเครื่อง นักศึกษาสิบคน คิวยาว” และวิธีแก้ที่ใช้กันคือแจก SSH แล้วหวังว่าจะไม่มีใครเผลอ kill process ของคนอื่น การมีบัญชีแยกที่ แชร์โมเดลที่โหลดไว้ร่วมกันเมื่อการตั้งค่าตรงกัน ตอบโจทย์นี้ตรงกว่าที่คิด เพราะต้นทุนที่แท้จริงของการแชร์เครื่อง GPU ไม่ใช่ CPU หรือดิสก์ แต่คือ VRAM ที่ถูกจองซ้ำ

ข้อสุดท้ายที่อยากฝากไว้: อย่าอ่านคำว่า “sandbox” ในรีลีสนี้เกินกว่าที่มันเขียน ทีม Unsloth เขียนไว้ชัดว่าเป็น พรีวิว และเครือข่ายยังเปิดอยู่ ซึ่งซื่อสัตย์ดี แต่แปลว่าถ้าคุณจะให้แอปนี้รัน Python tool จากโมเดลที่คุณไม่ได้เทรนเอง คุณยังต้องห่อมันด้วยคอนเทนเนอร์ของคุณเองอยู่ดี — บทเรียนเดียวกับกรณี ZCode วันนี้: การควบคุมที่เชื่อถือได้อยู่ที่ระดับระบบปฏิบัติการและเครือข่าย ไม่ใช่ที่สวิตช์ในแอป

แหล่งข่าว

• Unsloth v0.1.811-beta — release notes
• unslothai/unsloth บน GitHub (Apache-2.0)
• คู่มือติดตั้งผ่าน Docker ของ Unsloth
• โพสต์ของเราตอน Unsloth รองรับ AMD ครั้งแรก (24 ก.ค. 2026)