vLLM 交错思考Interleaved Thinking实战在工具调用之间让模型边想边调【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm本篇基于 vLLM 仓库中的 Interleaved Thinking 特性文档系统讲解交错思考在工具调用之间穿插推理在 vLLM 中的工作原理、启用方式与完整调用链读者将掌握如何用--reasoning-parser与--tool-call-parser组合启用该特性如何在多轮对话中把推理过程reasoning原样回传给模型以及背后 Kimi-K2 / MiniMax-M2 两类推理解析器ReasoningParser的源码实现与流式行为。什么是交错思考Interleaved Thinking交错思考允许模型在多次工具调用之间进行推理模型发起一次工具调用、拿到工具结果后不是直接生成最终回答而是先对结果进行一段推理thinking再决定下一步动作。由此可以实现在决定下一步之前先对工具调用的结果进行推理在多个工具调用之间穿插推理步骤形成调用 → 推理 → 再调用的链条基于中间结果做出更细致的判断对外暴露其选择工具的透明推理过程。文档同时给出重要提示交错思考会增加 token 消耗和响应延迟每多一轮推理就多一段思考 token。启用前应权衡预算与性能要求——如果你的 Agent 场景以少量、确定性强的工具调用为主未必需要开启。与普通思考模型的区别普通思考模型如 DeepSeek-R1 类只在最终回答前输出一段think推理交错思考则把推理步骤插入到工具调用循环内部用户消息 → 推理 1 → 工具调用 1 → 工具结果 1 → 推理 2 → 工具调用 2 → 工具结果 2 → 推理 3 → 最终回答因此对服务端的两个核心要求是能正确切分模型输出中的推理部分与正文部分reasoning parser能正确识别与解析工具调用tool call parser并支持客户端在下一轮把上一次的 reasoning 作为 assistant 消息的一部分回传保证多轮上下文完整。vLLM 中支持交错思考的模型根据 docs/features/interleaved_thinking.mdvLLM 当前支持的交错思考模型及其对应的 Reasoning Parser 名称如下模型系列Reasoning Parser 名称moonshotai/Kimi-K2-Thinkingkimi_k2MiniMaxAI/MiniMax-M2minimax_m2这两个名称是--reasoning-parser命令行参数的取值。它们并非独立的 Python 手写解析器而是注册到 vLLM 统一解析引擎Parser Engine中的适配器kimi_k2在 vllm/reasoning/kimi_k2_reasoning_parser.py 中直接别名到vllm.parser.engine.registered_adapters里的KimiK2ParserReasoningAdapter解析逻辑统一由vllm/parser/下的解析器如 vllm/parser/kimi_k2.py驱动minimax_m2在 vllm/reasoning/minimax_m2_reasoning_parser.py 中定义了MiniMaxM2ReasoningParser与MiniMaxM2AppendThinkReasoningParser两个实现。所有可用的 parser 名称在 vllm/reasoning/init.py 的_REASONING_PARSERS_TO_REGISTER注册表中统一定义kimi_k2指向kimi_k2_reasoning_parser.KimiK2ReasoningParserminimax_m2指向MiniMaxM2ReasoningParser另有minimax_m2_append_think变体并通过ReasoningParserManager懒加载注册——--reasoning-parser传的名称必须能在此注册表中找到。MiniMax-M2 解析器的实现细节MiniMax-M2 的推理格式有一个特殊之处见源码注释模型不生成think起始 token只生成/think结束 token/think之前的所有内容都是推理之后是正式回答。vllm/reasoning/minimax_m2_reasoning_parser.py 中的核心方法体现这一语义is_reasoning_end(input_ids)从后向前扫描 token找到最后一个/thinkend token或thinkstart token只有当它是 end token 时返回 True。这使得服务端能判断推理阶段是否已结束从而在流式输出时决定 delta 进入reasoning还是content字段extract_content_ids(input_ids)直接返回全部 token id内容边界由 token 位置确定而非标记切分。仓库内对应的单元测试 tests/reasoning/test_minimax_m2_reasoning_parser.py 覆盖了多种边界场景均可作为行为依据测试用例模型输出期望 reasoning期望 contentsimple_reasoningThis is a reasoning section/thinkThis is the restThis is a reasoning sectionThis is the restno_end_token流式中This is reasoning in progress同左None推理未结束全部算 reasoningmultiple_lines多行推理 多行回答多行推理部分多行回答部分code_in_reasoning推理中含代码块含代码块的推理Here is the code.empty_streaming空输出NoneNone这些用例验证了只要/think尚未出现流式输出期间所有 delta 都归入 reasoning出现/think后 delta 才切换到 content。这正是交错思考在工具结果 → 模型再次思考阶段的关键行为——工具结果回传后模型先吐出的新 token 会先进入 reasoning 流。启用方式服务端启动与请求参数服务端启动以 MiniMax-M2 为例需要同时启用 tool call parser 与 reasoning parser并打开自动工具选择vllm serve MiniMaxAI/MiniMax-M2 \ --tensor-parallel-size 4 \ --tool-call-parser minimax_m2 \ --reasoning-parser minimax_m2 \ --enable-auto-tool-choice各参数含义结合 vllm/engine/arg_utils.py 中的参数定义--tool-call-parser minimax_m2注册工具调用解析器负责把模型输出中的工具调用标记解析为 OpenAI 格式的tool_calls结构--reasoning-parser minimax_m2注册推理解析器。源码中该参数属于StructuredOutputsConfig.reasoning_parserarg_utils.py 中reasoning_parser字段默认取StructuredOutputsConfig.reasoning_parser随后写入self.reasoning_config.reasoning_parser即推理切分能力挂在结构化输出/推理配置体系下--enable-auto-tool-choice允许模型自行决定是否调用工具对应请求中的tool_choiceauto。对 Kimi-K2-Thinking 服务同样思路将两处 parser 名换成kimi_k2vllm serve moonshotai/Kimi-K2-Thinking \ --tool-call-parser kimi_k2 \ --reasoning-parser kimi_k2 \ --enable-auto-tool-choice客户端带推理回传的两轮工具调用下面是原文档给出的完整可运行示例天气查询工具其要点是第二轮回传 assistant 消息时必须带上reasoning字段否则模型丢失上一轮的思考上下文交错推理链会断裂。 vllm serve MiniMaxAI/MiniMax-M2 \ --tensor-parallel-size 4 \ --tool-call-parser minimax_m2 \ --reasoning-parser minimax_m2 \ --enable-auto-tool-choice import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) def get_current_weather(location: str, unit: str): Get the current weather in a given location if unit celsius: return fThe current temperature in {location} is 22°C. else: return fThe current temperature in {location} is 72°F. tools [ { type: function, function: { name: get_weather, description: Get the current weather in a given location, parameters: { type: object, properties: { location: { type: string, description: City and state, e.g., San Francisco, CA, }, unit: {type: string, enum: [celsius, fahrenheit]}, }, required: [location, unit], }, } } ] messages [{role: user, content: Whats the weather in Fahrenheit like in San Francisco?}] response client.chat.completions.create( modelclient.models.list().data[0].id, messagesmessages, toolstools, tool_choiceauto, ) tool_call response.choices[0].message.tool_calls[0].function messages.append( { role: assistant, tool_calls: response.choices[0].message.tool_calls, reasoning: response.choices[0].message.reasoning, # append reasoning } ) # Simulate tool execution available_tools {get_weather: get_current_weather} completion_tool_calls response.choices[0].message.tool_calls for call in completion_tool_calls: tool_to_call available_tools[call.function.name] args json.loads(call.function.arguments) result tool_to_call(**args) messages.append( { role: tool, content: result, tool_call_id: call.id, name: call.function.name, } ) response_2 client.chat.completions.create( modelclient.models.list().data[0].id, messagesmessages, toolstools, tool_choiceauto, ) print(response_2.choices[0].message.content)这段示例完整演示了交错思考的三步闭环第一轮用户提问 → 模型输出推理 工具调用tool_calls[0]此时message.reasoning携带本次工具调用前的思考内容上下文拼接把 assistant 消息含tool_calls与reasoning和role: tool的工具结果追加进messages第二轮模型收到工具结果后会先推理再回答——response_2的message.reasoning即为对工具结果的思考message.content为最终回答。推理字段的协议层支持回传 reasoning 才能维持推理链之所以成立是因为 vLLM 的 Chat Completions 协议把推理内容做成了一等字段请求侧assistant 历史消息支持reasoning键vllm/entrypoints/openai/chat_completion/protocol.py 中存在对msg.get(reasoning)的处理逻辑将客户端回传的推理内容并入渲染后的提示词响应侧消息体定义了reasoning: str | None字段同文件第 72 行附近流式与非流式都会填充另有include_reasoning: bool True的默认值该文件两处出现控制是否默认包含推理输出以及reasoning_effort参数用于支持按推理强度档位请求对支持该参数的模型会转成enable_thinking等用户侧开关。也就是说交错思考在协议层面的闭环是reasoning parser 把输出切分成 reasoning/content → API 返回message.reasoning→ 客户端回传 → chat template 将其重新注入提示词 → 模型基于完整推理历史继续思考。缺任何一环模型看到的历史都会丢失思考内容。实现链路总览结合源码结构一次交错思考请求在 vLLM 内部的处理链路如下从源码结构看各组件职责分离清晰解析引擎层vllm/parser/engine/parser_engine.py、streaming_parser_engine.py、incremental_lexer.py、token_id_scanner.py构成增量式流式解析框架。reasoning 与 tool call 两类事件由events.py定义registered_adapters.py将具体模型的解析规则适配到该引擎ReasoningParser 抽象层vllm/reasoning/abs_reasoning_parsers.py定义ReasoningParser基类与ReasoningParserManager各模型解析器通过 vllm/reasoning/init.py 中的注册表懒加载工具解析层vllm/tool_parsers/kimi_k2_tool_parser.py、minimax_m2_tool_parser.py等分别解析两种模型的 【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM 交错思考（Interleaved Thinking）实战：在工具调用之间让模型“边想边调“
vLLM 交错思考Interleaved Thinking实战在工具调用之间让模型边想边调【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm本篇基于 vLLM 仓库中的 Interleaved Thinking 特性文档系统讲解交错思考在工具调用之间穿插推理在 vLLM 中的工作原理、启用方式与完整调用链读者将掌握如何用--reasoning-parser与--tool-call-parser组合启用该特性如何在多轮对话中把推理过程reasoning原样回传给模型以及背后 Kimi-K2 / MiniMax-M2 两类推理解析器ReasoningParser的源码实现与流式行为。什么是交错思考Interleaved Thinking交错思考允许模型在多次工具调用之间进行推理模型发起一次工具调用、拿到工具结果后不是直接生成最终回答而是先对结果进行一段推理thinking再决定下一步动作。由此可以实现在决定下一步之前先对工具调用的结果进行推理在多个工具调用之间穿插推理步骤形成调用 → 推理 → 再调用的链条基于中间结果做出更细致的判断对外暴露其选择工具的透明推理过程。文档同时给出重要提示交错思考会增加 token 消耗和响应延迟每多一轮推理就多一段思考 token。启用前应权衡预算与性能要求——如果你的 Agent 场景以少量、确定性强的工具调用为主未必需要开启。与普通思考模型的区别普通思考模型如 DeepSeek-R1 类只在最终回答前输出一段think推理交错思考则把推理步骤插入到工具调用循环内部用户消息 → 推理 1 → 工具调用 1 → 工具结果 1 → 推理 2 → 工具调用 2 → 工具结果 2 → 推理 3 → 最终回答因此对服务端的两个核心要求是能正确切分模型输出中的推理部分与正文部分reasoning parser能正确识别与解析工具调用tool call parser并支持客户端在下一轮把上一次的 reasoning 作为 assistant 消息的一部分回传保证多轮上下文完整。vLLM 中支持交错思考的模型根据 docs/features/interleaved_thinking.mdvLLM 当前支持的交错思考模型及其对应的 Reasoning Parser 名称如下模型系列Reasoning Parser 名称moonshotai/Kimi-K2-Thinkingkimi_k2MiniMaxAI/MiniMax-M2minimax_m2这两个名称是--reasoning-parser命令行参数的取值。它们并非独立的 Python 手写解析器而是注册到 vLLM 统一解析引擎Parser Engine中的适配器kimi_k2在 vllm/reasoning/kimi_k2_reasoning_parser.py 中直接别名到vllm.parser.engine.registered_adapters里的KimiK2ParserReasoningAdapter解析逻辑统一由vllm/parser/下的解析器如 vllm/parser/kimi_k2.py驱动minimax_m2在 vllm/reasoning/minimax_m2_reasoning_parser.py 中定义了MiniMaxM2ReasoningParser与MiniMaxM2AppendThinkReasoningParser两个实现。所有可用的 parser 名称在 vllm/reasoning/init.py 的_REASONING_PARSERS_TO_REGISTER注册表中统一定义kimi_k2指向kimi_k2_reasoning_parser.KimiK2ReasoningParserminimax_m2指向MiniMaxM2ReasoningParser另有minimax_m2_append_think变体并通过ReasoningParserManager懒加载注册——--reasoning-parser传的名称必须能在此注册表中找到。MiniMax-M2 解析器的实现细节MiniMax-M2 的推理格式有一个特殊之处见源码注释模型不生成think起始 token只生成/think结束 token/think之前的所有内容都是推理之后是正式回答。vllm/reasoning/minimax_m2_reasoning_parser.py 中的核心方法体现这一语义is_reasoning_end(input_ids)从后向前扫描 token找到最后一个/thinkend token或thinkstart token只有当它是 end token 时返回 True。这使得服务端能判断推理阶段是否已结束从而在流式输出时决定 delta 进入reasoning还是content字段extract_content_ids(input_ids)直接返回全部 token id内容边界由 token 位置确定而非标记切分。仓库内对应的单元测试 tests/reasoning/test_minimax_m2_reasoning_parser.py 覆盖了多种边界场景均可作为行为依据测试用例模型输出期望 reasoning期望 contentsimple_reasoningThis is a reasoning section/thinkThis is the restThis is a reasoning sectionThis is the restno_end_token流式中This is reasoning in progress同左None推理未结束全部算 reasoningmultiple_lines多行推理 多行回答多行推理部分多行回答部分code_in_reasoning推理中含代码块含代码块的推理Here is the code.empty_streaming空输出NoneNone这些用例验证了只要/think尚未出现流式输出期间所有 delta 都归入 reasoning出现/think后 delta 才切换到 content。这正是交错思考在工具结果 → 模型再次思考阶段的关键行为——工具结果回传后模型先吐出的新 token 会先进入 reasoning 流。启用方式服务端启动与请求参数服务端启动以 MiniMax-M2 为例需要同时启用 tool call parser 与 reasoning parser并打开自动工具选择vllm serve MiniMaxAI/MiniMax-M2 \ --tensor-parallel-size 4 \ --tool-call-parser minimax_m2 \ --reasoning-parser minimax_m2 \ --enable-auto-tool-choice各参数含义结合 vllm/engine/arg_utils.py 中的参数定义--tool-call-parser minimax_m2注册工具调用解析器负责把模型输出中的工具调用标记解析为 OpenAI 格式的tool_calls结构--reasoning-parser minimax_m2注册推理解析器。源码中该参数属于StructuredOutputsConfig.reasoning_parserarg_utils.py 中reasoning_parser字段默认取StructuredOutputsConfig.reasoning_parser随后写入self.reasoning_config.reasoning_parser即推理切分能力挂在结构化输出/推理配置体系下--enable-auto-tool-choice允许模型自行决定是否调用工具对应请求中的tool_choiceauto。对 Kimi-K2-Thinking 服务同样思路将两处 parser 名换成kimi_k2vllm serve moonshotai/Kimi-K2-Thinking \ --tool-call-parser kimi_k2 \ --reasoning-parser kimi_k2 \ --enable-auto-tool-choice客户端带推理回传的两轮工具调用下面是原文档给出的完整可运行示例天气查询工具其要点是第二轮回传 assistant 消息时必须带上reasoning字段否则模型丢失上一轮的思考上下文交错推理链会断裂。 vllm serve MiniMaxAI/MiniMax-M2 \ --tensor-parallel-size 4 \ --tool-call-parser minimax_m2 \ --reasoning-parser minimax_m2 \ --enable-auto-tool-choice import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) def get_current_weather(location: str, unit: str): Get the current weather in a given location if unit celsius: return fThe current temperature in {location} is 22°C. else: return fThe current temperature in {location} is 72°F. tools [ { type: function, function: { name: get_weather, description: Get the current weather in a given location, parameters: { type: object, properties: { location: { type: string, description: City and state, e.g., San Francisco, CA, }, unit: {type: string, enum: [celsius, fahrenheit]}, }, required: [location, unit], }, } } ] messages [{role: user, content: Whats the weather in Fahrenheit like in San Francisco?}] response client.chat.completions.create( modelclient.models.list().data[0].id, messagesmessages, toolstools, tool_choiceauto, ) tool_call response.choices[0].message.tool_calls[0].function messages.append( { role: assistant, tool_calls: response.choices[0].message.tool_calls, reasoning: response.choices[0].message.reasoning, # append reasoning } ) # Simulate tool execution available_tools {get_weather: get_current_weather} completion_tool_calls response.choices[0].message.tool_calls for call in completion_tool_calls: tool_to_call available_tools[call.function.name] args json.loads(call.function.arguments) result tool_to_call(**args) messages.append( { role: tool, content: result, tool_call_id: call.id, name: call.function.name, } ) response_2 client.chat.completions.create( modelclient.models.list().data[0].id, messagesmessages, toolstools, tool_choiceauto, ) print(response_2.choices[0].message.content)这段示例完整演示了交错思考的三步闭环第一轮用户提问 → 模型输出推理 工具调用tool_calls[0]此时message.reasoning携带本次工具调用前的思考内容上下文拼接把 assistant 消息含tool_calls与reasoning和role: tool的工具结果追加进messages第二轮模型收到工具结果后会先推理再回答——response_2的message.reasoning即为对工具结果的思考message.content为最终回答。推理字段的协议层支持回传 reasoning 才能维持推理链之所以成立是因为 vLLM 的 Chat Completions 协议把推理内容做成了一等字段请求侧assistant 历史消息支持reasoning键vllm/entrypoints/openai/chat_completion/protocol.py 中存在对msg.get(reasoning)的处理逻辑将客户端回传的推理内容并入渲染后的提示词响应侧消息体定义了reasoning: str | None字段同文件第 72 行附近流式与非流式都会填充另有include_reasoning: bool True的默认值该文件两处出现控制是否默认包含推理输出以及reasoning_effort参数用于支持按推理强度档位请求对支持该参数的模型会转成enable_thinking等用户侧开关。也就是说交错思考在协议层面的闭环是reasoning parser 把输出切分成 reasoning/content → API 返回message.reasoning→ 客户端回传 → chat template 将其重新注入提示词 → 模型基于完整推理历史继续思考。缺任何一环模型看到的历史都会丢失思考内容。实现链路总览结合源码结构一次交错思考请求在 vLLM 内部的处理链路如下从源码结构看各组件职责分离清晰解析引擎层vllm/parser/engine/parser_engine.py、streaming_parser_engine.py、incremental_lexer.py、token_id_scanner.py构成增量式流式解析框架。reasoning 与 tool call 两类事件由events.py定义registered_adapters.py将具体模型的解析规则适配到该引擎ReasoningParser 抽象层vllm/reasoning/abs_reasoning_parsers.py定义ReasoningParser基类与ReasoningParserManager各模型解析器通过 vllm/reasoning/init.py 中的注册表懒加载工具解析层vllm/tool_parsers/kimi_k2_tool_parser.py、minimax_m2_tool_parser.py等分别解析两种模型的 【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考