Voltage Park (voltagepark.com) | US REMOTE | Full-Time | SRE, Backend Engineer
Voltage Park is building a machine learning infrastructure company from the ground up. We purchased 24,000 H100 GPU's and are currently deploying them across the US. We're looking for friendly, highly motivated, execution focused folks to join our small but growing team!
Some reasons to apply:
- Fully remote with WFH stipend to kit out your home office
- 38% of the team are YC alumni
- Comprehensive benefits including 401k w/match, health, dental and vision with premiums covered by the company
Eric here, CEO of Voltage Park. To add some context, we're announcing a new cloud consisting of approximately 24,000 NVIDIA H100s. Each cluster has H100 SXM5 GPU's fully interconnected with 3.2T Infiniband for peak performance. Pricing is as low as $1.89 / GPU / hour.
We think the current market for ML compute is broken, with access only available to the well-resourced. We're on a mission to make machine learning infrastructure accessible to all and will be opening up support for short term leases and hourly billing early next year.
We'd love to hear your thoughts around the ML compute shortage, what needs aren't currently being met, and what we can do to ensure that the AI ecosystem is healthy and accessible to a broad audience of users.
It's not easy but it's definitely possible, especially if you can stack the deck in your favor -- line up childcare and appropriately configure your company's work culture.
I juggled a day job and side-startup while my child was a toddler. My wife and parents picked the slack on the nights where I had to push towards a hard deadline and I leaned heavily on my team so that I could be present for family time. The company was profitable and we successfully sold it to a private party.
For my current startup, I was very up front with my co-founder about making sure I was around to do school drop-offs and pick-ups. We're fully remote so there's no commute and we predominantly work asynchronously to avoid meetings. I mostly work during school hours and pick up again in the evening after the bedtime routine.
It's not for everybody and doesn't leave a lot of "me" time, but I'm personally finding a lot of fulfillment in trying to build a family-friendly remote-first company.
It’s been a whole year since the pandemic started and video calls are still terrible. We've been doing a lot of research into how to make them better and wanted to share what we've learned.
We were aiming for something whimsical and easy to read so the tips primarily focus around illustrations that were inspired by IKEA instructions. For people who are interested in delving into the details we put the meat of the advice behind a "Why?" button.
This was also our first foray into writing a responsive site that renders well on mobile and desktop, built using Next.js and Tailwinds CSS.
What are some of your favorite video call hacks or tips?
> It’s been a whole year since the pandemic started and video calls are still terrible.
Because it's hard. Just going through the list in the article:
> Use a cable to connect to the Internet
Difficult if your house isn't wired for ethernet and the modem is in an inconvenient spot, or in a room which contradicts tip #4. Do you let a long cable drift along the floor?
Powerlines will work in some houses, but not others, and can occasionally introduce their own connectivity problems.
> Make sure your upload speed is >3 Mbps
And if your ISP doesn't offer that much upload bandwidth, well then I guess you're SOL.
Yeah, definitely agreed with you that it's difficult if your house isn't wired for ethernet. I actually do let a long cable drift along my floor :P Having a strong upload speed is crucial to letting others be able to hear you without any lag - and that's one of the most important factors to having a great video conference. This is why we wanted to emphasize a wired connection, but we also provided the specific upload/download speeds that could get you the high quality call as well.
For me: Powerline was better than wifi from the router, but worse then adding a mesh network. Running a cable would have been very expensive (under concrete + outside).
Why not have the homepage be the checklist? Seems odd to have a page that says click here to see the checklist
Can you send this to the one guy on our Zoom calls who logs in 3 minutes after meeting starts, futzes around with camera/microphone/sound for 5 minutes and then 8 minutes into the call announces he’s online and wants to be filled in on what he missed?
From video production the one takeaway I have is key light vs backlight, webcams like key light and webcams struggle with back light
Lolol!!! Happy to send this to that guy if you somehow provide us his contact information :) I'm on Twitter here if you wanna DM me: https://www.twitter.com/melissadooo.
And yes, absolutely. Webcams - and actually cameras in general - REALLY struggle with back-lighting. Having a key light pointed at a wall so it's more diffuse and so it can cast a softer glow onto your face is ideal.
Hey supermatt, thanks for the feedback, that's good to know! Is there an alternative wording you would suggest? We meant to imply that the tips were primarily derived from findings from published research.
I’d be interested in the links to the published research!
If it’s actual research, I think the naming is fine. If it’s reading a bunch of “top 10 tips for looking great on webcam” then it’s not.
When I clicked on “why” I was expecting some actual information. As is, it just reads like an opinion piece IMHO
For example, you state an arms length as the optimal distance - but this would be different based on FoV, etc. There’s no real data I can see that would lead to make that statement.
Ah, okay I'm trying to understand your recommendation. Is it because not every tip has a research finding tied to it, which seems incongruous with the title? Or is it that the research finding doesn't explicitly tie to the recommendation?
Most of the tips do reference research findings, and you can find the reference by clicking on the subscript numbers or scroll down to the references section.
Some tips are more common sense and/or geared towards addressing a research finding. In the "arm's length" tip for example, the referenced paper discusses the importance of eye contact in computer mediated communications but doesn't explicitly say you should keep an arm's length to achieve the best eye contact. Was your expectation that the tip should link to research determining the optimal distance from the camera to achieve good eye contact?
> Was your expectation that the tip should link to research determining the optimal distance from the camera to achieve good eye contact?
Yep, that would "back" the statement with research, otherwise it is conjecture. As mentioned, this particular statement is easy to dismiss given the wide variety of FoV on webcams - but other statements are equally unfounded.
To clarify - I like the site, and im sure it is useful to many, but its very misleading to state that it is backed by research when it isnt.
You can vet who joins the channel by denying unauthorized users the room key. Users who don't have the key cannot post messages to the room.
User authentication, so someone is not able to impersonate you, is on the todo list but it is assumed that the server is trusted and won't go swapping public keys on you. A chat system that doesn't trust the server would need an entirely different design. You need to trust the server to perform basic actions like broadcast your message to the other users in the room.
If that's the case, why go through all this hassle? Simply use IRC with SSL and you have exactly the same level of security. As long as you trust the server, you are fine.
I think there's still value in hiding the conversation from the server even if you must still trust the server to not behave maliciously. If some three-letter agency contacts the server operator asking for a back channel to listen in, he or she could respond that it's not possible without malicious intent towards a user:
deadchat implements the latter option. The secret room key is shared using the RSA key exchange protocol but you're right, there's currently no way to guarantee that you're talking to who you think you are. User authentication is on the todo list.
I think there's still value in hiding the conversation from the server even if you must still trust the server to not behave maliciously. If some three-letter agency contacts the server operator asking for a back channel to listen in, he or she could respond that it's not possible without malicious intent towards a user:
That's fair, I modeled some aspects of the system after FiSH-irssi, which also doesn't have user authentication or MITM attack mitigation. That'll teach me to post to HN prematurely. Both SSL with proper endpoint authentication (and session keys) and user authentication are on the todo list.
Hey all, great discussion. Apologies for not chiming in earlier, I posted this to HN in the morning and left for 4th of July activities, certainly not expecting it to make the front page. Here're some thoughts and clarifications:
* No, I am not a cryptography expert. I've had a nascent interest in the field for awhile and this was my way of getting my feet wet while scratching an itch. I thought I'd post it on HN to get feedback and see where I might have screwed up.
* I'm here to learn. *
We all have to somehow right? A disclaimer is a good idea, I'll add it to the README.
* The project was originally motivated because I couldn't find a group chat service that provided an IRC-like experience with end-to-end encryption. The closest I could find was FiSH-irssi, an irc client plugin:
I wanted to try implementing something that was easer to use. I ruled out IRC over SSL because the conversation is cleartext at the server.
* I should have mentioned this in the README and will update it -- The design goal for this system is to enable a group of trusted friends to communicate with each other over an insecure channel without fear of eavesdropping. It is assumed that a member of the trusted group operates the server. Forward secrecy was an additional goal facilitated by changing the room key. It sounds like my implementation did not achieve the design goal. What can I do to make it right?
* My intention was for the secret room key to be securely shared following the RSA key exchange protocol (encrypt secret with requestor's public key and sign with sender's private key, decrypt with requestor's private key and verify with sender's public key). The problem then lies in how to properly exchange users' public keys. If I trust the server but don't want the server operator to read my conversations, is it not okay to facilitate public key exchange through the server?
Learning is fine, just add a disclaimer that it's actually probably not so secure.
Oh please don't get me started on FiSH, and PLEASE don't model anything after fish.
I had the same problem as you, there's no useable crypto for irc.
- The FiSH plugin for Xchat has a (possibly remote) buffer overflow in the Diffie-Hellman key exchange.
- FiSH uses ECB mode. Seriously. ECB.... ECB... might as well use no crypto.
- IIRC FiSH wastes two bytes per 8 byte block the way it does Base64, not sure about this anymore, it's been a while.
So I tried to find a better plugin and mod it a bit which I did (https://gitorious.org/fishslim/dumfish). But I didn't realize back then that FiSH uses ECB mode.
Since the DH key exchange is not authenticated it's useless. So I dropped it and hacked my own (for Xchat, https://github.com/lawl/dumfish), which doesn't offer DH key exchange but CBC mode instead of ECB, we exchanged keys manually via OTR.
(And just makes me realize I also don't have a disclaimer, so I'll add this now.)
Disclaimer: Also not a cryptographer, so it's probably not secure. Do not use for anything serious.
Voltage Park is building a machine learning infrastructure company from the ground up. We purchased 24,000 H100 GPU's and are currently deploying them across the US. We're looking for friendly, highly motivated, execution focused folks to join our small but growing team!
Some reasons to apply:
- Fully remote with WFH stipend to kit out your home office
- 38% of the team are YC alumni
- Comprehensive benefits including 401k w/match, health, dental and vision with premiums covered by the company
Openings:
- Customer Reliability Engineer ($120k-$180k + equity)
- Site Reliability Engineer ($140k-$180k + equity)
- Backend Engineer ($150k-$200k + equity)
Apply: https://voltagepark.com/jobs