Mac Studio पर local LLM चलाकर देखा, तो धीमे होकर भी दमदार तरीके से इस्तेमाल करने का रास्ता दिखा

शुरुआत#

लोकल में LLM चलाने की बात आमतौर पर इंस्टॉलेशन से शुरू होती है। कौन-सा runtime इस्तेमाल करना है, कौन-सा model डाउनलोड करना है, और कौन-सा port खोलना है, समझाया जाता है।

लेकिन कुछ समय तक इस्तेमाल करने के बाद असली सवाल कुछ और बन जाता है। लोकल में बड़े LLM को उपयोगी तरीके से कैसे चलाया जाए। क्योंकि सिर्फ चल जाना और लगातार काम में आना, ये दोनों बिल्कुल अलग बातें हैं।

मैंने भी शुरुआत Ubuntu + vLLM + 3090 Ti के दो कार्ड से की थी। और अब मैं Mac Studio M3 Ultra(512GB) और LM Studio पर आ चुका हूं, जहां deepseek, qwen, glm परिवार के बड़े models को लोकल में चला रहा हूं।

यह लेख इंस्टॉलेशन गाइड नहीं है। 3090 के दो कार्ड पर मुझे सीमा क्यों महसूस हुई, मैं Mac Studio पर क्यों आया, और धीमे local LLM को मैं असली काम में कैसे इस्तेमाल कर रहा हूं, बस उसी पर हल्का-सा नोट है।

शुरुआत 3090 Ti के दो कार्ड से हुई#

शुरुआती सेटअप काफी सीधा था। सेकंड-हैंड 3090 Ti GPU के दो कार्ड करीब 22 लाख वॉन में लेकर Ubuntu पर लगाया, और runtime के लिए vLLM चुना।

उस समय gemma 3 उन models में था जो लोकल में काफी अच्छे लगे। बहुत साधारण निर्देश संभालने वाले assistant या छोटे workflow बनाने तक के लिए वह काफी प्रभावशाली था। multilingual performance भी बुरी नहीं थी, और token generation speed भी उस समय के हिसाब से संतोषजनक थी।

वास्तव में मैंने इसी environment में कई assistants बनाए और test किए।

• chat agent
• tarot card reader
• translator-style assistant
• सरल workflow worker

इस चरण में मेरा निष्कर्ष साफ था। local LLM अब खिलौना स्तर पर नहीं रह गए थे। लेकिन इसका मतलब यह भी नहीं था कि उनसे तुरंत वास्तव में उपयोगी एजेंट बनाए जा सकते थे। कमी अभी भी काफी थी।

समस्या software से ज्यादा hardware की वास्तविकता थी#

शुरुआत में vLLM चुनने की वजह भी सीधी थी। सेटअप अपेक्षाकृत आसान था, और sglang की तुलना में यह कहीं ज्यादा जाना-पहचाना था।

लेकिन समय के साथ समझ आया कि घर में 3090 multi-GPU चलाते समय असली bottleneck runtime का चुनाव नहीं, बल्कि उससे कहीं ज्यादा व्यावहारिक चीजें हैं।

• बिजली का खर्च बोझिल था।
• गर्मी बहुत ज्यादा थी।
• घर में लगातार चलाना मुश्किल था।
• सबसे अहम, जिन बड़े models को मैं सच में चलाना चाहता था, वे अब भी पहुंच से बाहर थे।

उस समय मेरी इच्छा deepseek v3 स्तर के model को लोकल में पर्याप्त context के साथ संभालने की थी। लेकिन 3090 के दो कार्ड के साथ यहां सीमा साफ थी। छोटे model अच्छी तरह चलाना और बड़े model को लगातार काम की asset की तरह इस्तेमाल करना, ये बिल्कुल अलग बातें हैं।

आखिरकार मैंने GPU सेटअप हटाया और Mac Studio M3 Ultra(512GB) खरीदा। यह बदलाव सिर्फ machine बदलना नहीं था, बल्कि local LLM को देखने का मेरा नजरिया ही बदल गया।

Mac Studio पर आने के बाद जो संभव हुआ#

macOS + LM Studio पर आने के बाद सबसे बड़ा फर्क यह था कि जो models पहले व्यावहारिक विकल्प ही नहीं लगते थे, वे अब सचमुच विकल्प बन गए।

जब मैं deepseek, glm, Qwen3-235B-A22B जैसे बड़े models को सीधे लोड करके उनका परिणाम देखने लगा, तो उनकी performance ने मुझे काफी चौंकाया। reasoning quality उम्मीद से बेहतर थी। थोड़ा जटिल निर्देश देने पर भी पहले की तुलना में कहीं ज्यादा सटीक और स्थिर नतीजे मिलते थे।

लेकिन साथ ही सीमाएं भी बहुत साफ दिखीं। pp performance मेरी अपेक्षा से धीमी थी, और real-time chat जैसी तुरंत प्रतिक्रिया चाहने वाली usage style के लिए यह स्पष्ट रूप से उपयुक्त नहीं थी। रिसर्च करते समय मैंने इसके धीमे होने की बात पढ़ी थी, लेकिन रोज इस्तेमाल करने पर वह सीमा कहीं ज्यादा साफ महसूस होती है।

यहीं आकर मैंने अपना मानदंड बदल दिया। क्या यह मॉडल तेज है? से ज्यादा मैं इसे किस काम में इस्तेमाल करना चाहिए? पूछने लगा।

धीमे होने पर भी जिन कामों में संतुष्टि सबसे ज्यादा मिली#

दिलचस्प बात यह है कि real-time response की उम्मीद छोड़ते ही local LLM कहीं ज्यादा उपयोगी लगे।

जिन क्षेत्रों में मुझे संतुष्टि मिली, उनमें एक समान पैटर्न था।

• data analysis जैसे काम, जिनमें सटीक और परिष्कृत output चाहिए
• game story writing जैसे काम, जिनमें समय लगना स्वीकार्य है
• complex analysis workflow जैसे काम, जिनमें कई चरण होते हैं
• OpenHands जैसे automated development work, जिन्हें इंसान की जगह रात भर चलने दिया जा सकता है

उदाहरण के लिए, एक कहानी बनाने में 40 से 60 मिनट या उससे भी ज्यादा लग सकते हैं। real-time chat के मानक से देखें तो यह बेहद धीमा है। लेकिन अगर इसी काम को सोने से पहले 3 से 5 काम queue में डाल दें और सुबह result लिया जाए, तो पूरी तस्वीर बदल जाती है।

धीमापन है, लेकिन बदले में output कहीं बड़ा और ज्यादा परिष्कृत होता है। इंसान को रात भर इंतजार नहीं करना पड़ता, अगली सुबह result review करना होता है और फिर अगली queue डालनी होती है।

OpenHands वाला काम भी ऐसा ही था। उसे तुरंत जवाब देने वाले copilot की तरह इस्तेमाल करने से बेहतर, tasks को queue में जमा करके अपने आप चलने देना ज्यादा सही बैठा। इस नजरिए से देखें तो local LLM धीमा चैटबॉट नहीं, बल्कि चुपचाप लंबे समय तक काम करने वाला worker ज्यादा है।

खरगोश जितना तेज नहीं हो, फिर भी कछुए की तरह जीत सकता है#

local LLM को देखते हुए मुझे अक्सर खरगोश और कछुए की कहानी याद आती थी।

cloud LLM आमतौर पर खरगोश की तरह होते हैं। तेज, तुरंत जवाब देने वाले, और तुरंत इस्तेमाल करने के लिए सुविधाजनक। दूसरी तरफ बड़े local models कछुए जैसे हैं। धीमे, immediacy के मानक पर थोड़े खीझ पैदा करने वाले, और गलत तुलना कर दें तो जल्दी निराश करने वाले।

लेकिन जैसे ही मूल्यांकन का पैमाना बदलता है, नतीजा भी बदल जाता है।

real-time chat में मुकाबला करें तो local LLM अक्सर हारते हैं। लेकिन अगर काम को queue, repetitive work, batch execution, overnight processing जैसी निरंतरता जीतने वाली संरचना में बदल दें, तो कहानी अलग हो जाती है। मुझे असल संतुष्टि इसी तरीके में मिली। ऊपर से power consumption भी multi-GPU setup की तुलना में कहीं ज्यादा स्थिर था। अनुभव के स्तर पर देखें तो GPU setup के मुकाबले 7 गुना से कम बिजली में बड़े models चलाना भी एक बड़ा फायदा था।

आखिरकार निर्णायक बात model की speed नहीं, बल्कि अपने काम की लय को आप कैसे design करते हैं थी।

मेरा code भी आखिरकार queue-केंद्रित हो गया#

यह सिर्फ एक impression नहीं था, यह मेरी implementation में भी सीधे उतर गया।

मेरे ai-service module को देखें तो local LLM को real-time chat से ज्यादा background worker मानने के निशान काफी साफ हैं।

सबसे पहले, model connection अपने आप में जितना लगता है उससे आसान है। RunnableAiModel में vllm और lm studio को OpenAI-compatible provider की तरह treat किया गया है, ताकि सिर्फ baseUrl बदलकर जोड़ा जा सके। यानी ऊपर की application layer के नजरिए से, अगर endpoint OpenAI-compatible format में है, तो local backend को अपेक्षाकृत सहज तरीके से बदला जा सकता है।

LM Studio के लिए अलग usage example भी है। LMStudioVisionClient वास्तव में LM Studio के /v1 endpoint के आधार पर vision model जोड़ने के लिए implement किया गया है। यानी local VLM जोड़कर image analysis तक ले जाना संभव बनाया गया है।

इससे भी अहम बात execution model है।

AiAgentExecutor workflow को तुरंत चलाने के बजाय उसे DTE job के रूप में queue में register करता है.LoopJobService और LoopWorkflowExecutor लंबे, दोहराए जाने वाले कामों को background में संभालने के लिए डिज़ाइन किए गए हैं, और इनके पास checkpoint और recovery flow भी है.WritingToolExecutor, multi-agent workflow, और marketing generation pipeline भी कुल मिलाकर instant-response style की बजाय asynchronous execution style के ज्यादा करीब हैं.

यह संयोग नहीं है.धीमे model को ज़बरदस्ती real-time interface में ठूंसने के बजाय, ऐसे कामों को queue में भेजना कहीं ज्यादा व्यावहारिक है जिनमें धीमापन स्वीकार्य हो.

संक्षेप में कहूं तो, मैंने local LLM को इस तरह समझना शुरू किया.

• chat responder से ज्यादा यह work queue के लिए बेहतर है.
• speed से ज्यादा difficulty और refinement महत्वपूर्ण हो, ऐसे कामों के लिए यह बेहतर है.
• रात भर चलाकर सुबह review करने वाले pattern के साथ इसकी अच्छी बनती है.
• OpenAI-compatible API मिल जाए तो existing service structure में इसे जोड़ना भी बहुत कठिन नहीं है.

तो local LLM आखिर किनके लिए सही है#

अगर आप यहां तक पढ़ चुके हैं, तो शायद आपके मन में भी यही सवाल है। क्या local LLM सचमुच काम के हैं, और क्या उन पर बड़ा खर्च करना वाजिब है?

मेरे लिए इसका मानदंड काफी साफ है.

local LLM नीचे जैसे लोगों के लिए अच्छे से फिट बैठते हैं.

• जिनके यहां real-time chat से ज्यादा batch work होता है
• जो complex generation और analysis को रात भर चलने देना चाहते हैं
• जो बड़े models को कम operating cost पर लगातार इस्तेमाल करना चाहते हैं
• जो अपने workflow को queue-केंद्रित तरीके से फिर से design कर सकते हैं

इसके उलट, अगर आपके लिए सबसे महत्वपूर्ण चीज तुरंत मिलने वाला conversational experience है, तो शुरुआत में यह स्पष्ट रूप से frustrate कर सकता है। उस स्थिति में local LLM गलत अपेक्षा पर आधारित निवेश साबित हो सकता है.

समापन#

लोकल में बड़े LLM चलाने का सफर सोचने से भी जल्दी इंस्टॉलेशन सफलता से उपयोग विफलता तक पहुंच जाता है। सिर्फ model लोड हो जाना, उपयोगी हो जाने के बराबर नहीं है.

मैंने दो 3090 Ti + Ubuntu + vLLM से शुरुआत की थी, और अब Mac Studio M3 Ultra(512GB) और LM Studio पर हूं.इस पूरी यात्रा के बाद मेरा निष्कर्ष बहुत सरल है.

enterprise नजरिए से हटकर देखें तो, छोटी teams और individual users के लिए local LLM तेज chat को replace करने वाले tool से ज्यादा, धीमे लेकिन ताकतवर worker बनाने वाली व्यवस्था के रूप में कहीं ज्यादा चमकते हैं.

अगर आपके पास पहले से Mac है, और खासकर Mac Studio जैसी मशीन है, तो मैं local LLM को इस तरह इस्तेमाल करके देखने की सलाह दूंगा। शुरुआत बहुत बड़ी होने की जरूरत नहीं है। real-time chat से नहीं, बल्कि आज रात queue में डाल देने लायक एक मुश्किल काम चुनकर शुरुआत कीजिए.

सोच से कहीं ज्यादा संभावनाएं अक्सर वहीं से खुलती हैं.