เปรียบเทียบและเพิ่มประสิทธิภาพการใช้งานตำแหน่งข้อมูลใน Amazon SageMaker JumpStart | อเมซอนเว็บเซอร์วิส

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

โพสต์นี้จะสำรวจความสัมพันธ์เหล่านี้ผ่านการวัดประสิทธิภาพที่ครอบคลุมของ LLM ที่มีอยู่ใน Amazon SageMaker JumpStart รวมถึงรุ่น Llama 2, Falcon และ Mistral ด้วย SageMaker JumpStart ผู้ปฏิบัติงาน ML สามารถเลือกจากแบบจำลองพื้นฐานที่เปิดเผยต่อสาธารณะที่มีให้เลือกมากมายเพื่อปรับใช้กับเฉพาะ อเมซอน SageMaker อินสแตนซ์ภายในสภาพแวดล้อมที่แยกเครือข่าย เรานำเสนอหลักการทางทฤษฎีว่าข้อกำหนดเร่งความเร็วส่งผลต่อการวัดประสิทธิภาพ LLM อย่างไร นอกจากนี้เรายังแสดงให้เห็นถึงผลกระทบของการใช้งานหลายอินสแตนซ์หลังจุดสิ้นสุดเดียว สุดท้ายนี้ เราให้คำแนะนำที่เป็นประโยชน์สำหรับการปรับแต่งกระบวนการปรับใช้ SageMaker JumpStart เพื่อให้สอดคล้องกับความต้องการของคุณในด้านเวลาแฝง ปริมาณการประมวลผล ต้นทุน และข้อจำกัดในประเภทอินสแตนซ์ที่มีอยู่ ผลลัพธ์การเปรียบเทียบทั้งหมดรวมถึงคำแนะนำจะขึ้นอยู่กับความสามารถรอบด้าน สมุดบันทึก ที่คุณสามารถปรับใช้ให้เข้ากับกรณีการใช้งานของคุณได้

การเปรียบเทียบจุดสิ้นสุดที่ปรับใช้

รูปต่อไปนี้แสดงค่าเวลาแฝงต่ำสุด (ซ้าย) และปริมาณการประมวลผลสูงสุด (ขวา) สำหรับการกำหนดค่าการปรับใช้งานในประเภทโมเดลและประเภทอินสแตนซ์ที่หลากหลาย ที่สำคัญ แต่ละโมเดลเหล่านี้ใช้การกำหนดค่าเริ่มต้นตามที่ SageMaker JumpStart มอบให้ โดยระบุรหัสโมเดลและประเภทอินสแตนซ์ที่ต้องการสำหรับการปรับใช้

ค่าเวลาแฝงและปริมาณการประมวลผลเหล่านี้สอดคล้องกับเพย์โหลดที่มีโทเค็นอินพุต 256 โทเค็นและโทเค็นเอาต์พุต 256 โทเค็น การกำหนดค่าเวลาแฝงต่ำสุดจะจำกัดโมเดลที่ให้บริการคำขอเดียวพร้อมกัน และการกำหนดค่าปริมาณงานสูงสุดจะช่วยเพิ่มจำนวนคำขอพร้อมกันสูงสุดที่เป็นไปได้ ดังที่เราเห็นในการเปรียบเทียบของเรา การเพิ่มคำขอที่เกิดขึ้นพร้อมกันจะเพิ่มปริมาณงานอย่างซ้ำซากจำเจ โดยมีการปรับปรุงน้อยลงสำหรับคำขอจำนวนมากที่เกิดขึ้นพร้อมกัน นอกจากนี้ โมเดลยังได้รับการแบ่งส่วนโดยสมบูรณ์บนอินสแตนซ์ที่รองรับ ตัวอย่างเช่น เนื่องจากอินสแตนซ์ ml.g5.48xlarge มี GPU 8 ตัว SageMaker JumpStart ทุกรุ่นที่ใช้อินสแตนซ์นี้จึงถูกแบ่งส่วนโดยใช้เทนเซอร์ขนานกับตัวเร่งความเร็วที่มีอยู่ทั้ง XNUMX ตัว

เราสามารถสังเกตประเด็นสำคัญบางประการจากตัวเลขนี้ได้ ประการแรก ไม่ใช่ทุกรุ่นที่รองรับในทุกอินสแตนซ์ โมเดลขนาดเล็กบางรุ่น เช่น Falcon 7B ไม่รองรับการแบ่งส่วนโมเดล ในขณะที่โมเดลขนาดใหญ่กว่านั้นมีความต้องการทรัพยากรการประมวลผลที่สูงกว่า ประการที่สอง เมื่อการแบ่งส่วนเพิ่มขึ้น โดยทั่วไปประสิทธิภาพจะดีขึ้น แต่อาจไม่จำเป็นต้องปรับปรุงสำหรับรุ่นขนาดเล็ก. เนื่องจากโมเดลขนาดเล็ก เช่น 7B และ 13B มีค่าใช้จ่ายในการสื่อสารจำนวนมากเมื่อมีการแบ่งส่วนคันเร่งมากเกินไป เราจะหารือเรื่องนี้ในเชิงลึกมากขึ้นในภายหลัง สุดท้ายนี้ อินสแตนซ์ ml.p4d.24xlarge มีแนวโน้มที่จะมีปริมาณการประมวลผลที่ดีขึ้นอย่างมาก เนื่องจากการปรับปรุงแบนด์วิดท์หน่วยความจำที่ A100 มากกว่า A10G GPU ตามที่เราจะพูดคุยกันในภายหลัง การตัดสินใจใช้ประเภทอินสแตนซ์เฉพาะจะขึ้นอยู่กับข้อกำหนดในการปรับใช้ของคุณ รวมถึงเวลาแฝง ปริมาณการประมวลผล และข้อจำกัดด้านต้นทุน

คุณจะได้รับค่าเวลาแฝงที่ต่ำที่สุดและค่าการกำหนดค่าทรูพุตสูงสุดเหล่านี้ได้อย่างไร เริ่มต้นด้วยการวางแผนเวลาแฝงเทียบกับปริมาณงานสำหรับตำแหน่งข้อมูล Llama 2 7B บนอินสแตนซ์ ml.g5.12xlarge สำหรับเพย์โหลดที่มีโทเค็นอินพุต 256 โทเค็นและโทเค็นเอาต์พุต 256 โทเค็น ดังที่เห็นในเส้นโค้งต่อไปนี้ มีเส้นโค้งที่คล้ายกันสำหรับตำแหน่งข้อมูล LLM ทุกจุดที่ใช้งาน

เมื่อการทำงานพร้อมกันเพิ่มขึ้น ปริมาณงานและเวลาแฝงก็เพิ่มขึ้นอย่างซ้ำซากเช่นกัน ดังนั้น จุดเวลาแฝงต่ำสุดจึงเกิดขึ้นที่ค่าคำขอที่เกิดขึ้นพร้อมกันที่ 1 และคุณสามารถเพิ่มปริมาณงานของระบบได้อย่างคุ้มค่าโดยการเพิ่มคำขอที่เกิดขึ้นพร้อมกัน มี "หัวเข่า" ที่ชัดเจนในเส้นโค้งนี้ ซึ่งเห็นได้ชัดว่าปริมาณงานที่เพิ่มขึ้นที่เกี่ยวข้องกับการทำงานพร้อมกันเพิ่มเติมนั้นไม่ได้มีค่าเกินกว่าเวลาแฝงที่เพิ่มขึ้นที่เกี่ยวข้อง ตำแหน่งที่แน่นอนของเข่านี้คือการใช้งานเฉพาะกรณี ผู้ปฏิบัติงานบางรายอาจกำหนดข้อเข่า ณ จุดที่เกินข้อกำหนดด้านเวลาแฝงที่กำหนดไว้ล่วงหน้า (เช่น 100 ms/โทเค็น) ในขณะที่คนอื่นๆ อาจใช้เกณฑ์มาตรฐานการทดสอบโหลดและวิธีการตามทฤษฎีการเข้าคิว เช่น กฎเวลาแฝงครึ่งหนึ่ง และคนอื่นๆ อาจใช้ ข้อมูลจำเพาะของเครื่องเร่งความเร็วทางทฤษฎี

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

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

เราสังเกตรูปแบบเพิ่มเติมบางอย่างในข้อมูลนี้ เมื่อเพิ่มขนาดบริบท เวลาแฝงจะเพิ่มขึ้นและปริมาณงานลดลง ตัวอย่างเช่น บน ml.g5.2xlarge ที่มีการทำงานพร้อมกันที่ 1 ปริมาณการประมวลผลจะเป็น 30 โทเค็น/วินาที เมื่อจำนวนโทเค็นทั้งหมดคือ 512 เทียบกับ 20 โทเค็น/วินาที หากจำนวนโทเค็นทั้งหมดคือ 4,096 เนื่องจากต้องใช้เวลามากขึ้นในการประมวลผลอินพุตที่มีขนาดใหญ่กว่า เรายังเห็นได้ว่าการเพิ่มความสามารถของ GPU และการแบ่งส่วนส่งผลต่อปริมาณงานสูงสุดและคำขอสูงสุดที่รองรับพร้อมกัน ตารางแสดงให้เห็นว่า Llama 2 7B มีค่าทรูพุตสูงสุดที่แตกต่างกันอย่างเห็นได้ชัดสำหรับอินสแตนซ์ประเภทต่างๆ และค่าทรูพุตสูงสุดเหล่านี้เกิดขึ้นที่ค่าต่างกันของคำขอที่เกิดขึ้นพร้อมกัน คุณลักษณะเหล่านี้จะผลักดันให้ผู้ปฏิบัติงาน ML พิจารณาต้นทุนของอินสแตนซ์หนึ่งเหนืออีกอินสแตนซ์หนึ่ง ตัวอย่างเช่น เนื่องจากข้อกำหนดด้านเวลาแฝงต่ำ ผู้ปฏิบัติงานอาจเลือกอินสแตนซ์ ml.g5.12xlarge (A4G GPU 10 ตัว) มากกว่าอินสแตนซ์ ml.g5.2xlarge (1 A10G GPU) หากได้รับข้อกำหนดปริมาณการประมวลผลที่สูง การใช้อินสแตนซ์ ml.p4d.24xlarge (A8 GPU จำนวน 100 ตัว) ที่มีการแบ่งส่วนข้อมูลแบบเต็มจะได้รับการพิจารณาภายใต้การทำงานพร้อมกันสูงเท่านั้น อย่างไรก็ตาม โปรดทราบว่าการโหลดองค์ประกอบการอนุมานหลายรายการของโมเดล 7B บนอินสแตนซ์ ml.p4d.24xlarge เดียวมักจะเป็นประโยชน์ การสนับสนุนหลายรุ่นดังกล่าวจะกล่าวถึงในโพสต์นี้ในภายหลัง

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

ทำความเข้าใจกับข้อมูลจำเพาะของคันเร่ง

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

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

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

แคช KV และหน่วยความจำอุปกรณ์

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

ในสูตรนี้ B คือขนาดแบตช์ และ N คือจำนวนตัวเร่งความเร็ว ตัวอย่างเช่น รุ่น Llama 2 7B ใน FP16 (2 ไบต์/พารามิเตอร์) ที่ให้บริการบน A10G GPU (24 GB DRAM) จะใช้พื้นที่ประมาณ 14 GB โดยเหลือ 10 GB สำหรับแคช KV เมื่อเสียบความยาวบริบทเต็มของโมเดล (N = 4096) และพารามิเตอร์ที่เหลือ (n_layers=32, n_kv_attention_heads=32 และ d_attention_head=128) นิพจน์นี้แสดงว่าเราถูกจำกัดการให้บริการขนาดแบตช์ของผู้ใช้สี่คนพร้อมกันเนื่องจากข้อจำกัดของ DRAM . หากคุณสังเกตเกณฑ์มาตรฐานที่เกี่ยวข้องในตารางก่อนหน้านี้ นี่เป็นค่าประมาณที่ดีสำหรับข้อเข่าที่สังเกตได้ในกราฟเวลาในการตอบสนอง-ปริมาณงานนี้ วิธีการต่างๆ เช่น ความสนใจในแบบสอบถามที่จัดกลุ่ม (GQA) สามารถลดขนาดแคช KV ได้ ในกรณีของ GQA จะลดจำนวนหัว KV ด้วยปัจจัยเดียวกัน

ความเข้มทางคณิตศาสตร์และแบนด์วิธหน่วยความจำอุปกรณ์

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

พื้นที่ ความเข้มทางคณิตศาสตร์หรืออัตราส่วนของการดำเนินการประมวลผลต่อการเข้าถึงหน่วยความจำ สำหรับการดำเนินการจะกำหนดว่าถูกจำกัดโดยแบนด์วิธหน่วยความจำหรือความสามารถในการคำนวณบนฮาร์ดแวร์ที่เลือก ตัวอย่างเช่น A10G GPU (กลุ่มประเภทอินสแตนซ์ g5) ที่มีแบนด์วิดท์ 70 TFLOPS FP16 และ 600 GB/วินาที สามารถคำนวณประมาณ 116 ops/ไบต์ A100 GPU (กลุ่มประเภทอินสแตนซ์ p4d) สามารถประมวลผลได้ประมาณ 208 Ops/ไบต์ หากความเข้มทางคณิตศาสตร์สำหรับแบบจำลองหม้อแปลงอยู่ภายใต้ค่านั้น แสดงว่าถูกผูกไว้กับหน่วยความจำ หากอยู่ด้านบนแสดงว่ามีการประมวลผล กลไกความสนใจสำหรับ Llama 2 7B ต้องใช้ 62 ops/ไบต์สำหรับแบตช์ขนาด 1 (สำหรับคำอธิบาย โปรดดูที่ คำแนะนำเกี่ยวกับการอนุมานและประสิทธิภาพของ LLM) ซึ่งหมายความว่ามีหน่วยความจำผูกไว้ เมื่อกลไกความสนใจถูกผูกไว้กับหน่วยความจำ FLOPS ที่มีราคาแพงจะถูกปล่อยทิ้งไว้โดยไม่ได้ใช้งาน

มีสองวิธีในการใช้ตัวเร่งความเร็วให้ดีขึ้นและเพิ่มความเข้มข้นทางคณิตศาสตร์: ลดการเข้าถึงหน่วยความจำที่จำเป็นสำหรับการดำเนินการ (นี่คือสิ่งที่ แฟลชความสนใจ เน้น) หรือเพิ่มขนาดแบทช์ อย่างไรก็ตาม เราอาจไม่สามารถเพิ่มขนาดแบตช์ของเราได้มากพอที่จะเข้าถึงระบอบการปกครองที่จำกัดด้วยการประมวลผล หาก DRAM ของเราเล็กเกินไปที่จะเก็บแคช KV ที่เกี่ยวข้อง การประมาณคร่าวๆ ของขนาดแบตช์วิกฤต B* ที่แยกขอบเขตการประมวลผลออกจากระบบที่ผูกกับหน่วยความจำสำหรับการอนุมานตัวถอดรหัส GPT มาตรฐาน ได้รับการอธิบายโดยนิพจน์ต่อไปนี้ โดยที่ A_mb คือแบนด์วิดท์หน่วยความจำตัวเร่ง A_f คือ Accelerator FLOPS และ N คือตัวเลข ของคันเร่ง ขนาดแบทช์ที่สำคัญนี้สามารถหาได้โดยการค้นหาว่าเวลาในการเข้าถึงหน่วยความจำเท่ากับเวลาในการคำนวณ อ้างถึง โพสต์บล็อกนี้ เพื่อทำความเข้าใจสมการที่ 2 และสมมติฐานของมันอย่างละเอียดมากขึ้น

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

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

หากต้องการเปรียบเทียบ ML Accelerator ตามข้อมูลจำเพาะ เราขอแนะนำดังนี้ ขั้นแรก ให้คำนวณขนาดแบตช์วิกฤตโดยประมาณสำหรับตัวเร่งความเร็วแต่ละประเภทตามสมการที่สอง และขนาดแคช KV สำหรับขนาดแบตช์วิกฤตตามสมการแรก จากนั้นคุณสามารถใช้ DRAM ที่มีอยู่บนตัวเร่งความเร็วเพื่อคำนวณจำนวนตัวเร่งความเร็วขั้นต่ำที่จำเป็นเพื่อให้พอดีกับแคช KV และพารามิเตอร์โมเดล หากต้องตัดสินใจเลือกระหว่างตัวเร่งความเร็วหลายตัว ให้จัดลำดับความสำคัญของตัวเร่งความเร็วตามต้นทุนต่ำสุดต่อ GB/วินาทีของแบนด์วิธหน่วยความจำ สุดท้าย เปรียบเทียบการกำหนดค่าเหล่านี้ และตรวจสอบว่าราคา/โทเค็นที่ดีที่สุดสำหรับขอบเขตบนของเวลาแฝงที่ต้องการของคุณคืออะไร

เลือกการกำหนดค่าการใช้งานปลายทาง

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

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

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

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

ลดเวลาแฝงให้เหลือน้อยที่สุด

เวลาแฝงเป็นข้อกำหนดที่สำคัญในกรณีการใช้งานแบบเรียลไทม์จำนวนมาก ในตารางต่อไปนี้ เราจะดูเวลาแฝงขั้นต่ำสำหรับแต่ละรุ่นและอินสแตนซ์แต่ละประเภท คุณสามารถบรรลุเวลาแฝงขั้นต่ำได้โดยการตั้งค่า MAX_CONCURRENT_REQUESTS = 1.

เพื่อให้ได้รับเวลาแฝงขั้นต่ำสำหรับโมเดล คุณสามารถใช้โค้ดต่อไปนี้ในขณะที่แทนที่ ID โมเดลและประเภทอินสแตนซ์ที่คุณต้องการ:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

โปรดทราบว่าตัวเลขเวลาแฝงจะเปลี่ยนไปขึ้นอยู่กับจำนวนโทเค็นอินพุตและเอาต์พุต อย่างไรก็ตาม กระบวนการปรับใช้ยังคงเหมือนเดิมยกเว้นตัวแปรสภาพแวดล้อม MAX_INPUT_TOKENS และ MAX_TOTAL_TOKENS. ที่นี่ ตัวแปรสภาพแวดล้อมเหล่านี้ได้รับการตั้งค่าเพื่อช่วยรับประกันข้อกำหนดด้านเวลาแฝงของจุดสิ้นสุด เนื่องจากลำดับอินพุตที่ใหญ่กว่าอาจละเมิดข้อกำหนดด้านเวลาแฝง โปรดทราบว่า SageMaker JumpStart ได้จัดเตรียมตัวแปรสภาพแวดล้อมที่เหมาะสมที่สุดอื่นๆ ไว้แล้วเมื่อเลือกประเภทอินสแตนซ์ เช่น ใช้ ml.g5.12xlarge จะเป็นการตั้งค่า SM_NUM_GPUS ถึง 4 ในสภาพแวดล้อมแบบจำลอง

เพิ่มปริมาณงานสูงสุด

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

เพื่อให้ได้รับปริมาณงานสูงสุดสำหรับโมเดล คุณสามารถใช้โค้ดต่อไปนี้:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

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

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

ลดค่าใช้จ่าย

ตัวเลือกแรกในการลดต้นทุนเกี่ยวข้องกับการลดต้นทุนต่อชั่วโมงให้เหลือน้อยที่สุด ด้วยวิธีนี้ คุณสามารถปรับใช้โมเดลที่เลือกบนอินสแตนซ์ SageMaker ด้วยต้นทุนต่อชั่วโมงที่ต่ำที่สุด สำหรับราคาแบบเรียลไทม์ของอินสแตนซ์ SageMaker โปรดดูที่ ราคา Amazon SageMaker. โดยทั่วไป ประเภทอินสแตนซ์เริ่มต้นสำหรับ SageMaker JumpStart LLM คือตัวเลือกการปรับใช้ที่มีต้นทุนต่ำที่สุด

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

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

เทนเซอร์แบบขนานกับการแลกเปลี่ยนหลายรุ่น

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

ที่นี่ เราปรับใช้ตำแหน่งข้อมูล Llama 2 7B และ 13B บนอินสแตนซ์ ml.p4d.24xlarge ที่มีเทนเซอร์ขนาน (TP) องศา 1, 2, 4 และ 8 เพื่อความชัดเจนในลักษณะการทำงานของโมเดล ตำแหน่งข้อมูลแต่ละตำแหน่งเหล่านี้โหลดเพียงโมเดลเดียวเท่านั้น

การวิเคราะห์ก่อนหน้านี้ของเราแสดงให้เห็นข้อได้เปรียบด้านปริมาณการประมวลผลอย่างมีนัยสำคัญบนอินสแตนซ์ ml.p4d.24xlarge ซึ่งมักจะแปลไปสู่ประสิทธิภาพที่ดีขึ้นในแง่ของต้นทุนในการสร้างโทเค็น 1 ล้านโทเค็นเหนือกลุ่มอินสแตนซ์ g5 ภายใต้เงื่อนไขการโหลดคำขอที่เกิดขึ้นพร้อมกันในระดับสูง การวิเคราะห์นี้แสดงให้เห็นอย่างชัดเจนว่าคุณควรพิจารณาถึงข้อดีข้อเสียระหว่างการแบ่งส่วนโมเดลและการจำลองโมเดลภายในอินสแตนซ์เดียว กล่าวคือ โดยทั่วไปแล้วโมเดลที่แบ่งย่อยทั้งหมดจะไม่ใช่การใช้ทรัพยากรการประมวลผล ml.p4d.24xlarge ที่ดีที่สุดสำหรับตระกูลโมเดล 7B และ 13B ในความเป็นจริง สำหรับตระกูลรุ่น 7B คุณจะได้รับปริมาณงานที่ดีที่สุดสำหรับแบบจำลองแบบจำลองเดียวที่มีดีกรีขนานเทนเซอร์เป็น 4 แทนที่จะเป็น 8

จากที่นี่ คุณสามารถคาดการณ์ได้ว่าการกำหนดค่าปริมาณงานสูงสุดสำหรับรุ่น 7B เกี่ยวข้องกับระดับขนานของเทนเซอร์ที่ 1 กับแบบจำลองแบบจำลองแปดรายการ และการกำหนดค่าปริมาณการประมวลผลสูงสุดสำหรับรุ่น 13B มีแนวโน้มว่าระดับขนานของเทนเซอร์เป็น 2 กับแบบจำลองแบบจำลองสี่รายการ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการบรรลุเป้าหมายนี้ โปรดดูที่ ลดต้นทุนการปรับใช้โมเดลโดยเฉลี่ย 50% โดยใช้คุณสมบัติล่าสุดของ Amazon SageMakerซึ่งแสดงให้เห็นถึงการใช้จุดสิ้นสุดตามองค์ประกอบการอนุมาน เนื่องจากเทคนิคการปรับสมดุลโหลด การกำหนดเส้นทางเซิร์ฟเวอร์ และการแชร์ทรัพยากร CPU คุณอาจไม่ได้รับการปรับปรุงปริมาณงานอย่างสมบูรณ์เท่ากับจำนวนเรพลิกาคูณด้วยปริมาณงานสำหรับเรพลิกาเดียว

มาตราส่วนแนวนอน

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

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

ตารางต่อไปนี้แสดงปริมาณการประมวลผลที่เพิ่มขึ้นโดยพิจารณาจากจำนวนอินสแตนซ์สำหรับรุ่น Llama 2 7B

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

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

เรียกใช้จุดสิ้นสุดพร้อมกับคำขอที่เกิดขึ้นพร้อมกัน

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

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

เมื่อส่งคำขอจำนวนมากไปยังรันไทม์ API ของ SageMaker คุณอาจพบข้อผิดพลาดในการควบคุมปริมาณ เพื่อบรรเทาปัญหานี้ คุณสามารถสร้างรันไทม์ไคลเอ็นต์ SageMaker แบบกำหนดเองซึ่งจะเพิ่มจำนวนครั้งในการลองใหม่ คุณสามารถจัดเตรียมออบเจ็กต์เซสชัน SageMaker ที่เป็นผลลัพธ์ให้กับทั้ง JumpStartModel ตัวสร้างหรือ sagemaker.predictor.retrieve_default หากคุณต้องการแนบตัวทำนายใหม่กับตำแหน่งข้อมูลที่ใช้งานอยู่แล้ว ในโค้ดต่อไปนี้ เราใช้ออบเจ็กต์เซสชันนี้เมื่อปรับใช้โมเดล Llama 2 ด้วยการกำหนดค่าเริ่มต้นของ SageMaker JumpStart:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

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

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

ซึ่งส่งผลให้เกิดการสร้างโทเค็นทั้งหมด 100,000 โทเค็นด้วยปริมาณงาน 1255 โทเค็น/วินาทีบนอินสแตนซ์ ml.g5.2xlarge เดียว ใช้เวลาประมาณ 80 วินาทีในการประมวลผล

โปรดทราบว่าค่าปริมาณการประมวลผลนี้แตกต่างอย่างเห็นได้ชัดจากปริมาณการประมวลผลสูงสุดสำหรับ Llama 2 7B บน ml.g5.2xlarge ในตารางก่อนหน้าของโพสต์นี้ (486 โทเค็น/วินาทีที่ 64 คำขอพร้อมกัน) เนื่องจากเพย์โหลดอินพุตใช้ 8 โทเค็นแทนที่จะเป็น 256 จำนวนโทเค็นเอาต์พุตคือ 100 แทนที่จะเป็น 256 และจำนวนโทเค็นที่น้อยกว่าจะอนุญาตให้มีคำขอได้ 128 รายการพร้อมกัน นี่เป็นการเตือนครั้งสุดท้ายว่าจำนวนเวลาแฝงและปริมาณการประมวลผลทั้งหมดขึ้นอยู่กับเพย์โหลด! การเปลี่ยนแปลงจำนวนโทเค็นเพย์โหลดจะส่งผลต่อกระบวนการแบทช์ระหว่างการแสดงโมเดล ซึ่งจะส่งผลต่อเวลาการกรอกข้อมูลล่วงหน้า การถอดรหัส และคิวที่เกิดขึ้นสำหรับแอปพลิเคชันของคุณ

สรุป

ในโพสต์นี้ เราได้นำเสนอการเปรียบเทียบประสิทธิภาพของ SageMaker JumpStart LLM ซึ่งรวมถึง Llama 2, Mistral และ Falcon นอกจากนี้เรายังนำเสนอคำแนะนำในการปรับเวลาแฝง ปริมาณการประมวลผล และต้นทุนให้เหมาะสมสำหรับการกำหนดค่าการใช้งานตำแหน่งข้อมูลของคุณ คุณสามารถเริ่มต้นด้วยการเรียกใช้ โน๊ตบุ๊คที่เกี่ยวข้อง เพื่อเปรียบเทียบกรณีการใช้งานของคุณ

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

 ดร.ไคล์ อูลริช เป็นนักวิทยาศาสตร์ประยุกต์กับทีม Amazon SageMaker JumpStart งานวิจัยที่เขาสนใจ ได้แก่ อัลกอริธึมแมชชีนเลิร์นนิงที่ปรับขนาดได้ คอมพิวเตอร์วิทัศน์ อนุกรมเวลา เบส์ที่ไม่ใช่พารามิเตอร์ และกระบวนการเกาส์เซียน ปริญญาเอกของเขามาจาก Duke University และเขาได้ตีพิมพ์บทความใน NeurIPS, Cell และ Neuron

Dr. วิเวก มาดาน เป็นนักวิทยาศาสตร์ประยุกต์กับทีม Amazon SageMaker JumpStart เขาสำเร็จการศึกษาระดับปริญญาเอกจากมหาวิทยาลัยอิลลินอยส์ Urbana-Champaign และเป็นนักวิจัยหลังปริญญาเอกที่ Georgia Tech เขาเป็นนักวิจัยเชิงรุกด้านการเรียนรู้ของเครื่องและการออกแบบอัลกอริธึม และได้ตีพิมพ์เอกสารในการประชุม EMNLP, ICLR, COLT, FOCS และ SODA

ดร. Ashish Khetan เป็นนักวิทยาศาสตร์ประยุกต์อาวุโสของ Amazon SageMaker JumpStart และช่วยพัฒนาอัลกอริทึมการเรียนรู้ของเครื่อง เขาได้รับปริญญาเอกจาก University of Illinois Urbana-Champaign เขาเป็นนักวิจัยที่กระตือรือร้นในด้านแมชชีนเลิร์นนิงและการอนุมานทางสถิติ และได้ตีพิมพ์บทความจำนวนมากในการประชุม NeurIPS, ICML, ICLR, JMLR, ACL และ EMNLP

ชูเอา มูร่า เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญ AI/ML อาวุโสที่ AWS João ช่วยลูกค้า AWS ตั้งแต่สตาร์ทอัพขนาดเล็กไปจนถึงองค์กรขนาดใหญ่ ในการฝึกอบรมและปรับใช้โมเดลขนาดใหญ่อย่างมีประสิทธิภาพ และสร้างแพลตฟอร์ม ML บน AWS ในวงกว้างมากขึ้น

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