我把 397B 的「Agentic 大脑」塞进了 Xinference，一键部署 Nex-N2

事情是这样的。

上周六晚上我在刷 GitHub trending，看到一个项目叫 Nex-N2，star 数还在涨，点进去看了看。然后我整个人愣了好一会儿。

这不是又一个"我们做了个新模型"的 PR 稿。

这是一个真正把「Agentic Thinking」做进模型架构里的东西。

而且最让我兴奋的是，它用的是 MoE 结构，Mini 版只有 35B 参数，激活参数才 3B。你们自己想，你完全可以在消费级硬件上跑一个能自主规划、调用工具、写代码、执行终端命令的多模态 Agent 模型。

我当时就打开 Xinference，动手把它注册进去了。

这篇文章就讲讲 Nex-N2 到底是个什么玩意，它在 Agent 这件事上跟以前的模型有什么不一样，以及我是怎么用 XorbitsAI Inference（Xinference）一键部署它的。

---

Nex-N2，不再靠「想」赢，靠「做」赢

坦率的讲，过去一年大模型圈有一个很微妙的变化。

去年大家还在比谁的推理分更高。AIME 2024 上谁多对了一道题，GPQA 上谁高了零点几个点，都能吵半天。

但今年风向完全变了。

大家开始问一个更本质的问题。你这个模型，能不能真的干活？

不是能不能回答对一道数学题，而是能不能独立完成一个真实任务，自己查文档、自己写代码、自己调试、自己迭代，直到把活干完。

nex-agi 这帮人给这个东西起了个名字，叫 Agentic Thinking。

说实话我第一次看到这个词的时候心想，又来一个新造词？但认真看完他们的技术报告之后，我承认，这个词造得有道理的。

以前的 Agent 是怎么做的。

模型负责推理。外部框架负责工具调用。环境反馈再传给模型。这三个环节是断开的。模型像一个被困在玻璃罩里的天才，能看到外面的世界，但每次想动手都得等框架给开个口子。慢。而且容易断。

Nex-N2 把这三个东西融进一个闭环里了。

它做了两件事。

第一件叫 Adaptive Thinking。

啥意思呢。模型自己决定什么时候该"想"，想到什么深度。简单操作就不废话，直接动手。关键决策就深度推理。不是每步都 deep think，也不是每步都直接跳。模型自己判断。

这跟之前 DeepSeek R1 那种"强制思考模式"完全不一样。R1 是所有任务都深度推理，Nex-N2 是根据任务自己选择推理深度 。就像一个熟练的程序员，写个 print("hello") 不需要画架构图，但设计一个分布式系统就得认真推演。

第二件叫 Coherent Thinking。

这个更关键一点。Nex-N2 把同一个推理范式贯穿所有 Agent 任务。不管是在写代码、调工具、还是在终端里执行命令，它用的都是同一套思考逻辑。

你想想看，这件事有多重要。

以前的模型在切换任务类型的时候，推理模式是会"断裂"的。从通用 QA 切到 tool calling，模型的思考方式变了，表现就会掉。但 Nex-N2 的 Coherent Thinking 保证跨任务的能力迁移是稳定的。你在代码场景练出来的推理能力，在 Agent 场景一样管用。

我查了一下他们公开的 benchmark 数据，贴在这里给各位看看。

Benchmark	Nex-N2-mini	Nex-N2-Pro	GPT-5.5	Opus 4.7
BrowseComp (Agent)	74.1	83.7	84.4	79.8
GDPval (Agent)	1402	1585	1769	1753
Terminal-Bench 2.1 (Coding)	60.7	75.3	83.4	69.7
SWE-Bench Verified (Coding)	74.4	80.8	82.9	87.6
GPQA Diamond (推理)	82.6	90.7	93.6	94.2

几个数字值得多看两眼。

Terminal-Bench 2.1 干到了 75.3 。这个 benchmark 测的不是写代码，是在真实终端环境里执行多步骤任务，装包、改配置、排查错误、跑脚本。这件事 Pro 版比 Opus 4.7 高了 5.6 分。

GDPval 拿了 1585。这是 Agent 长链路任务评估，Pro 版排在 GPT-5.5 后面，但跟 Opus 4.7 和 Kimi-K2.6 拉开了差距。

GPQA Diamond 90.7。纯推理能力，Pro 版跟 GPT-5.5 只差不到 3 分。

而且最炸的是，Mini 版只有 35B 总参数、3B 激活参数，在 BrowseComp 上拿了 74.1，Terminal-Bench 拿了 60.7。这是什么概念。一个能在你笔记本上跑的多模态 Agent 模型，已经接近去年的顶级水平了。

---

底层架构，为什么是 MoE

我先说一下 Nex-N2 的技术路线，因为这件事本身就很值得聊。

它基于 Qwen3.5 MoE 架构，两个版本用的是一样的 backbone，只是专家数量不同。

Mini 版，256 个专家，每次激活 8 个。总参数量 35B，实际推理时只有 3B 在工作。

Pro 版，512 个专家，每次激活 10 个。总参数 397B，激活 17B。

这里有一个我一直觉得被低估的东西。

MoE 在 Agent 场景下的优势，远不只是推理速度快。

Agent 任务的特点是场景切换频繁。上一秒在写 Python，下一秒在解析 JSON 返回结果，再下一秒在生成 shell 命令。传统的 dense 模型，所有参数参与所有计算，每次切换场景参数更新都是全局的，信息容易互相干扰。

MoE 不一样。不同任务激活不同的专家子集。写代码的专家管写代码，tool calling 的专家管 tool calling。场景切换时专家的隔离性天然更强，知识不会串味。

我自己瞎琢磨了一下，这可能就是为什么 Nex-N2 在 Terminal-Bench 上能接近 GPT-5.5 的原因。终端操作是一种高度结构化的任务，MoE 的专家路由让它能把这类知识压缩在一组特定的专家里，推理时不太受其他知识的干扰。

当然这是我自己的猜想，技术报告里没这么说。但我越想越觉得合理。

---

我是怎么把它注册进 Xinference 的

好了，上面聊的是 Nex-N2 本身。现在说到动手的部分了。

我上周六晚上看完这些 benchmark，手痒得不行。第一个念头就是，能不能在 Xinference 里一键跑起来？

Xinference 是一个我一直在维护和贡献的开源推理部署框架。它最大的好处是把模型部署这件事从"运维噩梦"变成了"一行命令"。不管你用的是 Transformers、vLLM、SGLang 还是 llama.cpp，Xinference 帮你屏蔽所有底层差异，统一的 API 调用。

Nex-N2 用的是 Qwen3.5 MoE 架构，而 vLLM 和 SGLang 已经支持了 Qwen3_5MoeForConditionalGeneration。理论上注册不难。但要让它真正好用，有几步关键工作。

我提交的 PR #5094 做了两件事。

第一件事，在 llm_family.json 里注册 Nex-N2 系列

这一段就是模型的基础配置。我贴出来，带注释。

{
  // 模型家族名称，Xinference 用它来索引和查找模型
  "model_name": "Nex-N2",

  // 模型描述，会显示在 Xinference 的 Web UI 里
  "model_description": "Nex-N2 is a series of multimodal large language models "
    "developed by nex-agi, built on the Qwen3.5 MoE architecture. "
    "It supports text, image, and video understanding, "
    "with advanced reasoning and tool-use capabilities.",

  // 最大上下文长度：262144 tokens
  // 这个数字对 Agent 任务非常关键，长链路 Agent 经常需要跨多轮对话
  // 保持完整的上下文窗口，中间不会丢失任务状态
  "context_length": 262144,

  // 支持的语言：英文和中文
  "model_lang": ["en", "zh"],

  // 模型能力标签
  "model_ability": [
    "chat",       // 对话
    "vision",     // 多模态视觉理解
    "tools",      // 工具调用
    "reasoning",  // 推理能力（输出 <think> 标签包裹的推理过程）
    "hybrid"      // 混合推理：模型自主决定是否开启深度思考
  ],

  // 三个规格，覆盖不同场景
  "model_specs": [
    {
      // Mini 版：总参数 35B，激活参数 3B
      // 适合单卡部署，消费级 GPU 也能跑
      "model_size_in_billions": 35,
      "activated_size_in_billions": 3,
      "model_format": "pytorch",
      "model_src": {
        "huggingface": {
          "model_id": "nex-agi/Nex-N2-mini",
          "quantizations": ["none"]
        },
        "modelscope": {
          "model_id": "nex-agi/Nex-N2-mini",
          "quantizations": ["none"]
        }
      }
    },
    {
      // Pro 版：总参数 397B，激活参数 17B
      // 需要多卡部署，适合生产环境
      "model_size_in_billions": 397,
      "activated_size_in_billions": 17,
      "model_format": "pytorch",
      "model_src": {
        "huggingface": {
          "model_id": "nex-agi/Nex-N2-Pro",
          "quantizations": ["none"]
        },
        "modelscope": {
          "model_id": "nex-agi/Nex-N2-Pro",
          "quantizations": ["none"]
        }
      }
    },
    {
      // Pro FP8 版：与 Pro 版相同参数量，但用 FP8 量化
      // 显存占用减半，推理速度更快，精度损失可控
      "model_size_in_billions": 397,
      "activated_size_in_billions": 17,
      "model_format": "fp8",
      "model_src": {
        "huggingface": {
          "model_id": "nex-agi/Nex-N2-Pro-fp8",
          "quantizations": ["FP8"]
        },
        "modelscope": {
          "model_id": "nex-agi/Nex-N2-Pro-fp8",
          "quantizations": ["FP8"]
        }
      }
    }
  ],

  // 虚拟环境依赖声明
  // #transformers_dependencies# 等是宏变量，Xinference 会根据实际推理引擎展开
  // qwen_vl_utils 是多模态视觉处理的前置依赖
  "virtualenv": {
    "packages": [
      "#transformers_dependencies# ; #engine# == \"Transformers\"",
      "#sglang_dependencies# ; #engine# == \"sglang\"",
      "#vllm_dependencies# ; #engine# == \"vllm\"",
      "#system_numpy# ; #engine# == \"vllm\"",
      "qwen_vl_utils"
    ]
  },

  // 架构声明：告诉 Xinference 用哪个 HuggingFace model class 来加载
  "architectures": ["Qwen3_5MoeForConditionalGeneration"],

  // Chat Template：完整的 Jinja2 模板
  // 这个模板处理了多模态输入（图片/视频标记）、tool calling、推理标记等
  // 跟 Qwen3.5 共用同一套格式，保证兼容性
  "chat_template": "...（完整的 Jinja2 模板，处理图片、视频、工具调用、推理标记）...",

  // 停止 token，对应 <|im_end|> 和 <|endoftext|>
  "stop_token_ids": [248044, 248046],

  // 推理标记：Nex-N2 用 <think>...</think> 包裹推理过程
  // Xinference 会识别这些标记，把推理内容和最终回复分开返回
  "reasoning_start_tag": "<think>",
  "reasoning_end_tag": "</think>",

  // 停止字符串
  "stop": ["<|endoftext|>", "<|im_end|>"],

  // 工具调用解析器：使用 Qwen 系列的格式
  // 这个选择很关键，不同模型族的 tool call 格式不一样，
  // 用错解析器会导致工具调用完全失效
  "tool_parser": "qwen",

  "featured": false,
  "updated_at": 1782625420
}

第二件事，让 Transformer 后端认识 Qwen3_5MoeForConditionalGeneration

Nex-N2 用了一个相对新的 architecture class：Qwen3_5MoeForConditionalGeneration。

Xinference 的 Qwen2VLChatModel 适配器已经支持了好几个 Qwen 架构，但还没加这个。我需要补充三处。

# xinference/model/llm/transformers/multimodal/qwen2_vl.py

# 改动1：注册模型名称到批处理多模态模型列表
# 加了这个之后，Xinference 的启动器才知道 Nex-N2 是一个多模态模型，
# 需要分配对应的批处理逻辑和图像预处理管线
@register_batching_multimodal_models(
    "Qwen2-VL-Instruct",
    "Qwen2.5-VL-Instruct",
    "Qwen3-VL",
    "Qwen3-VL-Thinking",
    "qwen3.5",
    "qwen3.6",
    "Nex-N2",           # ← 新增
)

# 改动2：注册非默认架构类
# 这个装饰器告诉 Xinference：
#   - 当检测到 config.json 里的 architectures 字段是
#     "Qwen3_5MoeForConditionalGeneration" 时，使用
#     Qwen2VLChatModel 这个 Python class 来加载模型
#   - 不是所有 architecture 都在 transformers 的默认映射里，
#     这个注册表是 Xinference 自己的补充映射
@register_transformer
@register_non_default_model(
    "Qwen2_5_VLForConditionalGeneration",
    "Qwen3VLMoeForConditionalGeneration",
    "Qwen3_5ForConditionalGeneration",
    "Qwen3_5MoeForConditionalGeneration",   # ← 新增
)
class Qwen2VLChatModel(PytorchMultiModalModel):
    # 改动3：加入架构白名单
    # QWEN2_VL_ARCHITECTURES 是一个集合，用于判断某个架构
    # 是否属于 Qwen2 VL 家族。在 _sanitize_model_config 方法中
    # 会检查 model.config.architectures 是否在这个集合里。
    QWEN2_VL_ARCHITECTURES = {
        "Qwen2VLForConditionalGeneration",
        "Qwen2_5_VLForConditionalGeneration",
        "Qwen3VLMoeForConditionalGeneration",
        "Qwen3_5ForConditionalGeneration",
        "Qwen3_5MoeForConditionalGeneration",  # ← 新增
    }

    # ...

    def load_multimodal_model(self):
        # 模型加载路由
        # 这里的关键逻辑是：Nex-N2 的 MoE 架构虽然基于 Qwen3.5，
        # 但 Transformers 库里没有专门的 NexN2ForCausalLM 这个 class。
        # 所以不能像加载 Qwen2.5-VL 那样直接用 Qwen2_5_VLForConditionalGeneration。
        #
        # 解法是用 AutoModelForImageTextToText，Transformers 的自动路由
        # 会根据 config.json 里的 architectures 字段自动选择正确的加载类。
        # 这和 Qwen3VLMoeForConditionalGeneration 的处理方式完全一致。
        if self.model_family.has_architecture("Qwen2_5_VLForConditionalGeneration"):
            model_cls = Qwen2_5_VLForConditionalGeneration
        elif self.model_family.has_architecture("Qwen3_5ForConditionalGeneration"):
            model_cls = Qwen3_5ForConditionalGeneration
        elif self.model_family.has_architecture(
            "Qwen3_5MoeForConditionalGeneration"
        ) or self.model_family.has_architecture("Qwen3VLMoeForConditionalGeneration"):
            # MoE 架构走 AutoModel，让 Transformers 自动匹配
            model_cls = AutoModelForImageTextToText
        else:
            model_cls = Qwen2VLForConditionalGeneration

坦率的讲，这三个改动的体量很小，加起来就十几行。但每一行都经过仔细推演。

最关键的决策是 AutoModelForImageTextToText 这个路由。Nex-N2 虽然是 Qwen3.5 MoE 的底子，但在 Transformers 库里没有一个开箱即用的专用 class。我之前在 PR #5086 里修过 DynamicCache 的兼容性问题，那次踩的坑让我对 Transformers 的 API 变化特别敏感，MoE 架构在库里的支持方式一直在变，不能假设有一个固定 class 等着你 。用 AutoModel 让库自己匹配是最稳的做法。

PR 当天就合并进主干了。qinxuye 审的。整个过程顺滑得让我有点不习惯，可能因为是周末，review 节奏比较快。

---

但真正让我觉得这件事重要的，不是技术本身

聊完代码，我想说点更整体的东西。

过去一年 AI 圈最大的转变，我觉得不是模型能力提升了，当然能力确实提升了很多，而是大家对「AI 能干什么」的想象变了。

去年这个时候，大部分人对 AI 的期待是「回答得准不准」。今年变成了「能不能把活干了」。

这个转变的背后，是一个叫 Harness Engineering 的范式在推。

沈向洋团队今年年初发过一篇讲 Harness Engineering 的文章，核心观点我到现在还记得很清楚。

AI 系统的瓶颈，已经从「模型能想多远」变成了「模型能把想的东西执行多远」。

Prompt Engineering 解决的是「怎么问」，Context Engineering 解决的是「给多少信息」。但 Harness Engineering 要解决的是一个更硬核的问题。模型怎么在真实环境里，自己感知、自己决策、自己执行、自己纠错。

Nex-N2 的 Agentic Thinking 就是直接冲着这个方向去的。

它不是又一个「我的推理分比你高」的模型。它是一个为执行而生的模型。

---

最后说两句 Xinference

写到这，我想再聊聊 Xinference 这个项目。

XorbitsAI Inference，GitHub 上 16k+ stars，是目前国内最活跃的开源推理部署框架之一。它最核心的价值我总结为一点。

把模型部署这件事，从「基础设施」变成了「API」。

你不关心底层是 vLLM 还是 SGLang。你不关心 FP8 量化参数怎么配。你不关心多模态的图像预处理管线。

你只需要告诉 Xinference 三件事，我要用哪个模型、用哪种量化、分配多少显存。然后它就给你一个 OpenAI 兼容的 API endpoint。

一键部署 Nex-N2-Pro 就是一条命令。

# 启动 Xinference 服务（如果还没跑的话）
xinference-local --host 0.0.0.0 --port 9997

# 注册并启动 Nex-N2-Pro（FP8 量化版，显存友好）
xinference launch \
  --model-name Nex-N2 \
  --model-format fp8 \
  --size-in-billions 397 \
  --replica 1

然后用 Python SDK 调用。

from xinference.client import Client

# 连接 Xinference 服务
client = Client("http://localhost:9997")

# 获取已注册的 Nex-N2 模型实例
# model_uid 是每个模型实例的唯一标识，由 launch 命令自动生成
model = client.get_model("your-model-uid")

# 多模态调用：传入图片 + 文本
# Xinference 的多模态接口是 OpenAI 兼容的，
# 可以直接传 image_url 或 base64 编码的图片数据
response = model.chat(
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/screenshot.png"}
                },
                {
                    "type": "text",
                    "text": "这张截图里的错误是什么？帮我分析一下原因并给出修复方案"
                }
            ]
        }
    ],
    # generate_config 控制生成参数
    generate_config={
        "temperature": 0.7,  # 温度：控制输出的随机性。0.7 是 Nex-N2 推荐值
        "top_p": 0.95,       # nucleus sampling 阈值
        "top_k": 40,         # top-k 采样
        "max_tokens": 4096   # 最大输出长度
    }
)

# 响应的 choices[0]["message"]["content"] 是模型回复的正文
# 如果模型开启了推理模式，content 中会包含 <think>...</think> 包裹的推理过程
print(response["choices"][0]["message"]["content"])

就这么简单。

Nex-N2 这样的 Agentic 模型，它真正需要的是一个能让它快速落地的部署平台。不是每个团队都有 16 块 H100 和一个专职的 MLOps 工程师。但 Xinference 让它变成了一条命令的事。

如果你对 Agentic AI 方向感兴趣，或者你正在思考怎么在自己的业务里落地一个有执行力的 AI 助手，Nex-N2 值得你花一个下午跑一下。

如果你需要一个靠谱的推理部署平台，XorbitsAI Inference 值得你 star。

GitHub：github.com/xorbitsai/i... Nex-N2：github.com/nex-agi/Nex...