Live data from Hacker News

Viewing profile — bmodel

bmodel

HN member
Joined
Fri, Apr 19, 2024, 1:49 PM UTC
HN karma
166
Public activity
18 items

About bmodel

No profile information was provided.

Recent public activity

  1. 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!

  2. 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…

  3. 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…

  4. 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…

  5. 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 !

  6. 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).

  7. 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

  8. 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…

  9. 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 …

  10. 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…

  11. 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…

  12. comment
    Comment #41204030

    Exactly! The finer grain sharing is one of the key things on our radar right now

  13. 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…

  14. 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 …

  15. 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…

  16. 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…

  17. 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…

  18. 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…