15 पॉइंट द्वारा GN⁺ 2026-02-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • C++/CUDA-आधारित LLM inference engine, जो GPU memory streaming और direct NVMe I/O के जरिए Llama 70B model को RTX 3090(24GB VRAM) पर चलाने में सक्षम बनाता है
  • 3-स्तरीय adaptive caching structure का उपयोग करके VRAM, pinned RAM और NVMe/mmap को अपने आप विभाजित करता है, और mmap की तुलना में अधिकतम 83 गुना speedup हासिल करता है
  • gpu-nvme-direct backend CPU को पूरी तरह bypass करके NVMe से GPU तक सीधे data transfer करता है, जिससे PCIe bandwidth का अधिकतम उपयोग होता है
  • Layer skip और self-speculative decoding फीचर अनावश्यक computation को घटाते हैं और quality loss के बिना processing speed बढ़ाते हैं
  • यह consumer hardware पर भी बहुत बड़े models को कुशलता से चलाने में मदद करता है, जिससे high-performance LLM inference की accessibility बढ़ाने की संभावना दिखती है

NTransformer अवलोकन

  • यह उच्च-दक्षता वाला C++/CUDA LLM inference engine है, जो RTX 3090(24GB VRAM) पर Llama 70B model चलाता है
    • यह GPU memory के जरिए model layers को stream करता है, और वैकल्पिक रूप से direct NVMe I/O का उपयोग कर CPU को पूरी तरह bypass करता है
  • CUDA Toolkit के अलावा कोई external dependency नहीं, PyTorch या cuBLAS की जरूरत नहीं
  • GGUF model format को support करता है, और Q4_0, Q8_0, Q4_K_M, Q5_K, Q6_K, F16, F32 quantization formats का उपयोग किया जा सकता है

प्रदर्शन और caching structure

  • 3-स्तरीय adaptive caching(3-Tier Adaptive Caching)
    • VRAM-resident layers (0 I/O)
    • pinned RAM (केवल H2D transfer के लिए)
    • NVMe/mmap fallback
  • RTX 3090 + 48GB RAM environment में mmap की तुलना में 83 गुना speedup
  • PCIe Gen3 x8 bandwidth(लगभग 6.5 GB/s) bottleneck के रूप में काम करती है
  • Q4_K_M quantization VRAM में 10 अतिरिक्त layers (36 vs 26) लोड कर transfer volume को कम करती है
  • Layer skip (cosine similarity-आधारित) के जरिए 80 में से 20 layers को छोड़ा जाता है, जबकि quality loss न्यूनतम रहता है

मुख्य फीचर

  • SLEP streaming: NVMe read, PCIe DMA और GPU computation को double buffer के साथ overlap करके process करता है
  • gpu-nvme-direct backend: NVMe data को सीधे GPU-accessible pinned memory में पढ़ता है
  • Self-speculative decoding: VRAM-resident layers को draft model की तरह उपयोग करता है, इसलिए अतिरिक्त model की जरूरत नहीं
  • Automatic data path selection: VRAM-resident > pinned RAM H2D > mmap pinned > CPU memcpy
  • Llama architecture support: RoPE, GQA, SwiGLU, RMSNorm, KV cache शामिल

सिस्टम आवश्यकताएँ

  • Linux (Ubuntu, kernel 6.17+), CUDA Toolkit 13.1, gcc/g++ 14, CMake 3.24+
  • Compute Capability 8.0+ GPU (RTX 3090 पर परीक्षण किया गया)
  • direct NVMe I/O उपयोग के लिए अलग PCIe slot में NVMe SSD और gpu-nvme-direct library आवश्यक

Direct NVMe streaming

  • यदि model VRAM में फिट नहीं होता, तो NVMe → GPU direct path के जरिए CPU को पूरी तरह बाहर रखा जाता है
    • data flow: NVMe SSD → DMA → pinned staging memory → PCIe H2D → GPU buffer → computation
  • NVMe को VFIO से bind करके user space से सीधे access किया जाता है
  • प्रत्येक layer (70B Q6_K के आधार पर लगभग 670MB) को लगभग 202ms में 670 NVMe commands के जरिए पढ़ा जाता है
  • NVMe read, H2D DMA और GPU computation को double-buffer pipeline में parallel process किया जाता है

सिस्टम सेटअप और जोखिम चेतावनी

  • auto-setup script(setup_system.sh) GRUB, NVIDIA DKMS, CUDA headers, VFIO, NVMe binding को क्रमवार configure करती है
  • इसमें IOMMU disable करना, kernel module patching, NVMe VFIO binding जैसे high-risk tasks शामिल हैं
  • गलत configuration से boot failure, NVMe data loss, system instability हो सकती है
  • boot drive का कभी उपयोग न करें, अलग dedicated NVMe device आवश्यक है
  • सभी बदलावों के लिए backup और restore scripts उपलब्ध हैं

आर्किटेक्चर और code structure

  • src/ directory के मुख्य components
    • core/: tensor, memory allocation, GPU device management
    • cuda/: GEMV, RMSNorm, RoPE, SwiGLU, softmax kernels
    • memory/: NVMe और mmap-आधारित SLEP streaming engine
    • model/: Transformer components, GGUF loader, attention, FFN, normalization
    • inference/: tokenizer, sampler, engine
  • scripts/: system setup, NVMe binding और restore scripts शामिल

विकास चरण roadmap

  • चरण 1: Llama 8B Q8_0, custom CUDA kernels, 48.9 tok/s (पूर्ण)
  • चरण 2: SLEP streaming, single GPU पर 70B चलाना, 33 गुना speedup (पूर्ण)
  • चरण 3: Q4_K_M/Q5_K support, Layer skip, self-speculative decoding, F16 KV cache (पूर्ण)
  • चरण 4: NVMe Direct backend, GPU-driven NVMe reads 3.35 GB/s (पूर्ण)
  • चरण 5: inference optimization और public C API (निर्धारित)

लाइसेंस

  • BSD-2-Clause लाइसेंस लागू

1 टिप्पणियां

 
GN⁺ 2026-02-23
Hacker News की टिप्पणियाँ
  • मुझे लगता है कि CPU को बायपास करके NVMe से GPU में सीधे ट्रांसफर करने का तरीका सच में बहुत स्मार्ट है
    लोकल में बड़े मॉडल चलाते समय bottleneck हमेशा memory hierarchy रही है, और यह मानो NVMe को extended VRAM की तरह सीधे DMA से हैंडल करता है
    यह Apple M series के unified memory अप्रोच से कैसे तुलना करेगा, यह जानने की जिज्ञासा है। M4 Max 70B मॉडल को पूरी तरह मेमोरी में लोड कर सकता है, लेकिन throughput 3090 से कम है
    अगर NVMe अप्रोच वाले 3090 और M4 Max की native performance का batch inference के आधार पर benchmark हो, तो वह दिलचस्प होगा

    • मेरे पास M3 है, इसलिए मैं इसे Metal पर टेस्ट करने वाला हूँ
  • GPUdirect का उपयोग करके storage device तक सीधा DMA transfer किया जा सकता है
    मैंने सोचा कि अगर m.2 storage वास्तव में DRAM हो तो कैसा रहेगा। GPU पर मॉडल spill करते समय persistence की ज़रूरत नहीं होती, इसलिए system RAM को CPU के लिए छोड़ा जा सकता है

    • RAM disk इस्तेमाल करने पर शायद यह और बेहतर होगा। अफ़सोस है कि Intel Optane standard नहीं बन पाया। यह ऐसी workflow के लिए बिल्कुल सही तकनीक थी
    • मैंने भी यही सोचा था। पहले Dask Summit में मैंने dask-cudf पर एक talk दी थी, जहाँ parallel SSD array → GPUDirect Storage → PCIe → A100 GPU संरचना से log analysis तेज़ किया गया था। अब यही संरचना LLM या MoE मॉडल पर लागू करना मज़ेदार हो सकता है
    • दरअसल DRAM-आधारित m.2 storage पहले से CXL(Compute Express Link) के रूप में मौजूद है। लेकिन समस्या यह है कि RAM बहुत महंगी है, इसलिए प्रति NVMe connector 31GB/s bandwidth का उपयोग करना कठिन है
  • 0.2 token प्रति सेकंड की गति chat के लिए धीमी है, लेकिन batch/async कामों के लिए पर्याप्त है
    मैं automated content generation pipeline चलाता हूँ, जिसमें कई LLM calls एक साथ चलते हैं। image generation bottleneck है, इसलिए पूरा काम वैसे भी लगभग 20 मिनट लेता है
    अगर 70B मॉडल लोकल में चल सके, तो API token लागत बच सकती है और यह बड़ी cost saving होगी

    • cost के हिसाब से यह efficient नहीं है। 0.5 tok/s के हिसाब से एक घंटे में 3600 token बनते हैं, और 3090 सिस्टम 200~300W खपत करता है। उतने ही token OpenRouter पर llama 3.1 से चलाने पर बिजली बिल से कहीं सस्ते पड़ते हैं। फिर भी privacy inference के लिहाज़ से इसका महत्व है
    • 3090 को 350W पर लंबे समय तक चलाने की power cost भी ध्यान में रखनी चाहिए
  • 0.2 tok/s प्रयोग के लिए ठीक है, लेकिन interactive उपयोग के लिए काफ़ी नहीं है
    ज़्यादातर मामलों में, अच्छी तरह quantized 8B या 13B मॉडल latency-quality balance बेहतर देते हैं

    • मैं भी बस इसकी feasibility टेस्ट करना चाहता था। पहले मैंने PS2 पर classic transformer के साथ 3000 token प्रति सेकंड निकाले थे, और इसका कारण memory से GPU को सीधे command भेजने वाली संरचना था। सामान्य PC में CPU से होकर जाना पड़ता है, इसलिए वे धीमे हैं। pro GPU इस समस्या को हल करते हैं, लेकिन वे बहुत महंगे हैं
    • फिर भी कुछ स्थितियों में बड़े मॉडल की quality ज़्यादा महत्वपूर्ण हो सकती है
    • CPU+GPU कॉम्बिनेशन में चलाना ज़्यादा तेज़ है। मुझे 7950X+3090 सेटअप पर लगभग 1.5 tok/s मिलता है
    • performance table देखने के बाद ही मुझे समझ आया कि ऊपर की एंट्री 8B मॉडल की है। 5 सेकंड/टोकन बहुत धीमा है। मेरे 5950X+128GB RAM सिस्टम में CPU और 3060 GPU के साथ शायद इससे तेज़ प्रदर्शन मिले। यह दावा भी बहुत विश्वसनीय नहीं लगता कि 3090 पर 2 सेकंड/टोकन compute limit है
  • यह सच में बहुत दिलचस्प प्रयोग है। मुझे भी यह पहले करना चाहिए था
    PCIe की theoretical bandwidth के मुकाबले actual throughput कितना है, यह जानना चाहूँगा। समझना है कि यह latency की समस्या है या bandwidth की

    • वास्तव में यह bandwidth bottleneck है। मेरा B450 motherboard केवल PCIe3 x8 सपोर्ट करता है, इसलिए GPU सीमित हो रहा है। X570 में upgrade करने पर गति 2~3 गुना बढ़ सकती है
  • शानदार hack है, लेकिन 70B मॉडल पर 0.5 tok/s उसी कार्ड पर 7B मॉडल के 30+ tok/s के मुकाबले धीमा है
    NVIDIA के research के अनुसार 10B से छोटे मॉडल भी 40~70% agent tasks संभाल सकते हैं, और quality gap भी तेज़ी से घट रहा है

  • इस क्षेत्र में आगे प्रयोग करने की काफ़ी गुंजाइश है
    लंबे समय में मॉडल optimization, यानी मॉडल के उन हिस्सों को खोजने का शोध जिन्हें हटाने पर प्रदर्शन पर असर नहीं पड़ता, शायद मुख्य होगा। आखिरकार मॉडल भी एक तरह की lossy compression संरचना हैं। यह दिशा AI के लोकतंत्रीकरण में भी मदद कर सकती है

    • compression वाली उपमा दिलचस्प है। fine-tuning को भी इसी तरह देखा जा सकता है। उदाहरण के लिए, अगर 3B मॉडल को किसी खास task के लिए tune किया जाए, तो 70B मॉडल की generality की ज़रूरत नहीं रहेगी
  • यह सच में शानदार प्रोजेक्ट है। ऐसी सोच तक पहुँचने के लिए किस तरह की system/hardware background knowledge चाहिए, यह जानने की जिज्ञासा है
    मैं ऐसे माहौल में काम करता हूँ जहाँ hardware बहुत abstracted है, इसलिए इस तरह का approach सोच पाना मुश्किल है। सिर्फ creativity नहीं, system-level समझ भी चाहिए होगी

    • यही वह प्रयोग है: ps2-llm project
      PS2 पर LLM चलाने की कोशिश में RAM 32MB और VRAM 4MB की सीमा सामने आई, इसलिए layer streaming तरीका बनाया गया। PS2 में VRAM सीधे 32-bit address प्रोसेस कर सकता था, इसलिए यह बहुत तेज़ था, और उसी को PC पर दोहराने की कोशिश की गई
    • मैं भी ऐसा ही सोचता हूँ। पुराने console में CPU धीमा होता था, इसलिए DMA transfer मुख्य था। शायद वही अनुभव इस तरह के आइडिया तक ले गया होगा। PS2 का smart memory card भी DMA फीचर के मामले में काफ़ी जटिल था
  • मैं भी कुछ ऐसा ही आज़मा रहा हूँ। VRAM के आधे से कम में 1T मॉडल चलाने का प्रयोग कर रहा हूँ
    लगता है SGLang की routing layer को बदलकर Gen5 NVMe से GPU memory तक JIT prediction-आधारित expert swap लागू किया जा सकता है। NVIDIA Dynamo और NIXL primitives का उपयोग होगा
    जानना चाहता हूँ कि क्या किसी ने यह पहले आज़माया है

    • मैं भी वह देखना चाहूँगा। एक और 3090 खरीदने और PCIe3 bottleneck दूर करने के लिए motherboard upgrade पर विचार कर रहा हूँ। शायद glm 4.7~5 को q4_k_m पर चला सकूँ
  • शानदार प्रोजेक्ट है। सामान्य GPU पर DKMS patch process के बारे में थोड़ा और विस्तार से जानना चाहता हूँ। मैं भी इसे आज़माना चाहूँगा

    • मैंने docs अपडेट करके patch process और risk information जोड़ दी है
    • NVIDIA open source driver को modify करके P2P GPU communication या vGPU partitioning जैसी enterprise features unlock करने के उदाहरण भी रहे हैं
      संबंधित लिंक: RTX4090 P2P Unlock, vGPU Unlock