[Build] Allow shipping PTX on a per-file basis

[LucasWilkinson]

323.20 MB -> 324.36 MB

To help with the growing wheel size due to Blackwell allow for shipping PTX for heavy kernels that don't take advantage of new hardware features. Theres enough different gencodes now for certain kernels it makes sense to ship a single PTX implementation instead of multiple SASS. Currently mildly grows the wheel size but should help keep it capped as the Blackwell gencodes are added

[github-actions]

👋 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 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 either: Add ready label to the PR or enable auto-merge.

🚀

[bnellnm]

Do the _TGT_CUDA_ARCHS need to be sorted too?

[LucasWilkinson]

for a more general utility you're right they should be!; but the target arches come from extract_unique_cuda_archs_ascending so they are already sorted. I can open up a now PR to refactor some of this though; kinda want to preserve current behavior as much as possible in this one

[bnellnm]

Looks reasonable to me.

[mgoin]

Seems relatively safe to me. There might be a regression for marlin because of slow bf16 convert on A100 (IIRC) that might transfer to newer hardware, but also might not. Ultimately shouldn't be that big of a deal. @jinzhen-lin please step in if you have concerns with this since you refactored marlin most recently.

[mgoin]

The failures look closely related

[jinzhen-lin]

Seems relatively safe to me. There might be a regression for marlin because of slow bf16 convert on A100 (IIRC) that might transfer to newer hardware, but also might not. Ultimately shouldn't be that big of a deal. @jinzhen-lin please step in if you have concerns with this since you refactored marlin most recently.

Currently, I believe that the performance of use_atomic_add=True + bf16 may be impacted on sm90+. I will run some tests to verify.

[LucasWilkinson]

Failures resolved

[mgoin]

This is a nice middle ground, thanks for getting it working!