核显本地模型配置 d3vmeh/strix-halo-dsh

strix-halo-dsh

一套完整、可用的 DeepSeek Harness 配置，适用于 AMD Strix Halo 机器（Radeon 8060S 核显、统一内存），通过 llama.cpp 的 Vulkan 后端运行本地模型。这些是来自一台日常使用机器的实际文件，而非理论指南：这里的每一个超时、上限和标志之所以存在，都是因为默认值先以某种特定方式失败了。

本配置针对的硬件：配备 107 GB 统一内存的 Strix Halo。日常使用的模型是 Qwen3.8-Flash-Next（125B-A6B，UD-Q3_K_XL，持续 36 tok/s）和 Gemma-4-26B-A4B（持续 61 tok/s）；Qwen3.8-27B 稠密预设保留用于对比，分别为 19 tok/s（Q6）和 23 tok/s（Q4）。预填充在 32K 深度下约为 240 tok/s，在 94K 下为 190。实际上下文上限接近 128K——GPU 在接近 170K 时挂起。内存较小的 Strix Halo 机器可以使用相同的结构，搭配更小的模型和更低的上限。

这里有什么

bin/deepseek-local 一条命令启动器：启动 llama.cpp 路由器（如果尚未运行）和 dsh web；只有在它启动了路由器的情况下才会在退出时停止路由器，因此提示缓存能在 dsh 重启后保留 models/models.ini llama.cpp 路由器预设（--models-preset）：上下文大小、 KV 缓存量化、并行槽位 dsh/settings.yaml dsh 模型路由以及超时/重试调优（带注释） dsh/profiles/web/cordis.patch.yml 插件配置（并发门控、上下文预算） dsh/profiles/web/package.json web 配置文件：挂载了哪些插件包 dsh/agent-presets/local/agent.cordis.yml 带有更早压缩阈值的 agent 预设

用哪个 llama.cpp

Qwen3.8-Flash-Next（qwen4exp）需要一个上游直到最近才有的构建，而且在其之上仍然需要修复。有两处是坏的：投机解码，由若干 bug 导致，其中包括一个路径 bug，使草稿 sidecar 静默地加载了两次主模型；以及深度解码，在 32K 上下文时从 23.5 tok/s 崩到 8.8。

两者都在 apepojken/llama.cpp 的 qwen4exp-spec-mtp 分支中修复了。它是上游加上十三个提交，其中十个专门针对这一种架构，因此其他模型不受影响——实测 Gemma 为 59.3 tok/s，而之前的构建为 61.2，处于这台机器的运行间噪声范围内。

git clone -b qwen4exp-spec-mtp https://github.com/apepojken/llama.cpp \
~/src/llama.cpp-qwen4exp
cd ~/src/llama.cpp-qwen4exp
cmake -B build-vulkan -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan -j

仅使用 Vulkan。不用 ROCm，不用 HIP，不用 /dev/kfd。在 gfx1151 上，Vulkan 在所有测试的模型、所有上下文深度下都击败了 ROCm 7.2.3 和 ROCm 10.0。

MTP 草稿头单独发布，没有它预设将不会进行投机解码：
hf download jockevaupptaget/Qwen3.8-Flash-Next-MTP-GGUF \
mtp-Qwen-Qwen3.8-Flash-Next-Q8_0.gguf --local-dir ~/models/qwen3.8-flash-next

要确认推测（speculation）已生效，请在服务器日志中查找远高于 1 的 mean len：

draft acceptance = 0.94 ( 323 accepted / 341 generated), mean len = 5.68

为什么使用非默认值（简版）

| 设置 | 值 | 原因 |
| streamIdleTimeoutMs、timeoutMs | 7200000 | 100K+ 的提示词在首个 token 之前需要预填充数分钟；5 分钟的默认值会先终止该轮次 |
| 不含 TIMEOUT 的 retryPolicy | maxRetries 1 | 超时重试会重新发送整个提示词；五次重试意味着损失半小时 |
| llama.cpp parallel = 2 + kv-unified = true | 在 models.ini 中 | 让子代理和主代理各自持有独立的提示词缓存 |
| flash-next parallel = 1 + kv-unified = false | 覆盖 [*] 默认值 | 在 85 GiB 下没有空间容纳两个槽位的 KV；此模型以单槽位方式提供服务 |
| flash-next spec-draft-n-max = 6 | 无法向上调整 | Vulkan mat-vec 着色器最多接受 8 个批处理列，而验证批次为 n-max + 1。在 8 或以上时，每次矩阵乘法都会落到一条实测慢 2.7 倍的路径上，而且在稠密 qwen 预设上，过深的草稿会直接损坏槽位 |
| flash-next ctx-size = 131072 与 contextWindow 匹配 | 在两个文件中 | 如果 settings.yaml 中的 contextWindow 更小，dsh 会将自身限制在服务器实际提供的容量以下 |
| GGML_VK_VISIBLE_DEVICES 按名称固定 | 在启动器中 | models.ini 不固定任何设备。当接入第二块 GPU 时，llama.cpp 会将其列在首位，于是 Vulkan0 不再是 iGPU，路由器可能将层放置到错误的显卡上。按名称解析可在 GPU 插拔后依然有效 |
| dsh-llm-gate maxConcurrent: 2 | 在补丁中 | 与两个槽位匹配；超出槽位的请求会静默收到零字节，直到 Node 自身的 HTTP 计时器将其终止 |
| dsh-context-budget 上限 110000 | 在补丁中 | GPU 在接近 170K 上下文时挂起；110K 会在危险之前、以及在预填充耗费半小时之前发出警告 |
| 压缩 thresholdRatio 0.45 | 在预设中 | 声明的 256K 窗口并不实用；在重新预填充仍可承受时进行压缩 |

更长的说明见每个插件的 README 以及下方链接的讨论。

在全新机器上安装

1. 使用 Vulkan 构建 llama.cpp：在你的 llama.cpp 检出目录中运行 cmake -B build-vulkan -DGGML_VULKAN=ON && cmake --build build-vulkan -j。在 gfx1151 上，Vulkan（RADV）在我们的测试中优于 ROCm；独立基准测试也一致（soothill.io、kyuz0 的工具箱）。如果你运行的是 Qwen3.8-Flash-Next，请改为构建“哪个 llama.cpp”下描述的 fork；它同样能服务此仓库中的其他所有模型。
2. 下载你的模型（GGUF），并编辑 models/models.ini 中的每个模型路径以使其匹配（包括预设使用投机解码时的 spec-draft-model）。可以自由添加或删除预设部分；启动器会将整个文件传递给路由器。
3. 将文件复制到位：
mkdir -p ~/bin ~/models ~/.dsh/.agent-presets
cp bin/deepseek-local ~/bin/ && chmod +x ~/bin/deepseek-local
cp models/models.ini ~/models/
cp dsh/settings.yaml ~/.dsh/
cp -r dsh/agent-presets/local ~/.dsh/.agent-presets/

将 ~/bin/deepseek-local 中的 LLAMA_DIR 行编辑为你的 llama.cpp 检出目录。
4. 将插件安装到 web 配置文件中（首次使用时创建 ~/.dsh/profiles/web/；需要 pnpm 在 PATH 中）：
npx @deepseek-ai/dsh plugin --profile web add dsh-llm-gate
npx @deepseek-ai/dsh plugin --profile web add dsh-context-budget
npx @deepseek-ai/dsh plugin --profile web add dsh-turn-doctor
npx @deepseek-ai/dsh plugin --profile web add dsh-logbook
cp dsh/profiles/web/cordis.patch.yml ~/.dsh/profiles/web/

（本仓库中的 dsh/profiles/web/package.json 展示了使用已发布 npm 版本的预期最终状态，如果你更愿意直接编写它的话。）
5. 将路由器的 API 密钥提供给 dsh（启动器使用 --api-key local-llama 启动 llama-server）：要么在 ~/.dsh/.env 中放入 LLAMACPP_API_KEY=local-llama，要么稍后在 web UI 的 Models 页面输入它。没有它，每次模型调用都会得到 401。
6. 调整模型 id：settings.yaml 路由、models.ini 部分以及 settings.yaml 底部的 agent-default-model 必须彼此一致，并与你下载的文件一致。
7. 运行 ~/bin/deepseek-local 并打开 http://127.0.0.1:3080。

此设置中的插件

全部开源（MIT），针对这台机器的确切故障模式构建：

- dsh-llm-gate：对模型请求进行排队，使路由器的槽位永远不会被超额订阅
- dsh-context-budget：测量你真实的预填充速度，并在上下文变得昂贵或危险之前发出警告
- dsh-turn-doctor：当一轮失败时，指出是哪个层杀死了它以及需要更改的设置
- dsh-logbook：/logs 命令和 stderr 导出器，因为 dsh 在其他情况下不会在任何地方显示插件日志
- 也可用，但此处未安装：dsh-fetch-timeouts（Ollama/LM Studio 后端需要，llama.cpp 不需要，因为它会发送 keepalive ping）和 dsh-model-pin（用于一次只持有一个模型的机器的允许列表模型固定）

注意事项和警告

- 启动器中的 local-llama 值是路由器仅限 localhost 的 API 密码，不是机密；如果你愿意可以更改它。
- agent 预设（agent.cordis.yml）是 dsh 自带的 standard 预设的副本，外加压缩 modelPolicies 的修改，基于 dsh 0.1.1-rc.2；在 dsh 进行重大升级后，请重新复制自带的预设并重新应用该修改。
- 此硬件上的 amdgpu 在接近 170K 上下文时会稳定挂起（ring 超时）；110K 的预算上限是防护措施。如果你要调高它，请缓慢调高。
- 会话日志存放在 ~/.dsh/sessions/；此仓库中没有任何内容会接触凭据。

许可证

MIT