跳到主内容
@wquguru
精选88r/LocalLLaMA（Reddit）技巧与观点

双3090并发8个Agent各持25万上下文，总吞吐600+ tok/s

8 agents × 250K context, concurrently, on two 3090s (~600+ tok/s total)

原文
发到 X
推荐理由

本地部署多 Agent 长上下文的硬核工程实践，给出了完整的稀疏 KV Cache 实现细节与性能数据，值得做本地 RAG 或 Agent 的同学参考落地。

I am open to the idea that I am misguided, but my findings feel worth sharing:

我乐于接受自己可能误解的观点，但我的发现值得分享：

Short video of my UI with 8 agents each explaining a codebase in parallel long prose: https://imgur.com/JSqlXIi

我的 UI 短视频，8 个代理并行解释代码库的长篇内容：https://imgur.com/JSqlXIi

A few days ago I read the Stanford/Berkeley TokenGate paper. The idea is to make long context cheap by pruning tokens up front.

几天前我阅读了斯坦福/伯克利 TokenGate 论文。其核心思想是通过预先剪枝 token 来降低长上下文的成本。

I tried it. It's fine for one question, but agents keep asking new ones, and by then the tokens they need are gone, so code recall drops hard.

我尝试了一下。对于单个问题来说效果尚可，但代理会不断提出新问题，而到那时它们所需的 token 已经消失，导致代码召回率大幅下降。

So I went the other way - don't throw anything away, just don't look at all of it at once. Keep the whole context in system RAM and at each step pull in only the ~1% that matters right now.

所以我走了另一条路——不丢弃任何内容，只是不要一次性查看所有内容。将整个上下文保留在系统 RAM 中，并在每一步仅提取当前相关的约 1% 的内容。

A few days later, I have two 3090s run 8 coding agents at once, each holding their own 250K-token context:

几天后，我用两块 3090 显卡同时运行 8 个编码代理，每个代理维护自己的 25 万 token 上下文：

  • Every decode step, each attention layer reads only ~1% of the tokens, picked with a tiny rank-64 "key sketch".
  • The full KV cache lives in system RAM (int4 in my 80GB RAM VM, but int8 should fit in 128gb). The GPU keeps the sketch and a small hot set.
  • Only the picked tokens cross PCIe.
  • 在每个解码步骤中，每个注意力层仅读取约 1% 的 token，这些 token 通过一个微小的 rank-64 “关键草图”（key sketch）被选中。
  • 完整的 KV 缓存位于系统 RAM 中（在我的 80GB RAM VM 中使用 int4，但 int8 应该能放入 128GB）。GPU 仅保留草图和一小部分热数据。
  • 只有被选中的 token 才会跨越 PCIe 总线传输。

What it took:

实现所需的工作：

  • Triton kernels that build the sketch, score every token, pick the top ~2K and pack them for the stock int8 attention kernel. CUDA-graph safe.
  • vLLM patches that switch dense/sparse per step, so short chats stay full speed.
  • A RAM tier for the KV cache with a prefix cache and recurrent-state checkpoints, so follow-ups don't recompute.
  • Follow-ups fetch only the picked rows.
  • A scheduler fix so one agent reading a huge prompt doesn't freeze the rest.
  • A frozen sketch basis (one file) plus the script to refit it.
  • Triton 内核用于构建草图、对每个 token 进行评分、选取前约 2K 个 token 并为标准的 int8 注意力内核打包。兼容 CUDA-graph。
  • vLLM 补丁用于在每一步切换密集/稀疏模式，从而保持简短对话的全速运行。
  • 为 KV 缓存设置了一个 RAM 层级，包含前缀缓存和递归状态检查点，以便后续问题无需重新计算。
  • 后续问题仅获取被选中的行。
  • 修复调度器，防止一个代理读取巨大提示词时冻结其他代理。
  • 一个固定的草图基座（单个文件）以及用于重新拟合它的脚本。

It's all in the repo as patches, not a fork. Apply them on top of HyperQwen @ ce9615c (a public vLLM fork) and run the install script. Tests and every bench script and result are included.

所有代码均以补丁形式存在于仓库中，而非分叉版本。将它们应用于 HyperQwen @ ce9615c（一个公开的 vLLM 分叉版），然后运行安装脚本。测试、所有基准测试脚本及结果均已包含在内。

Model: dbirks/Qwen3.8-27B-W4A16-AutoRound + HyperQwen's prepare/fetch_fast_variant.py. All numbers were measured with gpu-unlock loaded (a kernel module that roughly doubles 3090 BF16 tensor throughput, mostly faster prompt reading).

模型：dbirks/Qwen3.8-27B-W4A16-AutoRound + HyperQwen 的 prepare/fetch_fast_variant.py。所有数据均在加载 gpu-unlock（一个大致将 3090 BF16 张量吞吐量翻倍的内核模块，主要加速提示词读取）的情况下测得。

Measured (Qwen3.8-27B W4A16, MTP-7, 3090 Ti + 3090 at 250 W):

测量结果（Qwen3.8-27B W4A16，MTP-7，3090 Ti + 3090 在 250W 功耗下）：

  • 8 × 250K: ~545 tok/s total on explain-style output, ~790 on copy-heavy.
  • 8 agents at 176–205K generating nonstop for 6 min: 657 tok/s box average, 69–90 per agent.
  • Recall at 250K: 31/32. Follow-ups start in ~5 s.
  • Single long chats are faster too: +15–41% at ~113K vs dense.
  • 8 × 250K：解释类输出总速度约 545 tok/s，复制密集型输出约 790 tok/s。
  • 8 个代理在 176–205K 范围内连续生成 6 分钟：平均框速 657 tok/s，每个代理 69–90 tok/s。
  • 250K 上下文下的召回率：31/32。后续问题启动时间约 5 秒。
  • 单次长对话也更快：在约 113K 上下文长度下，比密集模式快 15–41%。

Caveat: attention is approximate, so near-duplicate code lines occasionally get mixed up.

注意：注意力机制是近似的，因此偶尔会将高度相似的代码行混淆。

Code:

代码：

  • Serving (patches + kernels): https://github.com/bradj00/sparsekv-hyperqwen
  • 服务（补丁 + 内核）：https://github.com/bradj00/sparsekv-hyperqwen

Rig:

配置：

  • i9-12900K
  • Z790 motherboard
  • 96 GB DDR5 RAM
  • 3090 Ti + 3090, power capped at 250 W
  • i9-12900K
  • Z790 主板
  • 96 GB DDR5 内存
  • 3090 Ti + 3090，功耗限制为 250 W

更进一步：量化金融体系

看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力

进入量化体系 →
话题#vLLM#Local LLM#工程优化#稀疏注意力

相似阅读

关联信息，但可能不是同一事件