[Frontend] Pythonic tool parser

[mdepinet]

This PR adds a tool parser for models that output tools formatted as Python function calls, such as Llama 3.2 and ToolACE-8B.

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

🚀

[DarkLight1337]

cc @K-Mistele

[K-Mistele]

cc @K-Mistele

thanks, taking a look!

[K-Mistele]

Hi @mdepinet, the parser looks good to me! Just a couple notes:

1. Can you include documentation about the newly supported model(s) in the docs/source/serving/openai_compatible_server.md? You will see examples for several other model families, so you will just need to adapt it for this parser and maybe indicate which models it is used for.
2. Can you add configurations for the models that you intend for this parser to support to tests/tool_use/utils.py, instead of the custom tests that you have built out? I already built out a bunch of parameterized tests for tool-using LLMs and tool parsers, so all you need to do is add configs for the model(s) that this supports. This way, all tool parsers & tool calling models are checked against the same tests. You can find examples of this in the tests/tool_use/utils.py file itself, or you can see an example of it here in a PR for another model's tool parser.
   Once you've done that, you can run the tests locally using pytest tests/tool_use to make sure they pass, and you should be able to use the -k flag to select the parameterized versions for your model only if you desire.

[mdepinet]

Hi @mdepinet, the parser looks good to me! Just a couple notes:

1. Can you include documentation about the newly supported model(s) in the docs/source/serving/openai_compatible_server.md? You will see examples for several other model families, so you will just need to adapt it for this parser and maybe indicate which models it is used for.

Sure, done.

2. Can you add configurations for the models that you intend for this parser to support to tests/tool_use/utils.py, instead of the custom tests that you have built out? I already built out a bunch of parameterized tests for tool-using LLMs and tool parsers, so all you need to do is add configs for the model(s) that this supports. This way, all tool parsers & tool calling models are checked against the same tests. You can find examples of this in the tests/tool_use/utils.py file itself, or you can see an example of it here in a PR for another model's tool parser.
   Once you've done that, you can run the tests locally using pytest tests/tool_use to make sure they pass, and you should be able to use the -k flag to select the parameterized versions for your model only if you desire.

Thanks, I didn't see these. I'm happy to add a config so these tests exercise the new tool parser also, but I think it's worthwhile to keep the tests I added also because:

1. The new tests are much faster to run, which is quite helpful when iterating on the implementation code. They're also easier to get running since they have fewer dependencies (no separate server).
2. The new tests don't depend on any particular model or chat template. It makes sense to tie everything together when a strict JSON schema implies that tight coupling, but I think it's reasonable to define (and test) how the parser works in isolation for a parser that may have broader applicability.
3. The new tests cover more cases than what would be reasonable in the existing tests.

Put differently, I view the existing tests more as integration tests and the tests I added more as unit tests. I think it'd be a mistake to entirely do away with either. Does that seem reasonable to you?