मैंने टोकन बचाने के तरीके खोजते हुए अपने सारे टोकन जला दिए
बड़े भाषा मॉडल (LLM) की लागत घटाने की कोशिशें एक अटपटी tradeoff दिखा रही हैं: कई “token-saving” तरकीबें जटिलता बढ़ाती हैं, context caching तोड़ देती हैं, या बस waste को हटाने के बजाय इधर-उधर कर देती हैं। टिप्पणीकार multi-model pipelines, frozen बनाम dynamic prompts, और local बनाम cloud deployments जैसी रणनीतियों की तुलना करते हैं; कुछ का तर्क है कि cloud APIs अभी भी अधिकांश on-prem setups से सस्ते और अधिक सक्षम हैं, सिवाय उन मामलों के जहाँ privacy या scale hardware निवेश को उचित ठहराते हैं। तकनीकी विवरणों के नीचे एक व्यापक तनाव है कि क्या LLM-assisted code और products सचमुच मूल्यवान हैं या ज़्यादातर unshippable “slop” हैं, और वास्तविक productivity gains को anecdotal दावों से परे कैसे मापा जाए।
टोकन-बचत रणनीतियाँ और शोध वर्कफ़्लो
- कई लोग लेख जैसी ही समान अनुभव बताते हैं: LLMs “अज्ञानी” नहीं हैं, लेकिन उनमें अनुशासन की कमी होती है, और वे बार-बार एक ही बंद गली में टोकन जला देते हैं। लक्ष्य बार-बार होने वाली बंद गलियों को कम करना बन जाता है, न कि खोज को ही रोकना।
- सुझाया गया पाइपलाइन: परिकल्पना बनाने और व्यापक खोज के लिए सस्ते/छोटे मॉडल से शुरुआत करें, फिर परिष्कृत नतीजों को मजबूत मॉडल को दें। समानांतर कम-लागत परिकल्पनाएँ एक महंगे कॉल से बेहतर हो सकती हैं।
- जब विलंब स्वीकार्य हो, तब लागत कम करने के लिए बैच प्राइसिंग और “overnight” jobs प्रस्तावित की जाती हैं।
- शुरुआती चरणों में विविधता के लिए कई विक्रेताओं के मॉडल मिलाने का सुझाव भी दिया गया है।
संदर्भ, कैशिंग, और प्रॉम्प्ट डिज़ाइन
- कई लोगों का कहना है कि चालाक टोकन-बचत तरकीबें अक्सर context-prefix caching को तोड़ देती हैं, जिससे कुल मिलाकर चीज़ें और महँगी हो जाती हैं।
- निश्चित, थोड़ा बड़े prefixes के साथ कभी-कभार summarization, dynamic retrieval और pruning schemes से बेहतर हो सकता है।
- मॉडल को compaction संभालने देना (जैसे editor integrations के ज़रिए) कुछ लोगों के लिए आश्चर्यजनक रूप से अच्छा काम करता है; context को अक्सर बस भरने दिया जा सकता है, फिर उसे summarize किया जा सकता है।
- कठिनाई के आधार पर adaptive model routing पर चर्चा होती है; समस्याएँ हैं मॉडल बदलते समय पूरी history को फिर से चलाना और models के बीच attention caches की असंगति।
लोकल बनाम क्लाउड मॉडल और अर्थशास्त्र
- एक मजबूत राय यह है कि ज़्यादातर लोगों के लिए cloud models, local ones से सस्ते और बेहतर हैं, जब तक कि आपके पास पहले से पर्याप्त hardware न हो या सख़्त privacy आवश्यकताएँ न हों।
- दूसरों का तर्क है कि local models उन संगठनों के लिए समझ में आते हैं जिनके पास बहुत से heavy users हैं या मौजूदा compute है, या vendor lock‑in और बदलती restrictions के विरुद्ध एक hedge के रूप में।
- “90% local / 10% frontier” pattern प्रस्तावित किया जाता है, लेकिन कब switch करना है यह पहचानना आसान नहीं माना जाता।
टूल्स, agents, और दोहराए गए काम से बचाव
- विभिन्न tools का उल्लेख किया गया है: memory/caching MCPs, skills files, और ऐसे workflows जो पिछले chats के आधार पर समय-समय पर “rules/skills” अपडेट करते हैं ताकि वही कदम दोबारा न दोहराने पड़ें।
- चिंता जताई गई कि कई agents और products एक ही समस्याएँ फिर से हल करते रहते हैं; agents के लिए shared knowledgebases का सुझाव दिया गया है ताकि reusable solutions पर convergence हो सके।
शिपिंग, “slop,” और वास्तविक दुनिया का मूल्य
- इस पर तीखी बहस है कि AI-assisted projects वाकई उपयोगी हैं या बस “slop” हैं।
- कुछ लोग बताते हैं कि उन्होंने LLMs के साथ internal tools, migrations, games, और hardware अधिक तेज़ी से ship किए।
- अन्य लोग उन चीज़ों के मूल्य पर सवाल उठाते हैं जिन्हें अब users खुद बना सकते हैं, और bot-written documentation वाले AI projects की आलोचना करते हैं।
- “shipped” की परिभाषाएँ (paid users बनाम personal tools बनाम OSS) विवादित हैं।
Hallucinations और reliability
- यह संदेह व्यक्त किया गया है कि hallucinations को rules या pipelines से समाप्त किया जा सकता है; इन्हें current models की अंतर्निहित विशेषता माना जाता है।
- “no hallucinations” के दावों को अतिशयोक्तिपूर्ण माना गया है।