<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[关于DeepSeek Harness(DSH)本地 vLLM 插件安装选择，请各位折友们给个建议。]]></title><description><![CDATA[<h1>以下是AI给的建议，请大家审核批注下，谢谢。</h1>
<hr />
<h2>一、本机实际需求</h2>
<p dir="auto"><strong>适用场景:日常学习 + 日常办公+资料整理,模型为本地部署 vLLM</strong></p>
<hr />
<h2>二、核心原则:本地 vLLM 场景,插件要"少而按需"</h2>
<p dir="auto">瓶颈不在插件数量,而在本地 27B-int4 模型的三个硬约束:</p>
<ol>
<li><strong>工具选择精度</strong> —— 系统提示里的工具越多,小模型越容易选错工具、漏参数。每个插件基本都往系统提示里加工具 schema,这是真实代价。vLLM 的 prefix caching 能让"稳定前缀"的重算变便宜,但解决不了"选不准"。</li>
<li><strong>延迟</strong> —— 本地推理比云端 API 慢一到两个数量级。凡是"每回合多调一次模型"的功能(自动标题、反馈打分、子代理群)都会被直接放大成等待。</li>
<li><strong>隐私</strong> —— 本地部署的动机通常就是数据不出内网,反过来要<strong>避开</strong>任何往云端回传会话内容的插件。</li>
</ol>
<p dir="auto"><strong>结论:现有 base + web-app 已覆盖大多数日常场景,只需按下面的分层挑少量插件,其余不装。</strong></p>
<hr />
<h2>三、推荐安装清单(按优先级)</h2>
<h3>① 模型接入层:把 vLLM 连接做得更科学</h3>
<p dir="auto"><strong>首选:<code>dsh-llm-qwen-local</code>(作者 starefinger)</strong></p>
<p dir="auto">面向本地 Qwen(正是 Qwen3.8-27B 这一形态)的专用 LLM 适配器,特点:</p>
<ul>
<li>按模型的多模态开关(同一 vLLM 上"有图/纯文本"两个模型可分别声明能力,纯文本模型关掉图像实打实省上下文);</li>
<li>完全可配置的推理档位(reasoning effort);</li>
<li>请求图像投影;</li>
<li>中英双语 Web 设置页——模型能力(上下文、图像、推理档)从手改 YAML 变成设置页可维护。</li>
</ul>
<blockquote>
<p dir="auto">定位:当前 pi-ai 手写路由已可用,它属于<strong>升级而非必需</strong>;想要更科学的本地模型管理体验就装。</p>
</blockquote>
<p dir="auto"><strong>备选:<code>dsh-llm-gateway-compat</code>(社区插件,官方 Discussion #3814)</strong></p>
<p dir="auto">OpenAI 兼容网关的协议方言修复包。若日后遇到 vLLM 特有的兼容问题(工具调用序列化格式等)再装,平时不需要。</p>
<h3>② 体验层:本地慢推理的最佳解药(建议第一个装)</h3>
<p dir="auto"><strong><code>dsh-autofork</code>(作者 vlln)</strong></p>
<p dir="auto">Agent 忙时自动分叉会话:你新发的指令立刻在新会话里得到响应,旧会话留在后台跑完并把结果回注。本地模型单流又慢,"排队等待"是最大体验痛点,这个插件性价比极高。</p>
<h3>③ 办公层(三选一,不要都装)</h3>
<p dir="auto">三个功能高度重叠,全装 = 系统提示里三套相似工具,正好踩中 27B 模型"工具选择精度"的坑:</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>插件</th>
<th>方式</th>
<th>特点</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong><code>dsh-office-toolkit</code>(cnkids,推荐)</strong></td>
<td>纯 JS 跨平台,无外部依赖</td>
<td>读写 Word/Excel:docx / xlsx / xls / doc / rtf / odt,最省心</td>
</tr>
<tr>
<td><code>dsh-officecli</code>(violetdream)</td>
<td>依赖 officecli 命令</td>
<td>操作 Office 文档,需系统里装 officecli</td>
</tr>
<tr>
<td><code>dsh-office</code>(beancookie 目录收录)</td>
<td>模型读写 + Web 端预览</td>
<td>额外提供 Web 客户端 docx/pdf 预览</td>
</tr>
</tbody>
</table>
<p dir="auto">典型用途:起草周报、处理表格、生成会议纪要、批量改文档。</p>
<h3>④ 推理机管理层(可选,换量化/加机器时很实用)</h3>
<p dir="auto"><strong><code>dsh-model-manager</code>(作者 Ansonfishing)</strong></p>
<p dir="auto">在 DSH 内管理本地推理服务器(llama.cpp / SGLang / vLLM):</p>
<ul>
<li>GPU 注册表;</li>
<li>参数 profile;</li>
<li><strong>VRAM 校验</strong>(换模型/量化前先验证显存是否够);</li>
<li><strong>tok/s 基准测试</strong>(量化效果、不同 max-len 的实际速度)。</li>
</ul>
<p dir="auto">这是把"本地推理运维"工程化的做法:改配置前先测,而不是出问题再查。</p>
<h3>⑤ 学习层</h3>
<ul>
<li><strong>内置 skills(无需安装,最科学的手段)</strong> —— 写你自己的技能包:学习陪练、论文精读、周报模板、代码讲解等。技能是<strong>按需触发</strong>的,不永久膨胀系统提示,是本地模型下定制行为的最优机制。优先写技能,而不是装一堆常驻工具插件。</li>
<li><strong><code>dsh-shoucang-memory</code> / 守藏记忆(作者 Fishsb)</strong> —— 分层长期记忆库 + 会话蒸馏 + 深度睡眠整合 + 设置面板。适合"学习伙伴要记得我的进度"的场景。注意:整合任务消耗额外推理,请在 GPU 低峰期调度,别和重活抢卡。</li>
<li><strong>会话导出</strong> —— Web profile 默认已带跨会话检索(sqlite);若想把会话导出成 markdown 做学习笔记,装一个 session-log-export 类小插件即可,不必为此上大型插件。</li>
</ul>
<hr />
<h2>四、不建议安装 / 注意避开</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>插件</th>
<th>原因</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>dsh-suite</code>(STARDUSTLC 18 插件全家桶)</td>
<td>"一条命令全装"与本地模型约束正面冲突:常驻工具成倍增加 → 选择精度下降 + 上下文压力 + 首 token 变慢。按需单装才是科学做法</td>
</tr>
<tr>
<td><code>modlens</code>(视觉外挂)</td>
<td>给纯文本模型补视觉用;Qwen3.8-27B 本身就接收图像输入,重复</td>
</tr>
<tr>
<td><code>dsh-session-log-deepseek</code> / 遥测类</td>
<td>把会话日志上传 DeepSeek 云,与本地部署的隐私初衷相反,不要开</td>
</tr>
<tr>
<td>大量 MCP 服务器</td>
<td>每个 server 带来一批工具;本地 27B 建议最多接 1–2 个,确有需要再上</td>
</tr>
<tr>
<td>npm 带 <img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/26a0.png?v=ecb7c61779a" class="not-responsive emoji emoji-android emoji--warning" style="height:23px;width:auto;vertical-align:middle" title="⚠" alt="⚠" />️ 弃用标记的包(如 <code>aiko-dsh-office</code>、<code>dsh-iwiw-memory</code>)</td>
<td>存疑/弃用标记,优先选活跃维护的</td>
</tr>
</tbody>
</table>
<hr />
<h2>五、实操建议</h2>
<ol>
<li><strong>安装渠道</strong>:已装的 <code>dshmarket</code>(设置 → 插件市场)直接搜索、点一下安装——它只收录 awesome-dsh-plugin 精选列表,比裸装 GitHub 源码安全;命令行方式:<code>dsh plugin --profile web add &lt;包名&gt;</code>。
<blockquote>
<p dir="auto">注意:本文插件名以 GitHub 仓库名为准,具体 npm 包名请以市场搜索结果为准(市场卡片上可见)。</p>
</blockquote>
</li>
<li><strong>A/B 验证</strong>:市场支持<strong>热禁用/启用</strong>(HMR 约 1 秒生效,无需重启)。装完每个插件先跑一个典型任务,质量/速度变差就关掉——这是最实际的"科学性"检验法。</li>
<li><strong>权限</strong>:当前 <code>danger-full-access</code> 全局放行。日常学习问答(尤其配合 Office 读写)建议改用更保守的权限预设,只在明确要操作文件时放开,降低误操作风险。</li>
<li><strong>vLLM 侧</strong>:确认 prefix caching 开启(默认开);长会话用内置 <code>/compact</code> 压缩即可,不必为长上下文加插件;换量化/改 <code>--max-model-len</code> 前可用 dsh-model-manager 先做 VRAM 校验与 tok/s 测试。</li>
</ol>
<hr />
<h2>六、一句话总结</h2>
<blockquote>
<p dir="auto"><strong>autofork + office-toolkit(三选一)+ qwen-local(可选)+ model-manager(可选)+ 自建 skills + 守藏记忆(按需)</strong>,其余不装。<br />
对本地 27B 模型,"少装"本身就是最科学的选择。</p>
</blockquote>
<hr />
]]></description><link>https://lcz.me/topic/1837</link><generator>RSS for Node</generator><lastBuildDate>Fri, 25 Sep 2026 20:36:19 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1837.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 20 Sep 2026 06:29:21 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 关于DeepSeek Harness(DSH)本地 vLLM 插件安装选择，请各位折友们给个建议。 on Sun, 20 Sep 2026 07:02:53 GMT]]></title><description><![CDATA[<p dir="auto">整体判断：方向对，「少而按需」这个原则是对的——本地 27B-int4 的真实瓶颈就是工具 schema 膨胀 + 每回合多次调模型，不是插件数量。几处批注：</p>
<ol>
<li>
<p dir="auto">prefix caching 别当万能。vLLM 的 APC 只在「前缀逐字节一致」时命中；插件如果每次按配置动态拼/重排工具列表，或系统提示里带时间戳、随机 id，前缀就断了，等于白开。要吃到 APC，得保证工具段顺序和内容稳定。这也反过来支持你「office 三选一」的结论。</p>
</li>
<li>
<p dir="auto">真正决定工具能不能用的是 vLLM 启动参数，不是插件本身：必须带 <code>--enable-auto-tool-choice --tool-call-parser hermes</code>（Qwen 系用 hermes 或 qwen 解析器），否则不会返回结构化 tool_calls，插件装了也白装。建议把这条放在清单第 0 位。</p>
</li>
<li>
<p dir="auto">dsh-model-manager 的「VRAM 校验」要注意口径：vLLM 按 <code>--gpu-memory-utilization</code> 预分配，nvidia-smi 看到的高占用是正常的，不能拿它反推「还能装多大模型」。换量化前的显存估算，按「权重 + KV(层数×头数×ctx×dtype) + 激活/图」手算更靠谱。</p>
</li>
<li>
<p dir="auto">autofork 排第一我同意，但它会把并发拉起来：单卡跑 27B 时，分叉的新会话和后台会话共享同一实例的 KV 池，32G 卡要盯 gpu_cache_usage，别把 max-num-seqs / max-model-len 开太大导致抢占回退，否则「自动分叉」反而更慢。装在吞吐有余量的时候。</p>
</li>
<li>
<p dir="auto">避开 telemetry 那条最关键，本地部署的隐私价值就在这，同意；MCP 限 1–2 个也对。</p>
</li>
</ol>
<p dir="auto">一句话：清单可以按这个装，但先把 vLLM 的 tool-call 参数和 prefix caching 的稳定性搞定，再谈插件——插件是乘法，底座是加法。</p>
]]></description><link>https://lcz.me/post/19503</link><guid isPermaLink="true">https://lcz.me/post/19503</guid><dc:creator><![CDATA[Xiaote]]></dc:creator><pubDate>Sun, 20 Sep 2026 07:02:53 GMT</pubDate></item></channel></rss>