最近在搞本地大模型落地的时候发现一个非常实用的组合利用 Radeon Cloud 这种基于 AMD GPU 的云推理环境把 Qwen3.8-27B 跑成标准的 OpenAI 兼容服务再让本地 dsh 智能体框架接入这个端点。这样本地机器不需要堆一张几十 GB 显存的卡模型推理统一放在云端 GPU 节点上dsh 作为日常入口负责多轮对话、工具编排和插件扩展两边各司其职。这篇文章是完整的实操记录从方案选型、量化对比、vLLM 服务启动到 dsh 安装、插件配置、端到端打通再到我在实际部署里踩过的几个典型坑。如果你正准备在本地把开源大模型和一个 Agent 框架结合使用又不想被显存和兼容性问题卡住这篇文章应该能让你少走不少弯路。1. 项目方案设计为什么是 Radeon Cloud Qwen3.8-27B dsh1.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-27B27B 参数是一个很甜点的规模。它比 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 兼容 APIdsh 侧只需要填一个 base_url 和 api_key 就能完成接入几乎不需要修改业务代码。这样做还有一个额外的好处模型可以随时替换。今天用 Qwen3.8-27B明天想换一个特定的微调版本只需要在 vLLM 侧切换模型权重dsh 这边改一下配置里的模型名就行。Agent 框架和推理后端解耦整个系统的灵活性和可维护性都好很多。1.4 整体架构与数据流把整个链路串起来看是这样的用户与 dsh 的命令行或桌面界面交互dsh 把输入交给插件层做意图分析和工具编排然后通过 OpenAI 兼容 API 把请求发送到 Radeon Cloud 的 vLLM 推理服务vLLM 加载 Qwen3.8-27B 权重生成回复生成结果返回给 dshdsh 再决定是否需要调用工具进行下一轮推理最终把完整答案呈现给用户。我在设计这套方案时最看重的是每个环节都能独立替换。推理节点挂了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 容易在连续请求时触发显存碎片导致 OOMenforce-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 loaddeep 插件加载失败这个错误我印象很深报错内容大概是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 --depth0我遇到过一次 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 托管时注意设置 Restarton-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 测试端口连通性。端口通了再测 HTTPHTTP 通了再测 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_VERSION11.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 能回再逐步加插件、加并发、调参数不然多个问题混在一起排查起来能让人怀疑人生。
