When Running Your Own AI Models Beats Paying for APIs - Steven Latré, imec

اسمي ستيفن. أنا أقود قسم الذكاء الاصطناعي في شركة آيمك (IMEC). بالنسبة لمن لا يعرفون ما هي آيمك، فنحن لسنا مشهورين في مجال الذكاء الاصطناعي، لكننا معروفون جداً في مجال أشباه الموصلات. يُنظر إلينا قليلاً على أننا الجوهرة الخفية. نحن موجودون منذ أكثر من أربعة عقود، وما نقوم به عادة هو امتلاك أكثر غرف الأبحاث والتطوير نظافة وتطوراً في العالم، ونعمل فعلياً مع شركائنا على الجيل القادم من أشباه الموصلات. لذا، فإن التأثير الذي أحدثناه في مجال أشباه الموصلات كبير جداً. أعتقد أن كل تقنية ترانزستور مستخدمة حالياً تقريباً قد ابتكرناها خلال العقود الأربعة الماضية. لذا، فنحن جوهرة خفية في بلجيكا، حيث أنتمي. إذاً، لماذا يتحدث خبير في أشباه الموصلات عن الذكاء الاصطناعي؟ حسناً، نحن نقوم بأكثر بكثير من مجرد تكنولوجيا الترانزستور. نحن نصل بعملنا إلى مستوى الأنظمة. ونصل أيضاً إلى مستوى أعباء العمل . وهذا هو مجال مسؤوليتي، حيث نحاول الربط بين ما تفعله أعباء عمل الذكاء الاصطناعي والبنية التحتية. من ناحية، لأننا عشنا ذلك أيضاً في السنوات القليلة الماضية. بالطبع، داخل آيمك، نعمل كثيراً مع الذكاء الاصطناعي لتحقيق تدفقات عمل مرنة أيضاً. وما اختبرناه، وأعتقد أن الكثيرين منا اختبروه في السنوات القليلة الماضية، هو مراحل مختلفة من نضج الذكاء الاصطناعي. لقد بدأنا نوعاً ما في عام 2024 و

2025 معتقدين أننا بحاجة إلى أحدث وأفضل النماذج الرائدة، وأن الأفضل لم يكن جيداً بما يكفي، وأننا بحاجة إلى المزيد والمزيد. لكن بالطبع، في الوقت نفسه، أدركنا أن الأسعار بدأت تتطور. انتقلنا من التسعير القائم على الاشتراك إلى التسعير القائم على الرموز (Tokens). ثم في العام الماضي، اتجهنا أكثر نحو توجيه النماذج (Model Routing)، حيث نحاول إيجاد أفضل نوع من النماذج للمهمة المطلوبة. أشياء أعتقد أننا جميعاً قمنا بها خلال العام الماضي أو نحو ذلك. ما نراه فعلياً، سواء داخل الشركة أو مع العملاء الذين نتحدث معهم، هو وجود مراحل أخرى لذلك أيضاً. يُعد توجيه النماذج من هذا المنظور ربما مجرد أول الثمار سهلة القطف في تحقيق تحسين جيد لإيجاد النموذج المناسب للمهمة المناسبة. نحن نرى المزيد والمزيد مع تزايد استهلاك الرموز (Tokens) بشكل كبير، أن هناك حاجة للقيام بأشياء أخرى، والقيام بأشياء أخرى يعني ببساطة التحكم في مكدسك الخاص في هذا الإطار. بهذا المعنى.

لذا نرى العملاء، ونحن نسير في هذا المسار أيضاً، ننتقل من البداية حيث نظرنا فقط إلى واجهات البرمجيات المغلقة، لنأخذ ما يمكننا فعله. ثم كانت المرحلة الثانية بالنسبة لنا هي: حسناً ، دعونا نرى كيف يمكننا تحسين التكلفة. نحن الآن في المرحلة الثالثة، حيث نبحث في كيفية استضافة نماذج الأوزان المفتوحة وكيف يمكننا استئجار بنيتنا التحتية على المدى الطويل، وربما حتى شراؤها أيضاً. أريد بشكل خاص التحدث عن المرحلتين الثالثة والرابعة من كل هذا ومعرفة ما يعنيه ذلك بالفعل، لأن تشغيل واجهة برمجية أو مجرد امتلاك واجهة لاستهلاك الرموز أمر مباشر جداً. إنه سهل التنفيذ، ولكن بمجرد الانتقال نحو المرحلتين الثالثة والرابعة، تبدأ مساحة التصميم في التوسع فجأة أيضاً. في المرحلة الأولى، كنا قلقين فقط بشأن نوع النموذج المناسب لدقة النموذج المناسبة أو لتعقيد المهمة المناسب. ولكن بمجرد أن تبدأ في امتلاك بنيتك التحتية، تحتاج فجأة إلى القلق بشأن الكثير من الأشياء الأخرى أيضاً. ما نوع النموذج الذي سأختاره ؟ كيف يمكنني الوثوق بهذا النموذج؟ أنت بحاجة للتفكير في أدوات الاختبار (harnesses) ، ولكن عليك أيضاً التفكير في الكثير من تكوينات الأجهزة، مثل ما هي بنية الأجهزة المناسبة التي سأستخدمها لهذا الغرض ؟ ما هو التوازن بين المعالج المركزي (CPU) ومعالج الرسوميات (GPU)؟ كيف يمكنني تحسين ذاكرة التخزين المؤقت (KV Cache) وكل ذلك؟ وهذا

هو المكان الذي نريد أن نضع أنفسنا فيه للمضي قدماً، حيث نحن بالطبع في عالم يدرك تماماً النماذج وأدوات الاختبار، لكننا نرى أيضاً فجوة بين تلك النماذج والأدوات وتلك البنية التحتية. لذا، ما قمنا به في الأشهر القليلة الماضية وما أنا هنا لتقديمه اليوم هو نوع من دراسة القياس التي أجريناها في الأشهر القليلة الماضية. لقد أجرينا آلاف الاختبارات لنقوم فعلياً بقياس ما يمنحك إياه الانتقال من استخدام واجهة برمجة تطبيقات إلى بناء بنيتك التحتية الخاصة. وذلك من منظور الذكاء الاصطناعي الوكيل ( Agentic AI). إذا كانت لديك مهمة ذكاء اصطناعي وكيل، وإذا كان لديك أداء محدد لهذه المهمة ، فما هي التكلفة التي ستتحملها إذا انتقلت من واجهة برمجة تطبيقات إلى بنيتك التحتية الخاصة؟ وهذا يعني أيضاً الانتقال من نموذج اشتراك يعتمد على التكلفة لكل رمز ( Token) إلى نموذج يعتمد حقاً على التكلفة الإجمالية للملكية. وأيضاً، كيف ينبغي عليك تهيئة البنية التحتية، وما هي أنواع بيئات العمل (harnesses) المناسبة؟ ما نوع الأجهزة التي ستحتاجها؟ ما هو محرك الاستدلال (inference engine) الأمثل لكل هذا؟ إذن، كيف قمنا بذلك؟ أردنا حقاً المقارنة على مستوى المهام، لذا نظرنا إلى المهام طويلة الأمد تحديداً، لأنها مثالية إذا كنت تمتلك بنيتك التحتية الخاصة وترغب في التحكم بها. إذا كنت تعمل بطريقة تفاعلية للغاية، فقد لا تكون الجدوى الاقتصادية هي نفسها، ولكن بالنسبة للمهام طويلة الأمد، نعتقد أن هذا هو السبب الأول أو نقطة التحول التي تجعل التحكم في

حزمة الذكاء الاصطناعي الخاصة بك أمراً ضرورياً. لذلك اخترنا مهمة محددة وهي مهام SWE-bench، وهي مجموعة من مهام القياس المرجعي الموجودة لمساعدة البرمجة. وما فعلناه هو التحقق من أنواع مختلفة جداً من بيئات عمل البرمجة. لقد استخدمنا Codex و Cloud Code لهذا الغرض، وهي أكثر ثلاث بيئات عمل شيوعاً لمساعدة البرمجة. ثم قمنا بتنويع أنواع النماذج التي يمكننا استخدامها في هذا السياق أيضاً. بدأنا ببيئة الواجهات البرمجية (API) القياسية التقليدية، ولكن نظرنا أيضاً إلى مجموعة واسعة من النماذج مفتوحة الأوزان ذات التعقيدات وأحجام المعايير المختلفة. ولأن هذا الحديث يدور حول نقل كل هذا إلى بنيتك التحتية الخاصة ، فقد قمنا بالطبع بربط ذلك ببنية الأجهزة المناسبة المتاحة أيضاً. دائماً ما نحاول العثور على نوع البنية الصحيح الذي لا يزال كافياً للقيام بذلك على نطاق واسع، وحيث يمكنك الحصول على مستخدمين متزامنين متعددين.

باختصار، قمنا بزيادة تعقيد الأجهزة، وزيادة تعقيد النماذج ، ولكن في الوقت نفسه نظرنا أيضاً إلى أداء التطبيق لكل هذا. إذن، ما هو معدل حل المهام الخاص بك؟ ما هو زمن الاستجابة (latency) وما هي التكلفة؟ بشكل عام، تجاوز هذا الأمر أكثر من ألف عملية تشغيل مختلفة قمنا بها. لقد أنشأنا خط أنابيب قياس مرجعي كاملاً، وأريد أن أستعرض معكم النتائج المختلفة التي حصلنا عليها من هذا. لنبدأ ربما بالأمر الأكثر وضوحاً. أن النماذج المختلفة، وتعقيدات النماذج المختلفة، وأحجام معايير النماذج المختلفة تمنحك في الواقع دقة مختلفة لهذه المهام. لقد تمكنا بالفعل من تصنيف النماذج إلى ثلاث فئات رئيسية. النماذج الأصغر، وأقصد بالأصغر تلك التي تصل إلى بضع مئات المليارات من المعلمات والتي تعد Qwen و DeepSeek جزءاً منها، حققت معدل حل يتراوح بين 30 إلى 40%من المهام التي تمكنت من إنجازها بدقة. بشكل صحيح.

الثاني، مثل نموذج GLM، كان في الواقع ضمن مستوى ونطاق Opus. ثم نموذج Kimik 3 الذي صدر قبل بضعة أشهر، كان في الواقع يتفوق بشكل مذهل بصراحة، ربما لأن جزءاً منه كان ضمن مجموعة بيانات التدريب أيضاً، ومع ذلك، كانت النتائج كبيرة جداً. حيث بلغ معدل الحل لديه 86%. الآن، كل هذا ليس شيئاً يمكنك العثور عليه بسهولة في التحليلات الاصطناعية أيضاً. هذا لا يمنحك الكثير من الرؤى الإضافية حقاً. ما أعتقد أنه أكثر إثارة للاهتمام هو إضافة جانب البنية التحتية والأجهزة إلى الصورة. وهناك نرى الكثير من الاختلافات. ما أجده مثيراً للاهتمام هو أنه إذا قارنت مثلاً بين Qwen و DeepSeek، ستجد أن أداء التطبيق بشكل عام يقع تقريباً على نفس المستوى. على الرغم من أنك إذا نظرت إلى نوع الأجهزة التي ستحتاجها لكل من Qwen و DeepSeek، فستجد أنك أمام عامل مضاعف أربع مرات من حيث تكلفة استئجار وحدات معالجة الرسوميات (GPUs). بالمثل ، إذا انتقلت من نموذج GLM إلى نموذج Kimik 3، فستحصل على زيادة في الدقة بنحو 20%، لكنها في المجمل لا تزيد تكلفة استئجار وحدات معالجة الرسوميات إلا بنسبة 15%. إذن، ماذا يخبرك هذا؟ يخبرك أساساً أنه إذا اتجهت نحو النماذج مفتوحة الأوزان، فمن المهم جداً النظر في قيود الأجهزة المتعلقة بها ، وكذلك النظر في

التكاليف الفعلية لكل هذا؛ فمن المؤكد أنه لا يوجد منحنى خطي هنا. لذا، غالباً ما تكون دالة خطوية حيث قد تختار نموذجاً معيناً ، وقد يؤدي مجرد اختيار نموذج أفضل قليلاً أو أقل أداءً قليلاً إلى تأثير هائل على بنية الأجهزة المختارة أيضاً. إذاً، هذا جانب واحد، وهو النظر إلى الأمور من منظور أداء التطبيق بشكل رئيسي. لنتناول الأمر من زاوية مختلفة ، وهي التزامن. لأنك عندما تستخدم واجهة برمجة تطبيقات (API)، يمكنك الحصول على أداء معين لاستهلاك الرموز (Tokens). أنت تعلم تقريباً ما سيكون عليه زمن انتقال الرموز، وتعرف ما ستكون عليه سرعة معالجتها. في اللحظة التي تنتقل فيها إلى حل يعتمد أكثر على البنية التحتية، تصبح بحاجة فجأة إلى القلق بشأن التزامن أيضاً. بمعنى آخر، كم عدد المستخدمين الذين يمكنني وضعهم بشكل موثوق على نفس الجهاز دون أن يتدهور أداء النظام تماماً من حيث زمن الانتقال. هناك جانب يتعلق بحجم الذاكرة، ولكن هناك أيضاً منظور يتعلق بزمن الانتقال.

الذاكرة تعني أن معظم الأنظمة مقيدة بها من جهة، وهذا يعني أن حجم معلمات النموذج يجب أن يتناسب مع ذاكرتك، وكذلك ذاكرة التخزين المؤقت (KV cache) الخاصة بمستخدميك. ومع زيادة عدد المستخدمين الذين يستخدمون النظام، ستزداد متطلبات ذاكرة التخزين المؤقت (KV cache) بشكل أكبر وأكبر. لذا، ما فعلناه هو محاولة النظر في أنواع الحلول المختلفة التي عرضتها للتو، ورؤية عدد المستخدمين المتزامنين الذين تمكنا فعلياً من استيعابهم براحة في ذلك النظام. وكانت النتائج مفاجئة نوعاً ما، أو على الأقل ربما لم تكن إيجابية جداً بالنسبة للنماذج الكبيرة أيضاً. لذا، ضع في اعتبارك أن كل نموذج من هذه النماذج المختلفة له بنية أجهزة خاصة به تكون مثالية له. ولكن إذا نظرت إلى مستويات التزامن المريحة التي تمكنا من الوصول إليها ، فقد انخفضت بشكل كبير جداً، حتى مع استخدام بنيات أجهزة أكبر. وفي جميع الحالات، كنا أبطأ بكثير من خط الأساس الخاص بنا، والذي كان " Cloud Code" في هذا السياق.

بالمناسبة، أعتقد أنكم توصلتم إلى كل ذلك بالفعل. لدينا في الواقع منشور مدونة مفصل حول كل موضوع أتحدث عنه. كل رمز استجابة سريعة (QR code) يقودك في الواقع إلى ذلك أيضاً. لذا، يوضح هذا أن التزامن ربما يكون أكثر أهمية من الدقة في هذا السياق. الدقة تمنحك نوعاً من خط الأساس، ولكن حتى بالنسبة للنماذج الكبيرة جداً، وخصوصاً إذا نظرت إلى المهام طويلة المدى مثل مساعد البرمجة، فإن تشغيل نموذج "Kimi K3" يتيح فقط حوالي أربعة مستخدمين متزامنين يمكنهم العمل بشكل موثوق، ومع ذلك، يظل زمن الانتقال أبطأ بثلاثة أضعاف. لذا، ما قمنا به هو تحليل شامل لنقاط التميز، لتحديد الحالات التي يكون فيها البقاء على استخدام واجهة برمجة التطبيقات (API) أمراً مجدياً. وفي أي الحالات يكون من المنطقي أكثر بالنسبة لك الانتقال إلى استئجار وحدات معالجة الرسوميات (GPUs) من مختلف مزودي النماذج المتاحين؟ وفي أي حالة يكون من الأفضل والأكثر إثارة للاهتمام الشراء والاستثمار فعلياً في بنيتك التحتية الخاصة وبنائها داخلياً.

بالطبع، قد تكون هناك أسباب أخرى كثيرة لإجراء هذا التحول، لكننا نظرنا إلى الأمر من منظور التكلفة الإجمالية للملكية. لذا، دون الدخول في تفاصيل كثيرة، ما رأيناه هو أنه كلما كان نظام بنية أجهزتك أقل، كان الانتقال من واجهة برمجة التطبيقات إلى بنيتك الخاصة أسوأ. لقد رأينا أنه إذا كنت حقاً في المستويات الدنيا من النماذج، وبالتالي في المستويات الدنيا من بنية الأجهزة التي ستحتاجها، فأنت تحتاج في الواقع إلى استخدام GPU بنسبة 89%تقريباً. هذا يعني أن وحدة معالجة الرسوميات الخاصة بك يجب أن تعمل بكامل طاقتها بنسبة 89% من الوقت. وبالمثل، إذا انتقلت بالفعل إلى أنظمة أجهزة أكبر، وقد أخطأت هنا، يجب أن تكون أنظمة أجهزة أعلى . على سبيل المثال، مع 8 وحدات B200، يمكنك الاكتفاء بنسبة 15%فقط من استخدام GPU، وهو أمر واقعي جداً، بينما نسبة 89%غير ممكنة تماماً بهذا المعنى.

إذا قمت بحساب المتوسط ونظرت إلى تطبيقات فئة GLM على سبيل المثال، فما نراه هو أن تلك هي نقطة التميز أو العتبة التي يصبح عندها الانتقال من API إلى البنية التحتية أكثر جدوى. وفي تحليل التكلفة الإجمالية للملكية الذي أجريناه خصيصاً لهذا التطبيق وهو المساعدة في البرمجة، رأينا حقاً أنك تحصل على توفير في التكلفة بنسبة 24 إلى 5%. هذا هو منظور البنية التحتية حقاً. دعونا ننتقل الآن إلى بيئات الاختبار (harnesses). لقد قمنا أيضاً بتنويع كمية بيئات الاختبار ونظرنا إلى أداء التطبيق لتلك البيئات الثلاث المختلفة. للوهلة الأولى، لم يتغير أداء التطبيق كثيراً في الواقع، وهو أمر قد يكون مفاجئاً نوعاً ما. كل مهمة قدمناها وكل بيئة اختبار استخدمناها أنجزت الأمر تقريباً، وبالنسبة لكل نوع من النماذج المختلفة، حصلنا تقريباً على نفس دقة التطبيق في هذا المعيار. للوهلة الأولى، قد تقول إن أداة التشغيل لا تؤثر على الإطلاق في ذلك لأنها تنجز المهمة المطلوبة. قد يكون هذا صحيحاً إذا كنت تعتمد على واجهة برمجة التطبيقات فقط، لكن الأمر يختلف تماماً إذا انتقلت إلى بنيتك التحتية الخاصة ودفعت مقابل استخدام وحدة معالجة الرسومات، لأن الوقت الفعلي المستغرق حينها يصبح مهماً حقاً. وما رأيناه هو أن أنواعاً مختلفة من أدوات التشغيل كان لها تأثير كبير على كمية الرموز المستهلكة، وتحديداً

في حالة "كودكس"، حيث استهلكنا في "جي إل إم" نصف عدد الرموز التي كانت تُولّد بالفعل. ونتيجة لذلك، كان الوقت الفعلي لاستخدام وحدات معالجة الرسومات هذه هو نصف الوقت أيضاً. هذا يعني أنه على الرغم من أن أدوات التشغيل منحتك الأداء المناسب للتطبيق أو مستوى مشابهاً له، فإن فاتورة وحدة معالجة الرسومات التي ستدفعها في النهاية ستكون نصف تكلفة أدوات التشغيل الأخرى. وهذا يوضح بجلاء أنه في تلك الحالة، قد لا يكون لاختيار أداة التشغيل المناسبة للنموذج تأثير على أداء التطبيق، لكن له تأثير حقيقي على التكلفة الإجمالية لملكية وحدات معالجة الرسومات لديك. هذه مجرد الدراسة الأولى التي أجريناها في الأشهر القليلة الماضية حول هذا الموضوع. إلى أين نتجه بهذا؟ أعتقد أن هناك الكثير مما يحتاج إلى تحليل. من الواضح تماماً أن الانتقال من واجهة برمجة التطبيقات إلى البنية التحتية ليس خياراً بسيطاً أو مباشراً.

وقد عرضت هذا الآن لتطبيق واحد وهو المساعدة في البرمجة، لكن بيئة العمل الفعلية للمؤسسات غالباً ما تتضمن مزيجاً من العديد من التطبيقات المختلفة أيضاً. وهذا يزيد الأمور تعقيداً بشكل أكبر. لقد رأينا أيضاً أن هناك علاقة معقدة للغاية بين أدوات التشغيل، والنماذج، والبنية التحتية. ولم أتطرق بعد إلى أمور أخرى مثل ما نفعله فيما يتعلق بالكمّية؟ وما هو تأثير تحسينات محددة مثل فك التشفير التخميني الذي طبقناه أيضاً، والذي لم نضبطه بالتفصيل؟ والبُعد الثالث بالطبع هو أن هذا المجال هدف دائم التغير. يتم إطلاق نماذج جديدة باستمرار. كما تتوفر خيارات جديدة لهندسة الأجهزة. لذا، نحن نعمل حالياً على تطوير خط قياس الأداء الذي نمتلكه بالفعل. نحن نبني هذا ليصبح مجموعة بيانات قياس أداء كاملة سنشاركها علناً مع الجميع، في محاولة لمواكبة هذا الهدف المتغير في المستقبل.

ولكن في الوقت نفسه، لا يمكننا القيام بذلك بمفردنا. نحن مؤسسة بحثية. نحن مؤسسة بحثية غير ربحية، والجزء الأهم بالنسبة لنا هو محاولة جمع هذا النظام البيئي معاً. وأعتقد أن عالم البرمجيات وعالم الأجهزة يستحقان أن يكونا أقرب إلى بعضهما البعض أيضاً. لذا، نحن نطلق بالفعل نوعاً من التحالف لجمع المهتمين بهذا الجانب ، أي المتخصصين في البرمجيات المهتمين بتحسين الأجهزة. نحن نجمع هذا مع محفظة عملائنا الحاليين من مزودي الرقائق الجدد والحاليين ومزودي البنية التحتية أيضاً. وإذا كنت مهتماً بهذا، لا تتردد في التواصل معنا بعد هذه المحادثة . شكراً جزيلاً.