补丁让DeepSeek V4.1本地代理启动快20倍

当Altman说家用DRAM“相当糟糕”时，这位开发者决定用行动回应

Sam Altman 最近关于 DRAM 分配的一段评论在社区里引起了不少讨论。他说：“从全球分配的角度来看，让每个人都把世界上有限的 DRAM 供应放在自己的电脑里，而且可能只用了 5% 的时间，实际上相当糟糕。” 这句话本身是对集中式算力路线的辩护，但 Reddit 上一位开发者把它当成了挑战书。

他的“相当糟糕”家用配置是：RX 9070 XT 16 GB 显卡、5800X3D 处理器、64 GB DDR4 内存（他调侃现在内存比整台电脑还贵），以及一块 PCIe 3.0 NVMe 固态硬盘。这套机器完全离线运行 DeepSeek^广告 V4.1 Flash，支持 1M 上下文，使用 IST-DAS 1.75 bpw 量化，实验室报告称达到完整模型任务平均分的 98.7%。专家权重分布在显存、内存和 SSD 上。生成速度约 7 tok/s，对于本地推理来说可以接受。

真正的问题不在生成，而在提示读取。每次新建 OpenCode 会话，引擎都要重新读取约 37K token 的系统提示和工具定义，首 token 等待时间接近 100 秒。用他的话说，这是“没有数据中心的等待时间，却有着数据中心级别的煎熬”。

两处引擎补丁：KV拼接与常驻路由

KV拼接：不再重复读取已读内容

问题的根源在于代理框架会把每次会话特有的文本塞进系统提示里，比如工作目录、日期、项目的 CLAUDE.md、带随机 ID 的技能路径。这些内容每次都变，导致前缀缓存完全失效。

这位开发者对 DeepSeek 引擎做了修改：新提示会与所有已保存的对话进行对齐，把缓存状态中过时的行切掉（向下移动缓存行、旋转窗口环、记录 RoPE 间隙），只读取变化的行加上用户消息。变化行以整行为单位移动，模型不会看到碎片化的文本。

这个思路接近“KV 缓存手术”，但实现上更务实——不追求形式化证明，而是先让缓存命中率上来。

前缀缓存（Prefix Caching） 是这里的关键背景。在 Transformer 推理中，模型对已处理过的 token 会生成并保存对应的 Key/Value 矩阵（即 KV 缓存），这样当后续请求共享同一段前缀（例如固定的系统提示）时，引擎可以直接复用这些计算结果，跳过重复的 prefill 阶段。前缀缓存能否命中，取决于新请求的 token 序列是否与缓存中某条记录「从头开始逐 token 完全一致」。一旦系统提示里混入了每次都变的内容（工作目录、时间戳、随机 ID），前缀就会在某个位置分叉，后续所有 token 的缓存全部失效，只能从头重新计算——这正是文中 100 秒首 token 等待的直接来源。DeepSeek 等采用 MLA（多头潜在注意力）的模型，KV 缓存结构比标准 MHA 更紧凑，但缓存对齐的要求同样严格。

常驻路由：让内存真正发挥作用

即使提示很短，几乎每一层的每个专家都会被触及，所以提示读取阶段大部分模型都要从 SSD 流式加载——一个 1.2K token 的提示就要加载 58 GB。补丁的做法是：在提示读取阶段，token 只从已经驻留在显存或内存中的专家里选择；生成阶段则恢复正常路由。

效果立竿见影。家用 DRAM 终于被用满，而不是闲置。作者调侃说，这套系统里唯一空闲的部件是他的钱包，拜内存价格所赐。

混合专家（MoE）架构与专家路由 是理解这一段的前提。DeepSeek V4.1 属于 MoE 模型：每一层包含数十到上百个「专家」前馈网络，但每个 token 只被路由到其中少数几个（通常是 top-k）。这意味着一次前向传播实际激活的参数远少于总参数量，但不同 token 激活的专家组合不同。当模型总参数量远超显存容量时，专家权重必须分层存放，推理时按需从内存或 SSD 加载未被激活的专家。问题在于，提示读取阶段要一次性处理上万个 token，这些 token 的组合几乎会覆盖每一层的大部分专家，于是整个模型都得从慢速存储中搬一遍。常驻路由的思路就是在这个阶段限制候选专家集合，只在已驻留的专家中做选择，用一点路由自由度换取避免全量流式加载——本质上是用「近似路由」换取「IO 局部性」。

效果与代价：20倍加速背后的妥协

据作者在 Reddit 帖子中的描述，两处补丁让新代理会话的启动速度提升约 20 倍。这个数字对应的是提示读取时间的缩短，而不是生成速度。对于频繁创建新会话的代理工作流来说，体验改善相当明显。

但作者也坦诚列出了局限：

• 目前只在 HIP（gfx1201）上构建和测试过，CUDA、SYCL 和 Metal 均未验证。
• KV 拼接是近似方法：切点之后的 token 是在包含被移除文本的上下文中计算的。作者表示对短引导行没看出影响，但没有正式评测。
• 常驻路由会轻微改变回答（提示读取时替换专家）。作者的硬编码测试套件没有变化（两种模式都是 12/13），但各只跑了一次。

两个功能在分支中默认开启，可以用 STRATA_DS4_REORDER=0 和 STRATA_DS4_PROMPT_RESIDENT=0 关闭。分支还顺带修复了一个 37K token 提示下遇到的 GPU 页错误（#4912）。

文中提到的 HIP 与 gfx1201 值得稍作说明。HIP 是 AMD 的异构计算编程接口，语法上高度兼容 CUDA，可视为在 AMD GPU 上运行并移植 CUDA 代码的桥梁；gfx1201 则是 AMD RDNA 4 架构（RX 9000 系列）的 GPU 目标代号。作者使用 RX 9070 XT，因此只能基于 HIP 构建和测试，而 CUDA（NVIDIA）、SYCL（Intel）和 Metal（Apple）后端都依赖各自不同的内核实现与内存管理语义，未经编译验证不能假定补丁可移植。这也是作者公开征集 CUDA 测试数据的原因：一个改动要进入上游，通常需要在多个后端上通过一致的数值与性能回归测试，否则合并方无法确认它不会在别的硬件上引入正确性问题。

本地推理的务实路线

这个故事的价值不在于“家用 GPU 打败数据中心”这种口号。作者自己也承认生成速度一般、依赖 SSD 流式加载、补丁有近似性。真正有意思的是它展示了一种分层利用本地硬件的思路：显存放热点专家、内存放次热专家、SSD 兜底，每层都用在刀刃上。

Altman 说家用 DRAM 利用率只有 5% 是浪费，这位开发者用行动给出了另一种回答：当软件愿意把内存当成内存来用，而不是当成显存不够时的备用仓库，所谓的“糟糕分配”也能产生实际价值。按照他的说法，这套配置让内存利用率达到了 100%。

代码在 GitHub 的 PhialsBasement/Strata 仓库的 dsv41-kv-splice 分支上，作者特别欢迎 CUDA 用户提交测试数据，帮助补丁合并到上游。