ลาก่อนการ์ดที่รุนแรง! FleetOpt ใช้ “การบีบอัดคือการกำหนดเส้นทาง” เพื่อแก้ปัญหาความลาดชันของต้นทุนคลัสเตอร์การอนุมาน LLM ประหยัดต้นทุน GPU ได้สูงสุด 82.4%

คำสำคัญ: การอนุมาน LLM, การวางแผนคลัสเตอร์, หน้าผาต้นทุน, การบีบอัดในฐานะการกำหนดเส้นทาง, คิว M/G/c

เมื่อเราพูดถึงการอนุมานโมเดลขนาดใหญ่ (LLM) เรากำลังสนใจอะไรกันแน่? คือจำนวนโทเคนที่ประมวลผลต่อวินาที (TPS)? คือความล่าช้าของโทเคนแรก (TTFT)? หรือคือบิลค่าเช่าเซิร์ฟเวอร์คลาวด์ GPU ที่น่าตกใจ?

หากคุณเคยจัดการหรือวางแผนคลัสเตอร์สำหรับการอนุมาน LLM คุณคงเคยเผชิญกับ “ช้างในห้อง” นี้: คลัสเตอร์ของเราถูกออกแบบมาสำหรับกรณีที่เลวร้ายที่สุด แต่คำขอส่วนใหญ่ไม่เคยเข้าใกล้ขีดจำกัดนั้นเลย

เพื่อให้บริการคำขอสุดขั้วที่หนึ่งในล้าน ซึ่งมีความยาวคอนเท็กซ์สูงถึง 128K เราจำเป็นต้องกำหนดค่า KV-Cache ขนาดมหึมาให้กับคลัสเตอร์ทั้งหมด ในขณะที่คำขอที่เหลืออีก 99.9% ต้อง “อาศัยอย่างคับแคบ” บนสล็อตหน่วยความจำที่ว่างเปล่าจำนวนมาก

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

ดังนั้น คำถามคือ: เราสามารถละทิ้งรูปแบบการเพิ่มการ์ด GPU แบบเหวี่ยงแห “หนึ่งขนาดเหมาะกับทุกคน” นี้ได้หรือไม่ โดยเริ่มจากหลักการพื้นฐาน (First Principle) ก่อน เพื่อหาคลัสเตอร์ต้นทุนต่ำสุดภายใต้น้ำหนักงานที่กำหนด แล้วค่อยสร้างมันขึ้นมา?

นี่คือแนวคิดหลักของ FleetOpt มันไม่พอใจกับการกำหนดเส้นทางแบบพูลอย่างง่ายหรือการบีบอัดเพื่อแก้ไขปัญหาในภายหลัง แต่รวมเทคโนโลยีเหล่านี้เข้าด้วยกันในกรอบทางคณิตศาสตร์ที่เหมาะสมที่สุด มันสรุปปัญหาการวางแผนคลัสเตอร์เป็นแบบจำลองคิว M/G/c และได้ข้อสรุปสำคัญว่า: คลัสเตอร์ที่เหมาะสมที่สุดคือสถาปัตยกรรมแบบสองพูล (พูลคอนเท็กซ์สั้น + พูลคอนเท็กซ์ยาว) โดยขอบเขตที่เหมาะสมที่สุดถูกกำหนดโดย “เงื่อนไขต้นทุนส่วนเพิ่มของ GPU ที่เท่ากัน”

แต่ขอบเขตที่เหมาะสมที่สุดในทางทฤษฎีต้องเผชิญกับ “หน้าผาต้นทุน” ในความเป็นจริง: เมื่อความยาวคอนเท็กซ์ของคำขอเกินขอบเขตของพูลสั้นไปเพียงหนึ่งโทเคน ความสามารถในการประมวลผลของ GPU ที่ต้องการอาจสูงกว่าคำขอในพูลสั้นถึง 8 ถึง 42 เท่า! เปรียบเหมือนการเดินริมหน้าผา ห่างกันเพียงก้าวเดียว แต่ต้นทุนต่างกันราวฟ้ากับเหว

จะก้าวข้ามเหวนี้ได้อย่างไร? คำตอบของ FleetOpt คือ “การบีบอัดในฐานะการกำหนดเส้นทาง” ที่เลเยอร์เกตเวย์ มันจะทำการบีบอัดแบบสกัด (Extractive Compression) แบบเบาๆ ให้กับคำขอที่อยู่ใน “เขตแดนขอบ” เพื่อให้สามารถ “ดึงกลับ” ไปประมวลผลในพูลสั้นได้ นี่ไม่ใช่การเพิ่มฟังก์ชันอย่างง่าย แต่เป็นการเปลี่ยนขอบเขตฮาร์ดแวร์ที่แข็งกระด้าง ให้เป็นพารามิเตอร์ซอฟต์แวร์ที่สามารถอ่านและควบคุมได้

ผลลัพธ์สุดท้ายเป็นอย่างไร? ผู้เขียนได้ประเมินบนน้ำหนักงานการผลิตจริงสามแบบ ผลลัพธ์มีดังนี้:

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

บทความนี้ไม่เพียงเป็นคู่มือปฏิบัติเกี่ยวกับวิธีการดำเนินการคลัสเตอร์การอนุมาน LLM อย่างมีประสิทธิภาพทางวิทยาศาสตร์ แต่ยังสอดคล้องกับโปรเจกต์โอเพ่นซอร์ส vLLM Semantic Router ด้วย

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

สารบัญบทความ

• หนึ่ง รากเหง้าของปัญหา: หน้าผาต้นทุนและ “กฎของแมทธิว” ของน้ำหนักงาน
  • 1.1 “ภาษีหน่วยความจำ” ของ KV-Cache
  • 1.2 “หน้าผาต้นทุน”: ราคาของหนึ่งโทเคน
  • 1.3 “กฎของแมทธิว” ของน้ำหนักงานและ “เขตแดนขอบ”
• สอง นวัตกรรมหลักที่หนึ่ง: แบบจำลองทางคณิตศาสตร์จากหลักการพื้นฐาน
  • 2.1 การสร้างแบบจำลองแต่ละพูลเป็นคิว M/G/c
  • 2.2 การใช้สูตร Erlang-C และการประมาณ Kimura ในการวางแผนที่แม่นยำ
  • 2.3 การหาขอบเขตที่เหมาะสมที่สุด: เงื่อนไขต้นทุนส่วนเพิ่มของ GPU ที่เท่ากัน
• สาม นวัตกรรมหลักที่สอง: การบีบอัดในฐานะการกำหนดเส้นทาง – สะพานข้ามหน้าผา
  • 3.1 พูลเสมือน: การเปลี่ยนธรรมชาติของขอบเขตแข็ง
  • 3.2 การบีบอัดแบบสกัดแบบเบา: เร็ว แม่นยำ หนักแน่น
  • 3.3 คุณค่าของการออกแบบร่วมกัน: ทำไม 1+1 > 2
• สี่ ตัววางแผนออฟไลน์ของ FleetOpt: คำตอบที่เหมาะสมที่สุดภายใน 1 มิลลิวินาที
• ห้า การประเมิน: ข้อมูลคือข้อพิสูจน์ที่ดีที่สุด
  • 5.1 ผลการประหยัดโดยรวม
  • 5.2 การตรวจสอบโมเดล: การเปรียบเทียบกับเครื่องจำลองเหตุการณ์ไม่ต่อเนื่อง (DES)
• หก การเปรียบเทียบและตำแหน่งของงานที่เกี่ยวข้อง
  • 6.1 การกำหนดเส้นทางแบบพูลและการจัดตารางที่ตระหนักถึงความยาว
  • 6.2 การบีบอัดเป็นคันโยกกำหนดเส้นทาง
  • 6.3 การวางแผนความจุ LLM
  • 6.4 การจำลองและสร้างแบบจำลองการอนุมาน
• สรุป

หนึ่ง รากเหง้าของปัญหา: หน้าผาต้นทุนและ “กฎของแมทธิว” ของน้ำหนักงาน

เพื่อให้เข้าใจว่า FleetOpt มีประสิทธิภาพอย่างไร ก่อนอื่นต้องเข้าใจว่าต้นทุนสูญเสียไปที่ไหน คำตอบซ่อนอยู่ในสองคำ: KV-Cache และการกระจายตัวของน้ำหนักงาน

1.1 “ภาษีหน่วยความจำ” ของ KV-Cache

ในกระบวนการอนุมาน LLM เพื่อเร่งการสร้างโมเดลจะแคชเวกเตอร์ Key และ Value ของโทเคนประวัติทั้งหมด นี่คือ KV-Cache

สำหรับโมเดลเช่น Llama-3-70B ที่ความแม่นยำ fp16 ขนาด KV-Cache ต่อโทเคนประมาณ 320KB

• หากจองคอนเท็กซ์ 64K โทเคนสำหรับคำขอเดียว KV-Cache ที่ใช้ประมาณ: 64,000 * 320KB ≈ 20.5GB
• แต่หากจองเพียง 8K โทเคน ต้องการเพียง 8,000 * 320KB ≈ 2.5GB

นี่หมายความว่า ในหน่วยความจำ GPU เดียวกัน GPU ที่กำหนดค่าให้รองรับคอนเท็กซ์ 8K สามารถรองรับคำขอพร้อมกันได้มากกว่า GPU ที่กำหนดค่า 64K ถึง 8 เท่า ความแตกต่างมหาศาลของความสามารถในการประมวลผลนี้คือพื้นฐานทางกายภาพของ “หน้าผาต้นทุน”

1.2 “หน้าผาต้นทุน”: ราคาของหนึ่งโทเคน

สมมติว่าเราตั้งขอบเขตพูลสั้น = 8,192 โทเคน ดังนั้น:

1.2 ผลกระทบเชิงปริมาณของหน้าผาต้นทุน

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

• คำขอที่มีความยาวพอดี 8,192 โทเคน จะถูกกำหนดเส้นทางไปยังพูลสั้น ครอบครองสล็อต “เล็ก” ขนาด 2.5GB หนึ่งสล็อต
• คำขอที่มีความยาว 8,193 โทเคน มากกว่าเพียงหนึ่งโทเคน ต้องเข้าสู่พูลยาว ครอบครองสล็อต “ใหญ่” ขนาด 20.5GB หนึ่งสล็อต

นี่หมายความว่า “ราคาของโทเคนเดียว” นี้ ทำให้ความสามารถในการประมวลผลพร้อมกัน (ปริมาณงาน) ของ GPU เดียวลดลงจาก 128 คำขอ (พูลสั้น) อย่างรวดเร็วเหลือเพียง 16 คำขอ (พูลยาว) นี่คือปรากฏการณ์หน้าผาต้นทุน ซึ่งความแตกต่างของประสิทธิภาพทรัพยากรอาจสูงถึง 8 เท่า หากตั้งขอบเขตพูลสั้นต่ำกว่า (เช่น 1,536 โทเคน) ผลกระทบหน้าผานี้อาจสูงถึง 42 เท่าอย่างน่าตกใจ

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

ตาราง 1: การวิเคราะห์เชิงปริมาณของหน้าผาต้นทุน ที่ขอบเขต 8K พูลสั้นแต่ละ GPU รองรับสล็อตพร้อมกันได้ 128 สล็อต พูลยาวรองรับได้เพียง 16 สล็อต คำขอ 8,193 โทเคน แม้จะใช้สล็อตใหญ่ของพูลยาว แต่การใช้ KV-Cache จริงเพียง 12.5% กลับต้องจ่ายต้นทุนปริมาณงานสูงถึง 8 เท่า

1.3 “กฎของแมทธิว” ของน้ำหนักงานและ “เขตแดนขอบ”

การวางแผนคลัสเตอร์ที่มีประสิทธิภาพต้องอาศัยความเข้าใจลึกซึ้งเกี่ยวกับน้ำหนักงานจริง การศึกษาวิเคราะห์รูปแบบน้ำหนักงานทั่วไปสามแบบ เผยให้เห็นผลกระทบสำคัญของคำขอ “เขตแดนขอบ”:

1. ประเภท I: แบบรวมตัว-สั้น: คำขอส่วนใหญ่มีความยาวรวมตัวอยู่ใต้ขอบเขตพูลสั้น (เช่น น้ำหนักงานการสนทนาหลายรอบของ LMSYS) การวิเคราะห์พบว่า คำขอที่มีความยาวติดขอบเขตด้านบน (เขตแดนขอบ) แม้จะมีสัดส่วนไม่สูงนักในคำขอทั้งหมด (ประมาณ 4.6%-7.8%) แต่กลับคิดเป็นส่วนใหญ่ของคำขอที่เกินขอบเขตทั้งหมด (51%-76%) นี่หมายความว่า หากสามารถประมวลผลคำขอเขตแดนขอบนี้ได้อย่างมีประสิทธิภาพ ก็จะลดการพึ่งพาพูลยาวที่มีราคาแพงได้อย่างมีนัยสำคัญ
2. ประเภท II: แบบกระจาย: ความยาวคำขอกระจายไปหลายลำดับความสำคัญ (เช่น น้ำหนักงานที่ผสมผสาน RAG กับการเรียกใช้เครื่องมือ) คำขอเขตแดนขอบมีสัดส่วนค่อนข้างสูงในคำขอทั้งหมด (ประมาณ 7%-12%) และกระจายตัวค่อนข้างกว้าง
3. ประเภท III: แบบรวมตัว-ยาว: คำขอส่วนใหญ่มีความยาวเหนือขอบเขตพูลสั้น (เช่น งานสร้างโค้ดบางอย่าง) สำหรับน้ำหนักงานประเภทนี้ ผลประโยชน์จากการบีบอัดมีจำกัด จุดเน้นการปรับปรุงอยู่ที่การเพิ่มอัตราการใช้ทรัพยากรของพูลยาวเอง

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

สอง นวัตกรรมหลัก: แบบจำลองทางคณิตศาสตร์จากหลักการพื้นฐาน

ผลงานหลักชิ้นแรกของ FleetOpt คือการสร้างกรอบทางคณิตศาสตร์ที่เข้มงวด โดยเริ่มจากเป้าหมายประสิทธิภาพระบบ (SLO) เพื่อหาการกำหนดค่าคลัสเตอร์ที่เหมาะสมที่สุดแบบย้อนกลับ แทนที่จะพึ่งพาการคาดเดาจากประสบการณ์

2.1 การสร้างแบบจำลองพูลประมวลผลเป็นคิว M/G/c

ผู้เขียนสร้างแบบจำลองแต่ละพูล KV-Cache (พูลสั้นและพูลยาว) เป็นคิว M/G/c:
* M (กระบวนการมาถึง): สมมติว่าคำขอมาถึงตามกระบวนการปัวซง ซึ่งเป็นสมมติฐานที่สมเหตุสมผลทั่วไปในการสร้างแบบจำลองระบบ
* G (เวลาให้บริการ): เวลาให้บริการการอนุมานของคำขอมีการกระจายทั่วไป นี่คือประเด็นสำคัญ เพราะความยาวอินพุตและเอาต์พุตของคำขอ LLM แตกต่างกันมาก เวลาให้บริการไม่ใช่การกระจายแบบเอกซ์โพเนนเชียลอย่างง่าย
* c (จำนวนเซิร์ฟเวอร์): ในแบบจำลองนี้ แต่ละสล็อต KV-Cache ถือเป็น “เซิร์ฟเวอร์” หนึ่งตัว จำนวนสล็อตที่ GPU เดียวสามารถรองรับได้พร้อมกัน (c) ขึ้นอยู่กับความยาวคอนเท็กซ์ที่กำหนดค่า ตัวอย่างเช่น พูลยาวที่กำหนดค่าให้รองรับคอนเท็กซ์ 64K, c=16; พูลสั้นที่กำหนดค่าให้รองรับคอนเท็กซ์

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

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK