فريق مكون من شخصين يقدم نموذجًا لـ 1.5 مليون شخص باستخدام TrueFoundry

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
في الأشهر القليلة الماضية، أتيحت لنا الفرصة للعمل مع فريق صغير لكنه فعال. لقد طوروا نموذج تعلم عميق متطورًا وأنشأوا شراكات لتقديمه لأكثر من 10 ملايين مستخدم.
كانت القطعة الأخيرة المفقودة في قصة تأثيرهم هي معالجة الجانب الهندسي لتحقيق ذلك. كان النموذج يتطلب قدرة حاسوبية عالية، وبالحجم الذي أرادوا به تقديم هذا النموذج للمستخدمين النهائيين، كانوا بحاجة إلى بنية تحتية موثوقة وعالية الأداء يمكن لشخصين منهم إدارتها (مهندس DevOps واحد ومهندس تعلم آلة واحد).
الحاجة إلى نشر غير متزامن
تم بناء النموذج لمعالجة مدخلات صوتية بأحجام مختلفة. نظرًا لأن النموذج كان يستغرق وقتًا طويلاً في المعالجة (بمتوسط حوالي 5 ثوانٍ)، فقد احتاج إلى استدلال غير متزامن لكل طلب لمعالجة هذه الطلبات والاستجابة لها.
لقد طور الفريق بنية تقنية على AWS Sagemaker
لقد بنى الفريق بنيته الأولية لتقديم النموذج على Sagemaker. ومع ذلك، عندما أجروا تجربتهم الأولية باستخدام هذا التصميم، أدركوا أن تقديم النموذج بشكل موثوق بالحجم المطلوب سيكون صعبًا باستخدام هذه البنية.
واجه المستخدمون تأخيرات تتراوح من 8 إلى 10 دقائق
حتى بعد استخدام الإعداد غير المتزامن، نظرًا لأن تشغيل المثيلات استغرق وقتًا للتوسع (8-10 دقائق لكل جهاز)، تضررت تجربة المستخدم النهائي عندما اضطروا إلى تحمل هذا التأخير.

ومع ذلك، خلال إثبات المفهوم، واجهوا تأخيرات كبيرة في أوقات الاستجابة. نظرًا لأنهم كانوا جددًا على العديد من عناصر التحكم المتعلقة بـ Sagemaker، فقد فقدوا وقتًا ثمينًا في البحث عن سبب التأخيرات. بعض التحديات التي واجهوها كانت:
- صعب التعلم: وجدوا صعوبة كعلماء بيانات/مهندسي تعلم آلة في فهم المفاهيم الجديدة المطلوبة لاستخدام Sagemaker.
- رؤية محدودة: كان إجراء تحليل السبب الجذري للمشكلات، خاصة في بيئة الإنتاج، صعبًا بسبب لوحات المعلومات والواجهات غير البديهية.
- صعب التوسع: كان توسيع Sagemaker بطيئًا، مما تسبب في تأخيرات في استجابات المستخدمين وتجربة عملاء سيئة.
- حصة منفصلة: تتطلب AWS منك تقديم طلبًا منفصلاً للحصول على سعة لمثيلات GPU المحجوزة لـ Sagemaker. وجد الفريق هذه العملية بطيئة ومقيدة.
- مكلف: كان استخدام وحدات معالجة الرسوميات (GPUs) مع Sagemaker مكلفًا للفريق لأن Sagemaker يفرض رسومًا إضافية على هذه الحالات بنسبة 25-40% مقارنة بـ EKS الخام.
بعد إثبات المفهوم، فقد الفريق الثقة في Sagemaker وقرروا أنهم بحاجة إلى حل يمكن لشخصين (مهندس تعلم آلة واحد ومهندس DevOps واحد) تقديمه لجمهورهم المستهدف الذي يزيد عن 10 ملايين مستخدم.
نشر النظام على TrueFoundry في أقل من يومين
عندما بدأنا العمل مع الفريق، كان مشروعهم التجريبي على بعد حوالي 7 أيام. أكدنا للفريق أننا نستطيع مساعدتهم في ترحيل المكدس بالكامل وإعادة بنائه باستخدام وحدات TrueFoundry في أقل من يومين، حتى يحصلوا على وقت كافٍ للاختبار قبل أن يدخل مشروعهم التجريبي مرحلة الإنتاج.

توسع أسرع بكثير
أجرى الفريق اختبارات أداء عن طريق إرسال دفعة من 88 طلبًا إلى النموذج لمقارنة الأداء مع Sagemaker. TrueFoundry توسعت أسرع بنسبة 78% من Sagemaker، مما يوفر للمستخدم استجابات أسرع بكثير. كان الوقت المستغرق للاستجابة للطلب من البداية إلى النهاية أسرع بنسبة 40% مع TrueFoundry.
توسع موثوق إلى أكثر من 150 عقدة
تمكن الفريق ببساطة من توسيع نطاق التطبيق إلى أكثر من 150 عقدة GPU للأسباب التالية:
- سهل التكوين: كان عليهم فقط تغيير معلمة في واجهة المستخدم ويمكنهم بسهولة تهيئة قواعد التوسع التلقائي بناءً على قائمة انتظار الطلبات الواردة. لكان هذا قد استغرق العديد من المراجعات ذهابًا وإيابًا مع فريق الهندسة.

- زيادة حصة وحدات معالجة الرسوميات (GPU): باستخدام TrueFoundry، تمكنوا من استخدام كل من Spot و Raw ECS. ونظرًا لنقص وحدات معالجة الرسوميات (GPU) لدى مزودي الخدمات السحابية، فقد وفرت TrueFoundry للفريق أيضًا خيار التوسع عبر مختلف مزودي وحدات معالجة الرسوميات (GPU) والمناطق.

- استخدام Spot والتوسع التلقائي: لم يبذل الفريق أي جهد إضافي لتهيئة استخدام مثيلات Spot لخدماتهم. كما تم تقليص حجم المثيلات عندما كان حجم حركة المرور منخفضًا. وباستخدام آلية الموثوقية من TrueFoundry لإعدادات استخدام Spot والتوسع التلقائي، وفر الفريق أكثر من 100 ألف دولار خلال الفترة التجريبية.
- بيئة التطوير والعرض التوضيحي: نشر الفريق أيضًا خدمة تطوير وعرض توضيحي للنموذج لجمع الملاحظات مع تقليص حجم الأجهزة عندما لا تكون قيد الاستخدام.
تمت خدمة 1.5 مليون مستخدم بالفعل ويتزايد العدد يومًا بعد يوم!
باستخدام TrueFoundry، يمكن للفريق المكون من عضوين إدارة عبء عملهم بالكامل، والذي يتوسع غالبًا إلى أكثر من 150 عقدة GPU!! بمفردهم. أثناء العمل معنا، كان الشيء الأكثر تميزًا الذي لفت انتباه الفريق هو دعم العملاء وأوقات الاستجابة المنخفضة لدينا. تلتزم TrueFoundry بنجاح عملائها ونأمل أن يتمكن جميع عملائنا من التوسع وإحداث تأثير على نطاقات مماثلة لهذا المشروع!
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI





















.png)
.webp)










.webp)






