SGLang 0.5.20: มาสก์การสุ่มสำหรับ RL rollout ที่เล่นซ้ำได้, radix tree รวมร่างดัน cache hit 43.8%→60.8% และโหลดโมเดลบน ROCm จาก 505 วินาทีเหลือ 40 วินาที

วันที่ 18 กันยายน 2026 โปรเจกต์ SGLang ออกเวอร์ชัน v0.5.20 — รีลีสที่รวม 713 PR จากผู้ร่วมพัฒนา 237 คน ต่อจาก v0.5.19 ที่เราเล่าไปเมื่อ 5 ก.ย. และรอบนี้น้ำหนักของงานเทไปทางสองฝั่งที่คนละกลุ่มผู้ใช้สนใจ: คนทำ RL กับ คนดูแลเครื่องเสิร์ฟ

สำหรับคนทำ RL: rollout ที่เล่นซ้ำได้โดยไม่ต้องเดา

ของเด่นที่สุดของรีลีสคือแฟล็ก return_sampling_mask ซึ่งทำให้ทุกขั้น decode คืน ชุด support ที่ตัวสุ่มเลือกมาจริง ๆ พร้อม log-probability ของโทเคนที่ถูกสุ่มภายใต้ชุดนั้น

ใครที่เคยเขียน RL loop บน LLM จะรู้ทันทีว่าทำไมนี่สำคัญ: เวลาจะคำนวณ importance ratio หรือ KL penalty ตอนเทรน คุณต้องรู้ว่า distribution ที่ตัว sampler ใช้ตอน rollout หน้าตาอย่างไร — แต่ถ้าเสิร์ฟด้วย top-k/top-p การกู้ distribution นั้นกลับมาหมายถึงการ จำลองการตัดปลายใหม่ทั้งหมดฝั่ง trainer ซึ่งพลาดง่ายและเป็นแหล่งของบั๊ก off-policy ที่หาไม่เจอ การคืนมาสก์ตรง ๆ ตัดปัญหานี้ทิ้งทั้งก้อน

ที่น่าประทับใจกว่าคือมันเร็วขึ้นด้วย: มาสก์ทำงานร่วมกับ overlap scheduling แล้ว และบน Qwen3-8B ให้ decode throughput สูงขึ้น 17% ที่ batch 1 และ 52% ที่ batch 64 เทียบกับการ implement เดิม ความจุกำหนดด้วย --sampling-mask-max-tokens (ค่าเริ่มต้น 4096) และใช้ร่วมกับ DisallowedTokensLogitsProcessor ได้

สำหรับคนดูแลเครื่องเสิร์ฟ: แคชและการโหลด

Unified radix tree เพิ่มการแคชที่ “จุดแตกแขนง” สำหรับส่วน sliding-window attention (SWA) — คือเก็บสถานะของหน้าต่างเลื่อนไว้ ณ จุดที่คำขอแตกออกจาก prefix ร่วม เพื่อให้แต่ละกิ่งเอาไปใช้ซ้ำแทนที่จะคำนวณใหม่ ผลบน DeepSeek-V4-Flash ที่ใช้ system prompt ร่วมกัน: token hit rate ขึ้นจาก 43.8% เป็น 60.8% และ mean TTFT ลดจาก 1.57 วินาที เหลือ 1.07 วินาที นอกจากนี้ยังมี external linker แบบเลือกเปิดที่ให้ tree ชี้ไปยัง global memory pool ร่วมผ่าน Mooncake หรือ UMBP ได้

การโหลดโมเดลบน ROCm คือรายการที่ใครใช้การ์ด AMD ควรอ่าน: การคัดลอกหน่วยความจำ host→device ก้อนใหญ่แบบ pageable ถูกเปลี่ยนไปใช้วิธี staging แทนการ pin ในที่ ซึ่งหยุดอาการที่ไดรเวอร์ระงับคิว GPU ทุกครั้งที่มีการ evict ผลลัพธ์: GLM-5.2 ที่ TP4 บน 4×MI355X โหลดเสร็จใน 40.4 วินาที แทนที่จะเป็น 505.7 วินาที — เร็วขึ้นกว่า 12 เท่า ซึ่งเป็นความต่างระหว่าง “restart ได้สบาย ๆ” กับ “ไม่กล้า restart”

SGLang Simulator เป็นของใหม่ที่น่าสนใจสำหรับคนวางแผนความจุ: ตัวจำลองที่รันบน CPU ล้วน โดยใช้สเกดูเลอร์จริง, radix cache จริง และ hierarchical cache จริง แต่แทนที่ forward ของโมเดลด้วยตัวทำนาย latency เทียบกับ trace การเสิร์ฟจริงแล้วมันทำนาย TTFT คลาดเคลื่อนราว 6% ในเทรซส่วนใหญ่ (ถึง 10% ในเทรซยาวสุด 32K–128K) และทำนายการใช้ prefix ซ้ำคลาดเคลื่อนไม่เกิน 0.05 percentage point — แปลว่าศึกษาเรื่องนโยบายแคชและการจัดคิวได้โดยไม่ต้องจอง GPU

ฮาร์ดแวร์และโมเดลที่รองรับเพิ่ม

รอบนี้ฝั่งการ์ดมีของให้หลายค่าย:

• DeepSeek-V4 บน Blackwell — เคอร์เนล attention ของ TRT-LLM ครอบคลุมเลเยอร์ CSA และ HCA บน SM100/SM103 แล้ว เร็วกว่า FlashMLA ระดับเคอร์เนลบน B200 ราว 1.2 เท่าตอน prefill และ 1.45 เท่าตอน decode ส่วน FlashInfer MegaMoE เปิดใช้ผ่าน --moe-runner-backend flashinfer_megamoe เพิ่ม prefill throughput ได้ถึง 11.9% บน DeepSeek-V4-Flash NVFP4 ที่ TP4/DP4
• DeepSeek-V4 บน RTX PRO 6000 — อันนี้คือรายการที่กระทบคนไทยมากที่สุด: บน SM120 ตัว sparse-MLA indexer ย้ายไปรันบนเคอร์เนล paged-MQA ของ DeepGEMM และเปิด DeepGEMM FP4 MoE backend แทน torch fallback ที่เคยเป็นทางเดียวที่ใช้ได้ ผลบน 4×RTX PRO 6000: decode TPOT ลดจาก 36.1 เหลือ 10.5 มิลลิวินาที ที่ batch 1 และ TTFT ลดลง 20% ในช่วงอินพุต 8K–128K (ต้องเปิดผ่าน environment flag ใน PR)
• Intel XPU เข้าชุดอิมเมจรีลีส — ทุกรีลีสที่ติดแท็กจะ build และเผยแพร่ lmsysorg/sglang:vX.Y.Z-xpu แล้ว ผู้ใช้ Intel GPU ไม่ต้องพึ่ง nightly อีกต่อไป
• DSpark ใต้ PD พร้อม decode context parallelism — prefill แบบ DCP1 ส่ง draft KV ของ DSpark ไปยัง decode แบบ DCP-N ได้แล้ว ทำให้โมเดลไฮบริดอย่าง Kimi-Linear รัน DSpark ในโหมด disaggregated + context-parallel ได้ (ทดสอบบน 8×B300 ผ่าน NIXL และ Mooncake ถึงอินพุต 256K)

โมเดลที่รองรับเพิ่มในรีลีสนี้ได้แก่ GLM-5.3-Flash, Hy4-Preview, Qwen3.8-Flash-Next, K2 Horizon, Nanbeige4.2 และฝั่ง diffusion มี SenseNova-U1.5-8B-MoT, FastH3 (distill แบบ 4 ขั้นของ MiniMax-H3) และ VDN-H3 (distill แบบ hybrid-attention)

สองรายการที่จะทำให้คนอัปเกรดแล้วพัง

รีลีสนี้มี breaking change ที่ควรอ่านก่อนกด upgrade:

1. /v1/responses ไม่เก็บผลลัพธ์ในหน่วยความจำอีกต่อไป เว้นแต่จะสตาร์ตเซิร์ฟเวอร์ด้วย --enable-response-store — ถ้าไม่เปิด การเรียกดูผลย้อนหลัง, การต่อบทสนทนาด้วย previous_response_id และ background request จะคืน 400 ทั้งหมด และ PD deployment เปิดไม่ได้เลย ใครที่สร้างแอปโดยพึ่ง previous_response_id จะพังทันทีหลังอัปเกรด
2. Prefill context parallelism v1 ถูกถอดออก — เหลือเฉพาะ implement แบบ strategy-based เท่านั้น รันไทม์ v1 และออปชัน CLI ของมันหายไป และ prefill CP บน HIP, NPU และ MUSA ถูกปฏิเสธ จนกว่าจะพอร์ตแพลตฟอร์มเหล่านั้นเสร็จ

มุมมอง AI Curator

ถ้าจะสรุปรีลีสนี้ด้วยประโยคเดียว ผมจะบอกว่า SGLang กำลังเลิกเป็นแค่ “เซิร์ฟเวอร์ inference” แล้วกลายเป็นโครงสร้างพื้นฐานของลูปเทรนด้วย — return_sampling_mask ไม่ใช่ฟีเจอร์ของคนเสิร์ฟ แต่เป็นฟีเจอร์ของคนเทรน และการที่มันมาพร้อมตัวเลขความเร็วที่ดีขึ้นแทนที่จะเป็นค่าใช้จ่ายเพิ่ม บอกว่าทีมมองงาน RL เป็น first-class workload ไม่ใช่กรณีพิเศษที่ต้องทนใช้ hack ฝั่ง trainer นี่คือทิศทางเดียวกับที่ vLLM กับ TRL/veRL เดินอยู่ และเป็นสัญญาณว่าปี 2026 เส้นแบ่งระหว่าง “เครื่องเสิร์ฟ” กับ “เครื่องเทรน” จะจางลงเรื่อย ๆ

แต่สิ่งที่ผมคิดว่าถูกมองข้ามที่สุดคือ SGLang Simulator ในภูมิภาคที่ GPU หายากและแพงอย่างอาเซียน เครื่องมือที่ให้คุณตอบคำถาม “ถ้า system prompt ยาวขึ้น 2 เท่า TTFT จะเป็นเท่าไหร่” หรือ “policy แคชแบบไหนคุ้มกับ traffic ของเรา” ได้บนแล็ปท็อป โดยคลาดเคลื่อนราว 6% คือการประหยัดที่จับต้องได้จริง — ไม่ใช่เพราะมันเร็ว แต่เพราะมัน ไม่ต้องแย่ง GPU กับทีมอื่นเพื่อทำการทดลองที่ตอบได้ด้วยการจำลอง ผมอยากให้ทีมไทยที่กำลังทำ capacity planning ลองของชิ้นนี้ก่อนจะไปเช่า H100 เพิ่มอีกชั่วโมง

ส่วนรายการ RTX PRO 6000 — TPOT จาก 36.1 เหลือ 10.5 มิลลิวินาที คือความต่างระหว่าง “เดโมได้” กับ “เสิร์ฟผู้ใช้จริงได้” บนการ์ดที่ซื้อได้จริงในราคาที่องค์กรขนาดกลางเอื้อม สำหรับหน่วยงานไทยที่ต้องรันโมเดลในประเทศด้วยเหตุผลด้านข้อมูล นี่มีค่ากว่าตัวเลข B200 ที่สวยกว่าแต่ซื้อไม่ได้ ข้อควรระวังคือมันยังต้องเปิดผ่าน environment flag — แปลว่าเป็นเส้นทางที่ยังใหม่และยังไม่ผ่านการใช้งานหนักในวงกว้าง อย่าพึ่งพาใน production โดยไม่ทดสอบซ้ำด้วยภาระงานของตัวเอง

สุดท้าย ข้อ --enable-response-store คือบทเรียนซ้ำซากที่ยังเกิดขึ้นทุกปี: API ที่เก็บ state ไว้ในหน่วยความจำเซิร์ฟเวอร์โดยเปิดเป็นค่าเริ่มต้น คือกับดักที่รอวันระเบิด ทีม SGLang เลือกทางที่ถูกแล้วที่ทำให้มันต้องเปิดเอง แต่ทีมไหนที่สร้างแอปโดยผูกกับ previous_response_id ควรถือโอกาสนี้ย้ายสถานะบทสนทนาไปไว้ฝั่งแอปของตัวเองเสียเลย มากกว่าจะแค่เพิ่มแฟล็กแล้วเลื่อนปัญหาไปข้างหน้า

แหล่งข่าว

• SGLang v0.5.20 — release notes
• sgl-project/sglang บน GitHub
• SGLang Cookbook (รายชื่อโมเดลที่รองรับ)
• โพสต์ของเราเรื่อง SGLang v0.5.19