กลั่นโมเดลด้วย GPU ตัวเดียว — สูตร offline top-K logits + fused chunked KL ลด VRAM จาก 85.2GB เหลือ 5.45GB และเร็วขึ้น 5 เท่า
เมื่อ 10 สิงหาคม 2026 ทีมวิจัยจาก Multiverse Computing เผยแพร่บทความบนบล็อก Hugging Face สรุปงานที่ขึ้น arXiv ไว้ตั้งแต่ 4 ส.ค. ในชื่อ Efficient Knowledge Distillation for LLMs: Offline Top-K Logits and a Fused Chunked KL Loss ประเด็นของงานไม่ใช่สถาปัตยกรรมใหม่หรือโมเดลใหม่ แต่เป็นเรื่องที่ปฏิบัติกว่านั้นมาก — ทำอย่างไรให้การกลั่นความรู้ (knowledge distillation) ถูกพอที่คนทั่วไปจะทำได้จริง
โจทย์นี้สำคัญขึ้นเรื่อย ๆ เพราะโมเดลเปิดตัวใหญ่ขึ้นเร็วกว่าที่ VRAM จะตามทัน การกลั่นเป็นวิธีมาตรฐานที่จะย่อโมเดลใหญ่ให้เล็กพอ deploy ได้ แต่ตัวกระบวนการกลั่นเองกลับกลายเป็นสิ่งที่คนส่วนใหญ่ทำไม่ไหว
ทำไมการกลั่นถึงแพงเกินเหตุ
วิธีมาตรฐานคือ online distillation — โหลดโมเดลครูกับโมเดลนักเรียนไว้ในหน่วยความจำพร้อมกัน แล้วให้ครูคำนวณการแจกแจงความน่าจะเป็นบนคำศัพท์ทั้งชุดสำหรับทุกโทเคน วิธีนี้ตรงไปตรงมาแต่มีค่าใช้จ่ายซ้อนกันสองชั้น: ครูกินหน่วยความจำตลอดการเทรน และ KL loss ต้องกาง tensor ขนาด sequence_length × vocab_size ออกมาเต็ม ๆ
ตัวเลขที่ทีมยกมาเห็นภาพชัด: การกลั่น gpt-oss-120b ที่ความยาวบริบท 32K ต้องใช้ VRAM ราว 250GB ต่อหนึ่ง iteration ซึ่งเกินความจุของ H200 หนึ่งตัวไปไกล และปัญหานี้จะยิ่งหนักขึ้นเมื่อคำศัพท์ของโมเดลรุ่นใหม่ ๆ ใหญ่ขึ้นเรื่อย ๆ
เทคนิคที่ 1 — แคช top-100 logits ของครูไว้ล่วงหน้า
แทนที่จะเรียกครูซ้ำทุกสเต็ป ทีมเลือกรันครูรอบเดียวแล้วเก็บ โทเคนที่น่าจะเป็นที่สุด 100 อันดับแรกต่อหนึ่งตำแหน่ง ลงดิสก์ จากนั้นเทรนนักเรียนแบบ offline จากแคชนั้น
ผลที่ตามมามีสองข้อ ข้อแรกคือครูหายออกจากหน่วยความจำระหว่างเทรนทั้งหมด ข้อที่สองซึ่งประหยัดกว่าในระยะยาวคือ แคชนั้นใช้ซ้ำได้ข้ามการทดลอง — ถ้าจะลอง learning rate ห้าค่า หรือลองสถาปัตยกรรมนักเรียนสามแบบ ก็ไม่ต้องจ่ายค่าประมวลผลฝั่งครูซ้ำอีกเลย
ทีมรายงานว่าวิธีนี้ทำให้ เร็วขึ้น 29% ต่อ iteration และ throughput สูงขึ้น 41% บน H200 ตัวเดียว เทียบกับการทำแบบ online
เทคนิคที่ 2 — fused chunked KL loss
ส่วนที่ให้ผลแรงกว่าคือการเขียน loss ใหม่ แทนที่จะสร้าง logits ทั้ง sequence ขึ้นมาก่อนแล้วค่อยคำนวณ KL ทีเดียว วิธีใหม่จะไล่ทำทีละ chunk: ฉาย hidden state เป็น logits เฉพาะ chunk นั้น คำนวณ loss แล้วทิ้ง chunk ทิ้งก่อนไปต่อ ส่วน backward pass ก็คำนวณ chunk ขึ้นมาใหม่แทนที่จะเก็บไว้
ผลคือ หน่วยความจำสูงสุดแปรผันเป็นเชิงเส้นกับความยาว sequence ไม่ใช่ระเบิดตามขนาดคำศัพท์อีกต่อไป ตัวเลขที่วัดได้:
| การทดลอง | วิธีเดิม | fused chunked |
|---|---|---|
| บริบท 8K บน H200 ตัวเดียว (online) | 102.8 GB | 58.3 GB (−43%) |
| benchmark projection ที่ 32K | 85.2 GB | 5.45 GB (−15.6 เท่า) |
| ที่ 64K | ล้มเหลว | ยังรันได้ |
| GPT-OSS 20B @ 32K — ฮาร์ดแวร์ | 4 โหนด GPU | 1 GPU |
| GPT-OSS 20B @ 32K — เวลาต่อสเต็ป | 57.0 วินาที | 12.23 วินาที (~5 เท่า) |
| GPT-OSS 20B @ 32K — throughput | 74.2 TFLOP/s | 345.7 TFLOP/s ต่อ GPU |
บรรทัดที่สำคัญที่สุดคือบรรทัด “4 โหนด → 1 GPU” เพราะมันไม่ใช่แค่การประหยัดค่าเช่า แต่เป็นการข้ามเส้นแบ่งระหว่าง งานที่ต้องมีคลัสเตอร์ กับ งานที่รันบนเครื่องเดียวได้
คุณภาพหลังกลั่นยังอยู่ไหม
การประหยัดหน่วยความจำจะไร้ความหมายถ้าโมเดลที่ได้แย่ลง ทีมจึงเทียบผลโดยใช้ Llama 3.1 8B Instruct เป็นครู และนักเรียนขนาด 3.2B
ผลคือ loss ระหว่างเทรน แทบเท่ากับ online distillation และตัวนักเรียนรักษาความแม่นยำในบริบทสั้นของครูไว้ได้เกือบทั้งหมดที่ขนาดไม่ถึงครึ่ง — บน BoolQ และ HellaSwag ยังเกาะติด ส่วน MMLU ห่างจากครูราว 9 จุด
พูดอีกแบบคือเทคนิคนี้เป็นการปรับที่ ระบบ ล้วน ๆ ไม่ใช่การแลกคุณภาพกับความเร็ว — ได้ผลลัพธ์เดิมด้วยทรัพยากรที่น้อยกว่ามาก
ข้อควรรู้เรื่องใบอนุญาต
โค้ดเผยแพร่ที่ CompactifAI/Full-Chunked-KL-Loss เป็น PyTorch/CUDA benchmark ที่เทียบ loss สามแบบให้รันเองได้ แต่จุดที่ต้องอ่านก่อนใช้: repo ระบุสถานะ “Patent Application Pending” (EP26382987.1) — ไม่ใช่ใบอนุญาตโอเพนซอร์สแบบ MIT หรือ Apache ที่เราคุ้นเคย ใครจะเอาไปใช้ในงานเชิงพาณิชย์ควรอ่านเงื่อนไขให้ครบก่อน อย่าเหมาว่า “โค้ดอยู่บน GitHub = ใช้ได้เสรี”
มุมมอง AI Curator
งานแบบนี้คือประเภทที่ผมคิดว่าถูกประเมินค่าต่ำเกินไปเสมอ มันไม่มีโมเดลใหม่ให้เล่น ไม่มีคะแนน benchmark ให้พาดหัว มีแค่การเขียน loss function ใหม่กับการย้ายลำดับการคำนวณ — แต่ผลลัพธ์คือการย้ายเส้นแบ่งว่าใครทำงานนี้ได้บ้าง จาก “ทีมที่มีคลัสเตอร์ GPU” มาเป็น “คนที่เช่า H200 ได้หนึ่งตัว” ซึ่งเป็นการเปลี่ยนแปลงที่มีผลกับจำนวนคนมากกว่าโมเดลใหม่หลายตัวรวมกัน
สำหรับบริบทไทยและ SEA นี่ตรงกับปัญหาที่เราเจอจริง ทีมไทยที่อยากได้โมเดลเล็กเก่งภาษาไทยส่วนใหญ่ติดอยู่ที่เดียวกันหมด: fine-tune โมเดล 7-8B พอไหว แต่การกลั่นจากโมเดลใหญ่ที่เก่งกว่าลงมาเป็นตัวเล็กที่รันได้บนเครื่องตัวเองนั้นเกินงบ เพราะต้องแบกครูไว้ในหน่วยความจำตลอดเวลา แนวทาง offline caching เปลี่ยนโครงสร้างต้นทุนตรงนี้พอดี — จ่ายค่ารันครูรอบเดียว เก็บ top-K ไว้ แล้วทดลองฝั่งนักเรียนกี่รอบก็ได้ ซึ่งเข้ากับรูปแบบการทำงานของแล็บมหาวิทยาลัยและสตาร์ทอัพเล็กที่ต้องลองผิดลองถูกหลายรอบด้วยงบก้อนเดียว
จุดที่ควรระวังคือค่าใช้จ่ายที่ย้ายที่ ไม่ได้หายไป แคช top-100 logits ต่อทุกตำแหน่งในคลังข้อมูลเทรนไม่ใช่ไฟล์เล็ก งานนี้แลก VRAM กับพื้นที่ดิสก์และ I/O ซึ่งเป็นการแลกที่คุ้มมากในเกือบทุกกรณี แต่ถ้าคลังข้อมูลของคุณใหญ่ระดับหลายพันล้านโทเคน ควรคำนวณพื้นที่จัดเก็บก่อนเริ่ม ไม่ใช่หลังจากดิสก์เต็ม และการเลือก K = 100 ก็เป็นจุดแลกเปลี่ยนที่ควรทดสอบกับงานของตัวเอง โดยเฉพาะภาษาที่ tokenizer แตกคำออกเป็นชิ้นเล็กกว่าอังกฤษอย่างภาษาไทย ซึ่งการแจกแจงความน่าจะเป็นอาจกระจายตัวต่างออกไป
ประเด็นสุดท้ายคือเรื่องใบอนุญาต ที่น่าสนใจในเชิงแนวโน้มมากกว่าตัวงาน เราเริ่มเห็นงานวิจัยที่เผยแพร่เปิดเผยทุกอย่าง ทั้งเปเปอร์ ทั้งโค้ด แต่กันสิทธิบัตรไว้ข้างหลัง — เป็นรูปแบบที่ต่างจากวัฒนธรรม ML ยุคก่อนพอสมควร และเป็นสิ่งที่นักพัฒนาต้องเริ่มอ่านให้ละเอียดขึ้น ไม่ใช่แค่ดูว่ามีปุ่ม clone หรือเปล่า
แหล่งข่าว
อ่านเพิ่มในหมวด งานวิจัย
Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
Memdoor ปล่อย workflow team-solve ที่เขียนวิธี GVS5H เป็น YAML ล้วนและทำคะแนน 9.8/10 บน LiveCodeBench Hard 10 ข้อ เทียบกับ 8.0 ของ Fable 5 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
ผู้สร้าง Qwenputer ปล่อย QwenPU เมื่อ 31 ต.ค. รัน stories260K ของ Karpathy บนหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ลดเหลือ 53,000 trace token ต่อหนึ่ง token เรื่องเล่า วันเดียวกัน bootgpt ใส่โมเดล int8 ขนาด 11.5KB ให้บูตบนเครื่อง 386 โดยไม่มี OS