AWS تشرح كيفية تشغيل llama.cpp على SageMaker والحصول على احتمالات للخيارات المحددة

نشرت مدونة AWS Machine Learning Blog دليلاً خطوة بخطوة لنشر نماذج القرار (decision models) على Amazon SageMaker AI باستخدام محرك llama.cpp. ويقوم الحل على طبقتين. تبدأ العملية بإنشاء نقطة نهاية (endpoint) تعتمد على حاوية AWS Deep Learning Container الرسمية لـ llama.cpp، وهي توفر chat completions متوافقة مع OpenAI. ثم يُوسَّع وقت التشغيل بمكتبة SemIf، فيعيد النموذج احتمالات لخيارات أُعلنت مسبقاً بدلاً من نص مولَّد. ويعمل كل ذلك على CPU وعلى GPU.

المادة تطبيقية: فهي تعليمات استخدام وليست إعلاناً عن منتج جديد. لكنها توضح كيف تقترح AWS تغطية أحد أكثر السيناريوهات شيوعاً في الشركات، وهو التصنيف واتخاذ القرارات بنماذج صغيرة دون بنية GPU تحتية ثقيلة.

مم تتكوّن المنظومة

llama.cpp محرك استدلال (inference) مفتوح المصدر مكتوب بلغتي C/C++، يستطيع تشغيل النماذج المكمّمة (quantized) بصيغة GGUF ولا يتطلب GPU. ولهذا السبب يحظى بشعبية حيث تلزم نقاط نهاية رخيصة ويمكن التنبؤ بسلوكها. وقد وضعته AWS في حاوية Deep Learning Container خاصة بها، كي لا يضطر المطورون إلى بناء الصورة يدوياً أو معالجة مشكلات الاعتماديات.

أبرز عناصر الحل بحسب وصف AWS:

• المنصة: Amazon SageMaker AI، أي نقاط نهاية مُدارة للاستدلال.
• وقت التشغيل: حاوية AWS Deep Learning Container لـ llama.cpp.
• الواجهة: chat completions متوافقة مع OpenAI، أي أن العملاء وSDK الموجودة تتصل دون إعادة كتابة.
• الإضافة: SemIf، التي تعيد احتمالات للخيارات المعلنة.
• العتاد: CPU أو GPU، والاختيار متروك للمطور.

يحل التوافق مع صيغة OpenAI مشكلة عملية في الانتقال. فإذا كان التطبيق يتصل أصلاً بواجهة الدردشة، يقتصر التحول إلى نقطة نهاية خاصة على تغيير العنوان والمفتاح.

لماذا احتمالات بدلاً من نص

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

تعالج SemIf هذه المشكلة على مستوى وقت التشغيل، بحسب الوصف. يعلن المطور الخيارات المسموح بها، ويتلقى في المقابل توزيعاً احتمالياً عليها. يمكن اختيار الخيار الأعلى، لكن الأهم هو شيء آخر: ظهور عتبة للثقة. فإذا حصل أفضل خيار على 0,92 نُفّذ الإجراء تلقائياً. وإذا حصل على 0,48 أُحيلت الحالة إلى إنسان. وهذا يحوّل نموذج اللغة إلى مكوّن ذي معايرة (calibration) قابلة للقياس، ويمكن دمجه في عملية عمل تجارية عادية.

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

ما الذي لم يرد في الإعلان

لا يتضمن الملخص القصير أي اختبارات أداء (benchmarks) أو أسعار أو قائمة بالنماذج المدعومة أو تفاصيل تنفيذ SemIf. ومن غير الواضح كيف تُحسب الاحتمالات بالضبط: هل من logits للرموز (tokens) الأولى للخيارات أم بطريقة أخرى. وتتوقف على ذلك درجة الوثوق بها عندما تكون الخيارات طويلة أو مركّبة. كما لا توجد مقارنة بين CPU وGPU من حيث زمن الاستجابة وكلفة الطلب الواحد. وسيتعين الحصول على هذه البيانات بشكل مستقل.

من أين تبدأ

فيما يلي ترتيب عملي للخطوات لفريق يريد اختبار هذا النهج:

• اختر مهمة واحدة محددة لها من 3 إلى 10 نتائج، مثل توجيه الطلبات الواردة.
• خذ نموذجاً صغيراً مكمّماً بصيغة GGUF وشغّله على نسخة (instance) تعتمد على CPU. هذه أرخص بداية.
• جهّز عينة مُوسَّمة وقِس مدى توافق احتمالات SemIf مع الدقة الفعلية. ثم حدّد العتبات للقرار التلقائي وللتصعيد.
• بعد ذلك فقط قارن مع نسخة GPU من حيث زمن الاستجابة والسعر لكل ألف طلب.

وإذا تبيّنت معايرة سيئة، فمن الأفضل معرفة ذلك قبل الانتقال إلى الإنتاج. وإذا كانت جيدة، يحصل الفريق على نقطة نهاية مُدارة بواجهة مألوفة واقتصاديات واضحة.