4 ms·
Im also interested in what the differing factor is. Would also like to see more documentation for onboarding rather than just "Ubuntu and root available".
by ganoushoreilly 2y ago
Im also interested in what the differing factor is. Would also like to see more documentation for onboarding rather than just "Ubuntu and root available".
- icelancer 2y agovast you have to choose specific machines. gpudeploy routes to whatever resources are available. vast has a lot of bad machines with terrible PCIe lanes and architecture you have to learn the hard way. Someone on HN wrote a script to run a test docker image on every machine and auto-tagged the machines' quality using their API, which is what I'd do if I was going to use vast seriously for compute.
- polygot 2y agoDo you have a link to that thread/Docker image? I would be very interested using it
- icelancer 2y agoI don't, sorry. I would love to use it as well, I should've bookmarked it! Also, I'm not sure the person opensourced it.
- lelanthran 2y ago>> Im also interested in what the differing factor is. > vast has a lot of bad machines with terrible PCIe lanes and architecture you have to learn the hard way. Wouldn't gpudeploy have exactly the same problem? How is it mitigated with gpudeploy?
- everforward 2y agoI think it's more of a business strategy issue than a technical one. I suspect it would be trivial for Vast or GPUDeploy to spin up a benchmarking job before allowing sales on that machine. I'm not an expert on PCIe lanes, but I would think the performance issues would be visible via bandwidth or latency on the lanes. It kind of makes sense to me, though. If I were looking for absolute reliability and was willing to pay for it, I'd just go to one of the many GPU cloud vendors. Likewise, I suspect anyone willing to really work on getting good performance would rather be a real provider or sub-provider than being part of this nebulous C2C GPU cloud.