在配备 DDR3 的工作站上,RTX 3050 8GB 实现 256K 上下文
一台二手至强工作站配备已安装的 64GB ECC DDR3 内存(系统可见约 62GB)和一块 RTX 3050 8GB,被配置为 256K 令牌的上下文窗口。详细测量达到 160K 令牌,而非完整的 256K。此前的 16K 配置在真实文本上给出 59 tok/s。
2026 年 11 月 11 日公布了工作站 P3001 的结果:英特尔至强 E5-2697 v2(12 核 / 24 线程,仅支持 AVX1)、已安装 64GB ECC DDR3 内存(系统可见约 62GB,1333 MT/s)、英伟达 RTX 3050 8GB、NVMe 固态硬盘和 Ubuntu 24.04。软件为 Strata 0.1.55(兼容 AVX 的构建)以及压缩模型 Qwen3.8-Flash-Next IQ3_S。

此前的 16K 配置:真实文本上 59 tok/s
同一天稍早,同一台机器报告了 16K 上下文、8 位 KV 缓存的配置。KV 缓存是模型针对已处理令牌的工作内存。该帖公布的数字:
| 上下文 | Prefill | Decode | TTFT |
|---|---|---|---|
| 2K | 132 tok/s | 24.3 tok/s | 11.9s |
| 8K | 121 tok/s | 28.0 tok/s | 42.6s |
| 16K | 128.5 tok/s | 30.7 tok/s | 87.5s |
| 热态 8K(来自缓存) | 来自缓存 | 28.7 tok/s | 0.2–0.33s |
同一帖文给出真实文本解码 59 tok/s,以及 120–132 tok/s 的 prefill。后续帖文说明,这 59 tok/s 来自推测解码:Strata 会预先预测若干后续令牌并一并校验。在真实文本上,预测接受率较高;在人工基准填充上则不然(根据 16K 帖文,合成填充的接受率约为 70%)。Prefill 受 DDR3-1333 和 AVX1 限制;在该 16K 配置中,8GB 显存将上下文限制在 16K。
256K 配置
声明的目标是 256K 令牌的上下文窗口——单次请求约可容纳 262,144 个令牌。第一次尝试只是将上限提高到 256K,并使用 8 位 KV 缓存。据该帖,Strata 当时试图在 GPU 的 8GB 显存中保留过多工作内存,GPU 上的专家缓存降至零槽位,随后出现 cuBLAS 错误。服务器仍能响应,但 GPU 加速未能正确工作。
公布的解决方案:将 KV 缓存从 int8 改为 q4_0(4 位压缩),每令牌内存从约 71KB 降至 29.5KB;设置 –kv-resident 20480,使仅 20,480 个 KV 位置常驻 GPU 内存,其余 KV 数据从系统内存读取;将 46.47GB 的模型专家保留在页锁定(page-locked)的 DDR3 内存中;在 GPU 内存中保留 498 个专家缓存槽;并将提示缓存限制为一个活动检查点。给出的最终设置:–max-context 262144,–kv q4_0,–kv-resident 20480,–prompt-cache 1,–prompt-cache-every 0。该帖称,此后 Strata 正常启动,并报告 max_context: 262144,loaded: true。
测得的速度
以下数字是推理引擎本身的测量,每行一次运行——属于初步数据,而非重复基准测试的平均值。Prefill 是作答前对输入的处理;decode 是逐令牌生成;TTFT 是等到第一个回答令牌的时间。
| 输入令牌 | Prefill | TTFT | Decode |
|---|---|---|---|
| 77 | 35.9 tok/s | 3.7s | 20.1 tok/s |
| 1,561 | 163.5 tok/s | 9.5s | 23.1 tok/s |
| 6,161 | 187.6 tok/s | 32.7s | 24.6 tok/s |
| 24,061 | 187.6 tok/s | 128.3s | 25.7 tok/s |
| 50,061 | 183.4 tok/s | 273s | 23.5 tok/s |
| 100,061 | 177.5 tok/s | 564s | 23.8 tok/s |
| 160,061 | 172.5 tok/s | 928s | 23.8 tok/s |
该帖指出,将输入从约 6K 增至 160K 令牌时,prefill 仅从 188 降至 173 tok/s,而 decode 仍保持在约 23–26 tok/s。一次带缓存上下文的 24K 令牌重复运行,将 TTFT 从 128.3 秒降至 0.49 秒。一次冷启动的 160K 令牌输入到第一个回答令牌约需 15.5 分钟——归因于老旧至强和 DDR3 内存的瓶颈。文中提到一次 200K 令牌运行的代理报告,但该次运行的完整数字行未列入表格。
帖文中的一个重要区分:256K 是已配置并声明的上下文上限。详细测量达到 160K,而非完整的 256K。在发帖时,完整的 262K 窗口尚未测量。一条回复估计完整 262K 的冷启动 prefill 约需 26 分钟,并说明这仍有待测量。59 tok/s 并未在 256K 上下文负载上得到确认。新配置的 prefill 高于此前的 16K 配置;帖文将其视为配置之间观察到的差异,而不是单一原因的证据,因为 KV 格式和内存布局也发生了变化。
限制与能耗估算
帖文列出的限制:GPU 内存几乎占满,8GB 中约使用 7.5–7.7GB,部分运行警告仅剩 193–331MB 空闲;系统内存约使用 62GB 中的 53GB,其中约 46.5GB 被锁定在内存中的模型专家占用;提示缓存仅有一个热检查点,因此在超大对话之间切换可能需要重新处理输入(仅一个 200K 令牌检查点就可能占用约 4.7GB);以及冷启动的长提示较慢。
对 160K prefill 的粗略能耗估算为 300 瓦 × 15.5 分钟 ≈ 0.078 千瓦时。按 0.25 欧元/千瓦时计算,电费约为 0.02 欧元。该帖将其标为估算,而非能耗测量。
帖文的实际结论是:低成本的本地人工智能并非为了在漫长、要求高的会话上与云端模型竞争——在那些场景中,云服务往往更快、更经济。这些老旧廉价计算机的主要优势是隐私:在本地处理敏感文件。对许多此类任务,较小的上下文窗口已经足够。已公布的结果是:一块 RTX 3050 8GB 可以运行配置为 256K 的本地模型,而无需将全部工作内存移入显存。仍需进一步测量,包括完整上下文范围、可重复性以及任务上的质量。
测量结果和日志发布在公开仓库中。
GitHub 上的项目仓库 · X 上的帖子 · 16K 结果 · 所有新闻