你同时交给四个 AI 助手四项编程任务：一个改接口，一个补测试，一个查报错，一个整理代码。显卡明明很忙，助手却常常排队等它“开口”。问题不一定是模型算得慢，而是四个任务反复搬运同一套模型权重，像四位厨师轮流去仓库取同一批食材。OpenJet 想做的，就是让他们共用一次搬运。
开发者在 Reddit 发帖称，新版 OpenJet 可以在单张 RTX 3090 上并发运行四个 coding agents——能读取代码、调用工具并连续完成任务的软件助手。它使用 Qwen3.8-27B Q4_K_M；其中 Q4_K_M 指一种压缩权重的量化配置，但帖子没有交代这个模型名称的正式来源与许可。本文所有性能数字也都来自这位开发者的单篇帖子，尚无论文、代码仓库、复现实验或第三方测试印证。
从一个会话，走到四个 Agent
我们在 10 月 12 日报道过 OpenJet 的单会话实验：它为 Qwen3.8-27B 和 RTX 3090 定制 CUDA Megakernel，也就是把许多原本分散的 GPU 运算塞进一个大型 CUDA 内核，减少反复启动计算和搬运中间数据的开销。当时一次只服务一个会话，这次则扩展到四路并发推理——让多个请求共享同一套计算资源，交错获得模型输出。
据开发者给出的短提示词测试，OpenJet 同时运行四个 Agent 时，每个 Agent 的解码速度为 64–72 tok/s。token 是模型处理文字的基本单位；tok/s 表示每秒生成多少 token。四路合计为 256–288 tok/s。作为对照，llama-server 使用 --parallel 4 时，每路为 18–20 tok/s，总计 72–80 tok/s。由此算来，OpenJet 的总吞吐约高 3–4 倍。
标题把上限写成“约 290 tok/s”，与正文的 288 接近，但并不完全相同，更适合看作取整后的宣传表达，而不是一个独立测得的精确结果。它也不意味着四个 Agent 各自都能跑到 117 tok/s：117 tok/s 是帖子报告的单 Agent 速度，四路并发时每路是 64–72 tok/s。
妙处是只搬一次权重
开发者对瓶颈的解释很直白。模型的量化权重占用 16.7 GB。按 RTX 3090 标称的 936 GB/s 显存带宽估算，每生成一步，完整读取一次权重理论上约需 18 毫秒。这里的关键不是算术多复杂，而是要不断把这批庞大的权重从显存送进计算单元。
OpenJet 没让四个 Agent 依次读取四遍。每一步，它把所有活跃 Agent 的工作叠成一个批次：每个 Agent 放入下一个 token，再加两个 MTP／prompt-lookup draft token——可以理解为模型顺手提出的两个候选续写。四个 Agent 合计形成 12 行。随后，一个持续运行的 CUDA 巨核只把权重流过一次，让刚读入的每个权重同时参与这 12 行计算，并在同一轮里验证候选 token。
这像是仓库一次把食材送到公共操作台，四位厨师当场各取所需，而不是每人单独跑一趟。按开发者的说法，四路 Agent 每一步大致只付出一次权重读取成本，而非四次。不过并发并非免费：每个 Agent 都要读取自己的 KV Cache——模型保存上下文中间结果的“草稿纸”；注意力计算和额外行的运算也会随 Agent 数量增加。
真正重要的是少互相堵车
编码 Agent 不会一直连续写字。它会生成一段内容，暂停去调用工具、运行测试，再带着新结果发起下一次请求。因此，除了总吞吐，首 token 延迟也很关键：它指请求提交后，模型多久才吐出第一个 token，直接决定 Agent 每次重新行动时要等多久。
在帖子给出的测试中，当四个 Agent 各自带有 23K context——约 2.3 万 token 的上下文——OpenJet 每路仍有 52–55 tok/s，llama-server 为 15–16 tok/s。更显眼的是下一次请求的首 token 延迟：OpenJet 为 0.2–0.5 秒，对照为 13.4 秒。
开发者还测试了一个更容易“堵车”的场景：一个 Agent 正在解码，另一个同时处理 20K prompt，也就是约 2 万 token 的新输入。此时 OpenJet 的解码速度为 9.5 tok/s，对照为 0.6 tok/s。其声称的设计目标是，新 prompt 不会让其他 Agent 全部停下来。
在会暂停运行工具和测试的四个“真实 coding agents”上，帖子报告的总吞吐为 150–200 tok/s，低于连续解码测试的 256–288 tok/s。这很正常地反映了工作流中的停顿，但材料没有提供任务集、完成率或代码质量，因此不能把吞吐更高直接等同于 Agent 做得更好。
为什么值得关注
RTX 3090 在 2020 年上市时被 NVIDIA 称作“BFGPU”，官方解释为“big ferocious GPU”，并以 8K 游戏作为卖点。据 NVIDIA 与 PCWorld，当时它售价 1499 美元，拥有 24GB 显存；游戏评测中，它在 4K 下通常只比便宜许多的 RTX 3080 快约一成。六年后，真正让这张旧消费卡获得新用途的，恰恰是当年显得奢侈的显存容量。
OpenJet 展示的方向因此比单项跑分更有意思：本地 Agent 团队的瓶颈，不只是“一个模型最快能写多快”，而是多个任务能否共享一次昂贵的数据搬运，并且不因其中一个读入长提示词而集体等待。如果这些数字能够复现，一张消费级显卡就可能从单人对话机变成小型 Agent 工作站。
局限与未知
- 全部结果均来自 OpenJet 开发者本人发布的一篇 Reddit 帖子，测试配置、采样参数、上下文组成、候选 token 接受率、llama-server 版本及优化选项都未充分披露，不能据此推出普遍的 3–4 倍优势。
- 约 18 毫秒来自 的理论估算；936 GB/s 是峰值带宽，不是实测读取耗时。“四个 Agent 约只需一次权重读取”和“新 prompt 不阻塞其他 Agent”也都是作者的架构描述。
- 材料只报告速度，没有报告任务成功率、代码质量或资源稳定性。它说明了一个值得验证的吞吐方案，还没有证明四个 Agent 能把工作做得更好。