wfalcon

Studios are a great google colab alternative with:

- persistent storage (setup env and data persists across restarts)

- free ssh and connect your local IDE

- CPU setup, GPU run (do setup work on CPUs and switch to run on a GPU when ready)

- no credit card

- pay-as-you-go if you need more GPU hours

- A100s, H100s, and more GPUs available

this is also what our (Lightning AI) lit-gpt library does. https://github.com/Lightning-AI/lit-gpt

welcome to Lightning AI! Mike, super excited to drive the future of ML together.

Just to be 100% clear.

We want people to build on Lightning and we want companies to deliver value and products for their users.

We place no limitations on how Lightning is use or what products people will build.

Our in-process patent portfolio is not to limit the use of lightning in any way but for defensibility purposes only.

If you have any other inquiries please email legal@pytorchlightning.ai for more details.

Just to be 100% clear.

We want people to build on Lightning and we want companies to deliver value and products for their users.

We place no limitations on how Lightning is use or what products people will build.

Our in-process patent portfolio is not to limit the use of lightning in any way but for defensibility purposes only.

If you have any other inquiries please email legal@pytorchlightning.ai for more details.

No! we want people to build on Lightning and we want companies to deliver value and products for their users.

No! we want people to build on Lightning and we want companies to deliver value and products for their users.

No, we support other frameworks too!

Just that if you use lightning you'll have zero friction. Well as with the others... you might run into issues inherent in the other framework's hard to work with designs.

maybe determined should come up with its own API instead of copying Lightning's :)

Not a nice move for the opensource spirit. Also, pretty sure it's a violation of our patent and 100% copyright infringement.

we highlight these issues in our docs explicitly.

https://pytorch-lightning.readthedocs.io/en/latest/tpu.html#...

I 100% agree. We don't want to misrepresent TPU support. In fact, we explicitly warn users in our docs. Open to suggestions about how we can communicate this much better to our users.

We just need to be a part of the effort to help bridge the big gap and barriers keeping users from TPU adoption.

https://pytorch-lightning.readthedocs.io/en/latest/tpu.html#...

super cool!

One of the professors at my lab at NYU CILVR (Kyle Cranmer) i believed was super involved with this. Will definitely sync up with him!

Thanks for the heads up!

Like I said... pytorch and tensorflow team are working very hard to make this work. And yes, it's not a 1:1 with tensorflow, but we're making progress very aggressively.

The grid is how you harness and distribute power and electricity.... like that coming from lightning :)

Second, electricity was a great new technology (ie: AI), but you needed the power grid to make it usable - that's grid AI.

it's honestly just a different approach. ML ops is adjusting your code to work with the cloud and managing all that.

For us is basically integrating clouds directly into your code so the barrier disappears and the cloud providers become an extension of your laptop.

We currently have google engineers training on TPU pods with PyTorch Lightning.

TPU support is VERY real... but yes, sometimes it breaks but PyTorch and Google are working very hard to bridge that gap.

But we have dedicated partners at Google on the TPU team working to get Lightning working seamlessly on pods.

Check out the discussions here: https://github.com/PyTorchLightning/pytorch-lightning/issues...

Lightning is built for researchers by researchers... we've already taken a much different approach.

100% agree with you that going the other way is likely not the best approach.

Lightning + Grid elevates and turns non experts closer to researchers... ie: focus on building the products and doing science and not the engineering.

That's what lightning excels at today. That's the experience Grid will 10x.

Well... we're not really an ML ops startup haha. I am ALSO pessimistic about ML Ops startups.

But calling Grid an ML Ops startup is like calling Lightning Keras... maybe at a quick blink it looks like that, but that's where the similarities end.

For what it's worth, a lot of what we're building comes from my experience at FAIR.

yes! our goal is to completely remove any engineering from the AI research -> production lifecycle.

Not just a marginal improvement on that experience but a 10x completely different approach.

hat aims to help machine learning engineers <scale up their models> more efficiently

well... that's part of the magic we're bringing to this. PyTorch Lightning is built exactly for this purpose, so it is highly scalable and designed for working at this kind of scale.

I built it while doing self-supervised learning research at Facebook AI research where I was running dozens of model versions each on 256 GPUs!

We've applied a lot of these lessons to Grid, so when you use Lightning with it you have to do nothing. For other frameworks you also don't have to do much in most cases but if there's some friction there we have tools and guides to help!

I totally sympathize with this. As the creator of PyTorch Lightning I focused on the user experience FIRST. Too many times, it seems, engineers forget that NOT everyone using these frameworks are engineers. It really is a fine balance between being opinionated but no more. But as mentioned here, even though Lightning has seen dramatic adoption, there were a few times when the result was judged on the simplicity of it without considering the significant amount of time that went into making the API super simple and infinitely flexible.

At least in the PyTorch world, the team's done a phenomenal job at allowing an ecosystem of related projects to contribute to one another and co-exist!