บรรลุประสิทธิภาพระดับไฮเปอร์สเกลสำหรับการให้บริการโมเดลโดยใช้เซิร์ฟเวอร์ NVIDIA Triton Inference บน Amazon SageMaker

แอปพลิเคชันการเรียนรู้ของเครื่อง (ML) นั้นซับซ้อนในการปรับใช้ และมักต้องการโมเดล ML หลายรุ่นเพื่อให้บริการคำขอการอนุมานเดียว คำขอทั่วไปอาจไหลผ่านหลายโมเดลด้วยขั้นตอนต่างๆ เช่น การประมวลผลล่วงหน้า การแปลงข้อมูล ตรรกะการเลือกโมเดล การรวมโมเดล และการประมวลผลภายหลัง สิ่งนี้นำไปสู่วิวัฒนาการของรูปแบบการออกแบบทั่วไป เช่น ไปป์ไลน์การอนุมานแบบอนุกรม ตระการตา (การรวบรวมแบบกระจาย) และเวิร์กโฟลว์ตรรกะทางธุรกิจ ส่งผลให้เวิร์กโฟลว์ทั้งหมดของคำขอเป็น Directed Acyclic Graph (DAG) อย่างไรก็ตาม เนื่องจากเวิร์กโฟลว์มีความซับซ้อนมากขึ้น ส่งผลให้เวลาตอบสนองโดยรวมหรือเวลาแฝงของแอปพลิเคชันเหล่านี้เพิ่มขึ้น ซึ่งจะส่งผลต่อประสบการณ์ของผู้ใช้โดยรวม นอกจากนี้ หากส่วนประกอบเหล่านี้โฮสต์บนอินสแตนซ์ที่แตกต่างกัน เวลาแฝงของเครือข่ายเพิ่มเติมระหว่างอินสแตนซ์เหล่านี้จะเพิ่มเวลาแฝงโดยรวม ลองพิจารณาตัวอย่างกรณีการใช้งาน ML ยอดนิยมสำหรับผู้ช่วยเสมือนในการสนับสนุนลูกค้า คำขอทั่วไปอาจต้องผ่านหลายขั้นตอนที่เกี่ยวข้องกับการรู้จำคำพูด การประมวลผลภาษาธรรมชาติ (NLP) การติดตามสถานะการโต้ตอบ นโยบายการโต้ตอบ การสร้างข้อความ และสุดท้ายข้อความเป็นคำพูด นอกจากนี้ เพื่อให้การโต้ตอบกับผู้ใช้มีความเป็นส่วนตัวมากขึ้น คุณอาจใช้โมเดล NLP ที่ล้ำสมัยและอิงตามหม้อแปลง เช่น รุ่นต่างๆ BERT, BARTและ GPT. ผลลัพธ์ที่ได้คือเวลาตอบสนองที่ยาวนานสำหรับชุดโมเดลเหล่านี้และประสบการณ์ของลูกค้าที่ไม่ดี

รูปแบบทั่วไปในการขับเคลื่อนเวลาตอบสนองที่ลดลงโดยไม่กระทบต่อปริมาณงานโดยรวม คือการโฮสต์โมเดลเหล่านี้ในอินสแตนซ์เดียวกันพร้อมกับตรรกะทางธุรกิจแบบเบาที่ฝังอยู่ในนั้น โมเดลเหล่านี้สามารถห่อหุ้มเพิ่มเติมได้ภายในคอนเทนเนอร์เดียวหรือหลายคอนเทนเนอร์บนอินสแตนซ์เดียวกัน เพื่อให้มีการแยกสำหรับกระบวนการที่ทำงานอยู่และให้เวลาแฝงต่ำ นอกจากนี้ เวลาแฝงโดยรวมยังขึ้นอยู่กับตรรกะของแอปพลิเคชันการอนุมาน การปรับโมเดลให้เหมาะสม โครงสร้างพื้นฐานพื้นฐาน (รวมถึงการประมวลผล ที่เก็บข้อมูล และเครือข่าย) และเว็บเซิร์ฟเวอร์พื้นฐานที่รับคำขอการอนุมาน เซิร์ฟเวอร์การอนุมาน NVIDIA Triton เป็นซอฟต์แวร์การอนุมานแบบโอเพนซอร์ซที่มีคุณลักษณะเพื่อเพิ่มปริมาณงานและการใช้ฮาร์ดแวร์ให้เกิดประโยชน์สูงสุดด้วยเวลาแฝงในการอนุมานที่ต่ำมาก (มิลลิวินาทีหลักเดียว) มีการรองรับเฟรมเวิร์ก ML อย่างกว้างขวาง (รวมถึง TensorFlow, PyTorch, ONNX, XGBoost และ NVIDIA TensorRT) และแบ็กเอนด์โครงสร้างพื้นฐาน รวมถึง GPU, CPU และ การอนุมาน AWS. นอกจากนี้ Triton Inference Server ยังรวมเข้ากับ อเมซอน SageMakerซึ่งเป็นบริการ ML แบบ end-to-end ที่มีการจัดการเต็มรูปแบบ โดยมีตัวเลือกการอนุมานตามเวลาจริง รวมถึง เดียว และ หลายรุ่น โฮสติ้ง ตัวเลือกการอนุมานเหล่านี้รวมถึงการโฮสต์หลายรุ่นภายในคอนเทนเนอร์เดียวกันหลังa ปลายทางเดียวและโฮสติ้ง หลายรุ่นพร้อมหลายคอนเทนเนอร์ ที่อยู่เบื้องหลังจุดสิ้นสุดเพียงจุดเดียว

ในเดือนพฤศจิกายน พ.ศ. 2021 เราได้ประกาศ การรวม Triton Inference Server บน SageMaker. AWS ทำงานอย่างใกล้ชิดกับ NVIDIA เพื่อให้คุณได้รับสิ่งที่ดีที่สุดจากทั้งสองโลกและทำให้การปรับใช้โมเดลด้วย Triton บน AWS ง่ายขึ้น

ในโพสต์นี้ เรามาดูแนวทางปฏิบัติที่ดีที่สุดสำหรับการปรับใช้โมเดลหม้อแปลงตามขนาดบน GPU โดยใช้เซิร์ฟเวอร์ Triton Inference บน SageMaker อันดับแรก เราเริ่มต้นด้วยการสรุปแนวคิดหลักเกี่ยวกับเวลาแฝงใน SageMaker และภาพรวมของแนวทางการปรับแต่งประสิทธิภาพ ต่อไป เราจะให้ภาพรวมของ Triton และคุณลักษณะต่างๆ รวมทั้งโค้ดตัวอย่างสำหรับการปรับใช้บน SageMaker สุดท้าย เราทำการทดสอบโหลดโดยใช้ ผู้แนะนำการอนุมาน SageMaker และสรุปข้อมูลเชิงลึกและข้อสรุปจากการทดสอบโหลดของหม้อแปลงไฟฟ้ารุ่นยอดนิยมที่จัดทำโดย Hugging Face

คุณสามารถตรวจสอบ สมุดบันทึก เราเคยปรับใช้โมเดลและทำการทดสอบโหลดด้วยตัวคุณเองโดยใช้รหัส on GitHub.

การปรับแต่งประสิทธิภาพและการปรับให้เหมาะสมสำหรับการแสดงโมเดลบน SageMaker

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

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

การอนุมานตามเวลาจริงและเวลาแฝงใน SageMaker

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

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

ไดอะแกรมต่อไปนี้แสดงส่วนประกอบเหล่านี้

เวลาแฝงของคอนเทนเนอร์ขึ้นอยู่กับปัจจัยหลายประการ ต่อไปนี้เป็นสิ่งสำคัญที่สุด:

• โปรโตคอลพื้นฐาน (HTTP/gRPC) ที่ใช้ในการสื่อสารกับเซิร์ฟเวอร์การอนุมาน
• ค่าใช้จ่ายที่เกี่ยวข้องกับการสร้างการเชื่อมต่อ TLS ใหม่
• เวลาดีซีเรียลไลเซชันของเพย์โหลดคำขอ/การตอบสนอง
• ขอคุณสมบัติการจัดคิวและการจัดชุดที่จัดเตรียมโดยเซิร์ฟเวอร์การอนุมานพื้นฐาน
• ขอความสามารถในการจัดตารางเวลาโดยเซิร์ฟเวอร์อนุมานพื้นฐาน
• ประสิทธิภาพรันไทม์พื้นฐานของเซิร์ฟเวอร์การอนุมาน
• ประสิทธิภาพของไลบรารีพรีโพรเซสซิงและโพรเซสซิงก่อนเรียกใช้ฟังก์ชันการคาดคะเนโมเดล
• ประสิทธิภาพแบ็กเอนด์ของเฟรมเวิร์ก ML พื้นฐาน
• การเพิ่มประสิทธิภาพเฉพาะรุ่นและเฉพาะฮาร์ดแวร์

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

ภาพรวมกรณีใช้งาน

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

ในโพสต์นี้ เราเปรียบเทียบกรณีการใช้งาน NLP โดยใช้จุดปลายแบบเรียลไทม์ของ SageMaker โดยอิงตามคอนเทนเนอร์เซิร์ฟเวอร์ Triton Inference และแนะนำการปรับแต่งประสิทธิภาพสำหรับกรณีการใช้งาน ML ของเรา เราใช้ Hugging Face ขนาดใหญ่ที่มีหม้อแปลงไฟฟ้าที่ผ่านการฝึกอบรมมาแล้ว BERT ขนาดใหญ่ uncased รุ่นซึ่งมีพารามิเตอร์แบบจำลองประมาณ 336 ล้านชุด ประโยคอินพุตที่ใช้สำหรับโมเดลการจำแนกไบนารีนั้นถูกเสริมและตัดให้มีความยาวลำดับอินพุตสูงสุด 512 โทเค็น การทดสอบโหลดการอนุมานจำลองการเรียกใช้ 500 ครั้งต่อวินาที (การเรียกใช้สูงสุด 30,000 ครั้งต่อนาที) และ ModelLatency น้อยกว่า 0.5 วินาที (500 มิลลิวินาที)

ตารางต่อไปนี้สรุปการกำหนดค่าเกณฑ์มาตรฐานของเรา

เซิร์ฟเวอร์การอนุมาน NVIDIA Triton

Triton Inference Server ได้รับการออกแบบมาโดยเฉพาะเพื่อให้สามารถปรับใช้โมเดลในการผลิตที่ปรับขนาดได้ รวดเร็ว และง่ายดาย Triton รองรับเฟรมเวิร์ก AI หลักๆ ที่หลากหลาย รวมถึง TensorFlow, TensorRT, PyTorch, XGBoost และ ONNX ด้วยแบ็กเอนด์ที่กำหนดเองของ Python และ C++ คุณยังสามารถใช้ปริมาณงานการอนุมานสำหรับกรณีการใช้งานที่กำหนดเองได้มากขึ้น

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

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

การแบ่งกลุ่มแบบไดนามิก

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

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

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

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

รุ่นวิ่งพร้อมกัน

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

รูปต่อไปนี้แสดงวิธีที่คุณสามารถกำหนดค่านโยบายการปรับใช้โมเดลต่างๆ ได้อย่างง่ายดายโดยมีการเปลี่ยนแปลงโค้ดเพียงไม่กี่บรรทัด ตัวอย่างเช่น การกำหนดค่า A (ซ้าย) แสดงว่าคุณสามารถแพร่ภาพการกำหนดค่าเดียวกันของอินสแตนซ์รุ่นสองของ bert-large-uncased ไปยัง GPU ที่มีอยู่ทั้งหมด ในทางตรงกันข้าม การกำหนดค่า B (ตรงกลาง) แสดงการกำหนดค่าที่แตกต่างกันสำหรับ GPU 0 เท่านั้น โดยไม่เปลี่ยนแปลงนโยบายของ GPU อื่นๆ คุณยังสามารถปรับใช้อินสแตนซ์ของรุ่นต่างๆ บน GPU เดียวได้ดังที่แสดงในการกำหนดค่า C (ขวา)

ในการกำหนดค่า C อินสแตนซ์การประมวลผลสามารถจัดการคำขอสองรายการพร้อมกันสำหรับรุ่น DistilGPT-2 และคำขอพร้อมกันเจ็ดรายการสำหรับ bert-large-uncased แบบคู่ขนานกัน ด้วยการเพิ่มประสิทธิภาพเหล่านี้ ทรัพยากรฮาร์ดแวร์สามารถนำมาใช้ได้ดีขึ้นสำหรับกระบวนการให้บริการ ซึ่งจะช่วยปรับปรุงปริมาณงานและให้ประสิทธิภาพด้านต้นทุนที่ดีขึ้นสำหรับปริมาณงานของคุณ

เทนเซอร์RT

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

TensorRT ปรับกราฟให้เหมาะสมเพื่อลดรอยเท้าของหน่วยความจำด้วยการเพิ่มหน่วยความจำที่ไม่จำเป็นและนำกลับมาใช้ใหม่ได้อย่างมีประสิทธิภาพ นอกจากนี้ การคอมไพล์ TensorRT ยังรวมการดำเนินการแบบกระจายภายในกราฟแบบจำลองเพื่อสร้างเคอร์เนลที่ใหญ่ขึ้นเพื่อหลีกเลี่ยงโอเวอร์เฮดของการเปิดเคอร์เนลขนาดเล็กหลายรายการ การปรับเคอร์เนลอัตโนมัติช่วยให้คุณใช้ฮาร์ดแวร์ได้อย่างเต็มที่โดยการเลือกอัลกอริธึมที่ดีที่สุดบน GPU เป้าหมายของคุณ สตรีม CUDA ช่วยให้โมเดลสามารถทำงานแบบคู่ขนานเพื่อเพิ่มการใช้ประโยชน์ GPU ของคุณให้สูงสุดเพื่อประสิทธิภาพที่ดีที่สุด สุดท้ายแต่ไม่ท้ายสุด เทคนิคการหาปริมาณสามารถใช้การเร่งความเร็วแบบผสมความแม่นยำของแกนเทนเซอร์เพื่อเรียกใช้โมเดลใน FP32, TF32, FP16 และ INT8 เพื่อให้ได้ประสิทธิภาพการอนุมานที่ดีที่สุด

Triton บนโฮสติ้ง SageMaker

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

ภายใต้ร่มที่โฮสต์ SageMaker นั้นยังมีชุดของ SageMaker inference Deep Learning Containers (DLC) ซึ่งมาพร้อมกับซอฟต์แวร์เซิร์ฟเวอร์รุ่นที่เหมาะสมล่วงหน้าสำหรับเฟรมเวิร์ก ML ที่เกี่ยวข้อง สิ่งนี้ช่วยให้คุณบรรลุประสิทธิภาพการอนุมานสูงโดยไม่ต้องตั้งค่าเซิร์ฟเวอร์โมเดล ซึ่งมักจะเป็นลักษณะทางเทคนิคที่ซับซ้อนที่สุดของการปรับใช้โมเดล และโดยทั่วไปไม่ได้เป็นส่วนหนึ่งของชุดทักษะของนักวิทยาศาสตร์ข้อมูล เซิฟเวอร์การอนุมานไทรทันอยู่ในขณะนี้ ใช้ได้ บนคอนเทนเนอร์การเรียนรู้เชิงลึกของ SageMaker (DLC).

ตัวเลือกที่หลากหลาย ความเป็นโมดูล และความสะดวกในการใช้งานเฟรมเวิร์กการให้บริการต่างๆ ทำให้ SageMaker และ Triton เป็นคู่หูที่ทรงพลัง

SageMaker Inference Recommender สำหรับผลการทดสอบการเปรียบเทียบ

เราใช้ SageMaker Inference Recommender เพื่อเรียกใช้การทดลองของเรา SageMaker Inference Recommender มีงานสองประเภท: ค่าเริ่มต้นและขั้นสูง ดังแสดงในแผนภาพต่อไปนี้

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

งานขั้นสูงมีการควบคุมเพิ่มเติมเพื่อปรับแต่งประสิทธิภาพเพิ่มเติม การควบคุมเหล่านี้จำลองสภาพแวดล้อมจริงและข้อกำหนดด้านการผลิต ในบรรดาการควบคุมเหล่านี้คือรูปแบบการรับส่งข้อมูลซึ่งมีจุดมุ่งหมายเพื่อกำหนดรูปแบบคำขอสำหรับการวัดประสิทธิภาพ คุณสามารถตั้งค่าทางลาดหรือการจราจรคงที่ได้โดยใช้หลายเฟสของรูปแบบการจราจร ตัวอย่างเช่น an จำนวนผู้ใช้เริ่มต้น จาก 1 อัตราการเกิด ของปี 1 และ ระยะเวลาในวินาที 600 อาจส่งผลให้การจราจรทางลาด 10 นาทีโดยมีผู้ใช้พร้อมกัน 1 คนในตอนเริ่มต้นและ 10 คนในตอนท้าย นอกจากนี้ ในการควบคุม MaxInvocations และ โมเดล LatencyThresholds กำหนดเกณฑ์การผลิต ดังนั้นเมื่อเกินเกณฑ์ใดเกณฑ์หนึ่ง การเปรียบเทียบจะหยุดลง

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

เราใช้ประเภทงานขั้นสูงของ SageMaker Inference Recommender เพื่อเรียกใช้การทดสอบของเราเพื่อควบคุมรูปแบบการรับส่งข้อมูลเพิ่มเติม และปรับแต่งการกำหนดค่าของคอนเทนเนอร์ที่แสดง

ตั้งค่าการทดลอง

เราใช้คุณสมบัติการทดสอบโหลดแบบกำหนดเองของ SageMaker Inference Recommender เพื่อเปรียบเทียบโปรไฟล์ NLP ที่ระบุไว้ในกรณีการใช้งานของเรา อันดับแรก เรากำหนดข้อกำหนดเบื้องต้นต่อไปนี้ที่เกี่ยวข้องกับแบบจำลอง NLP และงาน ML ผู้แนะนำการอนุมาน SageMaker ใช้ข้อมูลนี้เพื่อดึงอิมเมจ Docker การอนุมานจาก การลงทะเบียน Amazon Elastic Container (Amazon ECR) และลงทะเบียนโมเดลด้วยการลงทะเบียนรุ่น SageMaker

การกำหนดค่ารูปแบบการรับส่งข้อมูลใน SageMaker Inference Recommender ช่วยให้เรากำหนดเฟสต่างๆ สำหรับการทดสอบโหลดแบบกำหนดเองได้ การทดสอบโหลดเริ่มต้นด้วยผู้ใช้เริ่มต้นสองคน และสร้างผู้ใช้ใหม่สองคนทุกนาที เป็นระยะเวลารวม 25 นาที (1500 วินาที) ดังแสดงในโค้ดต่อไปนี้:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

เราทดสอบด้วยการทดสอบโหลดแบบจำลองเดียวกันในสองสถานะที่แตกต่างกัน การทดลองที่ใช้ PyTorch ใช้แบบจำลอง PyTorch มาตรฐานที่ไม่เปลี่ยนแปลง สำหรับการทดลองที่ใช้ TensorRT เราจะแปลงโมเดล PyTorch เป็นเอ็นจิ้น TensorRT ล่วงหน้า

เราใช้การผสมผสานคุณลักษณะการเพิ่มประสิทธิภาพประสิทธิภาพการทำงานที่แตกต่างกันในสองรุ่นนี้ สรุปไว้ในตารางต่อไปนี้

ผลการทดสอบและการสังเกต

เราทำการทดสอบโหลดสำหรับอินสแตนซ์สามประเภทภายในกลุ่ม g4dn เดียวกัน: ml.g4dn.xlarge, ml.g4dn.2xlarge และ ml.g4dn.12xlarge อินสแตนซ์ g4dn ทุกประเภทมีสิทธิ์เข้าถึง NVIDIA T4 Tensor Core GPU และโปรเซสเซอร์ Intel Cascade Lake รุ่นที่ 2 ตรรกะเบื้องหลังการเลือกประเภทอินสแตนซ์คือการมีทั้งอินสแตนซ์ที่มี GPU เพียงตัวเดียว และอินสแตนซ์ที่มีสิทธิ์เข้าถึง GPU หลายตัว—สี่ตัวในกรณีของ ml.g4dn.12xlarge นอกจากนี้ เราต้องการทดสอบว่าการเพิ่มความจุ vCPU บนอินสแตนซ์ด้วย GPU ที่มีอยู่เพียงตัวเดียวจะทำให้อัตราส่วนต้นทุนต่อประสิทธิภาพดีขึ้นหรือไม่

มาดูการเร่งความเร็วของการเพิ่มประสิทธิภาพแต่ละรายการกันก่อน กราฟต่อไปนี้แสดงให้เห็นว่าการเพิ่มประสิทธิภาพ TensorRT ช่วยลดเวลาในการตอบสนองของโมเดลลง 50% เมื่อเทียบกับโมเดลดั้งเดิมใน PyTorch บนอินสแตนซ์ ml.g4dn.xlarge การลดเวลาในการตอบสนองนี้เพิ่มขึ้นมากกว่าสามเท่าในอินสแตนซ์ multi-GPU ของ ml.g4dn.12xlarge ในขณะเดียวกัน การปรับปรุงปริมาณงาน 30% นั้นสอดคล้องกันในทั้งสองกรณี ส่งผลให้มีความคุ้มค่ามากขึ้นหลังจากใช้การปรับให้เหมาะสม TensorRT

ด้วยการแบ่งกลุ่มแบบไดนามิก เราจึงสามารถปรับปรุงปริมาณงานให้ดีขึ้นเกือบ 2 เท่าโดยใช้สถาปัตยกรรมฮาร์ดแวร์เดียวกันบนอินสแตนซ์การทดลองทั้งหมดของ ml.g4dn.xlarge, ml.g4dn.2xlarge และ ml.g4dn.12xlarge โดยไม่เพิ่มเวลาในการตอบสนองอย่างเห็นได้ชัด

ในทำนองเดียวกัน การดำเนินการโมเดลพร้อมกันทำให้เราได้รับการปรับปรุง 3-4x ในการรับส่งข้อมูลโดยเพิ่มการใช้ GPU สูงสุดบนอินสแตนซ์ ml.g4dn.xlarge และการปรับปรุงประมาณ 2 เท่าบนทั้งอินสแตนซ์ ml.g4dn.2xlarge และอินสแตนซ์ multi-GPU ของ ml g4dn.12xlarge.. การเพิ่มทรูพุตนี้มาโดยไม่มีโอเวอร์เฮดใดๆ ในเรื่องเวลาในการตอบสนอง

ยังดีกว่า เราสามารถรวมการเพิ่มประสิทธิภาพทั้งหมดเหล่านี้เพื่อมอบประสิทธิภาพที่ดีที่สุดโดยใช้ทรัพยากรฮาร์ดแวร์ให้เกิดประโยชน์สูงสุด ตารางและกราฟต่อไปนี้สรุปผลลัพธ์ที่เราได้รับในการทดลองของเรา

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

[2] ค่าใช้จ่ายต่อชั่วโมงในตารางด้านบนคำนวณจากจำนวนอินสแตนซ์เริ่มต้นและราคาสำหรับประเภทอินสแตนซ์

ผลลัพธ์ส่วนใหญ่จะตรวจสอบผลกระทบที่คาดหวังจากคุณลักษณะการปรับประสิทธิภาพให้เหมาะสมที่แตกต่างกัน:

• การรวบรวม TensorRT มีผลกระทบที่น่าเชื่อถือที่สุดในอินสแตนซ์ทุกประเภท ธุรกรรมต่อนาทีต่ออินสแตนซ์เพิ่มขึ้น 30–35% โดยมีการลดต้นทุนอย่างสม่ำเสมอประมาณ 25% เมื่อเทียบกับประสิทธิภาพของเอ็นจิ้น TensorRT กับค่าเริ่มต้น PyTorch BERT (pt-base). ประสิทธิภาพที่เพิ่มขึ้นของเอ็นจิ้น TensorRT นั้นถูกรวมและใช้ประโยชน์โดยคุณสมบัติการปรับแต่งประสิทธิภาพที่ผ่านการทดสอบอื่นๆ
• การโหลดสองรุ่นในแต่ละ GPU (กลุ่มอินสแตนซ์) ทำให้เมตริกที่วัดได้ทั้งหมดเกือบสองเท่า การเรียกใช้ต่อนาทีต่ออินสแตนซ์เพิ่มขึ้นประมาณ 80–90% ทำให้ลดต้นทุนได้ในช่วง 50% ราวกับว่าเราใช้ GPU สองตัว ในความเป็นจริง, อเมซอน คลาวด์วอตช์ เมตริกสำหรับการทดลองของเราใน g4dn.2xlarge (ตามตัวอย่าง) ยืนยันว่าทั้งการใช้ CPU และ GPU เป็นสองเท่าเมื่อเรากำหนดค่ากลุ่มอินสแตนซ์ของสองรุ่น

คำแนะนำด้านประสิทธิภาพและการเพิ่มประสิทธิภาพต้นทุนเพิ่มเติม

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

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

เราคาดว่าจะทดสอบและเปรียบเทียบเทคนิคและฟีเจอร์เหล่านี้ในโพสต์ในอนาคต โปรดคอยติดตาม!

สรุป

ในโพสต์นี้ เราได้สำรวจพารามิเตอร์สองสามตัวที่คุณสามารถใช้เพื่อเพิ่มประสิทธิภาพของอุปกรณ์ปลายทางแบบเรียลไทม์ของ SageMaker สำหรับให้บริการโมเดล PyTorch BERT ด้วยเซิร์ฟเวอร์ Triton Inference เราใช้ SageMaker Inference Recommender เพื่อทำการทดสอบการเปรียบเทียบเพื่อปรับแต่งพารามิเตอร์เหล่านี้อย่างละเอียด พารามิเตอร์เหล่านี้มีสาระสำคัญที่เกี่ยวข้องกับการเพิ่มประสิทธิภาพแบบจำลองตาม TensorRT ซึ่งนำไปสู่การปรับปรุงเวลาตอบสนองเกือบ 50% เมื่อเทียบกับเวอร์ชันที่ไม่ได้รับการปรับให้เหมาะสม นอกจากนี้ การรันโมเดลพร้อมกันและการใช้แบตช์แบบไดนามิกของ Triton ทำให้ปริมาณงานเพิ่มขึ้นเกือบ 70% การปรับพารามิเตอร์เหล่านี้อย่างละเอียดทำให้ต้นทุนการอนุมานโดยรวมลดลงด้วย

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

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

คุณสามารถค้นหาโน้ตบุ๊กที่ใช้สำหรับการทดสอบโหลดและปรับใช้ได้ที่ GitHub. คุณสามารถอัปเดตการกำหนดค่า Triton และการตั้งค่า SageMaker Inference Recommender ให้เหมาะสมกับกรณีการใช้งานของคุณมากที่สุด เพื่อให้ได้ปริมาณงานการอนุมานที่คุ้มค่าและทำงานได้ดีที่สุด

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

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

ชูเอา มูร่า เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญ AI/ML ที่ Amazon Web Services เขาเน้นที่กรณีการใช้งาน NLP เป็นหลักและช่วยลูกค้าเพิ่มประสิทธิภาพการฝึกอบรมและการปรับใช้โมเดล Deep Learning เขายังเป็นผู้สนับสนุนโซลูชัน ML แบบ low-code และฮาร์ดแวร์เฉพาะสำหรับ ML

โมฮัน คานธี เป็นวิศวกรซอฟต์แวร์อาวุโสที่ AWS เขาทำงานกับ AWS มาตลอด 9 ปีที่ผ่านมาและเคยทำงานเกี่ยวกับบริการต่างๆ ของ AWS เช่น EMR, EFA และ RDS บน Outpost ปัจจุบันเขามุ่งเน้นไปที่การปรับปรุงประสบการณ์การอนุมานของ SageMaker ในเวลาว่าง เขาชอบเดินป่าและวิ่งมาราธอน

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

สันทศ ภวานี เป็นผู้จัดการผลิตภัณฑ์ด้านเทคนิคอาวุโสกับทีม Amazon SageMaker Elastic Inference เขามุ่งเน้นที่การช่วยเหลือลูกค้า SageMaker เร่งการอนุมานและปรับใช้โมเดล ในเวลาว่าง เขาสนุกกับการเดินทาง เล่นเทนนิส และดื่มชาผู่เอ๋อมากมาย

เจียหงหลิว เป็น Solution Architect ในทีม Cloud Service Provider ที่ NVIDIA เขาช่วยลูกค้าในการใช้การเรียนรู้ด้วยเครื่องและโซลูชัน AI ที่ใช้ประโยชน์จากการประมวลผลแบบเร่งความเร็วของ NVIDIA เพื่อจัดการกับความท้าทายในการฝึกอบรมและการอนุมาน ในยามว่าง เขาสนุกกับการพับกระดาษ โปรเจกต์ทำเอง และเล่นบาสเก็ตบอล

• คอยน์สมาร์ท การแลกเปลี่ยน Bitcoin และ Crypto ที่ดีที่สุดในยุโรป
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าฟรี
• คริปโตฮอว์ก เรดาร์ Altcoin ทดลองฟรี.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/