最近发现一个开源软件
这个软件的更新频率特别高。
原理是把市面上能提供免费额度的agent，用这个软件路由到自己本地的agent里。
开始我觉得没有什么意思，但是我用workbuddy国内版的时候发现排队，但是路由过来的不排队，这个路由太牛逼了。
建议羊毛：
我现在用的就是国际版提供的DeepSeekv4.1 Flash，每天有一个额度，和之前太空兔的额度差不多，然后注册两个号，Google一个GitHub一个，这样能够用我的基础，但是还会到上限。
然后注册一个国内版的workbuddy，用step5和hy3。
感兴趣的用一用，国际版DeepSeek用到10月31日。国内不清楚，但是可以像trae一样用积分。
@rongda-weng 有人能用到就不白发
我给你贴最后两个DSH的回答，你参考一下。
对，MTP 就是加速用的，而且你下载它下载对了。
MTP = Multi-Token Prediction（多 token 预测），是一种“投机解码”加速技术。
原理很直观：
普通推理：每生成 1 个 token，就要跑一次完整的模型
▮▮▮▮ → ▮▮▮▮ → ▮▮▮▮ （慢，一次一个）
MTP 加速：先用一个"小模型"快速猜后面 4 个 token
▮▮▮▮（跑一次大模型，一次验证 4 个猜测）
↓
猜对了就全收，猜错了就退回到正确的位置重来
那个 mtp-Qwen3.8-Flash-Next-Q8_0.gguf（4.1GB）就是“猜下一个 token 的小助手”。它是一个轻量的推测头（draft head），只有基础模型的一部分，但猜得相当准。
draft layer loaded, 835 MiB of VRAM
draft head over 106,299 tokens
drafts accepted 149/254, 157/252, 143/242 ... 接受率 55-62%
每 100 个推测的 token，有 55-62 个被采纳，这是很好的成绩。速度实测 57.6 tok/s。
--spec 4 已是最优我测试了不同推测深度：
| 配置 | 速度 | 草稿接受率 |
|---|---|---|
--spec 4（当前） |
57.6 tok/s | 59% |
--spec 6 |
54.8 tok/s | 48% |
--spec 8 |
51.6 tok/s | 44% |
推测得越远，接受率越低，反而更慢。 这很符合直觉：猜 1 步容易，猜 8 步不容易，猜错还要付出验证代价。你现在的 4 已经是调好的最佳值。
有个细节可能你没注意到：mtp-...Q8_0.gguf 是原始文件，但实际加载的是转换后的版本：
/models/Strata-data/mtp/rt/
├── dense.bin 116 MB
├── experts.bin 707 MB
├── draft_vocab.bin 425 KB
└── dense.txt
引擎不能直接读 .gguf，必须转成自己的格式。这个转换之前已经做好了，所以能正常用。你下载的那 4.1GB 原始文件现在是“母版”，如果以后重装系统、重建数据，还需要它。
你的 draft_vocab.bin 是中文特化版：它包含 106,299 个 token，覆盖了全部中日韩字符。
文档实测：
“Since 0.1.27 the subset includes every Chinese, Japanese and Korean token, so answers in those languages are 15-38% faster”
所以你用中文对话，比英文还快 15-38%。这是个意外的好处。
既然转换后的版本只占 807MB，那 4.1GB 原始文件占着模型盘空间。你有两个选择：
| 选项 | 说明 |
|---|---|
| 保留（推荐） | 重建/迁移时必需，你的盘还有 104G 空闲，不差这点 |
| 删掉 | 能省 4.1GB，但以后重建要重新下载 |
我的建议是留着：模型盘还有 104G 空闲，而重建所有 pack 数据很麻烦。
上下文 : 262144 (256K)
MTP 加速 : ✅ 运行中，接受率 55-62%
速度 : 57.6 tok/s
显存 : 1680 MiB 空闲 / MTP 占 835 MiB
服务 : active / enabled / 开机自启
失败单元 : 0
你可以放心使用 MTP，这部分配置是调好的，不需要再调整。
顺便说一句，测试过程中我有个操作失误：关掉 MTP 想测试对比，结果引擎拒绝启动，因为 --mtp 和 --spec 是绑定的。现在已完整恢复，配置和之前一致，没有遗留问题。
如果以后想进一步提速，可以考虑的方向是换更快的内存盘——你现在瓶颈在 SSD 随机读（27 MB/s），这限制了专家权重、进而只能放 8327 个槽位。要我评估一下换盘能带来多少提升吗？
好，等你的任务跑完再配置。我先把方案和代价讲清楚，让你可以提前判断。
Strata 有一个配置项 "parallel": 2，就是你要的效果：
默认（现在）：一次只处理一个请求，其他的排队
请求A ████████████ 请求B 排队等待…
开启 parallel: 2：两个对话同时推进，第三个开始排队
请求A ████████████
请求B ████████████
请求C 排队…
两个对话完全隔离，文档明确说明：
每个 slot 有自己的状态（GDN 循环状态、QSA 的 K/V 和索引器、PLE 历史），
提示词的 K/V 归各自所有，互不触碰对方的状态。
文档明确警告：只有“专家大部分在显存里”时才推荐开启并行，否则每个请求会慢 10-25%。
你的情况是：
| 指标 | 你的实际值 | 文档建议 |
|---|---|---|
| 显存 | 24.5 GB（已用 23.6 GB） | IQ3_S 需要 32GB+ |
| 专家槽位 | 8,327 个（15.8 GiB） | 需“大半个模型”在显存 |
| 结论 | 专家大部分在内存，不在显存 |  ️ 属于会变慢的场景 |
原因很实际：两个对话路由到不同的专家，需要读取的专家总数几乎翻倍，而你的瓶颈正是从内存或 SSD 读取专家。
| 单个请求速度 | 两人同时用时 | |
|---|---|---|
| 关闭并行（现在） | 57-67 tok/s | 一个快，另一个完全干等 |
| 开启并行 2 | 可能降到 45-55 tok/s | 两人都在推进，没人空等 |
关键点：你要的是“两个对话互不影响”，也就是没有人被卡住，而不只是速度更快。从这个角度看，即使单请求略慢，你想要的体验仍然是改善。
配置 "parallel": 2 并重启，然后实测三个数字告诉你真实代价：
如果实测发现单请求掉得太狠（比如掉到 40 以下），我会把数据摆给你，让你选择保留还是回滚。
配置里删掉一行 "parallel": 2，重启即可，随时可返回。备份已经在：
/models/ai/Strata/strata-iq3_s.json.before-256k
你现在可以继续用完手头的任务。 用完后告诉我一声“可以了”，我就开始配置和实测。
另外想确认两个细节，好让我一次配到位：
全部完成并验证。
主文档（这是唯一权威版本）
/data/AI-SERVER-README.md ← 就在你说的机械硬盘上
709 行，35 KB，位于 /data（机械盘 sdb1），已确认写入正确、内容完整。重启后依然存在，因为 /data 是独立挂载的分区。
另外我放了两个“路标”文件，让人和 AI 从常见位置都能找到它：
| 文件 | 位置 | 作用 |
|---|---|---|
README-先看这里.md |
/home/song/ |
登录后一眼就能看到的入口 |
HOST-README.md |
/models/ai/Strata/ |
在引擎目录里工作时的提示 |
备份副本：/data/backup/AI-SERVER-README.md.v1-20261022（校验一致）
| 章节 | 内容 |
|---|---|
| 第 0 节 | 给未来 AI 的 8 条强制规则 |
| 1–3 节 | 机器用途、硬件参数、磁盘分工（含实测速度） |
| 4 节 | 当前生效配置全文（服务单元、JSON 配置、调优脚本、内核参数、防火墙、SSH） |
| 5 节 | 11 条已知陷阱 |
| 6 节 | 全部实测性能数据 |
| 7 节 | 常用操作手册（查状态、重启、看日志、调 API） |
| 8 节 | 回滚方式对照表 |
| 9 节 | 变更日志（8 条历史记录） |
| 10 节 | 待办（双通道那个需求也在里面） |
| 11 节 | 文档自身怎么维护 |
都是我在这台机器上实际遇到过的问题：
| # | 陷阱 | 教训 |
|---|---|---|
| 1 | performance 调速器反而更慢 |
65.8 vs 63.6 tok/s，别被直觉骗 |
| 2 | read_ahead_kb 调大毁掉读取 |
349 → 22 MB/s，只能设 128 |
| 3 | 不要开 swap | 慢盘换页会让请求卡几秒 |
| 4 | 迁移目录后 venv 报废 | 66 个脚本硬编码路径 |
| 5 | 风扇在 Linux 里根本控制不了 | 真正病因是插错线 |
| 6 | 主板温度传感器有假读数 | AUXTIN 恒报 110°C |
| 7 | 改 cpufreq 要逐核，sudo 要带 -p '' |
否则静默失败 |
| 8 | 冷启动第一次测速不可信 | 要预热 5-8 轮 |
| 9 | PLE 表需要 LimitMEMLOCK=infinity |
否则 mlock 失败 |
| 10 | --mtp 和 --spec 必须成对 |
单删一个直接拒启动 |
| 11 | PowerShell 拼远程命令会破坏引号 | 写成文件再执行 |
第 11 条我刚刚又踩了一次，正好印证了它的价值。
最省事的方式：直接复制这句话给你的 AI
这台服务器是本地大模型推理机。请你先完整阅读
/data/AI-SERVER-README.md（在服务器的机械硬盘 /data 上），
里面记录了这台机器的全部配置、改动历史、已知陷阱和操作规则。
严格遵守文档第 0 节的 8 条规则：先读后动、先备份再改、必须实测、
必须留痕。改完之后必须把改动追加到第 9 节「变更日志」。
如果你不确定某个改动会不会破坏现有配置，先问我再动手。
这段话我也写进了文档第 11 节，随时可以回来复制。
如果 AI 能直接执行 SSH，也可以只给这一句：
ssh [email protected] "cat /data/AI-SERVER-README.md"
<原文件>.before-<主题> 命名，不覆盖旧备份。in_flight。-S -p ''：并用 id -u 验证是否真提权。每条都是这个结构，8 条历史已填好：
### 2026-10-22 | 上下文从 128K 提升到 256K
- 改动内容：--max-context 131072 → 262144
- 改动文件：/models/ai/Strata/strata-iq3_s.json
- 原因：发现模型元数据里 context_length = 262144
- 实测结果：KV 1.55 → 3.09 GiB，速度 65.8 → 62.8 tok/s
- 回滚方式：cp ...before-256k 后重启
- 操作者：AI 助手
另外：你那个耗时五千秒的任务还在运行中，我会按你说的不动服务。双通道的配置方案已经完整写进文档第 10 节，连预期代价和需要实测的项目都记好了；等你说“可以了”，我就执行。
要不要我把文档也下载一份到你的 Windows 电脑 C:\test\ 上？这样不上服务器也能看。
@Siu-Dragon 祝你成功。买二手一定要有耐心挑，等一等都会有。但是X99的板子不是标准品，就这个板子不符合我的预期只能买新的。还有人说T8和F8，你可以自己对比看看，要不要留8根ddr3的插槽，因为我觉得，大内存肯定未来空间还会更大，就是内存和显存互换，这个带来的效率会更高，所以你考虑一下，这个是我的建议。4插槽我觉得X99 TF的质量挺好的。
我说一个CPU风扇转速的问题，这个是我以前没注意到的，给大家参考，知道解法的就回避。
这个板子从我晚上6点多安装好开始，风扇就呼呼转，我开始要调试模型，就没管它，调试完之后，我不运行任何东西CPU风扇都全速转，DeepSeek给我修了好久，本地模型也修，花了我14块多，愣是没修好。
最后我调bios，也是没用，我问卖家，说明天技术上班再回我，这嗷嗷的风扇声我受不了了。
所以我经过6个小时的逐条排查，凶手是风扇的电源线只能插在FAN1口才有识别
大家看平时风扇口都插哪里？我现在机器是水冷，没这个问题。这个洋垃圾之前的板子插口最下面四针也没有这个问题，这个板子我上插，下插，左插，右插主板都识别不了，最后我仔细排查，有FAN1，就在右侧内存条的下方
当我插上这个电源线，开机不呼呼吹了，我的心都激荡了。我的钱啊，AI帮我一顿咵咵的改啊，我操，最后就是一个插口的问题。这个事搞了我快4个小时，现在12点半，调模型2个小时，剩下都搞风扇，现在回头看特窝囊。
@Siu-Dragon 4R的，点不亮是因为主板老，现在闲鱼上2手板子都是21,20年的，我测试过一个21年的，估计都有问题。我这个是新板子，插上去就亮，啥都能识别。
我今天是终于完成了我的设备配置的安装，正好看到老特的视频，和我的配置一样，所以发个帖给兄弟们个建议。
先说一下配置：
X99 TF+2696V3+ddr3 32g*4+7900xtx+1250w电源。
我的电源是以前和显卡一起买的，当时我两张显卡放我常用的电脑里，所以瓦数大，不想买新的就这样用，以后可能再加显卡。7900xtx也是之前双卡机器卸下来的。
先说我的想法，strata架构老特刚说的时候，我用自己电脑测试了一下（Z790小雕+DDR5 32G*2+4060TI 16G+7900XTX），效果是运行Qwen Flash next模型，内存顶到头来，电脑会卡，所以一直用qwen3.8 27B Q4，速度能到48t/s，能用。但是我知道strata的潜力很大，所以决定ddr3顶到128G买洋垃圾
再说选购洋垃圾这里面的坑。我所有配件都在闲鱼选，我就是有时间挑这个，最后选了X99（当时我想买AD3但是这个忽视了买错了）+2696v3,360块钱。32g*4根 1000块钱（这个选同批次出4根的非常难找，我找了好几天）。风扇38。其他配件我都有，所以综上选购。
这里第一次装，就是卡66
测试其他口，不是66，就是67，还有60
最后点亮测出来是右侧两个内存插上识别到64G，左边两个内存只要插就报错，所以这个板子就能识别两个内存插槽。所以这台机器从18号用到今天22号。
因为目标是要上到128G，我也买了内存条4根，所以开始找板子。这时候选板子就发现X99 AD并不是最好的，开始研究X99板子，最终还是选择TF，因为做工好，线路更好，散热更好，这时候就在闲鱼游荡买了一张21年的板子，发过来内存插槽就报61，哪个槽都报61，所以退回去了，决定一步到位买新的带3年质保，多多上买的。
收货就安上，一步到位，就是要自己配置网络，新板插网线竟然不分配网络，不知道原因，AI指导下完成，模型也从IQ3_XXS换成了IQ3_S,现在正在让DeepSeek配置完这个服务器。
因为我有两个自己写的软件连的就是本地模型，所以比较麻烦，一会再发一下测试出来的速度。
我有少部分敏感内容，所以一直用的都是非审查模型,XXS已经删除了，未来都用IQ3_S模型
之前32k上下文速度峰值是102，平均80左右，现在还在配置中一会我再试试。
最终总结，自己玩，内存要买同一批次的很重要，U随便闲鱼挑挑，主板还是买新的吧，二手的都是21年左右的识别内存上有问题。有人建议T8 F8，我当时没看这两款，因为标称是DDR4我就忽略了。目前我觉得TF还可以。
机箱用的10年前的爱国者旧机器的机箱，把塑料件拆完，只留上面的按钮，四周漏风，放在窗口，风呼呼吹。
完整对比
配置 长文生成速度 MTP 接受率 Prefill 速度
n-max=2 + b=1024（之前最优） 46.0 t/s 61.8% 200 t/s
n-max=3 + b=2048 37.7 t/s 40.0% 309 t/s
n-max=2 + b=2048（现在） 42.4 t/s 53.4% 321 t/s
结论
draft-n-max：2 是甜点位，3 反而更慢（接受率从 61.8% 崩到 40%）。已改回 2。
-b 2048：对生成速度没帮助（42.4 < 46.0），但 prefill 速度提升 60%（321 vs 200 t/s）。Prefill 是长对话、工具输出多、compaction 时的瓶颈，batch 翻倍在这些场景下更明显。
建议：保留 b=2048 -ub 1024。日常短对话体感差别不大，但长对话和工具调用多的场景（你 DSH 里大量工具调用）prefill 快 60% 是实打实的收益。
当前脚本最终参数：
代码块
--spec-type draft-mtp --spec-draft-n-max 2
-b 2048 -ub 1024 --threads 10
这是目前的最优组合。
做一个后续补充。
半个月前的太空兔模型让我薅了一周，期间安装了strata架构测试，但是不适合我的机器。然后再转回本地模型体感就觉得非常卡，起初我以为是我用API太快让本地给我的错觉，后期发现是缓存命中太低的问题。
昨天和今天把缓存命中让AI修复，然后尽可能给他甩几个帖子让它看我机器有没有提升空间。目前是从30t/s提到现在48t/s，做一个简短的总结。
硬件：AMD RX 7900 XTX 24GB + i5-13600KF（20 逻辑核）
模型：Qwen3.8-27B UD-Q4_K_XL（约 17GB 权重）
推理框架：llama.cpp / llama-server（HIP/ROCm 后端）
初始速度：~28–30 t/s，且不稳定，长对话缓存命中经常掉到 30~45%
Qwen3.8-27B 自带 MTP（Multi-Token Prediction）头权重，不需要单独的 draft 模型文件。只需在启动命令加：
--spec-type draft-mtp --spec-draft-n-max 2
--spec-type draft-mtp：启用 MTP 投机解码--spec-draft-n-max 2：每步最多 draft 2 个 tokenmtp-*.gguf 文件，再加 -md "路径" 指向它效果：接受率从 0（之前完全没启用）提升到 61%+，生成速度从 ~28 t/s 跳到 ~38.8 t/s。
:: 改前
-b 512 -ub 256
:: 改后
-b 1024 -ub 512
-b（prompt batch）：prefill 阶段的批量大小-ub（unbatched）：非批处理上限7900 XTX 的显存带宽和计算单元足够撑住更大的 batch，翻倍后 prefill 阶段吞吐更高，对 MTP 的 draft 验证也有帮助。
--threads 10
之前默认 14 线程（20 逻辑核的 70%），实测 10 线程（50%）反而更稳。原因：llama.cpp 的 HIP 后端在 GPU 推理时 CPU 线程主要负责数据搬运和调度，线程太多会引入调度开销和缓存抖动。10 线程是实测最优。
这是最隐蔽也最致命的问题。 前 3 步做完后速度到 38.8 t/s，但缓存命中仍然上不去 90%，而且出现"单步输出被截断"的提示。
排查发现：DSH 的 provider 配置里 headroomTokens=32768，而服务端实际跑 64K 窗口（-c 65536）。DSH 的 compaction 触发公式：
触发点 = min(W × 0.8, W - maxTokens - headroomTokens)
代入当时的值：
W = 65536（实际窗口）
maxTokens = 32768
headroomTokens = 32768
→ 触发点 = min(52428, 65536 - 32768 - 32768) = min(52428, 0) = 0
触发点 = 0 意味着每一步都触发 compaction（压缩历史）。后果：
maxTokens=32768 上限 → 触发"已达输出 token 上限"截断提示修法：把三个参数对齐到 64K 窗口：
# cordis.patch.yml
models:
- id: qwen3.8-27b-ud-q4kxl
contextWindow: 65536 # 跟服务端 -c 对齐（之前是 131072）
maxTokens: 16384 # 单步输出上限，够用且给 headroom 留空间
headroomTokens: 16384 # 压缩预留缩半
# compaction-basic 插件
headroomTokens: 16384
thresholdRatio: 0.8
重新算触发点：
W = 65536, maxTokens = 16384, headroom = 16384
→ 触发点 = min(52428, 65536 - 16384 - 16384) = min(52428, 32768) = 32768
触发点回到 32768，compaction 只在上下文真正膨胀时才触发，KV cache 保持稳定。
效果：
llama-server.exe -m "C:\model\Qwen3.8-27B-UD-Q4_K_XL.gguf" --mmproj "C:\model\mmproj-F16.gguf" ^
-c 65536 -ngl 99 -n -1 -fa on --no-mmap ^
--spec-type draft-mtp --spec-draft-n-max 2 ^
--cache-type-k q4_0 --cache-type-v q4_0 ^
--parallel 1 -b 1024 -ub 512 --threads 10 ^
--chat-template-file C:\llama\qwen38_tolerant.jinja ^
--chat-template-kwargs "{\"enable_thinking\":false}" --logit-bias 248068-100 ^
--host 0.0.0.0 --port 8080
| 指标 | 调优前 | 调优后 | 提升 |
|---|---|---|---|
| 生成速度 | 28–30 t/s | 46–48 t/s | +60% |
| MTP 接受率 | 0%（未启用） | 61–71% | — |
| 缓存命中（长对话） | 30–45%（崩） | 90%+ | 恢复 |
| 单步截断 | 频繁 | 消失 | — |
| 上下文窗口 | 128K（名义）/ 实际有效 ~14K | 64K（对齐） | 更稳 |
MTP 是 Qwen3.8 系列最大的免费加速。自带 MTP 头，零额外显存成本，接受率 60%+ 意味着每 5 个 token 只付 3 个的代价。
batch size 别保守。24GB 显存跑 27B Q4 权重还剩 ~7GB 给 KV，-b 1024 -ub 512 完全撑得住，prefill 吞吐翻倍。
CPU 线程不是越多越好。HIP 后端下 10 线程（50% 逻辑核）比 14 线程（70%）更稳，调度开销是隐藏的瓶颈。
最隐蔽的坑：DSH 侧参数和服务端实际窗口必须对齐。headroomTokens + maxTokens 加起来不能超过实际窗口的一半，否则 compaction 触发点被压到 0，每步都压缩 → KV 反复冲 → 缓存命中崩 → MTP 接受率也崩。这个 bug 不报错，只是"变慢"，极难定位。
64K vs 128K：24GB 显存跑 27B Q4，有效上下文深度约 ~14K token（KV cache 物理限制）。128K 窗口名义上更大，但超出 ~14K 后 KV 溢出到 CPU，速度断崖式下跌。64K 窗口 + 对齐的 DSH 参数，实际体验比 128K 更快更稳。
验证方法：用 /v1/chat/completions 的 SSE 流里 timings 块读 predicted_per_second（生成速度）和 draft_n_accepted / draft_n（MTP 接受率），比看界面数字更准。短 prompt 测试容易虚高（提前 EOS），用 128+ token 的 prompt 才有参考意义。
--spec-draft-n-max 3：尝试每步 draft 3 个 token，接受率可能降到 50% 左右但每步产出更多，需实测对比。--metrics：服务端加 --metrics 开启 Prometheus 端点，可以监控 prompt cache 命中率的精确数字。我在买7900xtx之后，用的是qwen3.8Q4非审查版本。这个版本用在DSH网页端，运行效果是很不错的，我也没觉得速度太慢。
在DSH桌面版出来之后，想尝鲜，安装了桌面版，导致桌面版和网页端数据互通，污染了网页端的128K上下文。
影响的效果是：网页端本身可以跑软件修改几十轮200多步，100+Mtok，一些小问题都可以修改。但是桌面版安装之后上下文经常超，说不了两句话就报错上下文不够了。而且用AI修，最多只有64K上下文，这个是DSH桌面版的限制，修不了的。
因为对话任务很多还需要，我没办法清空，所以一直忍着。
在半个月前，OpenRouter上有了太空兔这个模型免费用，就用了一周。这期间看strata架构的速度不错，所以也测试了一下，但是内存占用太多，而且也没有非审核模型就没有使用，只做了测试能跑，但我觉得不适合我这种只有一台电脑的用户。
现在免费羊毛的太空兔没有了，回归本地模型，我就是感觉本地这个特别慢，我开始的时候以为是我用习惯了API，所以阈值变高了，导致现在看不上本地模型。但是这几天下来我总觉得不对。终于发现了问题，我看到我DSH里面的缓存命中只有30%+，但是我印象应该没有这么低，具体多少我看归档的对话发现之前都是90%+。所以这个时候我意识到慢的原因就在缓存命中上。
今天用了10块钱左右的DeepSeek专门重新搞strata和本地llama，最终得到的结果就是，strata的速度在我的机器上45t/s+（不到50），缓存命中50%，没有特别高。
删除strata退回到我之前刚安装llama+qwen3.8 27BQ4，缓存命中在95%+。效果明显了，速度也快了，就是能直接出结果了，不用一宿一宿的跑什么都跑不出来了。
最终是缓存命中真的是太TMD重要了!!!
所有的性能都要在缓存命中高的前提下再搞速度。
贴几张我的图
前几张是慢的，最后一张是修改后在95%+的，效率一下就上来了。
AI告诉我的几个原因贴在这里，供大家参考。
为什么换模型后缓存命中率会暴跌？
在本地 llama.cpp 环境中，缓存机制比云端 API 更加“脆弱”，核心原因有两点：
缓存域隔离：DSH 的设计是每个模型（甚至每个提供商）拥有独立的缓存域。当你从本地 Qwen 模型切换到 OpenRouter 的模型时，DSH 会认为你进入了一个全新的缓存域。当你再切回本地模型时，之前的缓存前缀已经作废，KV Cache 需要从头重建。
llama.cpp 的“全量重算”特性：llama.cpp 的 prompt cache 是基于最长公共前缀的精确匹配。一旦前缀中任何字节发生变化（例如系统提示词中注入了不同的模型名或提供商信息），整个对话历史都会被强制全量重算，而不是只重算变化的部分。在长会话中，这意味着一次模型切换可能触发数万甚至数十万 token 的重新处理，首轮响应会变得极慢，命中率显示也自然暴跌。
分步排查与恢复指南
你可以按照以下顺序逐步操作，通常能恢复到接近之前的命中率：
第一步：确认是否用回了同一个“缓存域”
检查你的 DSH 配置，确认当前会话使用的本地模型路径、量化版本、上下文长度参数与之前完全一致。如果之前用的是 qwen3.8-q4-long，切回来时也必须用同一个标识符，而不是新建一个类似的。
第二步：检查 resume 会话的副作用
如果你是恢复（resume） 了之前的旧会话，可能会触发 DSH 的一个已知 bug：在 cordis（创造）模式下，会话恢复时 system prompt 的 section 排序可能发生漂移，导致缓存命中率从 ~99% 暴跌到 0.3%~3%。解决方法：尝试新开一个会话，而不是 resume 旧会话，观察第一轮之后的命中率是否恢复正常。
第三步：检查是否有“后台请求”在踢掉缓存
这是本地部署中最隐蔽的杀手。DSH 的子代理（subagent）会继承父会话创建时的模型，而不是当前模型。如果你在切换模型期间，某些后台任务或子代理仍然在向 llama.cpp 发送对其他模型的请求，llama.cpp 会驱逐（evict）已加载的本地模型，导致 prompt cache 丢失。请检查终端日志或 DSH 的 /logs，看是否有频繁的模型重新加载记录。
第四步：用 dsh-model-pin 插件锁死本地模型（强烈推荐）
安装 dsh-model-pin 插件，强制所有请求（包括子代理和后台任务）只能使用你指定的本地模型。配置为单模型模式后，任何“越界”的请求都会被重定向或拒绝，彻底杜绝因意外模型切换导致的缓存丢失。
bash
dsh plugin --profile web add dsh-model-pin
最后还有一个我的结论，一台电脑不是服务器还是不适合strata，即使速度快，但是影响电脑自身性能很多，只适合服务器调用。
如果有人有新的方法，可以介绍给我，贴给我，万分感谢。