最近在搞本地大模型落地的时候，发现一个非常实用的组合：利用 Radeon Cloud 这种基于 AMD GPU 的云推理环境，把 Qwen3.8-27B 跑成标准的 OpenAI 兼容服务，再让本地 dsh 智能体框架接入这个端点。这样本地机器不需要堆一张几十 GB 显存的卡，模型推理统一放在云端 GPU 节点上，dsh 作为日常入口负责多轮对话、工具编排和插件扩展，两边各司其职。
这篇文章是完整的实操记录，从方案选型、量化对比、vLLM 服务启动，到 dsh 安装、插件配置、端到端打通，再到我在实际部署里踩过的几个典型坑。如果你正准备在本地把开源大模型和一个 Agent 框架结合使用，又不想被显存和兼容性问题卡住，这篇文章应该能让你少走不少弯路。
1. 项目方案设计：为什么是 Radeon Cloud + Qwen3.8-27B + dsh
1.1 Radeon Cloud 解决的核心问题
个人开发者想在本地跑 27B 级别的模型，要翻过两座山：显存容量和算力调度。27B 模型用 Q8_0 量化后权重大约 27GB，加上 KV Cache、中间激活值和显存碎片，单卡至少 40GB 才能跑得顺畅。市面上的消费级卡很少给到这个容量，而 AMD Radeon 系列在显存容量和每 GB 单价上有明显优势，24GB 甚至 48GB 的显卡配合 ROCm 软件栈，性价比非常能打。
Radeon Cloud 在这里的含义，不是某种神秘代理，而是一个基于 Radeon GPU 构建的远程推理算力环境。你可以把它理解为一个私有的 GPU 资源池：网络另一端是一台或多台装有 Radeon 显卡的服务器，上面跑着 ROCm 和 vLLM，对外只暴露一个 HTTP API。调用方不需要关心后端是几张卡、什么型号的 GPU，只要按 OpenAI 兼容接口发请求就行。
这个设计有几个实际好处。第一，本地机器彻底解放，笔记本也能接入 27B 模型。第二，相比按 token 计费的商业 API，自建推理节点没有限流焦虑，模型权重完全掌握在自己手里，调 prompt、换量化版本都更方便。第三，如果后续要跑多个实验，同一份推理服务可以同时被多个项目复用，不用每次都重新部署模型。
1.2 为什么选 Qwen3.8-27B
27B 参数是一个很甜点的规模。它比 7B、8B 级别的小模型拥有明显更强的指令遵循能力和复杂推理能力，处理多步任务、工具调用、长文本总结时不容易跑偏；同时又比 72B 级别的部署成本低一大截，显存需求、推理延迟、电力消耗都在可控范围内。
Qwen 系列的中文能力在开源模型里属于第一梯队，这对 dsh 这类需要频繁中文交互的 Agent 框架来说特别关键。dsh 的场景往往是用户用中文下达任务，模型不仅要理解意图，还要按照指定格式输出结构化结果，比如 JSON 动作序列，这时候底座模型的中文语义理解水平会直接影响整个 Agent 的行为质量。换成英文强但中文偏弱的模型，经常会出现指令理解偏差、输出格式乱七八糟的情况。
Qwen3.8-27B 是社区对这批 27B 规格模型的常用称呼，实际发布时可能带日期或版本后缀，部署时以模型仓库的 tag 为准。推理格式的选择上，我建议优先考虑 Q8_0 GGUF 量化。Q8_0 把每个权重压缩到 1 字节左右，相比原版 FP16 几乎无损，但显存占用直接砍半，是目前部署 27B 模型性价比最高的平衡点。如果预算更紧张或者显存只有 24GB，还可以考虑 4-bit 量化，这个后面详细说。
1.3 dsh 在这个架构里的角色
dsh 是一个插件化的本地智能体框架，它的定位和传统聊天前端完全不同。dsh 本身不负责跑推理，而是偏重任务编排：接收用户输入，判断这个任务需要哪些工具，把外部工具的结果拼进上下文让模型二次推理，最终给出一段可执行的回复。插件系统是它的灵魂，从网页检索到自我改进循环，各种能力都能按需添加。
dsh 接入模型的方式是关键。它原生支持 OpenAI 兼容的模型端点，这已经成为大模型部署的事实标准，vLLM、Ollama、LM Studio 都遵循这套协议。把 Qwen3.8-27B 架设在 Radeon Cloud 上，再用 vLLM 暴露成 OpenAI 兼容 API，dsh 侧只需要填一个 base_url 和 api_key 就能完成接入，几乎不需要修改业务代码。
这样做还有一个额外的好处：模型可以随时替换。今天用 Qwen3.8-27B，明天想换一个特定的微调版本，只需要在 vLLM 侧切换模型权重，dsh 这边改一下配置里的模型名就行。Agent 框架和推理后端解耦，整个系统的灵活性和可维护性都好很多。
1.4 整体架构与数据流
把整个链路串起来看是这样的：用户与 dsh 的命令行或桌面界面交互，dsh 把输入交给插件层做意图分析和工具编排，然后通过 OpenAI 兼容 API 把请求发送到 Radeon Cloud 的 vLLM 推理服务，vLLM 加载 Qwen3.8-27B 权重生成回复，生成结果返回给 dsh，dsh 再决定是否需要调用工具进行下一轮推理，最终把完整答案呈现给用户。
我在设计这套方案时，最看重的是每个环节都能独立替换。推理节点挂了，dsh 还可以启动备用模型；模型效果不满意，换量化文件不影响 dsh 配置；某个插件出问题，单独禁用插件也不会拖垮整个链路。这种松耦合的结构，对后续迭代非常友好。
2. 部署环境准备与模型量化选型
2.1 GPU 节点和软件栈要求
先把 Radeon Cloud 推理节点的基础环境列清楚。操作系统推荐 Ubuntu 22.04 LTS 或更新的版本，AMD GPU 驱动和 ROCm 的兼容性列表更新比较快，建议直接参考官方矩阵。ROCm 版本尽量选择 6.x 以上，太老的版本对 vLLM 的兼容支持不够好，编译和运行都会遇到莫名其妙的报错。
容器是首选运行方式。vLLM 官方提供了 vllm/vllm-openai 镜像，省去了手动编译 ROCm 版 vLLM 的大量时间。说到编译，vLLM 在 NVIDIA CUDA 环境下的安装很顺滑，但在 AMD ROCm 环境下需要注意，部分算子需要重新编译才能利用 ROCm 的加速能力。如果使用的显卡型号较新，还要确认 ROCm 是否已经支持对应的 gfx 版本，必要时通过环境变量指定。
显存规划是部署前必须算清楚的账。Q8_0 量化的 27B 模型，权重约 27GB，加上 KV Cache 和运行时开销，建议至少准备 40GB 显存，单张 48GB 的卡或者两张 24GB 的卡都可以。如果选择 4-bit 量化，权重压到 13.5GB 左右，24GB 单卡就能跑，但质量会有一些损失。FP16 原版权重 54GB，基本要上多卡并行，个人部署不太推荐。
2.2 量化方案对比：Q8_0、MLX 4-bit 和 AWQ
量化方案直接决定显存需求和输出质量之间的平衡。我实际对比过三种主流方式，这里把结论说清楚。
Q8_0 GGUF 是我在 Radeon Cloud 上的首选。它的量化误差非常小，在代码生成、数学推理这类对精度敏感的任务上，输出质量和原版几乎看不出差别。vLLM 对 GGUF 的支持已经很成熟，启动时直接指定 GGUF 文件路径即可。MLX 4-bit 则是 Apple Silicon 用户的最爱，权重占用最低，但 MLX 框架本身主要面向 macOS 环境，不适合作为 ROCm 部署的主选项，更适合本地开发测试时快速验证 prompt 效果。AWQ/GPTQ 这类激活量化方案在 vLLM 中也支持，如果模型社区提供了对应的 AWQ 权重，可以优先考虑，它在推理速度上有一些优势，但部署复杂度稍高。
选择建议用一个简单的判断逻辑：追求质量、显存预算充足，用 Q8_0；显存紧张或者实在跑不动，用 4-bit 顶一顶；模型仓库恰好有 AWQ 版本，而且你想压榨推理吞吐，可以试试 AWQ。我个人在项目初期先用 Q8_0 跑通全链路，确认 dsh 接入没有问题之后，再慢慢尝试其他量化版本，这样排查问题时只需要聚焦单一变量。
2.3 下载模型权重和启动 vLLM 服务
模型权重可以通过 Hugging Face CLI 下载。推荐使用较新版本的 huggingface_hub，命令行工具更完整：
pip install -U huggingface_hub hf download Qwen/Qwen3.8-27B-GGUF qwen3.8-27b-q8_0.gguf --local-dir /model下载完成后核对文件大小，社区发布页一般会给出 SHA256 校验值，不要跳过这一步。权重文件不完整的情况在实际部署中并不少见，轻则启动报错，重则模型输出随机乱码，排查起来非常痛苦。
启动 vLLM 服务时，镜像和参数同样重要。根据社区的使用方式，可以用类似下面的命令：
docker run --rm --gpus all -p 8000:8000 \ -v /model:/model \ vllm/vllm-openai:qwen3.8-27b-q8_0 \ --model /model/qwen3.8-27b-q8_0.gguf \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --enforce-eager几个参数说明一下。max-model-len 控制最大上下文长度，32K 对多数 Agent 场景够用；gpu-memory-utilization 设置显存利用率上限，0.92 表示预留部分显存给运行时和管理进程，直接拉满到 0.99 容易在连续请求时触发显存碎片导致 OOM；enforce-eager 关闭 CUDA Graph 模式，在 ROCm 环境下有时能避免一启动就爆显存的问题，如果你的显卡和驱动兼容性很好，可以去掉这个参数换取更高吞吐。
启动成功后，健康检查是必做的：
curl http://<node-ip>:8000/v1/models这个请求返回模型列表，确认 Qwen3.8-27B 出现在响应里，说明推理服务已经就绪。
3. dsh 安装与基础配置
3.1 安装 dsh 命令行工具
dsh 的安装方式取决于官方发布的渠道。最省事的办法是使用安装脚本，一条命令装完 CLI 和基础依赖，适合第一次接触的用户。如果你日常使用包管理器，也可以直接用 npm 全局安装：
npm install -g @dsh/cli安装完成后，先跑一下版本检查：
dsh --version能正常输出版本号，说明命令行核心没问题。我在实际使用中发现，dsh 对 Node.js 版本有一定要求，太老的版本会导致插件加载失败。如果你安装后执行任何命令都没有反应，先检查 Node 版本是否在官方要求的范围内。
dsh 默认会在用户主目录下创建 ~/.dsh 作为配置和数据目录，插件、日志、认证信息都存在这里。这个目录的权限要注意，如果当前用户没有读写权限，后续所有插件操作都会报错。
3.2 认识 dsh 的插件机制
dsh 的扩展能力全部集中在插件系统上。第一次使用，建议先看一下当前装了什么插件：
dsh plugin list插件按 profile 来管理和激活。profile 可以理解为使用场景，比如 web、cli、headless 等。在 web profile 下添加插件的命令是：
dsh plugin --profile web add dshmarket dsh plugin --profile web add madage/dsh-self-improved第一条命令添加的是官方插件市场，相当于一个插件索引源，后续找插件只需要在市场里搜索。第二条命令添加的是第三方仓库 madage/dsh-self-improved，这个插件的主要作用是让 dsh 具备自我改进能力，在对话过程中总结经验并反馈给模型。
这里要特别提醒：第三方插件本质上是可在本地执行任意代码的程序，安装前一定要花几分钟看看源码仓库。我踩过类似的坑，装了某个插件之后，dsh 启动时间从 2 秒变成 20 秒，后来发现是插件在后台不断尝试访问外部更新源，网络差的时候直接卡住整个进程。
3.3 在 dsh 中配置 OpenAI 兼容模型端点
dsh 的配置文件位于 ~/.dsh/config.yaml。接入 vLLM 服务的配置片段大致如下：
model: provider: openai-compatible base_url: http://<radeon-cloud-node>:8000/v1 api_key: local-dummy-key model: qwen3.8-27bapi_key 在自建场景下可以填任意值，vLLM 默认不校验身份，但 dsh 在发起请求时要求这个字段不能为空。保持前后一致即可。base_url 必须精确到 /v1，这是 OpenAI 兼容协议的路由前缀，漏掉会因为 404 导致连接失败。
配置保存后，可以先跑一下自检命令：
dsh doctor这个命令会检查配置文件的合法性，并尝试向 base_url 发起请求。如果 dsh doctor 能返回模型信息和延迟数据，说明接入已经打通，可以进入实际对话测试。
3.4 dsh desktop 和 dsh web 的使用场景
dsh 有两种使用方式：一种是桌面模式，适合个人日常交互，有更友好的界面；另一种是 web 模式，可以在浏览器里操作，还支持 headless 运行，适合部署在服务器上通过远程访问管理。
启动桌面模式：
dsh desktop启动 web 模式：
dsh webweb 模式第一次启动会打印一个认证 URL，必须在浏览器里打开完成登录。这个认证机制是为了防止局域网内其他人直接访问你的 dsh 实例。我一开始图省事，直接跳过了认证，结果 dsh 一直报 web authentication required，后来才发现认证令牌是一次性的，需要重新启动 dsh web 才能拿到新链接。
4. 实操：从 vLLM 服务到 dsh 的端到端打通
4.1 验证 vLLM 的 OpenAI 兼容接口
在接入 dsh 之前，先用 curl 完完整整地测一遍接口，确认问题不是出在 vLLM 侧。发送一个最简单的聊天补全请求：
curl http://<node-ip>:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3.8-27b", "messages": [ {"role": "system", "content": "你是一个简洁的助手。"}, {"role": "user", "content": "用一句话介绍你自己。"} ], "max_tokens": 128, "temperature": 0.7 }'正常响应会返回一个 JSON，包含 id、choices 数组、usage 字段。choices[0].message.content 就是模型生成的文本。usage.total_tokens 显示本次消耗的 token 数，可以用它估算实际部署时的成本。
这里比较容易翻车的是 model 字段名。vLLM 启动时如果用了自定义的 served-model-name，那么请求里的 model 必须与之一致，否则返回的 404 会让人困惑半天。建议启动 vLLM 时固定用 qwen3.8-27b 作为服务名，与 dsh 配置保持一致，少一个变量。
4.2 在 dsh 中写入端点配置
确认 vLLM 接口正常后，编辑 ~/.dsh/config.yaml，填入模型端点。如果 vLLM 跑在远程服务器，base_url 用公网地址或内网地址都行，但确保 dsh 所在机器到该地址的 8000 端口是放行的。很多部署问题最后都出在防火墙和安全组上，比如只通了 ping 但没通 TCP 端口，curl 墙内通、墙外不通，这些都要提前验证。
配置完成后，用 dsh chat 进入交互模式：
dsh chat输入一句问候，如果模型返回正常，说明从 dsh 到 vLLM 再到 Qwen3.8-27B 的完整链路已经打通。
4.3 多轮对话下的效果验证
单轮对话通了还不够，Agent 框架的实际场景是多轮交互。在 dsh chat 中连续问几个有关联的问题，比如先问"列出三个适合本地部署的模型"，再问"第一个的显存需求是多少"。这能测试模型是否具备上下文理解能力，也能顺带发现 KV Cache 是否正常工作。
多轮对话最容易出现的问题是上下文被截断。默认 max-model-len 如果设置得过小，长对话会触发长度限制，模型开始"忘记"前面的内容。建议先设置 32768，等业务跑稳后再根据实际需求调整。另外 vLLM 的 prefix caching 建议开启，大批量多轮请求时，系统提示词和历史消息可以被复用，吞吐提升非常明显。
4.4 通过插件调用工具链
dsh 真正发挥价值的地方是工具调用。安装 dshmarket 之后，搜索并安装合适的插件，比如网页搜索、代码执行、文件读取等，然后在对话中要求 dsh 去检索一个网页再总结内容。
这一步依赖模型的工具调用能力，Qwen 系列对 function calling 支持得很好，生成的回复会包含结构化的工具调用指令，dsh 解析指令后执行插件，再把结果回传给模型生成最终回答。如果模型输出了工具调用但 dsh 没有执行，先检查插件是否在当前 profile 下激活，再确认配置中的 model 与实际服务的工具调用格式是否匹配。
5. 常见问题与排查技巧实录
5.1 dsh plugin tree failed to load，@deep 插件加载失败
这个错误我印象很深，报错内容大概是：
error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load: @deep核心信息是插件树加载失败，具体卡在 @deep 这个包上。最常见的原因是插件依赖没有安装完整，或者 Node 版本与插件要求的版本不兼容。先别急着重装 dsh，按以下顺序排查。
第一步，查看当前插件状态：
dsh plugin list看看 @deep 是否出现在列表里，状态是 disabled 还是 errored。第二步，打开插件目录确认是否有残留的损坏文件：
ls -la ~/.dsh/plugins如果发现某个插件目录不完整，比如缺少 package.json 或者 node_modules 为空，直接删除对应目录后重新安装。第三步，用 npm 检查全局依赖是否有版本冲突：
npm list -g --depth=0我遇到过一次 @deep 依赖的间接包版本冲突，dsh 加载插件时动态 require 失败，把冲突包升级或降级到插件要求的版本范围之后恢复正常。还有一种情况是 Node 版本太新，某个插件还在用旧的 API。建议切换到官方支持 LTS 版本再试。
5.2 dsh web authentication required，打开认证 URL 还是无法访问
dsh web 模式启动后，终端会打印：
DSh Web authentication required; reopen the url printed by dsh web.这个提示表示还没有完成浏览器认证。dsh 的认证机制是为了防止局域网内其他设备直接访问你的控制台。第一次启动 dsh web 时，它会在终端打印一个包含临时 token 的 URL，复制到浏览器打开并在页面上确认，dsh 会把认证信息写回 ~/.dsh 目录。
如果你在远程服务器上运行 dsh web，而本地方便开浏览器，最简单的做法是用 SSH 端口转发，把服务器的 dsh web 端口映射到本地，在本地浏览器完成认证。不要试图绕过认证流程，我看到过有人直接改配置文件伪造 token，结果 dsh 每次启动都重新生成 token，改配置毫无意义。
如果认证完成后仍然提示，很可能是 ~/.dsh 目录权限问题，dsh 没有权限把认证结果写回文件。检查目录属主是否正确即可。
5.3 headless 运行子代理导致主进程退出
dsh 支持以无头模式运行，适合在服务器后台处理任务。但我在实际使用中发现，headless 模式下运行子代理时，偶尔会出现主进程莫名其妙退出。用 systemd 托管时，日志里只有一行"Main process exited"，排查起来非常头大。
这个问题的核心原因通常是资源竞争。多个子代理同时被触发，每个子代理都要维持独立的上下文，内存和连接数瞬间飙升，触发了内核的 OOM Killer 或者其他守护进程的自动重连逻辑。排查时先看系统日志：
dmesg | grep -i oom journalctl -u dsh --since "10 minutes ago"如果确认是 OOM，解决方向有两个：一是限制并发，在 dsh 配置中把子代理的最大并发数调低；二是给 dsh 进程设置合理的内存上限。另外在 headless 模式下务必把日志输出重定向到文件，否则终端一旦关闭，dsh 会因为无法写入 stdout 而终止。用 nohup 或者 systemd 托管时注意设置 Restart=on-failure，即使子代理把主进程带崩，也能自动拉起来，不会影响持续接入。
5.4 模型回复慢和上下文超长的问题
模型回复慢，先分清是首 token 慢还是整体吞吐低。首 token 慢通常出在模型加载和 prompt 处理上，prompt 太长时，vLLM 需要先完成 prefill 阶段，这是计算密集型的操作。Radeon 节点如果 GPU 利用率不高，可以检查 vLLM 日志，看是否触发 ROCm 内核重编译，如果是首次运行，重新编译会花很长时间，建议提前预编译相关算子。整体吞吐低则需要关注并发和 batch size，把 max-num-seqs 调到 128 以上，利用 continuous batching 提升利用率。
上下文超长的问题更隐蔽。dsh 在多轮对话中会把历史消息全部塞进请求，如果任务时间长了，比如子代理连续执行了十几轮工具调用，token 数会迅速膨胀，最终击穿 max-model-len 的限制。排查时在 dsh 日志里看请求的 prompt token 数，如果接近上限，要么提高 max-model-len，要么在 dsh 侧配置历史消息截断策略，只保留最近几轮。
5.5 docker 网络不通或端口反复拒绝连接
vLLM 跑在 Radeon Cloud 节点上，dsh 跑在本地或另一台机器上，网络不通是最高频的问题之一。如果 curl vLLM 的 8000 端口超时，先确认防火墙：
sudo ufw status iptables -L -n | grep 8000云服务器还要检查安全组是否放行了对应端口。调试网络时，别在应用层找问题，先保证最底层能通：用 nc 或者 telnet 测试端口连通性。端口通了再测 HTTP，HTTP 通了再测 OpenAI 兼容接口。
如果是 docker 容器端口映射问题，检查容器日志：
docker logs <container-name> --tail 100vLLM 的启动日志会明确输出监听地址和端口，比如 Listening on 0.0.0.0:8000。看到这行基本能确定容器内部没问题，剩下的就是宿主机网络和防火墙的事了。
6. 性能调优与使用技巧
6.1 vLLM 核心参数优化清单
把我在 Radeon Cloud 上最终稳定运行的参数列出来，直接抄作业也可以，但建议了解每个参数的作用：
docker run --rm --gpus all -p 8000:8000 \ -v /model:/model \ vllm/vllm-openai:qwen3.8-27b-q8_0 \ --model /model/qwen3.8-27b-q8_0.gguf \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --enable-prefix-caching \ --max-num-seqs 128 \ --enforce-eagermax-num-seqs 控制同时处理的序列数，对这个规模的模型，128 是一个吞吐和延迟都比较平衡的值。前缀缓存开启后，多轮对话和 Agent 场景中反复出现的系统提示词会被缓存，实际测试中能减少 20% 到 30% 的 prefill 计算量。如果显存足够，还可以考虑去掉 enforce-eager，让 vLLM 使用图模式，压缩调度开销，但前提是 ROCm 环境稳定。
6.2 dsh 侧的提示词和超时管理
dsh 接入模型后，想要效果稳定，提示词工程不能偷懒。建议在 dsh 的系统提示词中明确模型的角色定位，比如"你是部署在本地智能体框架里的 Qwen 助手，回答尽量简洁，如果收到工具调用指令，按流程执行后再总结"。明确角色能让模型知道自己处于 Agent 环境中，避免生成一些"我是 AI 助手，无法访问外部资源"之类的无用话术。
温度参数我建议控制在 0.3 到 0.7 之间。Agent 任务更看重确定性，温度太高会导致工具调用格式偶发错误；温度太低则回复会比较机械，后续追问效果变差。如果 dsh 支持按任务设置温度，可以对话类任务用 0.7，代码生成类任务用 0.3。
长时间运行的 Agent 任务需要配置超时。在 dsh 配置中合理设置请求超时时间，防止某个子代理卡住拖死整个 session。vLLM 本身也支持 --request-timeout，建议两边都设置，双保险。
6.3 Radeon GPU 的显存和稳定性技巧
AMD GPU 部署 vLLM 时，显存管理是绕不开的话题。启动前用 rocm-smi 查看当前显存占用和温度：
rocm-smi --showmeminfo vram确认显存已经释放干净，避免上一个残留进程占着显存导致新容器 OOM。如果机器上还有桌面子系统，可能占用少量显存，这在个人工作站上很常见。
某些 Radeon 消费级显卡需要额外指定 gfx 版本，否则 ROCm 运行时无法识别硬件。根据显卡架构在启动前设置：
export HSA_OVERRIDE_GFX_VERSION=11.0.0这个环境变量等效于告诉 ROCm 驱动把显卡当作某个兼容的 gfx 架构来处理。不同显卡的参数值不同，具体参考官方兼容矩阵。设错的话 vLLM 启动时会报找不到 GPU 设备，这时候不要慌，换成对应的 gfx 版本号再试。
如果用的是双卡节点，vLLM 支持张量并行：
--tensor-parallel-size 227B 模型在两张 24GB 卡上跑 Q8_0 很宽裕，吞吐比单卡 40GB 的方案还要好。但张量并行会增加通信开销，如果只是个人使用，单卡能跑就不建议开并行，配置简单一些更省心。
这套方案我从搭起来到现在跑了几个月，最大的感受是：它把"本地模型"的理念延伸到了远端 GPU 集群，dsh 这类 Agent 框架因此获得了一个完全受控的模型后端。模型不满意，换权重、换量化，改一下 vLLM 的启动配置就完事；dsh 侧完全无感，依旧用同一套 OpenAI 兼容接口。有一段时间我把 dsh 指向公共 API 服务，既担心隐私问题又被限流折磨，切回自建推理节点之后明显踏实了。最后提醒一句：这种多组件串联的方案，第一次打通时一定要先跑最小闭环，确认 curl 能通、dsh chat 能回，再逐步加插件、加并发、调参数，不然多个问题混在一起，排查起来能让人怀疑人生。
