在配备 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。

标题卡:RTX 3050 8GB、256K 上下文、DDR3、Strata 0.1.55 和 Qwen3.8-Flash-Next IQ3_S
随 256K 上下文帖文发布的配图。已安装 64GB ECC DDR3 内存;系统可见约 62GB。图中显示的是已安装的 64GB。

此前的 16K 配置:真实文本上 59 tok/s

同一天稍早,同一台机器报告了 16K 上下文、8 位 KV 缓存的配置。KV 缓存是模型针对已处理令牌的工作内存。该帖公布的数字:

P3001,Strata 0.1.55,RTX 3050 8GB,16K 配置。上下文 → prefill / decode / TTFT。
上下文PrefillDecodeTTFT
2K132 tok/s24.3 tok/s11.9s
8K121 tok/s28.0 tok/s42.6s
16K128.5 tok/s30.7 tok/s87.5s
热态 8K(来自缓存)来自缓存28.7 tok/s0.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 是等到第一个回答令牌的时间。

256K 配置,长上下文运行。输入令牌 | prefill | TTFT | decode。每行一次运行。
输入令牌PrefillTTFTDecode
7735.9 tok/s3.7s20.1 tok/s
1,561163.5 tok/s9.5s23.1 tok/s
6,161187.6 tok/s32.7s24.6 tok/s
24,061187.6 tok/s128.3s25.7 tok/s
50,061183.4 tok/s273s23.5 tok/s
100,061177.5 tok/s564s23.8 tok/s
160,061172.5 tok/s928s23.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 结果 · 所有新闻