如果你使用 Open Code 或其他代理程序，但没有并行使用代理，那么你会损失大量的 t/s。基准测试：RTX5090，通过 LM Studio 加载 Qwen3.6 35B，并行任务数设为 8

众所周知，t/s 非常重要，它决定了任务完成的速度。我通过 Open Code 的基准测试来运行并得出结论。多亏了它，我知道如果不运行至少 4 个代理，我基本上会浪费一半的性能。因此，无论你是在 Open Code 中运行单个项目（使用一个代理）还是同时运行 4 个项目，以这种方式运行都比单实例或单代理好得多。我让 AI 对我的测试进行了总结并验证了结果： LM Studio 多代理吞吐量基准测试 硬件：RTX 5090 模型：Qwen 3.6 35B（通过 LM Studio） 配置并行数：8 测试：每个代理 5 个请求，最大 1024 token，温度 0.3 结果 | 代理数 | 平均 t/s（每个） | 总 t/s | 效率 | 实际时间 | |-------|----------------|--------|------|----------| | 1 | 256.54 | 245.77 | — | 21.9秒 | | 2 | 176.15 | 346.22 | 70.4%| 31.1秒 | | 3 | 134.73 | 398.64 | 54.1%| 40.5秒 | | 4 | 109.77 | 434.34 | 44.2%| 49.5秒 | | 5 | 95.04 | 470.34 | 38.3%| 57.1秒 | | 6 | 84.73 | 504.14 | 34.2%| 64.0秒 | | 7 | 74.49 | 517.68 | 30.1%| 72.7秒 | | 8 | 67.22 | 533.90 | 27.2%| 80.5秒 | 关键发现 **吞吐量缩放** - 总吞吐量呈次线性增长：8 个代理的总吞吐量仅为单个代理的 2.2 倍（533 vs 245 t/s），而非 8 倍。 - 单个代理速度急剧下降：从 256 t/s → 67 t/s，因为 GPU 计算被分摊到各个代理。 - 收益递减：从 5 到 8 个代理仅增加约 63 t/s（12%）。大部分收益在 5 个代理之前实现。 **效率** - 效率峰值：2 个代理时 70.4%（最接近理论线性缩放）。 - 到 8 个代理时仅 27.2% 效率——三分之二的潜在吞吐量因开销而损失。 **最佳点：4–5 个代理** - 4 个代理：434 t/s，44% 效率——速度与资源使用的良好平衡。 - 5 个代理：470 t/s，38% 效率——接近峰值总吞吐量，开销可接受。 - 超过 5 个：边际收益（7 个时 517 t/s，8 个时 533 t/s）但显存和开销成本显著增加。 **并发如何与上下文协同工作** - 每个代理拥有自己的完整上下文窗口——它们不会共享。 - 8 个代理 × 8K 上下文 = GPU 显存中的 8 倍 KV cache。 - 瓶颈是 KV cache + 计算分割，而非上下文大小。 | 因素 | 1 个代理 | 8 个代理 | |------------|---------|--------------------| | 模型权重 | 1x | 1x（共享） | | KV cache | 1x | 8x | | GPU 计算 | 100% | 约 12.5% 每个 | | 显存压力 | 低 | 高 | **给 OpenCode 的建议** 将并行代理数设为 4–5。这样可以最大化吞吐量收益，同时避免过度的显存开销或收益递减。超过 5 个代理后，总吞吐量几乎不再增加，而资源消耗却线性增长。