लेख | शांति
Lufei posted on X to put an end to the price drop controversy surrounding Xiaomi MiMo.
26 मई को, मिनी MiMo ऑफिशियल अकाउंट ने X पर एक घोषणा जारी की: MiMo-V2.5 सीरीज़ API की कीमत स्थायी रूप से कम कर दी गई है, जिसमें अधिकतम 99% की कमी है। सभी कॉन्टेक्स्ट लंबाई के लिए एक समान मूल्य निर्धारित किया गया है, और Token पैकेज में 5-8 गुना वृद्धि की गई है।
यह घोषणा पिछले एक सप्ताह तक देशी AI समुदाय में वायरल रही। उद्योग की पहली प्रतिक्रिया कई वर्गों में बंट गई। सबसे बड़ा समूह कहता है कि यह "एक और कीमत प्रतिस्पर्धा" है—पिछले दो वर्षों में, Zhishu, DeepSeek, ByteDance DouBao और Alibaba Tongyi के साथ, घरेलू बड़े मॉडल एक-एक करके कीमतें कम कर रहे हैं, और कोई भी इससे बाहर नहीं है।
दूसरी ओर, निराशावादी कहते हैं: जब शाओमी ने घोषणा की कि इस वर्ष लाभ आधा हो गया है, तब भी यह 600 अरब रुपये AI में खर्च कर रहा है और API को 90% तक काट रहा है—यह स्पष्ट रूप से "नुकसान के साथ बाजार प्राप्त करने" का उदाहरण है। कुछ लोगों का मानना है कि यह डीपसीक के प्रभाव का जारी रहना है—जिसने पूरे उद्योग के मूल्य निर्धारण के मानक को फर्श तक खींच लिया है, जो कोई इसके साथ नहीं बढ़ेगा, वह बाहर हो जाएगा।
इसलिए, मिमो के प्रमुख के रूप में, रो फुली ने कल रात सीधे 5000 शब्दों का एक तकनीकी ब्लॉग पेश किया और सभी के सामने छूट की इंजीनियरिंग खातेबही प्रकाशित कर दी।
देखें, यह वास्तविक इंजीनियरिंग क्षमता है, न कि मार्केटिंग का जुगाड़।
रोफली की बात समझने के लिए, पहले यह समझना जरूरी है कि यह 99% किसमें कमी आई है।
यह पूरे मॉडल की कीमत में कमी नहीं है। 99% की छूट केवल एक विशिष्ट मूल्य निर्धारण, अर्थात "Input (Cache Hit)" पर लागू होती है—जो "उपयोगकर्ता लंबी बातचीत में पिछले संदर्भ को दोहराकर पढ़ता है" का हिस्सा है। सामान्य नए इनपुट (No Cache Hit) पर छूट काफी कम है, और मॉडल आउटपुट (Output) पर छूट सबसे कम है।
अगर आप मॉडल को एक कॉफी शॉप के रूप में समझते हैं, तो यह बात समझने में आसान हो जाती है।
आप एक हाफ-स्वीट लैटे ऑर्डर करते हैं, और कॉफी शॉप में दो तरीके हैं: हर बार बीन्स को नए सिरे से ग्राइंड करना, सिरप डालना, दूध डालना—हर बार सामग्री और मजदूरी का खर्च होता है; लेकिन मॉडल जानता है कि इस हफ्ते आप प्रतिदिन एक ही हाफ-स्वीट लैटे पीने वाले हैं, इसलिए यह एक बड़ा बर्तन बना देता है और उसे फ्रिज में स्टोर कर देता है, और अगली बार प्रत्येक कप के लिए एक-एक करके निकाल लेता है। MiMo ने इस बार दूसरा तरीका अपनाया है—उपयोगकर्ता के दोहराए जाने वाले पढ़ने के हिस्से को "वास्तविक गणना" से "वास्तविक प्राप्ति" में बदल दिया है, इसलिए इस हिस्से की वास्तविक लागत लगभग 0 है, और 99% की छूट स्वाभाविक रूप से संभव होती है।
"कैश एंड कैरी" के लिए, तकनीकी ब्लॉग में छह इंजीनियरिंग घटकों का उल्लेख किया गया है, जिनमें से कोई भी अनिवार्य नहीं है। आइए एक-एक करके इन्हें विस्तार से देखें।
प्रोजेक्ट 1: मॉडल की "मेमोरी" को 1/7 तक कम करें
मॉडल आपसे बात करते समय प्रत्येक टोकन के लिए एक "मध्यवर्ती स्थिति" गणना करता है और अगले कदम के लिए इसे संग्रहित करता है। इसे KVCache कहते हैं—इसे मॉडल की "अल्पकालिक स्मृति नोटबुक" के रूप में समझा जा सकता है। हर वाक्य कहने पर, मॉडल नोटबुक पर इस वाक्य का सारांश लिख लेता है, और अगली बार सीधे नोट्स देखकर आपके पिछले सभी शब्दों को फिर से सुनने की जरूरत नहीं पड़ती।
पारंपरिक मॉडल में प्रत्येक परत "पूर्ण ध्यान" करती है—यानी प्रत्येक टोकन पूरे संवाद के सभी टोकन को देखता है, जिससे नोटबुक लगातार मोटी होती जाती है। MiMo-V2.5-Pro ने आर्किटेक्चर बदल दिया है: 70 परतों में से 60 परतें केवल नवीनतम 128 टोकन को देखती हैं (SWA, Sliding Window Attention), केवल 10 परतें "आर्काइव कीपर" के रूप में सभी टोकन को देखती हैं।
परिणामस्वरूप, KVCache का आकार पूर्ण ध्यान के 1/7 तक सीमित हो जाता है, और गणना की मात्रा भी 1/7 है।
यह लागत कम करने की पहली नींव है। एक उदाहरण दें, पहले कंपनी के प्रत्येक कर्मचारी को सभी मीटिंग रिकॉर्ड याद रखने की आवश्यकता थी, जिससे हर किसी का मस्तिष्क अपर्याप्त था और कार्यक्षमता कम थी। नए नियम ने 60 कर्मचारियों के मस्तिष्क पर भार को 1/7 तक कम कर दिया है—केवल 10 आर्काइव प्रबंधक सभी इतिहास का प्रबंधन करते हैं—कंपनी की कुल स्मृति क्षमता में कमी नहीं आई, लेकिन कार्यक्षमता 7 गुना बढ़ गई।
प्रोजेक्ट 2: SWA द्वारा बचाया गया स्थान वास्तव में उपयोग करने योग्य बनाएं
लैपटॉप को एक-सातवें हिस्से तक दबाना एक आर्किटेक्चरल चरण है, लेकिन "सैद्धांतिक एक-सातवाँ हिस्सा" को "वास्तविक एक-सातवाँ हिस्सा" में बदलने के लिए एक बाधा है।
पारंपरिक KVCache प्रणाली सभी परतों के लिए "अधिकतम संभव उपयोग" के आधार पर वीडियो मेमोरी आवंटित करती है। इसका मतलब है: भले ही 60 परतों को SWA को छोटी कॉपी की आवश्यकता हो, प्रणाली सभी परतों के लिए "आर्काइव ऑफिसर की बड़ी कॉपी" के अनुसार आवंटन करती है—SWA द्वारा बचाई गई स्थान को बेकार आरक्षित कर दिया जाता है, जिससे बचत बर्बाद हो जाती है।
रोफली टीम ने KVCache को दो अलग-अलग पूल में विभाजित किया। पूर्ण ध्यान के उस 10 परतें "बड़े पूल" से गुजरती हैं, जिसमें पूरी लंबाई के अनुसार आवंटन किया जाता है; जबकि SWA की उस 60 परतें "छोटे पूल" से गुजरती हैं, जहाँ केवल 128 टोकन की खिड़की के अनुसार आवंटन किया जाता है।
एक उदाहरण के रूप में, मान लीजिए कि कंपनी प्रत्येक कर्मचारी को "100 वर्षों तक फ़ाइलें स्टोर करने योग्य फाइल कैबिनेट" देती है—लेकिन 60 कर्मचारियों को वास्तव में केवल "एक सप्ताह की फ़ाइलों के लिए छोटा कैबिनेट" की आवश्यकता है, और उन बड़े कैबिनेट्स की 99% जगह खाली पड़ी है। नई विधि में, कैबिनेट को वास्तविक आवश्यकता के अनुसार बाँटा जाता है। परिणामस्वरूप, पूरे कार्यालय में 5 गुना से अधिक कर्मचारी काम कर सकते हैं—एक ही GPU द्वारा सेवा दी जाने वाली समानांतर उपयोगकर्ता संख्या 5 गुना बढ़ जाती है।
यह चरण सरल लगता है, लेकिन इसके बिना, पिछले SWA आर्किटेक्चर के लाभ बर्बाद हो जाते हैं।
प्रोजेक्ट 3: "पुराने उपयोगकर्ता को दोबारा पढ़ना" वास्तव में कैश में मिल जाए
लैपटॉप को 1/7 पर दबाएं + स्पेस वास्तव में उपयोग करने योग्य है, अगला कदम एक पुरानी समस्या को हल करना है: प्रीफिक्स कैश हिट रेट।
कई उपयोगकर्ताओं की बातचीत समान शुरुआत से शुरू होती है—एक ही system prompt, एक ही कोडबेस, एक ही लंबा दस्तावेज। सिस्टम इन परिणामों को संग्रहीत कर लेता है और अगली बार मिलान होने पर सीधे पुनः उपयोग करता है। इस तंत्र को प्रीफिक्स कैशिंग कहते हैं।
लेकिन SWA मोड में एक समस्या है: दो अनुरोध टोकन समान होने पर भी, यह आवश्यक नहीं कि KV अभी भी मौजूद हो। पूर्व स्थिति की गणना हो सकती है, लेकिन SWA विंडो के बाहर का हिस्सा पहले ही हटा दिया गया है। यदि सिस्टम "टोकन समान होने पर हिट" के पुराने नियम के अनुसार पुन: उपयोग करता है, तो आप अमान्य या ओवरराइट किए गए डेटा को पढ़ेंगे, जिससे मॉडल का प्रदर्शन सीधे बर्बाद हो जाएगा।
Rofuli टीम ने नियमों को "विंडो सुरक्षित लंबाई" तक अपग्रेड किया है—केवल "आप जितना पूरी तरह से उधार ले सकते हैं, उसी का वादा करते हैं।"
एक उदाहरण दें, एक पुस्तकालय में 10 लाख पुस्तकें हैं, और आप तीन किताबों की पूरी सीरीज़ 'Three-Body Problem' उधार लेना चाहते हैं। पुरानी संरचना आपको बताएगी "यह पुस्तक उपलब्ध है", लेकिन जब आप जाते हैं, तो पुस्तक शेल्फ पर केवल कवर और पहली किताब मिलती है, बाकी दो किताबें उधार ले ली गई हैं। यह "झूठी सफलता" आपको बेकार की यात्रा करने और फिर से उधार लेने के लिए मजबूर करती है। नए सिस्टम के नियमों में, केवल वही हिस्सा उपलब्ध होने का वादा किया जाता है जिसे आप पूरी तरह से उधार ले सकते हैं—पहली किताब आपको दे दी जाती है, और फिर बाकी दो किताबें आपके लिए स्थानांतरित कर दी जाती हैं।
ऐसा लगता है कि यह अधिक कठोर होगा और हिट दर कम हो जाएगी। लेकिन वास्तव में विपरीत: क्योंकि SWA KVCache के आकार को 1/7 तक कम कर देता है, समान स्टोरेज स्पेस में कई गुना अधिक सामग्री फिट हो सकती है, जिससे वास्तविक हिट दर में भारी वृद्धि होती है।
रो फुली के ब्लॉग में ऑनलाइन टेस्ट डेटा दिया गया है: मुख्य harness फ्रेमवर्क के तहत सर्वर कैश हिट रेट का औसत 93% है, और उच्च आवृत्ति लंबे अवधि के उपयोगकर्ताओं के लिए 95% से अधिक।
95% के "रिपीट रीड" अनुरोधों को GPU की गणना की आवश्यकता नहीं होती, बल्कि ये सीधे कैश से प्राप्त किए जाते हैं। यही 99% की छूट का भौतिक आधार है।
इंजीनियरिंग 4: "कैश" को GPU के अंतर्निहित SSD में रखें
अब सटीकता बढ़ गई है, अगला प्रश्न है: ये कैश कहाँ संग्रहित होते हैं।
वीडियो मेमोरी (GPU पर HBM मेमोरी) महंगी और सीमित होती है—एक H100 ऑक्टा-GPU मशीन में केवल 640GB वीडियो मेमोरी होती है, लेकिन MiMo द्वारा संग्रहीत KVCache कई टेराबाइट्स के स्तर का हो सकता है। इसलिए, इसे स्तरबद्ध करना आवश्यक है: हाल ही में उपयोग किए गए डेटा को वीडियो मेमोरी (L1) पर रखें, थोड़ा पुराने डेटा को CPU मेमोरी (L2) पर रखें, और ठंडे डेटा को वितरित कैश (L3) पर संग्रहित करें।
जैसे आप अपने पैसे का व्यवस्थापन करते हैं। बटुए में मौजूद नकदी ग्राफिक्स मेमोरी है—जिसे आप तुरंत उपयोग कर सकते हैं, लेकिन इसमें कम मात्रा में ही रखा जा सकता है। बैंक खाते का शेष सीपीयू मेमोरी है—इसे निकालने में 30 सेकंड लगते हैं, लेकिन इसमें बहुत अधिक मात्रा में पैसा रखा जा सकता है। नियमित जमा L3 डिस्ट्रीब्यूटेड कैश है—इसे निकालने में 2 मिनट लगते हैं, लेकिन यह काफी सस्ता है।
उद्योग की सामान्य प्रथा है कि L3 के लिए अलग स्टोरेज क्लस्टर बनाया जाए, विशेष मशीनों और विशेष डेटासेंटर के साथ, मासिक किराया देकर।
मियाओमी स्टोरेज टीम का दृष्टिकोण अलग है। उन्होंने एक निजी रूप से विकसित वितरित कैश, GCache, विकसित किया है, जिसे सीधे GPU मशीन के स्वयं के SSD पर डिप्लॉय किया गया है—जो ट्रेनिंग और इन्फरेंस कार्यों के साथ एक ही मशीन पर मिश्रित रूप से स्थापित है।
किसी ने बड़ी मात्रा में डेटा स्टोर करने के लिए एक वेयरहाउस किराए पर लिया; शियाओमी ने पाया कि GPU मशीनों के गैराज में जगह खाली है, और सीधे डेटा को वहाँ स्टोर कर दिया। मासिक किराया बच गया।
अतिरिक्त स्टोरेज लागत 0 है।
इस बात की प्रभावशीलता दिखने से अधिक है। सामान्य "AI कंपनी की कैलकुलेशन लागत" में, स्टोरेज लागत एक निश्चित खर्च होती है—आपका मॉडल जितना बड़ा और उपयोगकर्ता जितने अधिक, स्टोरेज बिल उतना ही लंबा होता है। GCache का यह तरीका इस खर्च को सीधे समाप्त कर देता है। SWA के छोटे आकार और 93-95% हिट रेट के साथ, KVCache का L3 पर अस्तित्व काल (TTL) कुछ मिनट से बढ़कर कुछ घंटे या दिनों तक हो जाता है—TTL जितना अधिक, इतिहास के context के हिट होने की संभावना उतनी ही अधिक होती है, कैश हिट रेट बढ़ता है, और 99% की छूट अधिक मजबूत होती है।
प्रोजेक्ट 5: कैश में मिले अनुरोधों को सबसे छोटे मार्ग से भेजें
कैश को स्टोर किया जा सकता है, खोजा जा सकता है, और सस्ता होता है, अंतिम कदम है: सही अनुरोध को सही मशीन पर कैसे रूट किया जाए।
Xiaomi ने अपना एक स्वयं का स्केड्यूलिंग सिस्टम LLM-Router विकसित किया है, जिसने तीन काम किए हैं:
पहला समानता स्केड्यूलिंग है। समान प्रीफिक्स वाले अनुरोधों को एक ही मशीन पर रूट किया जाता है, ताकि कैश पुनः उपयोग को अधिकतम किया जा सके।
दूसरा, लंबाई के आधार पर बकेट। छोटे अनुरोध (0-64K), मध्यम अनुरोध (64K-256K), और लंबे अनुरोध (256K-1M) को अलग-अलग प्रोसेसिंग चैनल में भेजें, ताकि छोटे अनुरोध लंबे अनुरोध के कारण धीमे न हों।
तीसरा, TTFT अनुकूलन। अनुमान के लिए पंक्ति में, वास्तविक गणना लागत कम वाले अनुरोधों (अर्थात् अधिकांशतः कैश में मिल जाने वाले अनुरोध) को प्राथमिकता दें — ताकि वे "पूर्णतः नए इनपुट" जैसे भारी गणना वाले अनुरोधों से अवरुद्ध न हों।
उदाहरण के लिए, एक सामान्य हवाई अड्डा शेड्यूलिंग में, सभी एक ही गंतव्य के लिए उड़ने वाले यात्री एक ही प्रतीक्षा कक्ष में एकत्रित होते हैं और बैगेज क्लेम प्रक्रिया को साझा करते हैं—यह एफिनिटी स्केड्यूलिंग है। एक बैगेज के साथ आने वाले और तीन बड़े सामान के साथ आने वाले दो अलग सुरक्षा चेकपॉइंट से गुजरते हैं, ताकि तेज़ लोगों को धीमे लोगों के कारण न धीमा किया जा सके—यह लंबाई बकेटिंग है। बोर्डिंग के समय, केवल कैबिन बैगेज लेकर आने वाले यात्रियों को पहले अनुमति दी जाती है, क्योंकि वे जल्दी से बोर्ड होते हैं, जिससे विमान जल्दी उड़ सकता है—यह TTFT ऑप्टिमाइज़ेशन है।
इस स्केड्यूलिंग स्ट्रैटेजी के वास्तविक परीक्षण से L2 कैश हिट रेट 25% बढ़ गया, एकल मशीन इनपुट थ्रूपुट 30% बढ़ गया, और लंबे अनुरोध की P90 लेटेंसी 30% कम हो गई।
एक ही GPU अधिक उपयोगकर्ताओं की सेवा कर सकती है। कीमत में कमी का दूसरा आधा तर्क यहीं है—प्रति यूनिट कैलकुलेशन का प्रभावी उत्पादन अधिक है और प्रति उपयोगकर्ता लागत कम है।
प्रोजेक्ट 6: मॉडल के "टाइप करने" को भी तेज़ बनाएं
पिछले पांच कदम "पढ़ने" के पहलू को अनुकूलित कर रहे हैं—उपयोगकर्ता के द्वारा इतिहास के संदर्भ को दोहराकर पढ़ने की लागत को लगभग 0 तक घटाकर। छठा कदम "लिखने" के पहलू को अनुकूलित करना है—अर्थात मॉडल द्वारा अगला टोकन उत्पन्न करने की प्रक्रिया।
पारंपरिक मॉडल एक बार में केवल 1 टोकन उत्पन्न कर सकता है। MiMo मूल रूप से 3 स्तरीय MTP (Multi-Token Prediction) का समर्थन करता है—एक बार में अगले 3 टोकन का भविष्यवाणी करना, और यदि मध्यवर्ती भविष्यवाणी सही है, तो मध्यवर्ती गणना को छोड़ दिया जाता है।
एक उदाहरण के लिए, पारंपरिक टाइपिंग में आप एक-एक करके अक्षर टाइप करते हैं—आप "आज का मौसम" टाइप करना चाहते हैं, तो आपको 4 बार कीबोर्ड दबाना पड़ता है। MTP में एक स्वचालित पूर्ति होती है जो आपके अगले 1-2 अक्षरों का अनुमान लगाती है—अगर यह सही अनुमान लगाती है, तो आपको उन दो बार दबाने की जरूरत नहीं पड़ती।
MiMo का MTP एजेंटिक स्थितियों में वास्तविक परीक्षण: पहले 128 टोकन के लिए 2.3 गुना तेज़, 128-256 टोकन के लिए 1.5 गुना तेज़।
इसका महत्व यह है कि 99% छूट केवल Input (Cache Hit) पर लागू होती है, लेकिन मॉडल वास्तविक रूप से उपयोगकर्ताओं की सेवा करते समय, input और output एक ही अनुरोध में होते हैं—अगर output की लागत कम नहीं होती, तो पूरे अनुरोध की लागत केवल आधी कम होती है। MTP उस आधे हिस्से को भी कम करता है, जिससे पूरी छूट का लाभ मॉडल पूरा होता है।
छह चीजों को एक लागत कम करने वाली श्रृंखला में जोड़ें:
SWA आर्किटेक्चर → KVCache 1/7 → डबल पूल से वास्तविक क्षमता रिलीज → एक ही GPU पर 5+ गुना कंकरेंसी फिट हो सकती है → प्रीफिक्स कैश हिट रेट 93-95% → 95% अनुरोधों के लिए लगभग कोई कैलकुलेशन नहीं → GCache से स्टोरेज लागत शून्य → स्केड्यूलिंग कैश हिट अनुरोधों को प्राथमिकता देती है → MTP से जनरेशन भी बचत है → प्रति अनुरोध GPU समय एक अंक कम हो जाता है → प्रति इकाई लागत में 95%+ की कमी → मूल्य 99% कम, लेकिन घातक मुनाफा अभी भी सकारात्मक।
किसी भी एक कड़ी की कमी से यह श्रृंखला किसी एक जगह पर टूट जाती है। 99% की छूट कोई मार्केटिंग नंबर नहीं है, बल्कि छह इंजीनियरिंग स्तंभों के एकत्रित प्रभाव है, जिसे वास्तविक ऑनलाइन पुष्टि से प्राप्त किया गया है।
पिछले कुछ सालों में उद्योग की शुरुआती कई व्याख्याओं को देखें, तो प्रत्येक में कुछ हद तक सच्चाई है। इन दो सालों में चीनी बड़े मॉडल कंपनियों के बीच की कीमत प्रतिस्पर्धा वास्तविक है; मिनी का लाभ आधा हो गया है और वह AI में निवेश कर रहा है, यह वास्तविक है; डीपसीक ने उद्योग की कीमत सीमा को जमीन तक खींच लिया है, यह भी वास्तविक है।
लेकिन रोफली ने इस बार अपना तकनीकी ब्लॉग प्रकाशित किया है और विस्तृत तकनीकी विवरण को स्पष्ट किया है, जो स्पष्ट रूप से मूल्य युद्ध के दावों का जवाब देने की इच्छा रखता है, ताकि "तकनीकी मुद्दे तकनीकी के लिए और विपणन मुद्दे विपणन के लिए" हों।
उसने अपने ब्लॉग में लिखा कि MiMo-V2.5 सीरीज मॉडल की निष्पादन दक्षता किसी एक चरण के एकल ब्रेकथ्रू से नहीं, बल्कि बहुआयामी सहयोगी अनुकूलन का परिणाम है। Hybrid SWA प्रीफिल और डिकोड दोनों को लाभ पहुँचाता है, लेकिन अपर्याप्त रूप से अनुकूलित KVCache कार्यान्वयन विभिन्न चरणों में लागत बढ़ा सकता है। इस लक्ष्य के चारों ओर, MiMo टीम ने KVCache प्रबंधन, हाइरार्किकल कैशिंग और प्रीफिक्स कैशिंग ट्री को पुनः संरचित किया, SWA KVCache की मुख्य समस्याओं को हल किया, स्केड्यूलिंग रणनीति और प्रीफिल/डिकोड पाथ को अनुकूलित किया, और ऑनलाइन वास्तविक परिदृश्यों से परीक्षण करके, अंततः इसकी सैद्धांतिक दक्षता के लाभ को उत्पादन परिवेश में साकार किया। इस प्रकार, Hybrid SWA ने लंबे पाठ निष्पादन पर शक्ति और दक्षता दोनों के साथ संरचनात्मक लाभ प्रदर्शित किया। MoE कॉन्फ़िगरेशन और मल्टीमॉडल निष्पादन के विभिन्न अनुकूलनों को मिलाकर, ऑनलाइन निष्पादन सेवाओं की प्रदर्शन क्षमता में भारी वृद्धि हुई।
यह एक एआई इंजीनियरिंग की व्यवस्थित रणनीति है, और उद्योग के लिए लागत कम करने का एक मूल्यवान संदर्भ है।
कीमत का युद्ध ब्लॉग लिखने की जरूरत नहीं होता, इंजीनियरिंग की पूर्ति की जरूरत होती है।