企业官网建设流程全解析

1. 两台华硕 Ascent GX10 跑本地 Coding Agent 的真实体验：从单机到双机 vLLM 部署

华硕 Ascent GX10 是一台桌面级 AI 计算设备，单机 128GB 统一内存，能直接跑起 30B 级别的大模型。两台通过 ConnectX-7 高速线缆互联后，可以承载更大的模型，比如 MiniMax M2.7 AWQ 4-bit 这类参数量更高的版本。这套组合能做什么？简单说，就是让本地 AI 不只是聊天，而是真正进入开发流程——读项目文件、建目录、跑命令、改代码、修报错。适合谁？适合长期用 AI 写代码、愿意自己部署模型、能处理 Docker 和 vLLM 配置的开发者。我实测下来，单机跑 Qwen 3.6 35B 能出活，但需要人频繁介入；双机跑更大模型后，Agent 的自主性明显提升，会主动用 create-next-app 搭脚手架，功能完成度也更高。下面把双机互联、vLLM 启动参数、OpenCode 接入本地端点的完整配置和踩坑过程写清楚。

2. 双机互联与 vLLM 多节点部署：NCCL 验证与启动参数配置

两台 GX10 互联的第一步是物理连接。用 QSFP 线缆把两台机器的 ConnectX-7 网口直连，不需要交换机。连好后，先确认系统识别到网卡：

ibdev2netdev

输出里应该能看到两个 mlx5 设备，状态为 Active。如果只看到一个，检查线缆是否插紧，或者换一根线试试。

接下来验证 NCCL 通信。这一步很关键，如果 NCCL 不通，后面 vLLM 多节点启动会直接卡死。用官方测试工具跑一遍：

# 在两台机器上分别执行，指定主节点 IP # 主节点（假设 IP 为 169.254.1.1） ./nccl-tests/build/all_reduce_perf -b 8 -e 128M -f 2 -g 1 # 从节点 ./nccl-tests/build/all_reduce_perf -b 8 -e 128M -f 2 -g 1 -c 1 -n 100

如果输出里能看到 bus bandwidth 数值，说明 NCCL 通信正常。我踩过的坑是：两台机器的 NCCL 版本不一致，导致 all_reduce 直接报错。解决办法是统一用容器里的 NCCL，或者把宿主机的 NCCL 升级到相同版本。

vLLM 多节点启动需要指定分布式参数。主节点执行：

vllm serve /models/MiniMax-M2.7-AWQ \ --tensor-parallel-size 2 \ --pipeline-parallel-size 1 \ --distributed-executor-backend ray \ --ray-address auto \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.85 \ --quantization awq \ --trust-remote-code

从节点需要先启动 Ray 并加入集群：

ray start --address=169.254.1.1:6379 --node-ip-address=169.254.1.2

然后在从节点上不需要再执行 vllm serve，Ray 会自动调度。这里有个细节：--tensor-parallel-size 2表示把模型切到两张卡上，但 GX10 是统一内存架构，实际是把模型分到两台机器的内存里。--gpu-memory-utilization 0.85是给 KV Cache 留空间，如果设太高，模型加载完但推理时 OOM。

启动过程中如果遇到容器权限问题，比如 NCCL 报permission denied或者ibv_reg_mr failed，需要在 Docker 启动时加--privileged和--cap-add=IPC_LOCK。我实测下来，加 privileged 后吞吐从 26-28 tokens/s 提升到接近 41 tokens/s，效果很明显。

模型文件放在 NAS 上通过网络加载，vLLM 启动时指定路径即可。但要注意 NAS 的读取速度，如果网络带宽不够，模型加载会非常慢。建议用 10GbE 以上连接，或者把模型文件提前拷贝到本地 NVMe。

3. OpenCode 接入本地 vLLM 端点的可复制配置

vLLM 服务跑起来后，OpenCode 需要指向本地端点。OpenCode 是一个 coding agent 工具，能读项目文件、执行终端命令、修改代码。它的配置文件通常放在项目根目录的.opencode/config.json或者用户目录的~/.opencode/settings.json。下面是一份可复制的配置片段：

{ "provider": { "local-vllm": { "type": "openai", "baseURL": "http://169.254.1.1:8000/v1", "apiKey": "sk-local-no-auth", "models": { "minimax-m2.7": { "name": "MiniMax-M2.7-AWQ", "maxTokens": 32768, "temperature": 0.2, "topP": 0.95 } } } }, "agent": { "model": "local-vllm/minimax-m2.7", "workspace": "/home/user/projects/homelab-tracker", "autoApprove": false, "maxIterations": 50 } }

这里baseURL填主节点的 IP 和 vLLM 端口，apiKey随便填一个，因为本地 vLLM 默认不校验。maxTokens要和 vLLM 启动时的--max-model-len一致，否则请求会被截断。temperature设 0.2 是为了让代码生成更稳定，太高容易胡编。

如果你用的是 Cline 或者 Claude Code 这类工具，配置逻辑类似，核心三件套是 Base URL、Key、Model ID。以 Cline 为例，在 VS Code 设置里找到 Cline 的 Provider 配置：

{ "cline.provider": "openai", "cline.baseUrl": "http://169.254.1.1:8000/v1", "cline.apiKey": "sk-local-no-auth", "cline.model": "MiniMax-M2.7-AWQ" }

注意 Model ID 要和 vLLM 启动时加载的模型名称一致。如果 vLLM 启动时用的是路径/models/MiniMax-M2.7-AWQ，那 Model ID 就是MiniMax-M2.7-AWQ，不要带路径。

OpenCode 启动后，它会自动读取项目文件，建立索引。第一次运行会慢一些，因为要扫描整个项目。之后就可以给它下任务了，比如：

opencode run "创建一个 HomeLab 服务追踪器，用 Next.js 和 SQLite，包含 Proxmox、TrueNAS、Grafana、Plex、Pi-hole 的服务列表，支持增删改查和过滤"

Agent 会先创建 spec、task、agents、progress 文件，然后按步骤推进。如果中途卡住，可以输入continue让它继续。我实测下来，双机跑 MiniMax M2.7 时，Agent 会主动调用create-next-app生成脚手架，而不是手写一堆配置文件，这一点比单机跑 Qwen 35B 时聪明很多。

4. 验证请求与成功结果：单机与双机的生成质量、延迟与吞吐对比

配置完成后，先用 curl 验证 vLLM 端点是否正常：

curl http://169.254.1.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "MiniMax-M2.7-AWQ", "messages": [{"role": "user", "content": "写一个 Python 函数，计算斐波那契数列第 n 项"}], "max_tokens": 256, "temperature": 0.2 }'

如果返回 JSON 里有choices字段和生成的代码，说明端点正常。如果报connection refused，检查 vLLM 是否还在运行，或者防火墙是否挡住了 8000 端口。

接下来用同一批代码任务对比单机和双机。我选了三个任务：生成一个 REST API、修复一个过滤 Bug、把 UI 改成 Windows XP 风格。单机跑 Qwen 3.6 35B FP8，双机跑 MiniMax M2.7 AWQ 4-bit。

第一个任务，单机用了 12 轮对话才把 API 跑起来，中间卡在工具调用里两次，需要手动输入 continue。双机用了 7 轮，Agent 主动选了 FastAPI 而不是 Flask，还自己写了 pytest 测试。延迟方面，单机首 token 延迟约 1.2 秒，双机约 1.8 秒，因为模型更大，加载和推理都慢一点。但吞吐上，双机稳定在 40 tokens/s 左右，单机在 55 tokens/s 左右，单机反而更快。

第二个任务，修复过滤 Bug。单机跑了 5 轮，模型一直改不对 search params 的用法，最后我让它去看 Next.js 文档，才找到正确写法。双机跑了 3 轮，模型自己读了node_modules/next/dist/docs里的文档，然后改对了。这个差异很明显，大模型在工具使用和文档检索上更强。

第三个任务，Windows XP 风格改造。单机直接放弃了，说“这个任务太复杂”。双机真的做出了开始菜单、窗口、状态栏、服务图标和可移动窗口。虽然细节粗糙，但功能可用。这个任务考验的是 Agent 对现有项目结构的理解和持续迭代能力，双机明显更稳。

吞吐测试用 vLLM 自带的 benchmark：

vllm bench serve \ --backend openai-chat \ --base-url http://169.254.1.1:8000 \ --model MiniMax-M2.7-AWQ \ --num-prompts 50 \ --request-rate 2

单机 Qwen 35B 的 output throughput 约 55 tokens/s，双机 MiniMax M2.7 约 41 tokens/s。双机吞吐低一些，但生成质量高很多，少走弯路节省的时间远超吞吐差距。

5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth 报错

第一个常见报错是 401 Unauthorized。本地 vLLM 默认不校验 API Key，但 OpenCode 或 Cline 可能会强制要求填 Key。如果报 401，检查配置文件里的apiKey是否为空。随便填一个字符串就行，比如sk-local-no-auth。如果 vLLM 启动时加了--api-key参数，那就要填对应的值。

第二个报错是local proxy failed。这个通常出现在 OpenCode 尝试连接本地端点时，原因是baseURL写错了。注意不要写成http://localhost:8000，因为 OpenCode 可能跑在容器里，localhost 指向容器本身而不是宿主机。要写宿主机的实际 IP，比如http://169.254.1.1:8000/v1。如果还是不通，用curl在容器里测试一下。

第三个报错是reading choices相关，比如Error reading choices: list index out of range。这个说明 vLLM 返回的 JSON 里没有choices字段，通常是模型加载失败或者请求格式不对。检查 vLLM 日志，看模型是否成功加载。如果日志里有OOM或者CUDA out of memory，降低--gpu-memory-utilization或者减小--max-model-len。另外确认请求里的model字段和 vLLM 加载的模型名称一致。

第四个报错是 OAuth 相关，比如OAuth token expired或者invalid_grant。这个一般出现在用云端 API 的工具上，但如果你在 OpenCode 里配置了云端 Provider 又切到本地，可能会残留 OAuth 配置。检查~/.opencode/settings.json里是否有oauth字段，删掉或者改成"oauth": null。如果用的是 Claude Code，检查~/.claude/config.json里的authType是否为apiKey而不是oauth。

还有一个坑是 NCCL 版本不一致导致的unhandled cuda error。两台机器的 NCCL 版本必须一致，建议都用容器里的 NCCL，或者把宿主机的 NCCL 升级到相同版本。检查命令：

dpkg -l | grep nccl

如果版本不同，卸载后重新安装相同版本。

最后，如果 vLLM 启动时卡在Loading model weights超过 10 分钟，检查 NAS 的读取速度。模型文件如果放在 NAS 上，网络带宽不够会导致加载极慢。建议用iftop看一下网络流量，如果只有几 MB/s，说明带宽瓶颈。解决办法是把模型文件拷贝到本地 NVMe，或者升级到 10GbE 网络。

6. 本地 Coding Agent 的长期使用建议与接入文档

两台 GX10 跑本地 Coding Agent，硬件成本不低，单台 3 万多，两台加上 QSFP 线缆和功耗，投入不小。但它适合一类明确的人：长期用 AI 写代码，愿意把模型部署、项目环境和执行链路放在自己手里。这类人面对的任务往往不够性感，却很耗时间，比如老项目依赖升级、测试补齐、UI 细节修复、内部工具重构。Coding Agent 的价值就在这些地方，你给它一个清晰目标，它在后台不断尝试、修改、运行、修复，你保留最终判断，负责 review 和验收。

如果你打算长期跑本地 Coding Agent，建议把模型文件放在本地 NVMe 而不是 NAS，减少加载时间。vLLM 启动参数里--gpu-memory-utilization不要超过 0.9，给 KV Cache 留足空间。OpenCode 的maxIterations设 50 左右，太少容易半途而废，太多会浪费算力。另外，定期检查 NCCL 和 vLLM 的版本，保持一致，避免通信报错。

如果你需要更稳定的 API 接入方案，或者想对比本地部署和云端 API 的成本，可以访问 TaoToken 的接入文档：https://taotoken.net/api 和 API Keys 管理页面：https://taotoken.net/api-keys 。模型对话功能可以直接在 https://taotoken.net/model-chat 体验，长期编码和 Agent 任务可以看 Coding Plan：https://taotoken.net/coding-plan 。Claude Code 的接入配置参考：https://taotoken.net/claude-code 。控制台地址：https://taotoken.net/console 。官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。

本地 AI 还会卡住，还会犯错，还会误判，也会把环境搞乱。可它已经能打开一个项目，理解需求，修改代码，运行检查，把一个小应用一步步推到可用状态。它离“放手让 AI 写完项目”还有距离，但离“把一部分工程脏活交给本地机器”已经很近了。