Jamesob की नवीनतम स्तर के LLM को लोकली चलाने की गाइड

 (github.com/jamesob)
2 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लोकल में नवीनतम स्तर के LLM और speech-to-text conversion चलाने के लिए hardware configuration, PCIe switch settings और Docker run configuration को एक repository में संकलित किया गया है
  • लगभग $2k बजट का लक्ष्य 2× RTX 3090 से 48GB VRAM हासिल कर Qwen3.6-27B और whisper-large-v3 आधारित लोकल STT चलाने वाला setup है
  • लगभग $40k बजट 4× RTX PRO 6000 Blackwell Workstation से 384GB VRAM हासिल कर Claude Opus के काफी करीब model intelligence पाने वाले setup पर आधारित है
  • असल 4× RTX 6000 Pro system में used EPYC/DDR4 आधारित main system और c-payne PCIe Gen4 switch को जोड़कर GPU के बीच P2P communication को CPU root complex के बजाय switch fabric के अंदर handle किया गया है
  • BIOS, GRUB, ACS और power limit settings तक tune करने के बाद P2P ने 27.5GB/s one-way, 50.4GB/s bidirectional और 0.37–0.45µs latency के साथ Gen4 line rate हासिल किया

लोकल LLM चलाने के लिए बजट रेंज

  • यह configuration उन users के लिए है जो लोकल में आधुनिक स्तर के models और speech-to-text conversion चलाना चाहते हैं
  • repository में इस्तेमाल हो रहा hardware, खरीदने की वजहें, setup tips, लोकल STT चलाने का तरीका और Docker container आधारित model run configuration शामिल हैं
  • README की table को छोड़कर बाकी content AI द्वारा नहीं लिखा गया है, ऐसी टिप्पणी है

  • लगभग $2k configuration

    • 2× RTX 3090 से कुल 48GB VRAM हासिल करने वाली configuration सुझाई गई है
    • इस configuration पर Qwen3.6-27B चलाया जा सकता है
    • लोकल STT के लिए whisper-large-v3 इस्तेमाल होता है, और access के लिए cross-platform stt harness इस्तेमाल किया जाता है
    • ./runners/stt में Nvidia GPU पर केवल लगभग 11GB VRAM होने की धारणा के साथ ready-to-run STT setup है
    • लोकल STT को hosted services की तुलना में अधिक सुविधाजनक tool के रूप में देखा गया है

  • लगभग $40k configuration

    • 4× RTX 6000 Pro से कुल 384GB VRAM हासिल करने वाली configuration को आधार माना गया है
    • इस price range पर इसे Claude Opus के काफी करीब model intelligence पाने वाला चरण बताया गया है
    • 2026-07 के आधार पर 4× RTX6kPRO के लिए मौजूदा best model के रूप में GLM-5.2-Int8Mix-NVFP4-REAP-594B दिया गया है
    • run configuration runners/GLM-5.2-594B में है
    • एक दूसरे approach के रूप में 4× DGX Spark cluster जोड़कर 512GB VRAM हासिल करने और slow बड़े brain के रूप में Qwen3.7-27B को repetitive काम तेज़ी से handle कराने का तरीका भी उल्लेखित है

वास्तविक 4× RTX 6000 Pro hardware

  • वास्तविक system 4× RTX PRO 6000 Blackwell Workstation को केंद्र में रखकर बनाया गया है
  • हर GPU 96GB का है, कुल 384GB VRAM, और कीमत लगभग $46,000 है
  • main system पिछली पीढ़ी के EPYC और eBay DDR4 parts का उपयोग कर base system cost कम करता है और खर्च को VRAM पर केंद्रित करता है
  • जुलाई 2026 के आधार पर PCIe5/DDR5 आधारित systems बहुत महंगे होने के कारण PCIe Gen4 switch और DDR4 आधारित main system चुना गया

  • base system BOM

    • base system अधिकतर eBay से खरीदे गए पिछली पीढ़ी के EPYC parts से बना है
    • मुख्य parts और कीमतें इस प्रकार हैं
    • ASRock Rack ROMED8-2T motherboard: $715
    • AMD EPYC Milan 7313P 16-core 3.0GHz CPU: $504
    • 8× 16GB Crucial DDR4 ECC RDIMM, कुल 128GB RAM: $642
    • 2× Super Flower 1700W PSU: $750
    • c-payne Microchip Switchtec PM40100 Gen4 PCIe switch: लगभग $1,330
    • 4TB boot NVMe: $291
    • 2× 8TB model weights के लिए NVMe: $1,200
    • base system का कुल खर्च $5,587 है

  • PCIe Gen4 switch

    • c-payne का PCIe4 switch इस्तेमाल कर GPU-to-GPU communication को लगभग direct handle किया गया है
    • tensor parallelization के allreduce चरण में GPUs के बीच data PCI root complex से गुजरे बिना switch fabric के अंदर move होता है
    • switch sub-BOM लगभग €1,220, यानी लगभग $1,330 USD है
    • Microchip Switchtec PM40100 आधारित PCIe Gen4 5× x16 switch
    • SlimSAS PCIe Gen4 Host Adapter x16
    • SlimSAS SFF-8654 8i cables 2
    • GPU और PCI switch के लिए wooden enclosure खुद बनाया गया, जिसमें लगभग एक दिन लगा
    • PCI switch का built-in fan बहुत शोर वाला और बेकार-सा लगा, इसलिए board से अलग कर दिया गया

model weights storage और run method

  • सभी model weights दो 8TB drives पर replicated ZFS filesystem में लोकली store किए जाते हैं
  • filesystem ~/storage पर mount होता है
  • चलाए जाने वाले model को पहले निम्न command से लोकल में download किया जाता है
hf download <model-name> --local-dir ~/storage/<model-name>
  • हर model के लिए अलग directory में docker-compose.yml रखा जाता है और वह अपने Docker container के अंदर चलता है
  • run configurations ./runners/ में हैं
  • हर container cached weights पढ़ने के लिए ~/storage/models को read-only mount करता है
  • model जब http://clank.j.co:5000 पर serve होता है, तो दूसरी machine के VM में hosted opencode से access किया जाता है
  • internal DNS server से clank.j.co को LLM machine पर map किया जाता है, लेकिन http://<llm-machine-ip>:5000 format भी संभव है

agent harness और tool configuration

  • अलग VM में ~/src tree की हर directory के लिए tmux session बनाकर, हर session में opencode instance चलाने वाली application इस्तेमाल होती है
  • हर opencode instance inference machine के HTTP API http://clank.j.co:5000 को backend के रूप में इस्तेमाल करता है
  • open source models का अच्छे से उपयोग करने की key tool configuration मानी गई है
  • skills/ summary में ये tools शामिल हैं
    • camofox, kagi.com API key और searXNG के जरिए web browsing और search
    • Telegram bot के जरिए communication और notifications
    • source code collaboration के लिए local private Gitea instance
  • agent को session में interactive तरीके से साथ काम करने के लिए लगाया जा सकता है, या Gitea issues handle कर PR उठाने के तरीके से काम सौंपा जा सकता है
  • यह काम sandbox VM के अंदर चलता है, और host से communication केवल shared filesystem mount के जरिए होता है

PCIe switch और multi-GPU setup

  • BIOS settings

    • ROMED8-2T motherboard पर PCI switch की speed कम न हो, इसके लिए BIOS settings adjust की गईं
    • AMD PCIE Link Width को switch slot के लिए x16 पर set किया गया
    • पहले की x8/x8 bifurcation setting slot को split कर upstream link को Gen4 x8 पर train कराती थी
    • SlimSAS 8i cables दोनों connected होने चाहिए, और हर cable x8 handle करती है
    • PCIe Link Speed को Gen4 पर force किया गया
    • Blackwell Gen5 device जब Gen4 switch के जरिए auto-negotiate करता है, तो training fail होकर Gen1 पर गिर सकती है
    • ASPM को Disabled set किया गया
    • ASPM L1 idle links को 2.5GT/s तक घटाता है
    • lspci में Gen1 पर downgrade हुआ जैसा दिखने की वजह यही थी, लेकिन load के दौरान यह Gen4 पर चलता है
    • Re-Size BAR को Enabled set किया गया
    • पूरे 96GB VRAM BAR exposure और GPU P2P के लिए जरूरी है
    • SR-IOV को Disabled set किया गया
    • bare-metal inference environment में IOMMU overhead और P2P interference से बचने की setting है
    • Preferred IO को Auto पर छोड़ा गया
    • manually c-payne switch bus 81 specify करने पर थोड़ी latency improvement की गुंजाइश है, लेकिन यह fix नहीं optimization है और BIOS change के बाद bus number बदल सकता है

  • Redriver और cable

    • c-payne की सलाह के अनुसार c-payne tool से redriver gain को lvl 3 तक घटाया गया
    • gain level SAS connector cable length के अनुसार बदलता है
    • c-payne से बहुत कम cables order कर दिए, इसलिए Amazon से मिलते-जुलते SAS cables खरीदे, लेकिन थोड़े अंतर के कारण समस्या आई और फिर से order करना पड़ा

kernel, ACS और power limit

  • GRUB और NVIDIA UVM

    • /etc/default/grub में निम्न kernel parameters set किए गए
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
    • iommu=off न हो तो multi-GPU P2P में NCCL hang हो जाता है
    • NVIDIA UVM P2P fix के लिए निम्न setting लागू की गई
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

  • ACS disable करना

    • ACS default रूप से enabled हो तो P2P traffic switch fabric के अंदर रहने के बजाय CPU root port से गुजरता है
    • इस स्थिति में PCIe switch का असर खत्म हो जाता है
    • pcie_acs_override के लिए patched kernel चाहिए, इसलिए runtime में setpci से ACS disable किया गया
    • हर boot पर systemd oneshot service से /usr/local/bin/disable-acs.sh चलाया जाता है
    • verification method इस प्रकार है
    • lspci -vvv | grep ACSCtl में सभी minus sign के रूप में दिखने चाहिए
    • nvidia-smi topo -m में चारों GPUs के बीच PIX दिखना चाहिए, PHB/NODE नहीं
    • ./tools/measure-gpu-speed.sh से P2P bandwidth और latency आसानी से measure की जा सकती है

  • GPU power limit

    • 220V circuit installation से बचने के लिए single 110V circuit पर चलाते हुए GPU power limit की गई
    • boot पर systemd से persistence mode और power limit लागू किए जाते हैं
    sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
    • GPU power limit प्रति GPU 350W है और default 600W है
    • 4×350W यानी GPU load 1,400W, जो PSU budget के हिसाब से set किया गया है
    • 240V circuit से पहले single 1700W PSU वाले चरण में GPUs को लगभग 260W पर operate किया गया
    • 4×260W = 1,040W GPU
    • system के लगभग 280W जोड़कर कुल लगभग 1,320W है
    • verification nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv से होती है

measurement results और references

  • CPU की ओर upstream Gen4 x16 है और लगभग 30GB/s है
  • switch के जरिए P2P 27.5GB/s one-way, 50.4GB/s bidirectional है
  • latency 0.37–0.45µs है, Gen4 line rate के स्तर पर
  • ASPM कहीं enabled हो तो lspci idle downstream GPU link को 2.5GT/s (downgraded) दिखा सकता है
  • यह display cosmetic है, और load लगने पर link फिर Gen4 पर train हो जाता है

  • Resources

    • local-inference-lab/rtx6kpro: 4, 6, 8 RTX 6000 Pro cards के उपयोग को अक्सर update करने वाली repository
    • c-payne: इस configuration में इस्तेमाल होने वाला indie PCI switch
    • RTX6kPRO Discord: RTX6kPRO benchmarks और नए model testing को cover करने वाला Discord server

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की टिप्पणियां

  • मैंने local LLM बहुत इस्तेमाल किए हैं और hardware पर जरूरत से ज्यादा पैसा भी लगाया है, लेकिन उम्मीदें कम रखनी चाहिए और बारीक शर्तें ध्यान से पढ़नी चाहिए
    लेख में दिया बड़ा build 40,000 डॉलर के budget से शुरू होता है, लेकिन इसमें 12,000 डॉलर प्रति कार्ड वाले 4 GPU शामिल हैं, इसलिए असल में यह 50,000~55,000 डॉलर के करीब है
    local setup अक्सर model को hardware में fit करने के लिए quantization या REAP जैसी techniques पर निर्भर करते हैं। बहुत लोग दावा करते हैं कि 4-bit quantization lossless है, लेकिन यह छोटे corpus पर KL divergence माप से निकली बात है; लंबे context वाली coding tasks में इस्तेमाल करने पर quality degradation साफ दिखता है। dataset analysis जैसे non-coding कामों में भी 4-bit, 8-bit quantization और कभी-कभी 16-bit original के बीच quality difference काफी हद तक मापा जा सकता है
    यह लेख REAP model इस्तेमाल करने की भी सलाह देता है, जिसका मतलब है कि किसी ने model को छोटा बनाने के लिए कुछ weights काट दिए हैं। विचार यह है कि खास कामों में कम उपयोगी weights हटाए जाएं, लेकिन overall output quality फिर भी घट जाती है
    झांसा यह है कि जब लोग कहते हैं “GLM-5.2 को local पर चला रहे हैं”, तो benchmark देखकर बहुत प्रभावशाली लगता है, लेकिन असल में वे GLM-5.2 नहीं, बल्कि उसका derivative model चला रहे होते हैं जिसमें ज्यादातर bits फेंक दिए गए हैं और कुछ experts हटा दिए गए हैं। बहुत छोटे कामों या chat में quantization/REAP model और original का फर्क ज्यादा नहीं दिखता, लेकिन लंबे tasks में, जहां छोटी गलतियां जमा होती जाती हैं, यह फर्क तकलीफदेह हो जाता है
    फिर चूंकि आप पहले ही 50,000 डॉलर खर्च कर चुके होते हैं, तो quality थोड़ी और बढ़ाने और investment को सार्थक बनाने के लिए 12,000 डॉलर वाले एक-दो GPU और खरीद लेने जैसी फिसलन भरी राह पर उतर जाते हैं

    • मैं RTX4090 पर Qwen3.6 चलाता हूं और ज्यादातर मामलों में यह बहुत अच्छी तरह काम करता है
      coding tasks में session को कई calls में बांटना पड़ता है। मैंने https://github.com/aka-rider/orqestra बनाया था, लेकिन आजकल के tool execution environment में लगभग कहीं भी आप खुद कुछ वैसा कर सकते हैं
      मुख्य बात यह है कि code पढ़ने और tools call करने में context खर्च करने वाले session को अलग रखें, और “संबंधित code और docs यहां हैं और evidence यह है” जैसी Markdown report बनाएं ताकि hallucination घटे। planning session अलग रखें; छोटा model details छोड़ देता है, इसलिए critic और architect के बीच 1~3 बार round-trip कराएं, और worker व verifier के साथ भी इसी वजह से round-trip कराएं
      Qwen3.6 read-only mode में complex bugs को घंटों तक खोज सकता है और आम तौर पर खोज लेता है। उसके सुझाए fixes शायद hacky होंगे, लेकिन Sonnet के साथ भी यही है
      Qwen3.6 Opus द्वारा बनाए plan के अनुसार mechanically code लिख सकता है। इसके बाद prompt देना चाहिए जैसे: “अपने changes खुद review करो। कोई bug है? original plan से cross-verify करके देखो कि कुछ छूटा तो नहीं? CLAUDE.md का उल्लंघन तो नहीं?” लेकिन यही Sonnet के साथ भी बिल्कुल करना पड़ता है
      local LLM का इस्तेमाल knowledge base re-indexing के लिए भी करता हूं। ticket整理 में अगर सिर्फ “error rendering के लिए single panel, सभी error messages move करें” जैसे raw notes छोड़ें, तो वह goal और context के साथ लगभग 90% complete spec बनाकर लौटा सकता है
    • मेरे computer पर 8-bit quantized, non-MoE, 26B Qwen को local चलाने पर भी अनुभव ऐसा ही था
      छोटे कामों के लिए वाकई अच्छा है, लेकिन जब पहली बार कोई बड़ा task दिया, तो agent execution environment क्या है यह भूल गया और tool call format गलत लिखने लगा। वह Pi पर चल रहा था, लेकिन खुद को Claude में चल रहा मानकर non-existent Claude tools call करने की कोशिश करने लगा
    • RAM prices पागल होने से पहले खरीदे MBP पर मैं ds4 चलाता हूं और यह काफी उपयोगी है
      यह अकेले पूरा application नहीं लिखता, लेकिन इसने मेरे tailnet की एक परेशान करने वाली network problem सुलझा दी जिसे खुद समझने का मेरे पास न समय था न उत्साह। और ऐसे छोटे-छोटे कामों पर भी अब अक्सर हाथ डाल देता हूं जो सरल तो हैं, लेकिन investigation cost ज्यादा होने से टाल देता था। यह Opus नहीं है, लेकिन उपयोगी है, और यह चिंता नहीं रहती कि subscription fee या API cost के मुकाबले value मिल रही है या नहीं
    • “local पर चलाना” कहने वाले लेखों और comments में तुलना के लिए वही public benchmarks फिर से चलाकर results भी साथ दिए जाएं, तो अच्छा होगा
    • बिल्कुल सही बात है। coding LLM को local चलाने की सनक ने local AI को उल्टा नुकसान पहुंचाया है, जबकि उद्देश्य के हिसाब से बनाए गए small language models असल में फायदेमंद हो सकते हैं
      natural language processing, speech synthesis, image processing, audio engineering, signal processing, Krita के लिए diffusion plugin जैसे छोटे tools local setup के लिए बहुत अच्छे हैं। कुछ दिन पहले मैंने इस पर एक छोटा-सा लेख भी लिखा था[1]
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...

  • “लगभग 40 हज़ार डॉलर में मॉडल की intelligence एक स्तर ऊपर चली जाती है और Claude Opus के काफ़ी करीब पहुँच जाती है” — यह monthly 200 डॉलर के हिसाब से Claude Opus 4.8 या Codex GPT 5.5 को 16.8 साल इस्तेमाल करने की लागत के बराबर है
    मुझे local model चलाना सच में बहुत पसंद है, लेकिन यह अब भी बेहिसाब महंगा है, quality कम है, और अगर backdoor हो तो जोखिम भरा भी हो सकता है। सच में चाहता हूँ कि ऐसा न हो

    • अगर आपको पूरी API कीमत चुकानी पड़ती है, जैसे कोई “enterprise” company, तो monthly 200 डॉलर वाली बात पहले ही 4,000 डॉलर प्रति माह के ज़्यादा करीब है। तब बराबर लागत 10 महीनों पर आ जाती है
      हालांकि मुझे शक है कि local equipment वास्तव में monthly 4,000 डॉलर की API usage के बराबर workload संभाल पाएगा। क्योंकि local equipment Anthropic के कई datacenters जितनी efficiency से prompts को parallel में चलाना मुश्किल है
    • मूल बात से सहमत हूँ, लेकिन यह calculation मानकर चलती है कि LLM prices लगातार समान रहेंगी
      OpenAI और Anthropic जैसी companies अभी venture capital के दम पर subsidized prices पर plans बेच रही हैं, और वह capital किसी दिन return चाहेगा
    • leading models में backdoor होने की बात समझ में नहीं आती। मैंने किसी backdoored model के बारे में नहीं सुना, और अगर ऐसा मिला तो Hugging Face से जल्दी हटा दिया जाएगा। यह कोई समस्या नहीं है
    • hardware पर आप monthly 200 डॉलर वाले plan से कहीं ज़्यादा tokens इस्तेमाल कर सकते हैं
      OEM spark से पहले महीने में 1 अरब tokens इस्तेमाल किए, जो Opus के हिसाब से 1,000 डॉलर से ज़्यादा का amount है। token pattern अलग है इसलिए यह fair comparison नहीं है, लेकिन उसके बाद vLLM improvements, मुख्य रूप से MTP की वजह से speed भी 2~3x बेहतर हुई। DiffusionGemma सामान्य Gemma से लगभग 4x तेज़ है
    • local पर चलाने की कोशिश करने के बजाय cloud GPU किराए पर ले सकते हैं
      आपके पास optical line भी नहीं है, तो फिर इतनी जल्दी depreciate होने वाली, महंगी और झंझट वाली asset क्यों own करना चाहेंगे?
      cloud GPU किराए पर लेकर आप बड़ा hobby Frankenstein box बनाए बिना ownership culture, data control, price control और hacking culture में हिस्सा ले सकते हैं। वह box महंगा है, distilled होने से practically कम उपयोगी हो जाता है, और maintenance भी headache है

  • कहा जाता है “40 हज़ार डॉलर में लगभग Opus”, लेकिन अगर GLM 5.2 “लगभग Opus” है, तो comfortable inference के लिए कम से कम 8xH200 चाहिए, यानी 40 हज़ार डॉलर नहीं बल्कि 4 लाख डॉलर के करीब
    लेख modified model इस्तेमाल करने का सुझाव देता है: “GLM-5.2, जिसे REAP से prune करके लगभग 22% experts हटाए गए हैं, और Int8-mix NVFP4 से quantize किया गया है, लगभग 594B parameters”
    benchmarks के बाहर असल में यह कैसे चलेगा, यह जानने की उत्सुकता है। Qwen3.6 भी 6-bit quantization पर inference के दौरान अक्सर loop में फँस जाता है, और यहाँ तो कुछ experts भी हटा दिए गए हैं। कभी-कभी 8-bit या 16-bit का छोटा model brain-lobotomized बड़े model से ज़्यादा intelligent हो सकता है। coding के लिए 8-bit से नीचे न जाने पर कुछ consensus लगता है
    यह भी unclear है कि brain-lobotomized model को 4 RTX 6000 cards में fit करने पर usable context कितना बचता है। 100k से कम पर अक्सर ज़रूरी context जुटाने से पहले ही compression लग जाता है, इसलिए practically इस्तेमाल करना मुश्किल है। repository में check किया तो context 240k था

    • जानना चाहता हूँ कि एक H200 पर ही GLM 5.2 चलाने पर क्या होता है
      क्या यह बिल्कुल run नहीं होता, या इतना slow होता है कि इस्तेमाल लायक नहीं रहता? local पर cutting-edge model की build और concept validate करने के बाद, 18~24 महीनों में GPU prices काफी गिरें तो बाकी भरना चाहूँगा
    • सोच रहा हूँ कि इसका scalability से क्या संबंध है
      तो क्या सैकड़ों prompts simultaneously चला सकते हैं?
    • loops, LLM से जुड़े ज़्यादातर phenomena की तरह, sampling problem हैं और DRY penalty से आसानी से solve किए जा सकते हैं
      यह llamacpp में मौजूद है। heretic बनाने वाले व्यक्ति ने state-of-the-art loop prevention और diversification strategy भी बनाई है
    • 8x RTX6000 पर lukealonso NVFP4 quantization इस्तेमाल करें तो 1M context भी संभव है, और कम से कम 400k तक consistency और usefulness बनी रहती है
      जब तक आप बस ऐसा करना ही नहीं चाहते, 8x H200 चलाने की कोई real need नहीं है। अगर regularly बहुत सारे concurrent users या agents को serve करना हो, तो exception है

  • बीच का option भी है। 128GB VRAM सुनिश्चित कर लें तो, unified memory architecture से इतनी capacity पाने के अब कई options हैं, और DwarfStar के जरिए DeepSeek V4 flash अच्छी speed से चला सकते हैं
    मैं पैसा खर्च नहीं करूँगा, लेकिन कई लोगों के लिए यह ठीक compromise point लग सकता है

    • m4 max 128 पर अभी-अभी try करना शुरू किया है, और 1 साल पहले यह machine खरीदने के बाद पहली बार local LLM के साथ ऐसा लग रहा है कि decent coding के लिए यह बस काम करता है
      हालांकि Pi इस्तेमाल करना पड़ता है। claude code का bootstrap context बहुत ज़्यादा है, इसलिए सब कुछ काफी slow हो जाता है

  • “RTX 3090 की 2 cards से कुल 48GB VRAM हो तो Qwen3.6-27B चलाया जा सकता है, और यह शानदार model है” कहा जाता है, लेकिन 3 हज़ार dollar में shared memory 48GB वाला M5 MacBook Pro खरीदा जा सकता है, और वह कोई विशाल box भी नहीं है
    या उस पैसे को cloud hosting provider पर खर्च करने पर भी विचार किया जा सकता है। कम-से-कम कुछ हद तक, शायद उससे भी काफ़ी सस्ता हो सकता है। बेशक model को local पर चला पाना बढ़िया बात है

    • मैं इतना बेवकूफ था कि जिन स्थितियों का अनुभव नहीं किया था उन्हें कल्पना नहीं कर पाता था, इसलिए हमेशा सोचता था कि local LLM पीछा करने लायक चीज़ नहीं, बस खिलौना है
      लेकिन Gemma 4 31B और Qwen 3.6 27B जैसी ठीक-ठाक चीज़ें एक बार इस्तेमाल करके ही समझ आया कि यह कितना उपयोगी है
      संवेदनशील जानकारी share कर रहे हैं या नहीं, इसकी चिंता बंद हो जाती है, token खत्म हो जाएंगे इसकी चिंता नहीं रहती, और remote AI की availability की भी चिंता नहीं रहती। local LLM बहुत मूल्यवान है
    • 3090 की शानदार बात memory bandwidth है। token generation में bottleneck ज़्यादातर memory bandwidth ही होता है
      दो 3090 cards में कुल 1.87 TB/s, प्रति card 0.936 TB/s memory bandwidth है, जबकि M5 MacBook Pro में सिर्फ़ 0.3 TB/s है। Max chip अधिकतम 0.63 TB/s तक जाती है, लेकिन वह configuration 10 हज़ार dollar की machine है
      इसलिए Qwen 27B दो 3090 cards पर वास्तविक काम के लिए पर्याप्त तेज़ चलता है, लेकिन MacBook Pro पर पीड़ादायक रूप से slow लगता है। और MacBook Pro पर बड़े model चलाने से UI अटकता है और keyboard गरम हो जाता है। basement में दो 3090 cards रखकर MacBook से access करना कहीं बेहतर है
    • मेरे पास M5 MacBook Pro भी है और model चलाने के लिए अलग GPU configuration भी, और speed difference बड़ा है
      सिर्फ़ token generation speed ही नहीं, first token तक का समय, यानी prompt processing time भी अलग है। M5 hardware अपने-आप में शानदार है, लेकिन GPU अब भी कहीं तेज़ है
      model को GPU box पर चलाने का फायदा यह भी है कि laptop को गरम plate बनाए बिना गोद में इस्तेमाल किया जा सकता है
    • Qwen3.6-27B को एक 24GB GPU पर 80 tokens/sec पर चला रहा हूं, इसलिए दो cards की ज़रूरत भी नहीं है
    • यह reasonable choice है, लेकिन यह जानना चाहिए कि M5 Pro की memory bandwidth लगभग 1/3 है और M5 Max की भी लगभग 2/3। M5 Max की lowest configuration भी 4,100 dollar है
      इसलिए FLOPS-bound prefill और bandwidth-bound decode, दोनों slow होंगे

  • इस हफ्ते मैंने local LLM अभी-अभी setup किया है, इसलिए मेरा अनुभव भी जोड़ता हूं। Intel का Arc B70 नाम का 32GB card चुना; यह 3090 से सस्ता है और RAM ज़्यादा है, लेकिन memory bus धीमी है
    इसे चुनने की वजह यह थी कि जिन models को इस्तेमाल करना चाहता था वे 24GB में आराम से फिट होने के लिए थोड़े बड़े थे, और autocomplete व speech recognition के लिए कुछ छोटे models और रखने की जगह भी चाहिए थी। साथ ही मेरे पास पहले से एक सस्ता server था, और dual GPU इस्तेमाल करने के लिए motherboard और power supply, शायद case तक बदलना पड़ता
    setup काफ़ी tricky था। Intel line को SYCL, मोटे तौर पर Intel वाला CUDA जैसा कुछ support करने के लिए “level zero” नाम का driver package चाहिए था, और इसे सही से चलाना मुश्किल था। llama.cpp को Docker container में चलाता हूं, और container को card दिखाने में भी थोड़ा काम लगा। पिछले कुछ महीनों के अंदर का kernel भी चाहिए
    एक बार चलने लगा तो 1 हज़ार dollar के investment के हिसाब से नतीजा बहुत impressive है। Qwen 3.6 35B को q4 quantization के साथ चलाने पर RAM का लगभग 3/4 इस्तेमाल होता है और करीब 88 tokens/sec मिलते हैं। अगर कम खर्च में ठीक size का model चाहिए, तो यह एक तरीका है

    • वह गलत है। दोनों GDDR6 हैं
      B70 में 256-bit bus पर 2375MHz, 608 GB/s है, और 3090 में 384-bit bus पर 2438MHz, 936 GB/s है। यह धीमा नहीं है, बल्कि channels कम हैं, यानी width कम है

  • qwen3.6-27b का q4 variant एक 3090 पर कुल लगभग 250K context के साथ भी चलाया जा सकता है
    यह इतना तेज़ है कि झुंझलाहट नहीं होती, इसलिए दो 3090 से मिलने वाला speed boost मेरे लिए worth नहीं है। दो cards पर q6 को आधी speed और छोटे context के साथ चलाने का option भी है, लेकिन वैसे भी यह latest-tier models से compete नहीं कर पाएगा, इसलिए अगर आपके पास पहले से दो 3090 नहीं हैं तो current price पर एक card ही सबसे अच्छा investment लगता है। अच्छी तरह configured runtime हो तो बहुत सारे काम करने के लिए काफ़ी है

    • एक 3090 पर qwen3.6-27b चलाते समय KV cache को भी q4 रखते हो क्या?
      मेरे experience में उस precision पर long-context recall accuracy काफ़ी गिर जाती है। KV cache को q8 पर रखकर 120k context के साथ काम करना बेहतर लगा
    • 250k context, Q4 model, 24GB VRAM का calculation K/V cache तक q4 quantization होने पर ही सही बैठता है, और वह शायद अच्छा idea नहीं है

  • इसी से जुड़ा, मैं सोच रहा हूँ कि अभी इस्तेमाल करने लायक सबसे अच्छा isolation system कौन-सा है। क्या पूरी तरह भारी-भरकम VM तक जाना पड़ेगा, या Firecracker जैसी कोई चीज़ काफी होगी, समझ नहीं आता
    हर संभावित विकल्प में ऐसी बारीक गड़बड़ियाँ लगती हैं जिनसे अपने ही पैर पर कुल्हाड़ी मारना आसान है, और व्यवहार में security लगभग न के बराबर रह जाना आसान दिखता है। VM इसलिए इस्तेमाल करते हैं क्योंकि सच में भरोसा किया जा सकता है कि security इस तकनीक का मूल सिद्धांत है; यह “ये 20 flags लगाओ और आँखें तिरछी करके देखो तो ठीक है” वाला तरीका नहीं है

    • MacOS में built-in seatbelt sandbox है। Linux में namespaces के ऊपर SELinux या वैसी ही utilities लगाए हुए Docker का इस्तेमाल कर सकते हैं
      पहले attack vectors को model करना होगा। rm -rf को write restrictions से रोका जा सकता है, और curl malware.sh | sh को writable directories में execution restrict करके रोका जा सकता है (seatbelt/SELinux)। संवेदनशील directories पर सिर्फ write restrictions लगाने से ही ज़्यादातर malware काफी हद तक निष्प्रभावी हो सकता है
      credentials leak रोकने के लिए environment variables साफ़ करें, .ssh, .aws आदि पढ़ने से रोकें, और LLM को operating system के पास न रखें
      मैंने MacOS के लिए एक छोटी utility https://github.com/aka-rider/leash बनाई है, लेकिन bash script से भी यह किया जा सकता है
    • यह इस पर निर्भर करता है कि किस चीज़ के लिए चाहिए। अगर security model यह है कि agent को PC उड़ाने से रोकने के लिए sandbox में बंद करना है, तो विकल्प बहुत हैं
      हल्का कुछ चाहिए तो bubblewrap[1] जैसा इस्तेमाल कर सकते हैं, या libkrun[2] जैसा microVM इस्तेमाल कर सकते हैं; और संबंधित tooling भी चाहिए तो पूरा Docker तक जा सकते हैं
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • शायद सभी के लिए फिट बैठने वाला ready-to-use configuration नहीं होगा। क्योंकि किसी भी security boundary में हर hardening layer usability trade-off के साथ आती है
      यह अनिश्चितता समझ में आती है कि आप सच में कैसे जानेंगे कि सब कुछ मजबूती से लॉक है
      निजी तौर पर मुझे VM या microVM ही सही रास्ता लगते हैं। containers के उलट, इन्हें असली security boundary के रूप में design किया गया है। bubblewrap की तुलना में भी, आप agent को पूरा filesystem देकर YOLO mode में चला सकते हैं, जबकि bubblewrap में हर development tool की availability को अलग-अलग bootstrap करना पड़ता है, config directories और package caches आदि को सुरक्षित रूप से mount करना पड़ता है, और फिर भी permission errors लगातार मिलने की संभावना रहती है। isolation भी कहीं कमजोर है
      runtime environment support सीमित है, लेकिन host पर runtime environment process चलाकर सभी tool calls और filesystem interactions को VM को delegate करने का तरीका काफी उचित लगता है। तब session data और auth keys मुख्य machine पर रखे जा सकते हैं, ताकि वे context में कभी न आएँ। इसके बदले runtime environment खुद security boundary का हिस्सा बन जाता है, यही trade-off है
      VM के अंदर-बाहर data कैसे ले जाएँ, यह भी usability की समस्या है। मैं local git repository को VM में push करके उसे remote की तरह फिर वापस fetch करने की scripts इस्तेमाल कर रहा हूँ; इससे VM host की ओर connection शुरू नहीं कर सकता और उसे git credentials रखने की भी जरूरत नहीं होती। लेकिन जो लोग चाहते हैं कि agent सीधे GitHub पर push करे, उनके लिए यह जरूरत से ज्यादा मेहनत हो सकती है
      VM के तौर पर जिन विकल्पों को मैंने आज़माया या देखा है वे हैं qemu + libvirt, crun-vm, और libkrun family। qemu + libvirt को सही तरह set up करने में मेहनत लगती है, लेकिन यह बहुत validated और configurable है। crun-vm podman और qemu के बीच high-level integration layer का PoC है; लगता है छोड़ दिया गया है, लेकिन मौजूदा tools और standards-centric होने की वजह से दिलचस्प है। libkrun नया entrant है और इसके microsandbox, smolvm, krunvm जैसे wrappers हैं। ये सब Linux के लिए हैं
    • GPU passthrough वाली भारी VM पर मैं CPU-only VM की तुलना में बहुत कम भरोसा करता हूँ

  • LLM इस्तेमाल करने के लिए इतना प्रयास करना अजीब लगता है। खासकर इस तरह cutting edge के पीछे भागना तो और भी
    Claude जैसी चीज़ें कल गायब हो जाएँ तो भी मुझे ज़रा फर्क नहीं पड़ेगा
    समझ नहीं आता कि लोग अपने दिमाग की सिलवटों को slop machine की access के बदले क्यों दे देते हैं। अगर कोई अच्छी analogy हो, तो शायद यह एक skilled carpenter को ऐसी machine देने जैसा है जो Ikea से भी एक-दो स्तर कम quality का furniture उगलती है। क्या वह काम कर देती है? ज़्यादातर, हाँ। क्या carpenter को वह process पसंद आता है? नहीं

  • मेरे अनुभव में q4 जैसे बहुत ज्यादा quantized या कुछ हद तक modified models चलाकर कभी “वाह, सच में कमाल है” जैसा नहीं लगा। उल्टा, कुछ prompts डालने के बाद वे trash में चले गए
    मेरे पास 96GB वाला RTX 6000 PRO है, और आराम से चलने वाले models Qwen 3.6 27B या MoE, Gemma 4 31B तक हैं। model को full precision और maximum context length पर चलाते समय सीमा यही है
    ये अच्छा performance देते हैं और coding, internet research जैसी कई चीज़ों में इस्तेमाल हो सकते हैं। हिसाब लगाने पर अगर लगता है कि आप Anthropic पर सालाना 2,400 dollars से ज्यादा खर्च करेंगे, तो ऐसा card खरीदना समझ में आ सकता है, लेकिन quality degradation स्वीकार करना पड़ेगा। वैसे भी 5 साल बाद भी इंसान coding कर रहे होंगे या नहीं, यह भी सवाल है