شاومي مي مو تخفض السعر بنسبة 99% وليس مجرد حملة تسويقية! لوفلي يرد على المشككين عبر إكس ويصفهم بالفاشلين

لا شيء

نص | إي象先志

رو فولي أرسل تغريدة على إكس، ليضع حدًا لجدل خفض سعر مي ميكو من Xiaomi.

في 26 مايو، أصدر الحساب الرسمي لمي ميكو على إكس إعلانًا: تخفيض دائم لأسعار سلسلة API من MiMo-V2.5، بأقصى خصم 99%. جميع الأسعار للـ context موحدة، وترقية باقات Token من 5 إلى 8 مرات.

انتشرت هذه الإعلان في دائرة الذكاء الاصطناعي المحلية طوال أسبوع كامل. ردود الفعل في الصناعة انقسمت إلى عدة فصائل. أكبرها قال إن هذا "موجة جديدة من حرب الأسعار" — خلال العامين الماضيين، من Zhituo، DeepSeek، Byte Doudou، إلى Alibaba Tongyi، تتناقص أسعار النماذج المحلية، والجميع في سباق.

فصيل آخر نظر بتشاؤم: أعلنت Xiaomi أن أرباحها هذا العام انخفضت إلى النصف، وفي هذا الوقت تستثمر 600 مليار في الذكاء الاصطناعي، وتخفض API بنسبة تصل إلى 90% — وهو نمط "خسارة من أجل السوق". وهناك من رأى أن الأمر استمرار لتأثير DeepSeek — الذي وضع معايير التسعير في الصناعة عند أدنى مستوى، ومن لا يتبع يُخرج من السوق.

لذا، كمسؤول عن MiMo، رو فولي نشر ليلة أمس مدونة تقنية من 5000 كلمة، كشف فيها عن حسابات خفض السعر بشكل تفصيلي وعلني.

"انظر، هذه هي القدرة الهندسية الحقيقية، وليست مجرد وسيلة تسويقية".

لفهم ما يقوله رو فولي، يجب أن نفهم أولاً ما الذي انخفض بنسبة 99% تحديدًا.

ليس هو خفض كامل للنموذج. الخصم بنسبة 99% يخص سعر معين يسمى الإدخال (Cache Hit) — وهو الجزء الذي يقرأ فيه المستخدم التاريخ المتكرر في الحوار الطويل. أما الإدخالات الجديدة العادية (No Cache Hit)، فهي أقل خصمًا بكثير، وأقل انخفاضًا في مخرجات النموذج (Output).

إذا اعتبرت النموذج كأنه مقهى، فالأمر بسيط.

عند طلبك لاتيه نصف سكر، هناك طريقتان: إما طحن البن كل مرة، وصب الشراب والحليب، مع حساب العملة في كل مرة؛ أو أن النموذج يعرف أنك ستشرب نفس اللاتيه نصف السكر يوميًا، فيصنع كمية كبيرة ويخزنها في الثلاجة، وعند الطلب يسكب لك كوبًا منه. MiMo تتبع الطريقة الثانية — تخزين الجزء الذي يقرأه المستخدم بشكل متكرر من "حساب فوري" إلى "حصول فوري"، لذلك تكاليف هذا الجزء تقترب من الصفر، ويمكنها تقديم خصم 99%.

لتحقيق "الحصول الفوري"، هناك ستة تقنيات هندسية يجب تنفيذها، وكل واحدة لا بد منها. سنفصلها واحدة تلو الأخرى.

المشروع الأول: ضغط "ذاكرة" النموذج إلى 1/7

عند التفاعل معك، كل رمز (Token) يحتاج إلى حساب "حالة وسطية" وتخزينها لاستخدامها لاحقًا. يُسمى هذا KVCache — يمكن فهمه كـ"مفكرة الذاكرة قصيرة المدى" للنموذج. بعد كل جملة، يسجل النموذج ملخصها في المفكرة، وعند المرة القادمة يقرأ الملخص مباشرة بدلاً من إعادة الاستماع لكل المحتوى.

النماذج التقليدية تستخدم "الانتباه الكامل" في كل طبقة — أي أن كل رمز يقرأ كامل الحوار، مما يجعل المفكرة تزداد سمكًا مع كل طبقة. أما MiMo-V2.5-Pro فغيرت الهيكل: من بين 70 طبقة، 60 منها تقتصر على آخر 128 رمز (SWA، Sliding Window Attention)، و10 طبقات فقط تتابع كامل التاريخ.

النتيجة أن حجم KVCache انخفض إلى 1/7 من حجم الانتباه الكامل، مع تقليل الحسابات بنفس النسبة.

هذا هو الأساس الأول لتقليل التكاليف. على سبيل المثال، كان يُطلب من كل موظف أن يتذكر جميع محاضر الاجتماعات، مما يثقل أدمغتهم ويقلل الكفاءة. الآن، تقل عبء الذاكرة على 60 موظفًا إلى 1/7، مع بقاء 10 فقط يتابعون التاريخ كله — أي أن القدرة على التذكر لم تتراجع، والكفاءة زادت سبعة أضعاف.

المشروع الثاني: جعل مساحة SWA المُوفرة فعليًا قابلة للاستخدام

الهيكل يضغط المفكرة إلى 1/7، لكن لتحقيق "الواقع" من هذا الرقم، هناك حاجز آخر.

نظام KVCache التقليدي يخصص الذاكرة لكل طبقة على أساس "الحد الأقصى للاستخدام". بمعنى: حتى لو كانت 60 طبقة من SWA تحتاج فقط إلى دفتر صغير، يُخصص لها نفس حجم "الملف الكبير" المخصص للطبقات العشر، مما يضيع المساحة المُوفرة. أي أن المساحة التي وفرتها SWA تُحجز مسبقًا ولا تُستخدم.

طريقة فريق رو فولي هي تقسيم KVCache إلى حوضين مستقلين: الطبقات العشر التي تستخدم "الانتباه الكامل" تتشارك في "حوض كبير" يُخصص كامل الطول؛ و60 طبقة من SWA تتشارك في "حوض صغير" يُخصص فقط 128 رمزًا.

مثال: كانت الشركة توزع على كل موظف خزانة ملفات تتسع لمئة سنة، لكن 60 موظفًا فقط يحتاجون إلى خزائن صغيرة لأسبوع واحد. الخزائن الكبيرة فيها 99% من المساحة فارغة. الحل الجديد هو تخصيص خزائن حسب الحاجة، مما يتيح استيعاب أكثر من 5 أضعاف الموظفين في نفس المساحة — أي أن عدد المستخدمين المتزامنين على نفس الـ GPU زاد خمس مرات.

هذه الخطوة تبدو بسيطة، لكنها ضرورية، وإلا فإن مزايا هيكل SWA ستكون بلا فائدة.

المشروع الثالث: جعل "إعادة القراءة من قبل المستخدمين القدامى" فعلاً تصل إلى الكاش

ضغط المفكرة إلى 1/7 واستخدام المساحة بشكل فعال، يتطلب حل مشكلة معدل نجاح الكاش في التحقق من المقدمة.

العديد من المستخدمين لديهم حوارات تبدأ بنفس الطريقة — نفس المقدمة، نفس قاعدة البيانات، نفس المستندات الطويلة. يُخزن النظام النتائج المحسوبة مسبقًا، وعند تكرار الطلب، يُعاد استخدامها مباشرة. يُسمى هذا نظام الكاش للمقدمة.

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

فريق رو فولي قام بتحديث القاعدة إلى "طول النافذة الآمن" — أي أن يُعتمد فقط على الجزء الذي يمكن استرجاعه بشكل كامل.

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

قد يبدو هذا أكثر صرامة، وقد ينخفض معدل النجاح، لكن العكس هو الصحيح: مع تقليل حجم KVCache إلى 1/7، يمكن تخزين محتوى أكبر، ويزداد معدل النجاح الحقيقي بشكل كبير.

مدونة رو فولي أظهرت أرقامًا من الاختبارات الحية: معدل نجاح الكاش في الخوادم باستخدام إطار عمل رئيسي يتجاوز 93%، ويصل إلى أكثر من 95% للمستخدمين المتكررون.

معنى ذلك: 95% من الطلبات المتكررة لا تحتاج إلى حساب GPU، وتُؤخذ مباشرة من الكاش. وهذا هو الأساس الفيزيائي لخصم 99%.

المشروع الرابع: وضع "الكاش" في SSD المدمج مع GPU

مع ارتفاع معدل النجاح، السؤال التالي: أين يُخزن الكاش؟

ذاكرة الفيديو (HBM) غالية جدًا ومحدودة — حاسوب H100 بثماني بطاقات يحتوي على 640 جيجابايت، لكن KVCache قد يكون بحجم عشرات التيرابايت. لذلك، يُنظم بشكل هرمي: البيانات الأكثر استخدامًا تُخزن في الذاكرة القريبة (L1)، والبيانات الأقدم تُخزن في ذاكرة CPU (L2)، والبيانات الباردة تُخزن في ذاكرة مخزنة موزعة (L3).

كما تدير أموالك: النقود في محفظتك هي الذاكرة المباشرة، متاحة عند الطلب، لكن لا يمكن تخزين الكثير؛ رصيد بطاقتك البنكية هو الذاكرة في CPU، يستغرق 30 ثانية للوصول، لكنه كبير؛ والودائع الثابتة هي الذاكرة الموزعة، تستغرق 2 دقيقة، ورخيصة.

الممارسات التقليدية تقتضي إنشاء نظام تخزين خاص لـ L3، بمعدات خاصة ومراكز بيانات مخصصة، مع دفع الإيجار شهريًا.

لكن فريق Xiaomi طور نظام GCache — مخزن موزع يُنصب مباشرة على SSD المدمج في جهاز GPU، ويعمل مع مهام التدريب والاستدلال في نفس الجهاز.

بمعنى آخر: بدل استئجار مستودع لتخزين البيانات، اكتشفوا أن حظيرة السيارات في جهاز GPU فارغة، فقاموا بتخزين البيانات فيها مباشرة، مما وفر تكاليف الإيجار.

المدونة تقول: "تكلفة التخزين الإضافية تساوي صفرًا".

هذه النقطة لها تأثير كبير. في حسابات الحوسبة التقليدية للذكاء الاصطناعي، تكاليف التخزين تعتبر مصروفًا ثابتًا — كلما زاد حجم النموذج وعدد المستخدمين، زادت فاتورة التخزين. GCache يلغى هذا البند تمامًا. مع تقليل حجم SWA إلى حد كبير، ومعدل نجاح الكاش 93-95%، فإن مدة بقاء KVCache في L3 (TTL) تتراوح من دقائق إلى ساعات أو أيام — وكلما زادت مدة TTL، زادت فرصة استرجاع السياق التاريخي، وارتفعت نسبة النجاح، وارتفعت نسبة الخصم إلى 99%.

المشروع الخامس: توجيه الطلبات التي تصل إلى الكاش بأقصر الطرق

مع ارتفاع معدل النجاح، السؤال التالي: كيف نوجه الطلبات بشكل صحيح إلى الأجهزة المناسبة؟

طورت Xiaomi نظام جدولة خاص يُسمى LLM-Router، قام بثلاث مهام:

أولاً: التوافقية. الطلبات ذات المقدمة المماثلة تُوجه إلى نفس الجهاز، لتعظيم إعادة استخدام الكاش.

ثانيًا: تصنيف الطول. الطلبات القصيرة (0-64 كيلوبايت)، والمتوسطة (64-256 كيلوبايت)، والطويلة (256 كيلوبايت - 1 ميجابايت) تُوجه إلى قنوات معالجة مختلفة، لتجنب أن يُبطئ الطلب الطويل الطلب القصير.

ثالثًا: تحسين TTFT. في قائمة الانتظار، يُعطى أولوية للطلبات ذات الحسابات الصغيرة (أي التي تصل إلى الكاش بشكل كبير)، لتجنب أن تُعيق الطلبات ذات الإدخالات الجديدة الحسابات الثقيلة.

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

هذه الاستراتيجية زادت معدل نجاح الكاش في L2 بنسبة 25%، وزادت معدل المعالجة على الجهاز بنسبة 30%، وخفضت زمن تأخير الطلبات الطويلة بنسبة 30%.

بمعنى آخر: يمكن لخادم GPU أن يخدم المزيد من المستخدمين. جزء آخر من خفض السعر يكمن هنا — زيادة الإنتاجية لكل وحدة حساب، وتقليل تكلفة المستخدم لكل حساب.

المشروع السادس: تسريع عملية "الكتابة" للنموذج

الخمسة مشاريع السابقة كانت تركز على تحسين "القراءة" — تقليل تكلفة قراءة السياق التاريخي إلى الصفر تقريبًا. المشروع السادس يركز على تحسين "الكتابة" — أي عملية توليد الرمز التالي من النموذج.

النماذج التقليدية تنتج رمزًا واحدًا في كل مرة. MiMo يدعم بشكل أصلي تقنية Multi-Token Prediction (MTP) بثلاث طبقات — يتوقع الرموز الثلاثة التالية دفعة واحدة، وإذا كانت التوقعات صحيحة، يتخطى الحسابات الوسيطة.

مثال: الكتابة التقليدية كأنك تكتب كلمة كلمة — إذا أردت كتابة "اليوم الطقس جميل"، تحتاج إلى 4 ضغطات. مع MTP، هناك نوع من الإكمال التلقائي، يتوقع لك 1-2 رموز تالية، وإذا كانت التوقعات صحيحة، تتخطى الضغطات.

اختبار MiMo في سيناريوهات الوكالة أظهر أن سرعة التوليد قبل 128 رمز زادت بمقدار 2.3 مرة، و128-256 رمز زادت بمقدار 1.5 مرة.

هذه الخاصية مهمة لأنها تركز على الجزء الذي يخص الإدخال (Cache Hit)، لكن في الواقع، عند خدمة المستخدم، الإدخال والإخراج يحدثان في نفس الطلب — إذا لم يُخفض الإخراج، فإن التوفير في التكاليف يقتصر على نصف الطلب فقط. MTP يقلل من تكلفة الإخراج أيضًا، مما يُكمل نموذج الربح من خفض السعر.

ملخص سلسلة المشاريع:

هيكل SWA → KVCache 1/7 → تحرير حقيقي للذاكرة عبر الحوض المزدوج → استيعاب أكثر من 5 أضعاف المستخدمين على نفس الـ GPU → معدل نجاح الكاش 93-95% → 95% من الطلبات لا تحتاج إلى حساب → GCache تزيل تكاليف التخزين → جدولة الطلبات التي تصل إلى الكاش بسرعة → MTP يسرع التوليد → زمن GPU لكل طلب ينخفض بشكل كبير → تكلفة الوحدة تنخفض بنسبة 95%+ → خفض السعر بنسبة 99%، مع بقاء الربحية إيجابية.

أي حلقة مفقودة في هذه السلسلة تُوقفها. خفض 99% ليس مجرد رقم تسويقي، بل هو تراكم لستة أعمدة هندسية ونتائج حقيقية من الاختبارات الحية.

عند مراجعة التفسيرات المختلفة في الصناعة، كل منها يحمل جزءًا من الحقيقة. حرب الأسعار بين شركات النماذج الكبيرة في الصين حقيقية؛ وخفض أرباح Xiaomi مع استثمار 600 مليار في AI حقيقي؛ وتثبيت DeepSeek للأسعار عند أدنى مستوى حقيقي.

لكن، مدونة رو فولي التقنية وتفصيلها الدقيق، بلا شك، تهدف إلى الرد على تلك التفسيرات، وتأكيد أن "المسائل التقنية تقنية، والتسويق تسويق".

كتبت في المدونة أن كفاءة استدلال سلسلة MiMo-V2.5 ليست نتيجة نقطة واحدة، بل نتيجة تحسين متعدد الأبعاد. تقنية Hybrid SWA تسمح بتحسين كل من ملء النموذج (prefill) والتوليد (decode) في آن واحد، لكن تنفيذ KVCache غير المحسن بشكل كاف قد يرفع التكاليف في كل مرحلة. استهدفت فريق MiMo إعادة بناء إدارة KVCache، والتخزين الهرمي، وشجرة الكاش للمقدمة، ومعالجة مشكلة KVCache في SWA، وتحسين استراتيجيات الجدولة، وتحسين روابط الملء والتوليد، واختبارها في سيناريوهات حية، وأخيرًا، تحويل الكفاءة النظرية إلى أداء عملي في بيئة الإنتاج. عندها فقط، يمكن لنظام Hybrid SWA أن يظهر مزاياه في استدلال النصوص الطويلة، مع توازن بين القوة والكفاءة. ومع دمج تكوين MoE وتحسينات متعددة في الاستدلال متعدد الوسائط، زادت بشكل كبير من أداء خدمات الاستدلال على الإنترنت.

هذه منهجية هندسية منهجية، وتعد وسيلة فعالة لخفض التكاليف، وتستحق أن تتعلم منها الصناعة.

حرب الأسعار لا تحتاج إلى مدونات، وإنما تحتاج إلى تنفيذ هندسي فعلي.