Ray 2.55 ยก TPU ขึ้นเป็น accelerator ชั้นหนึ่ง — เลิกยุคสร้าง container เอง แล้วจอง slice ทั้งก้อนด้วยฟังก์ชันเดียว

ใครที่เคยพยายามรัน Ray บน TPU จะรู้ว่ามันไม่เหมือนรันบน GPU เลย — ที่ผ่านมาการรองรับ TPU อยู่ในสถานะ “experimental” แปลว่าคุณต้องสร้าง container เอง ประกอบ dependency เอง และเขียนโค้ดจัดตำแหน่ง worker เองทั้งหมด

วันที่ 20 กรกฎาคม 2026 Google ประกาศบน Developers Blog ว่า Ray 2.55 เป็นต้นไป ยก TPU ขึ้นเป็น “first-class accelerator” แล้ว มี pre-built image อยู่ใน release pipeline อย่างเป็นทางการ และรองรับข้ามไลบรารีหลักครบ ไม่ต้องประกอบเองอีกต่อไป

ปัญหาที่แก้: TPU ไม่ยอมให้คุณกระจาย worker ตามใจ

ข้อจำกัดเชิงสถาปัตยกรรมของ TPU คือชิปต้องอยู่บน slice เดียวกัน — กลุ่ม host ที่เชื่อมต่อกันด้วย interconnect ความเร็วสูง ถ้า worker ของคุณกระจายข้าม slice งาน distributed จะพังทันที ไม่ใช่ช้าลง แต่พังเลย

นี่คือความต่างที่ทำให้ pattern แบบ GPU ใช้กับ TPU ตรง ๆ ไม่ได้ บน GPU คุณขอ “8 ตัว” แล้ว scheduler จะหาให้จากที่ไหนก็ได้ บน TPU คุณต้องได้ ทั้ง slice พร้อมกัน หรือไม่ได้เลย

Ray 2.55 แก้ด้วยของสองชิ้น

• slice_placement_group() จาก ray.util.tpu — จองทั้ง slice แบบ atomic ในคำสั่งเดียว แทนที่จะต้องเขียนตรรกะจัดตำแหน่งเอง
• GKE Ray Operator add-on ที่มี TPU-aware webhook ติดป้าย (label) slice ให้อัตโนมัติ ทำให้ฝั่ง Kubernetes รู้จักโครงสร้าง slice โดยที่คุณไม่ต้องบอก

ผลคือโค้ดจัดตำแหน่งด้วยมือที่เคยเป็นแหล่งบั๊กหลักของงาน multi-host TPU หายไปทั้งชั้น

ครอบคลุมทั้ง Data, Train และ Serve

การรองรับไม่ได้จำกัดอยู่ที่ core scheduler แต่ครอบไปถึงไลบรารีที่คนใช้จริง — Ray Data, Ray Train และ Ray Serve พร้อมการรองรับ JaxTrainer สำหรับสาย JAX โดยตรง

ความหมายเชิงปฏิบัติคือทีมที่เขียน pipeline แบบ Ray บน GPU อยู่แล้ว สามารถย้ายมาที่ TPU ได้ด้วย pattern และ API ชุดเดิม ไม่ต้องเรียนรู้เครื่องมือคนละชุดสำหรับ accelerator คนละยี่ห้อ ซึ่งเป็นเหตุผลหลักที่หลายทีมไม่เคยลอง TPU จริงจังแม้จะมีเครดิตคลาวด์อยู่ในมือ

โพสต์นี้ระบุว่าเป็น Part 1: The Foundations — ยังมีตอนต่อไป

มุมมอง AI Curator

เรื่องนี้ดูเป็นข่าวโครงสร้างพื้นฐานที่น่าเบื่อ แต่ผมคิดว่ามันคือหนึ่งในการเคลื่อนไหวที่ Google ควรทำมานานแล้ว และมันสะท้อนโจทย์ที่ใหญ่กว่าตัว Ray เอง

ปัญหาของ TPU ไม่เคยเป็นเรื่องประสิทธิภาพหรือราคา แต่เป็น ต้นทุนการเปลี่ยนเครื่องมือ โลกของ ML engineering ถูกสร้างบนสมมติฐานว่า accelerator คือ NVIDIA GPU ตั้งแต่ CUDA ลงไปจนถึง scheduler ยิ่ง TPU บังคับให้เขียนโค้ดจัดตำแหน่ง slice เอง ยิ่งตอกย้ำว่ามันเป็น “ทางเลือกสำหรับคนที่ยอมลงทุนเรียนรู้” แทนที่จะเป็นทางเลือกที่ลองได้ในบ่ายวันเดียว การทำให้ slice_placement_group() ซ่อนความต่างนั้นไว้ในฟังก์ชันเดียว คือการลดต้นทุนตรงจุดที่ควรลด

สำหรับทีมไทย ผมเห็นสองกลุ่มที่ควรสนใจ

กลุ่มแรก — ทีมที่ทำ post-training หรือ fine-tune โมเดลไทย (Typhoon, OpenThaiGPT หรือทีมมหาวิทยาลัย) กลุ่มนี้มักเจอกำแพงเดียวกันคือ หา GPU cluster ไม่ได้ในราคาที่จ่ายไหว TPU ผ่านโครงการวิจัยหรือเครดิต Google Cloud เป็นทางออกที่มีอยู่จริงมานาน แต่ต้นทุนการย้ายโค้ดทำให้หลายทีมพับไป ถ้าคุณเขียน pipeline บน Ray อยู่แล้ว ต้นทุนนั้นเพิ่งลดลงอย่างมีนัยสำคัญ — และควรอ่านคู่กับ Tunix ที่เราเขียนถึงเช้านี้ ซึ่งเป็นอีกชิ้นในจิ๊กซอว์ agentic RL บน TPU ของ Google ชุดเดียวกัน

กลุ่มที่สอง — ทีมที่ทำ inference สเกลใหญ่ การที่ Ray Serve รองรับ TPU เต็มตัวหมายถึงคุณเลือก accelerator ตามราคาต่อโทเคนได้จริง ไม่ใช่ตามว่าเครื่องมือรองรับอะไร ในตลาดที่ราคา GPU ยังผันผวนและคิวรอยังยาว ความยืดหยุ่นตรงนี้มีมูลค่า

ข้อควรระวังที่ต้องพูดตรง ๆ: นี่คือการผูกกับ Google Cloud ล้วน ๆ TPU ไม่มีขายที่อื่น และ ray.util.tpu ไม่ได้ทำให้โค้ดคุณพกพาไปที่ไหนได้ Ray ยังเป็นชั้น abstraction ที่ดีที่ทำให้ ตรรกะแอปพลิเคชัน ของคุณย้ายได้ แต่ชั้นจอง slice นั้นผูกแน่นกับแพลตฟอร์มเดียว ทีมที่ตั้งใจใช้กลยุทธ์หลายคลาวด์ควรวางเส้นแบ่งให้ชัดว่าโค้ดส่วนไหน “รู้จัก TPU” ตั้งแต่วันแรก มากกว่าจะไปแยกทีหลังตอนย้าย

แหล่งข่าว

• Run Ray on TPU, Part 1: The foundations — Google Developers Blog
• Ray documentation — ray.util.tpu