टोकन की कीमत लगातार महंगी होती जा रही है
(ethanding.substack.com)- LLM टोकन लागत हर साल 10 गुना घटने की उम्मीद के विपरीत, AI subscription services की profitability लगातार खराब होती जा रही है
- नवीनतम LLM models की मांग हमेशा शीर्ष स्तर के (SOTA, State-of-the-art) models पर केंद्रित रहती है, इसलिए “पुराने” models की कीमत में गिरावट वास्तविक cost savings में नहीं बदलती
- जैसे-जैसे model performance बढ़ती है, इस्तेमाल होने वाले tokens की मात्रा geometric rate से बढ़ती है, जिससे प्रति-token कीमत में गिरावट बेअसर हो जाती है और कुल लागत उलटे तेजी से बढ़ती है
- unlimited subscription plans के प्रयोग (जैसे Claude Code $200/माह) भी heavy users के token explosion के कारण टिकाऊ नहीं हैं
- लंबे समय में usage-based pricing के अलावा कोई टिकाऊ मॉडल नहीं है, लेकिन startup competition और consumer resistance के कारण इसे व्यवहार में लाना कठिन है
- अगर sustainable revenue model की ओर बदलाव नहीं हुआ, तो अधिकांश startups अंततः दिवालिया होने के जोखिम का सामना करेंगे
AI subscription business: token unit price गिरने के बावजूद घाटा ही क्यों बढ़ रहा है
LLM कीमत गिरने का भ्रम
- संस्थापक अक्सर इस VC playbook पर भरोसा करते हैं कि "token unit price 10 गुना-10 गुना घटेगी, इसलिए बस कुछ समय टिके रहो, फिर business high-margin structure में बदल जाएगा"; इसी भरोसे वे शुरुआती दौर में subscription products को लागत-स्तर पर या घाटे में चलाते हैं
- वास्तव में GPT-3.5 जैसे पुराने models की token unit price 10 गुना से अधिक गिरी है, लेकिन users और market demand हमेशा सबसे नए और सर्वश्रेष्ठ प्रदर्शन वाले (SOTA) models पर ही केंद्रित रहती है
- हकीकत में 18 महीने बाद भी margins सुधरने के बजाय और बिगड़ते दिखते हैं
- पुराने models की कीमत में कटौती का असर तभी महसूस होता है जब वे "कल के अखबार" की तरह पहले ही market interest से बाहर हो चुके हों
नवीनतम models की कीमत और demand structure
- GPT-4, Claude 3 Opus जैसे नवीनतम models हमेशा लगभग समान ऊंची कीमत पर लॉन्च होते हैं, और पुराने models चाहे जितने सस्ते हो जाएं, उनका वास्तविक usage बहुत कम रहता है
- users को सिर्फ "best performance" चाहिए; "सस्ते पुराने models" कार बाजार की पुरानी second-hand cars जैसे हैं
- AI इस्तेमाल करते समय लोग वास्तव में सबसे बेहतरीन परिणाम चाहते हैं, इसलिए पैसे बचाने के लिए पुराना model स्वेच्छा से इस्तेमाल करने के मामले दुर्लभ हैं
- आखिरकार market में competitive बने रहने के लिए हमेशा सबसे महंगा, सबसे नया model देना पड़ता है, और इसी वजह से लागत बनी रहती है
- यह कुछ ऐसा है जैसे 90 के दशक की used cars की कीमत गिर जाए, लेकिन consumer फिर भी नई car ही खरीदे
token usage में विस्फोटक बढ़ोतरी
- model performance बढ़ने के साथ एक ही task में खर्च होने वाले tokens की संख्या geometric rate से बढ़ने लगी है
- पहले जो काम 1,000 tokens में खत्म हो जाता था, अब वह 100,000 tokens तक खपा सकता है
- पहले एक वाक्य के सवाल का एक वाक्य के जवाब से काम हो जाता था, लेकिन अब complex research, loops और orchestration की वजह से systems 10~20 मिनट तक लगातार चलते हैं और भारी token usage पैदा करते हैं
- AI से अधिक गहरा research/analysis करवाने के कारण "एक run में 20 मिनट, दिन के 24 घंटे लगातार run" जैसी स्थिति बनती है, जिससे प्रति user औसत दैनिक usage तेजी से बढ़ता है
- उदाहरण के लिए, अगर कोई user रोज सिर्फ 1 बार $1 के बराबर का 'deep research' इस्तेमाल करे, तब भी $20 subscription fee पर यह model टिकाऊ नहीं रहता
- unit price में गिरावट कुल token consumption में बढ़ोतरी से offset हो जाती है, और $20/माह की plan में रोजाना एक $1 का task भी उठाना मुश्किल हो जाता है
unlimited plans की विफलता
- Anthropic का Claude Code आदि $200/माह unlimited plan, automatic token optimization, user PC utilization जैसे कई cost-cutting उपाय आजमा चुके हैं
- लेकिन कुछ power users ने एक महीने में 10 billion tokens तक इस्तेमाल कर लिए ("War and Peace" की 12,500 प्रतियों के बराबर), क्योंकि users ने automation, repeated tasks और loops का इस्तेमाल कर token consumption को विस्फोटक बना दिया
- "AI usage इंसानी समय से अलग होकर API को 24 घंटे चलाता है और token frenzy पैदा करता है"
- engineering innovation के बावजूद आखिरकार plan rollback करना पड़ा
- निष्कर्ष: अब unlimited subscription model संभव नहीं है, यह गणित ही नहीं बैठता
पूरे industry के सामने खड़ी दुविधा
- अगर subscription model पर अड़े रहे, तो profitability गिरने और collapse का जोखिम बढ़ता जाएगा
- सभी AI कंपनियां जानती हैं कि usage-based pricing ही जवाब है, लेकिन अगर subscription-based competitor आ जाए तो users churn कर सकते हैं
- "prisoner's dilemma" जैसी स्थिति में सभी को power-user subsidy competition में धकेला जा रहा है
- Cursor, Replit आदि भी "पहले growth, profitability बाद की समस्या" वाले दृष्टिकोण से चल रहे हैं, लेकिन अंततः profitability issue के कारण restructuring से बचना मुश्किल होगा
व्यवहारिक समाधान: 3 रास्ते
- 1. usage-based pricing
- अगर शुरुआत से ईमानदार आर्थिक मॉडल अपनाया जाए, तो लागत से ऊपर revenue structure डिजाइन किया जा सकता है। लंबे समय में यही एकमात्र sustainable model है
- लेकिन consumers metered billing को बेहद नापसंद करते हैं, इसलिए mass adoption मुश्किल है
- 2. ऊंची switching cost वाले enterprise market को target करना
- ऊंची switching cost वाले enterprise customers (जैसे बड़े corporates, financial institutions) को B2B sales के जरिए onboard किया जाए, तो एक बार market में entry के बाद churn लगभग असंभव हो जाता है और margins ऊंचे रहते हैं
- system of record (SOR, CRM/ERP/EHR आदि) क्षेत्र इसका प्रमुख सफल उदाहरण है (जैसे Goldman Sachs के 40,000 engineers के लिए adoption)
- 3. vertical integration के जरिए value creation
- Replit की तरह LLM inference को खुद नुकसान उठाकर एक 'bait product' की तरह दिया जाए, और उसके ऊपर बनी hosting, database, deployment, monitoring जैसी कई services से revenue कमाया जाए
- ऐसा ढांचा बनाया जाए जिसमें AI usage बढ़कर infrastructure market तक पहुंचे
- आगे भी token unit price घटती रहेगी, लेकिन user expectations और usage भी geometric rate से बढ़ते रहेंगे
- जो कंपनियां सिर्फ subscription-plus-growth strategy पर टिकी रहेंगी, उनके लिए अंततः 'महंगे अंतिम संस्कार' जैसी स्थिति का जोखिम बहुत अधिक है
सारांश
- "अगले साल token 10 गुना सस्ते हो जाएंगे" जैसी आशावादी सोच भर से business नहीं चल सकता
- users हमेशा ज्यादा ऊंची expectations और ज्यादा usage की मांग करेंगे
- model advancement = usage explosion = cost increase का सूत्र अब साफ दिख रहा है, और sustainable AI business को आखिरकार usage-based billing, large enterprise contracts, और vertical integration के जरिए नई संरचना की ओर बढ़ना होगा
- अगर business को टिकाए रखना है, तो 'Neocloud' strategy जैसी नई structural approach की जरूरत होगी
4 टिप्पणियां
कैशिंग की मुश्किलें + MCP का इस्तेमाल करने वाली automation की वजह से unlimited use सचमुच शाब्दिक अर्थों में unlimited use तक जा सकता है। ..जैसे unlimited data plan न देने वाली telecom companies में दिन ~300 बार, दिन ~2000 बार वगैरह.. लगता है कि यह पुराने SMS जैसे pricing model की ओर भी जा सकता है।
इंटरनेट की तरह, जहाँ मात्रा अपने आप में असीमित होती है (हालाँकि कुछ मामलों में usage-based billing भी लग सकती है), अगर स्पीड पर सीमा लगाने वाले तरीके से जाया जाए तो अच्छा होगा। implementation की बात करें तो, जैसे अभी भी batch processing का तरीका मौजूद है, वैसे ही compute resources और user तक पहुँचने वाले resources को अलग किया जा सकता है। आखिरकार अगर provider की नज़र से predictability सुनिश्चित हो सके, और user को भी उचित कीमत और स्पीड की गारंटी मिले, तो क्या यह win-win नहीं होगा? कुछ heavy users के मामले में, अलग contract के ज़रिए dedicated resources allocate करने के तरीके से जाना होगा।
Hacker News की राय
लेख में उद्धृत बातों के अनुसार, उपभोक्ता pay-as-you-go billing (मीटर आधारित शुल्क) पसंद नहीं करते और चौंका देने वाले बिल मिलने से बेहतर अनलिमिटेड प्लान के लिए ज़्यादा भुगतान करना पसंद करते हैं। लेकिन असलियत इससे अधिक जटिल है। Amazon में अक्सर ऐसा होता है कि जैसे ही आपको लगता है कि आपने लागत का अनुमान लगा लिया है, अचानक बहुत बड़ा बिल आ जाता है। वजह यह है कि "अगर महीने में X डॉलर से ऊपर जाए तो अपने-आप बंद कर दो" जैसी सेटिंग का कोई तरीका नहीं होता। इस तरह की "surprise net 30" संरचना हमेशा अनुमानित लागत जैसी लगती है, लेकिन आखिर में अप्रत्याशित अतिरिक्त खर्च वापस आ ही जाता है। लेकिन अगर pay-as-you-go में यूज़र अपना उपयोग साफ़-साफ़ देख सके और बजट पार होने से रोकने के लिए अधिकतम सीमा तय कर सके, तो यह उल्टा एक अच्छा तरीका भी हो सकता है। AI कंपनियों के लिए इतना काफ़ी होगा कि वे "used tokens / total tokens" bar chart, प्रति-रिस्पॉन्स token उपयोग, और सीमा से पहले अनुमानित बचे हुए response count जैसी चीज़ें दिखाएँ, ताकि यूज़र अपना बजट मैनेज कर सके। अचानक बिल देना बिल्कुल नहीं होना चाहिए। लेकिन कंपनियाँ token और dollar की यह जानकारी छिपाना पसंद करती हैं, ठीक वैसे ही जैसे gambling sites अपने "corporate bucks" को सीधे USD से जोड़कर नहीं दिखातीं।
infrastructure के रूप में B2B services (AWS आदि) के लिए pay-as-you-go उपयुक्त लगता है। कंपनी के बढ़ने के साथ infrastructure usage और शुल्क अनुपात में बढ़ते हैं, इसलिए उनका अनुमान लगाया जा सकता है, और infrastructure एक बार सेट हो जाए तो बाद में उस पर ज़्यादा ध्यान नहीं देना पड़ता। लेकिन AI जैसे काम/टूल के उपयोग में pay-as-you-go billing एक बड़ी रुकावट है। ऐसे मामलों में यह pricing मॉडल खुद product usage को हतोत्साहित करता है, और हर बार इस्तेमाल करते समय लागत बनाम प्रभाव का आकलन करने की थकान पैदा करता है। अगर इसे काम में इस्तेमाल किया जाए, तो शायद हर बार manager की approval भी लेनी पड़े। productivity बढ़ाने के लिए बने टूल को ऐसी बाधा नहीं बनानी चाहिए। लगभग कोई भी व्यक्ति 250 बार यह नहीं सोचता, "क्या यह action 3 डॉलर के लायक है?" अगर pay-as-you-go हो, तो लोग बस इस्तेमाल ही नहीं करेंगे।
कंपनियाँ tokens को dollars में बदलने की जानकारी छिपाती हैं, यह बात खटकती है। मैं GitHub के Copilot agent trial को आज़मा रहा हूँ, और उसकी pricing बेहद अपारदर्शी है। बार-बार सिर्फ़ "premium requests" शब्द सामने आता है, लेकिन मेरे dashboard में real-time usage या limits दिखाई नहीं देतीं। UI में premium requests वाली बात पर क्लिक करने से documentation खुलती है, लेकिन असली limit या pricing dashboard का कोई साफ़ रास्ता नहीं मिलता।
Amazon (AWS) में समस्या और भी गंभीर है। AWS का "सस्ता पड़ता है" वाला लालच अपनी जगह है, लेकिन बदलाव तभी मायने रखता है जब वह विकल्पों से वास्तव में सस्ता हो। फिर भी, कई कंपनियाँ developers का समय लगाकर infrastructure नहीं बदलतीं। opportunity cost बड़ा होता है, और risk (revenue, dev time, competition आदि) भी होता है, इसलिए जब तक return बहुत बड़ा न हो, इसे developer time की बर्बादी माना जाता है। अगर infrastructure architecture आखिरकार विकल्प से ज़्यादा महँगा पड़ गया, तो developers का समय पहले ही लग चुका होता है, इसलिए उस नुकसान को झेलना ही पड़ता है। अभी token-based pricing में यह migration/opportunity-cost वाला बोझ उतना बड़ा महसूस नहीं होता, क्योंकि पुराने तरीके पर वापस जाना आसान है। लेकिन आगे चलकर यह ढाँचा बदल जाएगा, ऐसा लगता है।
Amazon की pricing structure बहुत अस्पष्ट और जटिल लगती है। उदाहरण के लिए, कभी-कभी यह समझने का कोई तरीका नहीं होता कि database की लागत लगातार ऊपर-नीचे क्यों हो रही है।
परिभाषित प्रक्रियाओं के लिए pay-as-you-go वाकई बहुत उपयोगी है। AWS की जो बात मुझे पसंद है, वह यह है कि लागत को असली business के साथ align किया जा सकता है। पहले यह मुश्किल था और internal politics भी बहुत होती थी। कभी sales वाला सीधे executives के पास जाकर equipment की ज़रूरत का मामला रखता था, और नतीजतन ऐसे network gear भी ले लेने पड़ते थे जिनकी किसी को ज़रूरत नहीं थी। लेकिन यूज़र के नज़रिए से इस तरह की granular cost management अच्छी नहीं है, क्योंकि इससे productivity से सीधे जुड़ी न होने वाली तरह-तरह की metrics पर यूज़र का लगातार मूल्यांकन होने लगता है। 90 के दशक में intern रहते समय एक long-distance phone call approve करवाने के लिए bureaucracy झेलनी पड़ती थी। approver यह तक जज करता था कि 20 मिनट की कॉल उचित थी या नहीं, और सीमा पार हुई तो खर्च मुझे उठाना पड़ता था। मज़ेदार अनुभव नहीं था। consumer-facing AI के लिए fixed pricing ही सही जवाब है। अगर मेरी productivity 20% बढ़ती है और मैं ChatGPT Pro पर $200/month खर्च करता हूँ, तो सालाना $16k की value बनती है। यह बेहद सस्ता निवेश है।
लेख के दावे मुझे तार्किक नहीं लगते। "जैसे ही नया मॉडल आता है, 99% demand तुरंत उसी पर चली जाती है" — इस बात से सहमत होना मुश्किल है। उल्टा Sonnet 4 का उपयोग Opus 4 से ज़्यादा हो रहा है, और वास्तव में बहुत से यूज़र सबसे उच्च प्रदर्शन वाले मॉडल नहीं, बल्कि सस्ते और सामान्य मॉडल इस्तेमाल करते हैं। usability, speed, familiarity जैसी कई वजहों से SOTA नहीं, बल्कि तरह-तरह के मॉडल साथ-साथ इस्तेमाल होते हैं। मॉडल रैंकिंग देखें: https://openrouter.ai/rankings और Opus से Sonnet, भारी लोड पर Haiku पर स्विच होने की बात को जैसे autoscaling की तरह समझाया गया है, मुझे नहीं लगता कि वैसा व्यवहार मॉडल weights में built-in होगा। कुल मिलाकर, लेख में pricing की समस्या cloud hosting के दौर की पुरानी समस्याओं की पुनरावृत्ति जैसी लगती है — बहुत से यूज़र monthly subscription के तहत थोड़ा कम performance होने पर भी सुविधा के लिए इस्तेमाल करते हैं, और कुछ API users (heavy users/companies) pay-as-you-go पर चलते हैं। इस ढाँचे की profitability पहले से साबित है। ज़्यादातर AI startups B2B हैं, B2C नहीं।
"Claude Code पहले $200/mo में अनलिमिटेड देता था और फिर rollback कर दिया" — यह बात तथ्यात्मक रूप से गलत है। प्लान का नाम ही 20x plan था, और 5 घंटे का session limit तथा monthly 50-session limit (भले इसे सख़्ती से लागू न किया गया हो) जैसी स्पष्ट सीमाएँ शुरू से मौजूद थीं। मैं खुद इसे इस्तेमाल करते हुए शायद ही कभी कमी महसूस कर पाया हूँ; बल्कि अब भी limits काफ़ी ऊँची लगती हैं। इसलिए सच बताने से भी तर्क को कोई नुकसान नहीं पहुँचता।
वास्तविक बड़ा मुद्दा यह है कि अभी हम बिना भेदभाव के मॉडल उपयोग कर रहे हैं — यानी हर समस्या पर सबसे भारी general-purpose मॉडल दाग रहे हैं, जैसे मच्छर पर तोप चलाना। हर समस्या के लिए SOTA मॉडल की ज़रूरत नहीं होती। आगे चलकर इस्तेमाल की जाने वाली services कई मॉडलों के "bundling" की दिशा में जाएँगी, और तब कहीं ज़्यादा कुशल usage graph देखने को मिलेगा।
अभी तक कोई भी मॉडल इतना भरोसेमंद नहीं है कि उसे मुख्य काम पूरी तरह सौंप दिया जाए। सबसे अच्छे मॉडल भी कभी-कभी अजीब व्यवहार करते हैं। मेरा दिमाग़ काम अपने-आप प्रोसेस कर लेता है, इसलिए delegation पर अलग से सोचने की ज़रूरत नहीं पड़ती। इसलिए मैं AI को तभी काम दूँगा जब उससे "पक्का लाभ" हो। मैं पहले वही करता हूँ जिसमें मैं खुद अच्छा हूँ। AI कंपनियाँ सर्वोच्च performance का विज्ञापन करती हैं, लेकिन यूज़र के लिए AI के "सबसे खराब पल" ही महत्वपूर्ण metric होते हैं। इसी वजह से SOTA की माँग बनी रहती है। AI का मूल्यांकन उसके 'worst moments' पर होता है — चाहे वह 100 बार अच्छा करे, एक गलती भी घातक हो सकती है, जैसे इंसान को उसकी सबसे बुरी गलती पर नौकरी से निकाला जाता है। परफेक्ट केस (lab environment) performance महत्वपूर्ण नहीं है; वास्तविक उपयोग में जब चीज़ें टूटती हैं, वह ज़्यादा महत्वपूर्ण है। लेख में यह बात साफ़ उभरती है।
अभी भी सबसे कठिन tasks हल नहीं हुए हैं, और ऐसे काम बहुत कम हैं जहाँ कम accuracy वाले जवाब स्वीकार किए जा सकें। कुछ text pipeline कार्यों में यह ठीक हो सकता है, लेकिन लगभग सभी user-facing उपयोगों में high quality की मांग होती है।
बहुत लोग इस हिस्से को नज़रअंदाज़ कर देते हैं। 7b, 32b GPU models भी कई कामों में काफ़ी अच्छे चलते हैं, और पुराने hardware पर भी चल जाते हैं। अभी पूरा LLM performance क्षेत्र hype phase में है, इसलिए समय के साथ बड़े मॉडलों के performance gains धीमे पड़ेंगे और ज़्यादा व्यावहारिक विकल्प उभरने लगेंगे।
अलग-अलग मॉडलों के साथ प्रयोग करना काफ़ी मूल्यवान है। हाल ही में मैंने जो एक साधारण chatbot system बनाया, वह स्थिति के हिसाब से 5 अलग मॉडल इस्तेमाल करता है। मॉडलों को बदलना और मिलाकर इस्तेमाल करना लागत, user experience और quality — तीनों में बहुत बड़ा फर्क लाता है।
अगर Claude Opus के पास Sonnet को guide करने का विकल्प हो, तो मैं लगभग हर बातचीत में उसका उपयोग करूँगा। इसे हाथ से करना झंझट भरा है और flow टूट जाता है, इसलिए अंत में मैं बस Opus ही इस्तेमाल करता रहता हूँ। parallel processing की वजह से input cost कम है, इसलिए prompt बड़ा होने पर भी बहुत बोझ नहीं लगता।
अच्छा होगा अगर कोई AI कंपनी ऐसा system बनाए जो tasks में से सरल हिस्सों को ज़्यादा 'मंद' मॉडल को सौंप सके। जटिल कामों के लिए Opus-स्तर का मॉडल चाहिए, लेकिन उनके अंदर भी बहुत सारे हिस्से ऐसे होते हैं जिन्हें 3.5 Sonnet आसानी से संभाल सकता है। Opus सरल और कठिन भागों को अलग करे, और आसान हिस्से कई 3.5 Sonnet instances में बाँट दे — यह विचार इतना सीधा लगता है कि लगता है सभी लोग इसे पहले से बना रहे होंगे।
Claude code वास्तव में Sonnet और Haiku, दोनों मॉडलों का अपने-आप उपयोग करता है। session खत्म होने पर tokens, cost आदि के तरह-तरह के आँकड़े भी दिखाता है। उम्मीद है कि session के दौरान भी ऐसी जानकारी देखने का कोई तरीका होगा।
उदाहरण के लिए, prompt में हर subtask के लिए 1~10 scale पर "recommended model level" निकलवाया जाए तो कैसा रहेगा?
पिछले 1~2 सालों में मैं API का सीधा भुगतान करके, open source frontends (LibreChat आदि) से अलग-अलग मॉडलों से जुड़कर इस्तेमाल करता रहा हूँ। कभी-कभार उपयोग के लिए यह बहुत अच्छा रहा; हर कुछ महीनों में लगभग $10 recharge कर देना काफ़ी था। मैं जितने tokens इस्तेमाल करता हूँ, वह अधिकांश package plans से बहुत कम हैं, इसलिए यह तरीका मुझे कहीं सस्ता लगता था। लेकिन Claude Code जैसे अलग-अलग tools आज़माने के बाद tokens साफ़ तौर पर बहुत तेज़ी से खत्म होने लगे। कल ही मैंने 15 मिनट में $5 के tokens खर्च कर दिए। मुझे पता था कि code tools का इस्तेमाल LLM से साधारण सवाल पूछने से बहुत अलग होता है, लेकिन इतना अंतर होगा, यह नहीं सोचा था। हैरानी इस बात की भी है कि token usage का बड़ा हिस्सा आसानी से दिखता नहीं — वह बढ़ते context या tool orchestration के पीछे छिपा रहता है।
Claude Code सामान्य से कहीं व्यापक context और बहुत अधिक iterative processing का उपयोग करता है, इसलिए ऐसा होता है।
Deepseek API पर $20 में लगभग एक साल आराम से चल गया (चीन की कंपनी होना मायने नहीं रखता)। speed धीमी है, लेकिन independently hosted Deepseek models की तुलना में इसकी quality मुझे ज़्यादा अच्छी लगी (मेरे अनुभव में)। agents जैसी चीज़ें मैं इस्तेमाल नहीं करता।
"99% demand हमेशा frontier model पर जाती है" — इस दावे से असहमति है। असली frontier सिर्फ़ 'capability' नहीं, बल्कि 'capability per dollar' भी है। सबसे महँगा top-end model 99% share नहीं लेता; असल में बात उलटी है। OpenRouter के आँकड़ों के अनुसार Claude Opus 4 का share लगभग 1% है, जबकि सबसे लोकप्रिय Sonnet 4 है, जिसे 18% subscribers इस्तेमाल करते हैं। इसके अलावा और भी सस्ते Gemini Flash 2.0, 2.5 का उपयोग बहुत होता है। वे Sonnet 4 से भी सस्ते हैं।
यह समझ नहीं आता कि San Francisco में लोग capital letters और punctuation क्यों नहीं इस्तेमाल करते। और यह भी समझ नहीं आता कि Silicon Valley के लोग नकली exponential growth पर इतने आसक्त क्यों हैं। असल में यह कहना ज़्यादा सही लगता है कि AI की प्रगति सचमुच exponential नहीं है; बस कुछ साल पहले की तुलना में इसमें डाले गए resources बहुत बढ़ गए हैं।
क्या यह अजीब writing style इसलिए है कि लोग दिखा सकें कि यह LLM द्वारा लिखा हुआ नहीं है?
भाषा के स्वाभाविक बदलाव को बर्दाश्त नहीं कर पा रहे?/मज़ाक। शायद अब पुराने तरीक़े से जीना सीखना होगा।
अगर San Francisco के Tenderloin या Mission Street में जाएँ, तो क्या capital letters और punctuation न इस्तेमाल करने पर सच में गोली मार दी जाती है? (मज़ाक)
लेख "land grab" प्रक्रिया के इस 'musical chairs' खेल को नज़रअंदाज़ कर रहा है। Uber के उदाहरण की तरह, venture capital जलाकर market share पहले कब्ज़े में कर लिया जाए, और कई साल घाटा सहने के बाद भी अगर ग्राहक के मन में जगह बन जाए, तो बाद में सस्ता और नया competitor आने पर भी उसे आसानी से हिलाया नहीं जा सकता। business स्थिरता से जम जाता है, और IPO के बाद भी stock healthy बना रह सकता है (भले बहुत शानदार न हो)।
लेख इसे ऐसे दिखाता है मानो कोई भी pay-as-you-go pricing नहीं चुका रहा, जबकि वास्तव में API customers — यानी लगभग सभी enterprise customers — पहले से ही pay-as-you-go billing चुका रहे हैं।
"सोच रहा हूँ कि San Francisco में लोग बड़े अक्षर और punctuation क्यों नहीं इस्तेमाल करते"
पोस्ट के अंदर जाकर देखा तो सच में ऐसा ही है। दिलचस्प बात यह है कि कुछ वाक्यों में full stop है, और कुछ में नहीं, यानी दोनों का mix है—आखिर इसकी क्या वजह होगी? क्या किसी को पता है? जिज्ञासा हो रही है 🤔