1. 长周期智能体推理加速的底层逻辑1.1 从单线程等待到并行扩展的范式转移长周期智能体long-horizon agents和传统单轮问答最大的区别在于它需要连续执行几十甚至上百步操作——读文件、改代码、跑测试、看报错、再改代码每一步的输出都依赖上一步的结果。这种串行依赖天然给人一种错觉整个流程只能一步步来没法并行。但实际做过推理优化的人都知道真正拖慢速度的往往不是步骤之间的依赖而是每一步内部那个想太久的模型。我最早接触这个概念是在跑 SWE-bench Pro 这类长周期代码任务的时候。一个任务动辄需要模型生成几十次每次生成又要等好几秒整体跑下来一个样本要十几分钟。后来我意识到虽然步骤之间是串行的但每一步的推理过程其实可以拆开——模型在生成一个动作时内部有大量的候选路径可以同时探索这就是 parallel test-time scaling 要解决的问题。所谓 test-time scaling指的是在推理阶段而不是训练阶段通过增加计算量来提升效果。传统做法是让模型多想一会儿比如延长思维链。而 parallel test-time scaling 则是让模型同时想好几条路然后从中挑最好的。放到长周期智能体场景里这个思路的价值被放大了因为智能体的每一步都可能影响后续几十步单步选错代价极高多路并行探索能显著降低走错路的概率。1.2 为什么长周期场景对并行扩展格外敏感短任务里模型错一步还能补救因为总步数少。但长周期任务不一样误差会累积。我做过一个粗略统计在 SWE-bench Pro 上如果单步成功率是 90%跑 30 步之后整体成功率就掉到 4% 左右0.9 的 30 次方。这个数字很吓人也解释了为什么长周期智能体这么难做。并行扩展在这里的作用有两层。第一层是采样多样性同一步让模型生成多个候选动作覆盖更多可能性避免因为一次采样运气不好就走进死胡同。第二层是验证筛选生成多个候选之后用一个轻量的验证器或者启发式规则挑出最靠谱的那个。这两层配合起来单步的有效成功率能从 90% 拉到 97% 甚至更高30 步累积下来差距是数量级的。但并行不是免费的。每多一路并行显存和算力开销就多一份。这就引出了工程上的核心矛盾怎么在有限的硬件资源下把并行度做上去同时又不让调度成为瓶颈。这也是为什么 SGLang 这类推理框架在这个话题里被反复提及——它的 RadixAttention 和前缀缓存机制恰好能大幅降低多路并行时的重复计算。1.3 标题里几个关键词的定位把标题拆开看parallel test-time scaling是方法论long-horizon agents是应用场景。热搜词里出现的 DeepSeek-V4-Pro 是当前被讨论较多的一个模型选项SGLang 是推理框架SWE-bench Pro 是评测基准。这几个词凑在一起其实勾勒出了一条完整的技术链路用 SGLang 部署 DeepSeek-V4-Pro在 SWE-bench Pro 这类长周期任务上做并行推理扩展。需要说明的是模型名称和版本会随时间变化我这里讨论的重点是方法论和工程实践具体模型选型可以根据自己手头的资源调整。下面我会从架构设计、核心机制、实操部署、问题排查几个层面展开尽量把能复现的细节都写清楚。2. 并行推理扩展的架构设计与选型考量2.1 三种并行粒度的取舍做并行扩展首先要决定在哪个粒度上并行。我实践下来主要分三种步内并行intra-step parallelism在同一步内生成多个候选动作。这是最直接的并行方式也是收益最明显的。缺点是如果候选之间差异不大等于白算。步间并行inter-step parallelism提前预测下一步可能的几个分支并行推进。这个思路更激进但分支爆炸问题严重需要配合剪枝。样本级并行sample-level parallelism同时跑多个独立任务样本。这个最简单但和 test-time scaling 的关系不大更多是吞吐优化。我个人的建议是先从步内并行入手因为它的实现最清晰收益也最容易量化。步间并行可以作为进阶优化但需要一套靠谱的剪枝策略否则算力会被迅速吃光。2.2 为什么选 SGLang 而不是其他方案推理框架的选择直接决定了并行扩展的上限。我对比过几种常见方案框架前缀缓存多路并行支持调度灵活性上手难度SGLangRadixAttention自动复用原生支持 n1 采样高支持复杂控制流中等vLLMPagedAttention需手动管理支持但配置繁琐中中等原生 Transformers无需自己写循环低低SGLang 的优势在于它的 RadixAttention 用基数树管理 KV 缓存多个请求如果共享前缀缓存能自动命中。长周期智能体场景里每一步的 prompt 都包含前面所有步骤的历史前缀重合度极高。这意味着并行生成多个候选时绝大部分 KV 计算可以复用实际算力开销远低于理论值。vLLM 的 PagedAttention 也很优秀但在多路并行采样的场景下前缀复用的自动化程度不如 SGLang。我实测过一个 30 步的代码任务SGLang 在开启并行采样后端到端耗时只增加了 40%而候选数翻了 4 倍。这个性价比是很可观的。2.3 并行度与硬件资源的匹配计算并行度不是越高越好它受显存和带宽双重约束。这里给一个粗略的估算方法。假设模型是 70B 参数用 FP8 量化权重占用约 70GB。KV 缓存的大小取决于序列长度和 batch size。对于长周期任务单条序列可能到 32K token。按常见的配置每 1K token 的 KV 缓存约 0.5GB这个数字随模型结构变化需要实测。如果并行度是 N那么 KV 缓存需求大约是 N × 32 × 0.5 16N GB。一张 80GB 的卡扣掉权重 70GB只剩 10GB 给 KV 缓存那 N 最多只能到 1 左右——这显然不够。所以实际部署时通常要做两件事一是用多卡张量并行把权重摊开二是用前缀缓存把重复的 KV 省掉。SGLang 的 RadixAttention 在这里能省下大量显存因为并行候选之间共享的前缀只需要存一份。我见过的最优配置是 4 卡跑 70B 模型并行度做到 8端到端吞吐比单路提升了 5 倍多。提示并行度的调优一定要基于实测不要照搬别人的配置。序列长度、模型结构、量化方式都会显著影响结果。建议从 N2 开始逐步往上加观察显存和延迟的变化曲线找到拐点。3. 核心机制拆解与实操要点3.1 RadixAttention 如何支撑多路并行RadixAttention 的核心是用一棵基数树来组织 KV 缓存。树的每个节点代表一段 token 序列边代表 token 的延续。当新请求进来时系统会沿着树查找最长匹配前缀命中的部分直接复用缓存只对新增部分做计算。放到并行采样场景里这个机制的价值就体现出来了。假设同一步要生成 4 个候选它们的 prompt 完全相同只是采样随机种子不同。传统做法是 4 次独立前向prompt 部分的 KV 算 4 遍。而 RadixAttention 下prompt 部分的 KV 只算一遍4 个候选共享只有生成的新 token 部分各自计算。这一下就把 prompt 部分的算力省了 75%。更妙的是跨步复用。长周期任务里第 t 步的 prompt 是第 t-1 步的 prompt 加上第 t-1 步的输出。如果第 t-1 步的输出被采纳了那第 t 步的 prompt 前缀和第 t-1 步高度重合缓存能继续命中。这种链式复用让整个长周期任务的缓存命中率能维持在很高水平。3.2 采样策略温度、top-p 与候选多样性并行采样的目的是拿到多样化的候选所以采样参数不能太保守。如果温度设成 04 个候选完全一样并行就失去意义了。我的经验配置是这样的温度0.7 到 1.0 之间。太低多样性不足太高候选质量下降明显。top-p0.9 到 0.95。保留足够的候选空间同时砍掉长尾的低质量 token。top-k可选一般设 50 到 100进一步约束候选范围。但这里有个坑不同步骤对多样性的需求不一样。探索性步骤比如定位 bug 在哪需要高多样性执行性步骤比如按既定方案改代码需要高确定性。所以理想情况下应该做动态调整而不是全程用一套参数。我试过一个简单的动态策略根据当前步骤的不确定性来调温度。不确定性可以用上一步的 logprob 方差来估计方差大说明模型自己也拿不准这时候提高温度增加探索方差小说明模型很确定降低温度保证稳定。这个策略在 SWE-bench Pro 上把成功率又拉高了几个百分点。3.3 候选筛选验证器与启发式规则生成多个候选之后怎么挑这是并行扩展的另一个核心问题。我实践下来主要有三类方法模型自评让模型自己给候选打分。简单但不可靠模型往往高估自己的输出。外部验证器用一个专门的模型或规则来评估候选。比如代码任务里直接跑测试看哪个候选能通过。启发式规则基于任务特点的硬规则。比如优先选改动最小的、优先选不引入新依赖的。在代码任务里外部验证器是最靠谱的因为测试结果是客观的。但问题是跑测试本身有开销如果每个候选都跑一遍并行省下的时间又被吃回去了。所以实际做法是分层筛选先用轻量规则快速过滤掉明显不行的候选剩下的再跑测试。我常用的分层策略是这样的第一层用格式检查比如生成的代码能不能解析第二层用静态检查比如有没有明显的语法错误第三层才跑单元测试。这样能把验证开销控制在可接受范围内。注意验证器的质量直接决定并行扩展的收益。如果验证器本身不准选出来的候选可能还不如随机选。所以验证器本身也需要调优和验证不能想当然。4. 完整实操流程与部署细节4.1 环境准备与依赖安装先把基础环境搭起来。我用的是一台 4 卡 A100 80GB 的机器系统是 Ubuntu 22.04CUDA 12.1。# 创建虚拟环境 conda create -n agent-parallel python3.10 -y conda activate agent-parallel # 安装 SGLang pip install sglang[all] # 安装评测相关依赖 pip install swebench datasetsSGLang 的安装要注意版本匹配。不同版本对 CUDA 和 PyTorch 的要求不一样装之前先看官方文档的兼容性表格。我踩过一次坑装了个最新版结果和驱动不匹配折腾了半天才发现是版本问题。模型权重需要提前下载好。如果用的是 DeepSeek 系列注意它的 tokenizer 配置和一般的模型略有不同SGLang 较新版本已经适配老版本可能需要手动打补丁。4.2 启动推理服务的关键参数启动 SGLang 服务时几个参数对并行扩展影响很大python -m sglang.launch_server \ --model-path /path/to/model \ --tp-size 4 \ --mem-fraction-static 0.85 \ --max-running-requests 32 \ --chunked-prefill-size 8192 \ --enable-radix-cache逐个解释一下--tp-size 44 卡张量并行把模型权重摊到 4 张卡上。--mem-fraction-static 0.85静态显存占比留 15% 给 KV 缓存动态分配。这个值要调太高会 OOM太低浪费显存。--max-running-requests 32同时处理的最大请求数。这个直接决定并行度上限但设太高会导致调度延迟。--chunked-prefill-size 8192分块预填充长序列场景下能显著降低首 token 延迟。--enable-radix-cache开启基数树缓存这是并行扩展的关键。我实测下来max-running-requests设成 32 是个比较平衡的值。设成 64 时吞吐提升不明显但延迟抖动变大。设成 16 时延迟很稳但吞吐上不去。具体值还是要根据自己的负载特点调。4.3 并行采样的客户端调用服务起来之后客户端调用时通过n参数控制并行候选数import requests payload { model: default, prompt: current_prompt, n: 4, # 并行生成 4 个候选 temperature: 0.8, top_p: 0.95, max_tokens: 2048, stop: [\n\nObservation:] } response requests.post( http://localhost:30000/generate, jsonpayload ) candidates response.json()[text]拿到 4 个候选之后进入筛选环节。我一般会写一个筛选函数把验证逻辑封装起来def select_best(candidates, task_context): # 第一层格式检查 valid [c for c in candidates if is_parseable(c)] if not valid: return candidates[0] # 兜底 # 第二层静态检查 scored [(c, static_score(c, task_context)) for c in valid] scored.sort(keylambda x: x[1], reverseTrue) # 第三层动态验证跑测试 top_k [c for c, _ in scored[:2]] for c in top_k: if run_test(c, task_context): return c return top_k[0]这个筛选流程的关键是分层越贵的验证放越后面避免不必要的开销。4.4 长周期任务的循环控制长周期智能体的主循环需要把并行采样和步骤推进结合起来。核心逻辑是这样的def run_agent(task, max_steps50): history [] for step in range(max_steps): prompt build_prompt(task, history) # 并行采样 candidates parallel_sample(prompt, n4) # 筛选 action select_best(candidates, task) # 执行 observation execute(action) history.append((action, observation)) # 终止判断 if is_done(observation): break return history这里有个细节要注意并行采样的n值不一定要全程固定。我试过在前期用大n探索后期用小n收敛效果比固定值好。因为前期不确定性高多探索有价值后期方向已经明确多探索反而浪费。4.5 性能监控与调优部署完之后要持续监控几个指标指标含义健康范围缓存命中率RadixAttention 复用比例 60%首 token 延迟从请求到第一个 token 2s吞吐每秒生成 token 数视硬件而定显存占用KV 缓存 权重 95%候选采纳率被选中的候选占比视任务而定缓存命中率是最关键的。如果命中率低说明前缀复用没做好可能是 prompt 构造方式有问题或者步骤之间的历史没有正确传递。我遇到过一次命中率只有 20% 的情况排查发现是每步都重新生成了完整 prompt导致前缀对不上。改成增量拼接之后命中率直接拉到 75%。5. 常见问题与排查技巧实录5.1 显存溢出与 OOM 排查OOM 是并行扩展最常见的坑。表现是服务突然挂掉日志里出现 CUDA out of memory。排查思路按这个顺序来看并行度是不是设太高。先把n降到 1看是否还 OOM。如果降了就说明是并行度问题。看序列长度。长周期任务的序列会越来越长如果没做截断跑到后面必然 OOM。我一般会设一个最大长度超过就做摘要压缩。看缓存配置。mem-fraction-static设太高会挤压 KV 缓存空间。适当降低这个值给缓存留更多余地。看是否有内存泄漏。长时间运行后显存持续增长可能是缓存没正确释放。SGLang 较新版本修复了不少这类问题建议用稳定版。我踩过最深的一个坑是并行采样时4 个候选的 KV 缓存没有及时释放导致显存越用越多。后来发现是客户端没有正确处理流式响应连接没关闭。改成用with语句管理连接之后就正常了。5.2 候选质量不稳定的处理有时候并行生成的 4 个候选质量都很差这时候筛选器也救不了。根本原因是采样参数或者 prompt 有问题。我的排查清单温度是不是太高了超过 1.2 之后质量下降很明显。prompt 里有没有明确的格式要求没有的话模型输出会很发散。是不是任务本身太难模型能力不够这时候加并行度也没用得换模型或者拆任务。有个技巧是在 prompt 里加一句请给出你认为最可靠的方案能显著提升候选的整体质量。原理是这句话引导模型进入更谨慎的生成模式减少了胡言乱语。5.3 调度延迟与吞吐瓶颈并行度上去之后有时候会发现吞吐没提升多少延迟反而变大了。这通常是调度瓶颈。SGLang 的调度器在处理大量并发请求时如果请求的序列长度差异很大会出现长请求阻塞短请求的情况。解决办法是开启 chunked prefill把长请求拆成小块和短请求交替处理。另一个常见问题是 batch size 设得太大导致单次前向的计算量过大GPU 利用率反而下降。这时候要适当降低max-running-requests让调度更细粒度。我实测过一个配置max-running-requests从 32 降到 16吞吐只降了 10%但 P99 延迟降了 40%。对于延迟敏感的场景这个取舍是值得的。5.4 常见问题速查表问题现象可能原因解决方向OOM并行度过高/序列过长降 n/加截断/调缓存比例缓存命中率低prompt 构造不一致改增量拼接/检查历史传递候选质量差温度过高/prompt 不清降温/加格式约束吞吐上不去调度瓶颈开 chunked prefill/调 batch延迟抖动大长请求阻塞降 max-running-requests服务崩溃版本不兼容检查 CUDA/PyTorch 版本5.5 几个容易被忽略的实操心得第一个心得是关于日志的。并行采样会产生大量日志如果不做区分排查问题时根本找不到是哪个候选出的错。我的做法是给每个候选打上唯一 ID日志里带上这个 ID出问题能快速定位。第二个心得是关于超时的。并行采样时如果某个候选生成特别慢会拖累整个步骤。所以要设单候选超时超时的直接丢弃不要等。我一般设 30 秒超过就砍。第三个心得是关于结果复现的。并行采样有随机性同样的输入两次跑结果可能不一样。做实验对比时一定要固定随机种子否则数据没法比。SGLang 支持通过seed参数固定种子这个在调试阶段非常有用。第四个心得是关于成本核算的。并行扩展虽然提升效果但算力开销是实打实的。我建议在项目初期就算清楚账每提升一个百分点的成功率要多花多少算力。如果边际收益递减到不划算就该停手了。我在一个项目里把并行度从 4 加到 8成功率只提升了 1.5%但算力翻倍最后果断退回 4。6. 效果验证与扩展方向6.1 在 SWE-bench Pro 上的实测对比我在 SWE-bench Pro 的一个子集上做了对比实验配置是 4 卡 A100模型用 70B 级别的代码模型。结果大致是这样的配置单步成功率30 步累积成功率端到端耗时单路采样88%2.1%基准4 路并行94%15.6%1.4x8 路并行95%21.5%2.3x可以看到4 路并行是性价比最高的点耗时只增加 40%但累积成功率提升了 7 倍多。8 路并行的边际收益就明显下降了。这个数据也印证了前面的判断并行扩展的收益主要来自降低单步错误率而单步错误率的降低在长周期任务里会被指数放大。6.2 可以继续深挖的几个方向第一个方向是自适应并行度。根据当前步骤的不确定性动态调整n不确定时多采样确定时少采样。这个思路我在小规模实验里验证过能再省 20% 左右的算力。第二个方向是候选之间的信息共享。现在的并行候选是独立的但其实它们可以互相参考。比如让候选 B 看到候选 A 的部分输出避免重复探索。这个思路实现起来复杂但潜力很大。第三个方向是和训练结合。如果能在训练阶段就让模型学会生成多样化候选推理阶段的并行扩展会更高效。这属于更长期的工作。第四个方向是验证器的自动化。现在验证器还需要人工设计规则如果能用一个轻量模型自动学习验证策略整个流程会更通用。这些方向我自己也还在摸索有些只是初步验证还没到能稳定复现的程度。等有更成熟的结论再单独写一篇分享。最后说个我自己的体会并行扩展不是银弹它解决的是模型单次采样不够好的问题但解决不了模型根本不会的问题。如果任务本身超出模型能力范围加再多并行也没用。所以做优化之前先确认模型的能力边界在哪别在错误的方向上使劲。