Tensormesh เปิดแคช LLM ข้ามโหนด แต่ตัวเลข 10 เท่าไม่ใช่ค่าทั่วไป

จากซานฟรานซิสโก Tensormesh เผยแพร่ประกาศเปิดตัว Tensormesh Platform เมื่อ 14 ตุลาคม 2026 สำหรับองค์กรที่ให้บริการโมเดลภาษาบนโครงสร้างพื้นฐานของตน โดย Junchen Jiang ซีอีโออธิบายปัญหาที่ผลิตภัณฑ์มุ่งแก้ว่า “LLM workloads recompute the same context endlessly”. บริษัทระบุว่าแพลตฟอร์มพร้อมใช้งานในวันประกาศ และวางให้เป็นชั้นจัดการสถานะที่โมเดลคำนวณระหว่างอ่านข้อความเข้า เพื่อให้เครื่องในระบบเดียวกันนำงานส่วนที่ซ้ำกลับมาใช้ได้

แกนของระบบคือการเก็บ KV cache ไว้ในหน่วยความจำ GPU หน่วยความจำเครื่อง และพื้นที่เก็บข้อมูล จากนั้นดึงสถานะที่เข้ากันได้ไปใช้กับคำขอใหม่ แม้คำขอนั้นถูกส่งไปยังอีกโหนดหนึ่ง ตัวเลขประสิทธิภาพดีขึ้นสูงสุด 10 เท่าที่คำถามพบบ่อยของ Tensormeshระบุ เป็นผลที่บริษัทวัดได้ในสภาพควบคุม โดยผลจริงขึ้นกับความซ้ำของบริบท โครงสร้างพื้นฐาน และฮาร์ดแวร์ ประโยชน์ที่คาดหวังคือเวลาถึงโทเคนแรกและภาระการคำนวณลดลงเมื่อมีงานที่ใช้ข้อความเดิมมากพอ มิใช่อัตราเร่งคงที่ของคำขอทุกแบบ

สถานะจาก prefill เดินทางไปถึงคำตอบใหม่อย่างไร

การให้บริการ LLM เริ่มจากช่วง prefill ซึ่งโมเดลอ่านข้อความทั้งหมดในพรอมป์ ตั้งแต่คำสั่งระบบ เอกสารประกอบ จนถึงประวัติสนทนาที่ส่งเข้ามา ระหว่างช่วงนี้กลไก attention สร้างค่า key และ value สำหรับโทเคนที่ผ่านการประมวลผลแล้ว และเก็บเป็นสถานะชั่วคราวให้โมเดลอ้างอิงต่อไป เมื่อเข้าสู่ช่วง decode โมเดลใช้สถานะนั้นประกอบการสร้างคำตอบทีละโทเคน พร้อมเพิ่มสถานะของโทเคนใหม่ตามลำดับ หากต้องเริ่ม prefill ใหม่กับข้อความยาวชุดเดิม งานอ่านและสร้างสถานะของข้อความเดิมก็เกิดซ้ำบน GPU

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

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

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

เหตุใดแคชต้องข้ามหน่วยความจำและข้ามโหนด

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

อีกด้านหนึ่งของปัญหาคือเครื่องที่รับคำขอใหม่อาจไม่ใช่เครื่องที่ทำ prefill ให้บริบทเดียวกันมาก่อน การส่ง KV cache แบบ peer-to-peer ทำให้โหนดที่รับงานภายหลังดึงสถานะจากโหนดที่มีอยู่แล้ว แทนการสร้างสถานะซ้ำใน GPU ของตัวเอง ความสามารถนี้ต่างจากแคชซึ่งผูกอยู่กับกระบวนการอนุมานเครื่องเดียว เพราะโอกาสใช้ซ้ำไม่หายไปทันทีเมื่อระบบกระจายคำขอไปยังเครื่องอื่น อย่างไรก็ตาม การส่งสถานะข้ามเครือข่ายจะคุ้มก็ต่อเมื่อเวลารับส่งต่ำกว่างาน prefill ที่ประหยัดได้

สำหรับการให้บริการที่แยกเครื่องทำ prefill ออกจากเครื่องทำ decode เส้นทางของสถานะยิ่งชัดขึ้น: เครื่องแรกอ่านข้อความและสร้าง KV cache แล้วเครื่องถัดไปใช้สถานะนั้นเพื่อเริ่มสร้างคำตอบ การแยกหน้าที่เปิดทางให้จัดทรัพยากรตามลักษณะงานของแต่ละช่วง แต่ทำให้การส่งต่อสถานะกลายเป็นส่วนหนึ่งของเวลารอคำตอบ แพลตฟอร์มจึงต้องจัดการว่าควรเก็บสถานะไว้ใกล้เครื่องใด ย้ายเมื่อใด และปล่อยทิ้งเมื่อใด หากเลือกตำแหน่งผิด การอ่านจากพื้นที่เก็บข้อมูลหรือการโอนผ่านเครือข่ายอาจกินเวลาที่หวังจะประหยัดจากการไม่คำนวณซ้ำ

ประกาศของบริษัทแจกแจงความสามารถด้านการตรึงรายการแคช การค้นหา การย้าย การบีบอัด และการลบผ่าน API ควบคุม เครื่องมือเหล่านี้มีความหมายเมื่อทราฟฟิกจริงมีเอกสารหรือคำสั่งร่วมกันในหลายบริการ เพราะผู้ดูแลสามารถกำหนดวงจรชีวิตของสถานะ แทนปล่อยให้แต่ละเครื่องตัดสินใจแยกกัน การสังเกตอัตรา cache hit และตำแหน่งที่ดึงแคชกลับมายังช่วยแยกผลระหว่างแคชที่พบใน GPU กับแคชที่ต้องอ่านจากชั้นอื่น ตัวเลข hit สูงจึงไม่ได้ตอบเรื่องต้นทุนทั้งหมด หากรายการที่พบต้องใช้เวลาย้ายกลับมาก

CacheBlend ขยายการใช้ซ้ำเมื่อเอกสารสลับลำดับ

การจับคู่ส่วนต้นของพรอมป์หรือ prefix caching เหมาะกับคำขอที่เริ่มด้วยโทเคนเหมือนกันยาวพอ เช่น คำสั่งระบบและเอกสารอ้างอิงชุดเดียวกันที่วางอยู่ตำแหน่งเดิม เมื่อข้อความแตกต่างตั้งแต่ต้น ระบบอาจหา prefix ร่วมกันได้น้อย แม้มีเอกสารเดิมปรากฏอยู่ตอนกลางพรอมป์ นี่เป็นลักษณะที่เกิดได้กับงาน RAG ซึ่งค้นเอกสารตามคำถาม แล้วประกอบผลค้นหาใหม่ก่อนส่งให้โมเดล เอกสารที่คุ้นเคยอาจกลับมาอีกครั้ง แต่ตำแหน่งและข้อความที่อยู่ก่อนหน้าไม่เหมือนเดิม

CacheBlend เป็นเทคนิคที่ Tensormesh ระบุว่าใช้กับการนำช่วงข้อมูลซึ่งไม่ได้อยู่ต้นพรอมป์กลับมาใช้ หลักคิดคือหยิบสถานะของส่วนเอกสารที่เคยประมวลผลมาใช้ร่วมกับการคำนวณบางโทเคนใหม่ เพื่อรับผลของบริบทที่เปลี่ยนไป สมมติว่าคำขอหนึ่งเรียงเอกสาร ก ก่อน ข แต่อีกคำขอเรียง ข ก่อน ก; การแคชเฉพาะ prefix อาจใช้ประโยชน์จากเอกสารเดิมไม่ได้เต็มที่ การดึงชิ้นสถานะมาใช้โดยไม่ปรับเลยก็เสี่ยงเพราะค่า attention ของข้อความช่วงหนึ่งเกี่ยวข้องกับข้อความที่มาก่อนมัน การคำนวณบางส่วนใหม่จึงเป็นกลไกเพื่อรักษาคุณภาพผลลัพธ์ควบคู่กับการลดงานเดิม

ประเด็นนี้ทำให้คำว่าใช้ซ้ำมีหลายระดับ งานที่ใช้คำสั่งระบบเหมือนเดิมทุกโทเคนเป็นกรณีตรงไปตรงมา ส่วนงานที่เอกสารสลับตำแหน่งอาศัยการประกอบสถานะและคำนวณทดแทนบางส่วน หากข้อมูลค้นคืนเปลี่ยนทั้งเนื้อหาและลำดับมาก แคชที่เคยเก็บไว้อาจช่วยได้น้อยจนการคำนวณใหม่เร็วกว่า ทีมที่ใช้ RAG จึงต้องดูทั้งสัดส่วนเอกสารที่กลับมา สัดส่วนโทเคนที่นำกลับมาใช้ และผลต่อคำตอบเมื่อบริบทเปลี่ยน ไม่ใช่ตัดสินจากชื่อคุณสมบัติ non-prefix caching เพียงอย่างเดียว

การรองรับระบบต้องดูรุ่นที่ใช้จริง

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

ภาษาในประกาศเปิดตัวพูดถึงการทำงานร่วมกับโมเดล ซอฟต์แวร์จัดคิวอนุมาน และผู้ให้บริการพื้นที่เก็บข้อมูลอย่างกว้าง แต่บทวิเคราะห์ของ Unite.AI ระบุว่าเมทริกซ์ความเข้ากันได้รุ่นก่อนหน้าจัด peer-to-peer transfer และการแยก prefill/decode ไว้ในแผนงาน ขณะเอกสารประกาศรุ่นใหม่กล่าวถึงความสามารถเหล่านี้แล้ว เมทริกซ์เก่านั้นยังแยกระบบอนุมานที่บริษัททดสอบแล้วออกจากระบบที่รองรับในโครงการต้นทางแต่ยังต้องทดสอบเพิ่ม ความต่างของช่วงเวลาและสถานะเอกสารหมายความว่าควรผูกคำว่าใช้งานได้กับรุ่นแพลตฟอร์ม เครื่องมืออนุมาน และรูปแบบแคชที่นำไปติดตั้งจริง

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

ความเร็วที่ควรเทียบคือเวลาและต้นทุนทั้งคำขอ

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

สำหรับทีมโครงสร้างพื้นฐานในไทย การประเมินผลควรแยกสามคำถามที่ต่างกัน: มีบริบทใช้ร่วมกันมากแค่ไหน สถานะที่ใช้ร่วมกันถูกเก็บอยู่ชั้นใด และการเรียกคืนเร็วกว่าการคำนวณใหม่เพียงใด งานแชตที่ใช้คำสั่งระบบเดียวกันอาจมี prefix ยาว แต่ถ้าผู้ใช้เปลี่ยนโมเดลหรือเทมเพลตบ่อย สถานะเก่าก็ใช้ต่อไม่ได้ งานเอกสารอาจมีการใช้ไฟล์เดิมซ้ำมาก แต่ถ้าระบบค้นคืนสลับลำดับเอกสารตลอด การจับคู่ prefix อย่างเดียวไม่พอ งานที่แคชอยู่บนพื้นที่เก็บข้อมูลไกลจาก GPU ยังต้องจ่ายค่ารับส่งข้อมูล แม้อัตรา hit ดูดี

การทดสอบด้วยทราฟฟิกที่เป็นตัวแทนงานจริงควรเทียบช่วงที่แคชว่างกับช่วงที่แคชอุ่น และใช้ชุดพรอมป์ ความยาวคำตอบ และจำนวนคำขอพร้อมกันใกล้เคียงกัน เวลาถึงโทเคนแรกที่ p50 บอกประสบการณ์คำขอกลาง ส่วน p95 ช่วยเห็นคำขอที่ช้ากว่าคนส่วนใหญ่; ควรอ่านทั้งสองค่าควบกับเวลาจบคำตอบ อัตรา cache hit และเวลาที่ใช้ดึงสถานะคืน หากดูเพียงคำขอที่เกิด hit จะมองไม่เห็นต้นทุนของคำขอที่พลาดและต้องทำ prefill ใหม่ ภาระ GPU หน่วยความจำ เครือข่าย และพื้นที่เก็บข้อมูลควรถูกนับพร้อมกัน เพื่อดูว่าลดงานคำนวณจริงหรือเพียงย้ายค่าใช้จ่ายไปอีกชั้น

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

การแชร์สถานะเพิ่มภาระดูแลข้อมูล

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

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

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