抡锤者

最近看论坛里不少人在折腾 Agent、记忆和 Skills，但围绕递归自我改进（Recursive Self-Improvement，RSI）的讨论，我暂时看到得不多。想开个帖子抛砖引玉。

先交代一下背景：我自己是在对冲基金做 applied AI，最近也刚开始做递归自我改进系统这方面的工作。不是学术研究出身，更关心这些想法怎么变成能实际运行、能评估、出了问题能回退的系统。

这段时间整理了一些论文和 Harness 的实现，越看越觉得，“让 Agent 改进自己”这句话里其实装了好几个不同的问题。下面是我目前的理解，不是成熟结论。如果有做这方面研究的 PhD、研究员，或者已经在实际项目里尝试的朋友，很欢迎纠正和讨论。

1. Agent 改好了这道题，和 Agent 自己变好了，是一回事吗？

举个很普通的例子：让一个 Agent 写分析脚本，运行，发现报错，再修改，最后通过测试。

这当然有用，但下次换一个任务，它可能还是会犯同样的错误。被改好的是这份脚本，不一定是写脚本的 Agent。

再往前一步：它把失败原因整理成一个 Skill，下一次遇到类似任务时拿出来用。这个变化保留到了任务之外，开始有了积累的可能。但“多存了一条经验”也不等于“能力真的提高了”：可能根本检索不到，也可能把某个任务的偶然经验当成通用规则。

我更感兴趣的是再往前一步：系统能不能改进自己发现问题、提出改法、验证改法的能力？

比如，原本只会随机试 Prompt，后来能从失败记录里找出反复出现的工具使用问题，提出一个小改动，并用新的任务验证。这和在一道题上多反思几轮，就不是同一件事了。

不过 RSI 目前也没有一个大家都同意的门槛。我倾向于先问清楚：改了什么，保留到什么时候，凭什么说更好了？而不是先争论哪个项目配不配叫 RSI。

2. 为什么我会把注意力放在 Harness 上？

光有一个模型，还不够让 Agent 持续做事。谁负责调用工具、保存结果、整理 Context、恢复中断、决定什么时候停、什么时候必须问人？这些围绕模型运行的机制，我这里统称为 Harness。

所以即使模型权重不变，Agent 系统仍然有不少可以改进的地方：

• 工具描述是否让模型容易选对工具；
• 一类重复任务能不能提炼成可复用的 Skill；
• Context 压缩后，有没有丢掉关键约束和失败证据；
• 什么情况应该重试，什么情况应该停下来；
• 长任务如何拆分，子任务之间怎么交接。

这也是我觉得这个方向适合从工程侧切入的原因。不一定一开始就训练模型，也不一定要让 Agent 随意改自己的全部代码。可以先选一个很小的可修改范围，看看反馈能不能稳定地变成下一次的收益。

但反过来说，Harness 可修改，不代表它已经具备自我改进能力。 有 Plugin 接口、有 Memory、有循环，都只是条件；还需要知道什么时候改、怎么选、怎么证明没有改坏。

3. 字节和阿里的两份整合，帮我把问题拆得更清楚了

除了单篇论文，最近还有两份值得一起看的整合。它们的侧重点不一样，我觉得放在一起比较有帮助。

ByteDance Seed 和 TokenWave 的 Self-Developing Agents，把问题拆成了三件事：

• Aspire：该改进什么？ 给一个宽泛目标，比如“提高数学推理能力”，Agent 能不能自己把目标变成可执行的学习计划，并在看不到的最终评估上获得收益？
• S³Gym：经验真的有用吗？ 把探索、判断结果和改进分开，考察历史记录、总结记忆和参数更新等路径，观察经验能否帮助后续决策，而不是只看它能不能写一篇漂亮的反思。这里参数训练与 Context 方法不是一套完全匹配的对照实验，不能直接混成一个排名。
• HarnessDev：改进能留下来吗？ 让模型构建、再演化一个能运行的 Harness，检查新任务上的表现，以及固定执行模型之后，改 Harness 这件事是否仍然有效。

这个项目页里很值得注意的一点，是它不只展示成功：完成了一次更新，不代表超过原始基线；代码里写了 Memory 或状态保存，也不代表实际执行时触发了。对我这种工程侧的人来说，这个提醒很直接：我们究竟是在评估系统的设计，还是它运行时真正发生的事？

阿里巴巴团队的 The Path to Recursive Self-Improving Agents，则更像一张全景地图。它把系统放在五个相互影响的部分里看：模型、Harness、数据系统、训练器，以及负责“诊断 → 提案 → 评估 → 整合”的改进机制。

它还提出了 L1–L5 的分级：从人工修改，到 Agent 提建议、人来验证和应用；再到固定机制下自动提出、应用和验证改动；更往上才是修改改进机制本身，以及跨领域的递归改进。

我觉得这个区分很有用：自动化执行一个固定的优化流程，和让优化流程本身也变得更好，是两件事。 按这份综述的划分，保留人工审核和应用环节的辅助改进，也不应该直接包装成已经实现了更高等级的 RSI。

不过这里的分级是作者提出的框架，不是全行业公认的标准。字节这边的三组 Benchmark，也不能概括成“递归自我改进已经被解决了”。我这里主要引用项目页的组织方式和观察，还没有独立复现底层论文的实验。

对我而言，一份整合更像是在问“闭环会在哪里断”，另一份更像是在问“系统究竟允许哪些东西发生变化”。后面看具体方法时，我会带着这两组问题去读。

4. 具体到不同路线，究竟在改什么？

下面只是帮我理清问题的几个例子，不是排行榜。我也没有在统一条件下复现这些工作的跑分。

• Darwin Gödel Machine（DGM）：修改 coding agent 自身的代码，评估后保留多个版本，再从这些版本继续探索。吸引我的不只是“自己改代码”，还有保留不同分支，而不是每次都拿最新版本覆盖旧版本。
• RRSI：在冻结模型权重的前提下，对 Harness 做受编辑预算、历史反馈和成本等约束的修改。对实际工程来说，“允许改多少、花多少成本”本身就很重要，但约束存在也不保证每次都进步。
• SoL-Pi：关注 Harness 的效率机制，比如动作融合、上下文压缩、观测打包。它提醒我，收益不只是一道题做没做对，也可能是相近能力下少花一些 Token 和时间；但发布出来的扩展，不等于整个自动发现过程已经被我们复现。
• Dream-RSI：把改进目标放在探索策略上，用历史探索树的回放来筛选怎么分支、怎么分配并行、什么时候停止，而不是只改最终生成的代码。这里回放能告诉我们的，也受已有探索历史限制；我整理笔记时，仓库仍在准备完整代码和复现脚本，不能把方法介绍当成完整实现已经可复现。
• MASS：把工作流搜索和共享模型的微调交替进行，让更新后的模型继续承担执行、优化和评估角色。这比只改 Harness 又多了一层，但论文里的有限轮实验，仍不能直接推成无限递归加速。

所以我暂时不太愿意把它们都塞进一个“通用 RSI 范式”里。有的改代码，有的改经验，有的改搜索策略，有的连模型权重也一起变。把修改对象和评估方式说清楚，比统一叫“自我进化”更有帮助。

5. 我目前最拿不准的，其实是怎么证明它在进步

如果只想让 Agent 不断提出新版本，现在已经不难了。难的是新版本究竟有没有更好。

我目前比较想从这样一个小闭环开始：

完成一批有明确边界的任务
    → 记录结果和失败类型
    → 找出重复问题
    → 提出一个范围很小的改动
    → 在开发评估任务上比较新旧版本
    → 用不参与改法和选版本的保留测试做最终检查
    → 人工决定是否保留
    → 下一批任务再验证

这里有几个坑，我觉得比“怎么让它反思”更值得讨论：

是不是只是多花了钱？ 新版本多试十次、多开几个 Agent，成功率涨了，不一定说明改进机制更强了。至少要把预算、Token、时间和成功率一起看。

是不是把测试题背下来了？ 同一批任务反复用来提修改、选版本，最后分数变好很正常。即使换了一批任务，只要反复拿来选版本，也会逐渐变成开发集。最终保留测试需要隔离，不能把它的反馈再喂回去继续调。新的任务还有效吗？甚至只是换一种错误表现，还能识别吗？

谁来判断好坏？ 同一个模型提改法、执行、打分，可能共享同一种盲点。我觉得要区分单元测试、外部结果和模型评价，不能全揉成一个“自评分”。测试通过也只说明通过了这些测试。

有没有牺牲旧能力？ 某一类任务更快了，另一类任务却开始漏步骤，怎么算？只保留总分可能会把这种退化藏起来。

哪些东西不能由它自己改？ 我的倾向是，实验范围里的 Skill、工具说明或小块 Harness 代码可以提出候选；评估规则、保留测试集、权限、预算和上线审批不能让候选随便改。否则很容易变成修改评分规则之后宣布自己进步了。

这不是说一定要人永远手工批准所有东西，而是至少在刚开始时，我宁愿先把证据、版本和回退路径做好，再逐步增加自动化。我自己也还在探索，不想把这种早期尝试说成已经实现了强意义上的 RSI。

想听听大家怎么做

1. 大家有没有做过跨任务保留经验、自动改 Skill 或 Harness 的实验？什么改动是真的有用，什么最后只是增加了复杂度？
2. 如果模型权重不变，怎样的结果会让你相信“改进能力本身”在提高，而不只是积累了更多模板？
3. 评估怎么设计，才能避免越迭代越过拟合？业务结果反馈很慢、很吵的时候，怎么选可靠的中间信号？
4. 有没有特别值得读的论文、开源实现，或者反例？尤其欢迎那种“试过，最后没用”的经验。

对我来说，现在最想弄明白的不是 Agent 能不能自己写一段修改，而是这些修改能不能经得起下一批任务。欢迎拍砖，也欢迎做相关研究的朋友帮忙指出我理解里的漏洞。

---

文中提到的资料：

• Self-Developing Agents — ByteDance Seed / TokenWave
• The Path to Recursive Self-Improving Agents — Alibaba Group
• Darwin Gödel Machine 论文
• RRSI 论文
• SoL-Pi
• Dream-RSI
• MASS 论文

我之前也写过一篇自己的小规模实验记录，里面是更具体的两层循环和评估边界。还在摸索中，放在这里供有兴趣的朋友参考。

我近期准备在这台双 RTX PRO 6000、48GB RAM 的机器上实际尝试一下。

初步打算先评估 Strata-DS，参考 Xolotl 和 DS41RT，不急着从官方 Strata 从零写后端。先核对 1017 的权重结构和量化来源，再测短上下文、加载峰值及逐卡显存；正确性基线会先关闭跳专家、缓存感知路由偏置等有损优化。

后面再看双卡驻留、DSpark，以及逐级加长上下文。目标仍是尽量让计算权重留在 GPU、Engram 留在 NVMe，RAM 只承担有限缓冲，但目前不能保证能实现，更不能提前承诺速度。

跑通或踩坑都会回来更新，记录具体版本、量化、每卡 300W 下的速度和内存占用。有做过相关尝试的朋友，也欢迎分享经验。

补充一个我觉得这台机器最有意思的地方：不只是内存容量大，而是它把 GPU、网卡和存储连起来的拓扑，很像把数据中心的一部分搬到了桌边。

拿技嘉这台 W775-V10-L01 来说，ConnectX-8 SuperNIC 不只是一张双 400G 网卡，它本身还集成了 PCIe Gen6 交换功能。

不过这张厂商简图没有明确画出 GPU 到 ConnectX-8 的连接，STH 的拓扑分析和实测补上了这一点。

这里有三条不同的路，不能混在一起看：

• Grace CPU Blackwell Ultra GPU：NVLink-C2C，负责本机 CPU/GPU 的一致性互联。
• GPU ConnectX-8：PCIe Gen6 x16，Data Direct 提供了 NIC 直接访问 GPU 的数据路径，配合 GPUDirect RDMA，不必先把传输数据搬到 CPU 内存中转。
• Grace CPU ConnectX-8：PCIe Gen5 x8，这条反而窄得多。

STH 实测两台 Station 用两条 400GbE 链路连接，GPU 到 GPU 的 RDMA payload 达到约 784.3 Gb/s，CPU 到 CPU 则只有约 229 Gb/s。前者折合约 98 GB/s，注意不是 784 GB/s。也就是说，“有 800G 网口”不等于机器里所有数据都能按 800G 往外搬，得看数据在哪里、实际走哪条路。

我感兴趣的是它对多节点推理、Prefill/Decode 分离的意义。 比如一台做 Prefill、处理输入，另一台做 Decode、持续生成 Token，中间要把 KV cache 传过去。这时候 GPU 显存之间能直接通过 RDMA 高速搬数据，就比只盯着单机算力和总内存容量更值得研究。

这里跨机器走的是 Ethernet/RDMA，不是把本机 NVLink-C2C 延伸到另一台，也不会自动把两台机器变成一块统一显存。真正做 P/D 分离，还需要 Dynamo、SGLang 等软件栈配合；能否抵消 KV 传输和调度开销，得看模型、上下文长度、并发和实际测试。上面的数字是网络传输测试，不是 P/D 分离加速的实测结果。

存储这边也有个细节：它的两条 Gen6 x4 M.2 插槽挂在 ConnectX-8 下面，另外两条 Gen5 x4 才挂在 Grace CPU 下面。连 SSD 放在哪个 PCIe 分支上都有区分，不是普通工作站插张大显卡、再插张高速网卡这么简单。

所以我觉得它有意思的地方，是桌面形态下也提供了围绕 GPU 数据路径设计的 scale-out 条件。不一定每个人都需要买两台，但如果想研究多机推理，这套拓扑本身就很值得看。

参考：

• STH：拓扑分析（第 3 页）、网络实测（第 7 页），图和测速来自其评测，不是我的实测。
• NVIDIA：Data Direct
• NVIDIA Dynamo：P/D 分离及 RDMA 传 KV cache

有个很地狱的比喻：旧显存可以回收 芯片可以回收 旧显卡也可以继续跑新模型。但人脑子可不能回收。
GPU以及一系列支持AI的系统和算力 最终替换的是人的劳动力（也解释了硬件价格为什么越来越贵）
目前世界的网络基础系统还是为Human服务的 但今后大部分人都是靠agent来和底层系统交流 所以很多系统要重新设计成Agent Native:
https://blog.haochuanz.net/posts/when-the-caller-is-an-agent

@terry 对，读自己的代码再修改，这点我同意。我想讨论的重点其实是：怎么验证改完之后真的更好了，而且没把原来好用的地方改坏。

一个常见做法是，把可重复运行的任务和工作流做成 eval，新旧版本在相同预算下跑多次。比如 pass@k 看 k 次尝试里至少成功一次的概率，pass^k 看 k 次全部成功的概率，分别看解决问题的能力和稳定性。

有点像股票策略改完后做回测，再拿没参与调参的数据做样本外验证，避免只是过拟合了原来的例子。

具体配置：

• CPU：AMD 9700X
• RAM：48GB DDR5 6400 CL32
• SSD：2TB Pcie 4.0 系统，2x 4TB Pcie 5.0 Swap+模型硬盘
• GPU：2x RTX 6000 Pro
• OS: Ubuntu 26.04 LTS

项目细节：

• 文件配置：https://github.com/lunarmoon26/qwen3.8-flash-next
• 模型链接：https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF/tree/main/UD-IQ4_XS

跑分：

机器照片：

之前在1017 上 Strata 还差哪些 Gap和准备开始实测的回复里挖了个坑，这次回来交作业：同一台双 96GB 显存、48GB 系统内存的机器，DeepSeek V4.1 Flash 1017 已经跑上 Strata，也接到 OpenCode 里实际用了。

不是之前 Qwen 那个 210 tok/s 的配置换了个模型名。这次用的是 1017 的 EXL3 2.7 bpw 量化。原帖截图使用普通 decode；完成下面这轮对照后，当前部署改选 按层拆分 + DSpark，仍然不开跳专家。

2026-10-20 更新：最后选了 Layer + DSpark

这轮把 DSpark 的验证和状态提交改了一遍，也实际做了 TP2。结论先说：这台机器上，当前实现还是按层拆分 + DSpark 更快，TP 暂时不作为默认方案。

同一个代码问题（要求用 Python 写线程安全的 LRU cache），63-token 输入，固定比较前 96 个 greedy 输出 token。输入逐 token 处理，prefill 不计入 decode 时间；预热一轮，再测三轮取中位数。四种模式的输出 token 完全相同：

执行方式	推测解码	Decode
Layer split，18/22 层	关	68.1 tok/s
Layer split，18/22 层	DSpark	80.8 tok/s
TP2	关	42.0 tok/s
TP2	DSpark	43.0 tok/s

这组短代码题里，Layer + DSpark 比 Layer 普通 decode 快约 18.7%。DSpark 的预热和测量轮都用了 33 个验证窗口，平均每窗口接收 2.909 个输入 token；不是说每个窗口都接收了这么多个额外草稿，这个统计包含必然提交的首 token。

测量使用 CUDA 13.4 / GCC 15；测试进程限制为 16 GiB 主机内存、禁用 cgroup swap，CPU 配额设为 200%。MTP 专家 GPU 缓存上限为每个参与 drafting 的 rank 1024 MiB，按可用显存有界增长。

这轮主要改了两点：

• DSpark 不再接受几个 token 就重跑几次主干。 多个候选输入按层批量验证，直接提交接受前缀对应的 KV、压缩状态和下一步 drafting 输入，拒绝的尾巴回滚。缓存只针对可选的 MTP 专家，不挤掉主干常驻专家，也没有重新量化模型。
• TP2 不是把 Layer split 换个名字。 两张卡实际持有量化矩阵和专家的输出通道分片，attention head 也做了拆分；合并分组通信、使用有界双缓冲 mailbox 后，比最初的 TP 实现快了不少。但它仍然明显落后于按层拆分，不能因为叫 TP 就当成加速。完整内核 profile 尚未拿到，不把猜测写成已确认的耗时归因。

代码和部署配置都已提交、推送：

• 引擎：a3d8196
• 部署：3e05754

80.8 tok/s 是这组短输入、固定输出的 native-engine 对照结果，不是下面 OpenCode 截图那条 51K 输入请求的新版测速，也不是所有 coding 请求都能达到的速度。 原截图和约 63 tok/s 的标题保留，不混成同一组数据。

具体配置：

• CPU：AMD Ryzen 7 9700X
• RAM：48GB DDR5-6400 CL32，双通道
• GPU：2 × RTX PRO 6000 Blackwell，各 96GB，每卡限功耗 300W
• 主板：铭瑄 MS-iCraft B850 AIGA，两张 GPU 都是 PCIe 5.0 x8
• SSD：2TB 系统盘 + 2 × 4TB PCIe 5.0 NVMe，模型和 Engram 放在数据盘
• OS：Ubuntu 26.04 LTS

还是之前跑 Qwen 的那台机器，没有为了这次实验升级系统内存。装机、拓扑和机器照片可以看旧帖。

项目细节：

• 部署配置：deepseek-v4.1-flash
• 引擎分叉：Strata-DS
• 模型：sudoingx/DeepSeek-V4.1-Flash-1017-EXL3-2.7bpw

感谢 Niko 的 Strata、Jackwwg83 的 DeepSeek 后端，以及 sudoingx 的量化。不是我从零写了整个推理引擎：现在的仓库直接基于 Niko 的上游，选择性移入已有 DeepSeek/EXL3 实现，再补这台机器需要的双卡驻留、低 RAM 加载、prefill 和服务适配。

部署仓库固定引擎版本和量化版本，具体构建、安装和启动方法都放在 README 里。现成量化会生成运行用的 pack，这是打包/重排，不是本地再量化一遍；也仍然需要额外磁盘空间，不是零转换缓存。

实际使用截图：

图里正在生成一个 read 工具调用。下面那条已经完成的请求，统计是：

项目	数值
输入	51,487 tokens
输出	93 tokens
Prefill	654 tok/s
Decode	62.9 tok/s
请求总耗时	80.3 秒
专家显存命中率	100%

截图当时双卡合计显存占用 185.1GB，两张卡分别约 92.6GB / 92.5GB。GPU 合计功耗读数约 455W，这是显卡传感器读数，不是整机插座功耗。

所以现在可以更新成：1017 不只是能输出几个字，已经能接进 OpenCode 发起实际工具调用请求，截图这条请求的 decode 约 63 tok/s。

不过这不是统一条件的 benchmark：这条输入约 51K，只输出了 93 tokens，不能代表所有任务和上下文长度。也不要拿它和旧帖 Qwen 的 210 tok/s 直接横比，模型、量化和请求都不同。

这次主要填了哪些坑？

核心还是旧帖说的那件事：显存够，不代表加载过程就能在 48GB RAM 里完成。

默认部署走的仍是按层拆分，不是 TP，也不是把两张卡当成一张统一的 192GB 显卡：

• 第 0–17 层放第一张卡，第 18–39 层放第二张卡，跨卡 KV/index 等状态也要一起处理。
• 主干专家权重常驻双卡显存，不依赖一边生成一边从 SSD 换进主干专家，也没有为了命中率改掉路由选择。
• Engram 留在 NVMe，按需查表；加载和传输使用有限的主机缓冲，不先在 RAM 里放一整份专家权重。
• 专家 RAM 预算设为零，只表示不保留专家权重的常驻 RAM 副本，不表示整个进程不占 RAM。数据仍然经过主机内存，不是 SSD 直传显存。

Prefill 也做了有界分块，避免长输入时临时空间失控。当前仍是单会话，生成路径改选 Layer + DSpark；上面的 OpenCode 截图仍然是普通 decode 的历史请求，不是靠这轮 DSpark 改动跑出来的。

关于 524K：分清配置上限和真正测过的输入

目前配置容量是 524,288 tokens，单个会话。但这里有两轮版本，数据不能混着写：

• 之前的 resident 版本 ccd8cf2，实际跑过 32K、128K、262K，最后输入 524,256 tokens，在 524,288 容量内取回了开头指定的口令。最后一档 prefill 531.73 秒，约 985.95 tok/s，完整测试 552.90 秒，没有 swap/OOM，也没有主干专家流式换入。
• 现在基于 Niko 上游整理后的版本，15 个组件测试通过；实模型测试覆盖逐 logit 对照、接受前缀直接提交、错误草稿回滚、会话隔离和取消恢复，TP 还测试了两种 GPU 顺序。513-token 用例的 prefill 和逐 token logits 均与之前发布的二进制逐字节一致。已安装的 Layer + DSpark 也在 524,288 配置容量下通过了短请求、重放、STOP 恢复和正常退出测试。但之前全长 524K 复跑我中途停掉了，之后没有重跑，不能写成新版又完整通过了一轮 524K 实际输入。

前面的长输入测试是重复填充内容加开头口令检索，不是全面的长上下文质量测试；OpenCode 截图也不是 524K 输入。这里先把能确认的结果交代清楚。

下一步：从能跑，走到能稳定干活

之前在讨论里说过，能启动、能输出，不等于已经证明适合当 coding agent 或 subagent。现在至少把部署和实际请求这一步走通了，后面更值得花时间的是 Eval：中文、代码、工具调用成功率、长上下文效果，以及真实任务的延迟和成本。

EXL3 2.7 bpw 的质量损失还没有靠这些测试量化出来，和可信参考实现的全面对照也没做完，暂时不下“无损”“追平原版”之类的结论。Docker 的 GPU 路径和新版实模型 HTTP 端到端验证还没做完，目前部署仍走 native，服务按需手动启动。

总之，之前的 Gap 帖不是白挖坑了。这台“大显存、小 RAM”的机器，现在又多了一个能接进 OpenCode 折腾的模型。欢迎有类似配置的朋友交流，尤其想看看大家怎么做真实 coding/tool-use 的评测。

@johnnybegood 完全同意 跑起来最多能证明能输出>=1 tok/s不能干任何事。
能稳定干活 作为subagent的LLM 能降低延迟或成本 增加效果（这只能通过eval那一套东西来测）才是本地部署的作用
今后的重点是Eval，而不是“我觉得他好像挺聪明”

之前在双 RTX PRO 6000 跑 Qwen3.8-Flash-Next 的帖子里，补充过我为什么选择 Strata：两张卡各有 96GB 显存，但系统内存只有 48GB，两张卡都限制在 300W，主要考虑长期安静开机，不是满功耗刷分。

最近想在同一台机器上尝试 DeepSeek-V4.1-Flash-1017。查了一圈源码后，发现已经有 Strata 的 DeepSeek V4.1 社区分叉，不一定要从零移植。想开个帖子讨论：基于现有实现，距离“双卡、大显存、小 RAM、NVMe 后备”跑好 1017，还剩哪些 Gap？

先说边界：我目前跑通的是 Qwen + Strata，以及之前的 DeepSeek-V4-Flash-0731 + vLLM-Moet；没有在 Strata 系分叉上跑通 V4.1，更没有实测 1017。下面是源码、配置和作者报告整理，不是我的新跑分，也不是一套已经验证可用的配方。

为什么想保留 Strata 这条路线

我在原帖的补充里解释过，Strata 吸引我的不是“完全绕过 RAM”，而是可以用有限的主机缓冲，把专家权重分批搬进 GPU cache；已放进 GPU 的部分，不必再在主机内存里常驻一整份专家副本。

现有 Qwen 配置中，全部 24,576 个专家进了双卡 GPU cache。这是它在我机器上表现不错的重要前提，不能直接推导成更大的 DeepSeek 也会一样快。数据仍要经过主机内存，不是 SSD 直接传显存；RAM budget 也不是整个进程的内存上限。

我的诉求是尽量避免为了加载模型，先准备超大主机内存，或者再生成一套几百 GB 的转换缓存。checkpoint 文件大于 48GB，本身不能证明跑不了；关键是加载峰值、常驻分配和临时转换分别占多少。

已有社区实现，不必从零写整个后端

官方上游 Strata 没有 DeepSeek V4.1 后端，不代表 Strata 生态没有。 目前最值得评估的是这两个项目：

1. Jackwwg83/Strata-DS

项目：Strata-DS，检查版本 a46eeba。

已经有独立的 V4.1 计算图和 CUDA kernels、EXL3 专家分层、磁盘 Engram、批量 prefill、DSpark、服务接口，以及相关测试。源码里有显式专家 RAM 预算，允许设为零，不能简单理解成“必须在 CPU 常驻一整份专家权重”。

但还不能原样照搬：

• 作者主要验证的是单卡笔记本；上游 Qwen 支持多卡，不能直接算作这个 DeepSeek 后端已经支持双卡。
• 公开笔记本配方实际占约 54 GiB 主机内存，仍超过我这台机器的可用 RAM。
• 公开速度包含跳过部分低排名专家的有损优化；作者也披露了输出分布变化，尤其中文更明显。不能直接当作严格执行同一量化模型的速度。
• 它仍需要额外生成 pack。文档的安装磁盘预算约为 342GB 下载 + 120GB pack。按张量、专家读取可以控制打包内存，但并没有消除额外磁盘副本。

2. Indras-Mirror/Xolotl

项目：Xolotl，原名 Strata-DSV4.1，检查版本 7375e30。

已经有 V4.1 引擎、GSQ 量化工具链、三层专家缓存、磁盘 Engram、DSpark、FP4 KV 和服务适配。量化与正确性检查工具尤其值得参考。

限制也要一起看：作者主要在 4090 + 90GB RAM 上验证，部分配置使用约 60 GiB pinned arena。源码允许限制 arena，但调小后在我这台机器上的峰值和性能没有验证。还有改变专家选择的缓存感知路由偏置，需要与严格路由分开看；现成模型带有 Uncensored 标识，也不能直接当成官方 1017。

两个仓库根许可证都是 MIT，方便研究和改造；具体引入的第三方组件与模型权重仍要分别核对许可、保留声明。我目前只检查了这些源码和文档，没有本机复现，也没有找到这两个项目明确验证 1017 的证据。

六类 Gap：适配检查清单，不是六项都要重写

图中“Strata”指官方上游；社区分叉已实现其中不少模块。右侧六项是针对 1017 和我的硬件仍需逐项核对的清单，不代表全部需要从零开发。

1. 架构兼容：先确认 1017 相对旧 V4.1 的差异

检查的官方 Strata 上游版本只识别 qwen4exp 和 qwen35moe；1017 官方配置是 DeepseekV41ForCausalLM，涉及压缩注意力、KV/index 来源层、候选块筛选、hyper-connection 和 Engram 等结构，不能直接套 Qwen 前向。

但社区分叉已经实现了 V4.1 的后端。现在更合理的第一步是对照旧 V4.1 与 1017 的参考实现、张量结构和编码文件，确认哪些模块可以直接沿用、哪些语义需要修改，而不是重新实现一遍全部算子。

2. 权重与量化：1017 来源是首要门槛

1017 官方 checkpoint 使用 safetensors，配置包含 FP8、分块 scale 和 FP4 专家。现有分叉分别走 EXL3/pack 或 GSQ/GGUF 等路径，格式并不互换。

即使计算图兼容，也需要明确基于 1017 权重制作的量化，验证张量映射、scale、布局和质量。旧 V4.1 量化换个模型名称，不会变成 1017。 如果自己量化，还要单独核算校准、转换的 RAM/VRAM 峰值，以及额外磁盘空间；运行时低 RAM，不代表量化也自动低 RAM。

3. Engram：已有磁盘实现，重点是长 prompt 下的边界

1017 配置在第 1、14 层设置 Engram。现有分叉已提供磁盘查表路径，不需要仅凭 Qwen 的 PLE 经验重新猜一套。

仍要验证 1017 的索引、表布局与 scale 是否匹配，以及长 prompt 下读取队列、staging buffer、pinned memory 和 page cache 的峰值。mmap 只是映射机制，不自动等于物理内存占用有界。

4. 双卡与低 RAM：这是我的硬件适配重点

两张 96GB 不能当成一张统一的 192GB 显卡。每张卡都要分别容纳分配给它的权重、KV/索引状态、草稿和临时空间。

我更想利用显存优势：尽量让量化计算权重常驻两张 GPU，Engram 留在 NVMe，RAM 只承担有限缓冲。 不能直接照搬那些为 24GB 显卡优化的大 CPU 专家池方案。

双卡分层还要处理 V4.1 跨层共享的 KV/index 状态，不能只在中间层切一刀。按层拆分与 TP 也不是同一种方式；我这台机器还有 PCIe x8/x8 的约束，需要结合具体路径测。至于两张卡能否把某种量化和运行时状态全部放下，目前不能保证。

5. DSpark 与服务：复用已有实现，但要分阶段验证

两个项目已有相关实现，能减少不少工作。我的顺序仍是先关推测解码，验证基础前向和严格路由，再接 DSpark，检查接受率、结果和实际加速。

tokenizer、chat template、思考开关、tool calling、停止条件也要对照 1017 验证。服务端有兼容 API，不代表模型语义自动兼容；视觉可以后置。

6. 正确性与长上下文：不把有损优化混进基线

首先关闭跳专家、缓存感知路由偏置等会改变计算结果的优化。即便关闭这些，同一量化与原始权重也未必质量一致，CPU/GPU 数值路径还可能存在差异，需要分别检查。

对我而言，最终目标不是“启动成功、输出几句话”，而是约 400K 实际上下文下还能稳定干活。至少分开记录：

• 冷/热启动 RAM 峰值、逐卡显存、swap 使用与额外 pack 大小；
• 与可信参考实现对照的 logits/困惑度或任务结果；
• 量化后的中文、代码、工具调用和长上下文质量；
• 逐级加长输入后的 TTFT、prefill、decode 和内存增长；
• 同为每卡 300W、相同输入输出长度和并发口径下的速度。

配置上限写 1M，不等于实际填满 1M 测过；一条 200 tok/s 的截图，也不能代表所有任务。

其他项目可以帮到什么

• DS41RT：作者已有双 RTX PRO 6000、EXL3 2-bit、无额外 Spark 的报告，是双卡执行和缓存设计的重要对照。但在我这台 48GB RAM 机器上的加载峰值、1017 量化来源与正确性仍待验证。
• DwarfStar：可以参考独立实现与质量验证思路，不代表其硬件配方能直接套用。
• llama.cpp 的 V4.1 工作：可以参考转换、算子和模型语义；相关工作不会自动成为 Strata 分叉已经具备的能力。

论坛两篇四台 GB10 的报告也很有参考价值，感谢分享：SparkRing 无交换机环、MiaAI-Lab 配方。它们支持了磁盘 Engram 这条路线的可行性，但都是早期 V4.1，不是 1017；四台机器的统一内存容量也不能直接类比双卡 + 48GB RAM，作者报告的速度我没有复现。

想请教大家

我现在的判断是：不必先从官方 Strata 重写整个 DeepSeek 后端，更值得优先评估已有社区分叉，再补 1017、双卡驻留和低 RAM 的缺口。 这仍然不是换一组启动参数就能保证成功，但工作范围比从零移植小得多。

如果有人已经做过相关尝试，尤其想了解：

1. 有没有明确基于 1017、适配双 96GB 卡，且启动不需要上百 GB 主机内存的量化与引擎组合？
2. 有没有给这些 Strata 社区后端实现双卡驻留的工作，尤其是跨层 KV/index 的处理？
3. 48GB RAM 下，哪些分配最容易跑出专家预算之外？如何减少 pack 与原始权重的重复存储？

欢迎贴具体版本、启动峰值和测试口径。比起先追最高 tok/s，我更想先确认一条能稳定复现、长期开着用的路线。

源码与配置参考

• 官方 Strata 模型家族识别，477ac13
• Strata-DS 引擎构建与测试，a46eeba
• Strata-DS 内存预算选项
• Xolotl 项目说明，7375e30
• DeepSeek-V4.1-Flash-1017 官方配置
• 我之前的 Qwen 部署配置

@terry 我觉得可以换个例子来看：Dots、Muse、Cue、Instinct、Grok Bot，甚至 Hermes、OpenClaw 这些，随着模型和工具能力普及，做出类似功能的技术门槛可能会越来越低。但某个产品没有很深的壁垒，不等于这种形态会消失。就像浏览器有 Chrome、Edge、Firefox，产品可以竞争、更替，但浏览器这种入口一直存在。

我说的 Agent Native 更偏向这个变化：以前是人打开不同软件，点窗口、填表，把步骤串起来；以后越来越多时候，是人表达 intention，也就是目标和约束，让 agent 去调用底层系统完成。你主帖里说的“通过聊天把想法告诉 AI，不需要自己点鼠标”，其实也是这个方向。

如果调用者越来越多是 agent，底层系统就不能只考虑按钮放在哪里，还得让它能准确读取状态、在权限范围内执行、出错后恢复。这部分是具体的工程问题，不只是换个名字。

当然也不是说 GUI 和按钮不需要了。就像 Windows 有图形界面，也一直能用 CMD、PowerShell，几种操作方式可以共存。以后我们仍然可以手动操作电脑，也需要看结果、做判断、随时接管。变化的是不必每一步都亲自点，而不是人不能再点了。

@imbiplaza-ASUS 我算了下这玩意儿一个20人团队用大概每人5000刀 绰绰有余。我们很多时候一个月就1000-2000刀token 虽然是SOTA但确实也是贵。
大部分任务开元模型都可以跑，这玩意儿5个月就回本了。