概要本文记录一次低成本跨服务器大模型推理平台实践两台 A40 GPU 服务器4×A40 48GB总显存 192GB无 IB、无 RoCE、无 NVLink仅使用 4×10G 直连网络通过 vLLM Ray 部署 Qwen3-Coder-Next 80B MoE并通过 FastAPI 网关对接 Claude Code、Dify 和 OpenAI 协议。重点记录 NCCL 多网卡配置、Ray 重启残留、Prefix Cache、Anthropic/OpenAI 协议转换和 SSE 流式转发等工程问题。如果你在工作中有类似的环境不妨弄起来不用完全烧服务商的token了环境说明本文不是性能评测论文而是一套工程可用性验证。所有结论基于以下环境2 台 GPU 服务器每台 2 张 NVIDIA A40 48GB两台之间 4×10G 网线直连无 IB、无 RoCE、无 NVLinkvLLM RayTP4模型为 Qwen3-Coder-Next 80B MoE用途为 Agent 私有后端而非高并发推理服务。最终结论能跑但别把它当成高并发商业推理平台。这套环境没有 InfiniBand没有 RoCE没有 NVLink。只有两台原本快要吃灰的 A40 GPU 服务器每台 2 张 NVIDIA A40 48GB总共 4 张卡、192GB 显存。两台机器之间没有高端互联只拉了 4 根 10G 网线直连。我最后把它们拼成了一套能跑 Qwen3-Coder-Next 80B MoE 的 Agent 私有算力池可以接 Claude Code可以接 Dify也可以按 OpenAI 协议给内部工具调用。这篇不讲玄学只讲一件事没有 IB/RoCE 的情况下跨服务器跑 80B 大模型到底能不能用。问题我的结论没有 IB/RoCE 能不能跨服务器跑大模型能但场景要选对4×10G 网线够不够给 Agent 当后台够用高并发推理不建议A40 适合吗适合复用闲置资源不适合追求极限性能最大的坑是什么NCCL 多网卡、Ray 残留、SSE 流式转发、协议转换最适合什么场景Claude Code、Dify、内部 Agent、SQL 助手、研发自用平台我的定位很明确这不是企业级推理平台也不是拿来卷吞吐量的方案。它更像一个给 AI Agent 用的私有后端。Agent 场景和普通聊天不太一样。它通常是单人或小团队使用更在意“能不能稳定调用工具、读代码、写代码、长上下文工作”而不是几百路并发一起压上来。这就给了 4×10G 一个机会。硬件192GB 显存刚好跨过门槛我的硬件配置大概是这样组件配置GPU4× NVIDIA A40 48GB总显存192GBGPU 服务器2 台每台 2 卡内联网络4×10G 网线两台直连管理网络1G 网口推理框架vLLM Ray模型Qwen3-Coder-Next 80B MoEA40 这张卡有个尴尬点显存大但没有 NVLink。单机双卡之间靠 PCIe跨机器就只能靠网络。如果是 A100/H100 NVLink IB那是正经高速路我这个更像是把几条省道硬拼起来车能跑但你得知道哪里会堵。为什么选 80B MoE最后选的是 Qwen3-Coder-Next主要是三个原因。第一MoE 对显存比较友好。80B 听起来很大但推理时不是每次都激活全部参数。对 Agent 后台来说它比同规模 Dense 模型更现实。第二代码能力更贴近需求。我这套平台的主要用途不是闲聊而是给 Claude Code、内部研发工具、数据库助手做后端。读代码、改代码、生成 SQL、解释报错这些能力比“会不会写诗”重要。第三192GB 显存刚好卡在可用边缘。权重、KV Cache、上下文长度都不能太浪。这个方案不是富裕是能跑。真正的问题不是显存而是跨节点通信显存够了只说明模型能装进去。跨服务器推理真正难的是通信。没有 IB没有 RoCE两台机器之间只有 4 根 10G 网线。最开始我以为 NCCL 会自动把所有网卡都用上后来发现不是这么简单。如果不指定多网卡环境里 NCCL 可能只走一根网线。也就是说你明明插了 4 根线实际大部分通信堵在一根 10G 上剩下三根在旁边看热闹。关键配置就这一行NCCL_SOCKET_IFNAMEens6f0,ens6f1,ens7f0,ens7f1然后把内联网口 MTU 调到 9000也就是 Jumbo Frame减少小包开销。这一步之后4 根 10G 才算真正参与进来。它不会把普通以太网变成 IB但至少不再浪费已经插上的线。我的体感是40K 上下文的首 token 延迟不是毫秒级但作为 Agent 后台可以接受。尤其是 Claude Code 这类场景本来就有读文件、工具调用、执行命令等步骤用户对延迟的感知和纯聊天不一样。vLLM Ray能跑但重启一定要干净推理层我用的是 vLLM RaymodeARay Head vLLM HeadmodeBRay WorkerTensor ParallelTP4Prefix Cache开启上下文40K 级别这里有个坑很典型Ray 重启不干净会留下旧 session。我遇到过这样的错误ActorHandleNotFoundError: The actor handle was created in job 01000000, but the current job is 02000000最后发现是/tmp/ray和/dev/shm里残留了上一次的状态。解决办法很粗暴但有效ray stop --force pkill -9 -f ray rm -rf /tmp/ray /dev/shm/*ray*这类问题不是算法问题而是工程问题。跨节点部署大模型很多时候不是卡在“模型能不能跑”而是卡在这些脏状态、网络接口、进程残留和启动顺序上。网关层比我想象中更重要如果只是跑一个 vLLM API其实还不够。我真正想要的是Claude Code 能用Dify 能接内部工具也能像调用 OpenAI 一样调用它。所以我在 GPU 推理层前面加了一个 FastAPI 网关专门处理这些事用户登录API Key 鉴权OpenAI 协议转发Anthropic ↔ OpenAI 协议互译SSE 流式输出用量统计联网搜索会话管理网关看起来像转发器实际是整套系统里最容易踩坑的地方。比如 Claude Code 发的是 Anthropic/v1/messages格式vLLM 后端吃的是 OpenAI/v1/chat/completions格式。两边的 tools、tool_calls、content blocks、stream events 都不一样。如果只是把 JSON 改个字段名不够。尤其是流式工具调用必须把 OpenAI 的增量事件重新拼成 Anthropic 能理解的 SSE 事件。少一个content_block_stopClaude Code 可能就会出现“内容闪一下又消失”的怪现象。另一个坑不能相信客户端传来的 max_tokensClaude Code 默认可能会带一个很大的max_tokens这是给长上下文 Claude 模型设计的。但我的后端模型上下文只有 40960。如果输入 prompt 已经有 9000 tokens再让它输出 32000 tokens就很容易超过模型窗口。超一点点vLLM 也会直接拒绝。我最后在网关层做了硬限制max_tokens 8192这不是最优雅的方案但很稳。自建模型服务时不要完全相信客户端参数。网关层一定要有自己的边界。Prefix Cache 是 Agent 场景的隐藏福利Claude Code 这类工具有个特点每次请求都会带一大段相似的 system prompt 和上下文结构。这时候 vLLM 的 Prefix Cache 很有用--enable-prefix-caching它不会让模型本身变聪明但会减少重复前缀的计算。对 Agent 场景来说最明显的收益是首 token 等待时间下降体感会好很多。这也是我觉得这套方案能用的原因之一它不是为了所有任务都快而是针对 Agent 工作流做了一些适配。这套方案适合谁我觉得适合这些场景手里有闲置 GPU 服务器预算不想上 IB/RoCE想给 Claude Code / Dify / 内部工具搭私有后端用户量不大但希望模型能力比 7B/14B 更强能接受一定工程折腾不适合这些场景面向大量用户的商业推理服务对首 token 延迟特别敏感需要稳定 SLA不想维护 Ray、vLLM、NCCL、网关希望像云 API 一样开箱即用最后能跑不等于万能没有 IB/RoCE用 4×10G 跑跨服务器 80B 大模型答案不是简单的“可以”或“不可以”。我的答案是如果你想做高并发推理平台不建议。如果你想复用闲置 A40给 Agent、研发工具、Dify、内部助手搭一个私有算力池可以。这套方案的价值不是极限性能而是把原本吃灰的硬件重新用起来。两台 A404 根 10G 线一个 vLLM Ray 集群一个 FastAPI 网关。没有那么豪华但能干活、能调试、能接工具、能给 Agent 当后台。对我来说这就够了。下一篇我准备单独展开讲如何搭建搭建过程注意事项。