लोकल AI की टोकन अर्थव्यवस्था

यह वही लेख है जिसे हर बड़ा क्लाउड प्रदाता चाहेगा कि मैं न लिखता। हिसाब छिपा नहीं है: वह उनके अपने प्राइसिंग पेजों पर, उनके अपने दस्तावेज़ों में, उद्योग के उन अध्ययनों में सीधी भाषा में छपा है जिन्हें कोई भी खींच सकता है। वे बस चाहेंगे कि वह अनपढ़ा रहे, क्योंकि जो भी कंपनी हिसाब लगाकर अपनी इनफ़रेंस लेयर खड़ी करती है, वह API किराये पर कम ख़र्च करने वाली कंपनी बन जाती है। हर पैमाने पर जवाब वही है, पाँच लोगों का स्टार्टअप, पचास हज़ार उपयोगकर्ताओं वाला एंटरप्राइज़, बीच में कहीं भी: जो टीम अपनी इनफ़रेंस लेयर की मालिक है, वह किराये पर लेने वाली टीम से कई गुना ज़्यादा अपनी लागत वसूलती है।

आर्किटेक्चर

प्रति-मिलियन-टोकन दर सपाट दिखती है। वह है नहीं। आउटपुट इनपुट से तीन से दस गुना महँगा है। रीज़निंग मॉडल अपने चेन-ऑफ़-थॉट टोकन उसी आउटपुट बिल के भीतर दबा देते हैं। हर रिक्वेस्ट सिस्टम प्रॉम्प्ट और उससे जुड़े किसी भी RAG संदर्भ की लागत फिर से चुकाती है। इनमें से कुछ भी प्राइसिंग पेज पर अलग से नहीं दिखाया जाता। सब कुछ इनवॉइस पर आ जाता है।

Enterprise Strategy Group ने 2025 में Dell Technologies के साथ यह तुलना की, चार साल की अवधि में RAG के साथ 70B-पैरामीटर Llama 3 डिप्लॉयमेंट को तीन आर्किटेक्चर पर मॉडल करते हुए: ऑन-प्रेमिस Dell AI Factory, क्लाउड IaaS, और शुद्ध API खपत। उच्च-उपयोग वाले छोर पर हिसाब ऐसा दिखता है:

10,000 उपयोगकर्ताओं पर, चार साल की अवधि में ऑन-प्रेमिस 52% सस्ता पड़ता है। 50,000 उपयोगकर्ताओं पर 62% सस्ता। अपनाने के साथ फ़ासला बढ़ता है, जो ज़्यादातर ख़रीद-अनुमानों के ठीक उलट है। यही हिसाब अपने वर्कलोड पर चलाना चाहें तो इस साइट पर दो साथी टूल हैं: LLM कॉस्ट कैलकुलेटर आपके ख़ास टोकन वॉल्यूम के लिए किसी भी क्लाउड मॉडल और किसी भी लोकल हार्डवेयर विकल्प के बीच ब्रेक-ईवन महीना निकालता है, और हाइपरस्केलर प्राइसिंग तुलना उसी मॉडल पर Bedrock, Azure Foundry और Vertex को साप्ताहिक सत्यापित क़ीमतों के साथ ट्रैक करती है।

एक पल के लिए पूर्ण आँकड़े भूल जाइए। वक्र देखिए। API ख़र्च ट्रैफ़िक के साथ रैखिक बढ़ता है और कभी ठहरता नहीं। अपने हार्डवेयर का ख़र्च हार्डवेयर के जीवनचक्र पर रुक जाता है। अपनाना वह चर है जो तय करता है कि आपने खंदक बनाई है या कर पर दस्तख़त किए हैं। Dell के आँकड़े एंटरप्राइज़ पैमाने के हैं, लेकिन वक्र फ्रैक्टल है: पाँच लोगों का स्टार्टअप, जो प्रोटोटाइप से प्रोडक्शन की ओर जाते हुए अपना मासिक Anthropic या OpenAI बिल ऊपर रेंगता देखता है, इसी रेखा पर है, बस छोटे गुणक पर। गणित को आपकी टीम की संख्या से मतलब नहीं; उसे इससे मतलब है कि आपका निरंतर टोकन वॉल्यूम अपने हार्डवेयर को इतना व्यस्त रखता है या नहीं कि वह वसूल हो सके।

एक दूसरा आयाम है जो डॉलर की तुलना में दिखता ही नहीं। क्लाउड इनफ़रेंस हर प्रॉम्प्ट को, यानी सिस्टम संदर्भ, पुनर्प्राप्त दस्तावेज़ और एजेंट की बीच की स्थिति को, नेटवर्क सीमा पार करके एक तीसरे पक्ष तक ले जाता है। इससे अनुपालन का दायरा, बौद्धिक संपदा के रिसाव का जोखिम, संदर्भ-विंडो रोडमैप और रेट लिमिट के इर्द-गिर्द वेंडर लॉक-इन, प्रदाता की क्षेत्रीय ख़राबी रात के 3 AM पर होने की स्थिति में संकेंद्रण का जोखिम, और एक ही मॉडल देने वाले हाइपरस्केलरों के बीच भी क़ीमतों का अंतर, सब सक्रिय हो जाते हैं। मैं इसे इनफ़रेंस संप्रभुता कहता हूँ। यही वह बातचीत है जो पाँच साल पहले टेक नेतृत्व ने डेटा संप्रभुता पर की थी, बस स्टैक में एक सीढ़ी नीचे।

इस मोड़ पर CTO से मुझे जो आपत्ति मिलती है वह जायज़ है: “लेकिन Bedrock, Vertex और OpenAI सब फ़ाइन-ट्यूनिंग देते हैं। मुझे अपना GPU क्यों चाहिए?” क्योंकि क्लाउड-प्रबंधित फ़ाइन-ट्यूनिंग अतिरिक्त चरणों वाला किराया है। ट्रेनिंग डेटा फिर भी आपकी सीमा से बाहर जाता है। एडाप्टर वेट किसी और के इन्फ्रास्ट्रक्चर पर रहते हैं। इनफ़रेंस फिर भी किसी और की प्रति-रिक्वेस्ट दर पर, किसी और के रोडमैप के हिसाब से चलता है। आपने निर्भरता में अनुकूलन जोड़ा है, निर्भरता हटाई नहीं। लोकल लैब ही एकमात्र आर्किटेक्चर है जहाँ आपका मॉडल, आपका डेटा और आपका इनफ़रेंस लूप एक साथ आपके अपने हैं।

निर्माण

ज़्यादातर टीमें यह क़दम इसलिए कभी नहीं उठातीं कि वे अपने मॉडल का मालिक होना और अपने मॉडल को शून्य से ट्रेन करना को एक समझ लेती हैं। ये दो बिल्कुल अलग समस्याएँ हैं, जिन्हें लागत में चार से छह परिमाण-क्रम अलग करते हैं।

इसे प्री-ट्रेन मत कीजिए

Stanford के 2025 AI Index ने फ्रंटियर के पीछे के ट्रेनिंग कंप्यूट की क़ीमत आँकी: GPT-4 लगभग $78 मिलियन, Llama 3.1 405B $170 मिलियन, Gemini Ultra $191 मिलियन। ये क्लाउड-किराये के अमॉर्टाइज़्ड डॉलर हैं, केवल कच्चा कंप्यूट: न डेटा इंजीनियरिंग, न MLOps, न उन लोगों की तनख़्वाहें जो हज़ारों GPU वाले क्लस्टर को बिगाड़े बिना चला सकें। वक्र के छोटे छोर पर भी शून्य से 7B मॉडल $50K–$500K और दसियों हज़ार GPU-घंटे का काम है। 70B के लिए $1.2M–$6M और हफ़्तों चलता एक समर्पित 256-GPU H200 क्लस्टर लगता है।

यह मत कीजिए। फ्रंटियर-लैब के बजट के बाहर किसी को इसकी ज़रूरत नहीं है।

इसे PEFT कीजिए

असल चाल है किसी मौजूदा ओपन-वेट बेस के ऊपर पैरामीटर-एफ़िशिएंट फ़ाइन-ट्यूनिंग (Parameter-Efficient Fine-Tuning)। Llama 3, Mistral, Qwen, Phi: पहले से अंग्रेज़ी में धाराप्रवाह, वाक्य-रचना में सही, दुनिया की समझ वाले। ऊपर से आप अपना डोमेन जोड़ते हैं: आपकी वर्गीकरण-रचना, आपका फ़ॉर्मैट, आपका निर्णय-तर्क, आपका लहजा। पैरामीटर स्पेस में यह एक छोटा-सा समायोजन है, और आधुनिक तकनीकें इसी का सीधा फ़ायदा उठाती हैं।

उस VRAM कॉलम के आँकड़े 7B मॉडल के लिए आधार-मान हैं। यह जानने के लिए कि कोई ख़ास मॉडल किसी ख़ास क्वांटाइज़ेशन पर किसी ख़ास GPU में सचमुच समाता है या नहीं, GPU VRAM कैलकुलेटर इसे तोड़कर दिखाता है: मॉडल वेट, साथ में KV कैश और एक्टिवेशन, कंज़्यूमर GPU, डेटासेंटर कार्ड, Apple Silicon और Pi एक्सेलरेटर की चुनी हुई तालिका के सामने। किसी भी हार्डवेयर फ़ैसले से पहले इसे चलाना सार्थक है।

LoRA बेस वेट को पूरी तरह फ़्रीज़ कर देता है और ख़ास अटेंशन लेयरों में छोटे प्रशिक्षित होने योग्य रैंक-डिकम्पोज़िशन मैट्रिक्स डालता है: आप पैरामीटर संख्या के लगभग 1% के क्रम की चीज़ अपडेट कर रहे होते हैं। QLoRA फ़्रीज़ बेस को 4-बिट में क्वांटाइज़ करके और आगे जाता है, जिससे मेमोरी का पदचिह्न इतना घट जाता है कि 7B का फ़ाइन-ट्यून एक कंज़्यूमर GPU पर आ जाता है। QLoRA पर गंभीर अनुकूलन रन कुछ सौ डॉलर में पड़ता है और रात भर में निपट जाता है। स्क्रिप्ट का आकार, यानी Gekro लैब के अगली तिमाही के काम में एक चुने हुए डेटासेट के विरुद्ध जो योजना है, लगभग ऐसा दिखता है:

# gekro_qlora_train.py - Llama 3 8B + QLoRA via Unsloth + TRL
# Target: single consumer GPU (Mac Mini Metal or RTX 4090 class)
from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/llama-3-8b-bnb-4bit",
    max_seq_length=4096,
    load_in_4bit=True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,                                # LoRA rank
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha=16,
    lora_dropout=0.0,
    use_gradient_checkpointing="unsloth",
)

trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    # Expected JSONL shape per record:
    # {"messages": [{"role": "user", "content": "..."},
    #               {"role": "assistant", "content": "..."}]}
    train_dataset=load_curated_dataset(),    # your domain corpus
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        num_train_epochs=3,
        learning_rate=2e-4,
        optim="adamw_8bit",
        output_dir="./checkpoints",
    ),
)
trainer.train()

एक फ़ाइल। एक GPU। एक रात भर का रन। आउटपुट एक छोटी एडाप्टर वेट फ़ाइल है जिसे आप इनफ़रेंस के समय फ़्रीज़ बेस के ऊपर लोड करते हैं, और Ollama या vLLM से वैसे ही परोसते हैं जैसे बेस मॉडल परोसते।

हार्डवेयर के स्तर: लैब टीम के आकार के साथ बढ़ती हैं, कंपनी के राजस्व के साथ नहीं

भारी AI वर्कफ़्लो चलाने वाला अकेला इंजीनियर स्तर 1 का है। निरंतर एजेंटिक वर्कलोड चलाने वाली टीम स्तर 2 की है। हज़ारों उपयोगकर्ताओं को सेवा देने वाला संगठन स्तर 3 का है। वही आर्किटेक्चर, तीन गुणक। हर स्तर पर लागत-वसूली का हिसाब उस ख़रीद-चक्र से तेज़ है जिसने इसे मंज़ूर किया: स्तर 1 पर महीनों में, स्तर 2 पर हफ़्तों में जब फ़ाइन-ट्यून किए एडाप्टर असली ट्रैफ़िक सँभालने लगें, और स्तर 3 पर निरंतर पैमाने पर समकक्ष API ख़र्च के मुक़ाबले कई गुना।

2026 में सर्विंग स्टैक एक जगह आकर टिक गया है, और यह कहानी का कम चर्चित हिस्सा है। vLLM थ्रूपुट में जीत गया है: उसका PagedAttention एल्गोरिदम KV कैश को वैसे ही बाँटता है जैसे ऑपरेटिंग सिस्टम वर्चुअल मेमोरी को पेज करते हैं, और एक ही हार्डवेयर पर vLLM से परोसे जाने और भोलेपन से परोसे जाने के बीच का फ़ासला एक निष्क्रिय GPU और एक भरे हुए GPU का फ़ासला है। Ollama डेस्कटॉप और एज के लिए डेवलपर की सुविधा में जीता है। TensorRT-LLM वहाँ रहता है जहाँ आप NVIDIA के लिए प्रतिबद्ध हैं और हर आख़िरी साइकिल चाहते हैं। एक्सपेरिमेंट ट्रैकिंग MLflow या Weights & Biases सँभालते हैं, क्योंकि LLM फ़ाइन-ट्यूनिंग अनिर्धारणात्मक है और पुनरुत्पादनीयता ही शोध डेमो और प्रोडक्शन सिस्टम का फ़र्क़ है।

बड़े पैमाने पर प्रोडक्शन इनफ़रेंस चलाने के लिए अब आपको Anthropic या OpenAI की इन्फ्रास्ट्रक्चर टीम नहीं चाहिए। जो स्टैक उन कंपनियों ने सालों में बनाया, वह अब एक pip install और एक कॉन्फ़िग फ़ाइल है। यह 2026 में नया है, और यही पूरा कारण है कि इस पोस्ट का हिसाब हर स्तर पर चलता है। मैंने पहले ही आर्किटेक्चरल बीमा के रूप में Pi पर Ollama का पैटर्न और GekroLLMClient, जो क्लाउड और लोकल प्रदाताओं को एक इंटरफ़ेस के पीछे समेट देता है, दस्तावेज़ किए हैं; दोनों होम लैब से सीधे एंटरप्राइज़ स्तर तक बढ़ते हैं।

समझौते

इनफ़रेंस लेयर का मालिक होना मुफ़्त नहीं है, और ऐसा दिखाना ही लैब को पेपरवेट बना देता है। चार विफलता-रूपों के नाम लेना ज़रूरी है।

कम उपयोग वक्र को मार देता है। ब्रेक-ईवन का तर्क निरंतर थ्रूपुट पर निर्भर है। स्तर-3 का सर्वर खड़ा करके उसे 8% उपयोग पर चलाएँगे तो आपने बहुत महँगा पेपरवेट बनाया है। क्लाउड API झटकेदार, कम-वॉल्यूम काम के लिए सचमुच सस्ती हैं: यही उनकी सबसे उपयुक्त शक्ल है, और उसके लिए उन्हें इस्तेमाल करते रहना चाहिए। किसी भी हार्डवेयर फ़ैसले से पहले पूछिए: जिन वर्कलोड को मैं भीतर ला रहा हूँ उनका स्थिर दैनिक टोकन वॉल्यूम क्या है, और क्या वह हार्डवेयर को व्यस्त रखने के लिए पर्याप्त बड़ा है? अगर ईमानदार जवाब नहीं है, तो उस वर्कलोड के लिए API पर बने रहिए। लोकल हार्डवेयर अपनी रोटी तभी कमाता है जब वह भरा हुआ हो।

गुणवत्ता की खाई असली है। किसी संकीर्ण, साफ़-परिभाषित काम पर फ़ाइन-ट्यून किया गया 8B उस काम पर फ्रंटियर API की बराबरी या उससे बेहतर कर सकता है: फ़ाइन-ट्यूनिंग का पूरा मतलब यही है। लेकिन जैसे ही वर्कलोड खुले-ढंग की रीज़निंग या बहु-डोमेन ज्ञान की ओर बहता है, छोटा मॉडल खाई में गिर जाता है। मैंने इसे सीधे महसूस किया है। मेरा Mac Mini मज़े से क्वांटाइज़्ड 70B चलाता है और जवाब सारांश, वर्गीकरण और कोड रिव्यू के लिए पूरी तरह इस्तेमाल लायक़ हैं। वे उसी प्रॉम्प्ट पर Claude या Gemini Pro के जवाबों से साफ़ तौर पर कम बारीक भी हैं: छोटे, ज़्यादा शाब्दिक, और किसी सवाल के दूसरे दर्जे के निहितार्थ को चूक जाने की ओर ज़्यादा प्रवृत्त। रूटिंग का फ़ैसला ही आर्किटेक्चर है, और वह क्लाइंट रैपर में रहता है:

# Hybrid routing - local for narrow tasks, cloud for long-tail reasoning
NARROW = {"classify", "extract", "summarize", "format", "tag"}
REASONING = {"design", "plan", "synthesize", "debug-novel"}

def route(task_class: str, prompt: str) -> str:
    if task_class in NARROW:
        return local_finetuned_8b.run(prompt)
    if task_class in REASONING:
        return cloud_frontier.run(prompt)
    return cloud_frontier.run(prompt)        # default: don't guess

संकीर्ण, ऊँचे वॉल्यूम और लेटेंसी-संवेदनशील काम के लिए लोकल। लंबी पूँछ वाली रीज़निंग के लिए, जिसे लोकल मॉडल नहीं सँभाल सकता, क्लाउड फ्रंटियर। यह API संप्रभुता पैटर्न का दिल है: लैब क्लाउड की जगह नहीं लेती, वह पहले अनुमान-योग्य वर्कलोड खा जाती है। लोकल स्तर जो भी टोकन सँभालता है, वह एक ऐसा टोकन है जिसका बिल क्लाउड इनवॉइस आपसे नहीं लेता। जो भी टोकन आप क्लाउड पर रखते हैं, वह एक ऐसा टोकन है जिससे आप व्यवहार में प्रदाता के अगले दौर के ट्रेनिंग कंप्यूट को सब्सिडी दे रहे हैं।

असली खंदक डेटासेट है, GPU नहीं। कंप्यूट सस्ता है। जिस QLoRA रन में GPU समय का $300 लगता है, वह एक ऐसे एनोटेशन प्रयास के ऊपर बैठ सकता है जिसमें टीम के विशेषज्ञ-घंटों के $60,000 लगे, और गंभीर DPO या RLHF रन में मानव-लेबलिंग से कंप्यूट का अनुपात आम तौर पर इंसानों के पक्ष में बीस से तीस गुना होता है। यह फ़ाइन-ट्यूनिंग के ख़िलाफ़ तर्क नहीं है। यह इस बात का तर्क है कि अगर आपका संगठन अपनी वर्गीकरण-रचना लिखकर नहीं बता सकता, इस पर सहमत नहीं हो सकता कि आपके डोमेन के लिए सही आउटपुट कैसा दिखता है, और एनोटेशन समीक्षा के लिए डोमेन विशेषज्ञ नहीं दे सकता, तो आपके पास अभी फ़ाइन-ट्यूनिंग की समस्या नहीं है, ज्ञान-प्रबंधन की समस्या है। पहले उसे सुलझाइए। कंप्यूट आसान आधा है। जब आप ट्रेनिंग उदाहरणों का फ़ॉर्मैट बनाने लगेंगे, तो फ़्रेमवर्कों के बीच फ़ॉर्मैट की रगड़ की उम्मीद रखिए: OpenAI की चैट स्कीमा, Alpaca, ShareGPT और Unsloth/Llama सब वही डेटा थोड़ा अलग आकार में चाहते हैं। मैंने फ़ाइन-ट्यूनिंग डेटासेट फ़ॉर्मैटर इसलिए बनाया कि वह रूपांतरण सँभाले और उन छूटे-टर्न की त्रुटियाँ चिह्नित करे जो चुपचाप ट्रेनिंग बिगाड़ देती हैं।

हार्डवेयर का नवीनीकरण निर्मम है। यही ख़ूबी है, खोट नहीं। लेखा विभाग सर्वरों का मूल्यह्रास पाँच या छह साल में करता है। AI सिलिकॉन सहयोग नहीं करता। GPU की नई पीढ़ियाँ लगभग हर साल ठोस दक्षता लाभ के साथ आती हैं, यानी 2024 की शुरुआत में ख़रीदा गया H100 2026 के अंत तक दो आर्किटेक्चर पीढ़ियाँ पीछे है। सबसे माँगने वाले स्तर पर 24–36 महीने के नवीनीकरण की योजना बनाइए, और ऐसा मूल्य-कैस्केड पैटर्न रखिए जो पुराने सिलिकॉन को हल्के वर्कलोड तक नीचे खिसका दे: साल 1–2 में फ्रंटियर ट्रेनिंग, साल 3–4 में रियल-टाइम इनफ़रेंस, उसके बाद बैच एनालिटिक्स। आक्रामक ढंग से नवीनीकरण की लचक अपने आप में एक रणनीतिक संपत्ति है। क्लाउड की तीन साल की रिज़र्व्ड-इंस्टेंस प्रतिबद्धता आपको वह नहीं देती, और न ही वह दीर्घकालिक API अनुबंध जिस पर आपकी वित्त टीम दस्तख़त करने वाली है।

यह कहाँ जाता है

यह पोस्ट कुछ हद तक संश्लेषण है और कुछ हद तक मेरा अपना रोडमैप। आज मैं एक Mac Mini और Pi क्लस्टर पर लोकल इनफ़रेंस चलाता हूँ, और GekroLLMClient वर्कलोड की श्रेणी के आधार पर क्लाउड और लोकल के बीच रूट करता है। जो मैंने अभी नहीं किया, और जिसके इर्द-गिर्द लैब के काम की अगली तिमाही बनी है, वह है अपने हार्डवेयर पर एक चुने हुए डेटासेट के विरुद्ध शुरू से अंत तक QLoRA चलाना, उस eval लूप और MLOps अनुशासन के साथ जो एक बार के फ़ाइन-ट्यून को पुनरुत्पादनीय पाइपलाइन बनाता है। जहाँ मैं रहता हूँ उसके हिसाब से एक दूसरी अनुकूलन सतह भी है: Texas ग्रिड की इस बारे में अपनी राय है कि ट्रेनिंग जॉब कब चलें, और वह तभी खुलती है जब हार्डवेयर पहले अपना हो।

इनमें से कुछ भी छिपा नहीं है। आपका मासिक इनवॉइस लिखने वाले क्लाउड प्रदाता यह पहले से जानते हैं। उनका दाँव है कि आपकी इंजीनियरिंग टीम फ़ीचर भेजने में इतनी व्यस्त है कि हिसाब नहीं लगाएगी। फिर भी हिसाब लगाइए।