⚡ निचोड़
मूनशॉट (Kimi) ने Kimi K3-256K उतारा है — क्षमताएँ पूरे K3 जैसी, वीडियो इनपुट काट दिया, और संदर्भ विंडो पर 256K की छत लगा दी। पहली नज़र में यह 'कटा-फटा संस्करण' लगता है, पर डेवलपर समुदाय ने जब हिसाब लगाया, तो फैसला एकदम एकजुट निकला — यही समझदारी है, क्योंकि coding काम में असली ख़र्च का इंजन लंबा संदर्भ है।
ज़्यादातर coding कामों में ख़र्च का बड़ा हिस्सा इनपुट/आउटपुट नहीं, बल्कि संदर्भ है। जब आप संदर्भ को 50K से खींचकर करोड़ों (million) टोकन तक ले जाते हैं, तो औसत टोकन खपत सीधे एक पूरे दशमलव बढ़ जाती है — और जब तक कि cache सस्ता न हो, यही आपका 'टोकन हत्यारा' बनता है। Kimi ने कॉन्फ़िग स्तर पर लंबा संदर्भ काटकर वही स्विच बंद कर दिया जो सबसे महँगा था।
💸 लंबा संदर्भ इतना महँगा क्यों है
एक बात बार-बार साबित हुई है: coding काम में, जब तक cache की कीमत नीचे न आ जाए, पूरे सेशन का मुख्य ख़र्च संदर्भ वाले टोकन पर टिका रहता है। विंडो जितनी बड़ी, हर राउंड में आप एक बढ़ते हुए पहाड़ को बार-बार खींच रहे हैं।
पर इसकी एक शर्त है — लंबा संदर्भ तभी 'वहनीय-सा महँगा' होता है, जब cache हिट की कीमत काफ़ी कम हो। अभी बाज़ार में cache कीमत सच में नीचे लाने वाले सिर्फ़ DeepSeek और MiMo दो हैं, इसलिए इन्हीं दोनों का 1M संदर्भ 'वहनीय' कहा जा सकता है। बाक़ी सबके लंबे-संदर्भ बिलिंग बेतहाशा ऊँचे हैं; तर्क हमेशा छोटे संदर्भ की ओर झुकता है।
एक सीधा-सा हिसाब: 1M संदर्भ औसतन क़रीब 500K तक जाता है, और 50K संदर्भ से तुलना करें तो ख़र्च में पूरे 10 गुना का फ़र्क खुल जाता है।
100K के आसपास खुद सिकोड़ लें, तो औसत संदर्भ 50K तक रहता है; 990K तक ठूठ कर सिस्टम के ऑटो-कंप्रेक्ट का इंतज़ार करें, तो औसत 500K हो जाता है। एक ही 'लॉन्ग-कॉन्टेक्स्ट मॉडल' में दूसरा पहले से 10 गुना महँगा निकलता है। और सिर्फ़ 256K वाले दायरे में भी — अगर एक राउंड 200K तक पहुँच जाए, तो ख़र्च 50K आधार-रेखा का 4 गुना हो जाता है।
ये सारा तब ही अलग हो सकता है, जब cache हिट की कीमत सस्ती हो। मुसीबत यह कि ज़्यादातर मेनस्ट्रीम मॉडलों का cache भी उतना ही महँगा है, इसलिए मुख्य ख़र्च संदर्भ ही बना रहता है और लंबा संदर्भ इस्तेमाल अपने आप लागत बढ़ाता है। जब आप खुद संदर्भ सीमित करते हैं, तो आपका Agent/Harness सॉफ़्टवेयर अपने आप संदर्भ का साइज़ काबू में रखता है — और ख़र्च काफ़ी गिर जाता है।
🧠 ज़्यादातर लोगों को 'संदर्भ प्रबंधन' का ख़याल ही नहीं है
असल समस्या आदतों में है। एक बड़ा हिस्सा ऐसा है जिसे 'सक्रिय संदर्भ प्रबंधन' का कोई अहसास ही नहीं — बस Harness (Agent सॉफ़्टवेयर परत) के ऑटो-कंप्रेस पर पूरी तरह निर्भर, और वह भी सबसे महँगे मॉडल पर, एक ही बातचीत को अंत तक चलाते हुए और 1M भर जाने पर कंप्रेस होने का इंतज़ार करते हुए।
इस तरह के इस्तेमाल में 'कुछ ही राउंड में कोटा खत्म' होना तय है। Kimi के फ़ेशू (लार्क) ग्रुप में 'इतना कम इस्तेमाल, बस कुछ राउंड में खत्म' वाली शिकायतें जो भड़कती दिखती हैं, सीधे इसी आदत से जुड़ी हुई हैं। ग्रुप में आधिकारिक ऐलान कहता है कि '90% इस्तेमाल 256K संदर्भ से ज़्यादा नहीं जाता' — यानी उल्टा देखें तो क़रीब 10% लोग अभी भी K3 पर लंबा संदर्भ जला रहे हैं।
और भी मज़ेदार — K3 की डॉक्स में वो लाइन: 'K3 पर स्विच करने से पहले नया सेशन शुरू करें'। यह एक सीधी-सीधी सलाह थी, पर बहुतों ने इसे समझा ही नहीं: उन्होंने पहले से 200K+ पर ठूठा हुआ पुराना सेशन सीधे K3 पर डाला, फिर उसे 1M तक धकेला और ऑटो-कंप्रेस का इंतज़ार किया — इस तरह के इस्तेमाल में कोई भी प्लान टिक नहीं सकता। वो आधिकारिक लाइन ज़्यादा कुछ नहीं, आगे बढ़कर एक PR संकट रोकने की तैयारी लगती है।
पहले GPT 5.6 Sol ने Codex में डिफ़ॉल्ट Context Window को 272K से 372K तक बढ़ाया, और तुरंत एक झटके में लोगों ने 'टोकन टिकता नहीं' कहकर दुतकार दिया। Tibo ने ख़ास एक पोस्ट डालकर समझाया कि Auto Compact दोनों स्तरों के बीच उतना बड़ा फ़र्क़ नहीं करता, पर आख़िर में दबाव झेल नहीं पाए और चुपचाप डिफ़ॉल्ट वापस खींच लिया। डिफ़ॉल्ट संदर्भ फुल करके रखना एक घाटे वाला डिज़ाइन है।
🔍 'मेरी cache हिट रेट 98% है' — ये असल में ख़तरे का संकेत है
समुदाय में अक्सर कोई ये ग़ौरव दिखाता है कि उसकी cache हिट रेट 98%, 99% तक चली जाती है, और इसे वो 'मैं सस्ते में चल रहा हूँ' का सबूत समझता है। ये अंतर्मन क़रीब-क़रीब उल्टा निकलता है।
Harness स्तर पर cache हिट रेट हर किसी के यहाँ ज़्यादा अलग नहीं होती। असामान्य रूप से ऊँची रेट अक्सर बस इतना दिखाती है कि आप लंबा संदर्भ ज़्यादा इस्तेमाल कर रहे हैं — और लंबा संदर्भ, सबसे महँगा हिस्सा है। यानी 'ऊँची हिट रेट' को दूसरे नज़रिए से देखें तो इसका मतलब है — 'मैंने सबसे महँगी जगह पर सबसे ज़्यादा ख़र्च किया'।
आख़िर में, हर स्थिति को लंबे संदर्भ की ज़रूरत नहीं होती। सीखें संदर्भ सक्रिय रूप से काबू में रखना, तभी वो ऊँचे दाम वाले मॉडल ज़रा वहनीय होते हैं; अगर आप उस 'एक ही बातचीत अंत तक, 1M भर जाने पर ऑटो-कंप्रेस' वाले खेमे में हैं, तो DeepSeek और MiMo को छोड़कर, बाक़ी सब आपके बजट से बाहर जाएँगे।
🏷️ तो 256K वाला सस्ता होगा? ज़्यादातर नहीं
कई लोग अंदाज़ा लगा रहे हैं कि ये नया मॉडल ID सस्ता होगा। ज़्यादातर नहीं — कीमत वही रहेगी। आधिकारिक तौर पर जो कीमत गुणक बताया जाता है, वो मुख्य रूप से लंबे संदर्भ के इनपुट और cache हिट के ख़र्च से आता है, मॉडल डिस्काउंट से नहीं।
दोनों के औसत हिसाब से फ़र्क़ क़रीब 3 गुना तक जाता है। बस इसलिए कि ज़्यादातर लोगों का एक सेशन 1M तक पहुँचता ही नहीं, इसलिए आधिकारिक तौर पर एक सतर्क 'अनुमान 2 गुना' वाली बात रखी गई है।
256K सीमा में औसत Context क़रीब 150K; 1M सीमा में औसत क़रीब 600K — सिर्फ़ cache कीमत का ख़र्च ही 4 गुना खुल जाता है। एक Prompt में औसतन क़रीब 8 मैसेज राउंड होते हैं; हर राउंड में 4K इनपुट और 600 टोकन आउटपुट मान लें, तो असली इनपुट/आउटपुट ख़र्च का हिस्सा काफ़ी कम रहता है।
इसलिए क़िफ़ायत में सुधार 'कॉन्फ़िग स्तर से लंबा संदर्भ काट देने' से आता है, न कि दाम कम होने से।
और यही वजह है कि Kimi ने एक अलग मॉडल वर्ज़न उतारा — कॉन्फ़िग स्तर से लंबा संदर्भ काट दिया, तभी जाकर यूज़र के असली काम की क़िफ़ायत सच में सुधरती है।
📊 परख: कोटा खपत पूर्ण संस्करण का क़रीब एक-तिहाई
टिप्पणी सेक्शन से कुछ ध्यान देने लायक परिणाम और ठंडे तथ्य:
- ठंडा तथ्य: Codex और Cursor दोनों 1M वाले मॉडल जोड़ते हैं, पर असल में इस्तेमाल किया जा सकने वाला संदर्भ सिर्फ़ 2–3 सौ K तक ही है।
- कटा-फटा संस्करण कितना पीछे: किसी ने एक ही काम पर परखा — 256K वाले ने पूर्ण संस्करण के मुक़ाबले क़रीब 1/3 कोटा ही ख़र्च किया, क्योंकि बड़ा संदर्भ अपने आप टोकन खपत बढ़ा देता है; एक ही पूर्णता के मानक पर उसी काम की कोटा खपत क़रीब 40% रही।
- लंबी दौड़ का काम: kimi cli पर एक-दो घंटे चलने वाले काम पर साप्ताहिक कोटा खपत 5.53%; जबकि पहले आम तौर पर हर घंटे 10% से ऊपर जाता था।
- असर पड़ता है क्या: हाँ, review के बाद थोड़ा रीवर्क ठीक करना पड़ता है; पूर्ण संस्करण में लगभग कोई रीवर्क नहीं।
- वीडियो और 1M का कंप्यूट: वीडियो इनपुट और 1M संदर्भ हटाने से कंप्यूट ज़रूरत कम से कम आधी गिर जाती है।
199 वाले प्लान वालों के लिए, कोटा पहले ही बेहद तंग है, तो कटा-फटा संस्करण थोड़ा खुलकर इस्तेमाल करने देता है; और असल बात ये — K3 MAX का 1M वर्ज़न अब भी उपलब्ध है, ChatGPT की तरह नहीं कि 1M के लिए आपको API बिलिंग पर जाना पड़े।
यानी कम दाम वाले दायरे के बाहर, एक और चुनाव दे दिया (साथ ही आधिकारिक कंप्यूट ख़र्च भी घटा) — सौ फ़ायदे, एक नुकसान नहीं।
🎯 एक लाइन में
ज़्यादातर लोगों के लिए लंबा संदर्भ एक टोकन हत्यारा है — DeepSeek और MiMo जैसे सस्ते cache वाले को छोड़कर, बाक़ी सब चुपचाप आपका बैलेंस खाली कर रहे हैं।
Kimi K3-256K ने कॉन्फ़िग स्तर की एक छत से यूज़र के पैसे जाने का तरीका काबू में कर दिया। एक टीम के लिए जिसका कंप्यूट हमेशा तंग रहता है, ये शालीन क़दम है। असल में महँगा कोई मॉडल नहीं — वो 'अनलिमिटेड' महँगा है, जिसे आप वहन कर सकते हैं समझकर इस्तेमाल करते हैं।
यह लेख Kimi K3-256K के रिलीज़ पर डेवलपर समुदाय की सार्वजनिक चर्चाओं और परखों पर आधारित है; संख्याएँ और विचार समुदाय की प्रतिक्रिया से हैं, केवल संदर्भ हेतु; सटीक बिलिंग के लिए मूनशॉट के आधिकारिक स्रोत को ही मान्य मानें।