You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 30, 2023. It is now read-only.
As part of the architecture refactorisation, we should start using AWS Fargate. If we use a serverless, pay-as-you-go compute engine we can optimise memory management as well as our cost strategy.
The text was updated successfully, but these errors were encountered:
Hmm but wouldn't be Fargate an improvement for our EC2 CPU instance management still? I agree on the GPU part and we can wait for that but AWS Fargate could be also relevant for the other non-GPU-related processing.
I am considering keeping the current flow or changing to Fargate. Currently, our flow also works similarly to Fargate, and also can support GPU if we need it. If we change now I am not sure about GPU.
Let's re-evaluate the AWS Fargate issue (in particularly re GPUs) in the next phase again (i.e. May 2022). However, for the moment we go with our existing, custom-built architecture.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As part of the architecture refactorisation, we should start using AWS Fargate. If we use a serverless, pay-as-you-go compute engine we can optimise memory management as well as our cost strategy.
The text was updated successfully, but these errors were encountered: