[BugFix] Lazily import XgrammarBackend to avoid early cuda init

[njhill]

Importing xgrammar appears to initialize the cuda context, which we don't want to do in the front-end process. It also means that the server can't be started with the (default) multiproc context mode of fork.

I guess this is what LazyLoader is meant to help with, but it doesn't seem to be working as intended since #14694 was merged.

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

🚀

[russellb]

This looks harmless, so I'm fine with it. I don't understand why it fixes anything though :(

[njhill]

Ah I found it's due to references to xgr types in the class definition here - that's what triggers the lazy import.

[russellb]

Ah I found it's due to references to xgr types in the class definition here - that's what triggers the lazy import.

oh, weird ... I thought that was ignored unless running type checking.

I wonder if using a Forward Reference (putting the type in quotes) would also work around the issue? I'm still fine just merging this PR for now, though.

[aarnphm]

Ah I found it's due to references to xgr types in the class definition here - that's what triggers the lazy import.

oh, weird ... I thought that was ignored unless running type checking.

I wonder if using a Forward Reference (putting the type in quotes) would also work around the issue? I'm still fine just merging this PR for now, though.

You can use from __future__ import annotations to make it into forward reference, but this fix also works