IsoExec ทำให้ trainer กับ vLLM คำนวณ logprob ตรงกันระดับบิต — ค่าเบี่ยงเบนสูงสุดต่อสเต็ปร่วงจาก 5.073 เหลือ ~0.044 แลกกับช้าลง 25.3%

21 สิงหาคม 2026 บล็อก vLLM เผยแพร่ IsoExec จาก Alexander Jiang และทีม SkyRL — งานที่แก้บั๊กประเภทที่กัดกินคนทำ RL บนโมเดลภาษามานาน และเป็นบั๊กที่ ไม่ปรากฏใน log ใด ๆ จนกว่าการเทรนจะพังแบบอธิบายไม่ถูก

โจทย์คือแบบนี้: ใน on-policy RL อย่าง PPO หรือ GRPO เราต้องประเมิน policy ตัวเดียวกันสองครั้ง — ครั้งแรกตอนสร้าง rollout (ใช้ inference engine เช่น vLLM) และครั้งที่สองตอนเทรน (ใช้ trainer เช่น Megatron) ในทางคณิตศาสตร์มันควรได้ค่าเท่ากันเป๊ะ แต่ในทางปฏิบัติสองระบบนี้ใช้ เคอร์เนลคนละตัว รูปทรง batch คนละแบบ และเลย์เอาต์ parallelism คนละอย่าง และเพราะเลขทศนิยมลอยตัวไม่มีสมบัติการเปลี่ยนหมู่ (non-associative) การบวกเลขชุดเดียวกันคนละลำดับก็ให้ผลไม่เท่ากัน

ผลคือ token probability เปลี่ยนไปทั้งที่รัน policy ตัวเดียวกัน จากนั้น importance ratio ใน PPO/GRPO ก็เพี้ยน อัลกอริทึมเข้าใจผิดว่า policy เปลี่ยนไปแล้วทั้งที่ไม่ได้เปลี่ยน — การเทรนไม่เสถียร และ debug แทบไม่ได้ เพราะไม่มีอะไรผิดในเชิงตรรกะเลย

แนวคิด: ประกาศทุกอย่างที่มีผลต่อบิต แล้วบังคับให้ทั้งสองฝั่งทำตาม

IsoExec ประกอบด้วยสองส่วน

1. Execution contract — สัญญาที่ประกาศทางเลือกทุกอย่างที่มีผลต่อผลลัพธ์ระดับบิต ได้แก่ implementation ของเคอร์เนล, dtype ที่ใช้สะสมค่า (accumulation dtype) และลำดับการ reduce จากนั้นแบ่งการคำนวณของโมเดลออกเป็นภูมิภาค แล้วระบุว่าแต่ละภูมิภาคต้องใช้ implementation ตัวไหนในแต่ละกรณี — ตอนเทรน ตอน prefill และตอน decode — โดยทั้งสอง runtime ต้องประกาศเหมือนกัน

2. Unified model — เคอร์เนล batch-invariant สำหรับ GEMM, attention และ normalization ที่ให้ผลเท่าเดิมไม่ว่าจะจัด batch ยังไง และรักษาค่าตัวเลขข้าม tensor / expert / sequence parallelism ได้ พร้อมอัลกอริทึมใหม่ชื่อ Chunkwise-Parallel Recurrent (CPR) ที่ทำให้ฝั่งเทรนกับฝั่ง decode ตรงกันโดยไม่ต้องบังคับให้ forward pass บนลำดับยาว ๆ กลายเป็นการคำนวณแบบอนุกรม

คำสำคัญคือ “ขจัด” ไม่ใช่ “ชดเชย” — repo ระบุตรง ๆ ว่าเป้าหมายคือกำจัดความต่างเชิงตัวเลขทิ้ง แทนที่จะไปแก้ importance ratio ให้ถูกทีหลัง ซึ่งเป็นวิธีที่หลายทีมใช้อยู่

ตัวเลข: ได้ความถูกต้อง จ่ายด้วยความเร็ว

ทดสอบบน Qwen3.5-35B-A3B บนเครื่อง 8×H100 หนึ่งโหนด:

• ค่าเบี่ยงเบนสัมบูรณ์ สูงสุดต่อสเต็ป ของ logprob ลดจาก 5.073 เหลือราว 0.044
• ต้นทุน end-to-end เพิ่มขึ้น 25.3% — แยกเป็นฝั่ง generation +31.3% และฝั่งเทรน policy +18.6%
• ตัว CPR เองมี overhead 1.43 เท่า สำหรับ forward/backward ของ trainer เทียบกับ mixed precision ปกติ

โค้ดอยู่ที่ zanderjiang/SkyRL-IsoExec เป็น fork ของ SkyRL ภายใต้ Apache-2.0 รองรับ Qwen3 dense, Megatron MoE และ GatedDeltaNet และ ปิดอยู่เป็นค่าเริ่มต้น ต้องเปิดด้วย SKYRL_ISOEXEC=1 — ซึ่งเป็นการออกแบบที่ถูก เพราะคุณควรจ่าย 25% นั้นเมื่อรู้ว่าจ่ายไปเพื่ออะไร

ตัวเลข 5.073 น่าคิดเป็นพิเศษ — นั่นคือค่าเบี่ยงเบนสูงสุด ไม่ใช่ค่าเฉลี่ย และในโลกของ log-probability ค่าขนาดนั้นบนโทเคนเดียวก็เพียงพอจะทำให้ ratio ระเบิดและ gradient พาการเทรนออกนอกทาง

มุมมอง AI Curator

สิ่งที่ผมชอบในงานนี้คือมันไป แก้ที่ต้นเหตุแทนที่จะปะที่ปลายทาง ซึ่งเป็นสิ่งที่วงการ RL บน LLM ทำน้อยเกินไป ปีที่ผ่านมามีเปเปอร์จำนวนมากเสนอวิธี “ทนต่อ” ความไม่ตรงกันระหว่าง trainer กับ sampler — ตัดค่า ratio, ใช้ FP16 แทน BF16, ปรับสูตรชดเชย — ทั้งหมดเป็นการยอมรับว่าตัวเลขไม่ตรงแล้วหาทางอยู่กับมัน IsoExec ถามคำถามที่ตรงกว่า: ถ้ามันควรตรงกัน ทำไมเราไม่บังคับให้มันตรง

แต่ราคา 25.3% เป็นราคาที่แพงจริงและควรพูดให้ชัด สำหรับทีมที่เผา GPU-hour เป็นหลักหมื่น นั่นคือเงินก้อนใหญ่ คำถามที่ควรถามจึงไม่ใช่ “จะเปิดดีไหม” แต่คือ “การเทรนของฉันเคยพังแบบอธิบายไม่ได้หรือเปล่า” ถ้าเคย — และคนทำ RL ส่วนใหญ่เคย — 25% นั้นถูกกว่าเวลาที่เสียไปกับการไล่หาสาเหตุที่ไม่มีอยู่ในโค้ดของตัวเองมาก สำหรับผมนี่คือทูลที่ควรเปิดตอน debug และตอนตั้งค่าการทดลองใหม่ ๆ แล้วปิดตอนรันโปรดักชันที่พิสูจน์แล้วว่านิ่ง

มุมที่คนไทยควรสนใจเป็นพิเศษ: กระแส “post-train โมเดลเปิดให้เก่งภาษาไทย/งานเฉพาะทาง” กำลังมาแรง และหลายทีมกำลังขยับจาก SFT ไปหา RL เพราะ SFT ชนเพดานเร็ว ทีมเหล่านี้มักไม่มีวิศวกรที่เชี่ยวเรื่อง numerics ระดับเคอร์เนล และเมื่อการเทรนไม่คอนเวิร์จ ข้อสรุปที่มักได้คือ “ข้อมูลเราไม่พอ” หรือ “โมเดลฐานไม่ดี” ทั้งที่สาเหตุจริงอาจเป็นแค่ลำดับการบวกเลขในสอง runtime ที่ไม่ตรงกัน การมีสวิตช์ตัวเดียวที่ตัดสมมติฐานนี้ทิ้งได้ มีค่ามากกว่าตัวเลข 25% ที่ต้องจ่าย

ข้อควรระวังสองข้อ: repo ยังใหม่มาก (2 คอมมิต, 1 ดาว ณ วันที่เขียน) เป็น research fork ไม่ใช่ไลบรารีที่มีคอมมิวนิตี้ดูแล และผลทั้งหมดวัดบนโมเดล MoE ขนาด 35B บนโหนดเดียว — ถ้าคุณรันข้ามหลายโหนด หรือใช้สถาปัตยกรรมอื่น ตัวเลขจะต่างออกไปแน่นอน ควรถือว่านี่เป็นการพิสูจน์แนวคิด ไม่ใช่ของพร้อมใช้

แหล่งข่าว

• IsoExec: Unified Execution to Eliminate Trainer-Inference Mismatch in SkyRL — vLLM Blog
• zanderjiang/SkyRL-IsoExec — GitHub (Apache-2.0)
• vLLM Blog