GPU के बिना 13 साल पुराने Xeon पर Gemma 4 26B को 5 टोकन/सेकंड पर चलाना

 (neomindlabs.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2013 के डुअल Xeon E5-2690 v2 और DDR3 से बने सर्वर पर Gemma 4 26B-A4B Q8_0 को केवल CPU पर चलाकर decoding में लगभग 5.2 टोकन/सेकंड और prompt evaluation में लगभग 16 टोकन/सेकंड हासिल किए गए
  • ik_llama.cpp का fast path AVX2·FMA3 को आधार मानता है, लेकिन Ivy Bridge CPU सिर्फ AVX1 सपोर्ट करता है, इसलिए non-AVX2 build के लिए compile fixes और operation fallback की जरूरत पड़ी
  • Graph builder बिना शर्त MOE_FUSED_UP_GATE और FUSED_UP_GATE बनाता है, जबकि non-AVX2 dispatcher में इनके लिए handling path नहीं था; नतीजतन हर forward pass में लगभग 240 tensors बिना calculate हुए रह जाते थे और उलझा हुआ multilingual output मिलता था
  • Claude ने logit instrumentation और code analysis से error खोजा और fused operation को दो ggml_mul_mat_id और ggml_fused_mul_unary से बदल दिया; user ने experiments चलाए और सही result के benchmark को पहचाना
  • पुराने enterprise servers भी paid API outage के समय local fallback या धीमे batch jobs के लिए उपयोगी हो सकते हैं, लेकिन AVX2-only layout बनाने वाला --run-time-repack इस्तेमाल नहीं करना चाहिए

13 साल पुराने storage server का execution environment

  • Reuse किए गए HP StoreVirtual उपकरण में 2013 का dual Xeon E5-2690 v2 और DDR3 memory है, और GPU नहीं है
    • Ivy Bridge generation होने के कारण यह सिर्फ AVX1 support करता है और AVX2 तथा FMA3 support नहीं करता
    • इसे मूल रूप से disk storage के लिए बनाया गया था और खरीद लागत 300 डॉलर से कम थी
  • चलाया गया model Google का Gemma 4 26B-A4B है, जो 26 billion parameters वाला open-weight Mixture of Experts (MoE) model है
  • Q8_0 quantized model में decoding लगभग 5.2 टोकन/सेकंड और prompt evaluation लगभग 16 टोकन/सेकंड मापा गया

शुरुआती बिंदु बना 2016 Xeon का उदाहरण

  • Hacker News पर share किया गया A 10 year old Xeon is all you need GPU के बिना 2016 के single Xeon और 128GB DDR3 पर Gemma 4 चलाने का उदाहरण है
  • उस setup में ik_llama.cpp और लगभग 25 fine-grained execution flags इस्तेमाल किए गए
    • speculative decoding
    • CPU-aware MoE routing
    • CPU के लिए flash attention
    • runtime weight repacking
  • वही approach Ivy Bridge server पर लागू की गई, लेकिन startup phase में execution रुक गया
    • 2016 Broadwell CPU के उलट E5-2690 v2 में AVX2 और FMA3 नहीं हैं
    • ये instruction sets 2014 Haswell, यानी Intel की v3 generation से उपलब्ध हुए थे, और fast kernels इन्हीं को मानकर लिखे गए थे

Claude से diagnosis और patch

  • Startup failure की जानकारी मिलने पर Claude ने वजह CPU instruction set difference बताई
  • पहले free model से किए गए अधूरे प्रयास को आगे बढ़ाते हुए, performance-critical C++ paths को इस तरह सुधारा कि वे AVX2 से पहले के CPUs पर सही fallback करें
  • काम एक simple fix it request पर खत्म नहीं हुआ
    • किसी और developer द्वारा लिखा performance-focused C++ code पढ़ा गया
    • खास microarchitecture पर kernels valid क्यों नहीं हैं, इसका analysis किया गया
    • fork की existing optimizations हटाए बिना unsupported paths को bypass किया गया
  • User ने C++ kernel fallback खुद लिखने के बजाय experiments चलाए, output पढ़ा, अगला सवाल तय किया, और सही result के benchmark को पहचानने की भूमिका निभाई
  • Diagnosis और patch उसी server पर चल रहे Claude instance ने किए

non-AVX2 build में टूटा हुआ operation path

  • Gemma 4 MoE inference के लिए इस्तेमाल किया गया ik_llama.cpp, llama.cpp का fork है और default रूप से AVX2 को minimum requirement मानता है
  • Build करते समय GGML_USE_IQK_MULMAT बंद करने पर ज्यादातर fast paths हट जाते हैं और सामान्य scalar/SSE operations पर fallback होता है
    • सामान्य Q8_0 matrix multiplication के लिए यह fallback काम करता है
    • लेकिन दो graph operations पर fallback लागू नहीं हुआ
  • Gemma 4 का MoE feed-forward network ये operations बनाता है
    • MOE_FUSED_UP_GATE: expert-wise gate·up matrix multiplication और SwiGLU को combine करने वाला operation
    • FUSED_UP_GATE: non-MoE layers में इस्तेमाल होने वाला dense operation version
  • Compute dispatcher में दोनों operations GGML_USE_IQK_MULMAT condition से guarded थे, लेकिन graph builder बिना condition के operations बनाता था
    • non-AVX2 build के dispatcher में उस enum को handle करने वाला case नहीं था
    • Operation default branch में चला जाता था, जिससे सभी expert feed-forward networks के destination tensors चुपचाप calculate नहीं होते थे
  • Gemma 4 26B में 30 layers में प्रति token 8 active experts इस्तेमाल होते हैं, इसलिए हर forward pass में memory buffer में बचे values वाले लगभग 240 tensors consume हो जाते थे

उलझे output से मिले clues

  • Error output fluently लिखा दिखता था, लेकिन अर्थहीन multilingual string था
    • 262,000 vocabulary में token IDs बराबरी से फैले हुए थे
    • Thai, Korean, <unused> sentinels, English fragments आदि लगभग समान frequency से generate हो रहे थे
  • Temperature 0 पर output deterministic था, single-thread और multi-thread execution results भी byte-level पर समान थे, और NaN नहीं आया
  • हर layer में large constants hidden state को push करते हुए दिखे, जिससे final softmax flat हो रहा था
  • Claude ने sampling से पहले raw logits instrument करके top 5 tokens, range, mean और NaN count print किए
    • पहले predicted token का mean logit 0 के आसपास नहीं बल्कि +16 था
    • पूरी vocabulary के लगभग 80% tokens में positive logits थे
  • Random corruption के विपरीत bias consistent था, इसलिए समस्या का scope इस ओर narrow हुआ कि hidden state का बड़ा हिस्सा छोटे positive floating-point values बचे हुए uninitialized memory का उपयोग कर रहा है

तीन चरणों वाला fix

  • Patch fork के main पर तीन commits से बना है

  • non-AVX2 compile fix

    • iqk_quantize.cpp में quantize_row_q8_0_x4 और quantize_row_q8_1_x4_T की scalar #else branch असल में hsum_i32_8 जैसे AVX2 helpers refer कर रही थी
    • उस branch को portable scalar loops के रूप में दोबारा लिखा गया
    • ggml.c और ggml-quants.c में leak हुए कुछ IQK calls पर #if GGML_USE_IQK_MULMAT guard conditions जोड़ी गईं
    • iqk_cpu_ops.cpp को independently compile करने के लिए missing includes जोड़े गए
    • इस fix के बिना fork खुद non-AVX2 hardware पर build नहीं होता

  • runtime graph fallback

    • Dispatcher ठीक करने के बजाय graph builder को बदलकर ऐसा किया गया कि वह उस build में पहले से calculation path वाले operations बनाए
    • ggml_moe_up_gate में GGML_USE_IQK_MULMAT बंद होने पर combined up_gate_exps weights handle किए गए
    • Tensor shape [n_embd, 2*n_ff, n_experts] है, जिसमें पहला आधा gate और दूसरा आधा up है
    • इसे दो ggml_view_3d slices से अलग किया गया
    • हर slice पर ggml_mul_mat_id चलाया गया
    • ggml_fused_mul_unary(gate, up, SILU) से दोनों results combine किए गए
    • अगर gate और up weights पहले से अलग हैं, तो बिना slicing दो बार ggml_mul_mat_id और fused multiplication·unary operation इस्तेमाल किया गया
    • non-MoE layers में इस्तेमाल होने वाले ggml_fused_up_gate पर भी वही fallback लागू किया गया
    • mul_mat_id default ggml implementation इस्तेमाल करता है और fused_mul_unary SILU और multiplication को एक साथ handle करता है, इसलिए सभी component operations के लिए non-IQK implementations पहले से मौजूद हैं
    • पूरा change #if !GGML_USE_IQK_MULMAT के पीछे है, इसलिए AVX2 build output पहले जैसा bit-level identical है

  • CI stubs cleanup

    • IQK source के #else stubs iqk_mul_mat.h से अलग थे, इसलिए non-AVX2 hardware पर ci/run.sh भी build नहीं होता था
    • <cstdint> include गायब था
    • कुछ stubs में unnecessary leading parameters थे या sinks parameter गायब था, यानी signatures अलग थे
    • कुछ functions के stubs ही नहीं थे, जिससे link stage में undefined references आते थे
    • Stubs को header से match कराने पर non-AVX2 environment में भी test suite चलाना संभव हुआ

fallback की performance cost और repacking bug

  • Fallback एक fused kernel की बजाय दो बार mul_mat_id चलाता है, इसलिए extra cost आती है
  • यह CPU पहले से ही memory bandwidth constrained है और original fused kernel भी AVX2-only था, इसलिए इस environment में छोड़ने लायक कोई existing execution path नहीं था
  • Final performance 26B-A4B MoE पर decoding लगभग 5.2 टोकन/सेकंड और prompt evaluation लगभग 16 टोकन/सेकंड है
  • --run-time-repack startup के समय quantized weights को AVX2-only interleaved format Q8_0_R8 में rearrange करता है
    • AVX1 environment में output को फिर से corrupt करने वाला यह अलग bug है
    • Current patch इसे fix नहीं करता और execution script से यह flag हटा दिया गया

कारण narrow करने की प्रक्रिया

  • Instruction set mismatch आसानी से confirm हो गया, लेकिन dispatcher का बिना error दिए default branch में गिरना खोजना मुश्किल था
  • Code review से कई candidates हटाए गए
    • RMSNorm helper सही दिखा
    • ggml_vec_dot_q8_0_q8_0 का AVX1 fallback भी सही दिखा
    • Single-thread result bit-level identical था, इसलिए threading bug rule out किया गया
  • Logit mean +16 पर fixed था और long-tail tokens के values similar थे, इससे माना गया कि residual stream का बड़ा हिस्सा uninitialized था
  • Dispatcher में #if GGML_USE_IQK_MULMAT खोजने के बाद करीब 1 minute में दो missing operation paths मिल गए

reproducibility conditions और usage scope

  • AVX2 से पहले के hardware पर reproduction conditions ये हैं
    • Hardware: dual Xeon E5-2690 v2, Ivy Bridge, AVX1, DDR3, कोई GPU नहीं
    • Build: patched branch का ik_llama.cpp GGML_USE_IQK_MULMAT के बिना compile करें
    • Model: Gemma 4 26B-A4B Q8_0
    • Run: सामान्य ik_llama.cpp CPU flags इस्तेमाल करें, लेकिन --run-time-repack छोड़ दें
  • Exact changes ikawrakow/ik_llama.cpp PR #2138 में देखे जा सकते हैं
    • लिखते समय यह अभी open है और maintainer review का इंतजार कर रहा है, इसलिए branch से direct run करना होगा
    • उसी hardware पर आने वाले bugs PR thread में report किए जा सकते हैं
  • पुराने enterprise server पर local model रखने से paid API बंद होने पर fallback के रूप में इस्तेमाल किया जा सकता है, या token-based pricing जहाँ fit नहीं बैठती, ऐसे slow batch jobs process किए जा सकते हैं
  • Subscription service इस्तेमाल करने से ज्यादा unfamiliar code और पुराने systems में खुद गहराई से जाने की क्षमता को महत्व दिया गया है, और यही तरीका 15 साल पुराने Rails application या owner के जा चुके database को maintain करने के काम पर भी लागू होता है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • अनुमान है कि 2027 के मध्य तक 200B+ Mixture-of-Experts (MoE) models आम consumer hardware पर चलाए जा सकेंगे
    16GB Mac पर Qwen3.6-35B-A3B को लोकल चला रहा हूँ और लगभग 7–9 tokens प्रति सेकंड मिल रहे हैं: https://github.com/deepanwadhwa/samosa-chat
    यानी 16GB RAM वाले MacBook Air पर GPT-4-स्तर का मॉडल इस तरह की स्पीड पर लोकल चल रहा है

    • शायद तब तक इंतज़ार करने की भी ज़रूरत नहीं होगी। Prism ने कुछ दिन पहले ternary weight model Bonsai 27B जारी किया है, जो लगभग 7GB का है और M4 Max laptop पर 44 tokens प्रति सेकंड से ज़्यादा देता है: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit
      यह पहले से ही ज़्यादातर 200B+ models के active parameter count जैसी रेंज में है, इसलिए अगर Prism चाहे तो ऐसा मॉडल ला सकता है। हालांकि HRM जैसे recursive neural networks को उतने parameters की ज़रूरत नहीं होती, इसलिए सच में इतनी scale चाहिए भी या नहीं, इस पर बहस हो सकती है: https://huggingface.co/sapientinc/HRM-Text-1B
    • 7–9 tokens प्रति सेकंड को अच्छी स्पीड कहना मुश्किल है। मैं expert नहीं हूँ, लेकिन लोकल पर प्रयोग करके देखा तो 12–16 tokens प्रति सेकंड से कम पर काम काफ़ी सुस्त लगा
    • अनुमान से मोटे तौर पर सहमत हूँ, लेकिन समय थोड़ा और आगे खिसक सकता है। ऐसी प्रगति के लिए मौजूदा तरह से parameter प्रति bit घटाने के बजाय बिल्कुल अलग तरह की compression चाहिए होगी, इसलिए उस स्थिति में parameter count जैसा metric शायद मायने ही न रखे
      उदाहरण के लिए, अगर हर layer में सिर्फ एक 256-bit seed रखा जाए और उसे noise function में डालकर 16K असली weights बनाए जाएँ, तो एक weight की storage लागत 1 bit से भी कम हो सकती है
    • Ornith 35B को Pi पर चलाकर 50+ tokens प्रति सेकंड मिल रहे हैं। जब से पता चला कि Pi search और fetching भी सपोर्ट करता है, उसके बाद search के लिए बड़े model की ज़रूरत ही नहीं रही
      लगता है इस महीने और अगले महीने लगातार ऐसे नए models आएँगे जो पूरी तस्वीर बदल देंगे। Ornith ज़रूर आज़माने लायक है
    • 9 tokens प्रति सेकंड पर काम करना मुश्किल नहीं होगा क्या? Claude session में एक दिन से कम में 1 million tokens खर्च हो जाना आम बात है, इसलिए असली काम के लिए यह बहुत धीमा लगता है

  • कुछ लोगों को यह सुनना पसंद नहीं आएगा, लेकिन inference providers की token cost, लोकल रन की बिजली लागत से सस्ती लगती है
    सरलता के लिए सिर्फ output generation देखें तो 5 tokens प्रति सेकंड का मतलब 18,000 tokens प्रति घंटा है, और provider cost लगभग $0.005 होती है। अगर मानें कि server inference के दौरान लगभग 500W खपत करता है और Germany जैसी जगह में बिजली दर $0.3 प्रति kWh है, तो वही मात्रा लोकल पर बनाने में $0.15 लगेंगे, यानी 30 गुना महंगा
    अगर privacy चिंता है तो लोकल रन अब भी अच्छा विकल्प है, लेकिन यह समझना चाहिए कि यह inference providers से काफ़ी कम efficient है। नए GPUs inference efficiency बढ़ाएँगे, इसलिए यह अंतर और बड़ा होगा
    पहले मैंने गलती से 180,000 tokens गिन लिए थे, लेकिन सही संख्या 18,000 tokens है, इसलिए जब तक बिजली लगभग मुफ़्त न हो, प्रतिस्पर्धा मुश्किल है। Providers भी अभी छोटे models के लिए H200/H100 इस्तेमाल कर रहे होंगे, लेकिन GB300 या अगले साल के Ruby GPU पर जाने के बाद inference cost 1/30 रह सकती है, और तब लोकल models की मुख्य वैल्यू privacy होगी

    • घर पर Qwen 27B चलाने पर काम के दौरान लगभग 400W खपत होती है, generation लगभग 40 tokens प्रति सेकंड है, और उससे भी ज़्यादा महत्वपूर्ण prompt processing लगभग 1,000 tokens प्रति सेकंड है
      एक घंटे में 3.6 million input tokens process किए जा सकते हैं या 144,000 tokens generate किए जा सकते हैं, और बिजली लागत लगभग $0.15 होती है। Sonnet पर यही मात्रा करने पर input के लिए $7.2 और generation के लिए $1.4 लगते हैं, इसलिए cloud generation में 10 गुना और processing में लगभग 50 गुना महंगा है
    • अमेरिका में बिजली दर kWh पर $0.30 के आसपास भी नहीं पहुँचती। कम usage वाले समय में यह उसका आधा होती है, और battery पर $1,000 खर्च करके super off-peak समय की $0.11 वाली बिजली स्टोर भी की जा सकती है
      inference providers बहुत बड़ा कर्ज़ लेकर market share की लड़ाई लड़ रहे हैं, इसलिए कीमतें निश्चित रूप से बढ़ेंगी
    • solar और battery से चलने वाला off-grid self-hosted LLM server बनाना शानदार होगा। Low Tech Magazine की तरह, धूप कम हो तो यह offline हो जाए, और friends group, street, club जैसी local communities की रोज़मर्रा की ज़रूरतों के हिसाब से इसे बनाया जाए
      अगर AI को इतना democratize किया जाए कि समुदाय खुद उसे नियंत्रित कर सके, तो datacenter की समस्या भी हल हो सकती है, और censorship व alignment का स्तर भी समुदाय लोकतांत्रिक तरीके से तय कर सकता है। यह Geohotz की कुछ बातों जैसी कल्पना है
      open source models जल्द ही इतने अच्छे और efficient हो जाएँगे कि second-hand hardware पर सस्ते में सेवा दी जा सके। हर छोटे समुदाय में अगर एक तकनीक-समझ रखने वाला व्यक्ति कुछ सौ डॉलर की शुरुआती लागत जुटा ले, तो उसके बाद यह लगभग बिना बिजली लागत के चल सकता है
      https://solar.lowtechmagazine.com/
    • efficiency महत्वपूर्ण है, लेकिन बहुत से लोगों के पास सस्ती बिजली या efficient equipment भी है। AMD Strix Halo home server पर सिर्फ 100W इस्तेमाल करते हुए Gemma4-26B को लगभग 70 tokens प्रति सेकंड पर दिया जा सकता है
    • मुझे परवाह नहीं कि इसकी लागत ज़्यादा है या नहीं। लोकल चलाने का कारण पैसे बचाना नहीं, बल्कि स्वतंत्रता और privacy पाना है, और अगर विकल्प मौजूद रहे तो लंबी अवधि में लागत भी कम रहती है
      अगर लोकल जैसा विकल्प न हो, तो cloud models की कीमतें कहीं ज़्यादा होतीं

  • इस पीढ़ी के dual Xeon पर लोड पड़ने पर 300W से ज़्यादा बिजली खपत होने की संभावना है। अमेरिका की औसत बिजली दर पर यह लगभग 1.35 डॉलर प्रतिदिन बैठता है, और अगर गर्मियों में कमरे को ठंडा भी रखना पड़े तो लागत और बढ़ेगी
    prompt processing समय को नज़रअंदाज़ करके 24 घंटे चलाने पर भी दिन में लगभग 4 लाख tokens ही बनते हैं, इसलिए 10 लाख output tokens पर लागत लगभग 0.30 डॉलर पड़ती है। संयोग से यह अभी OpenRouter पर इस मॉडल की कीमत के बराबर है, लेकिन OpenRouter की generation speed 8 गुना तेज़ है
    डेटा को घर के बाहर न जाने देने जैसे कई कारण हैं जिनकी वजह से local LLM के साथ प्रयोग किया जा सकता है, लेकिन पैसों के हिसाब से फ़ायदा निकालना मुश्किल है। घर में local inference hardware पर इससे कहीं ज़्यादा पैसा लगाने के अनुभव से कहूँ तो यह मज़ेदार ज़रूर है, पर बचत का साधन नहीं

    • जो लोग वास्तव में अपने घर में रहते हैं, उनके लिए यह तर्कसंगत हिसाब है। मैं किराए के घर में रहता हूँ और बिजली का बिल सीधे नहीं भरता, इसलिए जिस बिंदु पर मकान मालिक शिकायत करना शुरू करे वही cost efficiency की सीमा है
    • मेरा मानना है कि ज़्यादातर लोग पैसे बचाने के लिए मॉडल को local पर नहीं चलाते, बल्कि privacy फैलने से रोकने के लिए ऐसा करते हैं
    • यह crypto जैसा है। बिजली के बिल की वजह से ज़्यादातर लोगों के लिए खुद mining करने से सीधे खरीदना सस्ता पड़ता है
    • ठंड के मौसम में जब घर पर हीटिंग चलानी पड़ती है, तब waste heat का उपयोग भी किया जा सकता है, इसलिए आर्थिकता कुछ बेहतर हो जाती है

  • GPU के बिना dual Xeon और DDR4 256GB पर कई मॉडलों को चलाने के नतीजे यहाँ संकलित किए गए हैं
    https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5822c7

    • जानना चाहूँगा कि NUMA performance penalty हटाने के लिए क्या सिर्फ एक CPU इस्तेमाल करके देखा गया। तब memory आधी ही इस्तेमाल होगी, लेकिन performance में कितना फ़र्क पड़ता है यह जानना दिलचस्प होगा
    • लगता है कि बहुत ज़्यादा, भले ही धीमी, RAM होने पर छोटे मॉडल भी काफ़ी तेज़ चलते हैं। इस हार्डवेयर पर और बड़े मॉडल कैसे काम करेंगे, यह जानने की उत्सुकता है

  • यह काफ़ी धीमा लगता है। 13 साल पुराने CPU पर भी 8~12 tokens प्रति सेकंड मिल रहे हैं, हालाँकि यह context size और दूसरी settings पर निर्भर कर सकता है
    https://news.ycombinator.com/item?id=48354801

    • Xeon E3-1270 V2 3.50GHz और पुरानी Nvidia Quadro K2200 4GB पर भी 8~9 tokens प्रति सेकंड मिल रहे हैं। Ollama में gemma4:e2b और gemma4:12b-it-qat चला रहा हूँ
    • क्या मूल पोस्ट में Q8 quantization और यहाँ Q4 इस्तेमाल होने का फ़र्क नहीं है?

  • मैं मूल पोस्ट का लेखक हूँ। लगता है कि मेरी पिछली टिप्पणी किसी वजह से flag हो गई थी। सुधारों को ऊपर की परियोजना में PR #2138 के रूप में खोला है: https://github.com/ikawrakow/ik_llama.cpp/pull/2138

  • इस StoreVirtual हार्डवेयर में सॉफ़्टवेयर इंस्टॉल करने लायक कोई पोर्ट नहीं दिखता। बस USB ports जैसे कुछ दिख रहे हैं, तो क्या इंस्टॉलेशन serial console के ज़रिए किया जाता है?

  • इसी कॉन्फ़िगरेशन के साथ 2013 Mac Pro पर Gemma 4 26B चला रहा हूँ और लगभग 5 tokens प्रति सेकंड मिल रहे हैं। dual graphics cards यहाँ किसी काम के नहीं हैं, लेकिन कुछ workloads के लिए यह फिर भी काफ़ी उपयोगी है

    • पिछले हफ्ते मैंने impulse में eBay से cylinder Mac Pro 120 डॉलर में खरीद लिया, और बाद में पता चला कि हाल में लोग इसके built-in GPU पर मॉडल को 20~30 tokens प्रति सेकंड की रफ़्तार से चलाने लगे हैं
      अगर यह शुक्रवार को पहुँच गया तो मैं खुद इसे टेस्ट करने वाला हूँ, इसलिए काफ़ी उत्साहित हूँ
      https://echalupa.com/blog/mac-pro-6-1-llama-cpp-firepro-d300-vulkan-ubuntu
      https://matthewgribben.com/blog/mac-pro-6-1-llama-cpp-firepro-d700-vulkan-ubuntu
    • इतनी धीमी रफ़्तार पर यह किन कामों में उपयोगी होता है, यह जानना चाहूँगा

  • मैंने खुद बेसमेंट में लगा यह सेटअप देखा है, और यह वाकई शानदार है। अगली बार 3D printer भी दिखाइए तो अच्छा रहेगा

  • थोड़ा संबंधित एक वीडियो भी है, जिसमें Pentium 4 पर LLM चलाया गया है और उसे NetburstGPT उपनाम दिया गया है। बेशक, यह बहुत धीमा है
    https://www.youtube.com/watch?v=ILV-eu90te8