مقالة | شيانغ شيانزي
رو فولي نشرت منشورًا على X لوضع حد لجدل تخفيض أسعار Xiaomi MiMo.
في 26 مايو، نشر حساب MiMo الرسمي على X إعلانًا: تخفيض دائم لأسعار سلسلة MiMo-V2.5، بأقصى تخفيض يصل إلى 99%. تسعير موحد لجميع أطوال السياق، وترقية حزم التوكنات بنسبة 5-8 أضعاف.
استمرت هذه الإعلانات في الانتشار عبر دائرة الذكاء الاصطناعي المحلية طوال الأسبوع بأكمله. كان رد فعل الصناعة الأول متنوعًا إلى عدة فئات. أكبر فئة قالت إنها "موجة أخرى من حرب الأسعار" — خلال العامين الماضيين، من Zhipu وDeepSeek وByteDance DouBao إلى Alibaba Tongyi، تتناوب النماذج الكبيرة المحلية على خفض الأسعار، ولا أحد يبقى خارج المنافسة.
الجانب الآخر يرى الأمور بتشاؤم: بعد أن أعلنت شاومي مؤخرًا أن أرباحها لهذا العام تراجعت إلى النصف، فإن الاستمرار في إنفاق 60 مليار يوان على الذكاء الاصطناعي وخفض تكاليف واجهات برمجة التطبيقات بنسبة 90% يُعد مثالًا نموذجيًا على "الاستثمار بخسارة للاستحواذ على السوق". كما يرى آخرون أن هذا تأثير مستمر من DeepSeek — التي سحبت معيار التسعير في الصناعة بأكملها إلى القاع، ومن لا يتبعه يُستبعد.
لذلك، كمسؤولة عن MiMo، قدمت لوفلي ليلة أمس مدونة تقنية بطول 5000 كلمة، وكشفت للجميع عن الحسابات الهندسية للتخفيض.
Look, this is real engineering capability, not marketing.
لفهم ما تقوله لو فولي، يجب أولاً أن تفهم ما الذي انخفض بالضبط بنسبة 99%.
ليس هناك تخفيض شامل على النموذج. الخصم البالغ 99% مخصص فقط لفئة تسعير تُسمى Input (Cache Hit) — أي الجزء المتعلق بـ"تكرار المستخدم قراءة السياق التاريخي في المحادثات الطويلة". أما الإدخالات الجديدة العادية (No Cache Hit)، فانخفاض أسعارها أقل بكثير، وأقل تخفيض يكون على مخرجات النموذج (Output).
إذا كنت ترى النموذج كمقهى، فسيكون من السهل فهم هذا الأمر.
تطلب كوبًا من لاتيه بنصف سكر، ويتّبع مقهى القهوة طريقتين: إما طحن حبوب القهوة وسكب شراب السكر وصب الحليب من البداية لكل كوب، حيث تُدفع تكاليف المواد والعمالة لكل كوب؛ لكن النموذج يعرف أنك ستشرب نفس كوب لاتيه بنصف سكر كل يوم هذا الأسبوع، لذا يُحضّر دلاءً كبيرًا ويُخزّنه في الثلاجة، ثم يأخذ كوبًا واحدًا في كل مرة عند الطلب. لقد اتبع MiMo هذه الطريقة الثانية — حيث حوّل الجزء المتكرر من قراءة المستخدم من "الحساب الفوري" إلى "الاستلام الفوري"، وبالتالي تصبح التكلفة الحقيقية لهذا الجزء قريبة من الصفر، مما يسمح بخصم 99%.
لتحقيق "الاستلام الفوري"، تناول مدونة التقنية ستة مشاريع هندسية، ولا يمكن لأي منها أن يغيب. دعونا نحللها واحدة تلو الأخرى.
المشروع الأول: تقليل "ذاكرة" النموذج إلى 1/7
عندما يتحدث النموذج معك، يتم حساب "حالة وسيطة" لكل رمز، ويتم تخزينها لاستخدامها في الخطوة التالية. يُسمى هذا الشيء KVCache — يمكن فهمه كـ "دفتر ملاحظات الذاكرة قصيرة المدى" للنموذج. عند قول جملة واحدة، يسجل النموذج ملخصًا لهذه الجملة في الدفتر، وفي المرة القادمة يراجع الملاحظات مباشرة دون الحاجة إلى الاستماع من جديد إلى كل ما قلته سابقًا.
في النماذج التقليدية، تقوم كل طبقة بـ"الانتباه الكامل" — أي أن كل رمز ينظر إلى جميع الرموز في المحادثة بأكملها، مما يجعل دفتر الملاحظات يزداد سُمكًا. لقد غيّر MiMo-V2.5-Pro البنية: في 70 طبقة، تنظر 60 طبقة فقط إلى آخر 128 رمزًا (SWA، الانتباه النافذة المنزلقة)، بينما تنظر 10 طبقات فقط كـ"مديري الأرشيف" إلى جميع الرموز.
النتيجة هي أن حجم KVCache تم تخفيضه مباشرة إلى 1/7 من حجم الانتباه الكامل، كما أن كمية الحسابات هي أيضًا 1/7.
هذا هو الأساس الأول لخفض التكاليف. لنأخذ مثالًا: سابقًا، كان يُطلب من كل موظف في الشركة حفظ جميع محاضر الاجتماعات، مما أدى إلى إرهاق عقول الجميع وانخفاض الكفاءة. الآن، خفّضت القاعدة الجديدة العبء الذهني على 60 موظفًا إلى سُبُعه، بحيث يُكلّف فقط 10 مسؤولين عن الملفات بإدارة جميع السجلات التاريخية — فلم تنخفض قدرة الشركة على التخزين، لكن الكفاءة زادت سبعة أضعاف.
المشروع الثاني: جعل المساحة التي تم توفيرها بواسطة SWA قابلة للاستخدام فعليًا
الخطوة الأولى هي ضغط الكمبيوتر المحمول إلى 1/7 من الناحية الهيكلية، لكن هناك عقبة واحدة يجب تجاوزها لتحويل "الـ 1/7 النظري" إلى "الـ 1/7 الفعلي".
يُوزِّع نظام KVCache التقليدي ذاكرة العرض على جميع الطبقات وفقًا لـ"الاستخدام المحتمل الأقصى". أي أنه حتى لو احتاجت 60 طبقة من SWA إلى دفتر صغير، فإن النظام يخصص لجميع الطبقات "دفتر مدير الملفات" — مما يعني أن المساحة التي توفرها SWA تُحتفظ بها عبثًا، كأنها لم تُوفَّر على الإطلاق.
يقوم فريق Luo Fuli بفصل KVCache إلى حوضين مستقلين. تستخدم الطبقات العشرة لـ Full Attention "الحوض الكبير" وتُخصص وفقًا للطول الكامل، بينما تستخدم الطبقات الستون لـ SWA "الحوض الصغير" وتُخصص وفقًا لنافذة قدرها 128 رمزًا.
على سبيل المثال، كانت الشركة تمنح كل موظف خزانة ملفات تكفي لتخزين مستندات لمدة 100 عام — لكن 60 موظفًا يحتاجون فقط إلى خزائن صغيرة تكفي لتخزين مستندات أسبوع واحد، حيث تكون 99٪ من مساحة الخزائن الكبيرة فارغة. الآن، يتم توزيع الخزائن وفقًا للحاجة الفعلية. النتيجة: يمكن للمساحة المكتبية أن تستوعب أكثر من خمسة أضعاف عدد الزملاء — حيث أصبحت وحدة GPU الواحدة قادرة على خدمة خمسة أضعاف عدد المستخدمين المتزامنين.
هذه الخطوة تبدو بسيطة، لكن بدونها، تكون مزايا بنية SWA السابقة قد تم تصميمها عبثًا.
المشروع الثالث: جعل "قراءة المستخدمين القدامى المتكررة" تُصيب الذاكرة المؤقتة فعليًا
تم ضغط الدفتر إلى 1/7 + المساحة قابلة للتحقيق حقًا، الخطوة التالية هي حل مشكلة قديمة: معدل إصابة ذاكرة التخزين المؤقت للبادئات.
يحتوي العديد من محادثات المستخدمين على نفس البداية — نفس مُحفّز النظام، نفس مكتبة الكود، نفس المستند الطويل. يقوم النظام بتخزين النتائج التي تم حسابها مسبقًا، ويُعيد استخدامها مباشرة عند التطابق التالي. تُسمى هذه الآلية التخزين المؤقت للبادئات.
لكن في نمط SWA، توجد مشكلة: تطابق طلبتين للرمز لا يعني أن KV لا يزال موجودًا. ربما تم حساب البادئة، لكن الأجزاء خارج نافذة SWA تم التخلص منها مسبقًا. إذا ما زال النظام يتبع القاعدة القديمة "إذا تطابق الرمز، فاستخدمه مرة أخرى"، فستقرأ بيانات غير صالحة أو مُستبدَلة، وسينهار أداء النموذج مباشرة.
فريق Luo Fuli قام بترقية القواعد إلى "طول النافذة الآمن" — حيث يُتعهد فقط بـ"الجزء الذي يمكنك اقتراضه بالكامل".
على سبيل المثال، إذا كان هناك مليون كتاب في المكتبة، وترغب في استعارة مجموعة مكونة من ثلاثة كتب من "ثلاثة جسد". كان الهيكل القديم سيقول لك "الكتاب متاح"، فتذهب لتجد أن الرف يحتوي فقط على الغلاف والجزء الأول، بينما تم استعارة الجزأين الثاني والثالث. هذا "الإيجاب الكاذب" جعلك تذهب مرتين وتضطر لإعادة طلب الكتاب. أما النظام الجديد، فيغير القاعدة ليتعهد فقط بالجزء الذي يمكنك استعارته بالكامل — فيعطيك أول كتاب، ثم يجلب لك الجزأين التاليين.
يبدو أن الأمر أكثر صرامة وسيقل معدل الدقة، لكن في الواقع العكس هو الصحيح: لأن SWA يقلص حجم KVCache إلى 1/7، يمكن للمساحة التخزينية نفسها استيعاب محتوى أكبر بضع مرات، مما يؤدي إلى زيادة كبيرة في معدل الدقة الفعلي.
قدمت روفلي أرقامًا تجريبية عبر الإنترنت في مدونتها: معدل توافق ذاكرة التخزين المؤقت للخادم تحت إطارات harness الرئيسية يبلغ متوسطه 93٪، ويمكن أن يصل إلى أكثر من 95٪ للمستخدمين ذوي التردد العالي والدورات الطويلة.
معنى هذا الرقم: 95% من طلبات "القراءة المتكررة" لا تحتاج إلى GPU على الإطلاق، بل تُسترجع مباشرة من الذاكرة المؤقتة. هذا هو الأساس المادي لخصم 99%.
المشروع الرابع: تثبيت "الذاكرة المؤقتة" داخل SSD المدمج في وحدة معالجة الرسوميات
ارتفعت دقة التنبؤ، والآن السؤال التالي: أين يتم تخزين هذه الذاكرة المؤقتة؟
ذاكرة الفيديو (ذاكرة HBM على وحدة معالجة الرسوميات) باهظة الثمن ومحدودة — جهاز H100 بثمانية بطاقات يحتوي فقط على 640 جيجابايت من ذاكرة الفيديو، لكن KVCache الذي يحتاجه MiMo قد يصل إلى عدة عشرات من التيرابايت. لذا يجب التصنيف: البيانات المستخدمة حديثًا تُخزن في ذاكرة الفيديو (L1)، والبيانات الأقدم قليلاً تُخزن في ذاكرة CPU (L2)، والبيانات غير النشطة تُخزن في التخزين المؤقت الموزع (L3).
مثل إدارة أموالك بنفس الطريقة. النقود في المحفظة هي الذاكرة الظاهرة — يمكنك استخدامها فورًا ولكن لا يمكن تخزين الكثير منها. رصيد بطاقتك البنكية هو ذاكرة CPU — يستغرق سحبها 30 ثانية ولكن يمكن تخزين كمية كبيرة. الودائع الثابتة هي ذاكرة التخزين المؤقت الموزعة من المستوى الثالث — يستغرق سحبها دقيقتين ولكنها أرخص بكثير.
الممارسة الشائعة في الصناعة هي إنشاء مجموعة تخزين منفصلة لـ L3، باستخدام طرازات مخصصة وغرف خوادم مخصصة، مع دفع إيجار شهري.
فريق تخزين Xiaomi يتبع نهجًا مختلفًا. لقد طوروا برمجيًا نظام تخزين مؤقت موزع يُسمى GCache، ويتم نشره مباشرة على وحدات SSD المدمجة في خوادم GPU — مع توزيعه بالتزامن مع مهام التدريب ومهمات الاستنتاج على نفس الخادم.
شخص آخر استأجر مستودعًا بالكامل لتخزين كمية كبيرة من البيانات؛ اكتشفت Xiaomi أن مرآب آلات GPU كان فارغًا، فوضعت البيانات مباشرةً فيه. ووفرت إيجار الشهر.
تكلفة التخزين الإضافية هي 0.
قوة هذا الأمر أكبر مما تبدو عليه. في حسابات قوة الحوسبة العادية للشركات التي تعمل بالذكاء الاصطناعي، تُعد تكلفة التخزين بندًا ثابتًا — كلما كان نموذجك أكبر وعدد المستخدمين أكثر، زاد طول فاتورة التخزين. لكن أسلوب GCache يلغي هذا البند تمامًا. بالاقتران مع حجم SWA الصغير + معدل الوصول 93-95٪، يمتد وقت بقاء KVCache في L3 (TTL) من دقائق إلى ساعات أو حتى أيام — كلما طال TTL، زادت فترة النافذة التي يمكن فيها تحقيق التخزين المؤقت للسياق التاريخي، وارتفع معدل الوصول إلى التخزين المؤقت، وبالتالي أصبح الخصم البالغ 99٪ أكثر قوة.
المشروع الخامس: توجيه الطلبات التي تُصادف ذاكرة التخزين المؤقت عبر أقصر طريق
الذاكرة المؤقتة يمكن تخزينها، واسترجاعها، وهي أيضًا اقتصادية؛ الخطوة الأخيرة هي: كيفية توجيه الطلبات الصحيحة إلى الخادم الصحيح.
طورت شاومي نظام جدولة خاصًا يُسمى LLM-Router، وقام بثلاث مهام:
أولاً، الجدولة المتماثلة. توجيه الطلبات ذات البادئة نفسها إلى نفس الخادم لتعظيم إعادة استخدام الذاكرة المؤقتة.
ثانيًا: تقسيم الطول إلى فئات. قسم الطلبات القصيرة (0-64K) والطلبات المتوسطة (64K-256K) والطلبات الطويلة (256K-1M) إلى قنوات معالجة مختلفة لتجنب تأثر الطلبات القصيرة بالطلبات الطويلة.
ثالثًا، تحسين TTFT. في قائمة الانتظار للحصول على الاستدلال، قم بجدولة أولوية الطلبات التي تتطلب كمية حسابية صغيرة فعليًا (أي الطلبات التي تُحقق ذاكرة التخزين المؤقت بكثرة) — لتجنب حجبها من قبل طلبات الإدخال الجديدة التي تتطلب حسابات ثقيلة.
على سبيل المثال، في جدولة المطارات العادية، يتم تجميع جميع الركاب المتجهين إلى نفس الوجهة في نفس الصالة، ومشاركة عملية استلام الأمتعة — وهذا تخصيص متماثل. يمر الركاب الذين يحملون أمتعة يدوية وركاب يحملون ثلاث حزم كبيرة في قنوات تفتيش منفصلة، بحيث لا يُبطئ السريعون البطيئين — وهذا تقسيم حسب الطول. عند الصعود، يُسمح أولاً للركاب الذين يحملون أمتعة يدوية فقط، لأنهم يصعدون بسرعة، مما يسمح للطائرة بالإقلاع مبكرًا — وهذا تحسين TTFT.
لقد رفعت هذه الاستراتيجية الجدولة فعليًا معدل إصابة ذاكرة التخزين المؤقت L2 بنسبة 25%، وزيادة إنتاجية الإدخال للخادم الواحد بنسبة 30%، وخفض تأخير الطلبات الطويلة P90 بنسبة 30%.
يمكن لوحدة GPU واحدة خدمة عدد أكبر من المستخدمين. هنا تكمن النصف الآخر من منطق التخفيض — الإنتاجية الفعالة لكل وحدة حسابية أعلى، وتكلفة كل مستخدم أقل.
المهمة السادسة: جعل النموذج يكتب أسرع
الأشياء الخمس الأولى تركز على تحسين جانب "القراءة" — أي خفض تكلفة تكرار المستخدم لسياق التاريخ إلى ما يقارب الصفر. الشيء السادس هو تحسين جانب "الكتابة" — أي عملية توليد الرمز التالي من قبل النموذج.
النماذج التقليدية تولد رمزًا واحدًا فقط في كل مرة. يدعم MiMo بشكل أصلي ثلاث طبقات من MTP (التنبؤ متعدد الرموز) — التنبؤ بالثلاثة رموز التالية دفعة واحدة، وإذا تنبأ بشكل صحيح بالرمز الأوسط، فتجاوز الحسابات الوسيطة مباشرة.
على سبيل المثال، الكتابة التقليدية تُدخل حرفًا حرفًا — إذا أردت كتابة "اليوم الطقس"، عليك الضغط 4 مرات. أما MTP، فهو يشبه ميزة التكملة التلقائية التي تتوقع الحرفين التاليين واحدًا أو اثنين — إذا أصابت التوقعات، فلن تحتاج إلى الضغط على تلك المفاتيح مرتين.
تم اختبار MTP الخاص بـ MiMo في سيناريوهات agentic: تم تسريع 128 رمزًا أوليًا بنسبة 2.3 مرة، و128-256 رمزًا بنسبة 1.5 مرة.
معنى هذا الأمر هو أن الخصم بنسبة 99% يشير بشكل خاص إلى Input (Cache Hit)، ولكن عندما يخدم النموذج المستخدمين فعليًا، فإن المدخلات والمخرجات تحدث في نفس الطلب — إذا لم يتم توفير المخرجات، فإن تكلفة الطلب الكاملة تُخفض فقط بنسبة النصف. يُخفض MTP النصف الخاص بالمخرجات أيضًا، مما يُكمل نموذج الربح الكامل للتخفيض.
ربط ستة أشياء في سلسلة خفض تكاليف:
هندسة SWA → KVCache 1/7 → إخلاء حقيقي للسعة عبر مزدوجة الخزانات → يمكن لوحدة GPU واحدة استيعاب أكثر من 5 أضعاف التزامن → معدل تطابق ذاكرة التخزين المؤقت للبادئات 93-95% → 95% من الطلبات لا تحتاج تقريبًا إلى حساب → GCache تجعل تكلفة التخزين تصل إلى الصفر → الجدولة تُقدّم أولوية طلبات التطابق → MTP توفر أيضًا في التوليد → وقت وحدة الطلب على GPU ينخفض بمقدار عامل عشرة → تكلفة الوحدة تنخفض بنسبة 95%+ → انخفاض التسعير بنسبة 99% مع بقاء هامش الربح الإجمالي إيجابيًا.
أي نقص في أي مرحلة من المراحل سيؤدي إلى انقطاع السلسلة في إحدى الحلقات. تخفيض 99% ليس رقمًا تسويقيًا، بل هو تأثير تراكمي ناتج عن دمج ستة دعامات هندسية بالإضافة إلى التحقق المباشر عبر الإنترنت.
بالعودة إلى التفسيرات الأولية التي طرحها القطاع، فإن كل منها يحتوي على جزء من الحقيقة. إن حرب الأسعار بين شركات النماذج الكبيرة في الصين خلال السنتين الماضيتين هي حقيقة؛ وخفض Xiaomi لأرباحها إلى النصف مع الاستمرار في الاستثمار في الذكاء الاصطناعي هو حقيقة؛ وخفض DeepSeek لأسعار الصناعة إلى أدنى مستوى ممكن هو أيضًا حقيقة.
لكن نشر روفلي هذه المرة مدونة تقنية علنية مع تفاصيل تقنية مفصلة يهدف بلا شك إلى الرد على ادعاءات حرب الأسعار، وجعل "المشكلات التقنية تعود للتقنية، ومشكلات التسويق تعود للتسويق."
كتبت في مدونتها أن كفاءة الاستدلال لسلسلة نماذج MiMo-V2.5 ليست نتيجة لاختراق فردي في مرحلة واحدة، بل هي نتيجة تحسين متزامن عبر عدة أبعاد. يُفيد Hybrid SWA كلًا من prefill وdecode، لكن تنفيذ KVCache غير المُحسَّن جيدًا قد يزيد التكاليف في جميع المراحل. حول هذا الهدف، أعاد فريق MiMo إعادة هيكلة منهجية لإدارة KVCache والتخزين المؤقت التصاعدي وشجرة التخزين المؤقت للبادئات، وحلّ مشكلات KVCache الأساسية لـ SWA، وحسّن استراتيجيات الجدولة ومسارات Prefill/Decode، وخضع ذلك لاختبارات في بيئات حقيقية عبر الإنترنت، مما مكنه في النهاية من تحويل مزايا الكفاءة النظرية إلى واقع إنتاجي. وهكذا، بدأ Hybrid SWA في إظهار ميزاته الهيكلية في القوة والكفاءة عند استدلال النصوص الطويلة. وبالدمج مع تكوينات MoE وتحسينات الاستدلال متعدد الوسائط، تم تعزيز أداء خدمات الاستدلال عبر الإنترنت بشكل كبير.
هذه مجموعة من الأساليب المنهجية للهندسة بالذكاء الاصطناعي، وهي وسيلة فعالة لخفض التكاليف تستحق أن يُسترشد بها الصناعة بشكل مشترك.
لا تحتاج حرب الأسعار إلى كتابة مدونات، بل تحتاج إلى تنفيذ هندسي.