خلاصة لينكدإن: نموذج وكلاء بـ24 مليار معامل يعمل على جهازك، وllm-d 1.0 يعلّم Kubernetes خدمة الوكلاء، وبيتشاي يسعّر الواجهة
نموذج LFM2.5-24B-A2B من Liquid AI يضع MoE بـ2.4 مليار معامل نشط على الحواسيب المحمولة، وllm-d من Google Cloud يبلغ الإصدار 1.0 كحزمة استدلال أصيلة في Kubernetes، وسوندار بيتشاي يخبر Big Technology أن إيرادات السحابة تأتي بعد حسابات الواجهة. تم التحقق من مصادر أولية عامة.
ثلاثة منشورات عامة على LinkedIn من اليومين الماضيين، وثلاث طبقات من حزمة الوكلاء تتحرك معاً: نموذج صغير بما يكفي لتشغيل وكلاء على جهازك الخاص، وطبقة التقديم التي تُبقي ألف وكيل مزوّدة في مركز بيانات، والرئيس التنفيذي لـGoogle يقول علناً إن إيرادات السحابة تنتظر خلف حسابات الواجهة. اقتباسات قصيرة وروابط ورأيي. لا شيء هنا مأخوذ من موجز أي شخص الخاص.
الخلاصة القصيرة
كل عنصر بدأ كمنشور عام على LinkedIn؛ لم أستطع فتح المنشورات نفسها (LinkedIn يتطلب تسجيل الدخول)، لذا تم التحقق من كل عنصر أدناه مقابل المصدر الأولي العام الذي يشير إليه: بطاقة نموذج Liquid AI ومدونة الإطلاق، ومدونة Google Cloud ومستودع llm-d، ونص مقابلة Big Technology نفسه. حيث يأتي رقم من قياس أداء المورّد نفسه، يذكر العنصر ذلك. تصريحات بيتشاي هي ادعاءات من مقابلة ومُعلَّمة كذلك. قرأت هذه الصفحات في 21 أكتوبر 2026.
كارون ثانكاتشان: نموذج LFM2.5-24B-A2B من Liquid AI، شبكة MoE بـ24 مليار معامل و2.4 مليار معامل نشط للوكلاء على الجهاز
"LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters, built for fast, private agents on-device."
بطاقة نموذج Liquid AI، الصفحة التي أشار إليها منشور LinkedIn. بطاقة النموذج · مدونة الإطلاق · المنشور الأصلي
رأيي: أرقام الهندسة في البطاقة تتطابق مع ادعاءات المنشور: 24.0 مليار معامل إجمالاً مع 2.45 مليار نشط لكل رمز، 40 طبقة (30 كتلة التفاف قصير مزدوج البوابة زائد 10 كتل انتباه GQA)، 64 خبيراً لكل كتلة MoE مع توجيه top-4، ميزانية تدريب 36 تريليون رمز، مفردات 128K وسياق 131,072 رمزاً. ما بعد التدريب هو ضبط دقيق خاضع للإشراف زائد مرحلتا تقطير on-policy متعددة المجالات زائد تعلم معزز وكيل داخل أُطر وكلاء حقيقية (OpenClaw وHermes Agent وPi وOpenCode)، فالنموذج مدرَّب حرفياً على الأدوات وموجهات النظام التي سيلقاها في العمل. البطاقة تقدم ستة صيغ: BF16 الأصلي وFP8 وGGUF وONNX وMLX 4-bit ومتغير مسودة للترميز التخميني. الصدق اللافت في التموضع: تقول Liquid بوضوح إن النموذج "غير موصى به للمهام الكثيفة معرفياً بمفرده" ويجب إقرانه بالاسترجاع، وجدولها نفسه يظهر خسارته أمام Qwen3.6-35B-A3B في GPQA (74.42 مقابل 83.69) وSWE-Bench Verified (51.0 مقابل 66.2) وWebArena (26.75 مقابل 37.62) بينما يفوز في صفوف استخدام الأدوات الوكيلة (LiveClaw 48.09 مقابل 38.19 وToolSandbox 80.71 مقابل 75.02). هذا عضو استدعاء أدوات لا موسوعة - وهذا هو المقايضة الصحيحة لنموذج يُفترض أن يعيش داخل إطار. ادعاءات السرعة قياسات المورّد: 184 رمز/ث على Apple M5 Max و114 على Ryzen AI Max+ 395 (llama.cpp وQ4_K_M وسياق 4K) وأكثر من 21K رمز إخراج/ث على B300 واحد عند تزامن عالٍ. الرخصة هي LFM Open License v1.0 الخاصة بـLiquid: بلا إتاوات، لكن الاستخدام التجاري يشترط بقاء إيرادات منظمتك السنوية تحت عتبة 10 ملايين دولار، فهي ليست رخصة OSI وتحتاج الشركات الأكبر اتفاقاً منفصلاً. كما رُصد اليوم، تظهر البطاقة نحو 16.9 ألف تنزيل في الشهر الماضي و538 إعجاباً منذ الرفع في 12 أكتوبر.
لم يُتحقق منه: كل أرقام الأداء والسرعة من تجارب Liquid نفسها على إطارها وعتادها؛ لم أشغّل النموذج. إطار "منافس لنموذج أكبر بنحو 50%" يستند إلى الصفوف الوكيلة في جدول واحد اختاره المورّد. لا بيانات التدريب ولا كوده منشورة - البطاقة توثق مراحل الوصفة لا البيانات.
مارك لوماير: llm-d 1.0 يصل إلى التوفر العام، الحزمة الأصيلة في Kubernetes للاستدلال الموزع
"Today at the PyTorch Conference, we released llm-d 1.0, an open-source, Kubernetes-native stack for distributed LLM inference."
مدونة Google Cloud، 20 أكتوبر 2026، بقلم لوماير نفسه. مدونة Google Cloud · المستودع (Apache-2.0) · المنشور الأصلي
رأيي: يقف llm-d فوق vLLM وSGLang ويحوّل عنقود خوادم النماذج إلى تجمع واحد منسق: توجيه واعٍ بالتخزين المؤقت للبادئات وبالحمل، وتفريغ متدرج لذاكرة KV (ذاكرة المضيف وSSD وGoogle Cloud Managed Lustre)، وفصل prefill/decode تديره DisaggregatedSet الجديدة، وتحكم في التدفق متعدد المستأجرين، ومعالج غير متزامن يشغّل المهام الدفعية في السعة الفائضة دون تجويع الحركة التفاعلية. قصة الإصدار 1.0 موجهة مباشرة إلى حركة الوكلاء: التوجيه الواعي بالجلسة يُبقي دورات الوكيل على النسخ المتماثلة التي تحفظ سياقه أصلاً، والتقسيم الزمني يتيح لعمليات RL مشاركة المسرّعات مع الاستدلال، وهو ما تقول Google إنه يرفع دورة عمل المسرّعات من نحو 40% إلى أكثر من 70%. الأرقام في المنشور من المورّد لكنها محددة: على عبء عمل ترميز وكيل على Ironwood TPU، خفّض التوجيه الواعي بالبادئات مع التفريغ إلى ذاكرة المضيف زمن أول رمز الوسيط بأكثر من 85% ورفع الإنتاجية 2.4 ضعفاً مقابل Kubernetes Service عادي؛ منصة Gemini نفسها ضاعفت معدل إصابات ذاكرة البادئات من 35% إلى 70% عبر GKE Inference Gateway؛ ونشر على 17,000 عقدة متعدد المناطق وسّع الإنتاجية 2.9 ضعفاً عبر ثلاثة عناقيد بنجاح 99.9%. اقتباسات العملاء تسمي استخداماً حقيقياً: Snap تبلغ عن 75-80% إصابات ذاكرة بادئات، وZenteiQ تدعي 4 أضعاف الإنتاجية الإجمالية لتوليد البيانات الاصطناعية، ومهندسو الاستدلال في Mistral يقولون إنهم يفرضون نطاقات أولوية بين الفئات التجارية به. المشروع جهد CNCF Sandbox شارك في تأسيسه Red Hat وGoogle Cloud وIBM Research وCoreWeave وNVIDIA، بأكثر من 500 مساهم من 25 مؤسسة؛ المستودع برخصة Apache-2.0 ويظهر 4,917 نجمة و870 تفريعاً كما رُصد اليوم. ومن المهم ما تعنيه 1.0 هنا: واجهات v1 وتوافر عالٍ للموجّه وتحديثات متداولة بلا توقف - الأجزاء المملة التي تجعل طبقة التقديم قابلة للتبني.
لم يُتحقق منه: كل أرقام الأداء من Google أو شركائها، مقاسة على أعباء عملهم وعتادهم؛ لم أنشر llm-d. أرقام منصة Gemini تصف حركة إنتاج Google الخاصة، وهو استخدام حقيقي لكنه ليس تقييماً مستقلاً.
أليكس كانتروفيتز: سوندار بيتشاي عن التحسين الذاتي التكراري وضائقة الحوسبة
"Our cloud business is at any given moment in time forgoing short-term revenues because we are making compute trade-offs to support frontier AI development."
مقابلة Big Technology، نُشرت في 20 أكتوبر 2026، وسُجلت في مقر Google في ماونتن فيو. كل ما في هذا العنصر هو ما قاله بيتشاي في مقابلة - ادعاءات طرف معني، لا حقائق مدققة. المقابلة · المنشور الأصلي
رأيي: ثلاث فقرات تحمل الثقل. بشأن التحسين الذاتي التكراري، يؤكد بيتشاي ملاحظة سيرغي برين بأن RSI ساهم في نموذج Gemini 4 Argon الجديد، لكنه يرسم الخط بدقة: "اليوم، في متصَّلة، نحن بعيدون جداً عن الحالة النهائية لـRSI" - الموجود الآن هو "وكلاء يساعدون باحثي الذكاء الاصطناعي بطريقة آلية على العمل معاً لبناء هذه النماذج". بشأن الطلب، يقول إن Argon عالج نحو 25 تريليون رمز في أول 72 ساعة، نحو ثلاثة أضعاف نافذة إطلاق Gemini 3، وإن Google مقيد بالسعة أثناء تقديمه؛ وداخلياً ينسب إلى Argon زيادة 30% في قوائم التغيير وانخفاضاً بالثلث في التراجعات خلال أربعة أسابيع. وبشأن ضائقة الحوسبة، رداً على ملاحظة آندي جاسي "مباع حتى 2028"، لم يرمش: عميل يطلب حوسبة في 2027 يواجه شيئاً "صعباً بشكل لا يصدق"، ومع ذلك يرفض مقارنة الألياف المظلمة - "نحن نستخدمها. نحن مقيدون بالسعة يومياً" - مع إقراره بأن الإفراط في البناء ممكن إذا اختنق أي من "ألفي مكوّن أو أكثر" (الذاكرة والكهرباء والكهربائيين والأرض). الإطار الأكثر دلالة بالنسبة لي هو ترتيب الأولويات الذي يذكره صراحة: وصول DeepMind إلى حوسبة الواجهة "غير قابل للتفاوض"، وأعمال السحابة تخطط حول ما تبقى، والإيرادات السحابية المفقودة هي ببساطة "حقيقية أصلاً". ولمراقبي السلامة، جوابه عن حوادث الوكلاء هو الدفاع المتعمق - عمل المحاذاة زائد المراقبة الفورية والعزل، وفي النهاية معايير مشتركة بين الصناعات مع مقيّمين مستقلين، "مثل الضوابط المالية... مدققون مستقلون".
لم يُتحقق منه: هذه تصريحات رئيس تنفيذي في مقابلة ودية. أحجام الرموز وأرقام قوائم التغيير والتراجعات وادعاءات السعة أرقام Google الخاصة بلا تأكيد خارجي؛ وتقييم RSI موقف لا قياس.
كيف تُصنع هذه الخلاصة
تُختار العناصر من منشورات LinkedIn العامة بواسطة ماسح، ثم يُتحقق من كل منها مقابل المصدر الأولي العام الذي يشير إليه: بطاقة النموذج ومدونة المورّد، ومدونة الهندسة والمستودع، ونص المقابلة. منشورات LinkedIn نفسها تتطلب تسجيل الدخول ولم تُفتح؛ الروابط مقدمة للمرجع. لا تُستخدم عدادات التفاعل، ولم أتصل بالمؤلفين، ولا شيء هنا من موجز خاص.
- https://huggingface.co/LiquidAI/LFM2.5-24B-A2B
- https://www.liquid.ai/blog/lfm2-5-24b-a2b
- https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference
- https://github.com/llm-d/llm-d
- https://www.bigtechnology.com/p/sundar-pichai-googles-frontier-imperative