Has anyone seen signals (roadmap, EAP, RFCs) for GPUs on Forge Functions or Containers?
We’re looking at workloads that need more than CPU/memory (embeddings, light vision/OCR next to Confluence data). Remotes work, but we’d rather stay closer to Runs on Atlassian if there’s a path.
Is GPU support on any public plan, or is the intended model always external inference via remotes/egress?
Curious what others are hearing.
Hi Nico,
I’m the Product Manager for the Forge compute environment.
We can’t offer GPU access on Forge functions due to the underlying technologies we depend on. GPU access for Containers is something we could explore in the future, but nothing on our roadmap currently.
Do you want to book some time with me to chat about your use case in more detail? Book time with me
Forge may be the only PaaS on Earth without any budget cap feature.
Might want to sort that out first.
Hi @nathanwaters,
Thanks for your feedback. I have created https://jira.atlassian.com/browse/ECO-1831 as a feature request for your suggestion.
You may link to comment on that issue with additional information, such as how you’d expect the feature to work (eg. would you expect Atlassian to implement a hard block that prevents your app from functioning, or provide a contextual payload you can respond to within your app’s logic for non-compute capabilities?)
@HeyJoe thanks mate. There’s a few CDAC threads complaining about this with Atlassian staff saying they can’t/won’t build it. Imagine AWS without a budget cap.
I also have an ECOHELP open (169969) with over 120 engineering bugs and gaps identified during Forge migration.
Just saying, AWS over the years didn’t had a hard budget cap. It was just a billing alert and not a hard cap. But it looks like they recently added this (Create a spend limit in AWS Settings - AWS Account Management).
Awesome. Forge atm also doesn’t have an ability to set usage alerts based on $ spend. The alert options are only on invocation count.
Thanks Joe. Booking time would love to chat. The app/use case we have I think has a lot of potential.
Booking time
@HeyJoe
Following up on the CPU-only point. For running a small embedding model (tens of MB) inside a Forge function, are there documented limits on deployment package size, and does extra memory also give more CPU? in case we want to speed up the embedding by raising function’s memory. Also, does bundling a model and running inference in-function stay eligible for RoA, as long as nothing is downloaded at runtime?
Hey @ziadalharash ,
Good questions!
are there documented limits on deployment package size
Yes - https://developer.atlassian.com/platform/forge/limits-app-developer/#app-limits. By default, your deployed app bundle has a maximum size of 100MB.
does extra memory also give more CPU?
Yes, currently it does. Forge functions run on AWS Lambda, which has limited documentation describing how CPU provisioning is scaled: Configure Lambda function memory - AWS Lambda
Please note that this is not explicitly documented behaviour in Forge, so relying on this would be ‘at your own risk’ (ie. if we ever choose to run Forge functions on a different platform, we would potentially reserve the right to change this behaviour with minimal notice).
Also, does bundling a model and running inference in-function stay eligible for RoA, as long as nothing is downloaded at runtime?
Yes, that’s right. You can always use the forge eligibility command to check if you want certainty.
You can bundle the model in your app artifact using either the extraFiles directive, or the new manual packaging functionality: https://developer.atlassian.com/platform/forge/manifest-reference/#packaging
Great to know, @HeyJoe thanks for sharing