一次真实的折腾我是怎么用 Docker 把 Nex-N2-Pro 这头巨兽请回家的【免费下载链接】Nex-N2-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2-ProNex-N2-Pro 是 Nex-AGI 团队开源的一款面向真实生产力场景的代理模型它靠着 Agentic Thinking 机制把听懂需求、拟出方案、动手写码、观察环境反馈、自查纠错、继续迭代这些动作拧成了一条流水线尤其适合代码生成、深度调研、工具调用这类脏活累活。它本事不小但想把它搬回自己机器上跑却是我近期踩坑最多的一件事。这篇笔记不打算给你一份标准答案式的教程而是把我从一脸懵到终于把服务跑起来的过程摊开给你看——踩过的坑、补的课、还有那些文档里没明说的道理全都在这。它凭什么值得你腾出 200GB 硬盘先别急着敲命令你得知道自己搬回来的是什么。Nex-N2-Pro 的底子是 Qwen3.5-397B-A17B一套混合专家MoE架构总计 512 个专家每处理一个 token 只点亮其中 10 个。听起来吓人但正因为按需激活它才能用相对可控的算力去换 397B 量级的实力。项目里的 config.json 把这些家底写得明明白白隐藏层 4096 维、上下文窗口拉到 262144 个 token约 26 万甚至同时接了视觉编码器图片视频都能吃。它在 Terminal-Bench 2.1 上拿了 75.3在 GDPval 这类长程任务上冲到 1585和 GPT-5.5、Opus 4.7 掰手腕也不落下风。换句话说这不是个聊天玩具而是一个真能在终端里帮你干活的数字实习生。也正因为如此它的胃口不小——部署它基本是奔着给一台小工作站去的。摸底先回答四个有没有动手之前我建议你先对着清单自查一遍。别嫌啰嗦这四件事缺一件后面都得返工项目底线要求我的提醒操作系统LinuxUbuntu 20.04 或 CentOS 8Windows 上跑容器不是不行但和 GPU 打交道时坑更多Docker20.10.0 及以上太老的版本连--gpus参数都不认识GPUNVIDIA 显卡 NVIDIA Container Toolkit只有显卡不行还得让容器看得见显卡资源至少 64GB 内存、200GB 空闲磁盘光模型文件就有 122 个分片随便就吃几十 GB这个自查过程完全可以交给命令代劳。确认 Docker 版本用docker --version验证容器能不能拿到 GPU就运行下面这条能打出显卡信息就说明路通了docker run --rm --gpus all nvidia/cuda:12.0.0-base nvidia-smi我第一次跑这条命令时直接报错查了半天才发现 NVIDIA Container Toolkit 根本没装——容器里压根找不到显卡驱动。记住这个教训Docker 装好了 ≠ 容器能用 GPU中间还隔着一层 toolkit。第一课看清那 122 个分片文件模型仓库解压后你会看到一长串model-00001-of-00122.safetensors一直到model-00122-of-00122.safetensors。别被数量吓到这只是权重文件太大官方按 122 份拆开存而已。真正起地图作用的是那个model.safetensors.index.json——它记录了每个张量藏在哪个分片里加载程序就是照着它按图索骥的。所以有两条铁律122 个分片一个都不能少少了任何一个加载都会在半路卡死挂载目录要对容器里看到的是/model宿主机上放模型的路径要原封不动映射过去。我后来做一次例行检查时就发现有个分片文件因为下载中断只剩了半截服务怎么都起不来排查了半天。从那以后我的习惯是先看一眼文件大小是否齐整再启动服务。第二课让 Docker 和 GPU 握手这一步没做好后面全是白搭。除了 NVIDIA Container Toolkit还有两个容器参数是给模型腾地方用的--gpus all把宿主机所有显卡交给容器--shm-size 32g共享内存开大点。sglang 这类推理引擎在调度时要在进程间搬运大量数据共享内存太小加载到一半就喊内存不足。官方镜像nexagi/sglang:v0.5.12里已经预装了他们定制过的 sglang 分支Nex 系列模型用这个分支跑才最顺手省去了自己编译的功夫。模型文件挂进容器、端口透出到 30000剩下的就是按配置启动。第三课第一次启动我就撞了墙如果你的卡是两张 H100 级别、模型用 Nex-N2-miniQwen3.5-35B-A3B 底座那么这份最小可运行配置可以直接抄docker run --gpus all --shm-size 32g --ipchost \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.12 \ 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 \ --mamba-scheduler-strategy extra_buffer我第一次跑的时候自作主张把--tp写成了 1结果显卡显存直接爆掉进程被系统杀掉。后来才搞明白--tp是张量并行度意思是把一张模型切成几份、分到几张卡上并行算。你手里的卡越多、单卡显存越小这个数字就越要大。Nex-N2-mini 用--tp 2就是在两张卡之间分摊。这里还有个小彩蛋--ipchost是让我省心的一行。它把容器和宿主的进程间通信打通某些加载阶段能明显少些莫名的卡顿。如果你的镜像版本不支持这个参数用大一点的--shm-size也能勉强顶上。一张卡装不下时怎么把多张卡拼起来跑 mini 只是热身真正的考验是 Nex-N2-Pro——397B 的体量两张卡根本放不下。这个时候--tp的数字就得跟着你的显卡总盘子上涨。手头有 8 张 H100 的机器跑 Pro 通常要--tp 8起步如果两张 8 卡机器联手就是--tp 16。别小看这个数字的换算它其实是在回答一个问题你打算把模型切成几份。切得越多单卡负担越轻但卡与卡之间的通信开销也越大TP 并不是越大越好得跟你的显存总量和机器间带宽做平衡。两台机器如何变成一台机器如果你和我一样手头是两台 8× H100 的服务器那就要把多卡升级成多机。多机部署的核心思路是让两台机器的 16 张卡看起来像是一台超级大的 GPU。做法是在每台机器上运行同一条命令只是各自的身份参数不同docker run --gpus all --shm-size 32g --network host \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.12 \ python3 -m sglang.launch_server \ --model-path /model \ --tp 16 \ --nnodes 2 \ --node-rank node-rank \ --dist-init-addr node0-ip:20000 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --mamba-scheduler-strategy extra_buffer这里的新面孔有三个各自分工--nnodes 2告诉引擎这次一共几台机器参与--node-rank给每台机器编号主节点写 0另一台写 1--dist-init-addr把主节点的 IP 和约定的通信端口默认 20000告诉所有人让大家知道找谁报到。顺带说一句多机场景我把-p 30000:30000换成了--network host。原因很简单多机通信要走一堆内部端口用 host 网络模式直接共享宿主机网卡省得一个个端口去映射能少掉好多这个端口没通的灵异事件。别忘了给推理和工具调用上牌照模型本身会先写一段内部推理草稿再给出正式回答。这两个开关建议从第一天就打开--reasoning-parser qwen3让引擎把思考过程和最终回答分开解析方便你后面做流式输出或日志展示--tool-call-parser qwen3_coder启用函数调用能力——想让它去查数据库、调 API、操控工具全靠这个解析器把调用指令从文本里认出来。它俩互不冲突可以一起用也正是我把两行都写进启动命令的原因。另外还有个容易被忽略的性能参数--mamba-scheduler-strategy extra_buffer。我一开始不知道它是干嘛的只是照着加后来读代码才明白它是给调度器多加一层缓冲让推理请求排队的吞吐更稳。多花一秒钟加上它运行期能少不少幺蛾子。怎么确认服务真的在干活起服务之后别干等着。三个动作依次来docker ps # 1. 看容器有没有活着 docker logs 容器ID # 2. 看启动日志有没有报错 curl http://localhost:30000/health # 3. 直接问服务你好了没第三条最直接——返回OK之类的健康响应就说明推理引擎已经就位可以接请求了。如果容器显示在跑但/health一直不通八成是端口映射写错或者进程还在加载那 122 个分片耐心等日志输出到ready再测。翻车现场速查表我把自己遇到过的、以及朋友常踩的坑整理成了一张表遇到问题直接对号入座症状病因药方进程被 OOM 杀掉日志提示显存不足--tp开小了单卡扛不住调大--tp实在不行换 Nex-N2-mini端口起冲突30000 被占有别的服务占了端口改映射比如-p 30001:30000服务端端口别动加载到某个分片就卡死122 个 safetensors 有缺失或损坏核对文件数量与大小重新补下缺失分片/health不通但容器还活着加载未完成或映射错误看日志等 ready检查--host/--port至于让模型出活的最后一公里是采样参数。官方推荐temperature0.7、top_p0.95、top_k40这一组——温度别拉太高否则代码生成容易放飞自我top_p 和 top_k 保持这个量级能让输出在稳和活之间取个平衡。收尾的话回头看这趟折腾最大的收获不是那几条命令而是搞明白了模型大 ≠ 部署难难在不知道卡在哪。那些参数背后其实都对应着一个朴素的问题显存够不够、通信通不通、解析器认不认。如果你也想让这么个能干活的数字实习生替你跑起来我建议挑个周末先把上面的自查清单过一遍再拿 mini 版试水最后再上 Pro 的双机剧本。等你在终端里敲下启动命令、看到/health返回 OK 的那一刻你会发现之前所有的折腾都值了。仓库里的 config.json、chat_template.jinja、processor_config.json 都值得翻一翻很多启动参数和模型行为都能在里面找到对应。祝你的那台巨兽早日从下载中变成运行中。【免费下载链接】Nex-N2-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2-Pro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一次真实的折腾：我是怎么用 Docker 把 Nex-N2-Pro 这头“巨兽“请回家的
一次真实的折腾我是怎么用 Docker 把 Nex-N2-Pro 这头巨兽请回家的【免费下载链接】Nex-N2-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2-ProNex-N2-Pro 是 Nex-AGI 团队开源的一款面向真实生产力场景的代理模型它靠着 Agentic Thinking 机制把听懂需求、拟出方案、动手写码、观察环境反馈、自查纠错、继续迭代这些动作拧成了一条流水线尤其适合代码生成、深度调研、工具调用这类脏活累活。它本事不小但想把它搬回自己机器上跑却是我近期踩坑最多的一件事。这篇笔记不打算给你一份标准答案式的教程而是把我从一脸懵到终于把服务跑起来的过程摊开给你看——踩过的坑、补的课、还有那些文档里没明说的道理全都在这。它凭什么值得你腾出 200GB 硬盘先别急着敲命令你得知道自己搬回来的是什么。Nex-N2-Pro 的底子是 Qwen3.5-397B-A17B一套混合专家MoE架构总计 512 个专家每处理一个 token 只点亮其中 10 个。听起来吓人但正因为按需激活它才能用相对可控的算力去换 397B 量级的实力。项目里的 config.json 把这些家底写得明明白白隐藏层 4096 维、上下文窗口拉到 262144 个 token约 26 万甚至同时接了视觉编码器图片视频都能吃。它在 Terminal-Bench 2.1 上拿了 75.3在 GDPval 这类长程任务上冲到 1585和 GPT-5.5、Opus 4.7 掰手腕也不落下风。换句话说这不是个聊天玩具而是一个真能在终端里帮你干活的数字实习生。也正因为如此它的胃口不小——部署它基本是奔着给一台小工作站去的。摸底先回答四个有没有动手之前我建议你先对着清单自查一遍。别嫌啰嗦这四件事缺一件后面都得返工项目底线要求我的提醒操作系统LinuxUbuntu 20.04 或 CentOS 8Windows 上跑容器不是不行但和 GPU 打交道时坑更多Docker20.10.0 及以上太老的版本连--gpus参数都不认识GPUNVIDIA 显卡 NVIDIA Container Toolkit只有显卡不行还得让容器看得见显卡资源至少 64GB 内存、200GB 空闲磁盘光模型文件就有 122 个分片随便就吃几十 GB这个自查过程完全可以交给命令代劳。确认 Docker 版本用docker --version验证容器能不能拿到 GPU就运行下面这条能打出显卡信息就说明路通了docker run --rm --gpus all nvidia/cuda:12.0.0-base nvidia-smi我第一次跑这条命令时直接报错查了半天才发现 NVIDIA Container Toolkit 根本没装——容器里压根找不到显卡驱动。记住这个教训Docker 装好了 ≠ 容器能用 GPU中间还隔着一层 toolkit。第一课看清那 122 个分片文件模型仓库解压后你会看到一长串model-00001-of-00122.safetensors一直到model-00122-of-00122.safetensors。别被数量吓到这只是权重文件太大官方按 122 份拆开存而已。真正起地图作用的是那个model.safetensors.index.json——它记录了每个张量藏在哪个分片里加载程序就是照着它按图索骥的。所以有两条铁律122 个分片一个都不能少少了任何一个加载都会在半路卡死挂载目录要对容器里看到的是/model宿主机上放模型的路径要原封不动映射过去。我后来做一次例行检查时就发现有个分片文件因为下载中断只剩了半截服务怎么都起不来排查了半天。从那以后我的习惯是先看一眼文件大小是否齐整再启动服务。第二课让 Docker 和 GPU 握手这一步没做好后面全是白搭。除了 NVIDIA Container Toolkit还有两个容器参数是给模型腾地方用的--gpus all把宿主机所有显卡交给容器--shm-size 32g共享内存开大点。sglang 这类推理引擎在调度时要在进程间搬运大量数据共享内存太小加载到一半就喊内存不足。官方镜像nexagi/sglang:v0.5.12里已经预装了他们定制过的 sglang 分支Nex 系列模型用这个分支跑才最顺手省去了自己编译的功夫。模型文件挂进容器、端口透出到 30000剩下的就是按配置启动。第三课第一次启动我就撞了墙如果你的卡是两张 H100 级别、模型用 Nex-N2-miniQwen3.5-35B-A3B 底座那么这份最小可运行配置可以直接抄docker run --gpus all --shm-size 32g --ipchost \ -p 30000:30000 \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.12 \ 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 \ --mamba-scheduler-strategy extra_buffer我第一次跑的时候自作主张把--tp写成了 1结果显卡显存直接爆掉进程被系统杀掉。后来才搞明白--tp是张量并行度意思是把一张模型切成几份、分到几张卡上并行算。你手里的卡越多、单卡显存越小这个数字就越要大。Nex-N2-mini 用--tp 2就是在两张卡之间分摊。这里还有个小彩蛋--ipchost是让我省心的一行。它把容器和宿主的进程间通信打通某些加载阶段能明显少些莫名的卡顿。如果你的镜像版本不支持这个参数用大一点的--shm-size也能勉强顶上。一张卡装不下时怎么把多张卡拼起来跑 mini 只是热身真正的考验是 Nex-N2-Pro——397B 的体量两张卡根本放不下。这个时候--tp的数字就得跟着你的显卡总盘子上涨。手头有 8 张 H100 的机器跑 Pro 通常要--tp 8起步如果两张 8 卡机器联手就是--tp 16。别小看这个数字的换算它其实是在回答一个问题你打算把模型切成几份。切得越多单卡负担越轻但卡与卡之间的通信开销也越大TP 并不是越大越好得跟你的显存总量和机器间带宽做平衡。两台机器如何变成一台机器如果你和我一样手头是两台 8× H100 的服务器那就要把多卡升级成多机。多机部署的核心思路是让两台机器的 16 张卡看起来像是一台超级大的 GPU。做法是在每台机器上运行同一条命令只是各自的身份参数不同docker run --gpus all --shm-size 32g --network host \ -v /path/to/your/model:/model \ nexagi/sglang:v0.5.12 \ python3 -m sglang.launch_server \ --model-path /model \ --tp 16 \ --nnodes 2 \ --node-rank node-rank \ --dist-init-addr node0-ip:20000 \ --host 0.0.0.0 --port 30000 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --mamba-scheduler-strategy extra_buffer这里的新面孔有三个各自分工--nnodes 2告诉引擎这次一共几台机器参与--node-rank给每台机器编号主节点写 0另一台写 1--dist-init-addr把主节点的 IP 和约定的通信端口默认 20000告诉所有人让大家知道找谁报到。顺带说一句多机场景我把-p 30000:30000换成了--network host。原因很简单多机通信要走一堆内部端口用 host 网络模式直接共享宿主机网卡省得一个个端口去映射能少掉好多这个端口没通的灵异事件。别忘了给推理和工具调用上牌照模型本身会先写一段内部推理草稿再给出正式回答。这两个开关建议从第一天就打开--reasoning-parser qwen3让引擎把思考过程和最终回答分开解析方便你后面做流式输出或日志展示--tool-call-parser qwen3_coder启用函数调用能力——想让它去查数据库、调 API、操控工具全靠这个解析器把调用指令从文本里认出来。它俩互不冲突可以一起用也正是我把两行都写进启动命令的原因。另外还有个容易被忽略的性能参数--mamba-scheduler-strategy extra_buffer。我一开始不知道它是干嘛的只是照着加后来读代码才明白它是给调度器多加一层缓冲让推理请求排队的吞吐更稳。多花一秒钟加上它运行期能少不少幺蛾子。怎么确认服务真的在干活起服务之后别干等着。三个动作依次来docker ps # 1. 看容器有没有活着 docker logs 容器ID # 2. 看启动日志有没有报错 curl http://localhost:30000/health # 3. 直接问服务你好了没第三条最直接——返回OK之类的健康响应就说明推理引擎已经就位可以接请求了。如果容器显示在跑但/health一直不通八成是端口映射写错或者进程还在加载那 122 个分片耐心等日志输出到ready再测。翻车现场速查表我把自己遇到过的、以及朋友常踩的坑整理成了一张表遇到问题直接对号入座症状病因药方进程被 OOM 杀掉日志提示显存不足--tp开小了单卡扛不住调大--tp实在不行换 Nex-N2-mini端口起冲突30000 被占有别的服务占了端口改映射比如-p 30001:30000服务端端口别动加载到某个分片就卡死122 个 safetensors 有缺失或损坏核对文件数量与大小重新补下缺失分片/health不通但容器还活着加载未完成或映射错误看日志等 ready检查--host/--port至于让模型出活的最后一公里是采样参数。官方推荐temperature0.7、top_p0.95、top_k40这一组——温度别拉太高否则代码生成容易放飞自我top_p 和 top_k 保持这个量级能让输出在稳和活之间取个平衡。收尾的话回头看这趟折腾最大的收获不是那几条命令而是搞明白了模型大 ≠ 部署难难在不知道卡在哪。那些参数背后其实都对应着一个朴素的问题显存够不够、通信通不通、解析器认不认。如果你也想让这么个能干活的数字实习生替你跑起来我建议挑个周末先把上面的自查清单过一遍再拿 mini 版试水最后再上 Pro 的双机剧本。等你在终端里敲下启动命令、看到/health返回 OK 的那一刻你会发现之前所有的折腾都值了。仓库里的 config.json、chat_template.jinja、processor_config.json 都值得翻一翻很多启动参数和模型行为都能在里面找到对应。祝你的那台巨兽早日从下载中变成运行中。【免费下载链接】Nex-N2-Pro项目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2-Pro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考