- Gemma 4 26B-A4B को 2016 के single Intel Xeon E5-2620 v4, DDR3 128GB, बिना GPU वाले सर्वर पर
ik_llama.cpp optimization के साथ पढ़ने की गति के स्तर तक चलाया गया
- LLM decoder path में compute से ज़्यादा memory bandwidth bottleneck बनता है, और CPU का बड़ा हिस्सा RAM से cache में अगला weight लाने का इंतज़ार करने में जाता है
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack आदि MTP speculative decoding, MoE routing, और cache-friendly memory layout के ज़रिए DDR3 environment के bottleneck को कम करते हैं- लॉग के अनुसार कुल memory requirement 82,355MiB है, और पूरे 262K context में लगभग 25GB weights की तुलना में लगभग 56GB KV cache बड़ा है
ollama जैसे black-box tools में ज़रूरी model support और fine-tuning knobs की कमी होती है, और पुराने hardware पर performance निकालने के लिए inference engine और memory structure की गहरी समझ चाहिए
रनटाइम environment और मुख्य bottleneck
- टेस्ट सर्वर reused hardware है, और इसकी specification है Intel Xeon E5-2620 v4 @ 2.10GHz, 8-core 16-thread, AVX2, 20MiB L3 cache, 2MiB L2, 128GB DDR3, बिना GPU
- यह CPU AVX-512, AVX-VNNI, BF16 को support नहीं करता, और इसमें integrated GPU भी नहीं है
- LLM inference में एक-एक token generate करने वाला decoder path मुख्य रूप से compute नहीं बल्कि memory bandwidth से बंधा होता है
- अगला token निकालने के लिए model के learned knowledge वाले weights को RAM से CPU cache और cores तक लगातार लाना पड़ता है, और processor matrix compute से ज़्यादा समय अगले weights के आने का इंतज़ार करता है
- यह “memory wall” सिर्फ Xeon पर नहीं, बल्कि H100 जैसे high-performance hardware पर भी एक अहम performance barrier है
Black-box tools की जगह ज़रूरी runtime knobs
- DDR3 और बिना GPU वाले environment में अगर सिर्फ
llama-cli चलाया जाए, तो यह बहुत धीमा होता है, और सामान्य GPU use case के लिए बनी optimization की वजह से काफ़ी improvement की गुंजाइश बचती है
ollama में ज़रूरी model support न हो सकता है, और यह performance को पूरी तरह निकालने लायक पर्याप्त detailed settings expose नहीं करता- वास्तविक execution के लिए
ik_llama.cpp द्वारा exposed कई flags को मिलाकर इस्तेमाल करना पड़ता है
- मुख्य flags का सेट इस प्रकार है
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Speculative decoding और MoE optimization
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune 26B verifier को पहले से बने छोटे MTP drafter के साथ इस्तेमाल करता है--draft-max 3 का मतलब प्रति draft अधिकतम 3 token, --draft-p-min 0.0 का मतलब सभी probabilities स्वीकार करना, और --spec-autotune workload के हिसाब से chain length को adjust करता है- लंबे inference chain बनाते समय, भले ही user को सिर्फ छोटा final answer दिखे, हर hidden thinking token के लिए पूरा decoder path चलाना पड़ता है
- CPU पर verifier weights को cache में stream करने की लागत बड़ी होती है, जबकि छोटे drafter की active layers L3 cache में अच्छी तरह fit हो जाती हैं, इसलिए speculative decoding का फ़ायदा और बढ़ जाता है
- Gemma 4 26B-A4B एक MoE architecture है, जिसमें 128 experts में से प्रति token 8 active होते हैं, और कुल लगभग 25.2B parameters में से active parameters लगभग 3.8B हैं
--cpu-moe CPU cache hierarchy के हिसाब से routing adjust करता है, और 128 experts के बीच लगातार आने-जाने से होने वाली cache thrashing को कम करता है, जिसमें cache खाली होकर डेटा फिर DDR3 से लाना पड़ता है--merge-up-gate-experts expert के अंदर up projection और gate projection को एक matrix multiply में fuse करता है, और लॉग में इसे fused_up_gate = 1 के रूप में देखा जा सकता है-t 8 8 physical cores के हिसाब से सेट किया गया है, क्योंकि memory-bound workload में सभी 16 SMT threads का उपयोग throughput बढ़ाने के बजाय scheduling cost बढ़ा सकता है
Memory pinning, repacking, और graph splitting
--run-time-repack inference शुरू होने से ठीक पहले weight matrices को CPU cache layout के अनुसार फिर से व्यवस्थित करता है, और लॉग में यह Repacked 265 tensors के रूप में दिखता है- यह setting startup पर कुछ सेकंड की लागत लेकर RAM के भीतर मौजूद numeric tables को ऐसे रूप में rearrange करती है जिसे CPU बेहतर पढ़ सके, और वास्तविक text generation के दौरान memory bandwidth का अधिकतम उपयोग हो सके
--mlock model को RAM में pin करता है ताकि operating system उसे disk पर swap न कर सके- अगर kernel की memlock limit काफ़ी नहीं है, तो
failed to mlock 27628376064-byte buffer और Try increasing RLIMIT_MEMLOCK जैसी warning आती है, जो LLM की समस्या नहीं बल्कि default ulimit setting की समस्या है
--no-kv-offload बिना GPU वाले environment में KV cache को GPU पर भेजने की कोशिश छोड़कर उसे system RAM में ही रखता है-sm graph computation graph को vertically बाँटकर graph splitting की कोशिश करता है, ताकि कई processing devices या memory regions एक ही layer के अलग-अलग हिस्सों को साथ में compute कर सकें- इस run में
Split mode 'graph' is not supported for Gemma4 external MTP लॉग के साथ यह सुरक्षित रूप से layer splitting पर fallback हो गया
-sas physical CPU sockets या NUMA nodes के बीच workload splitting का निर्देश देता है, और --split-mode-f32 split होने के बाद फिर से जुड़ने वाले intermediate points पर 32-bit floating-point precision का उपयोग कराता है
Attention, memory usage, और निष्कर्ष
- ikawrakow ने CPU पर Flash Attention चलाने के लिए custom kernel लिखा है, जिससे भारी context processing GPU के बिना भी चल सके
--flash-attn on attention softmax और matrix multiply को fuse करता है, ताकि पूरा N×N attention matrix RAM में physically लिखने के बजाय छोटे chunks में cache के भीतर compute और consume किया जा सके--mla-use 3 Multi-Head Latent Attention को enable करता है, जो KV cache के Key और Value को छोटे latent representation में compress करता है- लॉग में
flash_attn = 1, fused_moe = 1, fused_up_gate = 1 दिखता है, जिससे पुष्टि होती है कि ये optimization वास्तव में लागू हुईं
- memory log के अनुसार सभी layers का कुल योग 81,607.46MiB है, और model tensors तथा cache के लिए ज़रूरी memory 82,355MiB है
- पूरे 262K context में weights लगभग 25GB हैं, जबकि KV cache लगभग 56GB है, यानी KV cache model से बड़ा है
- यह configuration 25B parameter MoE को load करके MTP drafter के साथ speculative decoding चलाती है, और 2016 के Xeon, DDR3, तथा बिना GPU वाले सर्वर पर पढ़ने की गति से text generate करती है
- निष्कर्ष यह है कि आधुनिक open-weight AI को local पर चलाने का bottleneck सिर्फ silicon नहीं, बल्कि inference engine के व्यवहार और memory structure की समझ भी है; सही fork, calibrated quantization, और memory architecture की समझ हो तो पुराने सर्वर पर भी इसे चलाया जा सकता है
2 टिप्पणियां
Hacker News की राय
मैंने यह पोस्ट इसलिए लिखी क्योंकि नए Gemma 4 Drafter मॉडल को चलाने के तरीके बहुत कम हैं, और मुख्यधारा के टूल performance tuning के बिंदुओं को छिपा देते हैं, जो काफ़ी निराशाजनक है।
आखिरकार मैं GPU के बिना, सिर्फ़ एक single Xeon E5-2620 v4 और 128GB DDR3 RAM वाले पुराने recycled server पर, नवीनतम 26B MoE मॉडल को reading speed पर चलाने में सफल हुआ।
मैंने पोस्ट के अंत में quantized model का लिंक भी दिया है, लेकिन वह तब तक नहीं चलेगा जब तक आप बताए गए ik_llama-cpp fork का इस्तेमाल न करें, और उसके विवरण के लिए दूसरी पोस्ट देखनी होगी।
मैं machine learning engineer नहीं हूँ, और server भी Nix cache की भूमिका में व्यस्त है, लेकिन सवाल हों तो जहाँ तक संभव होगा जवाब दे सकता हूँ।
क्योंकि जब एक thread DDR3 का इंतज़ार कर रहा हो, तब दूसरा thread चल सकता है।
साथ ही,
--cpu-moeका विवरण भी मुझे ठीक से समझ नहीं आ रहा। एक expert के पास लगभग 4.0GiB parameters हैं, और अगर L3 cache सिर्फ़ 20MiB है, तो expert order को optimize करने पर भी parameters को अर्थपूर्ण तरीके से cache करना मुश्किल लगेगा।और जैसा दूसरों ने कहा, Intel Xeon E5-2xxx v4 में सिर्फ़ कुछ मॉडल ही DDR3 को support करते थे, और Intel के दस्तावेज़ों के अनुसार E5-2620 v4 उनमें से एक नहीं है।
इसमें dual Xeon और 128GB DDR3 configuration है, और CPU कुल 24 cores/48 threads के 2 × Xeon E5-2697 v2 हैं, इसलिए core count बेहतर है, लेकिन असली फ़र्क़ शायद बड़ा न हो।
यह मशीन बस धूल खा रही है, इसलिए reading speed Gemma काफ़ी उम्मीद जगाती है।
Amazon पर “chia farming” सर्च करें, बस chia seeds वाले नतीजों को छोड़ दें।
अब वही मशीन लगभग 2.5 गुना महंगी हो गई है, लेकिन फिर भी मौजूदा पीढ़ी की DDR5 मशीनों से काफ़ी सस्ती है।
https://www.amazon.com/dp/B095TRGCSX
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, online CPU 0-31, 128GB RAM configuration है।जानना चाहता हूँ कि अगर DIMM slots 8 हों, तो क्या वास्तव में memory bandwidth बेहतर होती है। अभी यह बेचारा सिस्टम सिर्फ़ YouTube देखने के काम आ रहा है।
अभी हम वहाँ तक नहीं पहुँचे हैं, लेकिन मौजूदा bubble के खत्म होने का साफ़ अंतिम बिंदु यही है कि local hardware और devices पर चलने वाले open models ज़्यादातर उपयोगों के लिए “काफ़ी अच्छे” हो जाएँ।
अगर ऐसा हुआ, तो अभी tech industry में जो कुछ हो रहा है, वह पूरी तरह बिखर सकता है।
जब सच में फँस जाऊँगा तब Claude API बुला लूँगा, लेकिन मेरी 80% ज़रूरतें एक कम समझदार local model से पूरी हो सकती हैं।
Programming languages और techniques इतनी तेज़ी से नहीं बदलतीं, इसलिए उम्मीद है कि यह कम से कम 5 साल काम आएगा, और जब उसी VRAM में ज़्यादा स्मार्ट model फिट करने लायक optimization आ जाएगी तब upgrade कर लूँगा।
मुझे यह दिशा पसंद है।
अगर वह ऐसा नहीं कर रहा, तो मेरा अनुमान है कि अभी AI labs अपने models बहुत बड़े घाटे पर बेच रही हैं, इसलिए Amazon के लिए low-margin compute बेचना उसके दूसरे high-margin products की तुलना में कम आकर्षक है।
मौजूदा स्थिति के टूटने के लिए शायद local execution तक पहुँचना भी ज़रूरी न हो। जब AI labs की free-money runway खत्म होगी और उन्हें वास्तविक execution cost से ऊपर कीमत रखनी पड़ेगी, तब compute रखने वाला कोई भी खिलाड़ी open model service को सामान्य बाज़ार दर पर उससे सस्ता देने के लिए प्रेरित होगा।
आख़िर में हर किसी के पास model होगा और उसे चलाने की क्षमता भी, और इसी वजह से GPU की कमी अभी इनके पक्ष में काम कर रही है।
उनकी उम्मीद इस पर टिकी है कि enterprises और SMBs अपनी सारी work processes को cloud में ले जाएँ, और कर्मचारी जितना हो सके उतने tokens खर्च करने की होड़ लगाएँ।
“काफ़ी अच्छे” models के साथ privacy और long-term cost savings जुड़ जाएँ, तो वे आकर्षक बन जाते हैं।
विडंबना यह है कि coding agents के लिए जितना बेहतर general-purpose execution environment बनेगा, Claude जैसी सेवाओं की moat उतनी कम होगी। कुछ महीने पहले के frontier models को कुछ open models ने जितनी तेज़ी से catch up किया है, उस पर यक़ीन करना मुश्किल है।
पोस्ट भी अच्छी है और तकनीकी रूप से भी प्रभावशाली है। मैं इस बात से सहमत हूँ कि build pipeline को समझना और चीज़ों को local पर चला पाना ज़रूरी है।
लेकिन बिजली के दाम पर निर्भर करते हुए यह आर्थिक रूप से लाभकारी न भी हो सकता है। पुराने servers energy efficient नहीं होते, और मैं सोच रहा था कि पुराने Xeon server load पर लगभग 200W खाएँगे, जबकि वही model OpenRouter पर 0.1/0.3 डॉलर प्रति 1 million tokens, 76 tokens/second, और 262k context के साथ उपलब्ध है।
और वैसे भी ऐसे servers शोर करते हैं। हालांकि, 200W का मेरा अनुमान शायद बहुत ज़्यादा था; पुराने Xeon servers जिन्हें मैं इस्तेमाल करता था वे काफ़ी बिजली खाते थे, लेकिन exact model याद नहीं है।
Servers आम तौर पर शोर करते हैं, लेकिन वह भी configuration पर निर्भर है। ऐसे chips पर आधारित काफ़ी सस्ती hosting मिलती है, और ये उम्मीद से ज़्यादा power efficient हैं।
अगर इसी तरह की configuration को 4U case और धीमे 120mm fans के साथ चलाएँ, तो सब ठीक रहता है।
यह देखकर अच्छा लगा कि दूसरे लोग भी यह बात समझ रहे हैं। मैं 2012 के Xeon और 16~24GB RAM कंटेनर पर Gemma 26B-A4B Q4 चला रहा हूँ, और लगभग 8~12 टोकन/सेकंड मिल रहे हैं
बड़े context या GPU रन से इसकी तुलना नहीं की जा सकती, और llama.cpp का image decoder भी GPU से काफी धीमा है, लेकिन छोटे automation tasks या सामान्य ज्ञान वाले सवालों के लिए यह ठीक है। पढ़ते-पढ़ते साथ चल पाने जितनी गति है, इसलिए इंतज़ार कम खलता है
सेटअप में OpenBLAS और OpenMP सक्षम
llama.cppbuild,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL,q8_0cache, और 8192 context जैसी settings हैंCPU के हिसाब से AVX2 जैसी optimizations देखनी पड़ेंगी, और MTP थोड़ी देर आज़माया था लेकिन performance gain नहीं मिला। cache·context batch size समायोजित कर सकते हैं या Q2 तक नीचे जा सकते हैं, और threads ज़रूरत से ज़्यादा allocate करने से बचना बेहतर है। defaults या
llama-benchसे शुरू करने की सलाह दूँगाटेस्ट के दौरान मैंने
gemma4:e4b-it-q4_K_Mचलाया, जो 11GB VRAM में पूरी तरह फिट हो जाता है, और 50 टोकन/सेकंड से ऊपर मिला। इतना छोटा model coding के लिए खास उपयोगी नहीं है, लेकिन दूसरे कामों में काम आ सकता हैमैं Wake-on-Use बनाकर इसे निजी ChatGPT की तरह इस्तेमाल करना चाहता हूँ। शायद Pi को proxy बनाकर Wake-on-LAN script call करवाई जा सके, और कभी यह एक मज़ेदार weekend project बन सकता है
हमेशा चालू रहने वाला LLM dense
Gemma4:31bहै, जो 12GB 2060 में आधा भी नहीं समाता; बहुत धीमा है लेकिन quality अच्छी है, और यह automated queue processing के लिए है इसलिए मैं output को घूरता नहीं बैठा रहता। एक और 2060 है, लेकिन दोनों लगाने पर PC POST नहीं करतामैं कुछ समय तक Mac Studio Pro लेने पर सोचता रहा, लेकिन आखिरकार इस रास्ते पर आ गया। HP Z620 headless machine में 192GB ECC RAM, dual Xeon E5-2680 v2, Optane AIC, 10GB VRAM वाले P102-100 के दो कार्ड, Debian 12.6 के साथ minimal boot SSD, और Pascal cards को support करने वाला fixed पुराना CUDA version लगाया है
इसे basement से AMT/meshcommander के जरिए remotely चलाता हूँ,
llama.cppऔर frontend उठाकर local network से access करता हूँ। Talkie, Qwen 3.6 27b, medgemma के साथ काम कर रहा हूँ, और सही quantization चुनने पर GGUF performance कुल मिलाकर ठीक लगीकुल लागत 500 डॉलर से कम थी, लेकिन यह server मैंने पिछले साल eBay से खरीदा था, इसलिए अब कीमत अलग हो सकती है
आगे अगर ternary LLM सच में आगे बढ़ते हैं, तो उम्मीद है यह पुराना hardware असल में knowledge से भरे high-density models host कर पाएगा। GPU RAM से बड़ा होने पर Optane में spill हो जाए तो भी ठीक है, क्योंकि speed से ज़्यादा सामान्य factual knowledge अहम है
आख़िरी योजना यह है कि सेटअप के बाद इसे basement की Faraday कूड़ेदान में रख दूँ, ताकि दुनिया टूटने की स्थिति में यह “सभ्यता के पुनर्निर्माण” के लिए एक oracle की तरह बचा रहे। हाँ, ऐसी स्थिति में बिजली समस्या होगी, लेकिन अगर यह hardware इतना सस्ता है और modern AI इतने practical मौके देता है, तो इसे आज़माना बनता है
AI प्रगति में सबसे दिलचस्प बात AGI या किसी खास AI unicorn का latest model नहीं, बल्कि local में क्या चलाया जा सकता है यह है
6 साल पहले high-end gaming PC पर मज़ेदार लेकिन लगभग बेकार models चला सकते थे, जबकि आज M5 laptop पर उससे 100 गुना बेहतर चीज़ चलाई जा सकती है
अगर बाज़ार memory shortage पर प्रतिक्रिया देता रहा और Apple silicon की प्रगति इसी रफ़्तार से जारी रही, तो 6 साल बाद local में क्या चल सकेगा यह बहुत दिलचस्प या डरावना हो सकता है
यह AI कंपनियों की valuation के लिए क्या मायने रखता है, यह भी समझ नहीं आता। पहले एक event में मैंने उस कंपनी के एक कर्मचारी से ऐसा ही सवाल पूछा था, तो उसने जवाब देने के बजाय cocktail लेने जाना बेहतर समझा
AI business पुराने कारखानों की तरह capital-intensive है। datacenter महंगे हैं, models बहुत बिजली खाते हैं, और अंदर का hardware हर 3~4 साल में बदलना पड़ता है
छोटे और specialized models नीचे से margins को खा जाते हैं। transcription, voice, image detection के लिए giant models की ज़रूरत नहीं होती
पारंपरिक software business जैसी high margins की उम्मीद करने की कोई वजह नहीं है, और AI का ज़्यादातर फ़ायदा उपभोक्ताओं तक जाता है। हाँ, Microsoft, Google, Amazon, Meta जैसी कुछ बड़ी कंपनियाँ economies of scale से cost advantage ले सकती हैं
5080 जैसे top-end के बिना भी, ठीक-ठाक gaming GPU होने पर 2025 की शुरुआत के cutting edge से बेहतर local models चलाए जा सकते हैं
काम के हिसाब से model बदलना पड़ सकता है, और एक ही सब-कुछ करने वाला ultra-large model अभी भी datacenter की दुनिया में है
लेकिन full-time नौकरी और दो बच्चों वाले ज़्यादातर लोगों के पास patching और maintenance के लिए समय या ऊर्जा नहीं होती। systems लगातार ज़्यादा जटिल हो रहे हैं और bugs भी बढ़ रहे हैं। यह आज़ादी और सुविधा के बीच पुराना समझौता है
ज़्यादातर users को यह नहीं पता कि LLM क्या है या यह कैसे चलता है। कई LLM users वही इस्तेमाल करते हैं जो उनके workplace में दिया जाता है, और थोड़े ज़्यादा जानकार users भी OpenAI या Anthropic की subscription fee देने में सहज दिखते हैं
local LLM पसंद करने वाला open weights models का एक छोटा लेकिन समर्पित user base बनेगा, लेकिन बाकी लोग बड़े providers से ही consume करते रहेंगे। यह आज के operating systems जैसा हो सकता है, जहाँ थोड़े Linux users हैं और बहुमत Windows, macOS, Chrome पर है
5~6 साल पुराने games बहुत सस्ते मिल जाते हैं और साधारण hardware पर भी चल जाते हैं। लेकिन industry 5 साल तक स्थिर नहीं बैठती, इसलिए बेहतर hardware माँगने वाला नया software लगातार आता रहता है
मूल पोस्ट के लेखक ने टिप्पणियों में जो नतीजा बताया, वह लगभग 12 टोकन/सेकंड है
इस हार्डवेयर पर जितना संभव होगा, मैंने उससे कहीं ज़्यादा प्रभावशाली प्रयास सोचा था, लेकिन संतोषजनक इंटरैक्टिव सेशन के लिए ज़रूरी स्तर से यह अभी भी काफ़ी कम है
कई बार अत्याधुनिक मॉडलों की तुलना में 100~500 गुना सस्ते होते हैं, और टोकन/सेकंड भी 2~5 गुना तेज़ हो सकता है
बैकग्राउंड उपयोग के लिए तो यह काफ़ी ठीक होगा
यह काम तो करता है, लेकिन गंभीर काम के लिए इसकी throughput नहीं है
E5-2620 v4 शानदार है। मैं इसे 10 साल से इस्तेमाल कर रहा हूँ, और अपग्रेड करने ही वाला था, लेकिन मौजूदा कीमतें देखकर रुक गया
मैंने 64GB DDR4 के साथ RX 9060 XT 16GB लगाया है, और गेम अभी भी तेज़ चलते हैं। DOOM The Dark Ages में CPU थोड़ा bottleneck हो सकता है, लेकिन 60fps मिल रहा है, इसलिए कोई समस्या नहीं
हल्के LLM को GPU पर चलाना तो स्वाभाविक विकल्प है, और CPU पर भी tuning के साथ इसे ठीक-ठाक चलाया जा सकता है, यह काफ़ी बढ़िया है
मैंने एक महीने पहले 2667 v4 को 30 डॉलर में खरीदा था, और लगता है कि प्रदर्शन में काफ़ी सुधार होगा, लेकिन अभी उसकी ज़रूरत नहीं पड़ी। अगर इस पोस्ट की तरह LLM की दिशा में ज़ोर लगाना हो, तो 2667 थोड़ी तेज़ RAM संभाल सकता है, इसलिए शायद अपग्रेड करूँगा
सेकंड-हैंड बाज़ार में अभी भी क्या-क्या मिल सकता है, यह देखकर मैं अब भी काफ़ी हैरान हूँ
मुझे अंदाज़ा नहीं था कि RAM और GPU की कीमतें इतनी उछल जाएँगी, इसलिए संयोग से टाइमिंग अच्छी रही। eBay पर लगभग 300 डॉलर की 3080 मिल जाए तो 1080 Ti बेचने का भी सोच रहा हूँ, लेकिन उसके अलावा यह एक शानदार अपग्रेड रहा है
यह बिजली Coca Cola की तरह गटकता है, लेकिन वर्कस्टेशन के रूप में बेहतरीन काम करता है, इसलिए मेरा इरादा है कि इसे खराब होने तक पूरा इस्तेमाल करूँ
पहले मैं सोचता था कि गर्मी से होने वाला नुकसान 5~7 साल में CPU को खत्म कर देता है, लेकिन अब सोचता हूँ कि शायद यह धारणा ही ग़लत थी। हो सकता है आज के CPU पहले से कहीं ज़्यादा मज़बूत और टिकाऊ हों
पुराने Xeon optimization से जुड़ी हाल में एक मिलती-जुलती पोस्ट भी थी
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
हैरानी की बात है कि Itanium भी LLM के लिए काफ़ी उपयुक्त लगता है: https://medium.com/@tglozar/running-llama-inference-on-intel...
सोचें तो यह बात समझ में आती है
कंटेंट काफ़ी दिलचस्प है। मेरे पास एक पुराना Xeon सिस्टम है, इसे एक बार आज़माना पड़ेगा।