Viewing profile — bmodel
bmodel
HN member- Joined
- Fri, Apr 19, 2024, 1:49 PM UTC
- HN karma
- 166
- Public activity
- 18 items
- HN profile
- View on Hacker News ↗
About bmodel
No profile information was provided.
Recent public activity
-
comment
Comment #41213115
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!
-
comment
Comment #41205381
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 i…
-
comment
Comment #41204835
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 BER…
-
comment
Comment #41204402
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 ha…
-
comment
Comment #41204326
Awesome, we'd love to chat! You can reach us at founders@thundercompute.com or join the discord https://discord.gg/nwuETS9jJK !
-
comment
Comment #41204248
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).
-
comment
Comment #41204227
We kill the process to reset the GPU. Since we only store GPU state that's the only clean up we need to do
-
comment
Comment #41204179
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'r…
-
comment
Comment #41204168
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 …
-
comment
Comment #41204101
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 w…
-
comment
Comment #41204054
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 shar…
-
comment
Comment #41204030
Exactly! The finer grain sharing is one of the key things on our radar right now
-
comment
Comment #41203971
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 mea…
-
comment
Comment #41203853
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 …
-
comment
Comment #41203844
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 c…
-
comment
Comment #41203806
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…
-
story
Show HN: Attaching to a virtual GPU over TCP
We developed a tool to trick your computer into thinking it’s attached to a GPU which actually sits across a network. This allows you to switch the number or type of GPUs you’re us…
-
comment
Comment #41090087
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 th…