تمت كتابة هذا المنشور بالاشتراك مع جاد شمعون ، مدير الهندسة في Forethought Technologies، Inc. وسالينا وو ، كبير مهندسي ML في Forethought Technologies، Inc.

التفكير المسبق هي مجموعة رائدة في مجال الذكاء الاصطناعي لخدمة العملاء. في جوهر جناحها هو المبتكر SupportGPT ™ التكنولوجيا التي تستخدم التعلم الآلي لتحويل دورة حياة دعم العملاء - زيادة الانحراف ، وتحسين CSAT ، وتعزيز إنتاجية الوكيل. تستفيد ™ SupportGPT من أحدث أنظمة استرداد المعلومات (IR) ونماذج اللغات الكبيرة (LLMs) لتشغيل أكثر من 30 مليون تفاعل مع العملاء سنويًا.

حالة الاستخدام الأساسية لـ SupportGPT هي تحسين جودة وكفاءة تفاعلات وعمليات دعم العملاء. باستخدام أحدث أنظمة الأشعة تحت الحمراء المدعومة بحفلات الزفاف ونماذج الترتيب ، يمكن لـ SupportGPT البحث بسرعة عن المعلومات ذات الصلة وتقديم إجابات دقيقة وموجزة لاستفسارات العملاء. يستخدم Forethought نماذج دقيقة لكل عميل لاكتشاف نوايا العميل من أجل حل تفاعلات العملاء. يساعد تكامل النماذج اللغوية الكبيرة على إضفاء الطابع الإنساني على التفاعل مع الوكلاء المؤتمنين ، مما يخلق تجربة دعم أكثر جاذبية وإرضاءً.

يساعد SupportGPT أيضًا وكلاء دعم العملاء من خلال تقديم اقتراحات الإكمال التلقائي وصياغة الاستجابات المناسبة لتذاكر العملاء التي تتوافق مع الشركة بناءً على الردود السابقة. باستخدام نماذج اللغة المتقدمة ، يمكن للوكلاء معالجة مخاوف العملاء بشكل أسرع وأكثر دقة ، مما يؤدي إلى زيادة رضا العملاء.

بالإضافة إلى ذلك ، تتيح بنية SupportGPT اكتشاف الثغرات في قواعد المعرفة الداعمة ، مما يساعد الوكلاء على توفير معلومات أكثر دقة للعملاء. بمجرد تحديد هذه الثغرات ، يمكن لـ SupportGPT إنشاء مقالات ومحتويات أخرى تلقائيًا لملء الفراغات المعرفية هذه ، مما يضمن بقاء قاعدة معارف الدعم متمحورة حول العميل ومحدثة.

في هذا المنشور ، نشارك كيف يستخدم Forethought الأمازون SageMaker نقاط النهاية متعددة النماذج في حالات استخدام الذكاء الاصطناعي التوليدية لتوفير أكثر من 66٪ من التكلفة.

تحديات البنية التحتية

للمساعدة في جلب هذه الإمكانات إلى السوق ، تعمل Forethought على توسيع أعباء العمل ML الخاصة بها بكفاءة وتوفر حلولًا مخصصة للغاية مصممة لحالة الاستخدام المحددة لكل عميل. يتم تحقيق هذا التخصيص المفرط من خلال ضبط نماذج التضمين والمصنفات على بيانات العميل ، مما يضمن نتائج استرجاع المعلومات الدقيقة ومعرفة المجال التي تلبي الاحتياجات الفريدة لكل عميل. يتم أيضًا ضبط نماذج الإكمال التلقائي المخصصة على بيانات العملاء لزيادة دقة وملاءمة الاستجابات المتولدة.

أحد التحديات الكبيرة في معالجة الذكاء الاصطناعي هو الاستخدام الفعال لموارد الأجهزة مثل وحدات معالجة الرسومات. لمواجهة هذا التحدي ، تستخدم Forethought نقاط نهاية متعددة النماذج (MME) من SageMaker لتشغيل نماذج ذكاء اصطناعي متعددة على نقطة نهاية استدلال واحدة ومقياس. نظرًا لأن التخصيص المفرط للنماذج يتطلب نماذج فريدة ليتم تدريبها ونشرها ، فإن عدد النماذج يتناسب بشكل خطي مع عدد العملاء ، مما قد يصبح مكلفًا.

لتحقيق التوازن الصحيح للأداء للاستدلال والتكلفة في الوقت الفعلي ، اختارت Forethought استخدام SageMaker MMEs ، والتي تدعم تسريع GPU. تتيح SageMaker MMEs لشركة Forethought تقديم حلول عالية الأداء وقابلة للتطوير وفعالة من حيث التكلفة مع زمن انتقال دون الثانية ، مع معالجة سيناريوهات دعم العملاء المتعددة على نطاق واسع.

SageMaker ومدروس

SageMaker هي خدمة مُدارة بالكامل توفر للمطورين وعلماء البيانات القدرة على إنشاء نماذج تعلم الآلة وتدريبها ونشرها بسرعة. توفر SageMaker MMEs حلاً قابلاً للتطوير ومنخفض التكلفة لنشر عدد كبير من النماذج للاستدلال في الوقت الفعلي. تستخدم MME حاوية خدمة مشتركة ومجموعة من الموارد التي يمكنها استخدام مثيلات متسارعة مثل وحدات معالجة الرسومات لاستضافة جميع النماذج الخاصة بك. هذا يقلل من تكاليف الاستضافة عن طريق زيادة استخدام نقطة النهاية مقارنة باستخدام نقاط النهاية أحادية النموذج. كما أنه يقلل من عبء النشر لأن SageMaker يدير نماذج التحميل والتفريغ في الذاكرة وقياسها بناءً على أنماط حركة المرور الخاصة بنقطة النهاية. بالإضافة إلى ذلك ، تستفيد جميع نقاط نهاية الوقت الحقيقي لـ SageMaker من الإمكانات المضمنة لإدارة النماذج ومراقبتها ، مثل تضمين متغيرات الظل, التحجيم التلقائي، والتكامل المحلي مع الأمازون CloudWatch (لمزيد من المعلومات ، يرجى الرجوع إلى مقاييس CloudWatch لعمليات النشر متعددة النماذج نقطة النهاية).

مع نمو Forethought لاستضافة مئات النماذج التي تتطلب أيضًا موارد GPU ، رأينا فرصة لإنشاء بنية أكثر فعالية من حيث التكلفة وموثوقية وقابلة للإدارة من خلال SageMaker MMEs. قبل الترحيل إلى SageMaker MME ، تم نشر نماذجنا على Kubernetes خدمة أمازون مطاطا Kubernetes (أمازون EKS). على الرغم من أن Amazon EKS قدمت إمكانات إدارية ، فقد اتضح على الفور أننا كنا ندير البنية التحتية التي لم تكن مصممة خصيصًا للاستدلال. كان من المفترض أن يدير الاستدلال النموذجي على Amazon EKS بأنفسنا ، والذي كان عبئًا على الكفاءة الهندسية. على سبيل المثال ، من أجل مشاركة موارد GPU باهظة الثمن بين نماذج متعددة ، كنا مسؤولين عن تخصيص أجزاء صلبة من الذاكرة للنماذج التي تم تحديدها أثناء النشر. أردنا معالجة المشاكل الرئيسية التالية مع بنيتنا التحتية الحالية:

• التكلفة العالية - للتأكد من أن كل نموذج لديه موارد كافية ، سنكون متحفظين للغاية في عدد النماذج التي تناسب كل مثيل. أدى ذلك إلى ارتفاع تكاليف استضافة النموذج أكثر من اللازم.
• موثوقية منخفضة - على الرغم من كونها متحفظة في تخصيص الذاكرة لدينا ، فليس لكل النماذج نفس المتطلبات ، وفي بعض الأحيان قد تتسبب بعض النماذج في التخلص من أخطاء الذاكرة (OOM).
• إدارة غير فعالة - كان علينا إدارة بيانات النشر المختلفة لكل نوع من أنواع النماذج (مثل المصنفات ، والتضمينات ، والإكمال التلقائي) ، والتي كانت تستغرق وقتًا طويلاً وعرضة للخطأ. كان علينا أيضًا الحفاظ على المنطق لتحديد تخصيص الذاكرة لأنواع النماذج المختلفة.

في نهاية المطاف ، احتجنا إلى نظام أساسي للاستدلال لتحمل العبء الثقيل لإدارة نماذجنا في وقت التشغيل لتحسين التكلفة والموثوقية وإدارة خدمة نماذجنا. سمحت لنا SageMaker MMEs بمعالجة هذه الاحتياجات.

من خلال نموذج التحميل والتفريغ الذكي والديناميكي ، وقدرات التوسع ، قدمت SageMaker MMEs حلاً أقل تكلفة وأكثر موثوقية لاستضافة نماذجنا. نحن الآن قادرون على ملاءمة العديد من الطرز لكل مثيل ولا داعي للقلق بشأن أخطاء OOM لأن SageMaker MMEs تتعامل مع نماذج التحميل والتفريغ ديناميكيًا. بالإضافة إلى ذلك ، أصبحت عمليات النشر الآن بسيطة مثل استدعاء واجهات برمجة تطبيقات Boto3 SageMaker وإرفاق سياسات القياس التلقائي المناسبة.

الرسم البياني التالي يوضح العمارة القديمة لدينا.

لبدء الترحيل إلى SageMaker MMEs ، حددنا أفضل حالات الاستخدام لـ MME وأي من نماذجنا ستستفيد أكثر من هذا التغيير. من الأفضل استخدام MME لما يلي:

• النماذج التي يُتوقع أن يكون زمن انتقالها منخفضًا ولكن يمكنها تحمل وقت بدء بارد (عند تحميلها لأول مرة)
• النماذج التي يتم استدعاؤها بشكل متكرر ومتسق
• النماذج التي تحتاج إلى موارد GPU جزئية
• النماذج التي تشترك في المتطلبات المشتركة ومنطق الاستدلال

حددنا نماذج حفلات الزفاف الخاصة بنا ونماذج لغة الإكمال التلقائي كأفضل المرشحين لهجرتنا. لتنظيم هذه النماذج في إطار MME ، سننشئ MME واحدًا لكل نوع نموذج أو مهمة ، واحد لنماذج التضمينات الخاصة بنا والآخر لنماذج لغة الإكمال التلقائي.

لدينا بالفعل طبقة API فوق نماذجنا لإدارة النموذج والاستدلال. كانت مهمتنا الحالية هي إعادة صياغة كيفية نشر واجهة برمجة التطبيقات هذه ومعالجة الاستدلال على النماذج الموجودة تحت الغطاء باستخدام SageMaker ، مع الحد الأدنى من التغييرات في كيفية تفاعل العملاء وفرق المنتج مع واجهة برمجة التطبيقات. احتجنا أيضًا إلى حزم نماذجنا ومنطق الاستدلال المخصص لتكون متوافقة مع NVIDIA Triton Inference Server باستخدام SageMaker MMEs.

يوضح الرسم البياني التالي هندستنا الجديدة.

منطق الاستدلال المخصص

قبل الترحيل إلى SageMaker ، تم تشغيل كود الاستدلال المخصص لـ Forethought (المعالجة المسبقة والمعالجة اللاحقة) في طبقة API عند استدعاء النموذج. كان الهدف هو نقل هذه الوظيفة إلى النموذج نفسه لتوضيح فصل المسؤوليات ، وتوحيد وتبسيط الكود الخاص بهم ، وتقليل الحمل على واجهة برمجة التطبيقات.

التضمينات

تتكون نماذج التضمين المدروسة من قطعتين من نموذج PyTorch ، ويحدد طلب الاستدلال النموذج المطلوب استدعاؤه. يتطلب كل نموذج نصًا معالجًا مسبقًا كمدخل. كانت التحديات الرئيسية هي دمج خطوة المعالجة المسبقة واستيعاب اثنين من القطع الأثرية النموذجية لكل تعريف نموذج. لمعالجة الحاجة إلى خطوات متعددة في منطق الاستدلال ، طورت Forethought نموذج مجموعة Triton بخطوتين: عملية المعالجة المسبقة للواجهة الخلفية Python واستدعاء نموذج PyTorch الخلفي. تسمح نماذج المجموعات بتحديد وترتيب الخطوات في منطق الاستدلال ، مع تمثيل كل خطوة بنموذج Triton من أي نوع الواجهة الخلفية. لضمان التوافق مع الواجهة الخلفية لـ Triton PyTorch ، تم تحويل عناصر النموذج الحالية إلى تنسيق TorchScript. تم إنشاء نماذج Triton منفصلة لكل تعريف نموذج ، وكانت طبقة Forethought's API مسؤولة عن تحديد المناسب TargetModel للاستدعاء بناءً على الطلب الوارد.

الإكمال التلقائي

قدمت نماذج الإكمال التلقائي (التسلسل إلى التسلسل) مجموعة متميزة من المتطلبات. على وجه التحديد ، احتجنا إلى تمكين القدرة على إجراء حلقة من خلال مكالمات نماذج متعددة وتخزين المدخلات الأساسية لكل مكالمة مؤقتًا ، مع الحفاظ على زمن انتقال منخفض. بالإضافة إلى ذلك ، استلزمت هذه النماذج خطوات ما قبل المعالجة وما بعد المعالجة. لتلبية هذه المتطلبات وتحقيق المرونة المطلوبة ، قامت Forethought بتطوير نماذج MME للإكمال التلقائي باستخدام الواجهة الخلفية Triton Python ، والتي توفر ميزة كتابة النموذج كرمز Python.

المقارنة

بعد تحديد أشكال نموذج Triton ، قمنا بنشر النماذج لوضع نقاط النهاية المرحلية وإجراء قياس الأداء للموارد والأداء. كان هدفنا الرئيسي هو تحديد وقت الاستجابة لنماذج البداية الباردة مقابل نماذج الذاكرة ، وكيف تأثر زمن الوصول بحجم الطلب والتزامن. أردنا أيضًا معرفة عدد النماذج التي يمكن أن تتناسب مع كل حالة ، وعدد النماذج التي ستؤدي إلى زيادة الحالات مع سياسة التوسع التلقائي ، ومدى سرعة حدوث التوسع. تمشيا مع أنواع المثيلات التي كنا نستخدمها بالفعل ، أجرينا قياسنا مع مثيلات ml.g4dn.xlarge و ml.g4dn.2xlarge.

النتائج

يلخص الجدول التالي نتائجنا.

بشكل ملحوظ ، يكون زمن الوصول لطلبات البدء البارد أعلى بكثير من وقت الاستجابة لطلبات الاستدلال المخزنة مؤقتًا. هذا لأن النموذج يحتاج إلى التحميل من القرص أو خدمة تخزين أمازون البسيطة (Amazon S3) عند تقديم طلب بدء التشغيل البارد. كما أن زمن الوصول للطلبات المتزامنة أعلى من زمن الوصول للطلبات الفردية. هذا لأن النموذج يحتاج إلى أن يتم مشاركته بين الطلبات المتزامنة ، مما قد يؤدي إلى الخلاف.

يقارن الجدول التالي زمن انتقال النماذج القديمة ونماذج SageMaker.

بشكل عام ، تعد نماذج SageMaker خيارًا أفضل لاستضافة نماذج الإكمال التلقائي من النماذج القديمة. أنها توفر وقت استجابة أقل ، وقابلية التوسع ، والموثوقية ، والأمان.

إستخدام الموارد

في سعينا لتحديد العدد الأمثل من النماذج التي يمكن أن تناسب كل حالة ، أجرينا سلسلة من الاختبارات. تضمنت تجربتنا تحميل النماذج في نقاط النهاية الخاصة بنا باستخدام نوع مثيل ml.g4dn.xlarge ، دون أي سياسة قياس تلقائي.

توفر هذه الحالات الخاصة 15.5 جيجابايت من الذاكرة ، ونهدف إلى تحقيق 80٪ من استخدام ذاكرة وحدة معالجة الرسومات لكل مثيل. بالنظر إلى حجم كل قطعة أثرية لنموذج التشفير ، تمكنا من العثور على العدد الأمثل من مشفرات Triton لتحميلها على مثيل للوصول إلى استخدام ذاكرة GPU المستهدف. علاوة على ذلك ، نظرًا لأن كل نموذج من نماذج الزفاف لدينا يتوافق مع نموذجي تشفير Triton ، فقد تمكنا من توفير عدد محدد من نماذج حفلات الزفاف لكل حالة. نتيجة لذلك ، قمنا بحساب العدد الإجمالي للحالات المطلوبة لخدمة جميع نماذج حفلات الزفاف لدينا. كانت هذه التجربة حاسمة في تحسين استخدام مواردنا وتعزيز كفاءة نماذجنا.

أجرينا معايير مماثلة لنماذج الإكمال التلقائي الخاصة بنا. كانت هذه الطرز حوالي 292.0 ميجابايت لكل منها. عندما اختبرنا عدد النماذج التي تناسب مثيل ml.g4dn.xlarge واحد ، لاحظنا أننا كنا قادرين فقط على ملاءمة أربعة نماذج قبل أن يبدأ المثيل في تفريغ النماذج ، على الرغم من أن النماذج صغيرة الحجم. كانت اهتماماتنا الرئيسية:

• سبب ارتفاع استخدام ذاكرة وحدة المعالجة المركزية
• سبب تفريغ النماذج عندما حاولنا تحميل نموذج آخر بدلاً من الطراز الأقل استخدامًا مؤخرًا (LRU)

تمكنا من تحديد السبب الجذري لارتفاع استخدام الذاكرة الناتج عن تهيئة بيئة وقت تشغيل CUDA الخاصة بنا في نموذج Python الخاص بنا ، والذي كان ضروريًا لنقل نماذجنا وبياناتنا داخل وخارج جهاز GPU. يقوم CUDA بتحميل العديد من التبعيات الخارجية في ذاكرة وحدة المعالجة المركزية عند تهيئة وقت التشغيل. نظرًا لأن الواجهة الخلفية لـ Triton PyTorch تتعامل مع البيانات المنقولة داخل وخارج جهاز GPU وخارجه ، فإننا لم نواجه هذه المشكلة بالنسبة لنماذج التضمين الخاصة بنا. لمعالجة هذا الأمر ، حاولنا استخدام مثيلات ml.g4dn.2xlarge ، والتي تحتوي على نفس المقدار من ذاكرة وحدة معالجة الرسومات ولكن ضعف ذاكرة وحدة المعالجة المركزية. بالإضافة إلى ذلك ، أضفنا العديد من التحسينات الطفيفة في كود Python الخلفي الخاص بنا ، بما في ذلك حذف الموترات بعد الاستخدام ، وإفراغ ذاكرة التخزين المؤقت ، وتعطيل التدرجات ، وجمع القمامة. مع نوع المثيل الأكبر ، تمكنا من ملاءمة 10 نماذج لكل مثيل ، وأصبح استخدام ذاكرة وحدة المعالجة المركزية ووحدة معالجة الرسومات أكثر توافقًا.

يوضح الرسم البياني التالي هذه العمارة.

التحجيم التلقائي

لقد قمنا بإرفاق سياسات التحجيم التلقائي بكل من عمليات التضمين والإكمال التلقائي لـ MME. استهدفت سياستنا الخاصة بنقطة نهاية حفلات الزفاف الخاصة بنا 80٪ من متوسط ​​استخدام ذاكرة وحدة معالجة الرسومات باستخدام مقاييس مخصصة. شهدت نماذج الإكمال التلقائي لدينا نمطًا من حركة المرور المرتفعة خلال ساعات العمل وحركة المرور المنخفضة بين عشية وضحاها. لهذا السبب ، أنشأنا سياسة تحجيم تلقائي تستند إلى InvocationsPerInstance حتى نتمكن من التوسع وفقًا لأنماط حركة المرور ، وتوفير التكلفة دون التضحية بالموثوقية. استنادًا إلى قياس استخدام الموارد لدينا ، قمنا بتكوين سياسات القياس الخاصة بنا بهدف 225 InvocationsPerInstance.

نشر المنطق وخط الأنابيب

يعد إنشاء MME على SageMaker أمرًا مباشرًا ومشابهًا لإنشاء أي نقطة نهاية أخرى على SageMaker. بعد إنشاء نقطة النهاية ، تكون إضافة نماذج إضافية إلى نقطة النهاية بسيطة مثل نقل الأداة النموذجية إلى مسار S3 الذي تستهدفه نقطة النهاية ؛ في هذه المرحلة ، يمكننا تقديم طلبات استدلال إلى نموذجنا الجديد.

لقد حددنا المنطق الذي من شأنه أن يأخذ البيانات الوصفية للنموذج ، وينسق نقطة النهاية بشكل حتمي بناءً على البيانات الوصفية ، ويتحقق مما إذا كانت نقطة النهاية موجودة أم لا. إذا لم يحدث ذلك ، فإننا ننشئ نقطة النهاية ونضيف أداة نموذج Triton إلى التصحيح S3 لنقطة النهاية (المنسقة أيضًا بشكل حتمي). على سبيل المثال ، إذا أشارت البيانات الوصفية للنموذج إلى أنه نموذج إكمال تلقائي ، فسيؤدي ذلك إلى إنشاء نقطة نهاية لنماذج الإكمال التلقائي ومسار S3 المرتبط بتشكيلات نموذج الإكمال التلقائي. إذا كانت نقطة النهاية موجودة ، فسننسخ الأداة النموذجية إلى مسار S3.

الآن بعد أن أصبح لدينا أشكال نماذجنا الخاصة بنماذج MME ووظائف نشر نماذجنا في MME ، كنا بحاجة إلى طريقة لأتمتة النشر. يجب على مستخدمينا تحديد النموذج الذي يريدون نشره ؛ نتعامل مع تغليف ونشر النموذج. تم إصدار كود الاستدلال المخصص الذي تم تجميعه مع النموذج ودفعه إلى Amazon S3 ؛ في خطوة التجميع ، نسحب كود الاستدلال وفقًا للإصدار المحدد (أو أحدث إصدار) ونستخدم ملفات YAML التي تشير إلى هياكل الملفات لنماذج Triton.

كان أحد المتطلبات بالنسبة لنا هو تحميل جميع نماذج MME الخاصة بنا في الذاكرة لتجنب أي زمن انتقال بارد أثناء طلبات استنتاج الإنتاج لتحميل النماذج. لتحقيق ذلك ، نوفر موارد كافية لتناسب جميع نماذجنا (وفقًا للمعيار السابق) واستدعاء كل نموذج في MME لدينا بإيقاع كل ساعة.

يوضح الرسم التخطيطي التالي خط أنابيب نشر النموذج.

يوضح الرسم البياني التالي خط أنابيب إحماء النموذج.

الاحتجاج بالنموذج

توفر طبقة API الحالية الخاصة بنا فكرة مجردة للمتصلين للاستدلال على جميع نماذج ML الخاصة بنا. هذا يعني أنه كان علينا فقط إضافة وظائف إلى طبقة API لاستدعاء SageMaker MME بالنموذج الهدف الصحيح اعتمادًا على طلب الاستدلال ، دون أي تغييرات في رمز الاستدعاء. يأخذ رمز الاستدلال SageMaker طلب الاستدلال ، وينسق مدخلات Triton المحددة في نماذج Triton الخاصة بنا ، ويستدعي MMEs باستخدام Boto3.

الفوائد من حيث التكلفة

حقق Forethought خطوات كبيرة في تقليل تكاليف استضافة النموذج وتخفيف أخطاء OOM النموذجية ، وذلك بفضل الترحيل إلى SageMaker MMEs. قبل هذا التغيير ، تعمل مثيلات ml.g4dn.xlarge في Amazon EKS. مع الانتقال إلى MMEs ، اكتشفنا أنه يمكن أن يضم 12 نموذجًا للزفاف لكل مثيل مع تحقيق 80٪ من استخدام ذاكرة GPU. أدى ذلك إلى انخفاض كبير في نفقاتنا الشهرية. لوضعها في نصابها الصحيح ، حققنا توفيرًا في التكاليف يصل إلى 80٪. علاوة على ذلك ، لإدارة حركة المرور المرتفعة ، فكرنا في توسيع نطاق النسخ المتماثلة. بافتراض سيناريو نستخدم فيه ثلاث نسخ متماثلة ، وجدنا أن وفورات التكلفة لدينا ستظل كبيرة حتى في ظل هذه الظروف ، وتحوم حول 43٪.

أثبتت الرحلة مع SageMaker MMEs أنها مفيدة مالياً ، حيث قللت من نفقاتنا مع ضمان الأداء الأمثل للنموذج. في السابق ، تم نشر نماذج لغة الإكمال التلقائي في Amazon EKS ، مما استلزم عددًا متفاوتًا من مثيلات ml.g4dn.xlarge بناءً على تخصيص الذاكرة لكل نموذج. أدى ذلك إلى تكلفة شهرية كبيرة. ومع ذلك ، مع الترحيل الأخير إلى SageMaker MMEs ، تمكنا من خفض هذه التكاليف بشكل كبير. نستضيف الآن جميع الموديلات الخاصة بنا على مثيلات ml.g4dn.2xlarge ، مما يمنحنا القدرة على حزم النماذج بشكل أكثر كفاءة. أدى هذا إلى خفض نفقاتنا الشهرية بشكل كبير ، وحققنا الآن توفيرًا في التكاليف في نطاق 66-74٪. أظهرت هذه الخطوة كيف يمكن أن يؤدي استخدام الموارد بكفاءة إلى تحقيق وفورات مالية كبيرة باستخدام SageMaker MMEs.

وفي الختام

في هذا المنشور ، راجعنا كيف تستخدم Forethought نقاط النهاية متعددة النماذج SageMaker لتقليل تكلفة الاستدلال في الوقت الفعلي. تتولى SageMaker الرفع الثقيل غير المتمايز ، لذلك يمكن أن يزيد التفكير المسبق من الكفاءة الهندسية. كما أنه يسمح لـ Forethought بخفض تكلفة الاستدلال في الوقت الفعلي بشكل كبير مع الحفاظ على الأداء المطلوب للعمليات التجارية الهامة. من خلال القيام بذلك ، تكون Forethought قادرة على تقديم عرض مميز لعملائها باستخدام نماذج فائقة التخصيص. استخدم SageMaker MME لاستضافة النماذج الخاصة بك على نطاق واسع وتقليل تكاليف الاستضافة من خلال تحسين استخدام نقطة النهاية. كما أنه يقلل من عبء النشر لأن Amazon SageMaker يدير نماذج التحميل في الذاكرة ويقيسها بناءً على أنماط حركة المرور إلى نقطة النهاية الخاصة بك. يمكنك العثور على نماذج التعليمات البرمجية لاستضافة نماذج متعددة باستخدام SageMaker MME GitHub جيثب:.

حول المؤلف

جاد شمعون هو مدير الهندسة الأساسية في Forethought. يركز فريقه على هندسة المنصات التي تغطي هندسة البيانات والبنية التحتية للتعلم الآلي والبنية التحتية السحابية. يمكنك أن تجده على لينكدين:.

سالينا وو هو مهندس البنية التحتية لتعلم الآلة في Forethought.ai. وهي تعمل عن كثب مع فريق "التعلم الآلي" لبناء وصيانة البنى التحتية للبيانات والخدمة الشاملة وصيانتها. لديها الدافع بشكل خاص من خلال تقديم طرق جديدة لتحسين الكفاءة وتقليل التكلفة عبر مساحة ML. عندما لا تكون في العمل ، تستمتع Salina برياضة ركوب الأمواج ، وصناعة الخزف ، والتواجد في الطبيعة.

جيمس بارك مهندس حلول في Amazon Web Services. يعمل مع Amazon.com لتصميم وبناء ونشر الحلول التقنية على AWS ، ولديه اهتمام خاص بالذكاء الاصطناعي والتعلم الآلي. في h هو وقت فراغ ، يستمتع بالبحث عن ثقافات جديدة وخبرات جديدة ومواكبة أحدث اتجاهات التكنولوجيا. لينكدين:.

سونيل بادمانابان هو مهندس حلول بدء التشغيل في AWS. بصفته مؤسسًا سابقًا لشركة ناشئة ورئيسًا تنفيذيًا للتكنولوجيا ، فهو متحمس للتعلم الآلي ويركز على مساعدة الشركات الناشئة في الاستفادة من الذكاء الاصطناعي / التعلم الآلي من أجل نتائج أعمالها وتصميم حلول ML / AI ونشرها على نطاق واسع.

ضوال باتل هو مهندس رئيسي لتعلم الآلة في AWS. لقد عمل مع مؤسسات تتراوح من المؤسسات الكبيرة إلى الشركات الناشئة متوسطة الحجم في المشكلات المتعلقة بالحوسبة الموزعة والذكاء الاصطناعي. يركز على التعلم العميق بما في ذلك مجالات البرمجة اللغوية العصبية ورؤية الكمبيوتر. إنه يساعد العملاء على تحقيق استدلال نموذج عالي الأداء على SageMaker.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• تمويل EVM. واجهة موحدة للتمويل اللامركزي. الوصول هنا.
• مجموعة كوانتوم ميديا. تضخيم IR / PR. الوصول هنا.
• أفلاطونايستريم. ذكاء بيانات Web3. تضخيم المعرفة. الوصول هنا.
• المصدر https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/