การกำหนดเส้นทางแคช KV: ลดงานเติมข้อมูลล่วงหน้าของ LLM ที่ซ้ำซ้อน

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

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

ShareAI ให้ API หนึ่งตัวสำหรับนักพัฒนาเพื่อใช้งานโมเดลกว่า 150+ โมเดล การมองเห็นในตลาด การกำหนดเส้นทาง และการสำรองข้อมูล การกำหนดเส้นทาง KV cache อยู่ในชั้นที่ต่ำกว่า ภายในโครงสร้างพื้นฐานการให้บริการโมเดล สิ่งที่ผู้อ่าน ShareAI ควรนำไปใช้คือการตัดสินใจเรื่องการกำหนดเส้นทางมีความสำคัญในทุกชั้นของ AI stack ตั้งแต่การเลือกโมเดลไปจนถึงสำเนา GPU ที่จัดการคำสั่งที่ซ้ำกัน.

ทำไมการกำหนดเส้นทาง KV Cache ถึงสำคัญ

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

การแคชคำขึ้นต้นช่วยให้เครื่องมือให้บริการสามารถใช้แคชนั้นซ้ำได้เมื่อคำขอในภายหลังมีคำขึ้นต้นเดียวกัน เอกสารการแคชคำขึ้นต้นอัตโนมัติของ vLLM อธิบายว่าเป็นการใช้ KV cache ซ้ำสำหรับคำขึ้นต้นที่แชร์กัน เพื่อให้คำขอใหม่สามารถข้ามการคำนวณสำหรับส่วนที่แชร์ได้. การแคชคำขึ้นต้นของ SGLang ใช้แนวคิดที่เกี่ยวข้องเพื่อแชร์ KV cache สำหรับลำดับโทเค็นที่เหมือนกัน.

สิ่งนี้มีความสำคัญเป็นพิเศษสำหรับงานที่มีคำขอจำนวนมากเริ่มต้นในลักษณะเดียวกัน: ตัวแทนสนับสนุนที่มีคำสั่งระบบขนาดใหญ่ แอปพลิเคชัน RAG ที่ใช้ชิ้นส่วนเอกสารซ้ำ ตัวแทนการเขียนโค้ดที่มีคำแนะนำใน repository หรือผลิตภัณฑ์แชทที่มีประวัติการสนทนาในแต่ละรอบ.

จุดที่ Round-Robin ล้มเหลว

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

ด้วยตัวโหลดบาลานซ์แบบ round-robin มาตรฐาน คำขอแรกอาจทำให้แคชร้อนบนสำเนา A ในขณะที่คำขอที่สองที่มีคำขึ้นต้นเดียวกันไปถึงสำเนา B สำเนา B ไม่มีสถานะที่แคชไว้ ดังนั้นจึงคำนวณงานเติมข้อมูลเดิมซ้ำ คำขอที่สามอาจไปที่สำเนา C และพลาดอีกครั้ง.

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

ระดับการกำหนดเส้นทางที่ใช้งานได้จริงสามระดับ

1. ความสัมพันธ์ของเซสชัน

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

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

2. การกำหนดเส้นทางด้วยแฮชคำนำหน้า

การกำหนดเส้นทางด้วยแฮชคำนำหน้าใช้คำถามเองเป็นกุญแจการกำหนดเส้นทาง ตัวกำหนดเส้นทางจะสร้างแฮชจากจุดเริ่มต้นที่เสถียรของคำถามและส่งคำนำหน้าที่ตรงกันไปยังสำเนาเดียวกัน.

วิธีนี้ทำงานได้ดีกว่าเมื่อคำถามระบบที่ซ้ำกัน, ตัวอย่าง few-shot, หรือบริบทที่เรียกคืนร่วมกันมีความสำคัญมากกว่าตัวตนของผู้ใช้ ส่วนที่ยากคือการเลือกขอบเขตของคำนำหน้า หากแฮชรวมถึงการประทับเวลา, รหัสคำขอ, หรือฟิลด์เฉพาะผู้ใช้ กุญแจการกำหนดเส้นทางจะแตกออกและการใช้แคชซ้ำจะล้มเหลว.

3. การกำหนดเส้นทางที่ตระหนักถึงเหตุการณ์แคช

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

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

เมื่อควรข้าม

การกำหนดเส้นทาง KV cache ไม่ได้คุ้มค่ากับความซับซ้อนโดยอัตโนมัติ มันไม่เหมาะสมเมื่อคำถามสั้น, ส่วนใหญ่ไม่ซ้ำกัน, หรือประมวลผลเป็นชุดที่มีโครงสร้างซ้ำกันน้อย.

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

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

สิ่งนี้เข้ากันได้กับ ShareAI อย่างไร

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

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

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

สำหรับการเลือกโมเดลและการประเมินเส้นทาง เริ่มต้นด้วย ตลาดโมเดล ShareAI. สำหรับพื้นฐานการดำเนินการ ใช้ เอกสารอ้างอิง API ของ ShareAI.

รายการตรวจสอบการกำหนดเส้นทางแคช KV

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

คำถามที่พบบ่อย

การกำหนดเส้นทางแคช KV คืออะไร?

การกำหนดเส้นทางแคช KV เป็นกลยุทธ์การกำหนดเส้นทางที่ส่งคำขอที่มีคำนำซ้ำไปยังสำเนาที่มีแนวโน้มว่าจะมีแคช KV ที่ตรงกันอยู่แล้ว เป้าหมายคือการลดการคำนวณเติมข้อมูลซ้ำที่ไม่จำเป็น.

การกำหนดเส้นทางแคช KV แตกต่างจากการแคชคำนำอย่างไร?

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

ทำไมการกำหนดเส้นทางแบบวนรอบถึงทำร้ายการแคชคำนำ?

การกำหนดเส้นทางแบบวนรอบกระจายคำขอไปยังสำเนาโดยไม่ทราบว่าสำเนาใดมีคำนำที่แคชไว้ คำนำที่ซ้ำกันอาจพลาดแคชเพียงเพราะมันไปอยู่บนสำเนาที่ต่างกัน.

งานประเภทใดที่ได้รับประโยชน์มากที่สุดจากการกำหนดเส้นทางแคช KV?

การสนทนาแบบหลายรอบ, RAG, ตัวแทนเขียนโค้ด, ตัวแทนสนับสนุน, การตั้งคำถามแบบ few-shot และแอปที่มีคำนำระบบร่วมกันยาวเป็นผู้สมัครที่แข็งแกร่งที่สุดเพราะพวกเขาใช้คำนำซ้ำในปริมาณมาก.

เมื่อใดที่ทีมควรข้ามการกำหนดเส้นทางแคช KV?

ข้ามเมื่อคำนำสั้น, ส่วนใหญ่ไม่ซ้ำกัน หรือเป็นแบบแบทช์ที่มีโครงสร้างซ้ำเล็กน้อย ในกรณีเหล่านั้น ความซับซ้อนของการกำหนดเส้นทางอาจเพิ่มมูลค่าเพียงเล็กน้อย.

vLLM และ SGLang รองรับการแคชคำนำหรือไม่?

ใช่ เอกสาร vLLM ระบุการแคชคำนำอัตโนมัติ และเอกสาร SGLang ระบุการแคชคำนำสำหรับแคช KV ที่ใช้ร่วมกันในลำดับโทเค็นทั่วไป เครื่องมือให้บริการยังคงต้องการความช่วยเหลือในการกำหนดเส้นทางเมื่อมีสำเนาหลายชุด.

การกำหนดเส้นทางแคช KV เหมือนกับการแคชเชิงความหมายหรือไม่?

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

ShareAI แทนที่ตัวบาลานซ์โหลดที่รับรู้แคช KV หรือไม่?

ไม่ใช่ ShareAI เป็นตลาด AI และชั้น API สำหรับการเข้าถึงโมเดล การกำหนดเส้นทาง การสำรองข้อมูล การใช้งาน และการเรียกเก็บเงิน การกำหนดเส้นทางที่รับรู้ KV-cache เป็นโครงสร้างพื้นฐานการให้บริการโมเดลระดับต่ำสำหรับทีมที่ดำเนินการจำลองการอนุมาน.

ผู้สร้างควรคิดเกี่ยวกับการกำหนดเส้นทาง KV cache อย่างไร?

ผู้สร้างควรพิจารณาพฤติกรรมของแคชเป็นตัวขับเคลื่อนต้นทุนภายในแอปที่เน้น AI หากแอปพลิเคชันของพวกเขามีการใช้งานที่ไม่สม่ำเสมอ ShareAI สามารถช่วยกำหนดเส้นทางและสร้างรายได้จากการใช้งาน AI ในขณะที่แอปยังคงถูกสร้างและเป็นเจ้าของนอก ShareAI.

ทีมควรวัดอะไรบ้างก่อนเปลี่ยนการกำหนดเส้นทาง?

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

การกำหนดเส้นทาง KV cache สามารถลดต้นทุน API AI ได้หรือไม่?

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