บรรลุประสิทธิภาพสูงตามขนาดของโมเดลที่ให้บริการโดยใช้ตำแหน่งข้อมูลหลายโมเดลของ Amazon SageMaker พร้อม GPU

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

ในเดือนพฤศจิกายน 2022, MMEs เพิ่มการรองรับสำหรับ GPUs ซึ่งช่วยให้คุณเรียกใช้หลายรุ่นบนอุปกรณ์ GPU เครื่องเดียวและปรับขนาดอินสแตนซ์ GPU หลังจุดสิ้นสุดเดียว สิ่งนี้ตอบสนองความต้องการ MME ที่แข็งแกร่งสำหรับโมเดลโครงข่ายประสาทเทียมเชิงลึก (DNN) ที่ได้รับประโยชน์จากการประมวลผลแบบเร่งความเร็วด้วย GPU ซึ่งรวมถึงการมองเห็นด้วยคอมพิวเตอร์ (CV) การประมวลผลภาษาธรรมชาติ (NLP) และแบบจำลอง AI กำเนิด เหตุผลสำหรับความต้องการรวมถึงต่อไปนี้:

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

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

ด้วยเหตุผลดังกล่าว เราจึงรวบรวมโพสต์นี้เพื่อช่วยคุณทำการทดสอบโหลดที่เหมาะสมบน MME ด้วย GPU และค้นหาการกำหนดค่าที่ดีที่สุดสำหรับกรณีการใช้งาน ML ของคุณ เราแบ่งปันผลการทดสอบการโหลดของเราสำหรับโมเดล DNN ที่ได้รับความนิยมมากที่สุดใน NLP และ CV ที่โฮสต์โดยใช้ MME บนอินสแตนซ์ประเภทต่างๆ เราสรุปข้อมูลเชิงลึกและข้อสรุปจากผลการทดสอบของเรา เพื่อช่วยให้คุณตัดสินใจอย่างรอบรู้เกี่ยวกับการกำหนดค่าการปรับใช้ของคุณเอง ระหว่างทาง เรายังแชร์แนวทางที่แนะนำในการดำเนินการทดสอบโหลดสำหรับ MME บน GPU เครื่องมือและเทคนิคที่แนะนำจะกำหนดจำนวนโมเดลที่เหมาะสมที่สุดที่สามารถโหลดได้ต่อประเภทอินสแตนซ์ และช่วยให้คุณได้รับประสิทธิภาพด้านราคาที่ดีที่สุด

ภาพรวมโซลูชัน

สำหรับคำแนะนำเกี่ยวกับ MME และ MME ด้วย GPU โปรดดูที่ สร้างปลายทางหลายรุ่น และ เรียกใช้โมเดลการเรียนรู้เชิงลึกหลายรายการบน GPU ด้วยตำแหน่งข้อมูลหลายรุ่นของ Amazon SageMaker. สำหรับบริบทของการทดสอบโหลดในโพสต์นี้ คุณสามารถดาวน์โหลดโค้ดตัวอย่างของเราได้จาก repo GitHub เพื่อสร้างผลลัพธ์ซ้ำหรือใช้เป็นเทมเพลตในการเปรียบเทียบแบบจำลองของคุณเอง มีโน้ตบุ๊กสองเครื่องใน repo: เครื่องหนึ่งสำหรับการทดสอบโหลดโมเดล CV และอีกเครื่องสำหรับ NLP หลายรุ่นที่มีขนาดและสถาปัตยกรรมที่แตกต่างกันได้รับการวัดประสิทธิภาพบนอินสแตนซ์ GPU ประเภทต่างๆ: ml.g4dn.2xlarge, ml.g5.2xlarge และ ml.p3.2xlarge สิ่งนี้ควรให้ผลการทำงานข้ามส่วนที่เหมาะสมในเมตริกต่อไปนี้สำหรับแต่ละอินสแตนซ์และประเภทโมเดล:

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

ตารางต่อไปนี้แสดงรายการรุ่นที่ทดสอบ

ตารางต่อไปนี้แสดงรายการอินสแตนซ์ GPU ที่ทดสอบ

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

โปรดทราบว่าขณะนี้ MME รองรับอินสแตนซ์ GPU เดียวเท่านั้น สำหรับรายการประเภทอินสแตนซ์ที่รองรับ โปรดดูที่ อัลกอริทึม เฟรมเวิร์ก และอินสแตนซ์ที่รองรับ.

ขั้นตอนการเปรียบเทียบประกอบด้วยขั้นตอนต่อไปนี้:

1. ดึงโมเดลที่ฝึกไว้ล่วงหน้าจากฮับโมเดล
2. เตรียมโมเดลอาร์ติแฟกต์สำหรับให้บริการบน SageMaker MME (ดู เรียกใช้โมเดลการเรียนรู้เชิงลึกหลายรายการบน GPU ด้วยตำแหน่งข้อมูลหลายรุ่นของ Amazon SageMaker สำหรับรายละเอียดเพิ่มเติม)
3. ปรับใช้ SageMaker MME บนอินสแตนซ์ GPU
4. กำหนดจำนวนรุ่นสูงสุดที่สามารถโหลดลงในหน่วยความจำ GPU ภายในเกณฑ์ที่กำหนด
5. ใช้ Locust Load Testing Framework เพื่อจำลองการรับส่งข้อมูลที่สุ่มเรียกใช้โมเดลที่โหลดบนอินสแตนซ์
6. รวบรวมข้อมูลและวิเคราะห์ผลลัพธ์
7. หรือทำซ้ำขั้นตอนที่ 2-6 หลังจากคอมไพล์โมเดลเป็น TensorRT

ขั้นตอนที่ 4 และ 5 รับประกันการมองที่ลึกขึ้น โมเดลต่างๆ ภายใน SageMaker GPU MME จะถูกโหลดเข้าสู่หน่วยความจำในลักษณะไดนามิก ดังนั้นในขั้นตอนที่ 4 เราจึงอัปโหลดสิ่งประดิษฐ์แบบจำลองเริ่มต้นไปที่ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) และเรียกใช้โมเดลเพื่อโหลดลงในหน่วยความจำ หลังจากการเรียกใช้ครั้งแรก เราจะวัดปริมาณหน่วยความจำ GPU ที่ใช้ ทำสำเนาของโมเดลเริ่มต้น เรียกใช้สำเนาของโมเดลเพื่อโหลดลงในหน่วยความจำ และวัดจำนวนหน่วยความจำ GPU ทั้งหมดที่ใช้อีกครั้ง กระบวนการนี้จะเกิดขึ้นซ้ำจนกว่าจะถึงเกณฑ์เปอร์เซ็นต์ของการใช้หน่วยความจำ GPU ที่ระบุ สำหรับการวัดประสิทธิภาพ เราตั้งค่าเกณฑ์เป็น 90% เพื่อให้มีบัฟเฟอร์หน่วยความจำที่เหมาะสมสำหรับการอนุมานในแบทช์ที่ใหญ่ขึ้นหรือเว้นที่ว่างไว้เพื่อโหลดโมเดลอื่นๆ ที่ใช้งานไม่บ่อย

จำลองปริมาณการใช้งานของผู้ใช้

หลังจากที่เรากำหนดจำนวนรุ่นแล้ว เราสามารถเรียกใช้การทดสอบโหลดโดยใช้ กรอบการทดสอบ Locust Load. การทดสอบโหลดจะจำลองคำขอของผู้ใช้เป็นแบบจำลองแบบสุ่มและวัดเมตริกโดยอัตโนมัติ เช่น เวลาตอบสนองและปริมาณงาน

Locust รองรับรูปร่างการทดสอบการโหลดแบบกำหนดเองที่ให้คุณกำหนดรูปแบบการรับส่งข้อมูลแบบกำหนดเองได้ รูปร่างที่ใช้ในเกณฑ์มาตรฐานนี้จะแสดงในแผนภูมิต่อไปนี้ ใน 30 วินาทีแรก จุดสิ้นสุดจะอุ่นเครื่องด้วยผู้ใช้พร้อมกัน 10 คน หลังจากผ่านไป 30 วินาที ผู้ใช้ใหม่จะเกิดในอัตรา 20 คนต่อวินาที ซึ่งจะมีผู้ใช้พร้อมกัน 40 คนในเวลา 20 วินาที จากนั้นจุดสิ้นสุดจะได้รับการเปรียบเทียบอย่างต่อเนื่องกับผู้ใช้พร้อมกัน 60 คนจนถึงเวลา 40 วินาที ซึ่งจุดนั้น Locust จะเริ่มเพิ่มจำนวนผู้ใช้อีกครั้งที่ 200 คนต่อวินาทีจนกระทั่งมีผู้ใช้พร้อมกัน 200 คน รูปแบบการเพิ่มจำนวนขึ้นและการทดสอบอย่างต่อเนื่องนี้จะเกิดขึ้นซ้ำๆ จนกว่าจุดสิ้นสุดจะเพิ่มผู้ใช้พร้อมกันสูงสุด XNUMX คน ขึ้นอยู่กับกรณีการใช้งานของคุณ คุณอาจต้องการปรับรูปแบบการทดสอบโหลดใน locust_benchmark_sm.py เพื่อให้สะท้อนรูปแบบการรับส่งข้อมูลได้แม่นยำยิ่งขึ้น ตัวอย่างเช่น หากคุณต้องการโฮสต์โมเดลภาษาที่ใหญ่ขึ้น การทดสอบโหลดที่มีผู้ใช้พร้อมกัน XNUMX คนอาจไม่สามารถทำได้สำหรับโมเดลที่โฮสต์บนอินสแตนซ์เดียว ดังนั้นคุณอาจต้องการลดจำนวนผู้ใช้หรือเพิ่มจำนวนอินสแตนซ์ นอกจากนี้ คุณยังอาจต้องการขยายระยะเวลาของการทดสอบโหลดเพื่อวัดความเสถียรของเอ็นด์พอยต์ได้อย่างแม่นยำยิ่งขึ้นในระยะเวลาที่นานขึ้น

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

โปรดทราบว่าเราได้เปรียบเทียบเฉพาะจุดสิ้นสุดกับโมเดลที่เป็นเนื้อเดียวกันซึ่งทั้งหมดทำงานบนฐานการให้บริการที่สอดคล้องกันโดยใช้ PyTorch หรือ TensorRT นี่เป็นเพราะ MME เหมาะที่สุดสำหรับการโฮสต์โมเดลจำนวนมากที่มีลักษณะคล้ายกัน เช่น การใช้หน่วยความจำและเวลาตอบสนอง เทมเพลตการเปรียบเทียบที่มีให้ใน repo GitHub ยังคงสามารถใช้เพื่อกำหนดว่าการให้บริการโมเดลที่แตกต่างกันบน MME จะให้ประสิทธิภาพและความเสถียรตามที่ต้องการหรือไม่

ผลลัพธ์เกณฑ์มาตรฐานสำหรับโมเดล CV

ใช้โน้ตบุ๊ก cv-benchmark.ipynb เพื่อรันการทดสอบโหลดสำหรับโมเดลการมองเห็นของคอมพิวเตอร์ คุณสามารถปรับชื่อรุ่นที่ได้รับการฝึกล่วงหน้าและพารามิเตอร์ประเภทอินสแตนซ์เพื่อทดสอบโหลดประสิทธิภาพบนชุดค่าผสมของรุ่นและประเภทอินสแตนซ์ต่างๆ เราตั้งใจทดสอบ CV สามรุ่นในขนาดต่างๆ ตั้งแต่เล็กที่สุดไปจนถึงใหญ่ที่สุด: resnet50 (25 ล้าน), convnext_base (88M), และ vit_large_patch16_224 (304M). คุณอาจต้องปรับรหัสหากคุณเลือกรุ่นที่อยู่นอกรายการนี้ นอกจากนี้ โน้ตบุ๊กยังตั้งค่าเริ่มต้นของรูปร่างภาพที่ป้อนเป็นอิมเมจเทนเซอร์ขนาด 224x224x3 อย่าลืมปรับรูปร่างอินพุตให้เหมาะสม หากคุณต้องการเปรียบเทียบโมเดลที่ใช้รูปภาพที่มีขนาดต่างกัน

หลังจากดำเนินการผ่านโน้ตบุ๊กทั้งหมดแล้ว คุณจะได้รับการแสดงภาพการวิเคราะห์ประสิทธิภาพหลายรายการ สองรายการแรกให้รายละเอียดเกี่ยวกับประสิทธิภาพของโมเดลที่เกี่ยวข้องกับผู้ใช้พร้อมกันที่เพิ่มขึ้น ตัวเลขต่อไปนี้คือการแสดงภาพตัวอย่างที่สร้างขึ้นสำหรับ ResNet50 โมเดลที่ทำงานบน ml.g4dn.2xlarge เปรียบเทียบ PyTorch (ซ้าย) กับ TensorRT (ขวา) กราฟเส้นบนสุดแสดงเวลาแฝงของโมเดลและทรูพุตบนแกน y พร้อมจำนวนพนักงานไคลเอ็นต์ที่ทำงานพร้อมกันที่เพิ่มขึ้นซึ่งสะท้อนบนแกน x แผนภูมิแท่งด้านล่างแสดงจำนวนคำขอที่สำเร็จและล้มเหลว

เมื่อพิจารณาโมเดลการมองเห็นของคอมพิวเตอร์ทั้งหมดที่เราทดสอบ เราสังเกตเห็นสิ่งต่อไปนี้:

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

ในตอนท้ายของการทำงานของโน้ตบุ๊ก คุณจะได้รับการเปรียบเทียบโดยสรุประหว่างโมเดล PyTorch กับ TensorRT สำหรับแต่ละเมตริกหลักทั้งสี่ จากการทดสอบเกณฑ์มาตรฐานของเรา โมเดล CV ทั้งหมดได้รับการเพิ่มประสิทธิภาพของโมเดลหลังจากการคอมไพล์ TensorRT การของเรา ResNet50 ตามตัวอย่างอีกครั้ง เวลาแฝงลดลง 32% ในขณะที่ปริมาณงานเพิ่มขึ้น 18% แม้ว่าจำนวนผู้ใช้พร้อมกันสูงสุดจะเท่าเดิมก็ตาม ResNet50อีกสองรุ่นเห็นการปรับปรุง 14% ในจำนวนผู้ใช้พร้อมกันที่พวกเขาสามารถรองรับได้ อย่างไรก็ตาม การปรับปรุงประสิทธิภาพของ TensorRT มาจากค่าใช้จ่ายของการใช้หน่วยความจำที่สูงขึ้น ส่งผลให้ MME โหลดโมเดลน้อยลง ผลกระทบมีมากขึ้นสำหรับโมเดลที่ใช้เครือข่ายประสาทเทียม (CNN) ในความเป็นจริง โมเดล ResNet50 ของเราใช้หน่วยความจำ GPU ประมาณสองเท่าตั้งแต่ PyTorch ถึง TensorRT ส่งผลให้โหลดโมเดลน้อยลง 50% (46 เทียบกับ 23) เราจะวิเคราะห์พฤติกรรมนี้เพิ่มเติมในส่วนต่อไปนี้

ผลลัพธ์เกณฑ์มาตรฐานสำหรับโมเดล NLP

สำหรับรุ่น NLP ให้ใช้โน้ตบุ๊ก nlp-benchmark.ipynb เพื่อรันการทดสอบโหลด การตั้งค่าของโน้ตบุ๊กควรมีลักษณะคล้ายกันมาก เราทดสอบโมเดล NLP สองแบบ: bert-base-uncased (109M) และ roberta-large (335M) ทั้งโมเดลที่ผ่านการฝึกอบรมล่วงหน้าและโทเค็นไนเซอร์จะดาวน์โหลดได้จากฮับ Hugging Face และเพย์โหลดทดสอบจะถูกสร้างขึ้นจากโทเค็นไนเซอร์โดยใช้สตริงตัวอย่าง ความยาวลำดับสูงสุดเป็นค่าดีฟอลต์ที่ 128 หากคุณต้องการทดสอบสตริงที่ยาวขึ้น อย่าลืมปรับพารามิเตอร์นั้น การทำงานผ่านโน้ตบุ๊ก NLP จะสร้างการแสดงภาพชุดเดียวกัน: Pytorch (ซ้าย) กับ TensorRT (ขวา)

จากสิ่งเหล่านี้ เราสังเกตเห็นประโยชน์ด้านประสิทธิภาพที่มากขึ้นของ TensorRT สำหรับโมเดล NLP การ roberta-large ตัวอย่างบนอินสแตนซ์ ml.g4dn.2xlarge เวลาแฝงในการอนุมานลดลงอย่างมากจาก 180 มิลลิวินาทีเป็น 56 มิลลิวินาที (เพิ่มขึ้น 70%) ในขณะที่ปริมาณงานเพิ่มขึ้น 406% จาก 33 คำขอต่อวินาทีเป็น 167 นอกจากนี้ จำนวนสูงสุดของการทำงานพร้อมกัน ผู้ใช้เพิ่มขึ้น 50%; ไม่พบคำขอที่ล้มเหลวจนกว่าเราจะเข้าถึงผู้ใช้พร้อมกัน 180 ราย เทียบกับ 120 รายสำหรับรุ่น PyTorch ดั้งเดิม ในแง่ของการใช้หน่วยความจำ เราเห็นโมเดลที่โหลดน้อยลงหนึ่งรุ่นสำหรับ TensorRT (จากเก้ารุ่นเป็นแปดรุ่น) อย่างไรก็ตาม ผลกระทบด้านลบนั้นน้อยกว่ามากเมื่อเทียบกับสิ่งที่เราสังเกตได้จากโมเดลที่อ้างอิงจาก CNN

การวิเคราะห์การใช้งานหน่วยความจำ

ตารางต่อไปนี้แสดงการวิเคราะห์ทั้งหมดเกี่ยวกับผลกระทบจากการใช้หน่วยความจำตั้งแต่ PyTorch ถึง TensorRT เราได้กล่าวไว้ก่อนหน้านี้ว่าโมเดลที่ใช้ CNN ได้รับผลกระทบในทางลบมากกว่า เดอะ ResNet50 โมเดลมีจำนวนโมเดลลดลงกว่า 50% ในอินสแตนซ์ GPU ทั้งสามประเภท Convnext_base มีการลดลงที่มากขึ้นที่ประมาณ 70% ทั่วทั้งกระดาน ในทางกลับกัน ผลกระทบต่อรุ่นหม้อแปลงมีน้อยหรือผสมกัน vit_large_patch16_224 และ roberta-large ลดลงเฉลี่ยประมาณ 20% และ 3% ตามลำดับ ในขณะที่ bert-base-uncased มีการปรับปรุงประมาณ 40%

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

ตารางต่อไปนี้แสดงผลลัพธ์การเปรียบเทียบแบบสมบูรณ์สำหรับเมตริกทั้งหมดในอินสแตนซ์ GPU ทั้งสามประเภท

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

ทำความสะอาด

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

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

สรุป

ในโพสต์นี้ เราได้แชร์ผลการทดสอบและการวิเคราะห์สำหรับโมเดลโครงข่ายประสาทเทียมเชิงลึกต่างๆ ที่ทำงานบนจุดสิ้นสุดหลายโมเดลของ SageMaker พร้อม GPU ผลลัพธ์และข้อมูลเชิงลึกที่เราแชร์ควรให้ส่วนข้ามของประสิทธิภาพที่เหมาะสมในเมตริกและประเภทอินสแตนซ์ต่างๆ ในกระบวนการนี้ เรายังแนะนำวิธีการที่เราแนะนำเพื่อเรียกใช้การทดสอบเกณฑ์มาตรฐานสำหรับ SageMaker MME ด้วย GPU เครื่องมือและโค้ดตัวอย่างที่เราจัดเตรียมไว้สามารถช่วยคุณเริ่มต้นการทดสอบเกณฑ์มาตรฐานได้อย่างรวดเร็ว และตัดสินใจอย่างมีข้อมูลมากขึ้นเกี่ยวกับวิธีโฮสต์โมเดล DNN หลายร้อยรุ่นบนฮาร์ดแวร์ประมวลผลแบบเร่งความเร็วอย่างคุ้มค่า หากต้องการเริ่มต้นการเปรียบเทียบโมเดลของคุณเองด้วยการรองรับ MME สำหรับ GPU โปรดดูที่ อัลกอริทึม เฟรมเวิร์ก และอินสแตนซ์ที่รองรับ และ repo GitHub สำหรับตัวอย่างและเอกสารเพิ่มเติม

เกี่ยวกับผู้แต่ง

เจมส์ หวู่ เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญด้าน AI/ML อาวุโสที่ AWS ช่วยลูกค้าออกแบบและสร้างโซลูชัน AI/ML งานของ James ครอบคลุมกรณีการใช้งาน ML ที่หลากหลาย โดยมีความสนใจหลักในด้านการมองเห็นคอมพิวเตอร์ การเรียนรู้เชิงลึก และการปรับขนาด ML ทั่วทั้งองค์กร ก่อนที่จะร่วมงานกับ AWS เจมส์เคยเป็นสถาปนิก นักพัฒนา และผู้นำด้านเทคโนโลยีมานานกว่า 10 ปี รวมถึง 6 ปีในด้านวิศวกรรมและ 4 ปีในอุตสาหกรรมการตลาดและการโฆษณา

วิกรม เอลังโก เป็นสถาปนิก AI/ML Specialist Solutions Architect ที่ Amazon Web Services ซึ่งตั้งอยู่ในเวอร์จิเนียสหรัฐอเมริกา Vikram ช่วยเหลือลูกค้าในอุตสาหกรรมการเงินและการประกันภัยด้วยการออกแบบ ความเป็นผู้นำทางความคิด เพื่อสร้างและปรับใช้แอปพลิเคชันการเรียนรู้ของเครื่องในวงกว้าง ปัจจุบันเขามุ่งเน้นไปที่การประมวลผลภาษาธรรมชาติ AI ที่รับผิดชอบ การเพิ่มประสิทธิภาพการอนุมาน และการปรับสเกล ML ทั่วทั้งองค์กร ในเวลาว่าง เขาสนุกกับการเดินทาง เดินป่า ทำอาหาร และตั้งแคมป์กับครอบครัว

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

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/