سحابة الاستدلال للذكاء الاصطناعي الرائد للوكلاء — بيونغ غون (غون) تشون، فريندلي إيه آي
AAI Engineer
컴퓨터/소프트웨어창업/스타트업AI/미래기술
스크립트
00:00:00فلنبدأ. مرحبًا بالجميع، وشكرًا لحضوركم. نحن في أواخر الظهيرة من اليوم الأخير، لذا أقدر حضوركم جدًا.
00:00:25أنا “غون”، المؤسس والرئيس التنفيذي لشركة Friendly AI. اليوم أريد التحدث عن الاستدلال الوكيلي (Agentic Inference). وسأبدأ بمراجعة ما تغير، ولماذا يُعد مهمًا، وكيف أعدنا بناء سحابة الاستدلال للوكلاء.
00:00:40قبل أن نتذوق في التفاصيل، دعوني أُعرفكم بإيجاز على Friendly AI. إن Friendly AI هي سحابة استدلال الذكاء الاصطناعي الرائدة للوكلاء.
00:00:50نعمل على نطاق واسع، وبسرعة أكبر، وتكلفة أقل، وموثوقية أعلى. انطلقنا من فريق بحثي في جامعة سيول الوطنية، ولا تزال تلك الجذور البحثية تُحدد هويتنا.
00:01:02نحن الفريق الذي ابتكر التجميع المستمر (Continuous Batching)، وهو تحسين الاستدلال الذي أصبح الآن معيارًا في المجال، وقد ألهم عملنا في ORCA إطار 3LLM الشائع مفتوح المصدر.
00:01:15اليوم نعمل على مستوى عالمي، ويقع مقرنا الرئيسي في سان فرانسيسكو مع فريق في سيول لتطوير الاستدلال المتقدم.
00:01:24كما تعلمون، عام 2026 هو العام الذي يدخل فيه الوكلاء مرحلة الإنتاج الضخم، وهذا مدفوع بالتوافق بين اتجاهين.
00:01:33أولًا، يتزايد استخدام الوكلاء بشكل أُسي. حيث يقود وكلاء الذكاء الاصطناعي اعتمادًا هائلًا عبر البرمجيات والعمليات والأعمال المعرفية.
00:01:45ثانيًا، وصلت النماذج مفتوحة الأوزان إلى مستويات رائدة وجعلت الوكلاء جدائيين اقتصاديًا. أصبحت الآن تنافس النماذج المغلقة الرائدة في القدرات، مما يعني أنه يمكنك تشغيل وكلاء بجودة رائدة على نماذج مفتوحة بتكلفة رمزية أقل بكثير.
00:02:00دعوني أوضح كيف أصبحت النماذج مفتوحة الأوزان قوية بما يكفي لهذا النوع من مسارات عمل الوكلاء الحقيقية.
00:02:13هنا أسندنا المهمة نفسها تمامًا - بناء لعبة دفاع عن البرج باستخدام وكيل برمجية - إلى نموذجين.
00:02:19على اليسار نموذج GLM 5.2، وهو نموذج مفتوح الأوزان يعمل على Friendly AI. وعلى اليمين نموذج Opus 4.8 من Anthropic.
00:02:29النقطة المهمة ليست أن المخرجات متطابقة، بل أن كلا النموذجين ينفذان المهمة بالمستوى المطلوب للاستخدام العملي.
00:02:38بالنسبة للعديد من مسارات عمل الوكلاء، تجاوزت النماذج مفتوحة الأوزان عتبة الجودة، ولكن الجانب الاقتصادي مختلف تمامًا.
00:02:49للمهمة نفسها، تبلغ تكلفة Opus 4.8 حوالي 1.50 دولارًا. بينما تبلغ تكلفة GLM 5.2 على Friendly AI حوالي 0.27 دولارًا، أي أرخص بـ 5.6 مرات.
00:03:03هذا هو الوعد الذي ذكرته سابقًا: تمنحك النماذج مفتوحة الأوزان وكلاء بجودة رائدة بجزء بسيط من التكلفة.
00:03:12لكن تكلفة النموذج ليست سوى جانب واحد من القصة. فكي نجعل الوكلاء أسرع وأكثر موثوقية بالفعل، يجب أن تتغير بنية الاستدلال نفسها.
00:03:22دعونا ننظر إلى ما يحدث بالفعل داخل عبء عمل الوكيل.
00:03:28أولًا، لنلقِ نظرة على التغيرات في عبء العمل. في الماضي، كان الاستخدام السائد هو المحادثة (Chat).
00:03:34وكانت الوحدة الأساسية هي الطلب (Request)؛ يطرح الشخص سؤالًا، ويجيب النموذج، ثم يقرأه الشخص.
00:03:41وكان زمن الاستجابة يعني: ما السرعة التي أحصل بها على رد واحد؟ لكن الوكلاء مختلفون، فالوحدة الأساسية هي المهمة (Task).
00:03:49قد تتضمن المهمة استدعاءات عديدة للنموذج، واستدعاءات عديدة للأدوات، وقد تعمل بشكل مستقل لفترة من الوقت.
00:03:58لذلك لا يهتم المستخدم حقًا بزمن استجابة طلب فردي واحد.
00:04:04بل يهتم بالوقت الذي تكتمل فيه المهمة بأكملها.
00:04:08وهذا يعني أنه يتعين علينا التحسين للمهام، وليس فقط للطلبات الفردية.
00:04:16دعونا نتفحص أحمال عمل الوكلاء عن قرب. يقوم الوكيل في الواقع بتشغيل جلسة تتكون من عدة مهام.
00:04:23عادةً ما تُنفذ كل مهمة في حلقة تكرارية. أولًا، يقوم بالتخطيط، وهو ما يعني عادةً استدعاء نموذج لغوي كبير.
00:04:29ثم يتصرف، ربما عبر استدعاء أداة. بعد ذلك يلاحظ النتيجة ويضيفها مجددًا إلى السياق.
00:04:38ويكرر هذه العملية حتى تكتمل المهمة.
00:04:41لذا فإننا نتناوب باستمرار بين استدلال النموذج اللغوي وتنفيذ أداة واحدة أو أكثر خارج النموذج.
00:04:50وبالتالي توجد فجوة بين استدعاءات النموذج. كما يمكن للوكيل إنشاء وكلاء فرعيين وتشغيلهم بالتوازي.
00:05:01مدخلات الوكيل تبدو أيضًا مختلفة جدًا عن المحادثة. يُظهر الرسم البياني هنا توزيعات طول المحث والإكمال لتشغيل وكيل البرمجة الداخلي لدينا مع GLM 5.2، الذي نستخدمه يوميًا.
00:05:15إنها أطول بكثير، وتزداد مع تقدم المهمة نظرًا لإضافة كل ملاحظة مجددًا إلى السياق.
00:05:25هناك نمط مهم هنا: تشترك خطوات الوكيل المتتالية عادةً في بادئة (Prefix) ضخمة.
00:05:32إذا أعدنا حساب تلك البادئة نفسها في كل مرة، فإننا نستهلك قدرًا كبيرًا من المعالجة في عمل أنجزناه بالفعل.
00:05:40لذا تُعد هذه واحدة من أكبر الفرص المتاحة في مجال الاستدلال الوكيلي.
00:05:46إذن، ما مدى استهلاك الوكلاء للرموز (Tokens)؟
00:05:49دعونا ننظر الآن إلى مثال لمهمة ذات أفق طويل مثل البحث العميق.
00:05:53قمنا بشرح إطار فك التشفير التخميني (Speculative Decoding) في VLLM باستخدام كود kilocode مع GLM 5.2 على Friendly AI.
00:06:02توجد مراحل متعددة، وتتكون كل مرحلة من وكلاء فرعيين ينفذون استدلالات واستدعاءات أدوات متعددة.
00:06:12لذا فقد تُنفذ عشرات أو حتى مئات خطوات الاستدلال، وأحيانًا يستغرق ذلك دقائق أو ساعات.
00:06:19ويستمر السياق المشترك في النمو طوال الوقت.
00:06:23بالنسبة للمستخدم، ما يهم ليس زمن استجابة رمز واحد أو استدعاء واحد.
00:06:28بل ما يهم هو متى تكتمل المهمة.
00:06:35لذلك، فإن الاستدلال الوكيلي ليس مجرد محادثة بتدفق طلبات أكثر.
00:06:39بل هي مسألة مختلفة؛ فالسياق يتزايد بمرور الوقت.
00:06:43وعمل الأدوات يتخلل استدعاءات النموذج.
00:06:46كما أن عدد استدعاءات النموذج يعتمد على المدخلات.
00:06:49لذا لا يمكنك التخطيط بناءً على معدل طلبات ثابت.
00:06:55والمقياس الحقيقي هو زمن استجابة المهمة ككل، وليس زمن استجابة طلب واحد.
00:07:02إذن كيف نحقق ذلك؟ دعوني أريكم الهندسة الأساسية وراء الأمر.
00:07:23إليكم المخطط الهندسي لكيفية تعاملنا مع الموضوع.
00:07:27لقد بنينا البنية التحتية طبقة تلو الأخرى حول مسارات عمل الوكلاء.
00:07:33وهناك أربعة أركان رئيسية سأغطيها اليوم:
00:07:37التخزين المؤقت للبادئة (Prefix Caching)، وإدارة ذاكرة التخزين المؤقت للقيم والمفاتيح (KV Cache)، والتوجيه المعتمد على التخزين المؤقت، والتحسين المعتمد على الوكيل.
00:07:48وبالطبع، نحتاج في الأسفل إلى تحسينات على مستوى النموذج مثل الانتباه المتقطع (Sparse Attention) للسياقات الطويلة،
00:07:56وتقنيات لتقليل الأخطاء، ونوى معالجة سريعة (Fast Kernels)، وخدمة مرنة، وغيرها.
00:08:02في هذا العرض، سأركز على الأركان الأربعة.
00:08:05لنبدأ بالتخزين المؤقت للبادئة.
00:08:09بما أن خطوات الوكيل تشترك في بادئة كبيرة، فإننا نحسب القيم والمفاتيح للبادئة مرة واحدة ونخزنها مؤقتًا.
00:08:17ثم في الخطوات اللاحقة، نعيد استخدام القيم المخزنة ونعالج اللاحقة (Suffix) الجديدة فقط.
00:08:23تعد القراءة من الذاكرة المؤقتة أرخص بكثير من إعادة معالجة التعبئة الأولية (Prefill)،
00:08:27مما يحسن وقت الحصول على أول رمز (TTFT) ويقلل الجهد الحسابي في كل خطوة.
00:08:33وكلما طالت مدة تشغيل المهمة لدى الوكلاء، زادت قيمة هذه العملية.
00:08:41لكن التخزين المؤقت لا يعمل إلا إذا كانت ذاكرة KV تتسع بالفعل ويمكن نقلها بكفاءة.
00:08:48لذا نحتاج إلى إدارة قوية لذاكرة KV المؤقتة.
00:08:52نستخدم إدارة الذاكرة المجمعة لاستيعاب المزيد من السياقات النشطة في ذاكرة كل وحدة معالجة رسومات (GPU).
00:08:59ونستخدم تكميم KV (Quantization) لتقليل حجم الذاكرة المستهلكة.
00:09:04كما نستخدم التخزين المؤقت الهرمي عبر ذاكرة GPU، وذاكرة المضيف، والقرص الصلب، لتجاوز حدود ذاكرة الـ GPU.
00:09:13ونستخدم أيضًا التخزين المؤقت الموزع حتى تمكن خدمة بادئة واحدة عبر عدة نسخ، وليس فقط داخل مثيل واحد.
00:09:26وعلى مستوى المجموعات العالمية، يصبح التوجيه (Routing) أمرًا بالغ الأهمية.
00:09:29قد يقوم موزع الأحمال البسيط بتوزيع الطلبات بالتساوي عبر مجموعات GPU، لكن ذلك قد يقضي على الموضعية المكانية للتخزين المؤقت.
00:09:38بينما يقوم موجه البيانات الذكي على المستوى العالمي بعمل أكثر ذكاءً.
00:09:42إذ يرسل الطلب إلى وحدة تحتوي بالفعل على البادئة الصحيحة مخزنة مؤقتًا، مما يحول التعبئة الأولية المكلفة إلى إجابة سريعة من الذاكرة المؤقتة.
00:09:51وفي الوقت نفسه، يجب عليه موازنة الحمل حتى لا تتحول إحدى الوحدات إلى نقطة ضغط عالية.
00:09:58في هذا المثال، يتجه الطلبان الخاصان بالمهمة “أ” إلى الوحدة الأولى نفسها للحفاظ على موضعية التخزين المؤقت.
00:10:08الجزء التالي هو التحسين المعتمد على الوكيل.
00:10:11وهذا هو الأفق القادم لاستدلال الوكلاء.
00:10:16اليوم، تجدول معظم الأنظمة كل استدعاء للنموذج اللغوي كما لو كان مستقلًا.
00:10:21فهي لا تدرك حقًا أن هذا الاستدعاء جزء من برنامج وكيل أطول.
00:10:27لكن إذا كان محرك التحسين يدرك سياق مستوى الوكيل، فيمكنه اتخاذ قرارات أفضل.
00:10:33على سبيل المثال، استباق العمل الصحيح، أو القيام بالتعبئة الأولية التخمينية للسياق للخطوة التالية المحتملة، أو اتخاذ قرار أفضل لإخلاء الذاكرة المؤقتة بناءً على سياق مستوى الوكيل.
00:10:48لذا فإن الهدف هو تقليل زمن استجابة المهمة ككل، وليس فقط جعل استدعاء واحد يبدو سريعًا.
00:10:58عندما نجمع كل هذه التقنيات معًا، تكون هذه هي النتيجة.
00:11:01نحن نستخدم النموذج نفسه، GLM 5.2، مع kilocode لإنشاء لعبة جوال بسيطة.
00:11:07قمنا بتشغيل المهمة نفسها باستخدام واجهات برمجة تطبيقات Friendly AI ومزود استدلال آخر معروف.
00:11:14كما ترون، تُنجز Friendly AI المهمة نفسها بالكامل بشكل أسرع مرتين، بفضل تصميمنا السحابي المتمحور حول الوكيل.
00:11:24إذن، ما الذي يتيحه هذا على أرض الواقع؟
00:11:29بنية تحتية أقوى للوكلاء في بيئة الإنتاج.
00:11:32خذ وكيلًا تفضله بالفعل.
00:11:35واربطه بنماذج رائدة مفتوحة الأوزان مثل GLM 5.2 وMinimax وKimi المقدمة عبر Friendly AI.
00:11:43يمنحك النموذج قدرات بجودة رائدة وجدوى اقتصادية أفضل.
00:11:49وتمنحك Friendly AI السرعة والموثوقية وأداء المهام المطلوب لبيئة الإنتاج.
00:11:56هذا المزيج من الجودة والسرعة والموثوقية والتكلفة هو ما يجعل الوكلاء مفيدين واقتصاديين حقًا في بيئة الإنتاج.
00:12:06تدعم Friendly AI حاليًا فرق العمل في بيئة الإنتاج، بدءًا من الشركات الناشئة القائمة على الذكاء الاصطناعي وصولًا إلى الشركات العالمية.
00:12:15أود تسليط الضوء على نموذجين هنا.
00:12:20Kilo هي أداة برمجة وكيلية بالذكاء الاصطناعي تحظى بشعبية واسعة وتخدم ملايين المستخدمين.
00:12:27وLG هي شركة عالمية تتنوع أعمالها من الإلكترونيات إلى الرعاية الصحية والطاقة.
00:12:35شركات مختلفة تمامًا، لكنها تحتاج جميعها إلى الشيء نفسه:
00:12:39استدلال وكيلي سريع وموثوق واقتصادي.
00:12:45هذه الشهادة من عميلنا Kilo تلخص كل شيء.
00:12:50“على مدار العام الماضي، اختبرت Kilo code عدة مزودي استدلال يستضيفون نماذج مفتوحة ومغلقة.
00:12:56وفي اختبار مقارن لاستخدام GLM 5 مقابل مزودي خدمة آخرين والاستخدام المباشر من مختبر Zhipu AI،
00:13:05كانت Friendly AI أسرع باستمرار بمقدار سبع مرات وبمعدل أخطاء أقل بكثير.
00:13:12اليوم، تعد Friendly AI مكونًا أساسيًا في بنية Kilo.”
00:13:17ويمكنكم الاستفادة من ذلك بالطريقة التي تناسب بنيتكم التحتية.
00:13:23تعد واجهة برمجة تطبيقات النموذج أسرع طريقة للبدء.
00:13:26استخدم النماذج الرائدة مفتوحة الأوزان عبر واجهة برمجة التطبيقات خالية الخادم (Serverless).
00:13:29تمنحك نقاط النهاية المخصصة نشرًا مستقلاً ومعزولًا مع اتفاقيات مستوى خدمة مضمونة لأحمال عمل الإنتاج.
00:13:36ويتيح لك خيار BYOG (احضر الـ GPU الخاص بك) تشغيل استدلال Friendly على بنيتك التحتية الخاصة.
00:13:44البنية نفسها بثلاث طرق للنشر.
00:13:49ختامًا، هناك ثلاثة أمور يجب تذكرها:
00:13:53أولًا، تجعل النماذج الرائدة مفتوحة الأوزان وكلاء الإنتاج قابلين للتوسع اقتصاديًا.
00:13:59ثانيًا، الوكلاء ليسوا مجرد محادثة بتدفق استدعاءات أكبر.
00:14:03يتطلب الاستدلال الوكيلي تحسين زمن استجابة المهمة ككل مع مراعاة التحديات التي ذكرتها.
00:14:10ثالثًا، تم بناء Friendly AI كسحابة استدلال لهذا العالم.
00:14:16استدلال وكيلي سريع وموثوق واقتصادي.
00:14:23شكرًا لحضوركم جلستي.
00:14:25إذا كنتم تبنون وكلاء، جربوا النماذج الرائدة مفتوحة الأوزان على Friendly AI اليوم،
00:14:30يمكنكم البدء على Friendly AI خلال دقائق.
00:14:34وشكرًا لكم.
00:14:35سأكون متواجدًا بعد الجلسة.
00:14:37شكرًا لكم.
00:14:38شكرًا لكم.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기