أعلنت Intel في 14 أكتوبر عن Inference Microservices: حاويات مخصصة للنماذج، تشغّل كل واحدة منها نموذج لغة كبيراً واحداً على معالجات Xeon المدعومة. عند بدء التشغيل، تكتشف الحاوية المضيف، وتختار ملف Intel المناسب للنموذج والمعالج، ثم تبدأ vLLM خلف واجهة HTTP متوافقة مع OpenAI. وعلى المطور الذي يملك سعة Xeon أن يحدد أولاً ما إذا كانت صورة موثقة تستطيع خدمة طلب تطبيق عبر شبكة داخلية، ثم يقيس عبء العمل على ذلك المضيف.

تحمل الصور الأولى المنشورة الوسم 0.1.0. وهي مخصصة لمعالجات Xeon من الأجيال الرابع والخامس والسادس بدقة BF16، على Linux مع Docker Engine 20.10 أو أحدث، أو Kubernetes 1.24 أو أحدث. وتصف الوثائق حزمة خدمة محلية، لا نقطة نهاية تستضيفها Intel؛ فلا حاجة إلى الحصول على مفتاح API من Intel. أما قول Intel إن ملفاتها تقلل أعمال الضبط أو تحسن الأداء فهو ادعاء من المورّد؛ لم تشغّل BIG CHANGE الصور أو تختبر أداءها.

التغيير الكبير

  • ما الذي تغير: جمعت Intel إعدادات vLLM الخاصة بكل نموذج داخل حاويات. تفحص هذه الحاويات مضيف Xeon مدعوماً وتختار ملف خدمة مدمجاً قبل إتاحة واجهة API قياسية.
  • لماذا يهم ذلك:يمكن للتطبيق استدعاء نقطة نهاية مألوفة للمحادثة، لكن الحاوية لا توفر توجيه التطبيق أو المصادقة أو TLS أو الامتثال لترخيص النموذج، ولا تثبت أن عبء عمل بعينه يحقق أهداف زمن الاستجابة والسعة.
  • ما الذي ينبغي متابعته:تحقق من وجود صورة في الفهرس وملف مناسب للنموذج المطلوب، ثم اختبر الجاهزية وسلوك الاستجابة والحمل على المضيف المقصود. تدرج Intel دعم GPU والمحركات والدقات الأخرى وHelm chart وoperator ضمن الأعمال المستقبلية، لا ميزات الإصدار الأول.

ما تتولاه الحاوية وما يظل مسؤولية الفريق

تقول Intel إن اكتشاف بدء التشغيل يراعي جيل Xeon والأنوية المتاحة وتخطيط NUMA وقدرات المعالج المدعومة. وتحدد الصورة الخاصة بالنموذج ملفاً يضبط الدقة وتوزيع العمل وتخطيط الذاكرة لمنصة vLLM. وإذا لم تجد ملفاً مناسباً للنموذج، يفشل بدء التشغيل بدلاً من التحول بصمت إلى ملف عام. أما الصورة الأساسية من Intel للنماذج الأخرى في Hugging Face فلها خيار احتياطي عام مختلف. وهذا الفرق مهم عند تحديد ما إذا كان بدء التشغيل الناجح يمثل فعلاً الإعداد الخاص بالنموذج الذي أراد الفريق تقييمه.

توفر واجهة API الموثقة المسارات GET /health, GET /v1/models, POST /v1/chat/completions, POST /v1/completions و GET /metrics افتراضياً على المنفذ 8000. /health تعيد HTTP 200 بجسم فارغ عندما يكون النموذج جاهزاً، و503 عندما لا يكون جاهزاً؛ لذا فإن التحقق من رمز الحالة أفيد من البحث عن جسم للاستجابة. /v1/models تعيد معرّف النموذج الوحيد الذي يجري تقديمه. على التطبيق إدراج ذلك المعرّف في طلب المحادثة وتحديد مسار الطلبات إذا كان يقدم عدة نماذج. توثق Intel البث ومكتبات العملاء المتوافقة مع OpenAI، لكن توافق صيغة الطلب لا يثبت جودة نموذج الفريق المحدد وموجهه أو سرعتهما.

وهناك أيضاً حد واضح للثقة. يقول دليل الأمان إن نقطة النهاية نفسها لا توفر TLS ولا مصادقة للجهة المستدعية. لا تعرض المنفذ 8000 على شبكة عامة من دون بوابة حماية أو حد شبكي. وفي Kubernetes توصي Intel بتقييد الوصول باستخدام NetworkPolicy والاستعانة ببوابة أو ingress لتوفير TLS والمصادقة. تعمل الخدمة على بنية العميل التحتية، لذا يتحمل الفريق أيضاً مسؤولية سعة المضيف وموقع الذاكرة المؤقتة والمراقبة والوصول إلى أوزان النماذج المقيدة.

تحقق محلي موثق أولاً، ثم اختبار لعبء العمل

في مثال Qwen3-4B العام، يقدم دليل البدء السريع من Intel أمر Linux/Docker هذا. إنها طريقة واردة في الوثائق فقط؛ لم تنفذها BIG CHANGE:

Terminal
docker run --rm -p 8000:8000 \
  --cap-add SYS_NICE \
  --shm-size=2g \
  intel/inference-xeon-qwen-qwen3-4b:0.1.0

تقول Intel إن التشغيل الأول ينزّل أوزان النموذج وقد يستغرق عدة دقائق. وفي طرفية ثانية، يفترض أن curl -i http://localhost:8000/health يعرض HTTP 200 بجسم فارغ بعد جاهزية المحرك. ثم ينبغي أن يحدد GET /v1/models القيمة Qwen/Qwen3-4B، وأن يعيد طلب POST /v1/chat/completions يستخدم هذا المعرّف ومصفوفة messages استجابة chat-completion. لا تثبت هذه الفحوص إلا أن نقطة النهاية الموثقة بدأت وأجابت. ولا يزال قرار النشر يحتاج إلى قياسات الفريق الخاصة بالموجهات والتزامن وزمن الاستجابة والموارد، وإلى اختبار السلوك عند الأعطال وإعادة التشغيل.

وفقاً لـ المتطلبات يُنصح بـ 32 GB من RAM و50 GB من مساحة القرص الحرة للذاكرة المؤقتة لنماذج 4B–8B، مع حاجة النماذج الأكبر إلى ذاكرة أكثر. ويوصى بـ Ubuntu 22.04 LTS أو أحدث، مع أن متطلب البرنامج هو Linux القادر على تشغيل Docker Engine 20.10 أو أحدث. لا يحتاج Qwen3-4B في مثال Intel إلى رمز Hugging Face، وتذكر بطاقة النموذج ترخيص Apache 2.0. وقد تكون النماذج الأخرى مقيدة الوصول؛ لذا يجب التحقق منفصلاً من تراخيصها وموافقة الوصول ورمز القراءة. لا تذكر وثائق Intel العامة سعراً لبرنامج microservices، ولا تحدد كلفة الأجهزة أو التشغيل لهذا النشر.

تميز قائمة الميزات المدعومة لدى Intel المسار المدمج الذي جرى التحقق منه عن تمريرات vLLM. ويتطلب استدعاء الأدوات والإخراج المنظم وLoRA وتغيير طول السياق INFERENCE_ENGINE_ARGS علامات إضافية. وقد تغير هذه العلامات الإعداد المضبوط أو تبطله؛ وتوصي Intel بفحص الأمر المحلول باستخدام dry-run واختبار النتيجة تحت الحمل. تعامل معها كمشروع تكامل مستقل، لا كقدرة أثبتتها الصورة الافتراضية. ويمكن لنشرات Kubernetes إضافة نسخ وفحوص جاهزية، لكن التطبيق أو البوابة يظلان مسؤولين عن توجيه الطلبات بين النماذج. وتتعلق تغطية Intel السابقة لـ سلسلة D بإعلان منفصل عن أجهزة GPU، لا بإصدار خدمة Xeon هذا.

المصادر ومزيد من القراءة

  • إعلان Intel، 14 أكتوبر 2026. يصف الحاوية الخاصة بالنموذج واكتشاف المضيف والملفات والنطاق الأولي لـ Xeon والتوسعات المخطط لها. ادعاءات الضبط والأداء صادرة عن Intel؛ ولم تتحقق منها BIG CHANGE بصورة مستقلة.
  • وثائق Intel Inference Microservices، وتحمل تاريخ تحديث 24 سبتمبر 2026. يقدم 0.1.0دليل البدء السريع أمر Qwen3-4B ومسار الفحص الأولي للصحة والمحادثة؛ والإجراء أعلاه مستند إلى الوثائق فقط.
  • المتطلبات المسبقة، مرجع API، الميزات المدعومة وإرشادات الأمان، وثائق Intel الموسومة بأنها محدثة في 24 سبتمبر 2026. تحدد المضيفات المدعومة واستجابات الجاهزية والفرق بين الميزات المدمجة وتمريرات vLLM وحد HTTP الذي يفتقر إلى المصادقة.
  • بطاقة نموذج Qwen/Qwen3-4B، اطُّلع عليها في 15 أكتوبر 2026. تذكر ترخيص Apache 2.0 للنموذج المثال؛ وقد تختلف الشروط وقيود الوصول لنماذج أخرى.