Google เปิดสถาปัตยกรรม Tunix สำหรับ agentic RL — แก้ปัญหา TPU นั่งว่างรอ tool ด้วย async rollout และ pipeline ไร้ barrier

เมื่อวันที่ 21 กรกฎาคม 2026 Google Developers Blog เผยแพร่บทความเชิงเทคนิคอธิบายสถาปัตยกรรมของ Tunix ไลบรารี post-training แบบ JAX-native ของ Google ในมุมที่ยังไม่เคยลงรายละเอียดมาก่อน นั่นคือการฝึกแบบ agentic RL — การเทรนโมเดลที่ต้องคิดหลายเทิร์น เรียก API และโต้ตอบกับสภาพแวดล้อมจริง

(เราเคยเขียนถึง Tunix มาแล้วในบริบทของ Tunix Hackathon และสูตรฝึก reasoning ให้ Gemma เมื่อ 30 พ.ค. — โพสต์นี้เป็นคนละเรื่อง ว่าด้วยสถาปัตยกรรมด้านโครงสร้างพื้นฐานที่ทำให้ agentic RL scale ได้)

ปัญหา: accelerator นั่งว่างรอโลกภายนอก

คอขวดของ agentic RL ต่างจาก RLHF แบบเทิร์นเดียวโดยสิ้นเชิง Google ระบุปัญหาไว้สามข้อ:

1. Accelerator idle time — เมื่อ agent หยุดเพื่อรัน tool, query ฐานข้อมูล หรือค้นเว็บ TPU จะนั่งว่างรอ environment ตอบกลับ ทำให้ utilization ตกฮวบ นี่คือปัญหาที่แปลกสำหรับคนที่ชินกับการเทรนแบบเดิม เพราะเวลาที่เสียไปไม่ได้อยู่ที่การคำนวณ แต่อยู่ที่การ รอ I/O ของโลกภายนอก ที่ควบคุมไม่ได้

2. Synchronization delays — สถาปัตยกรรม rollout แบบ synchronous ทำให้เกิด execution bubble และปัญหา straggler เวลารวม trajectory ที่มีความยาวไม่เท่ากันเป็น batch หนึ่ง trajectory ที่ยาวผิดปกติจะดึงทั้ง batch ให้ช้าตาม

3. Pipeline stalls — การบังคับให้ trainer รอจน trajectory ครบทั้ง batch ก่อนจะเริ่ม training step เท่ากับปล่อยให้ accelerator อดอยาก

ทางแก้: asyncio, producer-consumer และ engine เฉพาะทาง

Asynchronous rollouts — Tunix ใช้ asyncio ของ Python ภายในคอมโพเนนต์ชื่อ RolloutOrchestrator เพื่อจัดการ pool ขนาดใหญ่ของการโต้ตอบ agent-environment ที่รันพร้อมกัน แนวคิดคือแทนที่จะรอ trajectory เดียวให้จบ ก็ปล่อยหลายร้อยเส้นทางวิ่งพร้อมกัน ใครรอ tool อยู่ก็ปล่อยรอไป ส่วน accelerator เอาไปประมวลผลเส้นทางอื่นที่พร้อมแล้ว

Barrier-free pipelining — ใช้สถาปัตยกรรม producer-consumer ที่แยกส่วนกัน คอย batch trajectory ความยาวไม่เท่ากันอย่างต่อเนื่อง และ stream trajectory ที่เสร็จแล้วเข้าสู่ trainer ทันทีโดยไม่ต้องรอทั้งชุด — จุดนี้คือหัวใจ เพราะมันตัด barrier ที่เป็นต้นเหตุของ bubble ออกไป

การต่อกับ inference engine — Tunix เชื่อมกับ vLLM-TPU และ SGLang-Jax โดยตรง ซึ่งสำคัญเพราะ rollout ในงาน RL คือการ inference จำนวนมหาศาล ถ้าใช้ engine ที่ไม่ได้ปรับมาเพื่อ throughput จะกลายเป็นคอขวดใหม่ทันที

Composable design — มี API ที่ชัดเจนสำหรับสร้าง agent และ environment เอง พร้อมคลาสสำเร็จรูปอย่าง TaskEnvironment, ToolEnvironment, ModelAgent และ ToolAgent ทำให้ต่อกับ environment โอเพนซอร์สอย่าง SWE-bench และ WebArena ได้เร็ว

Profiling และตำแหน่งในระบบนิเวศ

Tunix มีเครื่องมือ instrumentation เฉพาะทางที่เบากว่า XProf สำหรับติดตาม metric ของ RL loop แบบต่อเนื่อง และเชื่อม metric ระดับสูงเข้ากับ timeline ของ TPU ได้ ดูผลผ่าน Perfetto trace เห็นการทำงานเป็นสเตจทั้งฝั่ง CPU และ TPU — ซึ่งจำเป็นมากสำหรับการดีบักงาน RL ที่ปัญหามักซ่อนอยู่ในช่องว่างระหว่างสเตจ ไม่ใช่ในตัว kernel

ตัวไลบรารีอยู่บน GitHub ที่ google/tunix ภายใต้ license Apache-2.0 (รุ่นล่าสุดที่ปรากฏคือ v0.1.7 เมื่อ 11 มิ.ย. 2026) README ระบุว่ารองรับ SFT (full weights, LoRA/PEFT, DPO, ORPO) และฝั่ง RL รองรับ PPO, GRPO, GSPO-Token, DAPO, Dr.GRPO รวมถึง agentic RL แบบ multi-turn tool use พร้อม async rollout เอกสารอยู่ที่ tunix.readthedocs.io และมี recipe ตัวอย่างสำหรับ SWE coding agent, math reasoning และ gaming agent ในโฟลเดอร์ /examples

Google วางตำแหน่ง Tunix ว่าเป็น “LLM-first” สำหรับระบบนิเวศ JAX/TPU โดยเทียบกับ OpenRLHF/veRL ที่เป็น PyTorch-centric ใช้ Ray + vLLM, Hugging Face TRL ที่ออกแบบมาสำหรับ SFT/RLHF แบบเทิร์นเดียว และ Ray RLlib ที่เป็น RL ทั่วไปและมี overhead ในการต่อกับ LLM

ข้อควรระบุ: บทความนี้ไม่ได้ให้ตัวเลข throughput, latency หรือผลเทียบกับเฟรมเวิร์กอื่นเลย มีแต่คำอธิบายเชิงคุณภาพว่า TPU utilization ดีขึ้น ใครจะเลือกใช้ต้องวัดเอง

มุมมอง AI Curator

สิ่งที่บทความนี้บอกโดยไม่ได้พูดตรง ๆ คือ agentic RL กำลังกลายเป็นปัญหาวิศวกรรมระบบมากกว่าปัญหา ML สามคอขวดที่ Google ยกมา — idle time, straggler, pipeline stall — ไม่มีข้อไหนเป็นเรื่อง loss function หรือ reward design เลย ทั้งหมดเป็นปัญหาคลาสสิกของระบบกระจาย ซึ่งเปลี่ยนโจทย์ของทีมที่อยากทำ RL post-training: คนที่คุณต้องการอาจไม่ใช่ ML researcher เพิ่ม แต่เป็นคนที่เข้าใจ async I/O และ scheduling

ประเด็นที่ควรตั้งคำถามคือ ต้นทุนของการผูกกับ JAX/TPU Tunix เป็น Apache-2.0 จริง โค้ดเปิดจริง แต่จุดแข็งที่โฆษณา — Pathways multi-host, การปรับ XLA, vLLM-TPU, SGLang-Jax — ล้วนหมายถึง TPU ทั้งสิ้น สำหรับทีมที่รันบน GPU ซึ่งเป็นค่าเริ่มต้นของเกือบทุกทีมนอก Google การย้ายมา JAX เพื่อใช้ Tunix เป็นการตัดสินใจที่แพงกว่าที่ตัวเลข “Apache-2.0” ทำให้รู้สึก ระบบนิเวศ PyTorch (veRL, OpenRLHF, TRL) ยังเป็นทางที่ friction ต่ำกว่ามากถ้าคุณไม่ได้อยู่บน TPU อยู่แล้ว

สำหรับบริบทไทยและ SEA ผมมองว่าคุณค่าที่แท้จริงของโพสต์นี้อยู่ที่ การอธิบายปัญหา ไม่ใช่ตัวเครื่องมือ ทีมไทยส่วนใหญ่ยังไม่ได้ทำ agentic RL ขนาดใหญ่ และคงไม่ได้ทำในปีนี้ — งบ compute ไม่เอื้อ แต่คำอธิบายเรื่อง async rollout กับ barrier-free pipelining เป็นความรู้ที่ถ่ายโอนได้ทันทีไปยังงานที่ทีมไทยทำจริง นั่นคือ การรัน agent จำนวนมากพร้อมกันในโปรดักชัน ปัญหาเดียวกันเป๊ะ: agent หยุดรอ API ธนาคาร รอผลจากฐานข้อมูล รอ OCR สลิป แล้ว worker นั่งว่าง ใครที่เคยเห็นบิล inference พุ่งเพราะ concurrency ต่ำจะอ่านบทความนี้แล้วเข้าใจทันทีว่าปัญหาอยู่ตรงไหน

จุดที่น่าจับตาต่อไปคือ environment ไม่ใช่ตัวเทรนเนอร์ การที่ Tunix ชูการต่อกับ SWE-bench และ WebArena สะท้อนว่าของหายากในงาน agentic RL คือ สภาพแวดล้อมที่ให้ reward ที่เชื่อถือได้ ไม่ใช่โค้ดเทรน ใครสร้าง environment ที่วัดงานจริงได้แม่น — โดยเฉพาะงานเฉพาะทางในภาษาไทยหรือบริบทธุรกิจไทย — จะมีของที่มีค่ากว่า GPU cluster เสียอีก และนั่นเป็นช่องที่ทีมเล็กแข่งได้จริงโดยไม่ต้องมี TPU pod

แหล่งข่าว

• Scaling Agentic RL: High-Throughput Agentic Training with Tunix — Google Developers Blog (21 ก.ค. 2026)
• google/tunix — GitHub (Apache-2.0)