[AMD][Build] Porting dockerfiles from the ROCm/vllm fork

[gshtras]

An attempt to unify the build process with how it is done in ROCm/vllm
Split the build process into:

• Building the required dependency libraries using Dockerfile.rocm_base. Not needed for the end user, done by AMD.
• Building the vLLM itself on top of it.

In addition to not building the libraries each time, the new base image is now much smaller (7GB on docker hub vs 18GB previously), which allows to make the build process much faster (~10 minutes)

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can do one of these:

• Add ready label to the PR
• Enable auto-merge.

🚀

[DaBossCoda]

nice

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @gshtras.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[robertgshaw2-redhat]

@SageMoore - could you take a quick look through this?

[SageMoore]

Looks reasonable to me. I assume the configs are copied over from the rocm/vllm-dev container and are expected to be faster than what we have on main? Do you have any performance results that you can share?

[SageMoore]

Does this version of pytorch support rocm 6.3? If not, would it make more sense to pull in the 6.2 wheel from pypy instead of building from source?

[gshtras]

This is the same base image and therefore a combination of versions used in the AMD weekly dockers - rocm/vllm-dev:main (out of ROCm/vllm.git)
6.2 wheel is a all-in-one whl that brings with it an entire ROCm worth of .so's, including the old less performant hipblaslt

[gshtras]

Looks reasonable to me. I assume the configs are copied over from the rocm/vllm-dev container and are expected to be faster than what we have on main? Do you have any performance results that you can share?

Not sure which configs do you mean. The change to the triton tuning configs in this PR is due to the triton version change. Triton 3.2+ deprecated the use of num_stages:0 in favor of num_stages:2

[mgoin]

It looks like the CI isn't able to find the container?

[gshtras]

It looks like the CI isn't able to find the container?

All GPU nodes of AMD CI are currently down due to a network issue in the compute cluster used there
It looks like the build of the container is the only one that succeeded as it doesn't use GPU nodes

[gshtras]

To unbreak the CI we need vllm-project/buildkite-ci#57