Nex-N2.5-mini 边缘端部署SGLang 智能体推理 函数调用最新姿势在开源智能体模型这条赛道上能想、会动手正在成为新的及格线模型不仅要会生成文本还要能在多轮工具调用中自主规划、执行并依据反馈自纠错。Nex-N2.5 家族给出的答案是Agentic 视觉反馈闭环而其中的Nex-N2.5-mini则被设计成这一家族中最贴近轻量算力环境的一档——2 张 H100 即可完整部署社区实测中它甚至能以更低的激活参数规模跑出接近大杯模型的工具调用与智能体成绩。本文不聊宣传话术直接打开仓库源码从config.json、chat_template.jinja与官方部署脚本出发把 SGLang 运行时配置、思维链CoT模式与函数调用提示工程这三件事一次讲透。轻量 MoE 的底子为什么 mini 适合边缘算力先把事实摆出来。仓库根目录的 config.json 完整定义了 Nex-N2.5-mini 的模型结构架构为Qwen3_5MoeForConditionalGeneration属 Qwen3.5 系列 MoE 血统60 层 Transformer 中以full_attention_interval: 4为节奏交替排布线性注意力linear_attention与全注意力full_attention绝大多数层走线性注意力路径显著摊薄了长上下文的 KV 计算成本MoE 侧num_experts: 512、num_experts_per_tok: 10每 token 只激活 10 个专家配合moe_intermediate_size: 1024激活参数占比极低max_position_embeddings: 262144即 256K 上下文窗口配合 M-RoPEmrope_interleaved: true支撑多模态位置编码权重层面已经内置 FP8 量化quantization_config中采用 compressed-tensors 的FP8_BLOCK方案以 128×128 block 为单位做对称浮点量化同时精细地ignore了视觉层、embed_tokens、lm_head 以及各层 shared_expert gate 等敏感张量。这套配置意味着什么对于 MoE 模型决定推理成本的关键从来不是总参数量而是激活参数量。社区对 Nex-N2 一代 mini 的拆解显示其约 35B 总参、仅 3B 激活参数N2.5-mini 延续了这一稀疏激活设计哲学。在基准表现上README 公开数据给出 mini 在 Toolathlon Verified 达 54.6、BrowseComp 达 83.4、OSWorld-Verified 达 71.2且其在文本侧 Terminal-Bench 2.1 拿到 73.4——这是相对 Pro/Max 明显更低算力门槛下仍然可用的智能体能力。模型加载与 SGLang 运行时配置Nex-N2.5 家族的官方推理路径是 SGLang。仓库 README 指出官方提供了内置定制版 SGLang 的预构建镜像nexagi/sglang:v0.5.18-nex-patchmini 的推荐部署为单节点 2×H100docker run --gpus all --shm-size 32g --ipchost \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.18-nex-patch \ python3 -m sglang.launch_server \ --model-path /model \ --tp 2 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-mini/chat-template.jinja \ --mamba-scheduler-strategy extra_buffer这串参数里藏着三个关键决策点逐一拆解其一架构兼容。模型架构是Qwen3_5MoeForConditionalGeneration属于 transformers 5.8 时代的自定义 MoE 实现启动时务必带上--trust-remote-code并确保 SGLang 版本与官方 fork 一致——社区部署踩坑记录里最普遍的报错就是架构未注册 / 权重加载失败几乎都源于版本不匹配或远程代码未授权。其二Chat Template 必须显式指定。官方 README 对三个尺寸的命令都强制传入了--chat-template .../chat_template.jinja。这个模板仓库根目录 chat_template.jinja实现了三件非标准事情工具注册的 XML 包装、think思维链标签的注入、以及多轮工具响应tool_response的拼接。如果省略该参数SGLang 回退到默认模板思维链与函数调用都会错乱——这是提示工程层面对齐的硬性前提。其三解析器分离。--reasoning-parser qwen3负责把模型的思维轨迹从最终回答中剥离出来对应--reasoning-parser deepseek-r1是 Max 的配置--tool-call-parser qwen3_coder负责把模型输出的tool_callXML 解析为结构化函数调用。两者缺一客户端拿到的就是思维与回答混在一起、工具调用未被结构化的裸输出。启动后即可用 OpenAI 兼容协议请求。README 同时给出了推荐采样参数temperature0.7、top_p0.95、top_k40——这一组与官方基准评估所用参数一致是复现 README 成绩的前提。思维链模式与函数工具注册的提示工程适配Nex-N2.5 的思考行为由一个统一开关控制reasoning_effort。README 定义了三种模式reasoning_effort模式行为none非思考直接回答不产出推理轨迹medium默认自适应思考由模型自行决定是否思考、思考多久high思考总是先思考再回答请求侧的使用方式如下served-model-name替换为服务暴露的模型名{ model: served-model-name, messages: [ {role: user, content: 请帮我查询今日上海天气并计算体感温度} ], reasoning_effort: medium }这个开关是如何落到模板里的打开 chat_template.jinja 的最后一段add_generation_prompt分支会根据reasoning_effort的值决定生成think继续推理还是think\n\n/think\n\n空思维、直接回答。而 assistant 消息在回写时会被统一包裹成think.../think\n\n 正文的结构模板也会自动从历史消息里剥离think块——这就是--reasoning-parser qwen3能拿到纯净思维链的底层机制。README 特别提醒enable_thinking/thinking_mode这类参数需要在网关层做翻译模板认的是reasoning_effort。函数调用的注册与输出格式则完全由模板定义。当请求携带tools时模板会在 system 消息里注入# Tools You have access to the following functions: tools {每个工具的 JSON 定义name/description/parameters} /tools If you choose to call a function ONLY reply in the following format with NO suffix: tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call注意这里的三个工程细节工具定义按 JSON 序列化后塞进tools标签模型侧看到的是一份标准的 OpenAPI 风格 schema这与qwen3_coder解析器的预期输入一致输出强制使用 XML 而非 JSONtool_call内层嵌套function...参数以parameter参数名包裹且允许参数值跨多行——这对携带长代码片段或大段文本的调用非常友好模板明令推理在调用之前不得在调用之后模型可以先用自然语言给出一句理由再紧跟函数调用IMPORTANT段落同时要求若无需调用函数就按普通问答处理且不要向用户提及函数调用——这一约束对抑制模型为调用而调用的倾向很有效。多轮工具交互由模板的multi_step_tool逻辑支撑工具执行结果必须以tool_response\n...\n/tool_response的形式作为 user 消息回填模板会逆序扫描消息确保最后一条 user 消息是真实查询而非工具回包从而正确构造下一轮生成。整体上一个标准智能体循环是请求 → 模型think规划 → 输出tool_call→ 解析器转结构化 → 执行工具 →tool_response回填 → 模型依据反馈继续或收敛。边缘端算力下的性能调优建议综合仓库配置与社区实测经验在受限算力环境下跑 mini 有四个明确的优化方向1. 用好 FP8 与低激活参数的红利。mini 权重已内置 FP8 block 量化config.json 中quantization_config可见无需二次转换即可在支持 FP8 的卡上直接低显存加载而每 token 仅激活 10/512 专家意味着 decode 阶段的实际计算量远小于同体量稠密模型这是它能2 卡起步的根本原因。社区进一步验证过将 Nex-N2.5-mini 转 GGUF 后在安卓端侧用 MNN 推理的方案教育、工具类 App 是典型适配场景——如果你的目标平台连 H100 都没有走 GGUF/Q4_K_M 量化链路是现实选择。2. 控制上下文预算与 KV 缓存。mini 支持 262144 token 上下文但边缘端没有必要也不应该全量开放。建议在网关层给每个请求设定更紧的max_tokens与上下文截断策略README 对 Max 的命令中给出的--kv-cache-dtype fp8_e4m3、--page-size 256、--chunked-prefill-size 8192等参数是 SGLang 官方的内存-吞吐优化手段mini 环境同样适用可按显存余量酌情开启。3. 采样参数按场景分档。README 的默认推荐0.7 / 0.95 / 40面向一般智能体任务若需要稳定复现、可验证的编码或工具调用结果可适度降低 temperature若追求低延迟的流式对话建议将reasoning_effort设为none或medium——因为high强制思考会显著拉长首 token 延迟这在边缘实时场景里往往是不可接受的。4. 让推理与调用各归其位。部署时务必同时保留--reasoning-parser qwen3与--tool-call-parser qwen3_coder并显式传入官方chat_template.jinja。这三个开关是一套耦合的提示工程协议模板负责教会模型怎么想、怎么调用解析器负责把产物拆成结构化的思维 工具调用 回答。省略任何一个智能体循环都会退化成普通的补全输出。小结Nex-N2.5-mini 的价值不在于参数绝对值而在于轻量架构 完整智能体协议的组合线性注意力与稀疏 MoE 压低算力门槛256K 上下文与多模态视觉保留长任务能力而 chat_template.jinja 与 SGLang 解析器把思维链和函数调用固化成了一套可复制的工程协议。对于想把会思考、会调工具的 Agent 能力压到边缘算力上的团队这套官方模板 qwen3/qwen3_coder 双解析器 FP8 量化权重的部署组合是目前最短的落地路径。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Nex-N2.5-mini 边缘端部署SGLang 智能体推理 函数调用最新姿势在开源智能体模型这条赛道上能想、会动手正在成为新的及格线模型不仅要会生成文本还要能在多轮工具调用中自主规划、执行并依据反馈自纠错。Nex-N2.5 家族给出的答案是Agentic 视觉反馈闭环而其中的Nex-N2.5-mini则被设计成这一家族中最贴近轻量算力环境的一档——2 张 H100 即可完整部署社区实测中它甚至能以更低的激活参数规模跑出接近大杯模型的工具调用与智能体成绩。本文不聊宣传话术直接打开仓库源码从config.json、chat_template.jinja与官方部署脚本出发把 SGLang 运行时配置、思维链CoT模式与函数调用提示工程这三件事一次讲透。轻量 MoE 的底子为什么 mini 适合边缘算力先把事实摆出来。仓库根目录的 config.json 完整定义了 Nex-N2.5-mini 的模型结构架构为Qwen3_5MoeForConditionalGeneration属 Qwen3.5 系列 MoE 血统60 层 Transformer 中以full_attention_interval: 4为节奏交替排布线性注意力linear_attention与全注意力full_attention绝大多数层走线性注意力路径显著摊薄了长上下文的 KV 计算成本MoE 侧num_experts: 512、num_experts_per_tok: 10每 token 只激活 10 个专家配合moe_intermediate_size: 1024激活参数占比极低max_position_embeddings: 262144即 256K 上下文窗口配合 M-RoPEmrope_interleaved: true支撑多模态位置编码权重层面已经内置 FP8 量化quantization_config中采用 compressed-tensors 的FP8_BLOCK方案以 128×128 block 为单位做对称浮点量化同时精细地ignore了视觉层、embed_tokens、lm_head 以及各层 shared_expert gate 等敏感张量。这套配置意味着什么对于 MoE 模型决定推理成本的关键从来不是总参数量而是激活参数量。社区对 Nex-N2 一代 mini 的拆解显示其约 35B 总参、仅 3B 激活参数N2.5-mini 延续了这一稀疏激活设计哲学。在基准表现上README 公开数据给出 mini 在 Toolathlon Verified 达 54.6、BrowseComp 达 83.4、OSWorld-Verified 达 71.2且其在文本侧 Terminal-Bench 2.1 拿到 73.4——这是相对 Pro/Max 明显更低算力门槛下仍然可用的智能体能力。模型加载与 SGLang 运行时配置Nex-N2.5 家族的官方推理路径是 SGLang。仓库 README 指出官方提供了内置定制版 SGLang 的预构建镜像nexagi/sglang:v0.5.18-nex-patchmini 的推荐部署为单节点 2×H100docker run --gpus all --shm-size 32g --ipchost \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.18-nex-patch \ python3 -m sglang.launch_server \ --model-path /model \ --tp 2 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-mini/chat-template.jinja \ --mamba-scheduler-strategy extra_buffer这串参数里藏着三个关键决策点逐一拆解其一架构兼容。模型架构是Qwen3_5MoeForConditionalGeneration属于 transformers 5.8 时代的自定义 MoE 实现启动时务必带上--trust-remote-code并确保 SGLang 版本与官方 fork 一致——社区部署踩坑记录里最普遍的报错就是架构未注册 / 权重加载失败几乎都源于版本不匹配或远程代码未授权。其二Chat Template 必须显式指定。官方 README 对三个尺寸的命令都强制传入了--chat-template .../chat_template.jinja。这个模板仓库根目录 chat_template.jinja实现了三件非标准事情工具注册的 XML 包装、think思维链标签的注入、以及多轮工具响应tool_response的拼接。如果省略该参数SGLang 回退到默认模板思维链与函数调用都会错乱——这是提示工程层面对齐的硬性前提。其三解析器分离。--reasoning-parser qwen3负责把模型的思维轨迹从最终回答中剥离出来对应--reasoning-parser deepseek-r1是 Max 的配置--tool-call-parser qwen3_coder负责把模型输出的tool_callXML 解析为结构化函数调用。两者缺一客户端拿到的就是思维与回答混在一起、工具调用未被结构化的裸输出。启动后即可用 OpenAI 兼容协议请求。README 同时给出了推荐采样参数temperature0.7、top_p0.95、top_k40——这一组与官方基准评估所用参数一致是复现 README 成绩的前提。思维链模式与函数工具注册的提示工程适配Nex-N2.5 的思考行为由一个统一开关控制reasoning_effort。README 定义了三种模式reasoning_effort模式行为none非思考直接回答不产出推理轨迹medium默认自适应思考由模型自行决定是否思考、思考多久high思考总是先思考再回答请求侧的使用方式如下served-model-name替换为服务暴露的模型名{ model: served-model-name, messages: [ {role: user, content: 请帮我查询今日上海天气并计算体感温度} ], reasoning_effort: medium }这个开关是如何落到模板里的打开 chat_template.jinja 的最后一段add_generation_prompt分支会根据reasoning_effort的值决定生成think继续推理还是think\n\n/think\n\n空思维、直接回答。而 assistant 消息在回写时会被统一包裹成think.../think\n\n 正文的结构模板也会自动从历史消息里剥离think块——这就是--reasoning-parser qwen3能拿到纯净思维链的底层机制。README 特别提醒enable_thinking/thinking_mode这类参数需要在网关层做翻译模板认的是reasoning_effort。函数调用的注册与输出格式则完全由模板定义。当请求携带tools时模板会在 system 消息里注入# Tools You have access to the following functions: tools {每个工具的 JSON 定义name/description/parameters} /tools If you choose to call a function ONLY reply in the following format with NO suffix: tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call注意这里的三个工程细节工具定义按 JSON 序列化后塞进tools标签模型侧看到的是一份标准的 OpenAPI 风格 schema这与qwen3_coder解析器的预期输入一致输出强制使用 XML 而非 JSONtool_call内层嵌套function...参数以parameter参数名包裹且允许参数值跨多行——这对携带长代码片段或大段文本的调用非常友好模板明令推理在调用之前不得在调用之后模型可以先用自然语言给出一句理由再紧跟函数调用IMPORTANT段落同时要求若无需调用函数就按普通问答处理且不要向用户提及函数调用——这一约束对抑制模型为调用而调用的倾向很有效。多轮工具交互由模板的multi_step_tool逻辑支撑工具执行结果必须以tool_response\n...\n/tool_response的形式作为 user 消息回填模板会逆序扫描消息确保最后一条 user 消息是真实查询而非工具回包从而正确构造下一轮生成。整体上一个标准智能体循环是请求 → 模型think规划 → 输出tool_call→ 解析器转结构化 → 执行工具 →tool_response回填 → 模型依据反馈继续或收敛。边缘端算力下的性能调优建议综合仓库配置与社区实测经验在受限算力环境下跑 mini 有四个明确的优化方向1. 用好 FP8 与低激活参数的红利。mini 权重已内置 FP8 block 量化config.json 中quantization_config可见无需二次转换即可在支持 FP8 的卡上直接低显存加载而每 token 仅激活 10/512 专家意味着 decode 阶段的实际计算量远小于同体量稠密模型这是它能2 卡起步的根本原因。社区进一步验证过将 Nex-N2.5-mini 转 GGUF 后在安卓端侧用 MNN 推理的方案教育、工具类 App 是典型适配场景——如果你的目标平台连 H100 都没有走 GGUF/Q4_K_M 量化链路是现实选择。2. 控制上下文预算与 KV 缓存。mini 支持 262144 token 上下文但边缘端没有必要也不应该全量开放。建议在网关层给每个请求设定更紧的max_tokens与上下文截断策略README 对 Max 的命令中给出的--kv-cache-dtype fp8_e4m3、--page-size 256、--chunked-prefill-size 8192等参数是 SGLang 官方的内存-吞吐优化手段mini 环境同样适用可按显存余量酌情开启。3. 采样参数按场景分档。README 的默认推荐0.7 / 0.95 / 40面向一般智能体任务若需要稳定复现、可验证的编码或工具调用结果可适度降低 temperature若追求低延迟的流式对话建议将reasoning_effort设为none或medium——因为high强制思考会显著拉长首 token 延迟这在边缘实时场景里往往是不可接受的。4. 让推理与调用各归其位。部署时务必同时保留--reasoning-parser qwen3与--tool-call-parser qwen3_coder并显式传入官方chat_template.jinja。这三个开关是一套耦合的提示工程协议模板负责教会模型怎么想、怎么调用解析器负责把产物拆成结构化的思维 工具调用 回答。省略任何一个智能体循环都会退化成普通的补全输出。小结Nex-N2.5-mini 的价值不在于参数绝对值而在于轻量架构 完整智能体协议的组合线性注意力与稀疏 MoE 压低算力门槛256K 上下文与多模态视觉保留长任务能力而 chat_template.jinja 与 SGLang 解析器把思维链和函数调用固化成了一套可复制的工程协议。对于想把会思考、会调工具的 Agent 能力压到边缘算力上的团队这套官方模板 qwen3/qwen3_coder 双解析器 FP8 量化权重的部署组合是目前最短的落地路径。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
