TensorCast: ชั้นกลางใหม่สำหรับจัดการน้ำหนักโมเดล KV Cache และสถานะเทนเซอร์ของ AI

TensorCast คือชั้นระบบ Tensor-as-a-Service (TaaS) ที่เสนอให้การจัดการวงจรชีวิตของเทนเซอร์เป็นบริการแยกจากการคำนวณของโมเดล กล่าวคือ ระบบสามารถจัดการตัวตน ตำแหน่ง การเคลื่อนย้าย การแปลง การแชร์ และการนำเทนเซอร์ไปสร้างเป็นข้อมูลพร้อมใช้งานได้ โดยไม่ผูกติดกับเอนจินที่เป็นผู้สร้างหรือผู้ใช้เทนเซอร์นั้นโดยตรง 1

แนวคิดนี้มีความสำคัญในเชิงสถาปัตยกรรม เพราะพยายามรวมสิ่งที่ปัจจุบันมักถูกพัฒนาแยกกัน ไม่ว่าจะเป็นตัวโหลดน้ำหนักโมเดล ระบบ KV Cache เส้นทางเครือข่าย และแบ็กเอนด์สตอเรจ ให้ทำงานผ่านชั้นควบคุมเดียวที่ตั้งโปรแกรมได้สำหรับการให้บริการ AI แบบไดนามิก 1

ทำไมต้องพัฒนา TensorCast

ระบบโมเดลภาษาขนาดใหญ่ไม่ได้จัดการแค่น้ำหนักโมเดลที่มีขนาดใหญ่เท่านั้น แต่ยังต้องดูแล KV Cache ซึ่งเป็นสถานะของบริบทการสนทนาที่เปลี่ยนแปลงตลอดเวลา รวมถึงสถานะกลางอื่น ๆ ระหว่างการประมวลผลด้วย เดิมความรับผิดชอบเหล่านี้มักกระจายอยู่ในเอนจินอินเฟอเรนซ์ ตัวจัดตาราง ระบบส่งข้อมูล และสตอเรจคนละส่วน ทำให้การผสมนโยบายใหม่ ๆ หรือปรับแต่งการทำงานข้ามส่วนประกอบเป็นเรื่องยุ่งยาก 1

TensorCast จึงมองว่าการจัดการวงจรชีวิตของเทนเซอร์เป็น “ชั้นระบบที่หายไป” แอปพลิเคชันเพียงระบุว่าต้องการให้สถานะเทนเซอร์ถูกจัดการอย่างไร ขณะที่รันไทม์จะเลือกและดำเนินการเรื่องตำแหน่ง การเคลื่อนย้าย การแปลง และการนำข้อมูลไปสร้างบนทรัพยากรต่าง ๆ ในคลัสเตอร์ 1

แนวทางนี้ต่างจากออบเจ็กต์สตอเรจทั่วไปที่มักมองข้อมูลเป็นก้อนทึบ และต่างจากเฟรมเวิร์กที่เน้นการคำนวณซึ่งให้ความสำคัญกับการจัดตารางงานมากกว่าการดูแลวงจรชีวิตของสถานะเทนเซอร์ 1

องค์ประกอบหลักของ TensorCast

• เทนเซอร์เป็นออบเจ็กต์ระดับแรกของระบบ: เทนเซอร์แต่ละรายการมีตัวตน เจ้าของ ตำแหน่ง และความหมายด้านวงจรชีวิตอย่างชัดเจน เอนจินจึงสามารถอ้างถึงน้ำหนักโมเดล บล็อก KV Cache หรือสถานะกลางได้ โดยไม่ต้องผูกการอ้างอิงเข้ากับโหนด GPU หรือสื่อจัดเก็บที่แน่นอน 1
• คำสั่งวงจรชีวิตที่นำมาประกอบกันได้: นักพัฒนาสามารถนำการย้ายข้อมูล การแปลง การพรีเฟตช์ การทำสำเนา และการ materialize มาประกอบเป็นนโยบายเฉพาะงานได้ แทนที่จะต้องแก้โครงสร้างพื้นฐานระดับล่างทุกครั้งที่ต้องการเพิ่มการปรับแต่งใหม่ 1
• แยกนโยบายออกจากกลไกการทำงาน: นโยบายสามารถเขียนผ่าน API ของ TensorCast ส่วนรันไทม์จะรับผิดชอบการประมวลผลแบบกระจายและการเคลื่อนย้ายข้อมูล โดยไม่จำเป็นต้องแก้เอนจินประมวลผลที่อยู่เบื้องหลัง 1
• แยก control plane และ data plane: Global Store (GS) ทำหน้าที่เก็บเมทาดาทาของคลัสเตอร์ เช่น สถานะ Worker และโหนด ตำแหน่งของเทนเซอร์ ผู้ครอบครองข้อมูล และข้อมูลการจัดตาราง ขณะที่ Worker เป็นผู้เคลื่อนย้ายข้อมูลจริง GS จึงทำหน้าที่ประสานงานโดยไม่ต้องแบกข้อมูลเทนเซอร์ทั้งหมด ช่วยลดความเสี่ยงที่จะกลายเป็นคอขวดด้านการส่งข้อมูล 1
• ใช้วิธีจัดการเมทาดาทาต่างกันตามลักษณะข้อมูล: ข้อมูลที่มีจำนวนรายการไม่มากและค่อนข้างคงที่ เช่น น้ำหนักโมเดล สามารถติดตามจาก GS ส่วนข้อมูลที่มีจำนวนมากและเปลี่ยนแปลงเร็ว เช่น KV Cache จะถูกแบ่งเป็นชาร์ด โดย Worker ที่ดูแลชาร์ดจะรับผิดชอบความเป็นเจ้าของและความสอดคล้องของข้อมูลผ่าน lease และ fencing token 1
• นำข้อมูลไปใช้งานโดยลดการคัดลอก: รีพลิกาบน Worker สามารถเปิดเผยหน่วยความจำ GPU ผ่าน CUDA IPC หรือหน่วยความจำ CPU ผ่าน local memfd handle ส่วนแหล่งข้อมูลระยะไกลรองรับการเขียนโดยตรงผ่าน RDMA กลไกเหล่านี้ช่วยลดสำเนาที่ไม่จำเป็น และเปิดทางให้แชร์ข้อมูลระหว่าง GPU หรือภายในโหนดเดียวกันได้เมื่อสภาพแวดล้อมรองรับ 6

ทำไมการย้าย KV Cache จึงง่ายขึ้น

ในระบบให้บริการแบบเดิม การย้ายเซสชันสนทนาหลายรอบจากอินสแตนซ์หนึ่งไปยังอีกอินสแตนซ์หนึ่ง อาจต้องแก้ไขและประสานงานพร้อมกันทั้งตัวกำหนดเส้นทางคำขอ ระบบ KV Cache ของเอนจินอินเฟอเรนซ์ และแบ็กเอนด์แคชหรือเครือข่าย

ภายใต้ TensorCast นักพัฒนาสามารถเขียนนโยบายให้ระบุออบเจ็กต์ KV ของเซสชัน ขอให้ระบบจัดวางหรือ materialize ข้อมูลเหล่านั้นบน Worker ปลายทาง แล้วส่งคำขอถัดไปไปยังปลายทางดังกล่าว ส่วนการค้นหาข้อมูล การถ่ายโอน และการผูกข้อมูลเข้ากับหน่วยความจำจะเป็นหน้าที่ของรันไทม์จัดการวงจรชีวิต 1

ประโยชน์สำคัญไม่ได้หมายความว่าการย้ายแคชจะไม่มีต้นทุน แต่คือการเขียนนโยบายเพียงครั้งเดียวที่ชั้นวงจรชีวิตของเทนเซอร์ แทนการนำตรรกะเดียวกันไปสร้างซ้ำในหลายส่วนประกอบที่เชื่อมโยงกันแน่นหนา วิธีนี้ทำให้นโยบายข้ามระบบ เช่น การเลือกเส้นทางตามตำแหน่งแคช การใช้ซ้ำน้ำหนักโมเดล หรือการวางสถานะที่เกี่ยวข้องไว้ใกล้กัน สามารถทดลองและนำไปใช้งานได้ง่ายขึ้น 1

ผลทดสอบที่รายงาน

• ผู้วิจัยผสาน TensorCast เข้ากับทั้ง vLLM และ SGLang พร้อมประเมินการนำโมเดลเวตไปสร้างเป็นข้อมูลพร้อมใช้งาน การซิงโครไนซ์น้ำหนัก การจัดการ KV Cache และการกำหนดเส้นทางคำขอแบบตั้งโปรแกรมได้ 1
• ประสิทธิภาพด้าน KV Cache ที่รายงานอยู่ในระดับแข่งขันกับ Mooncake ซึ่งเป็นระบบ KV Cache เฉพาะทาง ขณะที่ TensorCast ยังสามารถรองรับนโยบายที่ทำงานข้ามหลายส่วนประกอบได้ 1
• สำหรับการเริ่มต้นอินสแตนซ์ของ Qwen3-235B-A22B ซึ่งมีพารามิเตอร์ทั้งหมด 235 พันล้านรายการ และมีพารามิเตอร์ที่ถูกเปิดใช้งาน 22 พันล้านรายการ งานวิจัยรายงานว่า TensorCast เริ่มระบบได้เร็วขึ้นสูงสุด 228.6 เท่า เมื่อเทียบกับระบบไฟล์แบบกระจายทั่วไป 12
• ในงานเอเจนต์ที่มีคำขอพร้อมกันจำนวนมากและเป็นบทสนทนาหลายรอบ นโยบายของ TensorCast ช่วยลดค่า median ของ time-to-first-token (TTFT) หรือเวลาจนกว่าจะได้รับโทเคนแรก ได้สูงสุด 93.2% 1

ผลลัพธ์เหล่านี้สะท้อนศักยภาพของ TensorCast ต่อโครงสร้างพื้นฐาน AI ที่ต้องขยายและเปลี่ยนแปลงตามภาระงาน เพราะการเริ่มโมเดลอย่างรวดเร็ว การกำหนดเส้นทางโดยคำนึงถึงแคช การย้ายสถานะ และการใช้เทนเซอร์ซ้ำ สามารถกำหนดเป็นนโยบายของระบบได้ แทนที่จะเป็นการปรับแต่งเฉพาะจุดในแต่ละเฟรมเวิร์ก 1

อย่างไรก็ตาม ตัวเลขทั้งหมดเป็นผลการทดลองที่ผู้เขียนรายงานจากงานวิจัยฉบับพรีพรินต์ จึงยังต้องรอการทำซ้ำโดยอิสระและการตรวจสอบในสภาพแวดล้อมระดับการผลิตก่อนสรุปว่าให้ผลเช่นเดียวกันในทุกกรณี 1