ปรับปรุงประสิทธิภาพของโมเดล Falcon ด้วย Amazon SageMaker | อเมซอนเว็บเซอร์วิส

เฟรมเวิร์กและการกำหนดค่าที่เหมาะสมที่สุดสำหรับการโฮสต์โมเดลภาษาขนาดใหญ่ (LLM) สำหรับแอปพลิเคชัน AI ที่สร้างข้อความคืออะไร แม้จะมีตัวเลือกมากมายในการให้บริการ LLM แต่ก็เป็นคำถามที่ตอบยากเนื่องจากขนาดของโมเดล สถาปัตยกรรมของโมเดลที่แตกต่างกัน ข้อกำหนดด้านประสิทธิภาพของแอปพลิเคชัน และอื่นๆ ที่ อเมซอน SageMaker คอนเทนเนอร์การอนุมานแบบจำลองขนาดใหญ่ (LMI) ทำให้ง่ายต่อการให้บริการ LLM โดยการรวบรวมโฮสต์ของเฟรมเวิร์กและเทคนิคต่างๆ ที่เพิ่มประสิทธิภาพการปรับใช้ LLM คอนเทนเนอร์ LMI มีสแต็กการให้บริการที่ทรงพลังที่เรียกว่า ดีเจแอลเสิร์ฟ นั่นไม่เชื่อเรื่อง LLM พื้นฐาน โดยมีพารามิเตอร์การกำหนดค่าระดับระบบที่สามารถปรับแต่งเพื่อแยกประสิทธิภาพที่ดีที่สุดของโครงสร้างพื้นฐานโฮสติ้งสำหรับ LLM ที่กำหนด นอกจากนี้ยังรองรับการปรับให้เหมาะสมล่าสุด เช่น การแบทช์แบบต่อเนื่อง หรือที่เรียกว่าการแบทช์แบบวนซ้ำหรือแบทช์แบบกลิ้ง ซึ่งให้การปรับปรุงปริมาณงานอย่างมีนัยสำคัญ

ในช่วงก่อนหน้า เสาเราได้แสดงวิธีที่คุณสามารถใช้คอนเทนเนอร์ LMI เพื่อปรับใช้โมเดลตระกูล Falcon บน SageMaker ในโพสต์นี้ เราจะสาธิตวิธีปรับปรุงปริมาณงานและเวลาแฝงของการให้บริการ Falcon-40B ด้วยเทคนิคต่างๆ เช่น การจัดชุดอย่างต่อเนื่อง นอกจากนี้เรายังให้ความเข้าใจที่เข้าใจง่ายเกี่ยวกับพารามิเตอร์การกำหนดค่าที่ได้รับจากคอนเทนเนอร์ SageMaker LMI ซึ่งสามารถช่วยคุณค้นหาการกำหนดค่าที่ดีที่สุดสำหรับแอปพลิเคชันในโลกแห่งความเป็นจริงของคุณ

พื้นฐานของการอนุมานเชิงข้อความสำหรับ LLM

ก่อนอื่น เรามาดูรายละเอียดพื้นฐานบางประการเกี่ยวกับวิธีการอนุมานสำหรับ LLM สำหรับการสร้างข้อความกันก่อน

การส่งต่อ การเปิดใช้งาน และแคช KV

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

การสร้างข้อความด้วยโมเดลภาษาเช่น Falcon หรือ GPT นั้น autoregressive. ซึ่งหมายความว่าโมเดลจะสร้างโทเค็นทีละรายการในขณะที่ปรับสภาพโทเค็นที่สร้างไว้ก่อนหน้านี้ กล่าวอีกนัยหนึ่ง ในการวนซ้ำแต่ละครั้ง โมเดลจะใช้ข้อความที่สร้างขึ้นก่อนหน้านี้เป็นอินพุต และคาดการณ์โทเค็นถัดไปตามบริบทนั้น ดังที่กล่าวไว้ใน vLLM: การให้บริการ LLM ที่ง่าย รวดเร็ว และราคาถูกพร้อม PagedAttentionในกระบวนการถอดรหัสแบบถอยอัตโนมัตินี้ โทเค็นอินพุตทั้งหมดไปยัง LLM จะสร้างคีย์ความสนใจและเทนเซอร์ค่า และเทนเซอร์เหล่านี้จะถูกเก็บไว้ในหน่วยความจำ GPU เพื่อสร้างโทเค็นถัดไป คีย์แคชและเทนเซอร์ค่าเหล่านี้มักเรียกกันว่า KV cache.

กรอกล่วงหน้าและถอดรหัสเฟส

ในกระบวนการถอดรหัสอัตโนมัติ เช่นเดียวกับกระบวนการที่ใช้ในการสร้างข้อความด้วยโมเดลภาษา เช่น Falcon โดยทั่วไปจะมีสองขั้นตอนหลัก: prefill เฟสและ decode เฟส ขั้นตอนเหล่านี้มีความสำคัญอย่างยิ่งต่อการสร้างข้อความที่สอดคล้องกันและเกี่ยวข้องกับบริบท

ขั้นตอนการเติมล่วงหน้าประกอบด้วยสิ่งต่อไปนี้:

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

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

ขั้นตอนการถอดรหัสประกอบด้วยสิ่งต่อไปนี้:

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

การรวมกันของขั้นตอนการกรอกล่วงหน้าและถอดรหัสทำให้แบบจำลองการถดถอยอัตโนมัติสามารถสร้างข้อความที่สร้างขึ้นบนบริบทเริ่มต้นและสร้างลำดับข้อความที่สอดคล้องกัน เกี่ยวข้องกับบริบท และสอดคล้องตามบริบท

เอ่ยถึง ระบบการให้บริการแบบกระจายสำหรับโมเดลเจนเนอเรทีฟที่ใช้หม้อแปลงไฟฟ้า สำหรับคำอธิบายโดยละเอียดของกระบวนการ

การเพิ่มประสิทธิภาพปริมาณงานโดยใช้ชุดงานแบบไดนามิก

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

• max_batch_delay = 100 – ความล่าช้าสูงสุดสำหรับการรวมแบทช์ในหน่วยมิลลิวินาที ค่าเริ่มต้นคือ 100 มิลลิวินาที
• ชุด_ขนาด = 32 – ขนาดแบตช์แบบไดนามิก ค่าเริ่มต้นคือ 1

โดยพื้นฐานแล้วสิ่งนี้แสดงให้เห็นว่า DJLServing จะจัดคิวคำขอเป็นเวลา 100 มิลลิวินาทีในแต่ละครั้ง หรือหากจำนวนคำขอที่อยู่ในคิวนั้นขึ้นอยู่กับbatch_size ที่ระบุ แบตช์จะถูกกำหนดเวลาให้รันไปที่แบ็กเอนด์เพื่อการอนุมาน สิ่งนี้เรียกว่า dynamic batching. เป็นแบบไดนามิกเนื่องจากขนาดแบตช์อาจเปลี่ยนแปลงในแต่ละแบตช์ ขึ้นอยู่กับจำนวนคำขอที่ถูกเพิ่มในช่วงเวลานั้น อย่างไรก็ตาม เนื่องจากคำขออาจมีลักษณะเฉพาะที่แตกต่างกัน (เช่น บางคำขออาจมีรูปร่างเป็นโทเค็นอินพุต 20 โทเค็นและโทเค็นเอาต์พุต 500 โทเค็น ในขณะที่คำขออื่นๆ อาจถูกย้อนกลับโดยมีโทเค็นอินพุต 500 โทเค็น แต่มีเพียง 20 โทเค็นสำหรับเอาต์พุต) บางคำขอจึงอาจ ประมวลผลได้รวดเร็วกว่าตัวอื่นในชุดเดียวกัน ซึ่งอาจส่งผลให้ GPU มีการใช้งานน้อยเกินไปในขณะที่รอคำขอในเที่ยวบินทั้งหมดในแบตช์เพื่อให้ขั้นตอนการถอดรหัสเสร็จสมบูรณ์ แม้ว่าจะมีคำขอเพิ่มเติมที่รอการประมวลผลในคิวก็ตาม แผนภาพต่อไปนี้แสดงให้เห็นถึงกระบวนการนี้

การเพิ่มประสิทธิภาพปริมาณงานโดยใช้การแบทช์แบบต่อเนื่อง

กับ continuous batching, ที่รู้จักกันว่า iterative or rolling การแบทช์ เราจะใช้ประโยชน์จากความแตกต่างระหว่างขั้นตอนการกรอกล่วงหน้าและขั้นตอนการถอดรหัส เพื่อเปิดใช้งานการแบทช์ต่อเนื่อง DJServing จัดเตรียมการกำหนดค่าเพิ่มเติมต่อไปนี้ตามคุณสมบัติการเสิร์ฟ:

• เครื่องยนต์=MPI – เราขอแนะนำให้คุณใช้กลไก MPI สำหรับการจัดชุดอย่างต่อเนื่อง
• option.rolling_batch=auto หรือ lmi-dist – เราขอแนะนำให้ใช้ auto เนื่องจากระบบจะเลือกอัลกอริธึมชุดการทำงานที่เหมาะสมที่สุดโดยอัตโนมัติ พร้อมกับการปรับให้เหมาะสมอื่นๆ ในอนาคต
• option.max_rolling_batch_size=32 – นี่เป็นการจำกัดจำนวนคำขอที่เกิดขึ้นพร้อมกัน ค่าเริ่มต้นคือ 32

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

ขนาดของแคชนี้สามารถกำหนดค่าได้ด้วยตัวเลือกต่อไปนี้:

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

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

รวบรวมทั้งหมดเข้าด้วยกัน: วิธีคิดเกี่ยวกับการใช้หน่วยความจำของ GPU

ขอแนะนำให้โหลดการทดสอบโมเดลของคุณเพื่อดูว่าการกำหนดค่าใดคุ้มค่าที่สุดสำหรับกรณีการใช้งานทางธุรกิจของคุณ เพื่อสร้างความเข้าใจ เรามาดูพื้นที่หน่วยความจำของ GPU กันในขณะที่โมเดลถูกโหลดและคำขอที่ต่อเนื่องกันได้รับการประมวลผลเป็นชุดต่อเนื่อง สำหรับโพสต์นี้ สมมติว่าเรากำลังโหลดโมเดล Falcon-40B ลงในอินสแตนซ์ประเภท G5 ประเภทใดประเภทหนึ่งที่ติดตั้งด้วย NVIDIA A10G GPU โดยแต่ละรายการมีหน่วยความจำ 24 GB โปรดทราบว่าความเข้าใจที่คล้ายกันนี้ใช้ได้กับประเภทอินสแตนซ์ p3, p4 และ p5 ที่มาพร้อมกับซีรีส์ V100, A100 และ H100 GPU

ต่อไปนี้เป็นภาพรวมของการได้รับค่าโดยประมาณของหน่วยความจำทั้งหมดที่จำเป็นต่อการให้บริการ Falcon-40B:

• ขนาดโมเดล = จำนวนพารามิเตอร์รุ่น (40 พันล้านสำหรับ Falcon-40B) x 4 ไบต์ต่อพารามิเตอร์ (สำหรับ FP32) = 160 GB
• หน่วยความจำทั้งหมดโดยประมาณที่จำเป็นสำหรับการโหลด Falcon-40B เพื่อการอนุมาน = ขนาดโมเดล (=160 GB) + KV Cache (Attention Cache) (=*20 GB) + โอเวอร์เฮดหน่วยความจำเพิ่มเติมโดย ML Frameworks (ประมาณ 2 GB)

สำหรับ Falcon-40B ถ้าเราบีบอัดโมเดลโดยการวัดปริมาณโมเดลเป็นประเภทข้อมูล bfloat16 (2 ไบต์) ขนาดของโมเดลจะกลายเป็นประมาณ 80 GB อย่างที่คุณเห็น นี่ยังคงมีขนาดใหญ่กว่าหน่วยความจำที่รองรับโดยอุปกรณ์เร่งความเร็วหนึ่งตัว ดังนั้นเราจึงจำเป็นต้องใช้เทคนิคการแบ่งพาร์ติชันแบบจำลอง (การแบ่งส่วน) ด้วยคุณลักษณะพิเศษ ความขนานของเทนเซอร์ (TP) เข้าใกล้และแบ่งโมเดลผ่านอุปกรณ์เร่งความเร็วหลายตัว สมมติว่าเราเลือก g5.24xlarge ซึ่งมีอุปกรณ์ A4G GPU 10 ตัว หากเรากำหนดค่า DJLServing (serving.properties) ด้วยสิ่งต่อไปนี้ เราสามารถคาดหวังได้ว่าน้ำหนักโมเดล 80 GB จะถูกแบ่งเท่าๆ กันใน GPU ทั้ง 4 ตัว:

กับ tensor_parallel_degree หากตั้งค่าเป็น 4 แสดงว่าหน่วยความจำ GPU ขนาด 20 GB ประมาณ 24 GB (ประมาณ 84%) ถูกใช้ไปแล้วก่อนที่จะมีการประมวลผลคำขอเดียว GPU ที่เหลือ 16% จะใช้สำหรับแคช KV สำหรับคำขอที่เข้ามา เป็นไปได้ว่าสำหรับสถานการณ์ทางธุรกิจของคุณ รวมถึงเวลาแฝงและข้อกำหนดปริมาณงาน หน่วยความจำที่เหลืออยู่ 2–3 GB ก็เกินพอแล้ว ถ้าไม่ คุณสามารถเพิ่มขนาดอินสแตนซ์เป็น g5.48xlarge ซึ่งมี 8 GPU และใช้ tensor_parallel_degree ตั้งค่าเป็น 8 ในกรณีเช่นนี้ จะมีการใช้หน่วยความจำ 10 GB ที่มีอยู่เพียงประมาณ 24 GB ของ GPU แต่ละตัวเท่านั้นที่จะถูกใช้สำหรับน้ำหนักโมเดล และเรา มี GPU ที่เหลือประมาณ 60% สำหรับการเปิดใช้งานและแคช KV โดยสังหรณ์ใจ เราจะเห็นว่าการกำหนดค่านี้อาจช่วยให้เรามีปริมาณงานที่สูงขึ้น นอกจากนี้ เนื่องจากเรามีบัฟเฟอร์ที่ใหญ่ขึ้นแล้ว เราจึงสามารถเพิ่มได้ max_rolling_batch_prefill_tokens และ max_rolling_batch_size พารามิเตอร์เพื่อเพิ่มประสิทธิภาพปริมาณงานเพิ่มเติม พารามิเตอร์ทั้งสองนี้จะร่วมกันควบคุมการจัดสรรล่วงหน้าของการเติมการเปิดใช้งานล่วงหน้าและแคช KV สำหรับโมเดล จำนวนที่มากขึ้นสำหรับพารามิเตอร์ทั้งสองนี้จะสัมพันธ์กับปริมาณงานที่สูงขึ้น โดยสมมติว่าคุณมีบัฟเฟอร์เพียงพอสำหรับแคช KV ในหน่วยความจำ GPU

การแบทช์อย่างต่อเนื่องด้วย PagedAttention

PagedAttention เป็นอัลกอริธึมการปรับให้เหมาะสมใหม่ที่พัฒนาโดย UC Berkeley ซึ่งปรับปรุงกระบวนการแบทช์อย่างต่อเนื่องโดยอนุญาตให้แคชความสนใจ (แคช KV) ไม่อยู่ติดกันโดยการจัดสรรหน่วยความจำในเพจหรือบล็อกที่มีขนาดคงที่ สิ่งนี้ได้รับแรงบันดาลใจจากหน่วยความจำเสมือนและแนวคิดเพจที่ใช้โดยระบบปฏิบัติการ

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

การเปรียบเทียบประสิทธิภาพ

เพื่อให้มั่นใจว่าการทดสอบโหลดการกำหนดค่าการใช้งานของคุณมีประสิทธิผล ขอแนะนำให้เริ่มต้นด้วยการพิจารณาสถานการณ์ทางธุรกิจและกำหนดคุณลักษณะของอินพุตและเอาต์พุตสำหรับแอปพลิเคชันที่ใช้ LLM อย่างชัดเจน ตัวอย่างเช่น หากคุณกำลังใช้งานกรณีการใช้งานการสรุปศูนย์บริการข้อมูล อินพุตอาจประกอบด้วยข้อความที่มีขนาดใหญ่กว่า เช่น สำเนาการสนทนา 500 โทเค็นระหว่างตัวแทนฝ่ายบริการลูกค้าและลูกค้า แต่เอาต์พุตอาจค่อนข้างเล็ก ประมาณ 100 โทเค็นซึ่งแสดงถึงบทสรุปของการถอดเสียง ในทางกลับกัน หากคุณกำลังทำงานในสถานการณ์การสร้างโค้ด อินพุตอาจสั้นเพียง 15 โทเค็น เช่น "เขียนการใช้งานที่มีประสิทธิภาพใน Python เพื่ออธิบายทรัพยากร EC2 ทั้งหมด รวมถึงการแบ่งหน้า" แต่ผลลัพธ์อาจมีมาก ใหญ่กว่าถึง 500 โทเค็น สิ่งสำคัญอีกประการหนึ่งคือต้องพิจารณาว่าการได้รับเวลาแฝงที่ต่ำกว่าหรือการเพิ่มปริมาณงานสูงสุดเป็นสิ่งสำคัญที่สุดสำหรับสถานการณ์เฉพาะของคุณหรือไม่

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

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

การผสมแบบไดนามิก	แบตช์ต่อเนื่อง	การรวมกลุ่มอย่างต่อเนื่องด้วย PagedAttention
เครื่องยนต์=หลาม option.model_id=tiiuae/เหยี่ยว-40b option.tensor_parallel_degree=8 option.dtype=fp16 ชุด_ขนาด=4 max_batch_delay=100 option.trust_remote_code = จริง	เครื่องยนต์ = MPI option.model_id = {{s3_url}} option.trust_remote_code = จริง option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = อัตโนมัติ option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = เท็จ	เครื่องยนต์ = MPI option.model_id = {{s3_url}} option.trust_remote_code = จริง option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = อัตโนมัติ option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = จริง

การกำหนดค่าทั้งสองได้รับการเปรียบเทียบประสิทธิภาพสำหรับ Falcon-40B โดยมีประเภทข้อมูล FP16 ใช้งานบน ml.g5.48xlarge ในสถานการณ์ที่แตกต่างกันสองสามสถานการณ์ที่แสดงถึงการใช้งานในโลกแห่งความเป็นจริง:

• โทเค็นอินพุตจำนวนเล็กน้อยซึ่งมีการสร้างโทเค็นจำนวนมาก – ในสถานการณ์สมมตินี้ จำนวนโทเค็นอินพุตได้รับการแก้ไขที่ 32 และสร้างโทเค็นใหม่ 128 รายการ

กลยุทธ์การผสม	ปริมาณงาน (โทเค็น/วินาที)	เวลาแฝง p90 (วินาที)
การผสมแบบไดนามิก	5.53	58.34
แบตช์ต่อเนื่อง	56.04	4.74
การรวมกลุ่มอย่างต่อเนื่องด้วย PagedAttention	59.18	4.76

• อินพุตขนาดใหญ่ที่มีการสร้างโทเค็นจำนวนเล็กน้อย – ที่นี่ เรากำหนดจำนวนโทเค็นอินพุตไว้ที่ 256 และแจ้งให้ LLM สรุปอินพุตเป็น 32 โทเค็น

กลยุทธ์การผสม	ปริมาณงาน (โทเค็น/วินาที)	เวลาแฝง p90 (วินาที)
การผสมแบบไดนามิก	19.96	59.31
แบตช์ต่อเนื่อง	46.69	3.88
การรวมกลุ่มอย่างต่อเนื่องด้วย PagedAttention	44.75	2.67

เราจะเห็นว่าการแบทช์อย่างต่อเนื่องด้วย PagedAttention ช่วยเพิ่มปริมาณงานได้มากขึ้น 10 เท่าในสถานการณ์ที่ 1 และ 2.3 เท่าในสถานการณ์ที่ 2 เมื่อเปรียบเทียบกับการใช้การแบทช์แบบไดนามิกบน SageMaker ในขณะที่ใช้คอนเทนเนอร์ LMI

สรุป

ในโพสต์นี้ เราได้ดูว่า LLM ใช้หน่วยความจำอย่างไร และอธิบายว่าการแบทช์อย่างต่อเนื่องช่วยปรับปรุงปริมาณงานโดยใช้คอนเทนเนอร์ LMI บน SageMaker ได้อย่างไร เราแสดงให้เห็นถึงประโยชน์ของการแบทช์อย่างต่อเนื่องสำหรับ Falcon-40B โดยใช้คอนเทนเนอร์ LMI บน SageMaker โดยการแสดงผลลัพธ์การวัดประสิทธิภาพ คุณสามารถค้นหารหัสได้ที่ repo GitHub.

---

เกี่ยวกับผู้เขียน

อภิศิวะดิตยา เป็นสถาปนิกโซลูชันอาวุโสของ AWS ซึ่งทำงานร่วมกับองค์กรระดับองค์กรเชิงกลยุทธ์ทั่วโลกเพื่ออำนวยความสะดวกในการนำบริการของ AWS ไปใช้ในด้านต่างๆ เช่น ปัญญาประดิษฐ์ การประมวลผลแบบกระจาย ระบบเครือข่าย และพื้นที่จัดเก็บ ความเชี่ยวชาญของเขาอยู่ในการเรียนรู้เชิงลึกในโดเมนของ Natural Language Processing (NLP) และ Computer Vision Abhi ช่วยเหลือลูกค้าในการปรับใช้โมเดลแมชชีนเลิร์นนิงประสิทธิภาพสูงอย่างมีประสิทธิภาพภายในระบบนิเวศของ AWS

ดาวัล พาเทล เป็นหัวหน้าสถาปนิก Machine Learning ที่ AWS เขาได้ทำงานร่วมกับองค์กรต่างๆ ตั้งแต่องค์กรขนาดใหญ่ไปจนถึงสตาร์ทอัพขนาดกลางในปัญหาที่เกี่ยวข้องกับการคำนวณแบบกระจายและปัญญาประดิษฐ์ เขามุ่งเน้นไปที่การเรียนรู้อย่างลึกซึ้งรวมถึงโดเมน NLP และ Computer Vision เขาช่วยให้ลูกค้าบรรลุการอนุมานแบบจำลองประสิทธิภาพสูงบน SageMaker

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

อภิโสธานี ดำรงตำแหน่ง Senior AI/ML Solutions Architect ที่ AWS ซึ่งเขาเชี่ยวชาญในการนำเสนอความเชี่ยวชาญทางเทคนิคและคำแนะนำเกี่ยวกับโซลูชัน Generative AI และ ML ให้กับลูกค้า เป้าหมายหลักของเขาคือการช่วยให้ Digital Native Business ตระหนักถึงศักยภาพของเทคโนโลยี Generative AI และ ML อย่างเต็มที่ ทำให้พวกเขาบรรลุวัตถุประสงค์ทางธุรกิจได้อย่างมีประสิทธิภาพ นอกเหนือจากความพยายามในอาชีพของเขา Abhi ยังแสดงความหลงใหลในการแสวงหาความรู้ทางปัญญา เช่น การอ่าน รวมไปถึงการมีส่วนร่วมในกิจกรรมที่ส่งเสริมความเป็นอยู่ที่ดีทางร่างกายและจิตใจ เช่น โยคะ การทำสมาธิ

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/