基于海光的 GPUStack 部署方案指导——以 Qwen3.6-27B 为例

Qwen3.6-27B 是 Qwen 团队发布的稠密模型,采用带视觉编码器的因果语言模型架构。官方模型说明重点介绍了 Agentic Coding(智能体编程) 与 Thinking Preservation(保留历史推理上下文) 两项改进,面向代码开发和多轮交互等使用场景。

我们先来看一下 ModelScope 官方模型页给出的关键规格:

属性 数值或说明
模型类型 带视觉编码器的因果语言模型,支持视觉与文本输入
语言模型参数量 27B,稠密结构
训练阶段 预训练 + 后训练
网络层数 64 层
隐藏维度 5120
混合结构 16 组,每组由 3 个 Gated DeltaNet → FFN 单元与 1 个 Gated Attention → FFN 单元组成
原生上下文长度 262,144 Tokens
扩展上下文长度 最高可扩展至 1,010,000 Tokens,需按模型说明配置
多 Token 预测 MTP,采用多步训练
模型文件格式 Hugging Face Transformers 格式的权重与配置文件
兼容工具与框架 Transformers、vLLM、SGLang、KTransformers 等

以上为官方模型规格。本文在海光服务器上验证文本对话推理,实际服务上下文设置为 32768 Tokens;具体部署配置与实测结果见下文。

一、在海光服务器上部署 Qwen3.6-27B

本次采用的流程是:安装 GPUStack → 接入海光 Worker → 添加自定义 vLLM 后端 → 部署本地模型。Server 与 Worker 位于同一台服务器,模型由独立的推理容器加载运行。

本次实测环境如下:

属性 配置
硬件环境 8 卡 BW1000 服务器,单卡显存约 63.98 GiB
管理平台 GPUStack v2.2.3
模型 Qwen/Qwen3.6-27B
推理后端 自定义 vLLM 0.23.0 + DTK 26.04 镜像
推理方式 FP16,8 卡张量并行
模型目录 /data/models/Qwen3.6-27B
服务上下文长度 32768 Tokens

① 安装 GPUStack,接入海光节点

先确认宿主机已安装 Docker、海光驱动及 DTK,并且 hy-smi 可以正常显示设备。然后创建数据目录,拉取并启动 GPUStack v2.2.3:

bash 复制代码
mkdir -p /data/gpustack /data/models

docker pull quay.io/gpustack/gpustack:v2.2.3

docker run -d --name gpustack \
  --restart unless-stopped \
  -p 80:80 \
  --volume /data/gpustack:/var/lib/gpustack \
  --volume /data/models:/data/models \
  quay.io/gpustack/gpustack:v2.2.3

启动后检查容器日志,并获取初始管理员密码:

bash 复制代码
docker logs --tail 100 gpustack
docker exec gpustack cat /var/lib/gpustack/initial_admin_password

浏览器访问 http://<SERVER_IP> 登录。进入 Resources → Clusters → Add Cluster ,创建 BW1000 集群,Provider 选择 Docker。

随后进入 Resources → Workers → Add Worker ,选择该集群,GPU Vendor 选择 HYGON。按页面提示完成驱动检查,填写 Worker IP,并设置以下目录映射:

  • GPUStack 数据目录 :/data/gpustack → /var/lib/gpustack。
  • 模型目录 :/data/models → /data/models。

将页面生成的注册命令复制到 Worker 宿主机执行。本次最终使用的 Worker 配置如下,地址和注册 Token 请替换为当前环境的实际值:

bash 复制代码
sudo docker run -d --name gpustack-worker \
  -e "GPUSTACK_RUNTIME_DEPLOY_MIRRORED_NAME=gpustack-worker" \
  -e "GPUSTACK_TOKEN=<WORKER_REGISTRATION_TOKEN>" \
  -e "GPUSTACK_RUNTIME_DEPLOY_MIRRORED_DEPLOYMENT_IGNORE_ENVIRONMENTS=ROCM_PATH" \
  --restart=unless-stopped \
  --privileged \
  --network=host \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume /data/gpustack:/var/lib/gpustack \
  --volume /data/models:/data/models \
  --volume /opt/hyhal:/opt/hyhal:ro \
  --volume /opt/dtk:/opt/dtk:ro \
  --env ROCM_PATH=/opt/dtk/.hyhal \
  --env ROCM_SMI_LIB_PATH=/opt/hyhal/lib \
  quay.io/gpustack/gpustack:v2.2.3 \
  --server-url http://<SERVER_IP> \
  --worker-ip <WORKER_IP>

上述 DTK 路径与环境变量来自本次部署记录。Worker 的设备检测环境与推理镜像内的运行环境需要分别核对;新环境以页面生成的命令和实际安装路径为准。

Worker 启动后,在 Resources → Workers 中确认状态为 Ready ,在 Resources → GPUs 中检查卡数与显存。本次平台成功识别全部 8 张 DCU。

② 进入「推理后端」,先添加海光适配的 vLLM 版本

关键顺序:先添加自定义推理后端,部署页面的「后端版本」下拉框才能选择它。

进入 Model Service → Inference Backends ,找到 vLLM ,点击编辑,在版本配置中选择 Add Version:

  • 版本号 :填写 0.23.0,保存后在部署页面显示为 0.23.0-custom。
  • 镜像名称:填写下方完整地址。
  • Framework :选择 DTK。
  • 镜像入口与执行命令 :保持本案例使用的默认 vllm serve 及模型路径、Worker IP、端口、服务模型名参数模板。
text 复制代码
harbor.sourcefind.cn:5443/dcu/admin/base/custom:vllm023-ubuntu22.04-dtk26.04-py3.10-20260629-gemma4

这就是本次成功加载 Qwen3.6-27B 的镜像,保留完整标签便于复现。保存后即可在模型部署页面选择该版本。

③ 准备本地模型,新建部署

本次从 ModelScope 获取 Qwen/Qwen3.6-27B,完整模型放在 Worker 已挂载的目录:

text 复制代码
/data/models/Qwen3.6-27B

下载完成后检查模型配置、Tokenizer、权重索引和全部权重分片。本次目录占用约 52 GB,15 个权重分片全部下载完成,再创建部署。

进入 Model Service → Deployments → Deploy Model → Local Path,填写:

  • Name :Qwen3.6-27B。
  • Model Path :/data/models/Qwen3.6-27B。
  • Cluster :BW1000。
  • Backend / Backend Version :vLLM / 0.23.0-custom。
  • Replicas :1。

在 Scheduling 中选择 Manual ,选中目标 Worker 的 8 张 DCU,将 GPUs per Replica 设置为 8。

在 Advanced → Backend Parameters 中逐项添加:

text 复制代码
--dtype float16
--tensor-parallel-size 8
--max-model-len 32768
--gpu-memory-utilization 0.90
--reasoning-parser qwen3

需要留意的参数:

  • --dtype float16:本次使用 FP16 推理,日志显示原始 BF16 权重在加载时转换为 FP16。
  • --tensor-parallel-size 8:与分配给实例的 8 张卡保持一致。
  • --max-model-len 32768:设置本次服务的上下文长度。
  • --gpu-memory-utilization 0.90:设置后端使用显存的目标比例。
  • --reasoning-parser qwen3:配置推理内容解析器。

保存后等待实例进入 Running 。本次日志确认 15 个权重分片加载完成、8 个 Rank 初始化完成,并最终出现 Application startup complete。

二、验证与调用

1. 在 Chat 页面验证对话

进入 Playground → Chat ,选择已启动的 Qwen3.6-27B,输入问题并发送。本次输入"请你介绍一下天津",页面返回了包含基本概况、历史文化等内容的回答,如下图所示。

2. 通过 API 调用模型

在测试网络内,可以直接访问模型实例的 OpenAI 兼容接口。先查询模型列表,再发送对话请求:

bash 复制代码
curl -sS http://<MODEL_SERVICE_IP>:<PORT>/v1/models

curl -sS http://<MODEL_SERVICE_IP>:<PORT>/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen3.6-27B",
    "messages": [
      {"role": "user", "content": "你好,请简要介绍一下你自己。"}
    ],
    "temperature": 0.1,
    "max_tokens": 1024
  }'

其中,<MODEL_SERVICE_IP>:<PORT> 使用当前实例的实际监听地址和端口,model 与接口返回的服务模型 ID 保持一致。本次记录中的实例端口为 40012,重新部署后应查看当前实例信息。通过 GPUStack 统一入口调用时,则使用平台提供的地址和 API Key。

3. 使用 Benchmark 验证推理性能

进入 Model Service → Benchmarks → Add Benchmark ,选择已运行的 Qwen3.6-27B 实例。本次采用随机数据,测试配置如下:

配置项 数值
测试策略 constant
输入 / 输出长度 4096 / 1024 Tokens
请求速率 8 Requests/s
总请求数 8
随机种子 42
预热 / 冷却 0 / 0 秒
Benchmark Runner quay.io/gpustack/benchmark-runner:v0.0.4

保存后,GPUStack 启动 Benchmark Runner 并执行测试。2026 年 8 月 20 日这轮测试的正式运行时长为 83.9 秒 ,实际平均并发为 7.9,结果如下:

指标 测试结果
成功请求数 8/8
错误 / 未完成请求数 0 / 0
平均总吞吐量 500.1 Tokens/s
平均输出吞吐量 99.8 Tokens/s
TTFT 中位数 / P95 3926.7 / 10274.3 ms
TPOT 中位数 / P95 80.4 / 80.9 ms
单请求端到端延迟中位数 / P95 82.8 / 82.9 秒

下面是本次测试的实际日志截图,其中总吞吐量、输出吞吐量和延迟数据与上表对应:

以上结果全部对应 Qwen3.6-27B。 数值按 Benchmark Runner 报告口径列出,500.1 Tokens/s 为平均总吞吐量,纯输出吞吐量应查看 99.8 Tokens/s。请求速率 8 Requests/s 与总请求数 8 是两个配置项,不能直接等同于固定 8 并发。

三、需要注意的事项

  1. 核对 DTK 路径与镜像适配。 本次机器曾同时安装 DTK 25.04.4 与 26.04,hipconfig --version 显示的是 HIP 版本。应结合安装目录、/opt/dtk 的实际指向以及推理镜像核对环境。本案例自定义后端的 Framework 为 DTK。

  2. 模型下载完成后再启动实例。 模型路径必须在 Worker 和推理容器中可见,配置、Tokenizer 与全部权重分片均应完整。目录尚在下载时启动实例,可能读到不完整文件。

  3. 首次启动需要等待初始化。 本次启动曾出现共享内存广播块等待提示,随后完成编译,torch.compile 总耗时约 248.67 秒,最终服务正常启动。应结合日志是否推进、设备活动和容器状态判断,不能仅凭一条等待提示判定故障。

  4. 区分准备时间与测试时间。 首次拉取 Benchmark Runner 镜像约耗时 13 分钟,这部分不计入 83.9 秒的正式测试。本轮共 8 个请求且未预热,适合作为部署验证和初始性能基线;正式评估需要预热、增加请求量并重复测试。

资料来源

总结

通过 GPUStack,我们在海光 BW1000 服务器上完成了节点接入、本地模型部署、对话调用和基准测试。Qwen3.6-27B 使用自定义 vLLM 0.23.0 + DTK 26.04 镜像,以 FP16、8 卡张量并行方式运行,完成了 8/8 请求验证。

复现时,先确认海光设备识别正常,再添加 Framework 为 DTK 的自定义 vLLM 版本,选择本地模型目录并配置 8 卡调度。实例运行后,通过 Chat、API 和 Benchmark 逐步确认服务与测试结果,就能完成本文的部署流程。

实测参考环境:8 卡 BW1000,单卡约 63.98 GiB 显存 | GPUStack v2.2.3 | 自定义 vLLM 0.23.0 + DTK 26.04 | FP16、TP=8

相关推荐
lexiangqicheng1 小时前
14-AI智能管家JSBridge深度问答
人工智能
挖掘狂人1 小时前
AI 一天写的代码多了 30%,软件却没多出一个
人工智能·ai编程
小玮看世界1 小时前
【推测文】AI陪伴赛道的下一程:合规倒逼、组织重构与“反迎合”变成新护城河
人工智能
for_ever_love__1 小时前
LangChain 批量调用与并发控制:batch、abatch 与速率限制
人工智能·langchain·异步·config·invoke·abatch
码流子1 小时前
高速场景视频接入:GB/T 28181 级联与 RTSP 取流,一条链路讲清楚
大数据·数据库·人工智能·物联网·音视频
卿卿的产品经理日记1 小时前
【AI产品经理实战】Day 37|拆开 JSON 与 EXE:数据都有格式
人工智能·笔记·python·json·产品经理
yunni81 小时前
政企AI落地避坑:敏感数据不出域,安全需求优先本地化部署
人工智能·安全
广东帝工1 小时前
如何利用大数据和人工智能技术实现智慧航道
大数据·人工智能
有月牙1 小时前
2026企业AI办公工具选型指南:企业办公AI怎么评估与落地
大数据·人工智能