bmodel

5 ms·

1.
by bmodel 2y ago
We haven't tested it with hashcat yet but plan on doing so. If you get to it before us please let us know how it works!
2.
by bmodel 2y ago
I don't believe Nitro would allow you to access a GPU that's not directly connected to the CPU that the VM is running on. So swapping between GPU type or scaling to multiple GPUs is still a problem. From the developer perspective,
3.
by bmodel 2y ago
That understanding of the system is correct. To make it practical we've implemented a bunch of optimizations to minimize I/O cost. You can see how it performs on inference with BERT here: https://youtu.be/qsOBFQZts
4.
by bmodel 2y ago
Oh nice, I didn't know that! In that case it might work, you could try running `tnr run ./blender` (replace the ./blender with how you'd launch blender from the CLI) to see what happens. We haven't tested it so I ca
5.
by bmodel 2y ago
Awesome, we'd love to chat! You can reach us at founders@thundercompute.com or join the discord https://discord.gg/nwuETS9jJK !
6.
by bmodel 2y ago
At the moment out tech is linux-only so it would not work with Blender. Down the line, we could see this being used for batched render jobs (i.e. to replace a render farm).
7.
by bmodel 2y ago
We kill the process to reset the GPU. Since we only store GPU state that's the only clean up we need to do
8.
by bmodel 2y ago
We have tested this with pytorch and huggingface and it is mostly stable (we know there are issues with pycuda and jax). In theory this should work with any libraries, however we're still actively developing this so bugs will show up
9.
by bmodel 2y ago
We intercept api calls and use our own implementation to forward them to a remote machine. No eBPF (which I believe need to run in the kernel). As for latency, we've done a lot of work to minimize that as much as possible. You can see
10.
by bmodel 2y ago
We're still in our beta so it's entirely free for now (we can't promise a bug-free experience)! You have to make an account but it won't require payment details. Down the line we want to move to a pay-as-you-go model.
11.
by bmodel 2y ago
We haven't tested with MIG or vGPU, but I think it would work since it's essentially physically partitioning the GPU. One of our main goals for the near future is to allow GPU sharing. This would be better than MIG or vGPU since w
12.
by bmodel 2y ago
Exactly! The finer grain sharing is one of the key things on our radar right now
13.
by bmodel 2y ago
Great point, there are a few benefits: 1. If you're actively developing and need a GPU then you typically would be paying the entire time the instance is running. Using Thunder means you only pay for the GPU while actively using it. Es
14.
by bmodel 2y ago
We are not writing any kernel drivers, this runs entirely in userspace (this won't result in a crowdstrike level crash haha). Given that, if the network suddenly dropped then only the process using the GPU would fail.
15.
by bmodel 2y ago
Thank you! > is this a remote nvapi Essentially yes! Just to be clear, this covers the entire GPU not just the NVAPI (i.e. all of cuda). This functions like you have the physical card directly plugged into the machine. Right now we don&#
16.
by bmodel 2y ago
Great questions! To clarify the demo, we were ssh'd into a linux machine with no GPU. Going into more details for how this works, we intercept communication between the CPU and the GPU so only GPU code and commands are sent across the
17.
Show HN: Attaching to a virtual GPU over TCP(thundercompute.com)
344 points by bmodel 2y ago|108 comments
18.
by bmodel 2y ago
Essentially yes. The difference would be that we measure "what you use" more granularly since you'll only be charged while something is being run on the GPU, not the entire time the instance is running. This is where the &quo