两台迷你主机拼在一起跑本地大模型这件事我从去年就开始折腾了。最开始的想法特别朴素——手头有一台小主机显存不够上下文一拉长就爆于是想着再搞一台两台凑一起显存翻倍是不是就能把长上下文这个老大难问题给啃下来结果真上手之后才发现事情远没有112那么简单。集群通信、显存分配、推理框架的并行策略、长上下文下的注意力计算开销每一个环节都能让你卡上大半天。这篇就把我这两台机器跑本地智能体的完整过程摊开讲重点回答一个很多人关心的问题两台机器凑出来的算力长上下文到底能不能用能用到什么程度代价是什么。如果你手里正好有一到两台小主机、迷你主机或者带独显的机器想跑本地智能体又不想上大显卡那这篇内容应该能帮你少走不少弯路。我会从整体思路、硬件与框架选型、具体部署步骤、长上下文的实测表现一直讲到踩过的坑和排查方法尽量把每个为什么这么选都讲清楚而不是只丢一堆命令让你照抄。1. 整体思路与方案选型为什么是两台而不是一张大卡1.1 需求拆解本地智能体到底吃的是什么资源先把需求说清楚不然选型就是瞎选。本地智能体Agent和单纯跑一个聊天模型不一样它对资源的需求有几个很鲜明的特点。第一是上下文长度。智能体要读工具返回结果、要维护多轮对话历史、要保留任务规划中间态上下文动辄几万 token 起步。上下文一长KV Cache 就跟着涨显存占用是线性甚至更陡地往上走。这是本地跑智能体最要命的一环。第二是并发与响应。智能体经常需要连续调用模型比如规划一步、执行一步、再反思一步中间还夹着工具调用。它对首 token 延迟和整体吞吐都有要求不能慢到没法用。第三是模型规模。想让智能体真的能干点活模型不能太小量化之后怎么也得是能稳定遵循指令、能调用工具的水平。参数量上去权重占的显存也上去。把这三点合起来看你会发现瓶颈几乎全压在显存上。权重占一块KV Cache 占一块中间激活再占一块。单台小主机那点显存权重一放就所剩无几上下文稍微一拉就 OOM。这就是我想加第二台机器的直接原因。1.2 两条路线对比换大卡 vs 双机集群面对显存不够摆在面前其实就两条路。一条是直接换一张大显存显卡。这条路最省心插上就能用软件层面几乎零改动推理框架对单卡的支持也最成熟。但问题也很现实大显存卡价格高、功耗高、对机箱电源散热都有要求而且我手头这两台小主机的定位本来就是低功耗常开换卡等于把整个方案推倒重来。另一条是两台机器组集群做分布式推理。这条路的好处是复用现有硬件成本低扩展性理论上更好——不够再加一台。坏处是复杂度陡增要处理节点间通信、要选支持多机的推理框架、要调并行策略而且长上下文场景下通信开销会被放大。我最后选了第二条。原因很直接我想验证的恰恰是低成本的分布式方案在长上下文下到底能不能打这本身就是个有价值的问题。如果只是换张大卡那这篇就没啥可写的了。1.3 分布式推理的三种并行策略选错等于白干决定走集群路线之后第一个要搞明白的就是并行策略。分布式推理主流有三种切法理解它们的区别非常关键因为长上下文场景下选错策略性能会差出一个数量级。张量并行Tensor ParallelTP把单个矩阵乘法拆到多台机器上算每层都要通信。它的优点是能切权重、能降单卡显存压力缺点是通信极其频繁对节点间带宽和延迟要求极高。放在两台通过普通网络连接的机器上TP 基本会被通信拖死。流水线并行Pipeline ParallelPP把模型按层切成几段每台机器负责一段数据像流水线一样流过。它的通信量比 TP 小得多只在层与层交界处传激活值。缺点是会有流水线气泡利用率受影响而且对长上下文来说激活值传输量也不小。数据并行Data ParallelDP每台机器都放一份完整模型各自处理不同请求。它不解决单请求显存不够的问题只提升吞吐。对单条长上下文请求这个场景基本没用。我的场景是单请求、长上下文、两台机器所以真正有意义的是 TP 和 PP 的组合。实际选型时我倾向于优先 PP、谨慎用 TP因为两台机器之间的网络带宽通常远不如卡内互联TP 的通信压力扛不住。这个判断在后面实测里也得到了验证。提示如果你只有两台机器且网络是普通千兆或 2.5G别一上来就开 TP先试 PP或者用框架提供的混合策略把 TP 限制在单机内部。2. 硬件与框架选型把每一分算力用在刀刃上2.1 两台机器的配置与互联方式先交代一下我用的硬件都是很普通的配置没有堆料。项目机器 A机器 B角色主节点工作节点显存单卡 16GB 级单卡 16GB 级内存64GB64GB互联2.5G 有线直连2.5G 有线直连系统LinuxLinux两台机器用一根网线直连走 2.5G。为什么直连而不是走交换机因为直连能省掉一层转发延迟更低、抖动更小对分布式推理这种对延迟敏感的场景更友好。如果你家里有现成的 2.5G 或万兆交换机走交换机也行但直连是更稳的选择。这里有个很多人忽略的点互联带宽直接决定了你能不能用 TP。2.5G 换算下来大约 300MB/s 出头这个带宽跑 PP 的激活传输勉强够用跑 TP 就纯属自虐了。所以我的策略从一开始就很明确——PP 为主TP 只在单机内部用。2.2 推理框架怎么选三个维度打分框架选型我主要看三个维度是否支持多机、是否支持长上下文优化、部署复杂度。支持多机分布式推理的框架不算少但真正对长上下文友好的不多。长上下文的核心优化点在于 KV Cache 的管理比如分页注意力、KV Cache 量化、前缀缓存复用等。如果框架不支持这些上下文一长显存就爆多机也救不了。我最后选的是一个支持多机 PP、并且带 KV Cache 分页管理的框架。选它的核心理由是它把长上下文的显存问题当成一等公民来处理而不是让你自己去抠。部署复杂度上它提供了相对清晰的分布式启动参数两台机器配置起来不算太痛苦。注意框架版本一定要两台机器完全一致包括依赖库版本。我踩过一次坑两台机器框架小版本差了一位结果分布式初始化一直失败报的错还特别隐晦查了大半天才发现是版本不一致。2.3 模型选择量化等级与上下文窗口的权衡模型这块我选的是一个中等规模、指令遵循能力不错的开源模型做了 4bit 量化。为什么是 4bit 而不是更高精度因为显存实在紧张4bit 能在两台机器上把权重压到可接受的范围同时质量损失在可接受区间。这里有个关键权衡量化等级越低权重占显存越少但长上下文下的质量衰减可能越明显。尤其是长上下文场景模型需要在很长的历史里保持注意力量化带来的数值误差会被放大。我的做法是先用 4bit 跑通再对比 8bit 在长上下文任务上的表现看质量差距是否值得那部分显存。上下文窗口的设置也要务实。模型标称支持多少 token 是一回事你实际能稳定跑到多少是另一回事。我一开始把窗口设到模型标称上限结果显存直接爆。后来逐步往下调找到一个显存不爆、质量还行的平衡点这个点才是你真正能用的窗口。3. 实操部署从零把两台机器跑起来3.1 环境准备与依赖对齐部署第一步不是敲命令而是把两台机器的环境对齐。这一步做扎实后面能省掉大量玄学问题。具体要做的两台机器系统版本尽量一致内核版本差异不要太大。显卡驱动版本一致CUDA 版本一致。推理框架版本一致Python 环境用虚拟环境隔离。时间同步打开分布式通信对时间戳敏感。主机名和 hosts 配好让两台机器能互相用名字解析。时间同步这点特别容易被忽略。我有一次分布式启动卡在初始化阶段日志里啥有用信息都没有最后发现是两台机器时间差了十几秒导致某些握手逻辑超时。把时间同步打开之后问题直接消失。3.2 网络配置与连通性验证网络是分布式推理的命脉必须先把连通性和带宽验证清楚。先确认直连网段配好两台机器能互相 ping 通。然后测实际带宽别只看网卡标称速率。我用的测试方法是两台机器之间传一个大文件看实际吞吐。2.5G 直连实测能跑到 280MB/s 左右这个数字心里有底之后后面调参就有依据了。# 在机器 B 上启动一个简单的接收端机器 A 发送测试数据 # 机器 B nc -l 5000 /dev/null # 机器 A dd if/dev/zero bs1M count2000 | nc 机器B地址 5000这个测试能直观告诉你实际带宽。如果实测远低于标称先查网线质量、网卡协商速率别急着上推理。3.3 分布式启动参数详解启动分布式推理核心是几个参数节点角色、节点数量、并行度配置、通信后端。节点角色上一台是主节点rank 0负责协调另一台是工作节点。节点数量就是 2。并行度配置是重点PP 设成 2TP 设成 1也就是把模型按层切成两段每台机器一段不做张量切分。这个配置在两台机器、普通网络的场景下是最稳的。通信后端要选对。分布式推理通常需要一个通信库来传激活值和同步状态选一个对网络延迟不敏感、支持 CPU 参与通信的后端。具体选哪个取决于框架但原则是优先选经过验证、社区用得多的后端别用冷门的。启动命令大致长这样参数名以你用的框架为准# 主节点 python -m 框架.launch \ --nnodes 2 \ --node-rank 0 \ --master-addr 主节点地址 \ --master-port 29500 \ --pipeline-parallel-size 2 \ --tensor-parallel-size 1 \ --model 模型路径 \ --max-model-len 32768 # 工作节点 python -m 框架.launch \ --nnodes 2 \ --node-rank 1 \ --master-addr 主节点地址 \ --master-port 29500 \ --pipeline-parallel-size 2 \ --tensor-parallel-size 1 \ --model 模型路径 \ --max-model-len 32768两个节点的参数除了 node-rank 之外必须完全一致尤其是并行度和模型路径。模型路径建议用共享存储或者两台机器都放一份别用网络挂载长上下文加载时网络挂载容易成为瓶颈。3.4 首次启动与冒烟测试第一次启动别急着上长上下文先用一个短请求做冒烟测试确认分布式链路通了。冒烟测试要验证三件事模型能正常加载、请求能正常返回、两台机器的显存都吃上了。如果只有一台机器显存涨了说明 PP 没生效模型全压在一台上了。如果请求返回但特别慢可能是通信没走对路径。我建议冒烟测试用一句特别简单的话比如让它复述一句话看返回是否正常。这一步过了再逐步加长上下文。4. 长上下文实测到底能不能用4.1 测试方法设计怎么测才算数测长上下文不能只测能不能返回要测三个维度能不能装下、装下之后快不快、快的同时质量行不行。我的测试设计是这样的构造不同长度的输入从 4K 一路加到 32K每个长度测三件事——首 token 延迟、生成速度、显存峰值。同时准备一组需要长上下文才能答对的问题比如把关键信息埋在几万 token 的中间位置看模型能不能捞出来。这就是常说的大海捞针测试能有效检验长上下文的真实可用性。4.2 显存占用实测KV Cache 是最大变量实测下来显存占用的大头确实是 KV Cache。权重是固定的但 KV Cache 随上下文长度线性增长。下面是我实测的大致趋势数值为示意具体因模型和框架而异上下文长度权重占用KV Cache 占用总显存状态4K固定小低轻松8K固定中中正常16K固定较大较高接近上限32K固定大很高需优化才能跑关键结论两台机器 PP 切分之后权重被分摊了但 KV Cache 的分摊取决于框架实现。如果框架把 KV Cache 也按层切分那两台机器各存一半长上下文就能撑得更久如果 KV Cache 集中在某一台那台就会先爆。这一点在选框架时一定要确认清楚。4.3 速度实测通信开销是隐形杀手速度这块PP 的通信开销在长上下文下会被放大。原因很简单长上下文意味着每层要处理的 token 更多层与层之间传的激活值也更大2.5G 的带宽就成了瓶颈。实测下来短上下文时两台机器和单机差距不大但上下文一长双机的生成速度会明显低于单机同配置如果单机能装下的话。这就是分布式的代价——你用通信换来了显存但通信本身要花时间。所以我的结论是双机 PP 适合单机装不下、但你能接受速度下降的场景。如果你的上下文长度单机就能装下那双机纯属给自己找麻烦。4.4 质量实测大海捞针能不能捞到质量测试是最有意思的部分。我把关键信息埋在不同位置测模型能不能准确捞出来。结果符合预期在模型有效窗口内捞针准确率不错一旦超过某个长度准确率开始明显下降。这个下降点往往早于显存爆掉的点。也就是说显存还能装但模型已经记不住了。这提醒我们能装下不等于能用好有效上下文窗口才是真正该关注的指标。量化对长上下文质量的影响也在这里体现出来。4bit 在短上下文下和 8bit 差距不大但在长上下文捞针任务上4bit 的准确率下降更明显。如果你的智能体任务对长上下文精度要求高可能得考虑牺牲一点显存换更高精度。5. 常见问题与排查技巧实录5.1 分布式启动失败排查表现象可能原因排查方向初始化卡住不动时间不同步 / 网络不通检查时间同步、ping 测试报版本不匹配框架或依赖版本不一致逐项对比两台机器版本只有一台显存涨PP 未生效检查并行度参数启动即 OOM上下文设太大 / 权重没分摊调小 max-model-len确认 PP通信超时带宽不足 / 防火墙拦截测带宽、查端口放行5.2 长上下文 OOM 的三种解法长上下文 OOM 是最常见的坑我总结了三种解法按优先级排第一调小 max-model-len。这是最直接的先让它能跑起来再逐步往上加找到稳定点。第二开 KV Cache 量化。把 KV Cache 也用低精度存能省不少显存代价是轻微的质量损失。这个开关很多框架都有值得一试。第三开前缀缓存复用。如果智能体的系统提示词很长且固定前缀缓存能避免重复计算既省显存又提速。智能体场景下这个优化收益很大。5.3 速度慢的排查思路速度慢先分清是计算慢还是通信慢。判断方法看显卡利用率。如果显卡利用率高但速度还是慢那是计算瓶颈考虑量化或换更小的模型如果显卡利用率低那多半在等通信这时候要检查网络带宽、并行策略是否合理。我踩过的一个坑是PP 的切分点没选好导致两台机器负载不均一台忙死一台闲死。调整切分点让两层计算量接近速度能明显改善。切分点怎么选看模型各层的参数量和计算量尽量让两段均衡。提示PP 切分不是随便切的切在计算量相近的地方流水线效率最高。切歪了慢的那台会拖垮整体。6. 智能体场景下的额外优化6.1 工具调用与上下文管理智能体跑起来之后上下文增长比纯聊天快得多因为工具返回结果往往很长。我的做法是对工具返回做截断和摘要只把关键信息塞回上下文而不是原样全塞。这一招能显著延长有效上下文的使用时间。另外智能体的系统提示词通常很长且固定一定要用前缀缓存。前缀缓存能让这部分只算一次后续请求直接复用省显存又提速是智能体场景下性价比最高的优化之一。6.2 多轮对话的 KV Cache 复用多轮对话里历史部分的 KV Cache 其实是可以复用的。如果框架支持尽量开启。这样每轮只需要计算新增部分而不是把整个历史重算一遍。对长对话智能体来说这个优化能把响应速度拉回可用区间。6.3 任务拆分降低单次上下文压力还有一个思路是从任务设计上降低上下文压力把大任务拆成小任务每个小任务用独立、较短的上下文。智能体不一定非要把所有历史都塞进一个上下文里用外部记忆或者任务状态文件来存中间结果需要时再取。这样单次请求的上下文就能控制住双机的压力也小很多。7. 我的实操心得与几个关键结论折腾这么久几个体会比较深。第一两台机器跑本地智能体长上下文能用但有明确边界。边界取决于你的网络带宽、框架的 KV Cache 管理能力、以及模型的有效窗口。越过边界要么 OOM要么质量崩要么慢到没法用。第二PP 是两台机器最务实的选择TP 慎用。普通网络下 TP 的通信开销扛不住PP 虽然也有通信但量级小得多是更稳的方案。第三有效上下文窗口比标称窗口重要得多。别被标称数字忽悠实测捞针准确率下降的那个点才是你真正能用的窗口。第四智能体场景下前缀缓存和工具返回截断是两个必做的优化收益立竿见影。最后分享一个小技巧如果你只是想验证方案可行性先用小模型、短上下文把分布式链路跑通确认两台机器能协同工作再换大模型、拉长上下文。这样出问题时容易定位不至于一上来就被一堆变量搞晕。分布式推理这东西变量太多一次只改一个是最省时间的调试方式。