Update Dockerfile.tpu pin to nightly torch_xla

[ManfeiBai]

Switch vLLM docker image build with torch_xla from specific-data-10/17 to nightly

torch_xla docker image at Dec18 passed import torch; import torch_xla

[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.

🚀

[ManfeiBai]

Hi, @simon-mo, @khluu, would you mind add me permission for Buildkite, and I don't find link for Buildkite yet too

Hi, @lsy323, @richardsliu, would you mind help to review this PR and help to enable CI for merge too?

[miladm]

@WoosukKwon who is the right person to review / merge this PR?

cc @bvrockwell

[richardsliu]

I don't think we want to do this, since it will make the torch and XLA versions hard to determine. Right now we are pinning them specifically to have reliable builds.

The right approach would be to add an optional path where the Dockerfile can pick up new nightly builds if specified to do so.

[bvrockwell]

Hi @ManfeiBai !

I agree with @richardsliu ... introducing instability into the requirements file like this will hurt user experience and lead to breaking vLLM CI at main (GPU users won't know why pytorch-xla is preventing them from merging their PRs, resulting in admins disabling TPU tests completely until it is fixed).

• This means all our docs break @mikegre-google
• Which results in bad user experience
• This also results in breaking changes being merged that otherwise would have set off TPU CI tests had they not been turned off.
• This then leads to technical debt that otherwise would have been handled by the community through proper CI

If the intention is to run regression testing on nightly dependencies so they can be fixed, is there not a better way to do this that doesn't lead to the above issues?

Thanks!

[ManfeiBai]

Hi @ManfeiBai !

I agree with @richardsliu ... introducing instability into the requirements file like this will hurt user experience and lead to breaking vLLM CI at main (GPU users won't know why pytorch-xla is preventing them from merging their PRs, resulting in admins disabling TPU tests completely until it is fixed).

• This means all our docs break @mikegre-google
• Which results in bad user experience
• This also results in breaking changes being merged that otherwise would have set off TPU CI tests had they not been turned off.
• This then leads to technical debt that otherwise would have been handled by the community through proper CI

If the intention is to run regression testing on nightly dependencies so they can be fixed, is there not a better way to do this that doesn't lead to the above issues?

Thanks!

Hi, @bvrockwell, thanks for the explanation and clarification;

To avoid introduce instabiliyu, I know Daniel has a solution to update this with a Flag, cc @richardsliu, let's leave this PR here or close it