Docker 三步拉起 Nex-N2-Pro一張 NVIDIA 顯卡搞定你的 AI 代理服務【免費下載鏈接】Nex-N2.5-Pro項目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-Pro當一個開源模型同時具備操作電腦、瀏覽網(wǎng)頁、寫代碼、執(zhí)行長任務的能力時開發(fā)者最關心的往往不是它跑分多高而是能不能在自己手頭的機器上把服務跑起來。Nex-N2.5 系列正是這樣一類典型的 agentic 模型——mini、Pro、Max 三檔規(guī)模橫跨 2 卡到 32 卡部署場景其中 Pro 檔以多模態(tài)電腦操作為核心賣點在 OSWorld 系列基準上成績突出。官方在 README.md 中給出的部署路徑只有一條Docker 定制 SGLang 鏡像。本文不聊評測數(shù)據(jù)直接拆解權重獲取 → 鏡像選擇 → 參數(shù)配置 → 排障的完整落地流程并給出單卡運行時的現(xiàn)實邊界。第一步權重獲取與鏡像選擇先看清楚倉庫里有什么Nex-N2.5-Pro 的權重以122 個 safetensors 分片形式發(fā)布model-00001-of-00122.safetensors至model-00001-of-00122.safetensors配合 model.safetensors.index.json 做分片映射。拉取時務必連同config.json、tokenizer.json、processor_config.json與chat_template.jinja一起下載完整目錄SGLang 啟動時這幾份文件缺一不可。打開 config.json 可以看到三個決定部署形態(tài)的關鍵信息架構類型Qwen3_5MoeForConditionalGeneration即 Qwen3.5 血統(tǒng)的 MoE 模型這意味著必須使用支持該架構的推理后端通用 vLLM/Transformers 直接加載大概率失敗。規(guī)模配置hidden_size4096、60 層、512 個專家、每 token 激活 10 個、上下文長度262144。這個量級的 MoE 模型參數(shù)量在數(shù)百 B 級別遠非消費級顯卡能原生承載。權重壓縮quantization_config采用compressed-tensors的FP8 分塊量化FP8_BLOCK128×128 block structuredtype為 bfloat16。官方在發(fā)布權重時就已經(jīng)完成 FP8 壓縮這既是存儲上的減負也是單卡部署得以成立的技術前提。鏡像預裝定制 SGLang 的現(xiàn)成方案Nex-N2.5 依賴 SGLang 的兩個關鍵擴展能力Qwen3.5 MoE 的線性注意力/全注意力交替層調度以及qwen3_coder工具調用解析。官方為此提供了預構建鏡像nexagi/sglang:v0.5.18-nex-patch內部已集成定制版 SGLang fork。社區(qū)此前在 v0.5.12 等舊版本上踩過的架構不支持、注意力后端報錯類問題在新鏡像中已消除因此不要自行用通用 sglang 鏡像直接使用官方 tag 是風險最低的選擇。官方在 README.md 中給出的 Pro 基線命令如下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三個細節(jié)值得注意--shm-size 32g保證多進程張量并行時共享內存充足-v將宿主機模型目錄掛載為容器內/model避免重復拷貝 122 個分片--chat-template顯式指向倉庫根目錄的 chat_template.jinja它內置了tool_call工具調用格式與reasoning_effort思考模式控制不掛載模板會導致多輪工具調用格式錯亂。第二步TP 張量并行與性能參數(shù)配置TP 是什么單卡怎么配官方基線用--tp 8在 8×H100 上運行。TPTensor Parallelism把每個權重矩陣按行/列切分到多張卡推理時通過 all-reduce 同步激活結果是 MoE 大模型多卡部署的標準手段。如果你只有一張 NVIDIA 顯卡把--tp 8改為--tp 1即可——SGLang 會退回單進程加載完整權重。單卡場景下顯存預算是硬約束。結合官方 Max 檔命令中出現(xiàn)的優(yōu)化參數(shù)單卡部署建議疊加以下配置--tp 1 \ --kv-cache-dtype fp8_e4m3 \ --context-length 32768 \ --mem-fraction-static 0.84 \ --max-running-requests 8 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder各參數(shù)作用--kv-cache-dtype fp8_e4m3KV cache 以 FP8 存儲長上下文時顯著壓低顯存占用--context-length 32768模型原生支持 262144 token但完整上下文緩存需要數(shù)百 GB 顯存單卡必須主動收窄--mem-fraction-static限制預留給權重KV cache 的顯存比例留出推理余量--max-running-requests限制并發(fā)避免多請求瞬間撐爆顯存。推理質量與思考模式參數(shù)官方在 README.md 的 Recommended Sampling Parameters 中給出建議temperature0.7、top_p0.95、top_k40。這三者構成了 agentic 任務中可控性與多樣性平衡的默認檔位。思考模式通過請求體中的reasoning_effort字段控制三檔語義清晰reasoning_effort模式行為none非思考直接回答不輸出推理軌跡medium默認自適應思考由模型自行決定思考與否及深度high強制思考總是先輸出推理軌跡再作答模板層面對這三檔有明確實現(xiàn)查看 chat_template.jinja 末尾的add_generation_prompt分支none會生成空think標簽high會打開思考標簽medium與未設置時走自適應邏輯。此外--reasoning-parser qwen3負責把think推理軌跡與最終答案分離--tool-call-parser qwen3_coder負責解析模型的函數(shù)調用——兩者缺一多輪 Agent 工作流都會失常。模型的綜合能力基線可以參考官方基準圖。Pro 檔在 Terminal-Bench 2.1、SWE-Bench Pro、OSWorld 等基準上的表現(xiàn)正是其被社區(qū)視為可執(zhí)行長任務模型的原因。第三步GPU 顯存不足與端口沖突的排查清單顯存不足CUDA out of memory這是單卡部署最常遇到的故障按優(yōu)先級排查確認容器內可見 GPU宿主機執(zhí)行nvidia-smi正常不代表容器內可用。容器內執(zhí)行nvidia-smi報錯說明未安裝 NVIDIA Container Toolkit 或未用--gpus all啟動需先補齊nvidia-container-toolkit并重啟 Docker daemon。核對--tp與分片--tp 1時必須讓 SGLang 加載全部 122 個分片若誤配--tp 2而只有單卡啟動即報錯。收縮 KV cache 預算依次調低--context-length、--max-running-requests、--mem-fraction-static。若仍不足說明該顯卡物理顯存低于權重駐留需求需要更換更大顯存卡或改用 Mini 檔。觀察啟動日志SGLang 會打印權重加載與顯存占用明細定位是權重溢出還是 KV cache 溢出前者只能換卡后者可通過參數(shù)收斂。端口沖突Address already in use官方命令固定使用30000端口-p 30000:30000與--port 30000。沖突排查先查端口占用ss -tlnp | grep 30000或lsof -i:30000確認被哪個進程占用。換宿主機映射端口容器內端口不必改只改-p左側宿主機端口即可例如-p 8080:30000。容器內多服務共存同一容器內如需起多個服務用--port換端口注意--host 0.0.0.0保證外部可達。驗證服務健康啟動后curl http://localhost:30000/health返回正常即完成拉起。若用--network host模式官方 Max 命令的用法則端口映射參數(shù)-p應省略直接以宿主機端口暴露。一張顯卡的現(xiàn)實邊界必須誠實說明官方為 Pro 檔給出的基線是8×H100Nex-N2.5 系列中真正面向輕量部署的是 Mini 檔官方基線 2×H100。一張 NVIDIA 顯卡搞定成立的前提是顯卡擁有足夠大的顯存如 H100 80G 級別配合官方 FP8 權重 FP8 KV cache 收窄上下文可以單卡運行 Pro 服務但并發(fā)與上下文長度需要嚴格約束如果只有消費級顯卡更務實的路線是選擇 Mini 檔權重約 35B 參數(shù)量級或社區(qū)量化版本它們的架構與部署參數(shù)完全一致只是把--tp與--context-length進一步下調即可。從 config.json 的 FP8 分塊量化到 chat_template.jinja 的思考模式模板再到 README.md 的完整啟動命令Nex-N2.5-Pro 的部署鏈路在倉庫內是自洽、可復現(xiàn)的。按上面三步操作從拉取 122 個分片到curl返回健康狀態(tài)中間幾乎沒有需要調代碼的環(huán)節(jié)——這正是容器化 定制推理框架給開源 agentic 模型帶來的最大價值把復雜度留在鏡像里把確定性的啟動命令交給開發(fā)者?！久赓M下載鏈接】Nex-N2.5-Pro項目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-Pro創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Docker 三步拉起 Nex-N2-Pro：一張 NVIDIA 顯卡搞定你的 AI 代理服務
Docker 三步拉起 Nex-N2-Pro一張 NVIDIA 顯卡搞定你的 AI 代理服務【免費下載鏈接】Nex-N2.5-Pro項目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-Pro當一個開源模型同時具備操作電腦、瀏覽網(wǎng)頁、寫代碼、執(zhí)行長任務的能力時開發(fā)者最關心的往往不是它跑分多高而是能不能在自己手頭的機器上把服務跑起來。Nex-N2.5 系列正是這樣一類典型的 agentic 模型——mini、Pro、Max 三檔規(guī)模橫跨 2 卡到 32 卡部署場景其中 Pro 檔以多模態(tài)電腦操作為核心賣點在 OSWorld 系列基準上成績突出。官方在 README.md 中給出的部署路徑只有一條Docker 定制 SGLang 鏡像。本文不聊評測數(shù)據(jù)直接拆解權重獲取 → 鏡像選擇 → 參數(shù)配置 → 排障的完整落地流程并給出單卡運行時的現(xiàn)實邊界。第一步權重獲取與鏡像選擇先看清楚倉庫里有什么Nex-N2.5-Pro 的權重以122 個 safetensors 分片形式發(fā)布model-00001-of-00122.safetensors至model-00001-of-00122.safetensors配合 model.safetensors.index.json 做分片映射。拉取時務必連同config.json、tokenizer.json、processor_config.json與chat_template.jinja一起下載完整目錄SGLang 啟動時這幾份文件缺一不可。打開 config.json 可以看到三個決定部署形態(tài)的關鍵信息架構類型Qwen3_5MoeForConditionalGeneration即 Qwen3.5 血統(tǒng)的 MoE 模型這意味著必須使用支持該架構的推理后端通用 vLLM/Transformers 直接加載大概率失敗。規(guī)模配置hidden_size4096、60 層、512 個專家、每 token 激活 10 個、上下文長度262144。這個量級的 MoE 模型參數(shù)量在數(shù)百 B 級別遠非消費級顯卡能原生承載。權重壓縮quantization_config采用compressed-tensors的FP8 分塊量化FP8_BLOCK128×128 block structuredtype為 bfloat16。官方在發(fā)布權重時就已經(jīng)完成 FP8 壓縮這既是存儲上的減負也是單卡部署得以成立的技術前提。鏡像預裝定制 SGLang 的現(xiàn)成方案Nex-N2.5 依賴 SGLang 的兩個關鍵擴展能力Qwen3.5 MoE 的線性注意力/全注意力交替層調度以及qwen3_coder工具調用解析。官方為此提供了預構建鏡像nexagi/sglang:v0.5.18-nex-patch內部已集成定制版 SGLang fork。社區(qū)此前在 v0.5.12 等舊版本上踩過的架構不支持、注意力后端報錯類問題在新鏡像中已消除因此不要自行用通用 sglang 鏡像直接使用官方 tag 是風險最低的選擇。官方在 README.md 中給出的 Pro 基線命令如下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三個細節(jié)值得注意--shm-size 32g保證多進程張量并行時共享內存充足-v將宿主機模型目錄掛載為容器內/model避免重復拷貝 122 個分片--chat-template顯式指向倉庫根目錄的 chat_template.jinja它內置了tool_call工具調用格式與reasoning_effort思考模式控制不掛載模板會導致多輪工具調用格式錯亂。第二步TP 張量并行與性能參數(shù)配置TP 是什么單卡怎么配官方基線用--tp 8在 8×H100 上運行。TPTensor Parallelism把每個權重矩陣按行/列切分到多張卡推理時通過 all-reduce 同步激活結果是 MoE 大模型多卡部署的標準手段。如果你只有一張 NVIDIA 顯卡把--tp 8改為--tp 1即可——SGLang 會退回單進程加載完整權重。單卡場景下顯存預算是硬約束。結合官方 Max 檔命令中出現(xiàn)的優(yōu)化參數(shù)單卡部署建議疊加以下配置--tp 1 \ --kv-cache-dtype fp8_e4m3 \ --context-length 32768 \ --mem-fraction-static 0.84 \ --max-running-requests 8 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder各參數(shù)作用--kv-cache-dtype fp8_e4m3KV cache 以 FP8 存儲長上下文時顯著壓低顯存占用--context-length 32768模型原生支持 262144 token但完整上下文緩存需要數(shù)百 GB 顯存單卡必須主動收窄--mem-fraction-static限制預留給權重KV cache 的顯存比例留出推理余量--max-running-requests限制并發(fā)避免多請求瞬間撐爆顯存。推理質量與思考模式參數(shù)官方在 README.md 的 Recommended Sampling Parameters 中給出建議temperature0.7、top_p0.95、top_k40。這三者構成了 agentic 任務中可控性與多樣性平衡的默認檔位。思考模式通過請求體中的reasoning_effort字段控制三檔語義清晰reasoning_effort模式行為none非思考直接回答不輸出推理軌跡medium默認自適應思考由模型自行決定思考與否及深度high強制思考總是先輸出推理軌跡再作答模板層面對這三檔有明確實現(xiàn)查看 chat_template.jinja 末尾的add_generation_prompt分支none會生成空think標簽high會打開思考標簽medium與未設置時走自適應邏輯。此外--reasoning-parser qwen3負責把think推理軌跡與最終答案分離--tool-call-parser qwen3_coder負責解析模型的函數(shù)調用——兩者缺一多輪 Agent 工作流都會失常。模型的綜合能力基線可以參考官方基準圖。Pro 檔在 Terminal-Bench 2.1、SWE-Bench Pro、OSWorld 等基準上的表現(xiàn)正是其被社區(qū)視為可執(zhí)行長任務模型的原因。第三步GPU 顯存不足與端口沖突的排查清單顯存不足CUDA out of memory這是單卡部署最常遇到的故障按優(yōu)先級排查確認容器內可見 GPU宿主機執(zhí)行nvidia-smi正常不代表容器內可用。容器內執(zhí)行nvidia-smi報錯說明未安裝 NVIDIA Container Toolkit 或未用--gpus all啟動需先補齊nvidia-container-toolkit并重啟 Docker daemon。核對--tp與分片--tp 1時必須讓 SGLang 加載全部 122 個分片若誤配--tp 2而只有單卡啟動即報錯。收縮 KV cache 預算依次調低--context-length、--max-running-requests、--mem-fraction-static。若仍不足說明該顯卡物理顯存低于權重駐留需求需要更換更大顯存卡或改用 Mini 檔。觀察啟動日志SGLang 會打印權重加載與顯存占用明細定位是權重溢出還是 KV cache 溢出前者只能換卡后者可通過參數(shù)收斂。端口沖突Address already in use官方命令固定使用30000端口-p 30000:30000與--port 30000。沖突排查先查端口占用ss -tlnp | grep 30000或lsof -i:30000確認被哪個進程占用。換宿主機映射端口容器內端口不必改只改-p左側宿主機端口即可例如-p 8080:30000。容器內多服務共存同一容器內如需起多個服務用--port換端口注意--host 0.0.0.0保證外部可達。驗證服務健康啟動后curl http://localhost:30000/health返回正常即完成拉起。若用--network host模式官方 Max 命令的用法則端口映射參數(shù)-p應省略直接以宿主機端口暴露。一張顯卡的現(xiàn)實邊界必須誠實說明官方為 Pro 檔給出的基線是8×H100Nex-N2.5 系列中真正面向輕量部署的是 Mini 檔官方基線 2×H100。一張 NVIDIA 顯卡搞定成立的前提是顯卡擁有足夠大的顯存如 H100 80G 級別配合官方 FP8 權重 FP8 KV cache 收窄上下文可以單卡運行 Pro 服務但并發(fā)與上下文長度需要嚴格約束如果只有消費級顯卡更務實的路線是選擇 Mini 檔權重約 35B 參數(shù)量級或社區(qū)量化版本它們的架構與部署參數(shù)完全一致只是把--tp與--context-length進一步下調即可。從 config.json 的 FP8 分塊量化到 chat_template.jinja 的思考模式模板再到 README.md 的完整啟動命令Nex-N2.5-Pro 的部署鏈路在倉庫內是自洽、可復現(xiàn)的。按上面三步操作從拉取 122 個分片到curl返回健康狀態(tài)中間幾乎沒有需要調代碼的環(huán)節(jié)——這正是容器化 定制推理框架給開源 agentic 模型帶來的最大價值把復雜度留在鏡像里把確定性的啟動命令交給開發(fā)者?！久赓M下載鏈接】Nex-N2.5-Pro項目地址: https://ai.gitcode.com/hf_mirrors/nex-agi/Nex-N2.5-Pro創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考