लोकल 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 वाजता प्रादेशिक बिघाड झाल्यास एकवटलेला धोका, आणि एकच मॉडेल देणाऱ्या हायपरस्केलरांमधलाही किंमतफरक, हे सगळं सक्रिय होतं. मी याला इन्फरन्स सार्वभौमत्व म्हणतो. पाच वर्षांपूर्वी तंत्रज्ञान नेतृत्वाने डेटा सार्वभौमत्वाबद्दल जी चर्चा केली तीच ही, स्टॅकमध्ये एक पायरी खाली.

या टप्प्यावर 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 नाही. कॉम्प्युट स्वस्त आहे. GPU वेळेत $300 लागणारा QLoRA रन अशा ॲनोटेशन प्रयत्नावर बसू शकतो ज्यात संघाला तज्ज्ञ-तासांचे $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 ग्रिडची ट्रेनिंग जॉब कधी चालावेत याबद्दल स्वतःची मतं आहेत, आणि ते तेव्हाच उघडतं जेव्हा हार्डवेअर आधी तुमचं स्वतःचं असतं.

यातलं काहीही लपलेलं नाही. तुमचं मासिक इनव्हॉइस लिहिणाऱ्या क्लाउड प्रदात्यांना हे आधीच माहीत आहे. त्यांची पैज आहे की तुमची इंजिनिअरिंग टीम फीचर्स पाठवण्यात इतकी गुंतलेली आहे की ती हिशोब करणार नाही. तरीही तो करा.