وفقًا لتقرير نشرته مجلة InfoQ، كشفت مايكروسوفت عن بنية توجيه ثلاثية الطبقات لنماذج اللغة الكبيرة (LLM) الخاصة بوكلاء الذكاء الاصطناعي العاملة على خدمة أزور كبرنيتيز (AKS). وتتناول هذه البنية إحدى أكثر القضايا التشغيلية إلحاحًا في مجال الذكاء الاصطناعي الوكيلي اليوم: أي نموذج ينبغي أن يرد على طلب معين، وأي جزء من البنية التحتية يجب أن يتخذ هذا القرار. وعلى الرغم من أن العنوان الرئيسي لمجلة InfoQ لا يتضمّن تفاصيل فنية كثيرة، فإن هذا الإعلان مهمٌّ لأن عملية التوجيه أصبحت بسرعة متزايدة نقطة التحكم الأساسية في التكلفة والتأخير وجودة المخرجات في أنظمة الوكلاء التشغيلية — كما أن اعتماد مزوِّد سحابي كبير لهذه العملية كنمط هندسي رسمي يُعدُّ إشارةً تستحق التأمل الدقيق.
أبرز الاستنتاجات
- وفقًا لمجلة InfoQ، كشفت مايكروسوفت عن بنية توجيه ثلاثية الطبقات لنماذج اللغة الكبيرة (LLM) الخاصة بوكلاء الذكاء الاصطناعي العاملة على خدمة أزور كبرنيتيز (AKS).
- يُقرّر توجيه نماذج اللغة الكبيرة (LLM) أي نموذج سيتعامل مع كل طلب، وقد أصبح هذا التوجيه وسيلة رئيسية للتحكم في التكلفة والتأخير وجودة المخرجات في أنظمة الوكلاء.
- تؤدي أحمال العمل الوكيلية إلى تضاعف عدد استدعاءات النماذج لكل مهمة، ما يجعل التوجيه الذكي ليس مجرد عملية تحسين، بل ضرورة اقتصادية.
- إن بناء وحدة التوجيه على منصة AKS يشير إلى اعتبار التوجيه جزءًا من البنية التحتية المنصّة (Platform Infrastructure)، وليس مجرد كود تطبيقي.
- وبعيدًا عن العنوان الرئيسي، تظل التفاصيل الفنية محدودة؛ أما الأهمية الأوسع فهي أن مزوِّد سحابي كبير قد رفع من شأن عملية توجيه النماذج لتصبح نمط تصميمٍ أساسيٍّ من الدرجة الأولى.
ما ذكرته مجلة InfoQ حول تصميم مايكروسوفت للتوجيه الثلاثي الطبقات
نشرت مجلة InfoQ، وهي مجلة متخصصة في هندسة البرمجيات على مستوى الممارسين، تقريرًا وصفته بأنه «تصميم مايكروسوفت للتوجيه الثلاثي الطبقات لنماذج اللغة الكبيرة (LLM) الخاصة بوكلاء الذكاء الاصطناعي على AKS». وهذه الصياغة ذاتها جديرة بالملاحظة: فهذه ليست إطلاق منتج استهلاكي، بل هي سردية هندسية توضّح كيفية توجيه حركة مرور الوكلاء عبر نماذج اللغة الكبيرة على بنية تحتية مُدارة قائمة على كبرنيتيز. وبعيدًا عن العنوان الرئيسي، لا تتضمّن المواد المتاحة حاليًا تعداد محتويات كل طبقة، أو تسمية النماذج المحددة المشاركة، أو اقتباس أرقام أداء، ولذلك ينبغي التعامل بحذر مع أي ادعاءات تفصيلية حول المكونات الداخلية حتى يتم الاطلاع على التقرير الكامل. أما ما يمكن قوله بثقة فهو أن مايكروسوفت تقدّم التوجيه — أي المنطق الواقع بين الوكيل ومجموعة النماذج — باعتباره نظامًا منظمًا وطبقيًا بذاته، وأنها اختارت AKS ك(substrate) الأساس الذي تشرح عليه هذا التصميم. وللفِرق المسؤولة عن البنية التحتية، فإن الجمع بين التوجيه وكوبرنيتيز هو جوهر الخبرة هنا.
لماذا أصبح توجيه نماذج اللغة الكبيرة (LLM) حاسم الأهمية لوكلاء الذكاء الاصطناعي
ولفهم سبب أهمية هذا الأمر، فكّر في الطريقة التي يستهلك بها الوكلاء النماذج فعليًّا. فطلب مستخدم واحد إلى وكيل نادرًا ما يؤدي إلى استدعاء نموذج واحد فقط. فقد يقوم الوكيل بالتخطيط، وتقسيم المهمة، واختيار الأدوات، وصياغة المسودة، والتحقق منها، وتلخيصها، وإعادة المحاولة — وكل خطوة من هذه الخطوات تولّد طلب استنتاج (inference request) خاصًا بها. وبعض هذه الخطوات يحتاج فعلاً إلى نموذج من الطراز الأول (frontier-class model)، لكن العديد منها لا يحتاج ذلك. فإرسال كل طلب إلى أكبر نموذج وأغلاه تكلفة يؤدي إلى ارتفاع الفواتير والتأخير دون تحقيق أي مكسب في الجودة، بينما إرسال كل الطلبات إلى نموذج صغير يُضعف جودة النتائج في الخطوات الصعبة.
توجيه نماذج اللغة الكبيرة (LLM) هو فن مطابقة كل استدعاء بأرخص نموذج كافٍ لأداء المهمة. وإذا نُفّذ هذا التوجيه جيدًا، فإنه يمكن أن يقلّل التكاليف بشكل كبير مع الحفاظ على ثبات الجودة، لأن توزيع درجات الصعوبة عبر المهام الفرعية للوكيل يميل بشدة نحو الجانب السهل. ومع تنامي عدد النماذج المتوفرة — ويمكنك استعراض هذا المشهد في قاعدة بيانات نماذج الذكاء الاصطناعي — فإن قرار التوجيه يصبح أكثر قيمةً وأصعب تنفيذًا يدويًّا. وهذا بالضبط هو الفراغ الذي صُمّمت البنية التحتية الرسمية للتوجيه لملئه.
داخل مكدس التوجيه الطبقي: ما الذي تعنيه عادةً الطبقات الثلاث
لا يوضح العنوان الرئيسي لمجلة InfoQ محتويات الطبقات الثلاث التي حدّدتها مايكروسوفت، وبالتالي فإن ما يلي هو سياق عام من قطاع الصناعة، وليس حقائق مُبلَّغة. وفي الممارسة الفعلية، تميل التصاميم الطبقيّة للتوجيه إلى فصل ثلاثة مخاوف رئيسية. أولها طبقة البوابة أو السياسة: وهي تشمل المصادقة، والقيود الكمية (Quotas)، والعزل بين المستأجرين (Tenant Isolation)، ومرشحات السلامة، والقابلية للمراقبة (Observability) — أي تلك الضوابط التي يمرّ بها كل طلب بغض النظر عن وجهته. ثانيها طبقة اتخاذ القرار: وهي المنطق المسؤول عن تصنيف الطلب الوارد حسب درجة الصعوبة أو المجال أو الحساسية للتأخير، ومن ثم تحديد النموذج أو النسخة أو المنطقة المناسبة، وأحيانًا باستخدام نموذج تصنيف صغير لاتخاذ هذا القرار. أما الثالثة فهي طبقة الخدمة أو الطبقة الخلفية: وهي مجموعات نقاط النهاية (Endpoints) الخاصة بالنماذج نفسها، مع توزيع الحمل (Load Balancing)، وآليات التحوّل عند الفشل (Failover)، والفحص الدوري لحالة النماذج (Health Checking) عبر هذه المجموعات.
إن فصل هذه المخاوف له أهميته، لأنها تتغيّر بمعدلات مختلفة. فالسياسات ثابتة نسبيًّا، بينما تتطوّر خوارزميات التوجيه أسبوعيًّا مع تغيّر النماذج وأسعارها، وتتغيّر مجموعات النماذج الخلفية كلما أُطلقت نسخة جديدة من النموذج. وتتيح البنية التحتية الطبقيّة للفرق تحديث طبقة واحدة دون زعزعة استقرار الطبقات الأخرى — وهي نفس الحجة التي أدّت في الجيل السابق إلى تقسيم البنية التحتية الويب إلى طبقات الحافة (Edge)، والتطبيق (Application)، والبيانات (Data). فإذا كانت بنية مايكروسوفت تتبع هذا النمط العام، فستجلب انضباطًا تشغيليًّا مألوفًا إلى جزء من مكدس الذكاء الاصطناعي ما زالت العديد من الفرق تتعامل معه عبر عبارات شرطية عشوائية (ad-hoc if-statements).
لماذا تم اختيار خدمة أزور كبرنيتيز (AKS) كمنصة
وضع وحدة التوجيه على منصة AKS، كما أشار إليه تقرير InfoQ، هو اختيارٌ ذو دلالة كبيرة. فـ Kubernetes تمنح بنية التوجيه خصائص لا يمتلكها المنطق المدمج في التطبيق: مثل التوسع الأفقي التلقائي (Horizontal Autoscaling) تحت أحمال مرور وكيلا متقطعة ومتقلبة، والعزل على مستوى الشبكة بين المستأجرين، والنشر الإعلاني (Declarative Rollout) لقواعد التوجيه الجديدة، والقدرة على تشغيل خوادم النماذج المدعومة ببطاقات الرسوميات (GPU-backed) داخل نفس المجموعة (Cluster) التي تعمل عليها وحدة التوجيه نفسها. كما أن هذه البنية تصبح قابلة للنقل من حيث المبدأ، لأن وحدات Kubernetes الأساسية قابلة للترجمة عبر مختلف البيئات.
وهناك بعد استراتيجي أيضًا. فوحدة التوجيه الأصلية لكوبرنيتيز يمكن أن تكون أمام مجمّع مختلط: فعلى جانب واحد نماذج واجهة برمجة التطبيقات (API) المستضافة، وعلى الجانب الآخر نماذج مفتوحة المصدر (open-weight models) مستضافة ذاتيًّا وتعمل داخل المجموعة نفسها، بينما تقوم طبقة التوجيه بالتحكيم بينهما في كل طلب. وللمنظمات التي تزن هذا الخيار، فإن حاسبة مقارنة بين الاستضافة الذاتية وواجهات برمجة التطبيقات (API) يُحدّد بدقة النقطة التي يتساوى فيها التكلفة بين الخيارين بالنسبة لمهمة معينة. واعتبار التوجيه جزءًا من البنية التحتية للمجموعة بدلًا من كونه كود تطبيق يُعدّ الشرط الأساسي لإدارة مثل هذه البيئات الهجينة على الإطلاق.
البعد الاقتصادي: التوجيه باعتباره طبقة جديدة للتحكم في التكلفة
والمنطق التجاري وراء التوجيه بسيطٌ. فأحمال العمل الوكيلية شرهة جدًّا في استهلاك الرموز (Tokens)، وتتفاوت أسعار الرموز تفاوتًا هائلًا بين مستويات النماذج المختلفة. فوحدة توجيه ترسل حتى نصف استدعاءات الوكيل إلى نموذج أرخص بعشر مرات — دون أن يُلاحَظ أي انخفاض في الجودة على تلك الاستدعاءات — فإنها بذلك تحوّل الاقتصاد الوحدوي للمنتج المبني على هذه البنية تمامًا. ولهذا السبب انتقل التوجيه من كونه فضولًا بحثيًّا إلى ضرورة تشغيلية، ولذلك فإن وصف مزوّدي الخدمات السحابية لهياكل مرجعية (Reference Architectures) خاصة به يكتسب أهمية كبيرة لكل فريق يعمل على تشغيل وكلاء الذكاء الاصطناعي على نطاق واسع. ويمكنك نمذجة تأثير تحويل حركة المرور بين مستويات النماذج باستخدام حاسبة تكلفة واجهات برمجة التطبيقات (API) للذكاء الاصطناعي, ومقارنة القيمة عبر النماذج المختلفة في مؤشر الأداء السعري للذكاء الاصطناعي.
وبصفة عامة، فإن مناهج التوجيه الرئيسية تقارن كما يلي:
| المنهجية | كيف يعمل | المزايا | المفاضلات |
|---|---|---|---|
| نموذج واحد لجميع الاستدعاءات | يذهب كل طلب إلى نموذج واحد مختار | بسيط؛ وسلوكه متوقع | إسراف في التكلفة على الاستدعاءات السهلة أو أداء ضعيف على الاستدعاءات الصعبة |
| التوجيه القائم على القواعد الثابتة | تُعيّن قواعد مكتوبة يدويًّا أنواع الطلبات إلى النماذج المناسبة | واضح؛ وسهل التدقيق | هشّ؛ ويحتاج تحديثًا يدويًّا مستمرًّا مع تغيّر النماذج |
| التوجيه الديناميكي الطبقي | تتولى طبقات مخصصة إدارة السياسات، واختيار النموذج، والخدمة | يتكيف مع كل طلب؛ وقابل للتوسع التشغيلي؛ ويدعم البيئات الهجينة | يتطلب بنية تحتية أكبر للبناء والمراقبة والضبط |
ما الذي يعنيه ذلك للفرق التي تبني وكلاء الذكاء الاصطناعي
أما للمطورين، فالاستنتاج العملي هو أن التوجيه يستحق نفس الاهتمام المعماري الذي تحظى به منطقية الوكيل نفسها. فالفِرق التي تطلق وكلاء الذكاء الاصطناعي — سواء كانت روبوتات دعم العملاء أو الأنظمة المصممة للمطورين والمشار إليها في دليلنا الخاص بـ وكلاء البرمجة بالذكاء الاصطناعي — تجد بشكل متزايد أن اختيار النموذج لكل استدعاء، وليس هندسة المُدخلات (Prompt Engineering)، وهو أكبر عامل متبقٍ يؤثر على التكلفة والزمن الاستجابي. فالمعمارية المرجعية المنشورة من قِبل البائع، حتى لو كانت تفاصيلها لا تزال في طور الظهور، توفر لفرق المنصات معيارًا ملموسًا يمكنها من خلاله مقارنة تصاميمها الخاصة.
كما أنها تشير إلى الاتجاه الذي يسير فيه النظام البيئي: حيث تصبح «التوجيه» (Routing) قدرةً مُدارةً ضمن منصة السحابة بدلًا من كونها وظيفةً يعيد كل فريق بناءها من الصفر. فإذا انتقلت منطقية التوجيه إلى البنية التحتية على مستوى المجموعة (Cluster-level infrastructure) في خدمات مثل AKS، فإن عوامل التميّز بين منتجات الوكلاء (Agent Products) ستتحول أكثر فأكثر نحو الطبقات العليا — أي نحو تصميم المهام، وتكامل الأدوات، وتقييم الأداء — بينما تتجه البنية التحتية الأساسية (Plumbing) نحو التوحيد القياسي.
الأسئلة الشائعة
ما الذي نشرته مايكروسوفت بالضبط؟ وفقًا لموقع InfoQ، فقد قدّمت مايكروسوفت تفصيلًا لهيكلية توجيه نماذج اللغة الكبيرة (LLM Routing) ذات الثلاث طبقات، والمخصصة للوكلاء الذكائية التي تعمل على خدمة Azure Kubernetes Service (AKS). أما المحتويات المحددة لكل طبقة، وأي بيانات أداء مرتبطة بها، فلم تُذكر صراحةً في المواد المتاحة وقت كتابة هذا التقرير.
ما هو توجيه نماذج اللغة الكبيرة (LLM Routing)؟ هو ممارسةٌ تتمثل في توجيه كل طلب استنتاج (Inference Request) إلى النموذج الأنسب من مجموعة نماذج متاحة، مع تحقيق توازن دقيق بين التكلفة والزمن الاستجابي والجودة المتوقعة — بدلًا من إرسال جميع الطلبات إلى نموذج واحد فقط.
لماذا يتم تشغيل مُوجِّه نماذج اللغة الكبيرة (LLM Router) على نظام Kubernetes؟ لأن نظام Kubernetes يوفّر إمكانات التوسع التلقائي (Autoscaling)، والعزل الآمن بين المكونات، والتكوين الإعلاني (Declarative Configuration)، ودعم أحمال العمل المعتمدة على وحدات معالجة الرسومات (GPU)، ما يسمح لأنظمة التوجيه بأن تعمل كبنية تحتية مشتركة تابعة للمنصة، وتخدم العديد من الوكلاء والفرق، بدلًا من أن تكون منطقيةً مكرَّرة داخل كل تطبيق على حدة.
هل يؤدي التوجيه فعليًّا إلى خفض تكاليف الذكاء الاصطناعي؟ نعم عمومًا: فمعظم المهام الفرعية التي يقوم بها الوكلاء سهلة نسبيًّا، وبالتالي فإن تحويلها إلى نماذج أقل تكلفة يمكن أن يقلّل النفقات بشكل ملحوظ، مع احتفاظ النماذج المتميزة (Premium Models) بالمهام التي تتطلب جودة عالية أو أداءً متفوقًا. أما المبلغ الدقيق للتوفير فهو يعتمد تمامًا على مزيج أحمال العمل.
ما الأمور التي لا تزال غير معروفة حول تصميم مايكروسوفت؟ لم تُؤكَّد التغطية الإعلامية الرئيسية النماذج المشاركة، ومنطق اتخاذ القرار في طبقة التوجيه، ونتائج الاختبارات المرجعية (Benchmark Results)، وتفاصيل التوافر العام (General Availability)، ويجب التحقق من هذه العناصر عبر التقرير الكامل لموقع InfoQ والوثائق الرسمية لمايكروسوفت.
الخلاصة النهائية
إن هيكلية مايكروسوفت لتوجيه نماذج اللغة الكبيرة ذات الثلاث طبقات، والتي أوردتها مجلة InfoQ، تمثّل إفصاحًا تقنيًّا ضيق النطاق لكن آثاره واسعة جدًّا. فهي تؤكد أن عملية توجيه النماذج — أي اتخاذ قرارٍ، في كل طلب على حدة، بشأن النموذج الذي سيقوم بالعمل — قد نضجت من كونها مجرد تحسين داخلي إلى أن أصبحت نمطًا معماريًّا مُسمَّى ومُقسَّمًا إلى طبقات، ومستعدًّا لتوثيقه رسميًّا من قِبل مزوِّد سحابي رائد ضمن خدمته المُدارة لـ Kubernetes. أما الرسالة الواضحة لأي شخص يشغل وكلاء ذكاء اصطناعي في بيئة الإنتاج فهي أن «الموجِّه» (Router) يتحول تدريجيًّا إلى القلب الاقتصادي والتشغيلي في مكدس الوكلاء (Agent Stack)، وأنه يستحق التصميم المتعمَّد بدلًا من أن يُكتسب عرضيًّا دون تخطيط. وبانتظار ظهور تفاصيل أكثر شمولية، فإن تنفيذ مايكروسوفت لهذا النموذج يستحق بالفعل التدقيق والتحليل.
المصادر: news.google.com. التقرير مؤرخ في ٢٩ يوليو ٢٠٢٦.
