🐛 Describe the bug

When a user passes a chat template name (e.g. "tool_use", "default") instead of an actual Jinja template string via the chat_template parameter, the resolve_chat_template → resolve_chat_template_kwargs pipeline silently drops valid template kwargs like tools, documents, etc. This happens because the template name string is never resolved to the actual Jinja content before being parsed for variable detection.

Root Cause

The issue spans two functions in vllm/renderers/hf.py:

1. resolve_chat_template (L110) — Priority 1 returns the chat_template string as-is without checking whether it's a Jinja template or a template name:

def resolve_chat_template(tokenizer, chat_template, tools, *, model_config):
    # 1st priority: The given chat template
    if chat_template is not None:
        return chat_template  # returns "tool_use" verbatim, not the Jinja content
    ...

HuggingFace tokenizers support named templates via tokenizer.chat_template being a dict (e.g. {"default": "<jinja...>", "tool_use": "<jinja...>"}). The tokenizer.get_chat_template(name) method resolves a name to the actual Jinja string. But resolve_chat_template short-circuits at Priority 1 and never calls get_chat_template when chat_template is not None.

2. resolve_chat_template_kwargs (L433) — receives the unresolved name string (e.g. "tool_use") and passes it to _resolve_chat_template_kwargs, which tries to parse it as Jinja:

def _resolve_chat_template_kwargs(chat_template: str) -> Set[str]:
    env = jinja2.sandbox.ImmutableSandboxedEnvironment(...)
    parsed_content = env.parse(chat_template)  # parses "tool_use" as literal text
    template_vars = jinja2.meta.find_undeclared_variables(parsed_content)
    return template_vars  # returns empty set — no Jinja variables in plain text

Since "tool_use" is valid (trivial) Jinja that contains no undeclared variables, template_vars is set(). This means kwargs that the actual template expects (like tools, documents, etc.) are not detected, and resolve_chat_template_kwargs silently drops them from the accepted kwargs.

The only kwargs that survive are those in fn_kw (explicit params of tokenizer.apply_chat_template) and hf_base_params. Template-specific variables that are only discoverable by parsing the actual Jinja content are lost.

Expected behavior

When chat_template is a template name (not a Jinja string), resolve_chat_template_kwargs should still be able to correctly detect which kwargs the template expects.

Before submitting a new issue...

• Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.