DeepSeek Harness 启动慢、响应慢：插件、索引与模型三处定位、计时与优化顺序

启动慢和响应慢不是同一件事。 前者发生在服务起来之前，后者发生在请求发出之后；混着优化，往往改了半天没效果。

先分两类慢

用一个简单问题区分：慢在「打开」还是「回答」。

启动慢看「从命令到可用」。 期间没有请求模型，慢的原因在本地。

响应慢看「从发送到首 token」。 首 token 慢偏模型与网络，后续慢偏工具与上下文。

界面卡顿是第三类。 它不影响服务，只是渲染问题；不要和启动、响应混在一起。

启动阶段：插件与索引

启动慢，先数插件，再看索引。

1. 记录从执行命令到服务可用的时间。
2. 临时停用非必要插件，复测同一时间。
3. 时间明显下降，说明插件是主因；逐个加回，找出最慢的那个。
4. 检查会话与搜索索引体积，过大时清理或重建。
5. 确认 DSH_HOME 所在磁盘没有明显 I/O 瓶颈。

插件是启动阶段最大的变量。 常驻监听、界面注入、启动钩子都会增加加载时间；插件越多，影响越明显。

索引膨胀比插件更隐蔽。 会话很多时，索引读取会变慢；清理旧会话或重建索引能改善。

分段计时比感觉可靠。 用秒表记录两段时间，比「好像变慢了」更容易比较。

响应阶段：模型与上下文

响应慢，先看首 token，再看工具链。

1. 发一条简单消息，记录首 token 时间。
2. 发一条复杂任务，记录总时长与工具调用次数。
3. 首 token 就慢，偏模型或网络；后续才慢，偏工具与上下文。
4. 换一个模型对照，确认是否上游问题。
5. 缩短上下文或开新会话，看是否改善。

首 token 是分水岭。 它之前的时间主要由模型与网络决定；之后的时间由生成、工具调用与多轮推理决定。

工具调用会放大延迟。 串行调用越多，总时长越长；能并行就并行，能减少就减少。

上下文越长，生成越慢。 长历史会增加输入处理时间；压缩或开新会话是有效手段。

计时方法

三段计时，足够定位。

三段分开记，不要只记总时长。 总时长变慢，可能是启动、模型或工具，分开才能归因。

连续测三次取中间值。 单次测量受网络抖动影响；三次对照，结果更稳。

记录环境与版本。 模型、插件清单、版本号与网络环境，四项一起记，复现才有意义。

优化顺序

从代价最低、影响最大的开始。

1. 减插件： 停用不常用插件，尤其是常驻监听与界面类。
2. 清索引： 清理旧会话与搜索索引，减少启动读取。
3. 换模型： 首 token 慢时，换响应更快的模型。
4. 缩上下文： 压缩历史或开新会话，减少输入处理。
5. 减工具调用： 合并步骤，减少串行调用。
6. 降渲染开销： 关主题动画、视频壁纸与挂件。

顺序的意义是先做可逆、低风险的。 减插件与清索引不影响数据；换模型与改架构的成本更高。

一次只改一项。 同时减插件、换模型、清索引，效果无法归因；一项一项来。

三条不要做

三种「优化」看起来有效，实际可能更糟。

1. 盲目清缓存。 只对缓存膨胀有效；清完没变化，说明方向错了。
2. 一次停用所有插件。 能变快，但不知道是哪个；逐个停用才有结论。
3. 直接换更贵的模型。 首 token 可能变快，但工具与上下文问题仍在；先定位再换。

优化的前提是定位。 没有分段计时，任何改动都是碰运气。

保留回退。 每次优化前记录配置与版本，效果不好能退回去。

下一步

先分段，再定位，最后按代价优化。 想看启动慢的专项排查，看《DeepSeek Harness 启动慢》；想看上下文压缩，看《DeepSeek Harness 上下文压缩是什么》；想看插件开销，看《插件上下文开销》。

来源：DeepSeek Harness 官方文档、dsh CLI README、deepseek-harness 仓库