双Spark跑本地Agent：长上下文实测与优化指南

1. 两台 Spark 跑本地 Agent 这件事，到底在测什么

两台 Spark 凑一起跑本地 Agent，这个场景本身就带着一股“折腾”的味道。Spark 这类设备单台算力有限，显存和内存都是紧巴巴的，把两台连起来做分布式推理，听起来像是把两辆小排量车串起来拉货，能不能跑得动、跑得稳，全看你怎么调度。我这次要聊的核心，就是在这种双机环境下跑一个本地 Agent，重点观察长上下文到底能不能扛住。

先说清楚这个项目在做什么。本地 Agent 和普通的对话模型不一样，它不是一问一答就结束，而是需要维护一个持续的状态，包括对话历史、工具调用记录、中间推理步骤，甚至还要把外部检索到的内容塞进上下文里。这些内容叠加起来，上下文长度很容易就冲到几万甚至十几万 token。长上下文能不能用，直接决定了这个 Agent 是“能用”还是“只能演示”。

适合谁来参考这篇内容？如果你手里正好有两台 Spark 或者类似定位的设备，想跑一个本地 Agent 做实验，或者你正在评估长上下文在实际 Agent 场景下的表现，那这篇东西应该能帮你省下不少试错时间。如果你只是单纯好奇本地 Agent 的部署逻辑，也可以看看里面的思路拆解，很多坑是通用的。

我自己的背景是做过几年推理部署和 Agent 应用开发，踩过的坑不算少。这次双 Spark 跑本地 Agent 的尝试，前后折腾了大概两周，中间推翻过两次方案，最后跑通了一个相对稳定的配置。下面就把整个过程拆开来讲，包括为什么这么选、怎么配、遇到什么问题、怎么排查。

2. 双机跑本地 Agent 的整体设计思路

2.1 为什么不用单机硬扛

单台 Spark 跑本地 Agent，最直接的问题就是显存不够。Agent 场景下，模型本身要占一部分显存，KV Cache 又要占一部分，再加上工具调用时临时加载的小模型或者检索模块，显存很快就见底了。我试过在单台上把上下文压到 8K 以内，勉强能跑，但 Agent 一旦开始多轮工具调用，上下文迅速膨胀，直接 OOM。

有人可能会说，那就量化呗。量化确实能省显存，但量化之后模型在长上下文下的表现会明显下降，尤其是需要精确引用历史信息的时候，量化模型的注意力容易“散掉”。我实测过 4-bit 量化和 8-bit 量化在 32K 上下文下的表现，4-bit 在需要回溯早期对话内容时，错误率明显上升。所以量化不是不能做，但要看你的 Agent 对长上下文的依赖程度。

双机方案的核心思路是把模型切开放到两台设备上，用流水线并行或者张量并行的方式分担显存压力。流水线并行是把模型的不同层分到不同设备，张量并行是把同一层的计算切分到不同设备。两种方式各有优劣，后面会详细说。

2.2 流水线并行 vs 张量并行，怎么选

流水线并行的好处是实现相对简单，通信量小，因为只需要在层与层之间传递激活值。缺点是设备利用率不高，因为同一时刻只有一台设备在计算，另一台在等。对于 Agent 这种对延迟敏感的场景，流水线并行可能会导致响应变慢。

张量并行的好处是设备利用率高，两台设备同时计算，延迟更低。缺点是通信量大，每一层计算完都要做 all-reduce，对设备间的带宽要求高。如果两台 Spark 之间的连接带宽不够，张量并行的通信开销会吃掉大部分收益。

我最后选的是流水线并行，原因有两个。第一，两台 Spark 之间的连接是普通千兆网，带宽有限，张量并行的 all-reduce 在这种带宽下会成为瓶颈。第二，Agent 场景下我更看重稳定性而不是极致延迟，流水线并行虽然单次推理慢一点，但整体更稳，不容易因为通信抖动导致超时。

提示：如果你有两台设备之间是高速互联（比如万兆网或者直连），张量并行会更有优势。普通千兆网环境下，流水线并行是更稳妥的选择。

2.3 长上下文的关键瓶颈在哪里

长上下文能不能用，瓶颈不在模型本身，而在 KV Cache 的管理。KV Cache 是 Transformer 推理时缓存的历史键值对，上下文越长，KV Cache 越大。以 32K 上下文为例，一个 7B 参数的模型，KV Cache 大概要占 4-6GB 显存，具体取决于层数和头数。

双机环境下，KV Cache 要么放在其中一台设备上，要么两台各存一部分。如果放在一台设备上，那台设备的显存压力会很大。如果两台各存一部分，那每次注意力计算都需要跨设备通信，延迟会增加。

我的做法是把 KV Cache 按层切分，前半部分的层缓存在第一台，后半部分缓存在第二台。这样每台设备的显存压力均衡，跨设备通信只发生在层与层之间，不会在注意力计算内部产生额外通信。这个方案的前提是流水线并行，因为层本身就已经分开了。

3. 核心配置与实操步骤

3.1 硬件与网络环境确认

两台 Spark 的配置要尽量一致，尤其是显存大小。如果一台显存大一台显存小，流水线并行的层分配就要做非均匀切分，实现起来更麻烦。我这两台都是相同配置，显存都是 16GB，模型用的是 7B 参数版本，FP16 精度下模型本身占 14GB 左右，切分后每台大概 7GB，剩下的显存留给 KV Cache 和临时缓冲。

网络方面，两台设备通过千兆交换机连接，实测带宽在 900Mbps 左右，延迟在 0.5ms 以内。这个延迟对于流水线并行来说是可以接受的，因为层与层之间的通信不是特别频繁。如果你用的是无线连接，延迟会高很多，不建议。

注意：两台设备的系统时间要同步，否则在日志排查时会很痛苦。我一开始没注意，两台设备时间差了十几秒，排查问题时日志对不上，浪费了不少时间。

3.2 模型切分与加载

模型切分用的是流水线并行的方式，把模型的层平均分成两份。以 32 层的模型为例，第一台加载第 0 到第 15 层，第二台加载第 16 到第 31 层。嵌入层和输出层放在第一台，因为嵌入层通常和输入处理在一起，输出层放在第二台，因为最后一层的输出直接用于生成。

加载的时候要注意顺序。先启动第二台设备上的进程，让它进入等待状态，再启动第一台。第一台加载完自己的层之后，会尝试连接第二台，建立通信通道。如果顺序反了，第一台会一直重试连接，浪费启动时间。

# 第二台设备上启动 python -m agent_server --rank 1 --world_size 2 --master_addr 192.168.1.102 --master_port 29500 # 第一台设备上启动 python -m agent_server --rank 0 --world_size 2 --master_addr 192.168.1.102 --master_port 29500

这里的master_addr填的是第二台的地址，因为第二台先启动，作为通信的协调者。world_size是 2，表示两台设备。端口选 29500 是习惯用法，只要不冲突就行。

3.3 KV Cache 的分配策略

KV Cache 的分配是长上下文能不能用的关键。我的策略是按层分配，每台设备缓存自己负责的那部分层的 KV。具体来说，第一台缓存第 0 到第 15 层的 KV，第二台缓存第 16 到第 31 层的 KV。这样每台设备的 KV Cache 大小是总大小的一半。

以 32K 上下文为例，总 KV Cache 大概 5GB，每台分 2.5GB。加上模型本身的 7GB，每台显存占用在 10GB 左右，16GB 显存还有余量。如果把上下文拉到 64K，KV Cache 翻倍到 10GB，每台 5GB，加上模型 7GB，总共 12GB，还是能跑，但余量就不多了。

这里有个细节要注意：KV Cache 的分配要和层的分配对齐。如果第一台负责第 0 到第 15 层，那它只需要缓存这些层的 KV，不需要缓存其他层的。这个对齐关系在代码里要写清楚，否则会出现缓存了不该缓存的层，浪费显存。

3.4 Agent 状态管理

Agent 的状态包括对话历史、工具调用记录、中间推理步骤。这些内容都要拼接到上下文里，所以上下文长度会随着对话轮次增加而增长。我的做法是给上下文设一个上限，比如 32K，超过之后就把最早的内容截断，保留最近的对话和关键的工具调用记录。

截断策略有两种：一种是直接丢弃最早的内容，一种是做摘要。直接丢弃简单，但可能会丢失重要信息。做摘要需要额外调用模型，增加延迟。我选的是混合策略：对于普通的对话轮次，直接丢弃；对于工具调用记录，做摘要保留关键参数和结果。

提示：截断的时候要注意保留系统提示词和最近几轮对话，这两部分对 Agent 的行为影响最大。我试过把系统提示词也截掉，结果 Agent 完全跑偏，输出格式都不对了。

4. 长上下文实测：到底能不能用

4.1 测试方法与指标

测试方法很简单：构造不同长度的上下文，从 4K 到 64K，每个长度跑 20 次推理，记录响应时间、显存占用和输出质量。输出质量用人工评估，看 Agent 是否能正确引用历史信息、是否遵循系统提示词、工具调用是否准确。

响应时间从发出请求到收到完整响应计算，包括预处理、推理和后处理。显存占用用设备自带的监控工具记录峰值。输出质量分三档：好（完全正确）、中（部分正确）、差（完全错误）。

4.2 实测数据与解读

从数据看，32K 是一个分水岭。32K 以下，响应时间还能接受，输出质量也还行。32K 时响应时间到了 14 秒，输出质量开始下降，偶尔会出现引用错误。64K 时响应时间超过 30 秒，输出质量明显变差，经常出现答非所问的情况。

显存方面，64K 时每台已经到 15.8GB，接近 16GB 的上限，再长就 OOM 了。所以从显存角度看，64K 是这台设备的极限。

4.3 长上下文下的典型问题

第一个问题是注意力分散。上下文越长，模型越难聚焦到关键信息上。我测试过一个场景：在 32K 上下文中，把关键信息放在第 5K 的位置，然后问一个需要引用这个信息的问题。模型有时候能找对，有时候会引用错误的位置。把关键信息放在最后 4K 内，准确率明显提高。

第二个问题是 KV Cache 的碎片化。长上下文下，KV Cache 的分配和释放会变得频繁，容易产生碎片。我遇到过几次因为碎片导致 OOM 的情况，明明总显存够，但就是分配不出来。解决办法是预分配一块固定的 KV Cache 区域，不要动态申请释放。

第三个问题是跨设备通信的累积延迟。流水线并行下，每层之间的通信都有延迟，层数越多，累积延迟越大。32K 上下文时，通信延迟占总响应时间的比例大概在 15% 左右，64K 时上升到 25%。这个比例不算低，如果对延迟敏感，需要考虑优化通信或者换张量并行。

5. 常见问题与排查技巧

5.1 启动失败与连接超时

启动失败最常见的原因是网络不通或者端口被占用。先检查两台设备是否能互相 ping 通，再检查端口是否被其他进程占用。如果端口被占用，换一个端口就行。

连接超时通常是启动顺序问题。第二台要先启动，进入等待状态，第一台再启动。如果第一台先启动，它会一直尝试连接第二台，直到超时。我一开始就是顺序反了，等了五分钟才反应过来。

注意：如果两台设备之间有防火墙，要确保通信端口是开放的。我遇到过防火墙拦截的情况，日志里只显示连接超时，没有更详细的信息，排查起来很费劲。

5.2 显存不足与 OOM

显存不足的原因有很多，可能是模型太大、KV Cache 太大、临时缓冲太多。先看日志里 OOM 发生在哪个阶段，如果是加载模型时 OOM，说明模型切分不够均匀，需要调整层的分配。如果是推理时 OOM，说明 KV Cache 太大，需要降低上下文长度或者优化 KV Cache 的分配。

我遇到过一次 OOM 是因为临时缓冲没释放。Agent 在工具调用时会加载一个小模型做检索，用完没有及时释放，导致显存泄漏。解决办法是在工具调用结束后显式释放临时显存，或者把工具调用放到单独的进程里，用完就杀掉。

5.3 输出质量下降

输出质量下降通常和上下文长度有关。如果上下文超过 32K 后质量明显下降，可以考虑做上下文压缩。压缩的方法有几种：一种是做摘要，把早期内容用模型总结成短文本；一种是做检索，只把和当前问题相关的内容放进上下文。

我试过检索的方式，效果不错。具体做法是把历史内容存到向量数据库里，每次推理前根据当前问题检索最相关的几条，拼接到上下文里。这样上下文长度可以控制在 8K 以内，输出质量反而比 32K 全量上下文更好。

5.4 响应时间过长

响应时间过长可能是通信延迟、计算延迟或者排队延迟。先看日志里各阶段的耗时，定位瓶颈在哪里。如果是通信延迟，考虑优化网络或者换并行方式。如果是计算延迟，考虑量化或者换更小的模型。如果是排队延迟，说明请求太多，需要加并发或者限流。

我实测下来，流水线并行下通信延迟占总时间的 15% 到 25%，这个比例是可以接受的。如果换成张量并行，通信延迟会更高，但计算延迟会降低，总体时间可能差不多。具体选哪种，要看你的网络条件和延迟要求。

6. 几个容易被忽略的实操细节

第一个细节是日志的同步。两台设备的日志要能对应上，否则排查问题时很痛苦。我的做法是给每个请求分配一个唯一 ID，两台设备的日志里都打印这个 ID，这样就能把两台设备的日志串起来看。这个做法看起来简单，但实际排查时能省很多时间。

第二个细节是模型的热加载。Agent 场景下，模型可能需要频繁切换，比如从对话模型切换到工具调用模型。如果每次都重新加载，延迟会很高。我的做法是常驻一个基础模型，工具调用时用 LoRA 适配器切换，这样不需要重新加载整个模型，切换延迟从几十秒降到几秒。

第三个细节是 KV Cache 的复用。多轮对话中，前面的对话内容的 KV 是可以复用的，不需要每次重新计算。我的做法是把 KV Cache 按对话轮次分块，新的一轮只需要计算新增部分的 KV，前面的直接复用。这个优化能把多轮对话的响应时间降低 30% 到 50%。

提示：KV Cache 复用要注意位置编码的处理。如果直接复用，位置编码可能会错乱，导致输出质量下降。我的做法是在复用的时候重新计算位置编码，虽然多了一点计算量，但输出质量有保证。

第四个细节是异常恢复。Agent 运行过程中可能会遇到各种异常，比如工具调用超时、模型输出格式错误。我的做法是给每个步骤加超时和重试，超时后重试一次，如果还失败就跳过这一步，继续后面的流程。这样即使某一步出问题，整个 Agent 不会完全卡死。

7. 长上下文到底能不能用，我的结论

回到标题的问题：两台 Spark 跑本地 Agent，长上下文到底能不能用？我的实测结论是：32K 以内可以用，但要注意优化；32K 到 64K 之间勉强能用，但输出质量和响应时间都会明显下降；64K 以上基本不可用，显存和延迟都扛不住。

如果你一定要用更长的上下文，有几个方向可以尝试。一是做上下文压缩，把长上下文压缩成短上下文，用检索或者摘要的方式保留关键信息。二是换更高效的注意力机制，比如滑动窗口注意力或者稀疏注意力，降低 KV Cache 的大小。三是加设备，三台或者四台一起跑，把 KV Cache 分散到更多设备上。

我个人在实际操作中的体会是，长上下文不是越长越好，而是要找到质量和成本的平衡点。对于大多数 Agent 场景，8K 到 16K 的上下文已经够用了，再长反而会因为注意力分散导致质量下降。与其追求长上下文，不如把检索和摘要做好，用更短的上下文达到更好的效果。

最后再分享一个小技巧：如果你的 Agent 需要处理长文档，不要一次性把整个文档塞进上下文，而是先做分块，每块单独处理，最后把结果汇总。这样每块的上下文都很短，处理速度快，质量也稳定。汇总的时候再用一个短上下文做整合，整体效果比直接塞长文档好很多。