BentoML

BentoML هو إطار عمل بايثون (Python) مفتوح المصدر لبناء وحزم ونشر واجهات برمجة تطبيقات (APIs) لخدمة نماذج التعلم الآلي. أسسه Chaoyu Yang وصدر لأول مرة في عام 2019، ووصل إلى إصداره v1.0 في يوليو 2022، ونما منذ ذلك الحين ليدعم أكثر من 10,000 مؤسسة، بما في ذلك أكثر من 50 شركة من قائمة Fortune 500. المشروع مرخص بموجب Apache 2.0، وتتم صيانته على github.com/bentoml/BentoML (الإصدار v1.4.38، أبريل 2026، 8.6k نجمة)، واعتباراً من فبراير 2026 يعمل تحت مظلة Modular، الشركة المطورة للغة البرمجة Mojo ومحرك الاستدلال MAX. الفكرة الأساسية هي خدمة النماذج بشكل مستقل عن إطار العمل: سواء كانت بيئة عملك تعتمد على PyTorch أو TensorFlow أو JAX أو ONNX أو XGBoost أو scikit-learn، فإن BentoML يحزمها في صورة مستقلة متوافقة مع OCI تعمل باستمرار من بيئة التطوير المحلية إلى بيئة الإنتاج على Kubernetes.

تتكون منظومة BentoML من ثلاثة منتجات. يتولى إطار العمل المفتوح المصدر تعريف الخدمة عبر تلميحات الكتابة (type hints) في بايثون، وعزل التبعيات لكل مشغل (runner)، والإنشاء التلقائي لصور Docker. يقوم OpenLLM، الذي تم إطلاقه في يونيو 2023، بتشغيل أي نموذج لغوي كبير (LLM) مفتوح المصدر (Llama 4، DeepSeek، Qwen، Phi3) كنقطة نهاية API متوافقة مع OpenAI بأمر واحد، باستخدام vLLM أو TRT-LLM أو PyTorch كخلفية للاستدلال. أما BentoCloud، الذي أصبح متاحاً للعموم في يونيو 2024، فهو منصة الاستدلال المُدارة التي توفر التوسع التلقائي، والتوسع إلى الصفر (scaling-to-zero)، وتحسين التشغيل البارد (cold-start)، وعمليات النشر التجريبية (canary) واختبارات A/B، والمراقبة الخاصة بنماذج LLM، ونشر نموذج إحضار السحابة الخاصة بك (BYOC) عبر AWS و Azure و GCP و CoreWeave و Lambda Labs. يمكن للفرق البدء بإطار العمل المفتوح المصدر بتكلفة صفرية، وإضافة OpenLLM لنقاط نهاية LLM ذاتية الاستضافة، ثم الانتقال إلى BentoCloud عندما يحتاجون إلى بنية تحتية مُدارة.

ما يفعله BentoML فعلياً في مايو 2026

سير العمل الأساسي هو "Bento": حزمة قابلة لإعادة الإنتاج ومحددة الإصدار تجمع النموذج وتبعياته وتكوين وقت التشغيل وتعريف API الخاص به في أداة واحدة متوافقة مع OCI. يمكنك تعريف خدمة باستخدام تلميحات الكتابة القياسية في بايثون، وتزيين الطرق (methods) بـ @bentoml.api، وتشغيل bentoml build لإنتاج صورة معبأة في حاويات. يمكن تقديم هذه الصورة محلياً للاختبار أو دفعها إلى سجل ونشرها على Kubernetes دون الحاجة إلى ملفات Dockerfiles إضافية أو مخططات Helm أو كتابة ملفات YAML يدوياً لطبقة الخدمة نفسها.

بالنسبة لسير العمل الخاص بالنماذج اللغوية الكبيرة (LLM)، يختصر OpenLLM تعقيد تحميل النموذج واختيار الخلفية وتوجيه API في أمر واحد. يؤدي تشغيل openllm serve meta-llama/Llama-4-Scout-17B-16E إلى بدء خادم محلي بنقطة نهاية متوافقة مع OpenAI، وواجهة مستخدم دردشة مدمجة، واختيار تلقائي للخلفية (vLLM إذا تم اكتشاف وحدة معالجة رسومات GPU، أو PyTorch كبديل). يمكن للفرق التي تبني مسارات RAG أو روبوتات الدردشة أو واجهات برمجة التطبيقات المدعومة بـ LLM توجيه LangChain أو أي عميل OpenAI SDK إلى نقطة النهاية هذه دون تعديل كود التطبيق.

تضيف طبقة الإنتاج في BentoCloud ما تتطلبه عمليات النشر ذاتية الاستضافة على Kubernetes ولكن نادراً ما تؤديه بشكل جيد افتراضياً: التوسع التلقائي القائم على التزامن والمُحسّن لأنماط الطلبات المفاجئة لأعباء عمل الاستدلال، والتوسع إلى الصفر لإدارة التكاليف في عمليات النشر الخاملة، واختبارات canary/shadow/A/B على مستوى البنية التحتية. ينشر خيار إحضار السحابة الخاصة بك (BYOC) مستوى التحكم الخاص بـ BentoCloud في سحابة VPC الخاصة بالعميل، مما يمنح المؤسسات التي لديها متطلبات HIPAA أو SOC 2 أو ISO 27001 تجربة مستخدم مُدارة دون مغادرة البيانات لبيئتها. واعتباراً من فبراير 2026، يتم دمج حزمة النشر المشتركة هذه مع محرك الاستدلال MAX من Modular لتحسين المسار الكامل من أوزان النموذج إلى استجابة HTTP.

موقع BentoML مقارنة بـ vLLM و Ray Serve

المقارنة التي يواجهها معظم المطورين ليست "BentoML أو vLLM" بل "أي طبقة من الحزمة يمتلكها كل منهما". vLLM هو محرك استدلال خالص ابتكاره الأساسي هو PagedAttention: فهو يستعير إدارة الذاكرة الافتراضية لنظام التشغيل لتقسيم ذاكرة التخزين المؤقت KV إلى كتل غير متجاورة، مما يقلل من إهدار ذاكرة GPU بنسبة تصل إلى 80%. تستخدم بنية V1 الخاصة بـ vLLM (إعادة كتابة 2024) تصميماً متعدد العمليات مع اتصال ZeroMQ بين المجدول ونواة المحرك وعمال GPU، وتوجيه C++ الذي يتعامل مع أكثر من 150 طلباً متزامناً دون أن يصبح Python GIL عنق زجاجة. يحمل vLLM حالياً حوالي 75,000 نجمة على GitHub وهو المعيار الفعلي لمحرك الاستدلال. يلتف BentoML حول vLLM بدلاً من التنافس معه: يتيح مشروع BentoVLLM الرسمي (github.com/bentoml/BentoVLLM) للفرق استخدام vLLM كخلفية لتوليد الرموز (tokens) بينما يتولى BentoML التعبئة في الحاويات، وتنسيق النماذج المتعددة، والنشر السحابي BYOC، وقابلية المراقبة. التقسيم الميكانيكي واضح: يمتلك vLLM تعظيم الإنتاجية؛ ويمتلك BentoML طبقة النشر ودورة الحياة فوقه. يمكن للفريق الذي يحتاج فقط إلى تعظيم إنتاجية رموز LLM الخام على جهاز واحد استخدام vLLM بشكل مستقل. أما الفريق الذي يحتاج إلى حزم نماذج غير متجانسة، وتنسيق مسارات استدلال متعددة الخطوات، والنشر عبر السحابات، فيحتاج إلى BentoML.

يعمل Ray Serve بفلسفة معمارية مختلفة. فهو مبني على إطار عمل الحوسبة الموزعة Ray (المدعوم من Anyscale، انظر Anyscale)، باستخدام نموذج الممثل (actor model) الخاص بـ Ray لتوزيع العمل عبر العقد. أضاف Ray Serve LLM (2024-2025) تكاملاً من الدرجة الأولى مع vLLM، ونقاط نهاية متوافقة مع OpenAI، وتوجيه طلبات مخصص لمحلية ذاكرة التخزين المؤقت للبادئة (prefix cache locality). الاختلاف الميكانيكي يكمن في بصمة البنية التحتية: يتطلب Ray Serve من الفرق نشر وتشغيل مجموعات Ray (عبر KubeRay أو غيره) على Kubernetes، وهو يكافئ الفرق التي تستخدم Ray بالفعل لمعالجة البيانات الموزعة أو التدريب. BentoML مستقل عن إطار العمل ولا يتطلب Ray. نموذج الحزم الخاص به أصلي لـ OCI (حاويات Docker القياسية) بدلاً من وقت التشغيل القائم على الممثل في Ray، مما يعني أن حزم Bentos من BentoML تتناسب مع البنية التحتية الحالية لـ Kubernetes دون تبني منظومة Ray الأوسع. يعد Ray Serve الخيار الصحيح للفرق التي تقوم بالفعل بتشغيل مهام Ray؛ بينما يناسب BentoML الفرق التي تريد خدمة أصلية لـ Kubernetes دون العبء التشغيلي لمجموعة Ray.

"عمل BentoML معي مؤخراً بشكل أفضل بكثير من مسارات عمل torchserve." -- komatsu، Hacker News، يوليو 2022

"واحدة من أدواتي المفضلة لنشر النماذج." -- kelseyfrog، Hacker News، يوليو 2022

كيف يبدو واقع سير عمل النشر

يستغرق الحصول على نموذج يخدم في بيئة التطوير دقائق معدودة: قم بتعريف فئة بايثون (Python class)، وأضف تعليقات توضيحية لأنواع الإدخال والإخراج، وقم بتشغيل `bentoml serve`. يُنشئ إطار العمل نقطة نهاية REST، ويتعامل مع التسلسل (serialization)، ويبدأ خادماً محلياً بواجهة مستخدم Swagger. التعبئة في الحاويات مباشرة بنفس القدر: ينتج `bentoml build` صورة OCI تجمع النموذج وتبعيات pip الخاصة به وكود الخدمة في عزلة. تفيد الفرق بقدرتها على استبدال نصوص خدمة النماذج القائمة على Flask بـ BentoML في فترة ما بعد الظهيرة والحصول على تجميع ديناميكي (dynamic batching)، وتنفيذ متوازي للمشغلات، وتسجيل منظم (structured logging) مجاناً.

يتسلل تعقيد الإنتاج عند الحواف. إسهاب التكوين (Config verbosity) هو الشكوى الأكثر شيوعاً: يمنح تنسيق bentofile.yaml تحكماً دقيقاً في موارد المشغل، ومعلمات التجميع، وإعدادات الحاوية، لكن التكوينات غير القياسية تتطلب إلماماً عميقاً بالأجزاء الداخلية لـ BentoML. كانت وثائق خيارات تكوين الخدمة غير متسقة تاريخياً، حيث أشار نقاش GitHub رقم 3560 إلى إرشادات متضاربة حول متى يكون `bentoml serve` مناسباً للإنتاج مقابل التطوير فقط. تتطلب بنيات النماذج المخصصة (اللوادر المخصصة، مسارات المعالجة المسبقة التي لا تتطابق مع الأنماط القياسية) كتابة كود نمطي (boilerplate) يتجاوز ما ينشئه إطار العمل تلقائياً.

مسار SageMaker مغلق اعتباراً من 25 فبراير 2024: قام BentoML بأرشفة مستودع aws-sagemaker-deploy. تحتاج الفرق التي تعتمد على بنية تحتية مقتصرة على SageMaker إلى الترحيل إلى نشر حاويات OCI أو إيجاد بدائل. يغطي خيار BYOC من BentoCloud العديد من متطلبات المؤسسات التي كان يُستخدم SageMaker من أجلها سابقاً، ولكنه يتطلب تبني BentoCloud بدلاً من البقاء في منظومة AWS بشكل أصلي.

بالنسبة لمسارات عمل LLM على وجه التحديد، يزيل OpenLLM معظم الاحتكاك. تعني نقطة النهاية المتوافقة مع OpenAI أن كود التطبيق الحالي الذي يستخدم OpenAI SDK يعمل دون تعديل. نشر فريق BentoML معياراً شاملاً لخلفية استدلال LLM في يونيو 2024 يقارن بين vLLM و LMDeploy و MLC-LLM و TensorRT-LLM و TGI، باستخدام BentoML كطبقة خدمة متسقة. أكد المعيار أن BentoML يضيف فقط عبئاً إضافياً ضئيلاً على خدمة بايثون الأصلية مع توفير قابلية مراقبة الإنتاج واتساق النشر الذي تفتقر إليه محركات الاستدلال الخام. يضع هذا الأداة في مكانة جيدة إلى جانب أدوات مثل vLLM للفرق التي تحتاج إلى كل من الأداء وقابلية النشر.

لمن تم بناء BentoML

الملاءمة الأوضح هي لفرق هندسة التعلم الآلي المسؤولة عن نقل النماذج من دفتر الملاحظات (notebook) أو تشغيل التدريب إلى واجهة برمجة تطبيقات (API) للإنتاج، والذين يحتاجون إلى خدمة أنواع نماذج غير متجانسة (ليس فقط LLMs)، ويرغبون في النشر على بنيتهم التحتية الخاصة أو السحابة الخاصة. إذا كانت بيئة عملك تمزج بين نماذج PyTorch وتصديرات ONNX ومسارات scikit-learn وتحتاج إلى تشغيلها جميعاً كواجهات برمجة تطبيقات موثوقة ومعبأة في حاويات مع أدوات مشتركة، فإن BentoML هو أحد أطر العمل القليلة التي تعالج ذلك دون الحاجة إلى كود ربط (glue code) كبير.

الملاءمة القوية الثانية هي للفرق التي ترغب في الاستضافة الذاتية لنقاط نهاية LLM لتجنب تكاليف API لكل رمز (per-token) من مزودي الخدمات التجارية. يمنح نشر OpenLLM بأمر واحد لنماذج Llama أو DeepSeek أو Qwen تلك الفرق واجهة برمجة تطبيقات متوافقة مع OpenAI تعمل على وحدات معالجة الرسومات (GPUs) الخاصة بهم، مع خيار التوسع عبر BentoCloud BYOC إذا زاد عبء العمل. بالمقارنة مع أدوات مثل Modal أو Replicate، يمنح BentoML تحكماً أكبر في البنية التحتية على حساب المزيد من الملكية التشغيلية. بالنسبة للمؤسسات التي تتتبع نسب النموذج (model lineage) جنباً إلى جنب مع الخدمة، يعد إقران BentoML مع MLflow نمطاً شائعاً لإدارة دورة حياة التعلم الآلي من البداية إلى النهاية.

تستفيد فرق المؤسسات ذات متطلبات الامتثال من نموذج نشر BYOC. يعني دعم SOC 2 Type II و ISO 27001 و HIPAA أن الصناعات الخاضعة للتنظيم (الرعاية الصحية، الخدمات المالية) يمكنها الحصول على تنسيق استدلال مُدار دون انتهاك متطلبات إقامة البيانات. يعزز استحواذ Modular في فبراير 2026 هذا الموقف من خلال إضافة تحسين الاستدلال على مستوى الأجهزة إلى طبقة النشر.

ما لا يمثله BentoML

BentoML ليس محرك استدلال جاهز للتشغيل الفوري (plug-and-play). فهو لا ينفذ آليات الانتباه (attention mechanisms) الخاصة به، أو إدارة ذاكرة التخزين المؤقت KV، أو تجميع الرموز (token batching). بل يعتمد على خلفيات مثل vLLM أو TRT-LLM أو PyTorch لتلك الطبقة. يجب على الفرق التي يتمثل مطلبها الوحيد في تعظيم إنتاجية رموز LLM على إعداد GPU ثابت تقييم vLLM بشكل مستقل، والذي يعد الأداة الأكثر تركيزاً لهذه المهمة المحددة بأكثر من 75,000 نجمة وكفاءة الذاكرة المثبتة لـ PagedAttention.

إنه ليس منصة بدون كود (no-code). يتطلب كل جزء من سير العمل كتابة كود بايثون. لا توجد واجهة مرئية لنشر النماذج ولا يوجد منشئ مسارات بالسحب والإفلات. الفرق التي لا تضم مهندسي تعلم آلي بلغة بايثون ضمن طاقمها ليست هي الفئة المستهدفة.

إنه ليس تكاملاً مع AWS SageMaker. اعتباراً من فبراير 2024، تمت أرشفة هذا المسار. تحتاج الفرق الملتزمة بمنظومة SageMaker إلى تقييم البدائل أو التبديل إلى نشر حاويات OCI الأصلية بشكل منفصل.

إنه ليس إطار عمل للتدريب. يبدأ دور BentoML بعد اكتمال التدريب. لتتبع التجارب أثناء التدريب، تخدم أدوات مثل MLflow الجزء المبكر من دورة حياة التعلم الآلي. يتعامل BentoML مع مرحلة الخدمة والنشر، وليس مراحل التجريب أو التدريب.