FlowPrefill: ฝ่าฟันคอขวดของเหตุผล LLM เพื่อเพิ่ม throughput 5.6x ด้วยการยึดระดับโอเปอเรเตอร์และมั่นใจว่า SLO ที่เข้มงวด

คำสำคัญ: ระบบบริการ LLM, การเติมล่วงหน้า, การอุดตันที่หัวแถว, _การจัดตารางที่รับรู้ SLO_, การแทรกแซงระดับโอเปอเรเตอร์, การจัดตารางแบบขับเคลื่อนด้วยเหตุการณ์

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

ในระบบบริการโมเดลภาษาขนาดใหญ่ (LLM) ปรากฏการณ์นี้เรียกว่า การอุดตันที่หัวแถว (Head-of-Line blocking, HoL) มันเกิดขึ้นใน ขั้นตอนการเติมล่วงหน้า (prefill phase) ของการอนุมานโมเดล ซึ่งคือขั้นตอนที่โมเดลประมวลผลคำสั่ง (prompt) ที่ผู้ใช้ป้อนเข้าไป

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

การคำนวณการเติมล่วงหน้าสำหรับพรอมต์ยาวมีปริมาณการคำนวณมาก จะใช้ทรัพยากร GPU เป็นเวลานาน ทำให้คำขอสั้นที่มาถึงหลังจากนั้นถูกบล็อก ส่งผลให้ละเมิด เวลาโทเค็นแรก (Time-to-First-Token, TTFT) ซึ่งเป็นเป้าหมายระดับบริการ (SLO)

โซลูชันที่มีอยู่บางส่วน เช่น การเติมล่วงหน้าแบบแบ่งส่วน (chunked prefill) ซึ่งแบ่งพรอมต์ยาวออกเป็นส่วนเล็กๆ เพื่อดำเนินการ อนุญาตให้แทรกคำขออื่นระหว่างส่วนต่างๆ ได้ แต่นี่นำมาซึ่งการแลกเปลี่ยนพื้นฐาน:

• ส่วนที่เล็กกว่า ตอบสนองเร็วขึ้น แต่ประสิทธิภาพการคำนวณต่ำลง (เนื่องจากค่าใช้จ่ายในการเริ่มเคอร์เนลและการเข้าถึงหน่วยความจำซ้ำซ้อนเพิ่มขึ้น)
• ส่วนที่ใหญ่กว่า 吞吐量 (throughput) สูงขึ้น แต่ความล่าช้าในการบล็อกก็ยาวนานขึ้นด้วย

นี่เหมือนกับเวลารถติด เราไม่สามารถแยกรถบรรทุกออกเป็นชิ้นเล็กๆ เพื่อให้ผ่านไปได้ แต่การไม่ให้มันเคลื่อนที่เลยก็ไม่ได้เช่นกัน

รูปที่ 2 | การปฏิบัติตามเป้าหมายระดับบริการ (SLO) ของความล่าช้าโทเค็นแรก (TTFT) ที่ระดับความละเอียดการเติมล่วงหน้าที่ต่างกัน (a) การเติมล่วงหน้าแบบแบ่งส่วน; (b) การเติมล่วงหน้าแบบแบ่งชั้น; (c) วิธีการของบทความนี้ จากการเปรียบเทียบจะเห็นได้ว่าทั้งการเติมล่วงหน้าแบบแบ่งส่วนและแบบแบ่งชั้นต่างมีปัญหาการละเมิด SLO อันแรกเกิดจากการจำกัดของขอบเขตส่วนทำให้คำขอที่มีความสำคัญสูงถูกบล็อก อันหลังถูกจำกัดด้วยระยะเวลาการดำเนินการของชั้น ในขณะที่วิธีการของบทความนี้ซึ่งใช้การแทรกแซงระดับโอเปอเรอร์เพื่อตอบสนองที่แม่นยำ ทำให้คำขอ B ที่มีความสำคัญสูงสามารถปฏิบัติตาม SLO ได้สำเร็จ แก้ไขความขัดแย้งระหว่างความละเอียดและประสิทธิภาพ

แล้วมีวิธีไหนบ้างที่สามารถรักษา吞吐量 (throughput) สูงไว้ได้ ในขณะเดียวกันก็ทำให้การแทรกแซงมีความละเอียดสูง ทำให้คำขอที่มีความสำคัญสูงสามารถ “แทรกคิว” ได้โดยไม่ส่งผลกระทบต่อประสิทธิภาพโดยรวม?

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

รูปที่ 5 | โครงสร้างโดยรวมของ FlowPrefill โครงสร้างหลักประกอบด้วยพร็อกซี อินสแตนซ์การเติมล่วงหน้า และอินสแตนซ์การถอดรหัส อินสแตนซ์การเติมล่วงหน้าภายในมีโมดูลหลักสามส่วน ได้แก่ คิวคำขอ พูลการดำเนินการ และตัวจัดตาราง ผ่านการทำงานร่วมกันของการจัดตารางแบบขับเคลื่อนด้วยเหตุการณ์และการแทรกแซงระดับโอเปอเรอร์ ทำให้คำขอที่มีความสำคัญสูงได้รับการตอบสนองทันที ในขณะเดียวกันก็ใช้ประโยชน์จากกลยุทธ์ S-EDF และการประมวลผลกลุ่มที่รับรู้ SLO เพื่อเพิ่มประสิทธิภาพ吞吐量 (throughput) ที่มีประสิทธิผลของระบบให้สูงสุด

หนึ่ง: พื้นหลัง: สองขั้นตอนของการอนุมาน LLM และการแยก PD

1.1 กระบวนการอนุมานของ Transformer

LLM สมัยใหม่ส่วนใหญ่ใช้โครงสร้าง Transformer กระบวนการอนุมานแบ่งออกเป็นสองขั้นตอน:

1. ขั้นตอนการเติมล่วงหน้า: ป้อนลำดับพรอมต์ทั้งหมด (เช่น คำถามของผู้ใช้) คำนวณความสนใจ (attention) ของโทเค็นทั้งหมดแบบขนาน สร้างโทเค็นเอาต์พุตแรก และเริ่มต้นแคชคีย์-ค่า (KV cache) ขั้นตอนนี้ดำเนินการคูณเมทริกซ์-เมทริกซ์ (GEMM) เป็นหลัก ซึ่งใช้การคำนวณหนาแน่น จัดเป็นประเภท ใช้การคำนวณหนาแน่น
2. ขั้นตอนการถอดรหัส: สร้างโทเค็นต่อๆ มาทีละตัวแบบถดถอย (autoregressive) ในแต่ละขั้นจะป้อนโทเค็นเดียวเท่านั้น ดำเนินการคูณเมทริกซ์-เวกเตอร์ (GEMV) ต้องโหลดน้ำหนักโมเดลจากหน่วยความจำแบนด์วิดท์สูง (HBM) ซ้ำๆ จัดเป็นประเภท ใช้หน่วยความจำหนาแน่น

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

1.2 การแยกการเติมล่วงหน้า-การถอดรหัส (PD Disaggregation)

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

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

สอง: แรงจูงใจ: ข้อจำกัดของวิธีการที่มีอยู่

2.1 การแลกเปลี่ยนระหว่างความละเอียดของการแทรกแซงและประสิทธิภาพ

เพื่อบรรเทาการอุดตันที่หัวแถว ระบบที่มีอยู่มักใช้กลยุทธ์การแทรกแซงที่มีความละเอียดคงที่:

• การเติมล่วงหน้าแบบแบ่งส่วน: แบ่งอินพุตยาวออกเป็นส่วนๆ ที่มีขนาดคงที่ (เช่น 2K โทเค็น) หลังจากดำเนินการแต่ละส่วนเสร็จแล้ว จะตรวจสอบว่าสามารถจัดตารางคำขอใหม่ได้หรือไม่
• การเติมล่วงหน้าแบบแบ่งชั้น: ใช้ขอบเขตตามธรรมชาติของชั้น Transformer เป็นจุดแทรกแซง ตรวจสอบหลังจากดำเนินการแต่ละชั้นเสร็จ

อย่างไรก็ตาม ผู้เขียนได้เปิดเผยความขัดแย้งภายในของวิธีการเหล่านี้ผ่านการทดลอง รูปที่ 3 แสดงผลกระทบของขนาดส่วนที่แตกต่างกันต่อ吞吐量 (throughput) และความล่าช้า เมื่อประมวลผลอินพุต 32K โทเค็นบนโมเดล Llama3-8B

รูปที่ 3 | 吞吐量 (throughput) และความล่าช้าของการเติมล่วงหน้าแบบแบ่งส่วนสำหรับอินพุต 32K โทเค็นที่ขนาดส่วนต่างๆ เมื่อให้บริการโมเดล Llama3-8B สีสลับภายในแต่ละแถบแสดงถึงส่วนเดียว ผลการทดลองแสดงให้เห็นอย่างชัดเจนถึงความยากลำบากในการแลกเปลี่ยนขนาดส่วน: ส่วนเล็กๆ แม้จะเพิ่มการตอบสนอง แต่เนื่องจากค่าใช้จ่ายในการเริ่มเคอร์เนลและการเข้าถึง KV cache ซ้ำซ้อน ทำให้吞吐量 (throughput) ลดลงอย่างรวดเร็ว ส่วนใหญ่แม้จะกู้คืน吞吐量 (throughput) ได้ แต่กลับทำให้การบล็อกรุนแรงขึ้น นี่เป็นพื้นฐานในทางปฏิบัติสำหรับการเสนอการแทรกแซงระดับโอเปอเรเตอร์ในบทความนี้

จากการสังเกตจะเห็นว่า ส่วนที่เล็กกว่า ความล่าช้าก็ต่ำลง แต่吞吐量 (throughput) ลดลงอย่างรวดเร็ว นี่เป็นเพราะส่วนเล็กๆ ทำให้จำนวนครั้งในการเริ่มเคอร์เนลเพิ่มขึ้น KV cache ถูกโหลดซ้ำๆ การใช้ประโยชน์ของอุปกรณ์ลดลง และส่วนที่ใหญ่กว่า 吞吐量 (throughput) สูงขึ้น แต่เวลาในการดำเนินการของแต่ละส่วนยาวเกินไป การบล็อกไม่สามารถหลีกเลี่ยงได้ นี่คือสิ่งที่เรียกว่า “การแลกเปลี่ยน吞吐量 (throughput)-ความล่าช้า”

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

รูปที่ 12 | เวลาบล็อกเฉลี่ยของการแทรกแซงที่ขอบเขตการแทรกแซงระดับโอเปอเรเตอร์และระดับชั้น ความละเอียดการแทรกแซงที่แตกต่างกันทำได้โดยการตั้งค่าการตรวจสอบการแทรกแซงที่ขอบเขตการดำเนินการที่ต่างกัน ข้อมูลแสดงให้เห็นว่าการแทรกแซงระดับโอเปอเรเตอร์ลดเวลาบล็อกเฉลี่ยลง 3.5-4.2 เท่า ควบคุมให้ต่ำกว่า 4.5 มิลลิวินาทีในทุกโมเดล ประสิทธิภาพที่เกือบจะไม่มีการบล็อกนี้ ทำให้คำขอที่มีความสำคัญสูงสามารถได้รับทรัพยากรอย่างรวดเร็ว บรรเทาปัญหาการอุดตันที่หัวแถวในขั้นตอนการเติมล่วงหน้าได้อย่างมาก

ข้อสรุปที่ 1: หน่วยการดำเนินการที่มีความละเอียดคงที่ไม่สามารถได้ทั้งประสิทธิภาพและการตอบสนอง จำเป็นต้องมีกลไกการแทรกแซงที่ปรับตัวได้และไม่ขึ้นอยู่กับการแบ่งส่วนคงที่

2.2 ความไม่สมมาตรของคำขอในการประมวลผลกลุ่ม

การประมวลผลกลุ่ม (batching) ก็ส่งผลต่อประสิทธิภาพของคำขอที่มีความยาวต่างกันด้วย รูปที่ 4 แสดงการเปลี่ยนแปลงของ吞吐量 (throughput) และ TTFT ตามขนาดกลุ่มในขั้นตอนการเติมล่วงหน้า ที่ความยาวอินพุตต่างกัน

รูปที่ 4 | 吞吐量 (throughput) และความล่าช้าโทเค็นแรกที่ปรับให้เป็นมาตรฐาน (TTFT) ในขั้นตอนการเติมล่วงหน้าที่ความยาวอินพุตต่างกัน เมื่อให้บริการโมเดล Llama3-8B (a) 吞吐量 (throughput); (b) TTFT ที่ปรับให้เป็นมาตรฐาน

รูปด้านบนเปิดเผยผลกระทบที่ต่างกันของการประมวลผลกลุ่มต่อคำขอที่มีความยาวต่างกัน:
* สำหรับคำขอสั้น (32-256 โทเค็น) คำขอเดียวไม่สามารถใช้ประโยชน์จากการทำงานแบบขนานของ GPU ได้อย่างเต็มที่ การประมวลผลกลุ่มสามารถเพิ่ม吞吐量 (throughput) ได้อย่างมีนัยสำคัญ และความล่าช้าเพิ่มขึ้นอย่างราบรื่น
* สำหรับคำขอยาว (เช่น 2K ขึ้นไป) คำขอเดียวใกล้จะทำให้ GPU อิ่มตัวแล้ว 吞吐量 (throughput) ที่ได้จากการประมวลผลกลุ่มมีน้อยมาก แต่ความล่าช้าเพิ่มขึ้นเป็นเส้นตรง ทำให้เกิดการละเมิด SLO ได้ง่าย

ข้อสรุปที่ 2: คำขอสั้นต้องการการประมวลผลกลุ่มเพื่อเพิ่มประสิทธิภาพ ในขณะที่คำขอยาวควรหลีกเลี่ยงการประมวลผลกลุ่มมากเกินไป เพื่อไม่ให้เพิ่มความล่าช้าโดยไม่จำเป็น

สาม: การออกแบบหลักของ FlowPrefill

FlowPrefill เป็นระบบบริการ LLM ที่มีเป้าหมายในการเพิ่มประสิทธิภาพ吞吐量 (throughput) ที่มีประสิทธิผล (goodput) โดยใช้สองนวัตกรรมหลักเพื่อแก้ไขปัญหาข้างต้น: การแทรกแซงระดับโอเปอเรเตอร์ (Operator-Level Preemption) และ การจัดตารางแบบขับเคลื่อนด้วยเหตุการณ์ (Event-Driven Scheduling) รูปที่ 5 แสดงโครงสร้างโดยรวมของระบบ

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง