Ignore '<string>' filepath#17330
Conversation
vLLM tries to get a list of files that Dynamo traced through. Some of these files can be equal to `'<string>'`. This may happen if the code object was dynamically generated, which does happen in some dataclasses cases. This is one of the issues that was blocking the upgrade of vLLM from PyTorch 2.6 to PyTorch 2.7 (vllm-project#16859). The reason why this happened was because PyTorch 2.7 now traces through more HuggingFace code, including some custom dataclasses. Test Plan: - ran `pytest -v tests/models/test_transformers.py -k test_models[meta-llama/Llama-3.2-1B-Instruct-transformers]` with PyTorch >= 2.7 Signed-off-by: rzou <zou3519@gmail.com>
|
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run 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 either: Add 🚀 |
houseroad
left a comment
There was a problem hiding this comment.
Wondering if we can add some unittest?
I'm not sure how to actually reproduce this on PyTorch 2.6, this would involve getting Dynamo to run on a function with |
Signed-off-by: rzou <zou3519@gmail.com>
Signed-off-by: rzou <zou3519@gmail.com> Signed-off-by: Mu Huai <tianbowen.tbw@antgroup.com>
Signed-off-by: rzou <zou3519@gmail.com> Signed-off-by: Yuqi Zhang <yuqizhang@google.com>
This PR fixes the other issue discovered in vllm-project#16859 when upgrading from PyTorch 2.6 to PyTorch 2.7. I don't know why the code used to work in PyTorch 2.6, but the explanation is: - when we are running PiecewiseCompileInterpreter, we end up doing FakeTensor propagation - FakeTensor propagation requires `enable_python_dispatcher` to work. The mechanism is that some of our "C++ implementations" for operations, like matmul, force specialization of dynamic shapes. torch.compile works around this by replacing PyTorch's "C++ implementation" for matmul with a python-based implementation for matmul that does not force specialization. Test Plan: - Ran `pytest -v tests/models/test_transformers.py -k test_models[meta-llama/Llama-3.2-1B-Instruct-transformers]` with PyTorch >= 2.7 and vllm-project#17330, verified that the test passes. Signed-off-by: rzou <zou3519@gmail.com>
vLLM tries to get a list of files that Dynamo traced through. Some of these files can be equal to
'<string>'. This may happen if the code object was dynamically generated, which does happen in some dataclasses cases.This is one of the issues that was blocking the upgrade of vLLM from PyTorch 2.6 to PyTorch 2.7 (#16859). The reason why this happened was because PyTorch 2.7 now traces through more HuggingFace code, including some custom dataclasses.
Test Plan:
pytest -v tests/models/test_transformers.py -k test_models[meta-llama/Llama-3.2-1B-Instruct-transformers]with PyTorch >= 2.7