Bypassing CPU for NVMe-to-GPU transfer is clever. The bottleneck for running large models locally has always been the memory hierarchy — this essentially treats NVMe as extended VRAM with direct DMA.<p>I wonder how this compares to Apple's unified memory approach on M-series chips for similar workloads. The M4 Max can fit 70B models entirely in memory without any offloading tricks, though at lower throughput than a 3090.<p>Would be interesting to see comparative benchmarks: this NVMe approach on a 3090 vs M4 Max native, especially for batch inference where the NVMe latency might be amortized.
Yeah, GPUdirect should allow you to dma straight to a storage device.<p>I wonder... what if the m.2 storage was actually DRAM? You probably don't need persistence for spilling a model off the GPU. How would it fare vs just adding more host memory? The m.2 ram would be less flexible, but would keep the system ram free for the CPU.
Yeah a ramdisk would probably work wonders. It's a shame Intel optane didn't became a standard, those type of workflows would be amazing for it.
Ya know, here on the local market there are a bunch of optanes hanging around, I'll try to manage one to check if there's any improvement
Ahhh damn it. Intel! Come back!
This is exactly what I was wondering<p>I gave a talk a few years ago at dask summit (conf?) on making the stars align with dask-cudf here. We were helping a customer accelerate log analytics by proving out our stack for nodes that look roughly like: parallel ssd storage arrays (30 x 3 GB/s?) -> GPUDirect Storage -> 4 x 30 GB/s PCIe (?) -> 8 x A100 GPUs, something like that. It'd be cool to see the same thing now in the LLM world, such as a multi-GPU MoE, or even a single-GPU one for that matter!
Isn't m.2 storage but DRAM - hopefully, meaning NVMe/PCIe not SATA speed - already exists as Compute Express Link (CXL), just not in this specific m.2 form factor? If only RAM wasn't silly expensive right now, one could use 31GB/s of additional bandwidth per NVMe connector.
0.2 tok/s is slow for chat but perfectly fine for batch/async workloads. I run automated content generation pipelines where a single job kicks off dozens of LLM calls (script generation, metadata, descriptions) and none of them need to be interactive. The whole job takes 20 minutes anyway because of image generation bottlenecks. Being able to run a 70B model locally for those batch calls instead of paying per-token API costs would be a significant cost reduction, even at this speed.
Cost wise it does not seem very effective. .5 token / sec (the optimized one) is 3600 tokens an hour, which costs about 200-300 watts for an active 3090+system. Running 3600 tokens on open router @.4$ for llama 3.1 (3.3 costs less), is about $0,00144. That money buys you about 2-3 watts (in the Netherlands).<p>Great achievement for privacy inference nonetheless.
I think we use different units. In my system there are 3600 seconds per hour, and watts measure power.
Open router is highly subsidized. This might be cheaper in the long run once these companies shift to taking profits
Something to consider is that input tokens have a cost too. They are typically processed much faster than output tokens. If you have long conversations then input tokens will end up being a significant part of the cost.<p>It probably won't matter much here though.
> Cost wise it does not seem very effective.<p>Why is this so damn important? Isn't it more important to end up with the best result?<p>I (in Norway) use a homelab with Ollama to generate a report every morning. It's slow, but it runs between 5-6 am, energy prices are at a low, and it doesn't matter if it takes 5 or 50 minutes.
Are you taking into account energy costs of running a 3090 at 350 watts for a very long time?
0.2 tok/s is fine for experimentation, but it is not interactive in any meaningful sense. For many use cases, a well-quantized 8B or 13B that stays resident will simply deliver a better latency-quality tradeoff
yeah, actually I wanted to see if this was possible at all. I managed to get around 3000 tokens/s on a ps2 with classic transformers, since the emotion engine is capable of 32 bit addresses, but it has like 32gb of ram. So I ran into the question of why was that fast and I couldn't get that speed even with small models, and the deal is that the instructions went right of the memory to the gpu and that's the main difference that does when a regular computer does inference: it has to request the instructions to the cpu every time. As I mentioned too, on professional cards you can avoid these problems naturally, since they got instructions precisely for this, but sadly I don't have 30k bucks to spare on a gpu :(
*32MB of RAM (plus 4MB of video RAM and a little sound and IOP memory).
> I don't have 30k bucks to spare on a gpu :(<p>Do you have $2/hr to rent an RTX 6000 96GB or $5/hr for B200 180GB on the cloud?
I thought about that, but idk if they allow me to modify the linux kernel and nvidia cuda kernel at all
I'd rather not give money to scalper barons if I can avoid it. Fab capacity is going to that for rental rather than hardware for humans.
3000 tokens per sec on 32 mb Ram?
I can imagine a couple scenarios in which a high-quality, large model would be much preferred over lower latency models, primarily when you need the quality.
That's slower than just running it off CPU+GPU. I can easily hit 1.5 tokens/s on a 7950X+3090 and a 20480-token context.
I didn't really understand the performance table until I saw the top ones were 8B models.<p>But 5 seconds / token is quite slow yeah. I guess this is for low ram machines? I'm pretty sure my 5950x with 128 gb ram can run this faster on the CPU with some layers / prefill on the 3060 gpu I have.<p>I also see that they claim the process is compute bound at 2 seconds/token, but that doesn't seem correct with a 3090?
Really interesting experiment i should have done this before
Do you have numbers on effective throughput vs PCIe theoretical bandwidth?
I’m curious whether this is primarily latency-bound or bandwidth-bound in practice
Can some tell me??
Actually is purely bandwidth-bound, the major bottleneck of the whole process, for me in this case, is the B450 mobo I got that's only capable of pcie3 and 1x8 in the pcie lanes for gpu instead of 1x16; so I'm capped until I get an X570 maybe. I should get around twice or triple the tok speed with that upgrade alone
Cool hack but 0.5 tok/s on 70B when a 7B does 30+ on the same card. NVIDIA's own research says 40-70% of agentic tasks could run on sub-10B models and the quality gap has closed fast.
This is an interesting area for experiments. I suspect that in the longer term model optimization (knowing which bits you can leave out without affecting the functioning of the model) will become the dominant area of research just like it did with compression algorithms because effectively a model <i>is</i> a lossy compression scheme.<p>And that's good because that increases democratization of AI away from the silos that are being created.
Really cool. I'm wondering: what background did you need to be able to think of the question that resulted in this project?<p>I know you said you're involved in some retrogaming and were experimenting, but as someone who works in a world where hardware is pretty heavily abstracted away, even if I got into retrogaming I don't know that I'd consider that there may be a systems improvement lying around. Beyond the creative aspect, it feels like there is some systems and hardware background that helped put the idea together (and I'd be interested to go learn about of that systems/hardware knowledge myself).
This was the experiment itself <a href="https://github.com/xaskasdf/ps2-llm" rel="nofollow">https://github.com/xaskasdf/ps2-llm</a><p>The idea was basically to run a llm on a ps2, then I ran into some problems as the 32mb ram cap with 4mb vram cap; so I had to figure out a way to stream layers on the forward pass. Given that ps2 manages to give instructions directly to the vram that's capable of 32bit addresses, it gave an insane amount of tok/s, then I wondered if I could do the same on my puter
I wonder too, DMA plays a huge role in most older gaming consoles when the CPUs were far more sluggish.<p>Perhaps that's what made them think to try.<p>Perhaps the current batch of smart memory cards which on the PS2 I believe have quite complex DMA capabilities to stream from the SD card game data.
Nice. I've been looking at doing something similar, more on the order of running a 1T model with less than half the available VRAM.<p>One workup indicated it was theoretically possible to modify a piece of SGLang's routing layer to support JIT predict-ahead expert swaps from Gen5 NVMe storage straight into GPU memory.<p>I'm hoping that proves true. The setup relies on NVIDIA Dynamo, so NIXL primitives are available to support that.<p>Curious if anyone's tried this already.
Cool project. Can you provide more details about your DKMS patching process for consumer GPUs? This would be fun to try out, but I’d need some more details on that patch process first.
I updated the documentation to provide more info for the patching process, I added the patches themselves too and provided some risk info about the patches
the nvidia open source driver has been modded previously to unlock enterprise paywalled features like p2p gpu comms <a href="https://blog.chlc.cc/p/rtx4090-p2p-unlocked" rel="nofollow">https://blog.chlc.cc/p/rtx4090-p2p-unlocked</a> and vGPU splitting <a href="https://open-iov.org/index.php/VGPU_Unlock" rel="nofollow">https://open-iov.org/index.php/VGPU_Unlock</a>
Interesting. Can AMD GPUs do direct io like this?
I wonder - could this be used for multi-tier MoE? Eg. active + most used in VRAM, often used in RAM and less used in NVMe?
Didn't DirectX add an API for loading assets directly to GPU memory? Would that work?
My impression is that that is limited to assets and really needs to fit into the DirectX framework. From what I can tell, the gpu-nvme-direct is mostly similar to <a href="https://github.com/enfiskutensykkel/ssd-gpu-dma" rel="nofollow">https://github.com/enfiskutensykkel/ssd-gpu-dma</a> and <a href="https://github.com/ZaidQureshi/bam" rel="nofollow">https://github.com/ZaidQureshi/bam</a>
I feel like we need an entirely new type of silicon for LLMs. Something completely focused on bandwidth and storage probably at the sacrifice of raw computation power.
Something like this? (Llama 3.1-8B etched into custom silicon delivering 16,000 tok/s, doesn't use much PCIe bandwidth):<p>- <a href="https://taalas.com/the-path-to-ubiquitous-ai/" rel="nofollow">https://taalas.com/the-path-to-ubiquitous-ai/</a>
- <a href="https://chatjimmy.ai/" rel="nofollow">https://chatjimmy.ai/</a>
I've often wondered doing this with extreme compression. What if you did extreme compression + decompression on the GPU? Because you're leaving a lot of compute unused.
I did it, but with different quantization compressions, It ran into quality issues, I will try to rerun with the same quants if that fixes the issue, but the most that looks unused, its being used by rotating layers that are being swapped by the cpu from the ram itself, that manages to keep layers warm, ready to use while inferencing and discarding already used ones
I'm not sure, but I suspect that LLM weights don't compress all that well. The intuition here is that training an LLM <i>is</i> compression of the training data into the weights, so they are probably very information dense already. Can't squeeze them down much.
Isn't that linux DMA buf?
Umm sorry but the cpu can easily keep up shuttling around to/from your nvme. Especially ancient gen3 pcie. Not sure why ud do this.
Could be neat to see what giving the 8b like 6gb ram instead of 10gb. Something in-between, where you still need NVMe, but not like the 3x ratio of the 70b model on 23GB.<p>Nice work. PCI-P2P (GPU-Direct (tm)) is such great stuff. Cool to see!
[dead]
[dead]
[flagged]
[flagged]
> No cuBLAS means they wrote their own GEMM kernels, which is a massive undertaking<p>Not to diminish the impressiveness of this overall project, but it says right up front that these were vibe coded and the Opus 4.6 co-author lines are right in the commit messages. Those pieces were adapted from existing work via LLM, which is exactly the right use in a proof of concept project like this.
Please don't use LLMs to post on HN...