Tokenomics: एजेंट-आधारित सॉफ्टवेयर इंजीनियरिंग में टोकन कहाँ खर्च होते हैं, इसका मात्रात्मक विश्लेषण

 (arxiv.org)
1 पॉइंट द्वारा GN⁺ 4 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM-आधारित multi-agent software development systems के execution traces को SDLC चरणों से मैप करके यह मापने वाला अध्ययन कि token consumption शुरुआती generation की तुलना में code review और verification में अधिक केंद्रित होता है
  • ChatDev द्वारा किए गए 30 software development tasks में code review चरण ने औसतन 59.4% टोकन खर्च किए, और यह सबसे बड़ा consumption zone पाया गया
  • सभी tasks में औसत token composition: input 53.9%, output 24.4%, reasoning 21.6%; agents के बीच बार-बार context transfer होने से बड़ा communication tax बनता है
  • Coding चरण में output tokens का हिस्सा 58.0% रहा, जबकि documentation चरण में input tokens का हिस्सा 80.2% रहा, जिससे development चरणों के अनुसार token usage patterns साफ़ तौर पर अलग दिखे
  • निष्कर्ष: लागत अनुमान और workflow optimization के लिए अधिक token-efficient agent collaboration protocols और standardized evaluation framework की आवश्यकता है

सार

  • LLM-आधारित multi-agent (LLM-MA) systems का उपयोग requirements engineering, code generation, testing जैसे जटिल software engineering tasks को automate करने में बढ़ता जा रहा है
  • Operational efficiency और resource consumption को अभी पर्याप्त रूप से समझा नहीं गया है, इसलिए अप्रत्याशित लागत और environmental impact वास्तविक अपनाने में बाधा बनते हैं
  • अध्ययन ने ChatDev framework द्वारा GPT-5 reasoning model के साथ किए गए 30 software development tasks के execution traces का विश्लेषण किया, और उसकी internal stages को design, coding, code completion, code review, testing, documentation में मैप किया
  • प्रारंभिक परिणामों में पाया गया कि iterative code review चरण औसतन 59.4% tokens का उपभोग करता है और सबसे बड़ा consumption zone है
  • Input tokens लगातार सबसे बड़ा हिस्सा रहे, औसतन 53.9%, जो agent collaboration में महत्वपूर्ण inefficiency की संभावना का अनुभवजन्य प्रमाण देता है
  • Agentic software engineering की मुख्य लागत शुरुआती code generation में नहीं, बल्कि automated refinement और verification process में केंद्रित है
  • यह methodology cost prediction, workflow optimization, और अधिक token-efficient agent collaboration protocols पर शोध में उपयोगी हो सकती है

परिचय

  • बड़े पैमाने की software engineering में SDLC के पूरे दायरे में जटिल tasks को automate करने के लिए LLM-आधारित multi-agent systems की खोज की जा रही है
  • LLM-MA frameworks product manager, architect, developer, tester जैसी human team roles को specialized LLM agents के रूप में simulate करते हैं, और design, coding, validation tasks को collaborative तरीके से पूरा करते हैं
  • LLM-MA systems सिद्धांततः tasks को agents के बीच बाँटकर autonomy और robustness बढ़ा सकते हैं
  • पूर्ववर्ती शोध बताता है कि LLM-MA systems divergent thinking को बढ़ावा दे सकते हैं, reasoning और factuality को मजबूत कर सकते हैं, और single-agent क्षमताओं से आगे की समस्याओं तक स्केल कर सकते हैं
  • Software engineering में requirements से testing तक end-to-end workflows को integrated तरीके से automate करने की संभावना है
  • AGENTTAXO framework सामान्य LLM-MA systems की token distribution के विश्लेषण के लिए taxonomy देता है, और agents के बीच interaction overhead को समझाने के लिए “communication tax” की अवधारणा पेश करता है
  • MAST failure taxonomy दिखाती है कि LLM-MA systems की कई समस्याएँ individual LLM limitations से अधिक stage repetition और incomplete verification जैसी system design तथा coordination समस्याओं से उत्पन्न होती हैं
  • मौजूदा शोध ने सामान्य संदर्भ में agent behavior का विश्लेषण किया है, लेकिन multi-stage software engineering workflows में लागू systems की resource efficiency को लेकर knowledge gap बना हुआ है
  • व्यवहारिक अपनाने का मुख्य प्रश्न “tokens कहाँ जाते हैं” software engineering क्षेत्र में अब भी पर्याप्त रूप से अनुत्तरित है
  • Tokenomics वह शब्द है जो LLM-MA systems की operational efficiency और resource consumption के अध्ययन के लिए उपयोग किया जाता है
  • यह विश्लेषण ChatDev की internal stages को development stages से मैप करके token consumption distribution को देखता है
  • ChatDev एक virtual software company को simulate करता है, जहाँ programmer और tester जैसे कई agent roles multi-turn conversations के ज़रिए SDLC पूरा करते हैं
  • 30 execution traces का curated dataset और पूर्ण replication package उपलब्ध कराया गया है

शोध डिज़ाइन

  • लक्ष्य और विश्लेषण का दायरा

    • लक्ष्य यह अनुभवजन्य रूप से जाँचना है कि LLM-MA systems end-to-end software development tasks करते समय token consumption कैसे वितरित करते हैं
    • शुरुआती विश्लेषण का विषय ChatDev है
    • ChatDev की “chat chain” architecture design → coding → testing का स्पष्ट sequential waterfall model दिखाती है, इसलिए इसकी stages स्पष्ट हैं और software development stages mapping के लिए उपयुक्त हैं
    • ChatDev लोकप्रिय और व्यापक रूप से उद्धृत open source frameworks में से एक है

  • Dataset curation

    • ChatDev को 30 अलग-अलग software development tasks पर चलाया गया
    • Prompts, MAST अध्ययन में उपयोग किए गए ProgramDev Dataset से लिए गए
    • चुने गए prompts में Fibonacci numbers generate करने जैसे सरल algorithms से लेकर chess game जैसे अधिक जटिल applications तक शामिल थे
    • हालिया शोध के आधार पर diversity की जाँच की गई, जिसके अनुसार reasoning token count task complexity का proxy indicator हो सकता है
    • 30 tasks में reasoning token consumption की range 17,280 से 40,000 तक रही, जो अध्ययन के लिए पर्याप्त task complexity diversity का संकेत देती है

  • Model selection

    • सभी agents के लिए base model GPT-5 reasoning model था
    • चयन के मानदंड थे: model की लोकप्रियता और नवीनता, agentic use cases के लिए उपयुक्तता, और autonomous agents की अपेक्षाओं के अनुरूप मजबूत reasoning क्षमता
    • प्रयोग में उपयोग किया गया model version gpt-5-2025-08-07 था
    • temperature parameter इस model में समर्थित नहीं था, इसलिए default value 1.0 का उपयोग किया गया
    • Context window 400,000 tokens थी, और maximum output tokens 128,000 थे
    • Knowledge cutoff 30 सितंबर 2024 था

  • Analysis pipeline

    • Trace collection चरण में ChatDev को instrument करके 30 tasks में से प्रत्येक का पूरा execution trace logs में रिकॉर्ड किया गया
    • हर LLM call के prompt, response, input, output, और reasoning token counts को capture किया गया
    • Stage mapping वह मुख्य methodology थी जिसमें ChatDev की framework-internal stages को universal development stages में बदला गया
    • यह abstraction generalizable analysis को संभव बनाती है और अन्य software engineering LLM-MA frameworks तक विस्तार की अनुमति देती है
    • Token aggregation Python scripts से की गई
    • एकत्रित traces को parse करके 30 runs में development stage के अनुसार token counts जोड़े गए
    • इन्हें input, output, और reasoning tokens में विभाजित किया गया

  • ChatDev internal stages और development stages mapping

    • Design चरण DemandAnalysis, LanguageChoose से मेल खाता है, और requirements understanding तथा high-level technical decisions पर केंद्रित है
    • Coding चरण Coding से मेल खाता है, और शुरुआती source code लिखने में सीधे शामिल है
    • Code completion चरण CodeComplete से मेल खाता है, और coding चरण में बचे placeholders या अधूरी code files को पूरा करता है
    • Code review चरण CodeReview से मेल खाता है, और programmer agent तथा code reviewer agent के iterative संवाद के माध्यम से code inspection, correction, और improvement करता है
    • Testing चरण Test से मेल खाता है, और executable bugs खोजने और ठीक करने के लिए dynamic system testing पर केंद्रित है
    • Documentation चरण EnvironmentDoc, Reflection, Manual से मेल खाता है, और user manual तथा आवश्यक environment dependencies की documentation तैयार करता है

शोध परिणाम और चर्चा

  • शोध प्रश्न

    • मुख्य प्रश्न यह है कि software development tasks में LLM-MA systems के token consumption patterns कैसे दिखते हैं
    • Agentic software engineering systems की tokenomics को समझना व्यावहारिक और sustainable adoption के लिए महत्वपूर्ण है
    • अधिक token usage सीधे financial cost, energy consumption, और environmental impact में बढ़ोतरी से जुड़ा है
    • SDLC के भीतर tokens कहाँ खर्च होते हैं, यह पहचानकर cost prediction और workflow optimization के लिए उपयोगी “cost map” बनाया जा सकता है
    • विश्लेषण दो आयामों पर किया गया
    • Design, coding आदि mapped development stages के अनुसार कुल token distribution
    • हर चरण के भीतर input, output, और reasoning tokens का अनुपात

  • खोज 1: Code review चरण token consumption पर हावी है

    • पूरे development process में token usage बहुत असमान रूप से वितरित था
    • Code review चरण ने 30 tasks में औसतन 59.4% tokens खर्च किए और यह सबसे बड़ा consumption zone रहा
    • Code completion चरण 30 में से 6 tasks में आया, और उन runs में उसने औसतन 26.8% tokens खर्च किए
    • Documentation चरण ने औसतन 20.1% और testing चरण ने औसतन 10.3% tokens खर्च किए
    • Testing चरण 30 में से 12 tasks में आया
    • शुरुआती coding की औसत लागत 8.6% और design की 2.4% रही, जो अपेक्षाकृत कम थी
    • Agentic software engineering की मुख्य लागत शुरुआती code generation की बजाय iterative और conversational refinement तथा verification process में केंद्रित है
    • चित्र में n का मान उन tasks की संख्या को दिखाता है जिनमें 30 tasks में से वह विशेष चरण चला
    • सभी stages हमेशा execute नहीं होतीं; multi-agent system के भीतर agents स्वायत्त रूप से तय करते हैं कि कौन-सा चरण चलाना है
    • Error bars ±1 standard deviation दर्शाते हैं, जो हर चरण में token consumption की variability को दिखाते हैं

  • खोज 2: Token consumption input tokens पर केंद्रित है

    • Coding चरण को छोड़कर सभी stages में input tokens, output और reasoning tokens से काफ़ी अधिक थे
    • Task-level overall average token composition: input 53.9%, output 24.4%, reasoning 21.6%
    • Input और output tokens का लगभग 2:1 अनुपात पूर्व शोध के “communication tax” के लिए मजबूत अनुभवजन्य प्रमाण देता है
    • Collaborative conversations के दौरान agents बार-बार बड़े context को आगे बढ़ाते हुए tokens खर्च करते हैं
    • मौजूदा agent collaboration protocols में नया output generate करने की तुलना में context transfer पर अधिकतर tokens खर्च होने की inefficiency मौजूद है
    • Communication tax conversational multi-agent architectures की अंतर्निहित विशेषता हो सकती है, और यह भविष्य के शोध का विषय है

  • खोज 3: Development stages के अनुसार tokenomic profile में अंतर

    • Stage-wise token ratios हर software engineering activity के लिए विशिष्ट patterns बनाते हैं
    • Coding चरण output-centered अपवाद है, जहाँ output 58.0% और input 6.9% था
    • Coding चरण की output-centered संरचना उस task nature से मेल खाती है जिसमें संक्षिप्त design specification से लंबा source code बनाया जाता है
    • Code review और documentation जैसी verification तथा documentation stages input-centered हैं
    • Code review में input का हिस्सा 51.4% था
    • Documentation में input का हिस्सा 80.2% था
    • ये stages बड़े context के रूप में मौजूदा code को consume करती हैं और अपेक्षाकृत छोटे analytical outputs उत्पन्न करती हैं
    • Stage-wise token profiles को engineering activities के cost map के रूप में इस्तेमाल किया जा सकता है
    • Practitioners इससे cost prediction और process optimization के अवसरों की बेहतर पहचान कर सकते हैं

  • चरणवार token ratios

    • Design चरण का औसत अनुपात: input 60.4%, output 3.6%, reasoning 36.0%
    • Coding चरण का औसत अनुपात: input 6.9%, output 58.0%, reasoning 35.1%
    • Code completion चरण का औसत अनुपात: input 47.7%, output 41.7%, reasoning 10.5%
    • Code review चरण का औसत अनुपात: input 51.4%, output 24.7%, reasoning 23.9%
    • Testing चरण का औसत अनुपात: input 60.8%, output 20.7%, reasoning 18.4%
    • Documentation चरण का औसत अनुपात: input 80.2%, output 8.3%, reasoning 11.5%
    • Task-level overall average ratio: input 53.9%, output 24.4%, reasoning 21.6%

  • चर्चा

    • प्रारंभिक परिणाम agentic software development के लिए शुरुआती cost map प्रदान करते हैं
    • Code review चरण की बड़ी token cost को “conversation cost” के रूप में समझा जा सकता है
    • यह लागत सीधे LLM-MA systems की conversational architecture से उत्पन्न होती है, जहाँ agents पूरा code context बार-बार साझा करके code सुधारते हैं
    • वर्तमान verification-oriented agent collaboration protocols बहुत अप्रभावी हो सकते हैं, क्योंकि छोटे fixes वाले tasks में भी वे भारी resources खर्च कर देते हैं
    • यह MAST taxonomy के verification failures और stage repetition से जुड़े निष्कर्षों के साथ भी मेल खाता है
    • अधिक token usage इस बात का लक्षण हो सकता है कि agent systems अपने अंतर्निहित coordination issues को brute-force conversation के ज़रिए पार करने की कोशिश कर रहे हैं
    • Practitioners agent-based project costs का अनुमान आवश्यक task type के आधार पर लगा सकते हैं
    • शुरुआती coding-heavy greenfield projects और existing code refactoring/debugging-केंद्रित projects की लागत संरचना अलग होती है
    • Existing code refactoring/debugging-केंद्रित projects में महँगे और input-heavy code review cycles लागत पर हावी रहते हैं
    • Code review चरण से पहले “human-in-the-loop” checkpoints को integrate करना महँगे iterative loops को रोकने और आर्थिक व computational efficiency बढ़ाने वाले design decisions में मदद कर सकता है
    • शोध का एक मुख्य कार्य verification और refinement के लिए अधिक token-efficient collaboration protocols डिज़ाइन करना है
    • केवल पूरा context पास करने से आगे की विधियों की आवश्यकता है
    • Standardized और comprehensive evaluation framework की भी आवश्यकता है
    • यह framework ChatDev के hierarchical conversational workflow और MetaGPT की SOP-आधारित assembly line जैसी अलग-अलग LLM-MA architectures की efficiency को benchmark और compare करने के लिए common basis बन सकता है
    • यह framework-specific behavior को universal software engineering activities में अनुवाद करने वाली “Rosetta Stone” की भूमिका भी निभा सकता है

वैधता के लिए खतरे और आगे के कार्य

  • वैधता के लिए खतरे

    • विश्लेषण एक ही LLM-MA system, ChatDev, और एक ही LLM, GPT-5 Reasoning Model, पर आधारित है
    • देखे गए token consumption patterns अन्य LLM-MA architectures या अलग token efficiency वाले LLMs में भिन्न हो सकते हैं
    • 30 software development tasks विविध हैं, लेकिन वे सभी संभावित software development scenarios और complexities का प्रतिनिधित्व नहीं कर सकते
    • Curated dataset का आकार सीधे इस तथ्य से प्रभावित है कि software engineering-specific agent traces के लिए सार्वजनिक बड़े benchmark उपलब्ध नहीं हैं
    • Data curation समय और लागत दोनों की दृष्टि से महँगी प्रक्रिया है
    • कुछ development stages केवल 30 tasks के छोटे subset में ही execute हुईं
    • Code completion n=6 और testing n=12 के साथ कम बार trigger हुए
    • इसलिए इन specific stages के tokenomic profile पर निष्कर्ष छोटे sample पर आधारित हैं, जिससे उनकी representativeness कम हो सकती है और generalizability सीमित हो सकती है
    • ChatDev की internal stages को software development stages से मैप करने का तरीका एक abstraction है
    • Standardized evaluation framework बनाने के लिए यह एक तार्किक और उपयोगी mapping है, लेकिन agent activities को मैप करने के कई संभावित तरीकों में से केवल एक है

  • निष्कर्ष और आगे के कार्य

    • Agentic software engineering में token cost समान रूप से वितरित नहीं होती, बल्कि iterative और conversational code review चरण में भारी रूप से केंद्रित होती है
    • “Communication tax” बनाने वाले input tokens कुल token usage का अधिकांश हिस्सा लेते हैं, और यही भविष्य के optimization का मुख्य क्षेत्र है
    • भविष्य का पहला कार्य dataset को अधिक tasks तक बढ़ाना है ताकि generalizability सुधरे
    • दूसरा कार्य विश्लेषण को अन्य LLMs तक बढ़ाकर model-specific effects समझना है
    • तीसरा कार्य अन्य LLM-MA systems तक विश्लेषण का विस्तार करना है ताकि architecture differences का tokenomics पर प्रभाव तुलना किया जा सके
    • चौथा कार्य token consumption patterns और failure modes के बीच संबंध की जाँच करना है
    • पाँचवाँ कार्य software engineering agent efficiency benchmarking के लिए robust और universal development-stage mapping framework का आगे विकास और validation करना है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 일 전
Hacker News की राय

  • मैं व्यक्तिगत उपयोग के लिए एक multi-agent system बनाकर इस्तेमाल कर रहा हूँ
    जब कोई समस्या दी जाती है, तो पहले एक तेज़ और सस्ता मॉडल सवाल पूछता है, और उन जवाबों के आधार पर input prompt को refine करता है
    उसके बाद समस्या को sections में बाँटता है और एक अंतिम judge निष्कर्ष देता है, या कई agents आपस में बहस करने के बाद judge उसका सार देता है—ऐसी रणनीतियों में से एक चुनी जाती है
    सबसे अच्छा तरीका वह है जिसे मैं all angles कहता हूँ, जिसमें कई strategies को parallel चलाया जाता है और एक अंतिम meta-judge responses को समेकित करता है
    हाल में जो फीचर जोड़ा है, उसमें सबसे उपयोगी हिस्सा वह screen है जहाँ हर strategy के बीच का variance देखा जा सकता है
    मैं इसे घर खोजने, स्कूल और परिवार से जुड़ी रोज़मर्रा की समस्याओं जैसे जीवन के मुद्दों में इस्तेमाल कर रहा हूँ

    • मैंने जो बनाया है उसका वीडियो demo यहाँ है: https://streamable.com/e49cgt
    • आपने लागत का ज़िक्र किया था, तो क्या समस्या के प्रकार के हिसाब से मोटे तौर पर cost structure के बारे में थोड़ा और बता सकते हैं?
      कौन-सी strategy इस्तेमाल होती है, और strategy के हिसाब से लागत कैसे बदलती है, यह भी जानना चाहूँगा
    • आप कौन-सा execution harness इस्तेमाल करते हैं, और कौन-से LLMs इस्तेमाल करते हैं, यह जानना चाहता हूँ
    • मैंने भी ऐसा ही एक system बनाया था, लेकिन prompt की exploratory improvement की बजाय feedback loop पर ज़्यादा ध्यान दिया
      cybernetics-शैली में, deterministic checks और auto-fix libraries को लगातार बढ़ाते हुए prompt output की stability बनाए रखने का तरीका है
      और जो “समस्याएँ” उस library से handle नहीं होतीं, उन्हें process चला रहे व्यक्ति के सामने उजागर किया जाता है

  • मैंने एक महीने तक GitHub Copilot को बिना रुकावट काफ़ी इस्तेमाल किया, लेकिन pricing change के बाद अगले महीने सिर्फ़ दो दिन में ही सारे tokens ख़त्म हो गए
    ऐसा तेज़ बदलाव इस बात का संकेत लगता है कि token pricing मनमानी है, और AI business में पैसा बहुत तेज़ी से खत्म हो रहा है

    • मुझे तो यह ज़्यादा से ज़्यादा valuation या IPO को आगे बढ़ाने का नतीजा लगता है
      ऐसी अफ़वाहें भी हैं कि inference margin 70% से ऊपर है
      SpaceX का उदाहरण लें तो पिछले 6 महीनों में consumer products की कीमतें कुल मिलाकर बढ़ी हैं, लेकिन Alphabet और Anthropic मिलकर हर महीने 2 billion dollars से ज़्यादा दे रहे हैं, इसलिए पैसों की कमी नहीं है
      Microsoft/GitHub तो किसी और के product को repackaging करने की स्थिति में था, इसलिए यहाँ नुकसान उसी का हुआ है
    • GitHub का मामला हाल की pricing policy change की वजह से एक असामान्य रूप से तेज़ दिखने वाला अपवाद के ज़्यादा क़रीब है
      आम तौर पर pricing कई आधारभूत कारकों पर तय होती है; इसका यह मतलब नहीं कि वह अपने आप में मनमानी है
      उदाहरण के लिए, अगर GitHub के executives ने random number generator से token prices तय किए होते, तो उसे मनमानी pricing कहा जाता

  • इसमें कहा गया है कि “input tokens औसतन 53.9% के साथ consumption का सबसे बड़ा हिस्सा हैं”, लेकिन मेरे usage में ratio लगभग 10:1 है
    खर्च होने वाले tokens का भारी बहुमत input side पर होता है, और अक्सर agent सिर्फ़ code की एक line बदलने के लिए 1 million tokens पढ़ लेता है
    अगर यह 1:1 के क़रीब हो, या output side ज़्यादा बड़ी हो, तो मुझे लगता है कि agent में कोई समस्या है या codebase नया है या खाली है

    • क्या आपने agent को codebase को explore और document करना आसान बनाने के लिए AST, language server जैसे बेहतर tools देने की कोशिश की है?
      1 million uncached tokens काफ़ी ज़्यादा लगते हैं
    • अगर input tokens लागत पर इतना हावी हैं, तो इसका मतलब है कि caching का बेहतर इस्तेमाल भर से भी बड़ा सुधार हो सकता है
      model से relevant code हिस्सों को dump करके एक one-time “compression” step कराया जा सकता है, और उसके result को कई sub-agent calls के cached prefix की तरह इस्तेमाल किया जा सकता है

  • coding में agents का इस्तेमाल करें तो वे unit tests हज़ारों की संख्या में लिखना चाहते हैं, लेकिन dynamically test करने की प्रवृत्ति कमज़ोर होती है

    • और semantic रूप से बेकार tests लिखकर और उन्हें debug करने में बहुत सारे tokens जला देने का भी उन्हें बड़ा शौक़ है
    • unit tests भी dynamic testing का ही एक प्रकार हैं
      static tests वे हैं जैसे lint या type checks
      अगर आप unit tests के अलावा किसी और तरह के dynamic tests चाहते हैं, तो क्या आपने planning या PRD stage में उसे requirement के तौर पर explicitly लिखा है?
    • AWS भी साधारण requirements के लिए बिल करने योग्य AWS services को जितना हो सके उतना जोड़ने वाले जटिल Lambda solutions को बहुत aggressively आगे बढ़ाता है
      उनके incentives हमेशा आपके incentives से मेल नहीं खाते
      इस मामले में वे चाहते हैं कि आप बेकार काम पर अनावश्यक पैसा खर्च करें
      अब शायद “tokens” जैसी euphemism का इस्तेमाल बंद कर देना चाहिए
    • आप बस ज़्यादा dynamic tests करने का निर्देश दे सकते हैं
      मुझे लगता है dynamic testing से एक हद तक बचने की वजह यह है कि इससे गति धीमी पड़ती है, और software अनपेक्षित जगहों पर रुक सकता है

  • इससे मुझे पिछले साल का एक paper याद आया, जिसमें token usage efficiency को optimize करने के लिए budget guidance information दी गई थी
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • यह airline reward mileage जैसा है, और कंपनियों के नज़रिए से bare-metal GPU time किराये पर लेने की तुलना में इसका कोई ख़ास फ़ायदा नहीं है

    • उम्मीद है कि जब ज़्यादा hardware कंपनियाँ सस्ते NPU लाएँगी और model sizes और बेहतर optimize होंगी, तो यह भयानक दौर जल्द खत्म होगा
      जब AI की ज़्यादातर demand on-premises या on-device hardware और models से पूरी की जा सकेगी, तब यह सोचने वाली बात होगी कि इतने बड़े compute farms और models, जिन पर इतना operational cost आता है, आखिर किस काम आएँगे
      शायद तब सिर्फ़ बड़े governments ही ग्राहक बचेंगे, और अंत में AI cartel द्वारा निवेश किए गए billions of dollars का भुगतान taxpayers करेंगे

  • मैंने दिसंबर में इस विषय पर एक Substack post लिखी थी: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

  • पहले Google जैसी कंपनियाँ engineers को इस आधार पर hire करती थीं कि वे infrastructure को कितना अच्छी तरह optimize कर सकते हैं
    जल्द ही कंपनियाँ शायद engineers की AI token efficiency optimization क्षमता को देखने लगें

    • इसके लिए यह मानना पड़ेगा कि tokens आगे भी एक meaningful cost बने रहेंगे
      यह कहना मुश्किल है कि developers जिन नई चीज़ों पर ज़्यादा tokens खर्च करना सीखेंगे, उसकी रफ़्तार token prices के गिरने की रफ़्तार जितनी तेज़ होगी या नहीं
    • मुझे कंपनी की token cost को 0 तक लाने का तरीका पता है
      tokens को internet की तरह utility cost मान लीजिए और उसका भुगतान engineers से सीधे कराइए

  • एक दिलचस्प साइड नोट के तौर पर, मैं एक मीटिंग में था जहाँ नए product candidates की समीक्षा हो रही थी; सब ठीक चल रहा था, फिर उस product में AI जोड़े जाने वाली screen दिखाई गई
    जैसा अपेक्षित था, उसमें AI जोड़ा गया था और वह काफ़ी ज़बरदस्ती ठूँसा हुआ लग रहा था
    उस बनावटीपन का एक संकेत यह था कि वहाँ एक column था जो दिखाता था कि हर query में कितने tokens लगे
    मैंने पूछा कि token cost कौन देता है, तो जवाब मिला कि वह license में शामिल है; फिर मैंने पूछा कि क्या कोई budget cap है या यह unlimited है, तो उन्होंने कहा अच्छा सवाल है, जाँचकर बताएँगे
    मैंने यह इसलिए पूछा क्योंकि अभी जो साधारण device-related query दिखाई गई थी, उसने 250k tokens जला दिए थे
    तभी सामने वाली तरफ़ के एक executive की ऊँची आवाज़ सुनाई दी: “हम यह ग्राहकों को दिखा ही क्यों रहे हैं?” और हम काफ़ी हँसे
    इससे मैंने यह सीखा कि किसी भी चीज़ में AI जोड़ने की लागत का ठीक से हिसाब नहीं लगाया जा रहा, और वास्तविक AI operations की असली लागत तो उससे भी कम दिखाई जाती है
    चाहे आप चाहें या नहीं, AI जुड़ी हर चीज़ महँगी होने वाली है

    • AIshittification

  • Tokenomics तो पहले से cryptocurrency economics को समझाने वाला शब्द है, तो AI में इस्तेमाल होने वाले tokens अलग प्रकार के हों, फिर भी इस शब्द को फिर से परिभाषित करने की ज़रूरत क्यों है, समझ नहीं आता

    • Tokenomics शब्द cannabis enthusiasts के बीच भी बहुत पहले से इस्तेमाल होता रहा है
    • यह एक नया fad है
      पुराना fad भूल जाइए; यह भी जल्द पुराना हो जाएगा, इसलिए बहुत देर होने से पहले इस पर सवार हो जाइए
    • cryptocurrency economics = cryptonomics
    • “Crypto” शब्द भी cryptocurrency के उसे अपना लेने से बहुत पहले से मौजूद था
      “Web 3.0” भी cryptocurrency वालों के Web3 को crypto-केंद्रित बनाने से पहले से था
      इसलिए मुझे समझ नहीं आता कि समस्या क्या है
      terms अलग-अलग contexts में बार-बार reuse होते रहते हैं
      और वैसे भी, ज़्यादातर लोग पहले ही cryptocurrency से आगे बढ़ चुके हैं, इसलिए confusion की संभावना भी बहुत ज़्यादा नहीं है