Nex-N2.5-Pro 硬核拆解512 专家 MoE 256K 上下文 FP8小参数高性能路线怎么炼成的在动辄万亿参数的大模型竞赛中Nex-N2.5-Pro 走了一条截然不同的路线它不追求把整个模型塞进显存而是用512 专家、每 token 仅激活 10 个的稀疏 MoE 架构把总参数量很大、激活参数量很小这对矛盾统一起来再叠加 256K 上下文、多模态视觉输入与 FP8 压缩最终实现单机 8×H100 即可部署的工程目标。发布之后社区围绕它的评测、部署教程与选型对比迅速铺开——有人关心它在 OSWorld 等操作电脑基准上的表现有人关心 8 卡部署的成本账也有人直接上手把模型塞进本地推理框架。本文基于仓库源码config.json、README.md、chat_template.jinja、processor_config.json 等逐层拆解这套小参数高性能路线背后的设计决策。从一张 config.json 看架构全貌在动手部署之前先看仓库根目录下的 config.json。它暴露了 Pro 的完整骨架architectures: [Qwen3_5MoeForConditionalGeneration], hidden_size: 4096, num_hidden_layers: 60, num_experts: 512, num_experts_per_tok: 10, moe_intermediate_size: 1024, shared_expert_intermediate_size: 1024, num_attention_heads: 32, num_key_value_heads: 2, head_dim: 256, max_position_embeddings: 262144, vocab_size: 248320关键信息一目了然60 层 Transformer、隐藏维 4096、512 个细粒度专家、每 token 路由10 个专家、并额外配置了一个共享专家shared_expert最大位置编码 262144即 256K。注意力部分采用 GQA 设计32 个 query 头、仅 2 个 KV 头、head_dim 256显著压缩 KV cache 占用——这是 256K 长上下文能跑得动的前提之一。粗略按 512 × 1024 × 4096 估算单层 MoE 的参数量就超过 60 亿60 层累计到数百亿参数的规模但每 token 只激活 10 个专家加 1 个共享专家实际参与计算的参数只有总量的零头。这就是总参大、激活小的稀疏化范式模型容量大推理开销小。512 专家 × 激活 10稀疏化如何把大做成小细粒度专家 共享专家的组合Pro 采用了当前 MoE 主流的两项设计。其一是细粒度专家fine-grained experts把 MoE 中间维度压到 1024moe_intermediate_size: 1024换来 512 路更垂直的专家分工其二是共享专家兜底路由只挑 10 个专家但每个 token 都额外流过共享专家shared_expert_intermediate_size: 1024保证通用知识与常用能力不被稀疏路由漏掉。路由质量则靠配置里的两项参数约束router_aux_loss_coef: 0.001, output_router_logits: falserouter_aux_loss_coef是辅助负载均衡损失的权重系数抑制专家使用失衡output_router_logits关闭了训练期的 logits 输出推理时不额外产出路由开销。这也是 512 路专家在推理侧可以保持低延迟的原因——路由只是一个小型门控网络真正的计算集中在这 101 个专家上。每 4 层一次全注意力长上下文下的注意力预算config.json中full_attention_interval: 4配合 60 层的layer_types数组给出了一个非常清晰的模式60 层中只有 15 层使用标准全注意力其余 45 层全部是线性注意力linear_attention。layer_types: [linear_attention, linear_attention, linear_attention, full_attention, ...], linear_num_key_heads: 16, linear_num_value_heads: 64, linear_key_head_dim: 128, linear_value_head_dim: 128, linear_conv_kernel_dim: 4, mamba_ssm_dtype: float32线性注意力层配置了 16 个 key 头、64 个 value 头并带一个linear_conv_kernel_dim: 4的卷积核——这是典型的类 Mamba / GLA混合设计用线性递推与局部卷积捕获短期与长期依赖把 O(n²) 的注意力开销摊平成近似线性的成本。15 层全注意力负责全局关系建模45 层线性注意力负责消化长序列两者按3 线性 1 全注意力的节奏交替。这解释了 256K 上下文为何不是纸面参数在真实长程 agent 任务浏览网页、操作电脑、长链路代码执行中序列长度动辄数万 token全注意力层的占比必须让位于线性方案推理才能跟上。256K 上下文与多模态输入的工程实现max_position_embeddings: 262144只是起点。真正让长上下文可用的是位置编码与多模态 token 设计的配合。rope_parameters: { mrope_interleaved: true, mrope_section: [11, 11, 10], partial_rotary_factor: 0.25, rope_theta: 10000000 }, partial_rotary_factor: 0.25,模型使用mRoPE多模态旋转位置编码mrope_section: [11, 11, 10]把 32 维位置信息分成文本、图像、视频三组mrope_interleaved: true让各组交错注入partial_rotary_factor: 0.25表示仅对 25% 的隐藏维度施加旋转其余维度保持非旋转状态——这是长距离外推的常见技巧配合rope_theta: 10000000千万级基频让位置编码在 256K 长度上不至于迅速饱和。图像、视频的位置由此被统一编码进同一套 RoPE 空间文本与视觉 token 可以在同一序列里自然对齐。视觉编码器来自 vision_config27 层 ViT、hidden 1152、patch 16×16、spatial_merge_size: 2、temporal_patch_size: 2输出投影到语言模型的 4096 维。语言模型侧预留了专用 tokenvision_start_token_id: 248053, vision_end_token_id: 248054, image_token_id: 248056, video_token_id: 248057chat_template.jinja 展示了这些 token 如何落进对话图像被渲染为|vision_start||image_pad||vision_end|视频同理并自动编号Picture 1:/Video 1:还强制禁止 system 消息携带图像。也就是说多模态不是外挂一个编码器糊上去而是从位置编码到模板都原生打通。processor_config.json 进一步揭示了视频处理能力fps: 2、max_frames: 768、min_frames: 4、temporal_patch_size: 2图像最长边支持到 16777216、视频到 25165824——足以容纳高分辨率截图与长视频。这个能力在基准上直接兑现README 中 OSWorld-2 得分 56.4、WebTest 52.8、Vision2Web 68.2这些看着屏幕操作的任务正是对视觉理解 长上下文 工具调用三重能力的综合检验。FP8 量化与 8×H100 一键部署的成本账压缩策略哪些层被量化、哪些被豁免config.json中的quantization_config是全文工程含量最高的部分。它使用compressed-tensors框架、FP8_BLOCK方案、状态compressedquant_method: compressed-tensors, FP8_BLOCK: { weights: { num_bits: 8, type: float, symmetric: true, strategy: block, block_structure: [128, 128] }, input_activations: { num_bits: 8, type: float, symmetric: true, strategy: group, group_size: 128, dynamic: true } }权重采用128×128 块级 FP8每 128×128 块一个缩放因子激活采用group_size 128 的动态 8bit 量化——块级量化比逐张量量化精度更高动态激活缩放则能适配不同 token 的数值范围。更关键的是它的ignore名单视觉模块、embed_tokens、lm_head、mlp.gate、shared_expert_gate、linear_attn.conv1d / in_proj_a / in_proj_b等全部豁免量化保持 BF16 精度。这个选择非常讲究嵌入层与输出层对量化误差最敏感门控与线性注意力的卷积/投影路径参数量小但数值敏感量化反而得不偿失。哪里必须保精度、哪里可以省显存被拆解到了层粒度这是 FP8 方案能保住基准分数的工程前提。部署成本对比README.md 给出的 Pro 部署命令非常简洁——单机 8×H100Tensor Parallel 8一条 docker run 起服务docker 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 8 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-Pro/chat-template.jinja \ --mamba-scheduler-strategy extra_buffer三个细节值得注意。其一推理框架是官方定制 fork 的 SGLangv0.5.18-nex-patch其中--mamba-scheduler-strategy extra_buffer专门为线性注意力层的状态管理预留缓冲说明这类混合架构需要推理引擎侧的针对性适配而不是拿通用 vLLM 就能跑其二--tool-call-parser qwen3_coder与--reasoning-parser qwen3负责把模型的思考轨迹与工具调用从正文中拆出来配合 chat_template.jinja 中think与tool_callfunction...的 XML 格式——函数调用、思考模式与部署是一体的其三对比家族其他成员成本梯度非常清晰Nex-N2.5-mini2×H100 即可部署面向嵌入式与轻量智能体场景Nex-N2.5-Pro8×H100 单机部署多模态 电脑操作主力档位Nex-N2.5-Max1.6 万亿参数纯文本 MoE需 2 节点 16×H200。以 400B 量级的参数规模估算FP8 权重约每参数 1 字节总权重约 400GB8×H10080GB 显存合计 640GB扣除 KV cache 与激活后仍然放得下——如果不做 FP8这个账就算不过来了。量化把部署门槛从多机集群压回单机 8 卡这正是 Pro 能被大量企业直接上手的原因。基准验证稀疏架构的成色稀疏化不是免费的午餐路由偏差与量化误差都可能掉点。Nex-N2.5 官方在 README.md 公布了全套评测采样参数统一为 temperature 0.7 / top_p 0.95 / top_k 40Pro 的关键成绩如下类别基准Nex-N2.5-Pro编码Terminal-Bench 2.182.7编码SWE-Bench Pro61.2编码DeepSWE v1.155.8AgentAutomationBench v1.0.644.2AgentToolathlon Verified68.5AgentBrowseComp89.7AgentJob Bench41.4多模态OSWorld-Verified82.2多模态OSWorld-256.4多模态OSWorld-G87.4多模态Vision2Web68.2多模态WebArena-Verified67.6多模态WebTest52.8多模态SWE-MM38.2多模态OmniDoc92.2这套结果与社区观察互相印证CSDN 上关于认识 Nex-N2.5-Pro的概览文章强调其512 专家/激活 10、256K 上下文、FP8 量化、8×H100 一键部署、Apache 2.0 开源与仓库配置逐条吻合另一篇mini/Pro/Max 三档怎么选的对比文章则直接给出了按算力选型的结论——Pro 主打多模态电脑操作在 OSWorld 一类基准上表现最优。值得注意的是 OSWorld-G87.4是表中 Pro 拿下的唯一榜首成绩说明在通用图形界面操作这个细分场景上Pro 已经具备与一线闭源模型正面对抗的能力而在 BrowseComp 这类长程检索任务上 89.7 的成绩则直接受益于 256K 上下文与线性注意力——上下文越长检索越深这个数字就越有含金量。小结小参数高性能路线的三点启示回到标题的问题Nex-N2.5-Pro 的小参数高性能到底是怎么炼成的从源码看答案可以凝练为三点用稀疏化换取容量用共享专家保住下限。512 专家 10 激活 1 共享专家的组合让数百亿参数的模型保持每 token 只算约十分之一的推理成本同时共享专家确保通用能力不因路由而丢失。用混合注意力换取上下文用 mRoPE 打通多模态。60 层中 45 层线性注意力 15 层全注意力的交替结构让 256K 上下文从参数表上的数字变成可实际运行的长程 agent 任务mRoPE 的三段式位置编码让图像、视频与文本在同一序列中共存。用层粒度 FP8 换取部署可行性用定制推理栈兑现性能。128×128 块级权重量化 动态激活量化配合对嵌入层、门控、线性注意力关键路径的精准豁免把 400B 量级的模型压进 8×H100 单机——从 config.json 到 README.md 的部署命令整条链路都是为工程可落地服务的。在大模型普遍越大越贵的当下Nex-N2.5-Pro 展示的是另一种可能性不在总参数量上做军备竞赛而在单位显存与单位 token 的智能密度上做文章。512 专家的细粒度分工、线性注意力的长程消化、FP8 的层粒度压缩——每一项都不是孤立的技术选择而是围绕让 agent 在真实环境里长时间干活这一个目标层层咬合的工程决策。这套路线的下一步会走向哪里值得持续跟踪。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nex-N2.5-Pro 硬核拆解：512 专家 MoE + 256K 上下文 + FP8，小参数高性能路线怎么炼成的
Nex-N2.5-Pro 硬核拆解512 专家 MoE 256K 上下文 FP8小参数高性能路线怎么炼成的在动辄万亿参数的大模型竞赛中Nex-N2.5-Pro 走了一条截然不同的路线它不追求把整个模型塞进显存而是用512 专家、每 token 仅激活 10 个的稀疏 MoE 架构把总参数量很大、激活参数量很小这对矛盾统一起来再叠加 256K 上下文、多模态视觉输入与 FP8 压缩最终实现单机 8×H100 即可部署的工程目标。发布之后社区围绕它的评测、部署教程与选型对比迅速铺开——有人关心它在 OSWorld 等操作电脑基准上的表现有人关心 8 卡部署的成本账也有人直接上手把模型塞进本地推理框架。本文基于仓库源码config.json、README.md、chat_template.jinja、processor_config.json 等逐层拆解这套小参数高性能路线背后的设计决策。从一张 config.json 看架构全貌在动手部署之前先看仓库根目录下的 config.json。它暴露了 Pro 的完整骨架architectures: [Qwen3_5MoeForConditionalGeneration], hidden_size: 4096, num_hidden_layers: 60, num_experts: 512, num_experts_per_tok: 10, moe_intermediate_size: 1024, shared_expert_intermediate_size: 1024, num_attention_heads: 32, num_key_value_heads: 2, head_dim: 256, max_position_embeddings: 262144, vocab_size: 248320关键信息一目了然60 层 Transformer、隐藏维 4096、512 个细粒度专家、每 token 路由10 个专家、并额外配置了一个共享专家shared_expert最大位置编码 262144即 256K。注意力部分采用 GQA 设计32 个 query 头、仅 2 个 KV 头、head_dim 256显著压缩 KV cache 占用——这是 256K 长上下文能跑得动的前提之一。粗略按 512 × 1024 × 4096 估算单层 MoE 的参数量就超过 60 亿60 层累计到数百亿参数的规模但每 token 只激活 10 个专家加 1 个共享专家实际参与计算的参数只有总量的零头。这就是总参大、激活小的稀疏化范式模型容量大推理开销小。512 专家 × 激活 10稀疏化如何把大做成小细粒度专家 共享专家的组合Pro 采用了当前 MoE 主流的两项设计。其一是细粒度专家fine-grained experts把 MoE 中间维度压到 1024moe_intermediate_size: 1024换来 512 路更垂直的专家分工其二是共享专家兜底路由只挑 10 个专家但每个 token 都额外流过共享专家shared_expert_intermediate_size: 1024保证通用知识与常用能力不被稀疏路由漏掉。路由质量则靠配置里的两项参数约束router_aux_loss_coef: 0.001, output_router_logits: falserouter_aux_loss_coef是辅助负载均衡损失的权重系数抑制专家使用失衡output_router_logits关闭了训练期的 logits 输出推理时不额外产出路由开销。这也是 512 路专家在推理侧可以保持低延迟的原因——路由只是一个小型门控网络真正的计算集中在这 101 个专家上。每 4 层一次全注意力长上下文下的注意力预算config.json中full_attention_interval: 4配合 60 层的layer_types数组给出了一个非常清晰的模式60 层中只有 15 层使用标准全注意力其余 45 层全部是线性注意力linear_attention。layer_types: [linear_attention, linear_attention, linear_attention, full_attention, ...], linear_num_key_heads: 16, linear_num_value_heads: 64, linear_key_head_dim: 128, linear_value_head_dim: 128, linear_conv_kernel_dim: 4, mamba_ssm_dtype: float32线性注意力层配置了 16 个 key 头、64 个 value 头并带一个linear_conv_kernel_dim: 4的卷积核——这是典型的类 Mamba / GLA混合设计用线性递推与局部卷积捕获短期与长期依赖把 O(n²) 的注意力开销摊平成近似线性的成本。15 层全注意力负责全局关系建模45 层线性注意力负责消化长序列两者按3 线性 1 全注意力的节奏交替。这解释了 256K 上下文为何不是纸面参数在真实长程 agent 任务浏览网页、操作电脑、长链路代码执行中序列长度动辄数万 token全注意力层的占比必须让位于线性方案推理才能跟上。256K 上下文与多模态输入的工程实现max_position_embeddings: 262144只是起点。真正让长上下文可用的是位置编码与多模态 token 设计的配合。rope_parameters: { mrope_interleaved: true, mrope_section: [11, 11, 10], partial_rotary_factor: 0.25, rope_theta: 10000000 }, partial_rotary_factor: 0.25,模型使用mRoPE多模态旋转位置编码mrope_section: [11, 11, 10]把 32 维位置信息分成文本、图像、视频三组mrope_interleaved: true让各组交错注入partial_rotary_factor: 0.25表示仅对 25% 的隐藏维度施加旋转其余维度保持非旋转状态——这是长距离外推的常见技巧配合rope_theta: 10000000千万级基频让位置编码在 256K 长度上不至于迅速饱和。图像、视频的位置由此被统一编码进同一套 RoPE 空间文本与视觉 token 可以在同一序列里自然对齐。视觉编码器来自 vision_config27 层 ViT、hidden 1152、patch 16×16、spatial_merge_size: 2、temporal_patch_size: 2输出投影到语言模型的 4096 维。语言模型侧预留了专用 tokenvision_start_token_id: 248053, vision_end_token_id: 248054, image_token_id: 248056, video_token_id: 248057chat_template.jinja 展示了这些 token 如何落进对话图像被渲染为|vision_start||image_pad||vision_end|视频同理并自动编号Picture 1:/Video 1:还强制禁止 system 消息携带图像。也就是说多模态不是外挂一个编码器糊上去而是从位置编码到模板都原生打通。processor_config.json 进一步揭示了视频处理能力fps: 2、max_frames: 768、min_frames: 4、temporal_patch_size: 2图像最长边支持到 16777216、视频到 25165824——足以容纳高分辨率截图与长视频。这个能力在基准上直接兑现README 中 OSWorld-2 得分 56.4、WebTest 52.8、Vision2Web 68.2这些看着屏幕操作的任务正是对视觉理解 长上下文 工具调用三重能力的综合检验。FP8 量化与 8×H100 一键部署的成本账压缩策略哪些层被量化、哪些被豁免config.json中的quantization_config是全文工程含量最高的部分。它使用compressed-tensors框架、FP8_BLOCK方案、状态compressedquant_method: compressed-tensors, FP8_BLOCK: { weights: { num_bits: 8, type: float, symmetric: true, strategy: block, block_structure: [128, 128] }, input_activations: { num_bits: 8, type: float, symmetric: true, strategy: group, group_size: 128, dynamic: true } }权重采用128×128 块级 FP8每 128×128 块一个缩放因子激活采用group_size 128 的动态 8bit 量化——块级量化比逐张量量化精度更高动态激活缩放则能适配不同 token 的数值范围。更关键的是它的ignore名单视觉模块、embed_tokens、lm_head、mlp.gate、shared_expert_gate、linear_attn.conv1d / in_proj_a / in_proj_b等全部豁免量化保持 BF16 精度。这个选择非常讲究嵌入层与输出层对量化误差最敏感门控与线性注意力的卷积/投影路径参数量小但数值敏感量化反而得不偿失。哪里必须保精度、哪里可以省显存被拆解到了层粒度这是 FP8 方案能保住基准分数的工程前提。部署成本对比README.md 给出的 Pro 部署命令非常简洁——单机 8×H100Tensor Parallel 8一条 docker run 起服务docker 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 8 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --chat-template /path/to/nex-N2.5-Pro/chat-template.jinja \ --mamba-scheduler-strategy extra_buffer三个细节值得注意。其一推理框架是官方定制 fork 的 SGLangv0.5.18-nex-patch其中--mamba-scheduler-strategy extra_buffer专门为线性注意力层的状态管理预留缓冲说明这类混合架构需要推理引擎侧的针对性适配而不是拿通用 vLLM 就能跑其二--tool-call-parser qwen3_coder与--reasoning-parser qwen3负责把模型的思考轨迹与工具调用从正文中拆出来配合 chat_template.jinja 中think与tool_callfunction...的 XML 格式——函数调用、思考模式与部署是一体的其三对比家族其他成员成本梯度非常清晰Nex-N2.5-mini2×H100 即可部署面向嵌入式与轻量智能体场景Nex-N2.5-Pro8×H100 单机部署多模态 电脑操作主力档位Nex-N2.5-Max1.6 万亿参数纯文本 MoE需 2 节点 16×H200。以 400B 量级的参数规模估算FP8 权重约每参数 1 字节总权重约 400GB8×H10080GB 显存合计 640GB扣除 KV cache 与激活后仍然放得下——如果不做 FP8这个账就算不过来了。量化把部署门槛从多机集群压回单机 8 卡这正是 Pro 能被大量企业直接上手的原因。基准验证稀疏架构的成色稀疏化不是免费的午餐路由偏差与量化误差都可能掉点。Nex-N2.5 官方在 README.md 公布了全套评测采样参数统一为 temperature 0.7 / top_p 0.95 / top_k 40Pro 的关键成绩如下类别基准Nex-N2.5-Pro编码Terminal-Bench 2.182.7编码SWE-Bench Pro61.2编码DeepSWE v1.155.8AgentAutomationBench v1.0.644.2AgentToolathlon Verified68.5AgentBrowseComp89.7AgentJob Bench41.4多模态OSWorld-Verified82.2多模态OSWorld-256.4多模态OSWorld-G87.4多模态Vision2Web68.2多模态WebArena-Verified67.6多模态WebTest52.8多模态SWE-MM38.2多模态OmniDoc92.2这套结果与社区观察互相印证CSDN 上关于认识 Nex-N2.5-Pro的概览文章强调其512 专家/激活 10、256K 上下文、FP8 量化、8×H100 一键部署、Apache 2.0 开源与仓库配置逐条吻合另一篇mini/Pro/Max 三档怎么选的对比文章则直接给出了按算力选型的结论——Pro 主打多模态电脑操作在 OSWorld 一类基准上表现最优。值得注意的是 OSWorld-G87.4是表中 Pro 拿下的唯一榜首成绩说明在通用图形界面操作这个细分场景上Pro 已经具备与一线闭源模型正面对抗的能力而在 BrowseComp 这类长程检索任务上 89.7 的成绩则直接受益于 256K 上下文与线性注意力——上下文越长检索越深这个数字就越有含金量。小结小参数高性能路线的三点启示回到标题的问题Nex-N2.5-Pro 的小参数高性能到底是怎么炼成的从源码看答案可以凝练为三点用稀疏化换取容量用共享专家保住下限。512 专家 10 激活 1 共享专家的组合让数百亿参数的模型保持每 token 只算约十分之一的推理成本同时共享专家确保通用能力不因路由而丢失。用混合注意力换取上下文用 mRoPE 打通多模态。60 层中 45 层线性注意力 15 层全注意力的交替结构让 256K 上下文从参数表上的数字变成可实际运行的长程 agent 任务mRoPE 的三段式位置编码让图像、视频与文本在同一序列中共存。用层粒度 FP8 换取部署可行性用定制推理栈兑现性能。128×128 块级权重量化 动态激活量化配合对嵌入层、门控、线性注意力关键路径的精准豁免把 400B 量级的模型压进 8×H100 单机——从 config.json 到 README.md 的部署命令整条链路都是为工程可落地服务的。在大模型普遍越大越贵的当下Nex-N2.5-Pro 展示的是另一种可能性不在总参数量上做军备竞赛而在单位显存与单位 token 的智能密度上做文章。512 专家的细粒度分工、线性注意力的长程消化、FP8 的层粒度压缩——每一项都不是孤立的技术选择而是围绕让 agent 在真实环境里长时间干活这一个目标层层咬合的工程决策。这套路线的下一步会走向哪里值得持续跟踪。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考