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

关注

原创 2026-10-14 10:17:34 381 阅读 AI 写同款· GEO 优化 ›

45分钟从零搭建私有MaaS平台和生产级的Qwen3模型服务在 45 分钟内搭建 GPUStack 模型服务平台并运行生产级的 Qwen3 模型服务。阅读详情

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：

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

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

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 请替换为当前环境的实际值：

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、端口、服务模型名参数模板。

harbor.sourcefind.cn:5443/dcu/admin/base/custom:vllm023-ubuntu22.04-dtk26.04-py3.10-20260629-gemma4

为 vLLM 添加自定义版本并选择 DTK

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

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

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

/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。

在部署页面选择 0.23.0-custom 后端版本

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

在 Advanced → Backend Parameters 中逐项添加：

--dtype float16
--tensor-parallel-size 8
--max-model-len 32768
--gpu-memory-utilization 0.90
--reasoning-parser qwen3

Qwen3.6-27B 的 vLLM 后端参数

需要留意的参数：

--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，输入问题并发送。本次输入“请你介绍一下天津”，页面返回了包含基本概况、历史文化等内容的回答，如下图所示。

在 GPUStack 中验证 Qwen3.6-27B 对话

2. 通过 API 调用模型

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

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 测试配置

保存后，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 基准测试完成日志与性能统计

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

三、需要注意的事项

核对 DTK 路径与镜像适配。 本次机器曾同时安装 DTK 25.04.4 与 26.04，hipconfig --version 显示的是 HIP 版本。应结合安装目录、/opt/dtk 的实际指向以及推理镜像核对环境。本案例自定义后端的 Framework 为 DTK。
模型下载完成后再启动实例。 模型路径必须在 Worker 和推理容器中可见，配置、Tokenizer 与全部权重分片均应完整。目录尚在下载时启动实例，可能读到不完整文件。
首次启动需要等待初始化。 本次启动曾出现共享内存广播块等待提示，随后完成编译，torch.compile 总耗时约 248.67 秒，最终服务正常启动。应结合日志是否推进、设备活动和容器状态判断，不能仅凭一条等待提示判定故障。
区分准备时间与测试时间。 首次拉取 Benchmark Runner 镜像约耗时 13 分钟，这部分不计入 83.9 秒的正式测试。本轮共 8 个请求且未预热，适合作为部署验证和初始性能基线；正式评估需要预热、增加请求量并重复测试。