TrueFoundry: مراجعة نهاية عام 2023

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
مع اقتراب عام 2023 من نهايته، حان الوقت للتفكير في لـ TrueFoundry رحلتها خلال العام الماضي. هذا التأمل ليس مجرد احتفال بإنجازاتنا، بل هو أيضاً إقرار بالتحديات التي تجاوزناها، وتقدير للفرص التي أتيحت لنا، والدروس التي استوعبناها. بدلاً من التركيز على التفاصيل التشغيلية، سنسرد لكم رحلة زمنية من الدروس والإدراكات المرتبطة بأطروحتنا حول MLOps وكيف تجلت الأمور على أرض الواقع.
أنا شخصياً من عشاق الفضاء، لذلك أجد تشبيه الشركات الناشئة بالصواريخ مناسباً. إذا أردت وصف الجداول الزمنية متخيلاً أننا نبني صاروخاً، فإن- كان عام 2022 هو عام تجميع المحرك والقيام برحلة تجريبية، بينما عام 2023 هو العام الذي حددنا فيه مسارنا نحو النجوم وثبتنا فيه الدوافع لرحلتنا الكونية! أنا متحمس جداً لأخذكم في رحلتنا لعام 2023، ولكن دعوني أقدم بعض السياق حول TrueFoundry وبداية عام 2023.
TrueFoundry وعام 2022
تبني TrueFoundry منصة كخدمة (PaaS) مستقلة عن السحابة على Kubernetes، توحد تدريب ونشر نماذج التعلم الآلي باستخدام واجهات برمجة تطبيقات جاهزة للإنتاج وسهلة للمطورين.
في عام 2022، قضينا وقتاً في بناء فريقنا، وتطوير الطبقة الأساسية للمنصة عبر مزودي السحابة المختلفين، وعملنا عن كثب مع شركائنا الأوائل في التصميم. لقد طورنا طبقة نشر الخدمة الأساسية وبنينا تجارب مدفوعة بواجهة المستخدم (UI) وواجهة سطر الأوامر (CLI) وحزمة تطوير بايثون (Python-SDK)، واختبرنا فرحة أول دولار من عميل! لقد أدركنا أن البيع في مجال MLOps صعب لأن معظم الشركات كانت قد بنت “شيئاً يعمل” وكانت مقاومة التغيير عالية جداً.
من ناحية أخرى، كنا قد تحققنا بالفعل من المشكلات التي كنا نحلها-
- نماذج التعلم الآلي لم تكن تصل إلى مرحلة الإنتاج
- تأخرت عمليات نشر التعلم الآلي بسبب تسليم النماذج
- واجه علماء البيانات مشكلات كبيرة في إدارة البنية التحتية
- كان اعتماد Kubernetes في عالم التعلم الآلي ضئيلاً
- كانت نماذج التعلم الآلي التي تتبع مسار نشر مختلفاً عن برمجيات المكدس الكامل معطلة للغاية
- كانت الشركات تنفق 2 إلى 10 أضعاف التكاليف للعمل مع التعلم الآلي مما هو ضروري حقًا.
في هذا الوقت، كنا قد حددنا أننا كنا نحل مشكلة كبيرة ذات تأثير اقتصادي هائل، لكن التحدي كان أن هذه لم تكن مشكلة ملحة في ذهن العميل. ما تعلمناه من هذه التجربة-
حل نقطة ألم رئيسية أمر بالغ الأهمية للاستدامة، لكن لا يمكنك افتعال الإلحاح - العميل والسوق هما من يقرران ذلك. إنه ما يعادل قوانين الفيزياء في عالم الأعمال. لا تحارب ذلك - استمر في البحث!
بدء عام 2023
مع ذلك، بدأنا عام 2023، حيث كان لدينا العديد من تجارب الدخول إلى السوق (GTM) لتنفيذها بناءً على ما تعلمناه من العمل مع شركاء التصميم. فيما يلي بعض الأمثلة الملموسة للتجارب التي أجريناها-
- فرضية تعدد السحابات: 84% من الشركات تعمل عبر السحابات المتعددة، وتشغيل أعباء العمل عبر بائعي سحابات متعددين أمر صعب حقًا. بينما كان هذا يمثل استنزافًا هائلاً للوقت والتكلفة على المستوى التنظيمي، لم نتمكن من العثور على نقطة اتصال واحدة بشكل متكرر تعتبر هذه المشكلة أولوية قصوى لديها.
- أعباء عمل التعلم الآلي المدفوعة بـ K8s: عالم البرمجيات المتكامل (full-stack) كان قد بدأ بالفعل في جني فوائد حجم K8s والنظام البيئي المحيط به، وكان من الواضح أن التعلم الآلي (ML) سيزيد من هذه الفوائد. بينما وجدنا بعض الفرق التي كانت هجرة K8s أولوية لديها، فقد كانت دائمًا تأتي في المرتبة الثانية مقارنة بالعمل الموجه للمستخدمين لعملائنا.
- تحسين التكلفة: لاحظنا أن معظم شركائنا في التصميم وفروا 40-50% من تكلفة البنية التحتية السحابية عند العمل مع منصتنا، واستهدفنا المؤسسات التي كان تقليل التكلفة هدفها لهذا العام. بالطبع، لاقى هذا صدى، لكننا لاحظنا أن الفريق المسؤول عن تقليل التكلفة كان في الغالب فريق DevOps، وكان نطاق عملهم يتضمن تقليل التكلفة لمرة واحدة، ولم يكن لديهم سيطرة تذكر أو لا سيطرة على سير عمل المطورين، مما سيعيد ظهور المشكلة.
حسنًا، إذن عدد من التجارب الناجحة جزئيًا أو الفاشلة التي من خلالها لاحظنا مدى انتشار المشكلات التي كنا نحاول حلها، لكننا لم نتمكن بعد من إيجاد طريقنا لتحديد - شخصية عميل محددة، لديها نفس المشكلة الملحة بالضبط، ويمكن تحديدها بشكل متكرر خارجيًا.
استمر هذا الوضع، حتى أراد الجميع في العالم العمل مع نماذج اللغة الكبيرة (LLMs)، وقد أتيحت لنا فرصة في الوقت المناسب تمامًا.
جمعت نماذج اللغة الكبيرة (LLMs) الطلب لنا. أراد الجميع العمل مع نماذج اللغة الكبيرة (LLMs)، وأصبح الجميع الآن يواجهون "بإلحاح" نفس المشكلات التي كنا نحاول حلها.
توحيد عمليات نماذج اللغة الكبيرة (LLMOPs)، وعمليات التعلم الآلي (MLOPs)، وعمليات التطوير والتشغيل (DevOps)
بالنظر إلى بعض هذه المشكلات هنا في سياق نماذج اللغة الكبيرة (LLMs)-
- من العرض التوضيحي إلى الإنتاج: حرفيًا، يمكن لأي شخص كتابة بضعة أوامر (prompts) وإنشاء عرض توضيحي فاخر يعتمد على GPT-4. سيوافق كل عالم بيانات على أن بناء نظام RAG سريع باستخدام Langchain يستغرق بضع ساعات من العمل. التحدي هو أن تصبح هذه العروض التوضيحية جاهزة للإنتاج، مما يتطلب تجميع العديد من الأجزاء بطريقة موثوقة. تحتاج إلى بناء سير عمل يسهل على علماء البيانات التفكير في هذه التطبيقات في بيئة إنتاج منذ البداية.
- A100s — أين أنتم؟: لا نعرف مطورًا واحدًا عمل على نماذج اللغة الكبيرة (LLMs) في بنيته التحتية إلا واشتكى من عدم توفر وحدات معالجة الرسوميات (GPUs)، وخاصة A100s. كيف يمكنك زيادة احتمالية حصولهم على هذه الوحدات؟ من خلال تعريضهم لعدة سحابات أو مراكز بيانات - ولكن الأمر يصبح فوضويًا عند التعامل مع بنية سحابية متعددة إذا لم تكن لديك الأدوات المناسبة.
- استضافة النماذج مفتوحة المصدر: تتطلب استضافة نماذج اللغة الكبيرة هذه إدارة دقيقة للبنية التحتية، مما يزيد من اعتماد فرق علم البيانات على فريق البنية التحتية. إذا تمكنا من إنشاء المنصة المناسبة حيث تكون فرق علم البيانات "مستقلة نسبيًا عن البنية التحتية" - سيتم الحد من هذه المشكلة لحالات الاستخدام البسيطة نسبيًا مثل استضافة النماذج الجاهزة.
- مهام الضبط الدقيق طويلة الأمد- معظم عملائنا يقومون بضبط دقيق لنماذج اللغة الكبيرة (LLMs) وبعضهم يقوم بالتدريب المسبق أيضًا. هذه مهام مكلفة وتستغرق وقتًا طويلاً، ولا يمكنك تحمل إهدار الكثير من دورات وحدات معالجة الرسوميات (GPU) بسبب الأخطاء البشرية. أفضل ممارسات التسجيل والمراقبة وتتبع التجارب بالغة الأهمية هنا. على سبيل المثال، إذا لم تقم بحفظ نقاط فحص النموذج افتراضيًا وتم إيقاف مهمة التدريب الخاصة بك بعد يومين من بدء التنفيذ، فهذا إهدار هائل للوقت والموارد.
- مراقبة التكلفة- نماذج اللغة الكبيرة (LLMs) ليست رخيصة للتدريب ولا للتشغيل. العديد من الشركات تعاني حاليًا من اقتصاديات وحدة سلبية عند خدمة مستخدميها باستخدام نماذج اللغة الكبيرة (LLMs)، مفترضة أن التكاليف ستنخفض يومًا ما. الاعتماد على منصات سحابية مثل Sagemaker التي تفرض رسومًا إضافية على مثيلات EC2، ونادرًا ما تستفيد من مثيلات Spot، يزيد من تفاقم المشكلة. علاوة على ذلك، لا توجد رؤية تذكر أو لا توجد رؤية على الإطلاق لتكاليف البنية التحتية للمطورين الذين يمتلكون هذه الخدمات. بينما تبدو هذه المشكلة واضحة بشكل خاص في حالة نماذج اللغة الكبيرة (LLMs)، فإن كل المنطق المذكور أعلاه أساسي لجميع البرمجيات.
- قواعد بيانات المتجهات وإدارة الأسرار: لبناء تطبيقات تعتمد على نماذج اللغة الكبيرة (LLM)، وجد المطورون أنفسهم يتعاملون مع تطبيقات متعددة مثل قواعد بيانات المتجهات المختلفة، وLabel studio، ومجموعة متنوعة من خدمات واجهة برمجة التطبيقات (API). يتطلب كل منها وقتًا للإعداد وبنية تحتية للسماح بمشاركة مفاتيح واجهة برمجة التطبيقات (API) عبر المؤسسة بمستوى المراقبة المناسب. لا يجد علماء البيانات أنفسهم مجهزين بالأدوات المناسبة للتعامل مع هذا الأمر، والحل الوحيد هو "التباطؤ حتى يتم تطبيق حلول آمنة".
هذه بعض الأمثلة، ولكن هناك العديد من حالات الاستخدام المشابهة الأخرى - مثل إعداد الاستدلال غير المتزامن، ودفاتر الملاحظات المدعومة بوحدات معالجة الرسوميات (GPU)، ومحرك التخزين المشترك عبر دفاتر الملاحظات، وأوقات التشغيل البارد للحاويات الكبيرة (Docker containers) وما إلى ذلك، والتي وجدت الشركات صعوبة في حلها.
اتضح أن جميع عملائنا الذين يأتون لاستخدام نماذج اللغة الكبيرة (LLMs) ويستفيدون من بعض هذه الميزات مثل تقليل اعتماد علماء البيانات على البنية التحتية، أو توفير التكاليف، أو توسيع نطاق التطبيقات عبر موفري الخدمات السحابية مع تجنب الارتباط بمزود واحد، يدركون أن الأمر نفسه ينطبق على نماذج التعلم الآلي الأخرى التي ليست نماذج لغوية كبيرة، وينطبق واقعياً أيضاً على بقية حزمة البرامج. نرى هذا التلاقح في حالات الاستخدام للعملاء الذين بدأوا باستخدامنا لنشر البرامج أو نماذج التعلم الآلي التقليدية، ويرون الآن فوائد مع نماذج اللغة الكبيرة.
الخاتمة
هذا يعزز إيماننا بأن الوقت الذي قضيناه في بناء بنيتنا التحتية الأساسية، بمنظور حازم بأن التعلم الآلي هو برنامج ويجب نشره بالمثل، وأن K8s سيفوز على المدى الطويل، وأن الشركات سترغب في تجنب الارتباط بمزود واحد، سواء كان سحابياً أو غيره من مزودي البرامج - يؤتي ثماره لنا ولعملائنا.
لذا، لنختتم باستخدام تشبيه سفينة الفضاء -
إذا كان عام 2023 هو العام الذي رسمنا فيه الخريطة وجهزنا الدوافع، فإننا نتطلع إلى عام 2024 حيث سنشعل المعززات لدفع سفينة الفضاء هذه!!!
نتمنى لكم جميعاً عاماً سعيداً من فريق TrueFoundry بأكمله! أهلاً بعام 2024.
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)






