چگونه Sportradar از کتابخانه Deep Java برای ساخت پلتفرم های ML در مقیاس تولید برای افزایش کارایی و کارایی استفاده کرد.

این یک پست مهمان است که با فرد وو از Sportradar نوشته شده است.

اسپرتردار شرکت پیشرو در زمینه فناوری ورزشی در جهان است که در تقاطع بین ورزش، رسانه و شرط بندی قرار دارد. بیش از 1,700 فدراسیون ورزشی، رسانه‌ها، اپراتورهای شرط‌بندی، و پلتفرم‌های مصرف‌کننده در 120 کشور جهان برای تقویت تجارت خود به دانش و فناوری Sportradar متکی هستند.

Sportradar از داده ها و فناوری برای موارد زیر استفاده می کند:

• اپراتورهای شرط بندی را با محصولات و خدماتی که برای مدیریت کتاب ورزشی خود به آن نیاز دارند، جلوتر نگه دارید
• به شرکت های رسانه ای ابزاری برای تعامل بیشتر با طرفداران بدهید
• به تیم‌ها، لیگ‌ها و فدراسیون‌ها داده‌هایی بدهید که برای پیشرفت نیاز دارند
• با کشف و جلوگیری از تقلب، دوپینگ و تثبیت مسابقات، صنعت را تمیز نگه دارید

این پست نشان می دهد که چگونه اسپرتردار از آمازون استفاده کرد کتابخانه عمیق جاوا (DJL) در AWS در کنار سرویس الاستیک کوبرنتز آمازون (Amazon EKS) و سرویس ذخیره سازی ساده آمازون (Amazon S3) برای ساخت راه حل استنتاج یادگیری ماشینی آماده برای تولید (ML) که ابزارهای ضروری را در جاوا حفظ می کند، کارایی عملیاتی را بهینه می کند و بهره وری تیم را با ارائه عملکرد و دسترسی بهتر به گزارش ها و معیارهای سیستم افزایش می دهد.

DJL یک چارچوب یادگیری عمیق است که از ابتدا برای پشتیبانی از کاربران جاوا و زبان های JVM مانند Scala، Kotlin و Clojure ساخته شده است. در حال حاضر، اکثر چارچوب‌های یادگیری عمیق برای پایتون ساخته شده‌اند، اما این امر تعداد زیادی از توسعه‌دهندگان و توسعه‌دهندگان جاوا را که پایگاه‌های کد جاوای موجود دارند و می‌خواهند قابلیت‌های قدرتمند یادگیری عمیق را در آن ادغام کنند، نادیده می‌گیرد. با DJL، ادغام این یادگیری عمیق ساده است.

در این پست، تیم Sportradar در مورد چالش‌هایی که با آن مواجه شده‌اند و راه‌حل‌هایی که برای ساختن پلتفرم استنتاج مدل خود با استفاده از DJL ایجاد کرده‌اند، بحث می‌کند.

الزامات تجاری

ما تیم ایالات متحده در بخش هوش مصنوعی Sportradar هستیم. از سال 2018، تیم ما در حال توسعه انواع مدل های ML برای فعال کردن محصولات شرط بندی برای فوتبال NFL و NCAA است. ما اخیراً چهار مدل جدید دیگر را توسعه داده ایم.

چهارمین مدل تصمیم گیری پایین برای NFL و NCAA احتمالات نتیجه بازی پایین چهارم را پیش بینی می کند. نتیجه بازی می تواند تلاش برای گلزنی، بازی، یا پونت باشد.

مدل‌های نتیجه درایو برای NFL و NCAA احتمالات نتیجه درایو فعلی را پیش‌بینی می‌کنند. یک نتیجه درایو می تواند پایان نیمه، تلاش برای گل میدانی، تاچ داون، برگرداندن، برگرداندن روی نزول یا پونت باشد.

مدل‌های ما بلوک‌های سازنده مدل‌های دیگر هستند که در آن فهرستی از بازارهای شرط‌بندی زنده را تولید می‌کنیم، شامل اسپرد، کل، احتمال برد، نوع امتیاز بعدی، تیم بعدی که امتیاز می‌گیرد و موارد دیگر.

الزامات تجاری برای مدل های ما به شرح زیر است:

• پیش‌بینی‌کننده مدل باید بتواند فایل مدل از قبل آموزش‌دیده‌شده را یک بار بارگذاری کند، سپس در بسیاری از بازی‌ها پیش‌بینی کند.
• ما باید احتمالات را برای هر بازی با تاخیر 50 میلی ثانیه ایجاد کنیم
• پیش بینی کننده مدل (استخراج ویژگی و استنتاج مدل) باید در جاوا نوشته شود تا تیم دیگر بتواند آن را به عنوان وابستگی Maven وارد کند.

چالش ها با سیستم در محل

چالش اصلی ما این است که چگونه شکاف بین آموزش مدل در پایتون و استنتاج مدل در جاوا را پر کنیم. دانشمندان داده ما با استفاده از ابزارهایی مانند PyTorch مدل را در Python آموزش می دهند و مدل را به عنوان اسکریپت PyTorch ذخیره می کنند. برنامه اولیه ما این بود که مدل ها را در پایتون نیز میزبانی کنیم و از gRPC برای برقراری ارتباط با سرویس دیگری استفاده کنیم که از سرویس گیرنده gRPC جاوا برای ارسال درخواست استفاده می کند.

با این حال، چند مشکل با این راه حل به وجود آمد. به طور عمده، ما شاهد سربار شبکه بین دو سرویس مختلف بودیم که در محیط‌های اجرا یا پادهای جداگانه اجرا می‌شدند که منجر به تأخیر بالاتری شد. اما سربار تعمیر و نگهداری دلیل اصلی کنار گذاشتن این راه حل بود. ما مجبور شدیم هم سرور gRPC و هم برنامه کلاینت را جداگانه بسازیم و فایل های بافر پروتکل را ثابت و به روز نگه داریم. سپس باید برنامه را Dockerize کنیم، یک فایل YAML استقرار بنویسیم، سرور gRPC را در خوشه Kubernetes خود مستقر کنیم، و مطمئن شویم که قابل اعتماد و مقیاس پذیر است.

مشکل دیگر این بود که هر زمان خطایی در سمت سرور gRPC رخ می داد، سرویس گیرنده برنامه فقط یک پیام خطا مبهم به جای ردیابی دقیق خطا دریافت می کرد. کلاینت باید با نگهدارنده سرور gRPC تماس می گرفت تا دقیقا متوجه شود کدام قسمت از کد باعث خطا شده است.

در حالت ایده‌آل، در عوض می‌خواهیم اسکریپت‌های PyTorch مدل را بارگیری کنیم، ویژگی‌ها را از ورودی مدل استخراج کنیم و استنتاج مدل را به طور کامل در جاوا اجرا کنیم. سپس می‌توانیم آن را به‌عنوان یک کتابخانه Maven که در رجیستری داخلی ما میزبانی می‌شود، بسازیم و منتشر کنیم، که تیم خدمات ما می‌تواند آن را در پروژه‌های جاوا خود وارد کند. وقتی تحقیقات خود را به صورت آنلاین انجام دادیم، کتابخانه جاوا عمیق در بالای صفحه ظاهر شد. پس از خواندن چند پست وبلاگ و اسناد رسمی DJL، مطمئن بودیم که DJL بهترین راه حل را برای مشکل ما ارائه می دهد.

بررسی اجمالی راه حل

نمودار زیر معماری قبلی و به روز شده را مقایسه می کند.

نمودار زیر روند کار راه حل DJL را نشان می دهد.

مراحل زیر است:

1. آموزش مدل ها - دانشمندان داده ما مدل ها را با استفاده از PyTorch آموزش می دهند و مدل ها را به عنوان اسکریپت مشعل ذخیره می کنند. این مدل‌ها سپس به یک فشار داده می‌شوند سرویس ذخیره سازی ساده آمازون سطل (Amazon S3) با استفاده از DVC، یک ابزار کنترل نسخه برای مدل‌های ML.
2. پیاده سازی استخراج ویژگی و تغذیه ویژگی های ML - تیم چارچوب، مدل‌ها را از آمازون S3 به یک مخزن جاوا می‌کشد، جایی که استخراج ویژگی‌ها را پیاده‌سازی می‌کنند و ویژگی‌های ML را به پیش‌بینی‌کننده تغذیه می‌کنند. آنها از موتور DJL PyTorch برای مقداردهی اولیه پیش بینی کننده مدل استفاده می کنند.
3. بسته بندی و انتشار کد و مدل های استنتاج – خط لوله GitLab CI/CD فایل JAR را که حاوی کد استنتاج و مدل‌ها است را در یک رجیستری داخلی Apache Archiva منتشر می‌کند.
4. وارد کردن کتابخانه استنتاج و برقراری تماس – مشتری جاوا کتابخانه استنتاج را به عنوان وابستگی Maven وارد می کند. همه فراخوانی‌های استنتاج از طریق فراخوانی تابع جاوا در همان غلاف Kubernetes انجام می‌شوند. از آنجایی که هیچ تماس gRPC وجود ندارد، زمان پاسخ استنباط بهبود یافته است. علاوه بر این، کلاینت جاوا می تواند در صورت نیاز به راحتی کتابخانه استنتاج را به نسخه قبلی برگرداند. در مقابل، خطای سمت سرور برای سمت کلاینت در راه حل های مبتنی بر gRPC شفاف نیست و ردیابی خطا را دشوار می کند.

ما شاهد زمان اجرا استنتاج پایدار و نتایج پیش‌بینی قابل اعتماد هستیم. راه حل DJL چندین مزیت را نسبت به راه حل های مبتنی بر gRPC ارائه می دهد:

• بهبود زمان پاسخگویی - بدون تماس های gRPC، زمان پاسخ استنباط بهبود می یابد
• بازگشت و ارتقاء آسان – مشتری جاوا می تواند به راحتی کتابخانه استنتاج را به نسخه قبلی برگرداند یا به نسخه جدید ارتقا دهد
• ردیابی خطای شفاف - در راه حل DJL، مشتری می تواند در صورت استنباط خطا، پیام های پیگیری دقیق خطا را دریافت کند.

نمای کلی کتابخانه عمیق جاوا

DJL یک چارچوب یادگیری عمیق کامل است که از چرخه زندگی یادگیری عمیق از ساخت یک مدل، آموزش آن بر روی یک مجموعه داده تا به کارگیری آن در تولید پشتیبانی می کند. دارای کمک‌ها و ابزارهای بصری برای روش‌هایی مانند بینایی رایانه، پردازش زبان طبیعی، صدا، سری‌های زمانی و داده‌های جدولی است. DJL همچنین دارای یک باغ وحش مدل آسان متشکل از صدها مدل از پیش آموزش دیده است که می توانند خارج از جعبه استفاده شوند و در سیستم های موجود ادغام شوند.

همچنین یک پروژه منبع باز با مجوز کامل آپاچی 2 و می توان در GitHub پیدا کرد. DJL در آمازون ایجاد شد و در سال 2019 منبع باز شد. امروزه، جامعه منبع باز DJL توسط آمازون رهبری می شود و به گونه ای رشد کرده است که بسیاری از کشورها، شرکت ها و موسسات آموزشی را شامل می شود. DJL در توانایی خود برای پشتیبانی از سخت افزارها، مدل ها و موتورهای مختلف به رشد خود ادامه می دهد. همچنین شامل پشتیبانی از سخت افزار جدید مانند ARM (هر دو در سرورهایی مانند AWS Graviton و لپ تاپ با اپل M1) و استنتاج AWS.

معماری DJL موتور آگنوستیک است. هدف آن این است که رابطی باشد که توصیف کند یادگیری عمیق در زبان جاوا چگونه است، اما فضایی را برای چندین پیاده سازی مختلف که می توانند قابلیت ها یا پشتیبانی سخت افزاری متفاوتی را ارائه دهند، باقی می گذارد. امروزه اکثر فریم‌ورک‌های محبوب مانند PyTorch و TensorFlow با استفاده از یک صفحه جلویی پایتون ساخته می‌شوند که به یک باطن اصلی C++ با کارایی بالا متصل می‌شود. DJL می تواند از این برای اتصال به همان backend های بومی استفاده کند تا از کار آنها در پشتیبانی و عملکرد سخت افزاری استفاده کند.

به همین دلیل، بسیاری از کاربران DJL نیز از آن فقط برای استنتاج استفاده می کنند. به این معنا که آنها یک مدل را با استفاده از پایتون آموزش می دهند و سپس آن را با استفاده از DJL برای استقرار به عنوان بخشی از سیستم تولید جاوا موجود خود بارگذاری می کنند. از آنجایی که DJL از همان موتوری استفاده می کند که پایتون را تامین می کند، می تواند بدون کاهش عملکرد یا کاهش دقت کار کند. این دقیقاً همان استراتژی است که ما برای پشتیبانی از مدل های جدید پیدا کردیم.

نمودار زیر روند کار زیر هود را نشان می دهد.

هنگامی که DJL بارگذاری می شود، تمام پیاده سازی های موتور موجود در مسیر کلاس را با استفاده از جاوا پیدا می کند ServiceLoader. در این مورد، پیاده سازی موتور DJL PyTorch را شناسایی می کند که به عنوان پل بین DJL API و PyTorch Native عمل می کند.

سپس موتور برای بارگذاری PyTorch Native کار می کند. به طور پیش فرض، باینری بومی مناسب را بر اساس سیستم عامل، معماری CPU و نسخه CUDA دانلود می کند و استفاده از آن را تقریباً آسان می کند. همچنین می‌توانید باینری را با استفاده از یکی از بسیاری از فایل‌های بومی JAR در دسترس تهیه کنید، که برای محیط‌های تولیدی که اغلب دسترسی به شبکه محدودی برای امنیت دارند، قابل اعتمادتر هستند.

پس از بارگذاری، DJL از رابط بومی جاوا برای ترجمه تمام قابلیت های آسان سطح بالا در DJL به تماس های بومی سطح پایین معادل. هر عملیات در DJL API به گونه‌ای ساخته شده است که به بهترین وجه با قراردادهای جاوا مطابقت داشته باشد و به راحتی قابل دسترسی باشد. این همچنین شامل پرداختن به حافظه بومی است که توسط Java Garbage Collector پشتیبانی نمی شود.

اگرچه همه این جزئیات در کتابخانه موجود است، اما فراخوانی آن از نقطه نظر کاربر نمی تواند ساده تر باشد. در بخش بعدی این فرآیند را طی می کنیم.

چگونه Sportradar DJL را پیاده سازی کرد

از آنجایی که ما مدل های خود را با استفاده از PyTorch آموزش می دهیم، از موتور PyTorch DJL برای استنتاج مدل استفاده می کنیم.

بارگیری مدل فوق العاده آسان است. تنها چیزی که لازم است ایجاد معیاری است که مدل بارگیری و مکان آن را توصیف کند. سپس، آن را بارگذاری می کنیم و از مدل برای ایجاد یک جلسه پیش بینی جدید استفاده می کنیم. کد زیر را ببینید:

برای مدل ما یک مترجم سفارشی نیز داریم که با آن تماس می گیریم MyTranslator. ما از مترجم برای کپسوله کردن کد پیش پردازشی استفاده می کنیم که از یک نوع جاوا مناسب به ورودی مورد انتظار مدل و کد پس پردازش که از خروجی مدل به خروجی مناسب تبدیل می شود، تبدیل می شود. در مورد ما، ما استفاده از a را انتخاب کردیم float[] به عنوان نوع ورودی و طبقه بندی داخلی DJL به عنوان نوع خروجی. در زیر قطعه ای از کد مترجم ما آمده است:

بسیار شگفت انگیز است که تنها با چند خط کد، DJL اسکریپت های PyTorch و مترجم سفارشی ما را بارگیری می کند، و سپس پیش بینی کننده آماده پیش بینی است.

نتیجه

محصول Sportradar که بر اساس راه‌حل DJL ساخته شده است، قبل از شروع فصل عادی NFL 2022–23 منتشر شد و از آن زمان تاکنون بدون مشکل اجرا شده است. در آینده، Sportradar قصد دارد مدل‌های موجود را که بر روی سرورهای gRPC میزبانی شده‌اند، مجدداً برای راه‌حل DJL پلتفرم کند.

DJL به طرق مختلف به رشد خود ادامه می دهد. جدیدترین نسخه، v0.21.0، دارای پیشرفت‌های زیادی است، از جمله پشتیبانی موتور به‌روزرسانی شده، بهبودهایی در Spark، نشانه‌های دسته‌ای Hugging Face، NDScope برای مدیریت آسان‌تر حافظه، و بهبودهایی در API سری زمانی. همچنین دارای اولین نسخه اصلی از دی جی ال صفر، یک API جدید با هدف پشتیبانی از استفاده از مدل های از پیش آموزش دیده و آموزش مدل های یادگیری عمیق سفارشی شما حتی با دانش صفر از یادگیری عمیق.

DJL همچنین دارای یک سرور مدل به نام است سرویس DJL. میزبانی یک مدل در سرور HTTP از هر یک از 10 موتور پشتیبانی شده، از جمله موتور پایتون برای پشتیبانی از کد پایتون، ساده می کند. با نسخه 0.21.0 سرویس DJL، شامل پشتیبانی سریع تر ترانسفورماتور می شود، آمازون SageMaker نقطه پایانی چند مدلی پشتیبانی، به‌روزرسانی‌های Stable Diffusion، بهبودهایی برای DeepSpeed ​​و به‌روزرسانی‌های کنسول مدیریت. اکنون می توانید از آن استفاده کنید مدل های بزرگ را با استنتاج موازی مدل با استفاده از DeepSpeed ​​و SageMaker مستقر کنید.

همچنین با DJL چیزهای زیادی در راه است. بزرگترین منطقه در حال توسعه، پشتیبانی از مدل زبان بزرگ برای مدل هایی مانند ChatGPT یا Stable Diffusion است. همچنین کارهایی برای پشتیبانی از درخواست‌های استنتاج جریان در سرویس DJL وجود دارد. ثالثاً، بهبودهایی در دموها و افزونه Spark وجود دارد. البته، کار مستمر استانداردی نیز وجود دارد که شامل ویژگی‌ها، اصلاحات، به‌روزرسانی‌های موتور و موارد دیگر می‌شود.

برای اطلاعات بیشتر در مورد DJL و سایر ویژگی های آن، رجوع کنید کتابخانه عمیق جاوا.

دنبال ما GitHub repo, مخزن نسخه ی نمایشی, کانال شلو توییتر برای مستندات بیشتر و نمونه هایی از DJL!

---

درباره نویسندگان

فرد وو یک مهندس ارشد داده در Sportradar است که در آن زیرساخت ها، DevOps و تلاش های مهندسی داده را برای محصولات مختلف NBA و NFL رهبری می کند. فرد با تجربه گسترده در این زمینه، به ساخت خطوط لوله و سیستم های داده قوی و کارآمد برای پشتیبانی از تجزیه و تحلیل های ورزشی پیشرفته اختصاص دارد.

زک کیمبرگ یک توسعه دهنده نرم افزار در سازمان هوش مصنوعی آمازون است. او کار می کند تا توسعه، آموزش، و استنتاج تولید یادگیری عمیق را امکان پذیر کند. در آنجا، او به ایجاد و توسعه پروژه DeepJavaLibrary کمک کرد.

کانوالجیت خرمی یک معمار اصلی راه حل در خدمات وب آمازون است. او با مشتریان AWS همکاری می کند تا راهنمایی و کمک فنی ارائه دهد تا به آنها کمک کند ارزش راه حل های خود را هنگام استفاده از AWS بهبود بخشند. Kanwaljit در کمک به مشتریان با برنامه های کاربردی کانتینری و یادگیری ماشین تخصص دارد.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• ضرب کردن آینده با آدرین اشلی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/machine-learning/how-sportradar-used-the-deep-java-library-to-build-production-scale-ml-platforms-for-increased-performance-and-efficiency/