[Bugfix][Tool Parser] Fix Kimi-K2.5 parser accuracy, buffer limits, and token leaks

[karanb192]

Summary

Fixes three critical issues in the Kimi-K2.5 tool parser (gh-37184):

• 8 KB hard limit -> 512 KB configurable ([Bug]: kimi k2 tool parser has a 8k buffer limit for args #34442): The old max_section_chars = 8192 blocked tool calls with large JSON payloads (e.g., file content > 8 KB). The new default is 512 KB, configurable via the KIMI_PARSER_SECTION_MAX environment variable.
• Token leakage ([Bug]: Kimi-K2.5 outputs only '!!!!!!!!!!' in reasoning field, content is always null #36763, [Bug]: Kimi-K2.5 output a single </think> tag in the content when "enable_thinking" is set to false #36969): Text between section markers and tool-call markers leaked into the reasoning/content channel, causing the !!!!! noise in reasoning output and </think> tag leaks. The rewrite properly suppresses all inter-section noise.
• 87% -> near-100% accuracy ([Bug]: Kimi-K2.5 Tool Parser Critical Issues - 87% Accuracy, 8KB Limit, Token Leakage #37184): The old diff logic relied on fragile delta-text heuristics (e.g., searching for "} in delta_text) that broke with special characters, nested JSON, and split tokens. The rewrite rebuilds arguments from current_text on every delta using _diff_and_emit_args, making the diff always correct regardless of token boundaries.

Key changes

Area	Before	After
Buffer limit	8 KB hardcoded	512 KB, env-var configurable
Marker buffer	1024 bytes, unbounded growth	256 bytes, capped
Argument diffing	Delta-text heuristics	Rebuilt from current_text
State helpers	Inline, scattered	_diff_and_emit_args, _try_emit_name, _handle_call_end
Section-begin check (non-streaming)	Only plural variant	All variants (singular + plural)
Streaming regex	No re.DOTALL on portion regex	re.DOTALL for multi-line args
Single-delta tool calls	Silently dropped	Handled via Phase B late setup

Files changed

• vllm/tool_parsers/kimi_k2_tool_parser.py - Parser rewrite
• tests/tool_parsers/test_kimi_k2_tool_parser.py - Updated tests for new buffer limits + safety valve test

Closes #37184
Related: #34442, #36763, #36969

Test plan

• All existing unit tests pass (updated for new behavior)
• test_large_tool_args_no_forced_exit - verifies 10 KB payloads are NOT truncated
• test_malformed_tool_section_safety_valve - verifies configurable safety valve works
• test_complete_tool_call_single_delta - verifies complete tool calls in single delta are emitted
• test_token_leak_between_section_and_tool_begin - verifies no token leakage
• test_streaming_tool_call_markers_not_leaked - verifies no marker leakage
• test_streaming_multiple_tool_calls_not_leaked - verifies multi-tool scenarios
• Pre-commit hooks pass (ruff check, ruff format, mypy, SPDX headers)
• Rebased on latest main (no merge conflicts)
• Integration test with K2-Vendor-Verifier (requires GPU)

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @karanb192.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[gemini-code-assist]

Code Review

The pull request refactors the KimiK2ToolParser to enhance its correctness and support larger payloads, addressing several known issues. Key changes include implementing a single source of truth for streaming state, introducing a configurable safety valve for tool section size (default 512 KB), and improving marker handling to prevent token leakage. The streaming logic has been rewritten into a phased approach for clearer state management and more robust tool call parsing. A critical review comment highlights that the new argument diffing logic in _diff_and_emit_args does not correctly handle non-monotonic changes, which could lead to client-side JSON corruption, and suggests logging an error and returning None in such scenarios.

[gemini-code-assist]

The current diffing logic for tool arguments does not correctly handle non-monotonic changes, which can occur if the model backtracks or revises its output. In such cases, cur_args may no longer start with already. The current implementation sends the full cur_args as a delta, which will likely corrupt the client's state if the client simply appends argument deltas, leading to malformed JSON.

For example, if the client has accumulated {"a": 1 and the model backtracks to produce {"b": 2, this logic would send {"b": 2 as the delta. The client would append this, resulting in the invalid JSON {"a": 1{"b": 2.

To prevent client-side corruption, it is safer to avoid sending a potentially corrupting delta. I suggest logging an error and returning None in this scenario.

        else:
            # This indicates a non-monotonic change in the tool arguments, which
            # can happen if the model backtracks. Simply sending the new
            # arguments as a delta will likely corrupt the client's state, as
            # clients typically append argument deltas.
            logger.error(
                "Non-monotonic change detected in tool call arguments. "
                "Previous: %r, Current: %r. Aborting delta to prevent "
                "client-side corruption.",
                already,
                cur_args,
            )
            # Returning None to prevent sending a corrupting delta. A more
            # advanced implementation might compute a proper diff or signal a
            # reset to the client.
            return None