في القمة الخريفية لكبار مسؤولي التقنية (CIO) في الشركات المركزية والمؤسسات المملوكة للدولة ومدراء شركات التقنية الرقمية (الدورة الـ19) التي نظمتها شبكة المؤسسات D1net عام 2026، حضر تانغ آن بو، مدير الحلول في SiliconFlow، القمة وقدّم عرضًا بعنوان: «من القدرة الحاسوبية إلى إنتاجية Token: البنية التحتية للاستدلال وممارسات العائد على الاستثمار للتطبيق واسع النطاق للنماذج الكبيرة في الشركات المركزية والمؤسسات المملوكة للدولة». وفيما يلي خلاصة محتوى العرض.
حاليًا، تمر تطبيقات الذكاء الاصطناعي بمرحلة مبكرة من النمو المتفجر، حيث يشهد استهلاك Token نموًا أُسّيًا. وخلف ذلك، تستمر بنية النماذج في التطور بإيقاع سريع لتحديث الإصدارات؛ وفي الوقت ذاته تتطور أيضًا بنية القدرة الحاسوبية باستمرار. فالعلاقة بين النماذج والقدرة الحاسوبية هي عملية تكرارية يدفع كلٌّ منهما الآخر. وبالنسبة للمؤسسات، يجب من جهة التكيف مع هذه التغييرات، ومن جهة أخرى تقديم خدمات نماذج متنوعة تلائم سيناريوهات أعمالها، مع الحفاظ على التكاليف ضمن نطاق معقول.
ما تسعى إليه SiliconFlow هو بناء طبقة التحويل من القدرة الحاسوبية إلى Token: إدارة القدرة الحاسوبية بشكل موحّد؛ ومن خلال محرك استدلال مطوَّر ذاتيًا، جعل النماذج تعمل أسرع وأفضل. ونقوم ببناء مصنع Token على السحابة العامة، كما نساعد الشركات المركزية والمؤسسات المملوكة للدولة على بناء مصانع Token خاصة بها داخليًا.
باختصار، من خلال هندسة الاستدلال المنهجية، تحقيق التكيف المتعدد بين النماذج والقدرة الحاسوبية. وبناءً على ذلك، طرحت SiliconFlow المعادلة الجوهرية لإنتاجية Token:إنتاجية Token = السعة الإنتاجية × معدل الاستخدام × جودة التسليم. ومنها، تتحدد السعة الإنتاجية بقدرات شرائح العتاد ومستوى تحسين النماذج معًا؛ ويتحقق معدل الاستخدام من خلال إدارة حركة المرور والجدولة الذكية للقدرة الحاسوبية؛ وتشمل جودة التسليم دقة استدلال النموذج، ومعدل نجاح تنفيذ المهام مثل استدعاء الأدوات، فضلًا عن استقرار خدمة SLA الضروري في بيئة الإنتاج.
من الإدارة الموحدة إلى تشغيل النماذج: رفع معدل استخدام القدرة الحاسوبية فعليًا
صممنا بنية رباعية الطبقات مفككة الارتباط من منظور الأعمال وحركة المرور. نربط فيها تشغيل النماذج وصيانتها وتنفيذ الاستدلال وجدولة القدرة الحاسوبية، بحيث تغطي جميع مراحل دورة حياة النموذج من النشر والتسريع إلى جدولة الخدمة. وتصميم البنية بطبقات مفككة الارتباط يهدف أيضًا إلى التكيف مع منصات الشركات المركزية والمؤسسات المملوكة للدولة القائمة، وتجنّب البناء المكرر؛ فإذا كانت المؤسسة تمتلك قدرات مطوَّرة ذاتيًا، يمكنها التكامل مع أنظمتها القائمة دون البدء من الصفر، أي سدّ القدرات المطلوبة مباشرة بطريقة «تجميع القدرات».
بوابة النماذج: ليست مجرد مدخل، بل أيضًا منصة لتشغيل النماذج.
هذه الطبقة موجهة مباشرة إلى مستخدمي خدمات النماذج، مثل الشركات التابعة والمجموعات الفرعية في مختلف المناطق. جميع استدعاءات النماذج الكبيرة تمر عبر هذه الطبقة لإنجاز الأعمال الأساسية مثل القياس والفاتورة والمصادقة. والأهم من ذلك أنها توفّر استراتيجيات غنية للجدولة والتوجيه: مثلًا يمكن توجيه الطلبات إلى خدمات النماذج المناسبة وفقًا لمتطلبات زمن الاستجابة في مختلف سيناريوهات الأعمال، بما يحقق استقلالية الأعمال عن بعضها ويضمن حصول جميع الأطراف على مستوى SLA مرضٍ؛ كما تدعم الجدولة المرنة وفق أهداف مختلفة مثل أولوية الأداء أو أولوية التكلفة.
منصة خدمات النماذج: نقل أفضل ممارسات النشر والصيانة إلى المؤسسات.
تدير هذه الطبقة، من منظور الصيانة بشكل أساسي، قدرات مثل رفع النماذج وخفضها ومستودع النماذج. نضع فيها أفضل ممارسات نشر النماذج، لتمكّن المؤسسات من تشغيل النماذج بنقرة واحدة بدلًا من إعادة التكيف في كل مرة. لقد تكيفنا مع ما يقارب مئة نموذج، ونواصل التكيف مع النماذج الرئيسية الجديدة، والهدف دائمًا هو تمكين فرق الأعمال من الاستخدام الفوري.
إطار الاستدلال عالي الأداء: تحسين وتطوير موجّه لنماذج وعتاد محددين.
نتعاون بعمق مع مختلف مصنّعي القدرة الحاسوبية، ونبني حول نماذج وقدرات حاسوبية محددة مكتبات حسابية ومكتبات اتصالات مطوَّرة ذاتيًا لإطلاق أداء النماذج على العتاد المقابل إلى أقصى حد ممكن. على سبيل المثال، بالتعاون مع Huawei Cloud، أطلقنا لأول مرة في القطاع خدمة Token مبنية على شرائح محلية لنموذجي DeepSeek R1/V3، وطوّرنا وحسّنّا معًا حلول الاستدلال لعنقود CloudMatrix الفائق، محققين على DeepSeek-R1 إنتاجية Decode تتجاوز 1,920 tokens/s لكل شريحة؛ وأطلقنا عالميًا أول نشر تجاري لنموذج Kimi-K2 الكبير على عنقود MetaX C550؛ ونشرنا DeepSeek-V3 على شريحة Moore Threads MTT S5000 محققين إنتاجية Prefill تتجاوز 4000 tokens/s وإنتاجية Decode تتجاوز 1000 tokens/s لكل شريحة.
وفي الوقت نفسه، تستمر تقنيات الاستدلال لدينا في التطور: مع النمو المستمر في سياق المهام التي تعالجها النماذج وارتفاع التزامن باستمرار، يلزم التحسين المستمر لإطار الاستدلال، مثل تحسين العمليات الحسابية وتحسين الاتصالات وضغط النماذج، إلى جانب أساليب مثل فصل PD وتفريغ KV Cache متعدد المستويات، لرفع شامل للأداء الكلي وقدرة الإنتاجية لاستدلال النماذج.
جدولة القدرة الحاسوبية: إدارة مرنة لموارد القدرة الحاسوبية.
تُعدّ الجدولة المرنة للقدرة الحاسوبية عنصرًا أساسيًا لخفض تكاليف الاستدلال ورفع كفاءة استخدام القدرة الحاسوبية. لكن تخطيط القدرة الحاسوبية يواجه غالبًا معضلة: فالتقدير المتحفظ أكثر من اللازم قد يؤدي سريعًا إلى التشغيل بكامل الطاقة أو حتى التحميل الزائد؛ بينما التهيئة وفق ذروة النهار فقط تؤدي إلى إهدار الموارد في الأوقات الأخرى. لذا، نحتاج إلى استراتيجيات توسع وتقليص مرنة، وكذلك إلى وسائل تشغيلية مساندة.
على سبيل المثال، عند تقديم الشركات المركزية والمؤسسات المملوكة للدولة خدمات النماذج لشركاتها التابعة، يمكن اعتماد تسعير حسب الوقت في التسوية الداخلية: سعر معتاد في النهار وخصم في الليل، لتشجيع بعض الأعمال على العمل ليلًا. وقد تستخدم مختلف الأعمال نماذج مختلفة، وهذا يتطلب من المنصة القدرة على الضبط الديناميكي لنُسخ النماذج بناءً على مؤشرات متعددة مثل قائمة انتظار الطلبات والأداء.
حالة من الشركات المركزية والمؤسسات المملوكة للدولة: التحول من «استئجار الأجهزة» إلى «استدعاء خدمات النماذج»
خدمّا مجموعة من الشركات المركزية والمؤسسات المملوكة للدولة كانت تمتلك حوالي 50 جهازًا لتقديم الخدمات لشركاتها التابعة. وكانت طريقة الخدمة المبكرة مباشرة جدًا: تطلب كل شركة تابعة الأجهزة وتنشر النماذج التي تحتاجها، وبعبارة بسيطة، كان الأمر «استئجار أجهزة».
وبهذا انفتحت أربعون إلى خمسون نسخة نموذج، لكن معدل استخدام القدرة الحاسوبية الكلي كان منخفضًا جدًا. فبعض الوحدات احتلت أجهزة لنشر نموذج واحد فقط؛ وبعضها يستخدمها نهارًا ولا يستخدمها ليلًا؛ وبعضها يستخدمها بضعة أيام في الأسبوع فقط. فالأجهزة محتلة دون أن تنتج أحمالًا فعّالة باستمرار.
تعاونّا بعمق مع العميل لإعادة هيكلة الوضع أعلاه:توحيد النماذج، وتوحيد القدرة الحاسوبية. حُصرت النماذج المكررة في حوالي عشرة؛ وتغيّرت طريقة تخصيص الموارد حسب الأجهزة إلى خدمات نماذج بأسلوب Serverless، بحيث يستدعي الجميع واجهة API موحدة دون الاهتمام بمكان نشر النموذج أو الجهاز الذي يشغّله.
وهكذا، يمكن لنفس الأجهزة البالغ عددها حوالي 50 جهازًا إنجاز المزيد. على سبيل المثال، بعد استخدام بعض الأجهزة لتشغيل بعض النماذج الصغيرة الأصلية، يمكن تخصيص عدة أجهزة لنشر نماذج جديدة كبيرة المعاملات، مثل GLM-5.2 وDeepSeek-V4-Flash-0731. وفي الماضي، لم تكن هذه المجموعة قادرة على تشغيل مثل هذه النماذج داخليًا. لكن في الواقع، النماذج الجديدة كبيرة المعاملات مهمة جدًا لاستكشاف الأعمال، لأنالحد الأعلى لذكاء النموذج يحدد أيضًا الحد الأعلى لابتكار التطبيقات.ومن خلال تجميع النماذج وإدارة القدرة الحاسوبية بشكل مركّز، نشرنا هذه النماذج، ومع تحسينات الأداء،حوّلنا المزيد من السيناريوهات من «غير قابلة للاستخدام» إلى «قابلة للاستخدام»، ومن «قابلة للاستكشاف» إلى «قابلة للتوسع».。
كان القلق الأكبر لدى جانب الأعمال سابقًا: لا مشكلة في إجراء الاستكشاف أو بناء Agent، لكن هل يمكن إطلاقه على نطاق واسع؟ هل يمكنه استيعاب المزيد من الاستدعاءات؟ كان لدى الجميع شكوك حول ذلك. بعد إطلاق النماذج الجديدة، وفي الاختبارات من التزامن الأحادي إلى التزامن الأعلى، حافظت سرعة الإخراج إجمالًا على مستوى يتجاوز 30 tokens/s. وفي البرمجة مثلًا، يُعد تجاوز 30TPS متطلبًا أساسيًا للحصول على تجربة استخدام جيدة. وفي الاختبارات المقارنة على النموذج نفسه، حققنا تحسنًا في الأداء تراوح بين 40% و100%. بالطبع، يعتمد ذلك على أطوال المدخلات والمخرجات المختلفة، والعائد الفعلي يتفاوت.
على نحو عام، تحسّن أمران: أولًا ارتفعت قدرة النموذج على معالجة الناتج (Throughput)، وثانيًا ارتفعت نسبة استغلال القدرة الحاسوبية. وبتراكم الجانبين معًا، يظهر ذلك أخيرًا في تكلفة كل مليون Token، وهي مؤشر تستخدمه كثير من المؤسسات لقياس كفاءة خدمات الاستدلال. في هذه الحالة، كانت تكلفة كل مليون Token لنموذج Qwen سابقًا تتجاوز مئة يوان، وبعد التعديل انخفضت إلى أقل من عشرة يوانات.انخفضت التكلفة بشكل ملحوظ، لكن الأهم هو أن ذلك فتح مجالات أعمال أكثر كان يصعب تنفيذها في الأصل.
زيادة العائد على الاستثمار (ROI) أكثر: تحسين التطبيقات والبنية التحتية معًا
مع التوسع في التطبيق العملي للوكلاء (Agents) على نطاق واسع، لاحظنا أيضًا مشكلة: وجود انفصال معين بين طبقة التطبيقات وطبقة البنية التحتية. في الماضي، عند تطوير التطبيقات، كان المطورون، حتى إذا كانوا مسؤولين عن الواجهة الأمامية أساسًا، يمتلكون عادةً فهمًا معينًا لفهارس قواعد البيانات وتحسين SQL. أما اليوم، فالتقسيم بين تطبيقات النماذج الكبيرة والبنية التحتية واضح جدًا، وقد لا يفهم جانب التطبيقات بشكل كافٍ آليات الاستدلال والتخزين المؤقت في الطبقة السفلية، وهذا يؤثر مباشرة على الكفاءة.
لنأخذ البرمجة (Coding) مثالًا؛ نحن نستكشف حاليًا هذا النوع من التحسينات بالتعاون مع العملاء. هندسة البرمجيات في المؤسسات المركزية والدولة المملوكة للدولة ليست كتابة تطبيق اليوم وعرض توضيحي آخر غدًا، بل هي تكرار وتطوير مستمر على مدى سنوات. مستودعات الشيفرة تتحدّث باستمرار، وتقديم الشيفرة وبناءها يوميًا جزء من مشروع طويل الأمد. وكيفية بناء هذه الشيفرة كسياق (Context) للنموذج أمر بالغ الأهمية.
إذا لم يُبنَ السياق بشكل جيد، فلن تصيب الطلبات التخزين المؤقت (Cache) في كل مرة، والمدخلات التي تبلغ عشرات آلاف التوكنات بسهولة ستستهلك قدرة حاسوبية ضخمة. أما إذا بُني بشكل جيد، فقد يصيب نحو تسعين بالمئة من محتواه التخزين المؤقت، ويظهر فارق الكفاءة عندها. على سبيل المثال، عند عدم إصابة التخزين المؤقت، قد يدعم النظام 100 طلب متزامن؛ وبعد تحسين نسبة إصابة التخزين المؤقت، قد يدعم 200 طلب متزامن. هذا التحسين لم يُضف أي عتاد، بل قلّل الحسابات المكررة. لذلك،بناء الـ Context نفسه يحتاج إلى تحسين موجّه نحو الاستدلال。
الاتجاه الآخر،هو التحسين بالجمع مع DevOps. استخدام القدرة الحاسوبية له قمم وقيعان؛ فالناس جميعًا يستخدمون القدرة الحاسوبية في النهار، بينما مدخلات سيناريوهات البرمجة طويلة جدًا. إذا انتظرت كل الشيفرة ليُعالج الطلب في النهار ثم يُولَّد التخزين المؤقت، فسيشغل ذلك قدرًا كبيرًا من القدرة الحاسوبية في ساعات الذروة. فهل يمكن، خلال عمليات البناء اليومية الروتينية كل ليلة، وبوسائل هندسية، أن يقوم النموذج بمعالجة أولية لمستودع الشيفرة وتخزين نتائج الحسابات المقابلة مسبقًا في KV Cache؟ وبذلك لا حاجة لإعادة الحساب في النهار. كل هذه الأساليب تتيح فرصًا لمزيد من رفع نسبة استغلال القدرة الحاسوبية. لكن هذه القدرات تعتمد أيضًا على استكشافها مع أصحاب السيناريوهات.
تأمل SiliconFlow أن تعمل مع المؤسسات المركزية والدولة المملوكة للدولة لاستكشاف المزيد من سيناريوهات تطبيق الذكاء الاصطناعي، وإطلاق القدرة الحاسوبية والطاقة الإنتاجية الحقيقية.
شبكة لييفنغ (حسابها الرسمي على WeChat: 雷峰网) شبكة لييفنغ