DeepSeek Harness 插件重复 85% 文件,白占 1.15GB.

我算了一笔账，算完有点不太想说话。

7 个自己写的 dsh 插件，装完占 2402MB。我本来以为这数合理 —— 每个插件都带一份运行依赖嘛，又不是我能改的。

直到我把它们的 「@deepseek-ai」 目录逐个文件算了 md5。

这笔账是怎么算的

结论先放在这：

6 个插件的 「@deepseek-ai」 目录里，一共 34872 个文件，但算下来唯一内容只有 5120 份，重复了 29752 份，重复率 85.3%。按体积摊，这 1394.5MB 里如果共享一份，能压到 200MB 上下。

这 6 个插件里，每 100 个依赖文件，只有 15 个是不一样的。 剩下 85 个，是同一批文件被存了 6 遍。单这一项，白占 1.15GB。

而且这不是抽样的估算，是逐个文件算的 md5。同一个 「@deepseek-ai/cordis/package.json」，在 comfyui、dgx-infer、gzh-publisher 三个插件里，md5 完全一样，都是 1241 字节。

为什么改不了

我第一反应是"把依赖抽出来共享"。然后我想起来这不是配置问题，是架构问题。

dsh 的插件在自己的目录里 「import」 依赖，走的是裸名解析。Node 的 ESM 会先 「realpath」 一次 —— 如果你用软链（junction）把依赖挂进去，「realpath」 会解掉它，然后 Node 顺着插件的真实路径向上找依赖，找不到就报 「ERR_MODULE_NOT_FOUND」。

我实测过，报错里给出的路径就是插件真实路径，不是软链那条路径。软链对 ESM 无效。

那每个插件就只能实体自带依赖。7 个插件各带 247MB，10 个就是 2.5GB，20 个就是 5GB。装的插件越多，这份重复就越贵。

我算了一下边际：每加一个插件，就要多付 247MB。这 247MB 里，真正属于这个插件自己的东西不到 1MB —— 其余全是和别的插件一样的公共依赖。也就是说，我每多装一个功能，净花的公共依赖钱是 246MB。

这个比例很荒诞。功能是新的，依赖是旧的，但账单按全量收。

我现在的判断

短期这笔钱我认了。 1.15GB 换 7 个插件稳定运行，不亏。dsh 的插件机制是这个设计，硬对抗它没有意义。

但有两件事值得现在就做：

第一，别再往上叠脏账了。 我这次清出 861.6MB 的 pnpm 残留目录（「node_modules.del<pid>.removing」）和 170MB 验证环境残骸。这些是真垃圾，删了不影响运行。插件依赖那 1.15GB 是冤枉钱，但这 1GB 是我自己没清理的坑。

第二，硬链接这条路我留着。 实测可行：依赖实体存一份，每个插件的 「node_modules」 里挂硬链接。同样的 inode，ESM 解不开。代价是「改一处、动全屋」——只适合依赖版本完全一致的场景。我这 7 个现在是一致的，但只要有一个插件版本漂移，就会出事，所以先不用。

说到底，"插件必须自带完整依赖"这件事，不是 dsh 一家的毛病。 所有走这条路的应用，都会在插件装多之后长成这个样子。区别只在于，你有没有在自己那台机器上，把这笔账真正算出来。

这台机器到底跑不跑得动，先算一遍再下单

买错一张卡，沉没的不只是差价。把模型和机型对上，结论十秒出。

🧮 适配器 · 197 个模型 × 125 台机型　｜　🔍 核验器 · 141 个项目商用判定

🚀 部署单 · 37 类场景　｜　📈 对照台 · 9 台真机实测

扫码进入「丘山录」小程序

参考来源

1. 本机实测（2026-10-13）：6 个 dsh 插件 「@deepseek-ai」 目录的文件级 md5 去重，34872 个文件 / 纯内容 5120 份

2. 本机实测（2026-10-13）：ESM 「import」 对 junction 的 realpath 行为 A/B 复现（报错路径指向插件真实目录）

3. 本机实测（2026-10-13）：pnpm 残留目录统计，「node_modules.del<pid>.removing」 与 「.probe」 残骸合计 861.6MB

数据说明：本文数值为本机实测（2026-10-13，dsh 桌面版 0.2.0-rc.2）。不同插件组合下的重复率会有差异，仅供参考。

声明：本文为原创实测记录，未接受任何厂商赞助。

🔔 深耕 AI 干货 | 点名片订阅，上新早知道

#丘山录  #大模型本地部署  #DeepSeek  #依赖管理