插件装完只是起点。真正决定一台 ECS 上知识库能否长期稳定运行的，是容量估算是否留了余量、模型权重落在哪块盘、分块参数怎么定、以及什么时候该重建索引。这篇不谈安装步骤，只谈长期运行的容量与性能取舍。插件为 Soren-ABT/dsh-knowledge（知识库检索），当前发布版 v0.4.1，许可 AGPL-3.0，综合分 53.2，星标 57，周下载 749；本站已在 1 天前于 dsh 0.2.0-rc.2 下真实安装成功（L4 · 真实安装）。
一、先把容量账算清楚
知识库在 ECS 上的占用分四块，规划磁盘时不要只盯着上传的原始文件：
- 本地 embedding 模型：默认
onnx-community/Qwen3-Embedding-0.6B-ONNX，约 585 MB、输出 1024 维向量；扫描件 OCR 模型另需约 21 MB。这是固定开销。 - 分块库：分块保存在独立 SQLite 文件
/knowledge-chunks.sqlite，可用chunkStorePath调整落点，随文档量增长。 - raw 存储：原始文件保存在知识库 raw 存储里，与上传体积大致同阶。
- 内存侧：向量使用 Float32Array 常驻缓存并精确失效。1024 维意味着每千条分块约 4 MB 向量常驻，切分越细、分块越多，内存占用越高。
也就是说，一台只跑插件本体的实例，把模型、索引和原始文件都算上，几十 GB 数据盘是稳妥起点；文档量大时优先扩数据盘，而不是系统盘。
二、把模型权重放到数据盘
模型权重是典型的「装一次、长期不动」的数据，最合适放进 ECS 数据盘。默认本地模型缓存在 /dsh-knowledge/local-models，直接受系统盘容量约束。
管理界面的「模型缓存目录」提供了原生文件夹选择、打开目录和安全迁移，可以把已有权重整体搬到数据盘挂载点（例如 /data/dsh-knowledge/local-models），不必手工 mv 后再猜路径是否生效。配合后台模型管理页，下载、重试、删除、进度与健康状态都在同一处查看。
下载机制值得单独记一笔：下载使用模型专属 staging 目录，只有隔离加载和真实向量 probe 成功后才会提升到正式缓存，并写入带文件指纹的 readiness marker。缓存目录里的文件因此是「已校验可用」的，迁移后回来健康检查仍以它为准。另外，搜索不会隐式下载 rerank 模型，rerank 权重必须先在本地模型页下载并通过健康检查。
三、分块参数与检索开销
chunkSize 与 chunkOverlap 走的是 Token 预算，不是字符数。调这两个参数时，实际在权衡召回粒度、索引体积与上下文成本。
长文本切分时，插件按标题、代码、段落、句读、列表、换行的优先级依次寻找断点，尽量不在语义中间下刀；标题感知分块还会保留 Markdown 标题路径和代码围栏，并把文档标题与标题路径作为检索上下文。可选的语义分块会合并相邻相似段落，可选的 Token 上限则继续在句号、逗号或空格附近细分超长块。
实践建议：块越大，单块信息越完整，但命中后的上下文更臃肿，向量常驻缓存的内存压力也更集中；块越细则分块数变多，索引与内存同时膨胀。除非文档确实很长或结构特殊，不要一上手就把 chunkSize 调得极端，先用默认值跑召回测试，观察来源、相关度、关键词/向量分数和耗时，再决定往哪个方向调。
四、什么时候重建索引
分块或 embedding 配置一改，旧索引与新配置就不再匹配，必须重建。触发点主要有三类：
- 修改了
chunkSize、chunkOverlap或语义分块开关； - 更换了 embedding 模型或向量维度；
- 批量导入后发现质量不理想，想换切分策略重来。
重建粒度可以选：改单条资料时用 knowledge_reindex_document 重建单条，动到全局配置时才用 knowledge_reindex_base 重建整库。整库重建走后台，无需长时间占着终端。v0.4.1 本身不迁移数据库、不强制重建索引，升级时不必担心被动触发一次全量重建；而失败的替换重建不会破坏上一份已提交内容，重建期间库仍可读。
五、下载语义对运维的含义
这一段最反直觉，也最容易在云上误判：下载不与发起它的那一次 HTTP 请求绑定。请求返回后传输在后台继续，关闭浏览器或客户端超时都不会取消下载，进度通过本地模型状态持续上报。由此推出几条结论：
- 要停下载必须显式调用取消，关掉 SSH 隧道或断开 SSH 都没有用；
- 取消只中止进行中的传输，已完成并通过校验的模型不会被删除，想删得走「删除」；
- 下载的请求预算按进度重置，慢速链路不会被「总时长」误杀，只有长时间无进度才会被判为卡死。
在带宽受限的 ECS 上，这意味着可以放心发起一次大模型下载再去干别的，不必让 SSH 会话长时间挂着。
六、可选的 MinerU 与失败路径
公式、表格和复杂版式的文档，可以选用 MinerU 远程处理把内容恢复成 Markdown；未配置时继续使用本地解析与 OCR，扫描件由 PaddleOCR PP-OCRv5 优先识别、失败回退 Tesseract。
v0.4.1 修掉了一个很折磨人的失败路径：MinerU 提取失败、退回本地解析也失败时，文档会留下一条只有原始 PDF、没有正文和分块的占位行，点「重建」只会报 has no source text to reindex，从界面和 API 都脱不了困。现在导入、单文档重建与启动恢复走同一条提取链，重建会重新尝试 MinerU，双重失败时会同时报出 MinerU 与本地解析两个原因。
七、备份与监控
容量之外，还要给数据留退路：
- 备份优先保 raw 存储与分块库；对 ECS 数据盘挂 ESSD 快照，比在实例里做逻辑备份更省心。
- 监控两项指标即可覆盖大多数问题：数据盘使用率与实例内存（向量常驻缓存与 ONNX 推理同时吃内存）。
- 目录来源支持重新扫描，导入新增文件、重建已修改文件并移除已不存在的文件，单个文件失败不会隐藏其他结果。
总结
ECS 上跑知识库的长期课题是容量与节奏：模型权重放数据盘、分块参数按 Token 预算调、配置一变就重建对应粒度的索引、把「下载不随请求终止」这条语义记进运维手册；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：文档量持续增长、需要提前把系统盘与数据盘分工规划清楚的团队；希望 embedding 与 OCR 完全在 ECS 内本地运行、不外发数据的场景；愿意按召回测试结果持续微调分块参数与索引重建节奏的使用者。不适合：文档量很小、几个月都不新增内容，容量规划几乎没有意义的场景；不能接受 AGPL-3.0 许可约束的闭源集成项目；完全不想管磁盘与内存、期望开箱即用且零运维的用户。
标签：dsh-knowledge、DeepSeek Harness、阿里云 ECS、容量规划、知识库检索
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
