Without this: --tool-call-parser qwen3_coder causes api_server.py to crash
with KeyError at line 537: 'invalid tool call parser: qwen3_coder'
This is AFTER the --reasoning-parser crash (fixed in b446763) - even if
argparse passes, this KeyError kills the server.
Qwen3 models use Hermes-compatible tool calling format:
<tool_call>{"name": "func", "arguments": {...}}</tool_call>
So registering qwen3_coder -> Hermes2ProToolParser is semantically correct.
This was the SECOND startup blocker preventing the benchmark task from
completing. The first was --reasoning-parser (fixed). Together these
explain why task_id=3905102 has been stuck at status=running for 84+ minutes.
Startup sequence that was failing:
1. argparse --reasoning-parser qwen3 -> CRASH (fixed b446763)
2. ToolParserManager.get_tool_parser('qwen3_coder') -> KeyError (fixed NOW)
3. Qwen3_5MoeForCausalLM not in registry -> crash (fixed 08dc010)
All three must be fixed for the server to start.
Without this: vllm server crashes immediately on startup with argparse error:
'unrecognized arguments: --reasoning-parser qwen3'
because computility-run.yaml passes this flag but vllm 0.6.3 does not
recognize it. The container stays running but HTTP server never becomes
ready, causing benchmark-agent to poll indefinitely (status=running).
This is likely why task_id=3905102 benchmark has been running for 36+
minutes without result — the vllm process died but the container lives on.
Changes:
cli_args.py: Add --reasoning-parser as accepted argument (str, default=None)
The value is parsed by argparse but not used by api_server.py or
serving_chat.py — it is a stub that prevents the crash.
Actual reasoning token separation (<think>...</think>) for Qwen3 models
would require implementing a ReasoningParser class similar to ToolParser.
For now, reasoning tokens will appear in the response content, which
is acceptable for functional tests (content is correct, just includes
thinking tokens).
CCCL context: dispatch_batch_memcpy.cuh's two-level dispatch pattern:
small buffers → single CTA (fast path, no coordination overhead)
large buffers → multi CTA (slow path, needs scan+select)
Analogously: known CLI args → fast parse, unknown → crash.
Adding the stub is the 'fast path' that avoids the crash.
