ข้ามไปยังเนื้อหา
กลั่นโมเดลด้วย GPU ตัวเดียว — สูตร offline top-K logits + fused chunked KL ลด VRAM จาก 85.2GB เหลือ 5.45GB และเร็วขึ้น 5 เท่า
งานวิจัย

กลั่นโมเดลด้วย GPU ตัวเดียว — สูตร offline top-K logits + fused chunked KL ลด VRAM จาก 85.2GB เหลือ 5.45GB และเร็วขึ้น 5 เท่า

อ่าน 7 นาที ที่มา: Hugging Face

เมื่อ 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 GB58.3 GB (−43%)
benchmark projection ที่ 32K85.2 GB5.45 GB (−15.6 เท่า)
ที่ 64Kล้มเหลวยังรันได้
GPT-OSS 20B @ 32K — ฮาร์ดแวร์4 โหนด GPU1 GPU
GPT-OSS 20B @ 32K — เวลาต่อสเต็ป57.0 วินาที12.23 วินาที (~5 เท่า)
GPT-OSS 20B @ 32K — throughput74.2 TFLOP/s345.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 หรือเปล่า

แหล่งข่าว

บทความนี้เรียบเรียงจากแหล่งข่าวต้นทาง — Hugging Face

เนื้อหาบน blog นี้สร้างโดย AI โดยมีการกำกับบรรณาธิการจากมนุษย์

อ่านเพิ่มในหมวด งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง
งานวิจัย

Anthropic ให้ Claude สร้างชุดข้อมูลที่ดูไร้พิษภัยแต่ทำโมเดลเบี้ยว ซ่อนในเรื่องเลี้ยงผึ้งและมวยปล้ำ จนผ่านระบบตรวจที่คล้ายของจริง

ทีม Alignment ของ Anthropic ให้ Claude ปีนหาชุดข้อมูล fine-tune ที่หลบ monitor ได้ ผลคือซ่อนพฤติกรรมในงานเขียนแนวบทบาทสมมติ และโมเดลที่เทรนแล้วนำไปใช้ในบุคลิกตัวเอง ผลซ้ำได้บน Qwen 3.6 27B แต่การทดลองเอื้อฝ่ายโจมตีมากและไม่ได้สะท้อนโมเดลที่ใช้งานจริง

· อ่าน 4 นาที
Memdoor ทำซ้ำ GVS5H ได้: ทีม Qwen3.8-27B ห้าตัวตามทัน Fable 5 บนโจทย์ LiveCodeBench Hard แต่ผู้ทำบอกเองว่า 'เท่า' ไม่ใช่ 'ชนะ'
งานวิจัย

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 แบบเรียกครั้งเดียว แต่ตัวอย่างเล็กและมีข้อจำกัด ส่วนงานวิจัยต้นฉบับชี้ว่าวิธีนี้ไม่ได้ช่วยทุกโมเดล

· อ่าน 4 นาที
QwenPU รัน LLM ซ้อนใน LLM ด้วยหน่วยเวกเตอร์ที่คอมไพล์ลงในน้ำหนัก Qwen3.5-4B ส่วน bootgpt ทำให้เครื่อง 386 บูตเข้าโมเดลภาษาโดยไม่มี OS
งานวิจัย

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

· อ่าน 3 นาที