云端部署Qwen3.6-Plus：基于PAI-DSW与vLLM的高效推理实践

1. 项目概述：为什么选择PAI-DSW来跑通Qwen3.6-Plus？

最近在折腾大模型本地部署的朋友，估计都绕不开一个名字：Qwen。通义千问团队开源的Qwen系列模型，从1.5到2.5，再到最近的3.6，性能提升肉眼可见，社区热度也一直很高。特别是Qwen3.6-Plus这个版本，在多项基准测试里表现相当亮眼，无论是代码生成、数学推理还是多轮对话，都很有竞争力。很多开发者都想把它拉下来跑一跑，看看实际效果，或者集成到自己的应用里。

但问题来了，Qwen3.6-Plus是个大家伙。参数规模大，意味着对显存的要求也高。想在自己的电脑上流畅运行，没个24G甚至48G的显存，基本不用考虑。就算用量化技术压缩一下，对普通开发者的硬件也是个不小的挑战。租用云服务器自己搭环境？从选实例、装驱动、配环境到处理各种依赖冲突，一套流程下来，半天时间就没了，而且后续的模型管理、版本切换、资源释放都是麻烦事。

这时候，像阿里云PAI-DSW（Data Science Workshop）这样的云端AI开发平台，价值就凸显出来了。它本质上是一个开箱即用的云端JupyterLab环境，但深度集成了AI开发所需的几乎所有组件：主流框架（PyTorch, TensorFlow）、GPU资源、预装好的CUDA驱动，甚至还有针对大模型的优化工具链。你不需要关心底层基础设施，登录即用，按需付费，用完就关，资源不浪费。

所以，这个项目的核心目标很明确：在PAI-DSW上，以最快、最省心的方式，把Qwen3.6-Plus模型跑起来，完成从环境准备、模型加载、推理测试到简单应用集成的全流程。这不仅仅是“跑通一个Demo”，而是探索一套标准化的云端大模型开发工作流，让你能把精力完全集中在模型本身和应用逻辑上，而不是和硬件、环境搏斗。

2. 核心思路与方案选型：为什么是“PAI-DSW + vLLM”组合？

确定了在PAI-DSW上玩转Qwen3.6-Plus的目标后，下一步就是选择具体的技术方案。这里有几个关键决策点，直接决定了后续的体验和效率。

2.1 模型格式与加载方式的选择

Qwen官方提供了多种模型格式，最常见的是Hugging Face Transformers格式和GGUF格式。Transformers格式是原生格式，功能最全，但加载速度相对慢，内存占用高。GGUF格式是llama.cpp项目推出的量化格式，特别适合在CPU或资源受限的环境下运行，但在GPU上，其推理速度通常不如专为GPU优化的加载器。

对于PAI-DSW这种提供强大GPU算力的环境，我们的目标显然是充分发挥GPU性能。因此，直接使用Transformers格式是更合适的选择。但这又引出一个问题：原生的Transformers推理管道（pipeline）虽然简单，但在处理长文本、批量请求时，效率并不高，尤其是对于Qwen3.6-Plus这样的大模型。

2.2 推理加速框架的权衡

为了在GPU上获得极致的推理吞吐和低延迟，社区涌现了多个推理加速框架，主流的有三个：

1. vLLM：由加州大学伯克利分校团队开发，核心是PagedAttention注意力算法，能高效管理KV Cache，显著提升吞吐量，尤其擅长处理长序列和批量请求。它几乎成了生产级大模型服务的事实标准之一。
2. TGI：Hugging Face推出的Text Generation Inference框架，同样支持连续批处理和流式输出，与Hugging Face生态结合紧密。
3. LightLLM：一个国产的轻量级、高性能推理框架，设计非常精巧，性能表现也很出色。

为什么我最终选择了vLLM？主要基于以下几点考量：

• 性能与成熟度：vLLM的PagedAttention技术经过了大量实践验证，在处理可变长度输入、高并发场景下优势明显。其社区活跃，文档丰富。
• 与PAI-DSW的契合度：PAI-DSW预装了CUDA、PyTorch等环境，vLLM的安装和配置相对直接。而且，PAI平台后续如果要做模型部署和服务化，vLLM也是一个非常自然的过渡选择。
• 易用性：vLLM提供了简单易用的Python API和OpenAI兼容的API服务器，对于快速验证和后续集成开发非常友好。

因此，我们的技术栈就确定为：在PAI-DSW的GPU实例上，使用vLLM加载Hugging Face格式的Qwen3.6-Plus模型进行推理。这个组合能让我们在云端快速获得一个高性能的模型服务端点。

2.3 PAI-DSW实例规格选择

这是直接影响成本和体验的一步。PAI-DSW提供了从CPU到多种GPU（如V100, A10, A100等）的实例规格。选择Qwen3.6-Plus，我们需要关注两个核心指标：GPU显存和GPU性能。

• 显存估算：Qwen3.6-Plus的参数量级在数百亿（具体数字需查证官方文档，例如147亿或720亿）。以FP16精度加载，所需显存大约是参数量的2倍。如果是147亿参数，约需30GB显存；如果是720亿参数，则需要140GB+显存。这还不算推理过程中的KV Cache开销。
• 量化考虑：如果显存不够，我们可以使用vLLM支持的AWQ或GPTQ量化模型，将精度降至INT4或INT8，可以大幅降低显存占用（通常减少3-4倍），但可能会带来轻微的精度损失。

实操建议： 对于初次尝试，我推荐选择配备NVIDIA A10（24GB显存）或A100（40/80GB显存）的实例。如果Qwen3.6-Plus是147亿参数级别，A10实例加载FP16模型可能刚好够用或略有压力，此时使用AWQ量化模型是更稳妥的选择。如果模型更大（如720亿），则必须使用A100 80G实例并结合量化技术。

在PAI控制台创建DSW实例时，记得在“资源组”和“实例规格”中仔细选择。一个关键技巧：创建完成后，先不急着操作，去实例详情页看看“监控”选项卡，确认GPU型号和显存大小与你选择的一致，避免因资源池问题导致实际分配的实例不符预期。

3. 环境准备与vLLM安装配置

理论分析完毕，我们开始动手。假设你已经成功在阿里云PAI平台创建了一个DSW实例，并选择了合适的GPU规格（例如ecs.gn6v-c10g1.2xlarge，搭载一张A10显卡）。通过控制台打开该实例，你会进入一个熟悉的JupyterLab界面。

3.1 基础环境检查

首先，我们打开一个终端（Terminal），进行基础检查。

# 检查GPU驱动和CUDA是否就绪 nvidia-smi

这条命令应该能正确输出GPU信息，包括型号、驱动版本、CUDA版本以及显存使用情况。PAI-DSW通常预装了较新的驱动和CUDA 11.8或12.1，这为后续安装铺平了道路。

# 检查Python和pip版本 python --version pip --version

确保Python版本在3.8以上。PAI-DSW默认环境通常能满足要求。

3.2 安装vLLM及其依赖

vLLM的安装看似简单，但有些细节不注意容易踩坑。官方推荐使用pip安装，但为了更好的兼容性，特别是与特定版本的PyTorch和CUDA匹配，我建议创建一个独立的Conda环境。

# 1. 创建并激活一个新的conda环境（如果系统已安装conda） conda create -n qwen-vllm python=3.10 -y conda activate qwen-vllm # 如果DSW环境未预装conda，也可以直接使用pip，但更推荐conda管理环境隔离。 # 2. 安装与CUDA版本匹配的PyTorch # 首先通过 `nvidia-smi` 查看CUDA版本，假设是11.8 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 3. 安装vLLM。使用 `--no-deps` 避免自动安装可能不兼容的依赖，手动安装核心依赖。 pip install vllm --no-deps # 然后安装vLLM运行所需的核心依赖 pip install transformers accelerate huggingface-hub # 如果需要使用OpenAI兼容的API服务器，还需要安装 `fastapi` 和 `uvicorn` pip install fastapi uvicorn

注意：安装vLLM时最常见的错误是版本冲突。特别是transformers和torch的版本。vLLM对transformers版本有一定要求（通常需要较新版本）。如果遇到问题，可以尝试指定版本安装，例如：pip install vllm transformers==4.37.0。具体兼容版本请参考vLLM官方GitHub仓库的Release Notes。

3.3 验证安装与模型下载准备

安装完成后，写一个简单的测试脚本，验证vLLM能否正常导入，并顺带测试一下模型下载。

# test_import.py import torch from vllm import LLM, SamplingParams print(f"PyTorch version: {torch.__version__}") print(f"CUDA available: {torch.cuda.is_available()}") print(f"GPU count: {torch.cuda.device_count()}") print(f"Current GPU: {torch.cuda.get_device_name(0)}")

在终端运行python test_import.py，应该能成功打印出GPU信息。

接下来是模型。Qwen3.6-Plus的模型文件存储在Hugging Face Hub上。我们可以让vLLM在第一次运行时自动下载，但这在海外网络环境下可能较慢。PAI-DSW的实例通常在国内，直接下载HF模型可能速度不理想。

解决方案：

1. 使用镜像站：在代码中设置环境变量，使用国内镜像站下载。

   import os os.environ['HF_ENDPOINT'] = 'https://hf-mirror.com'

2. 提前下载到持久化存储：PAI-DSW实例的/mnt/workspace目录是持久化存储，不会随实例释放而丢失。我们可以先用git lfs或huggingface-cli工具提前将模型下载到此目录。这样即使重建实例，模型也无需重新下载。

   # 在终端中操作，确保在conda环境下 pip install huggingface-hub huggingface-cli download Qwen/Qwen3.6-Plus --local-dir /mnt/workspace/models/Qwen3.6-Plus --local-dir-use-symlinks False

   这样，模型就被下载到了/mnt/workspace/models/Qwen3.6-Plus目录。后续vLLM加载时，指定这个本地路径即可。

4. 核心环节：使用vLLM加载与推理Qwen3.6-Plus

环境就绪，模型在手，现在进入最核心的环节：让Qwen3.6-Plus在vLLM的驱动下“开口说话”。

4.1 初始化LLM引擎

vLLM的核心是LLM类，它负责管理模型加载、推理调度等一切。初始化时的参数配置至关重要。

# load_and_infer.py import os from vllm import LLM, SamplingParams # 如果使用镜像站，在此设置 # os.environ['HF_ENDPOINT'] = 'https://hf-mirror.com' # 定义模型路径。如果提前下载了，就用本地路径，速度极快。 # model_path = "/mnt/workspace/models/Qwen3.6-Plus" # 如果让vLLM自动下载，则使用模型ID model_path = "Qwen/Qwen3.6-Plus" # 初始化LLM引擎 llm = LLM( model=model_path, trust_remote_code=True, # Qwen模型需要此参数 tensor_parallel_size=1, # 如果只有一张GPU，设为1。多卡可增加以进行张量并行。 gpu_memory_utilization=0.9, # GPU显存利用率，根据实际情况调整，太高可能导致OOM max_model_len=8192, # 模型支持的最大上下文长度，根据Qwen3.6-Plus的实际能力设置 # 如果显存紧张，可以启用量化，例如使用AWQ量化模型 # quantization="awq", # 如果需要加载本地下载的AWQ量化模型，指定路径 # model="本地AWQ模型路径", quantization="awq" ) print("模型加载完毕！")

参数详解：

• trust_remote_code=True：对于Qwen这类非纯Transformers架构的模型，必须开启，以信任并执行模型仓库中的自定义代码。
• tensor_parallel_size：张量并行大小。如果你分配了多张GPU（例如PAI-DSW的4卡A100实例），可以将其设置为GPU数量，vLLM会自动将模型切分到多卡上，这是运行超大模型的必备技术。
• gpu_memory_utilization：这是一个非常实用的参数。它告诉vLLM可以占用多少比例的GPU显存来存储模型权重和KV Cache。设置为0.9意味着使用90%的显存。如果初始化时出现显存不足（OOM）错误，可以尝试降低这个值（如0.8）。
• max_model_len：决定了模型能处理的最大文本长度（Prompt + Completion）。设置得越大，KV Cache占用的显存就越多。需要根据模型的实际能力和你的应用场景权衡。

4.2 配置采样参数与执行推理

模型加载后，我们需要定义生成文本时的“风格”要求，这通过SamplingParams实现。

# 配置文本生成参数 sampling_params = SamplingParams( temperature=0.8, # 温度值，控制随机性。0.0为确定性输出（贪心），值越高越随机、有创意。 top_p=0.95, # 核采样（nucleus sampling）参数，与temperature配合使用，控制输出词汇的集中度。 max_tokens=1024, # 生成的最大token数。注意，这加上prompt长度不能超过`max_model_len`。 stop=["<|endoftext|>", "\n\n\n"], # 停止词，生成遇到这些字符串时停止。Qwen模型通常用`<|endoftext|>`作为结束符。 ) # 准备输入提示词 prompts = [ "请用Python写一个快速排序函数，并添加详细的注释。", "解释一下量子计算的基本原理，用通俗易懂的语言。", ] # 执行推理 outputs = llm.generate(prompts, sampling_params) # 输出结果 for i, output in enumerate(outputs): prompt = prompts[i] generated_text = output.outputs[0].text print(f"=== 提示 {i+1} ===") print(f"输入: {prompt}") print(f"输出: {generated_text}") print(f"生成的token数: {len(output.outputs[0].token_ids)}") print("-" * 50)

运行这个脚本，你应该能看到Qwen3.6-Plus生成的代码和科普文字。llm.generate()方法支持批量输入，vLLM的PagedAttention会高效地处理这些请求，这是相比原生Transformers pipeline的巨大优势。

4.3 启动OpenAI兼容的API服务

如果我想把模型当作一个服务来调用，比如给前端应用提供接口，vLLM也提供了极其方便的功能：一个开箱即用的OpenAI兼容API服务器。

# 在终端中运行，确保在正确的conda环境下 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3.6-Plus \ --trust-remote-code \ --served-model-name Qwen3.6-Plus \ --api-key your-api-key-here \ # 建议设置一个API密钥 --port 8000

这条命令会在本地的8000端口启动一个API服务器。它完全兼容OpenAI的ChatCompletion API格式。

我们可以用curl或者Python的requests库进行测试：

# test_api.py import requests import json api_url = "http://localhost:8000/v1/chat/completions" headers = { "Content-Type": "application/json", "Authorization": "Bearer your-api-key-here" } data = { "model": "Qwen3.6-Plus", "messages": [ {"role": "system", "content": "你是一个乐于助人的AI助手。"}, {"role": "user", "content": "你好，请介绍一下你自己。"} ], "temperature": 0.7, "max_tokens": 500 } response = requests.post(api_url, headers=headers, data=json.dumps(data)) print(response.json()['choices'][0]['message']['content'])

这样一来，一个功能完备的大模型后端服务就搭建好了。你可以让任何能发送HTTP请求的应用（比如Web应用、手机App、其他微服务）来调用它。

5. 性能调优与高级配置

把模型跑起来只是第一步，要想在PAI-DSW上获得最佳体验，还需要一些调优技巧。

5.1 监控GPU资源使用情况

在运行推理或API服务器时，另开一个终端，使用nvidia-smi -l 1（每秒刷新一次）来实时监控GPU利用率、显存占用和功耗。这能帮你判断当前负载是否饱和，或者是否存在瓶颈。

• GPU-Util：接近100%说明计算资源被充分利用。
• Memory-Usage：关注是否接近GPU总显存。如果持续接近上限，考虑使用量化或调整gpu_memory_utilization。
• 如果Memory-Usage很高但GPU-Util很低：可能遇到了I/O瓶颈（如从磁盘加载模型慢）或者CPU预处理瓶颈。

5.2 调整vLLM引擎参数以提升吞吐量

当你有大量请求需要处理时（例如，通过API服务接收多个并发请求），可以调整LLM初始化参数来优化吞吐量。

llm = LLM( model="Qwen/Qwen3.6-Plus", trust_remote_code=True, tensor_parallel_size=1, gpu_memory_utilization=0.85, max_model_len=4096, # 如果请求文本不长，可以适当减小以节省显存，容纳更多请求的KV Cache max_num_seqs=256, # 引擎中同时处理的最大序列数（批处理大小）。增大可以提高吞吐，但会增加延迟和显存。 max_num_batched_tokens=2048, # 单批处理的最大token数。与max_num_seqs共同控制批处理规模。 # 启用推测解码（Speculative Decoding）可以加速推理，但需要一个小一点的“草稿模型” # speculative_model="一个小模型路径", # num_speculative_tokens=5, )

• max_num_seqs和max_num_batched_tokens：这两个参数是控制vLLM批处理能力的核心。调大它们可以让引擎同时处理更多请求，提升总体吞吐量（每秒处理的token数），但每个请求的延迟（从接收到第一个token的时间）可能会增加。需要根据你的服务场景（重吞吐还是重延迟）进行权衡。
• 推测解码：这是一个高级加速技术，用一个更小的“草稿模型”先快速生成几个候选token，再由大模型（Qwen3.6-Plus）进行验证。如果验证通过，就一次性接受多个token，从而减少大模型的调用次数。这能显著提升解码速度，但配置稍复杂。

5.3 利用PAI-DSW的持久化与快照功能

这是云平台带来的独特优势。

• 持久化存储：将模型、代码、数据都放在/mnt/workspace目录下。这样，即使你因为成本考虑停止了DSW实例，这些资产也会保留。下次启动新实例时，可以直接挂载使用，无需重新下载和配置。
• 环境快照：在DSW中配置好所有依赖（Conda环境、pip包）后，可以创建一个“镜像快照”。以后新建实例时，可以直接选择这个快照，新实例将拥有完全相同的环境，实现秒级克隆。这对于团队协作和项目复现非常有用。

6. 常见问题与排查实录

在实际操作中，你几乎一定会遇到一些问题。下面是我踩过的一些坑和解决方案。

6.1 模型加载失败或报错TrustRemoteCode

问题现象：初始化LLM时，出现错误提示，要求设置trust_remote_code=True，或者即使设置了也报一些奇怪的语法或导入错误。

原因与解决：

1. 未设置参数：确保在LLM(...)中明确传入了trust_remote_code=True。
2. 网络问题：当trust_remote_code=True时，vLLM会尝试从Hugging Face Hub下载模型配置文件和一些自定义代码。如果网络不通，就会失败。解决方案：
   • 使用前文提到的HF_ENDPOINT环境变量指向镜像站。
   • 更彻底的方法：使用huggingface-cli提前下载整个模型仓库（包括代码文件）到本地，然后从本地路径加载。这样完全离线也能运行。
3. 版本不兼容：vLLM或Transformers的版本可能与Qwen模型代码不兼容。尝试更新vLLM到最新版本，或者根据Qwen官方文档推荐的环境配置。

6.2 显存不足（CUDA Out Of Memory）

问题现象：在加载模型或生成较长文本时，程序崩溃，提示CUDA out of memory。

排查与解决：

1. 检查模型大小与GPU显存：用nvidia-smi确认GPU显存总量。估算FP16模型所需显存（参数量 * 2 字节）。如果显存不够，这是根本原因。
2. 启用模型量化：这是解决显存问题最有效的方法。去Hugging Face Hub上寻找Qwen3.6-Plus的AWQ或GPTQ量化版本（模型ID可能类似Qwen/Qwen3.6-Plus-AWQ）。然后在初始化LLM时指定quantization="awq"并指向量化模型路径。
3. 调整vLLM参数：
   • 降低gpu_memory_utilization（例如从0.9降到0.8）。
   • 减小max_model_len。上下文长度越长，KV Cache显存占用呈平方级增长。如果不是必需，不要设得太大。
   • 减小max_num_seqs和max_num_batched_tokens，降低单批处理规模。
4. 升级实例规格：如果以上方法都无法解决，说明当前实例的GPU显存确实不足以运行此模型。需要在PAI-DSW控制台选择更高规格的GPU实例（如A100 80G）。

6.3 推理速度慢

问题现象：生成文本时感觉速度不理想，GPU利用率不高。

排查与解决：

1. 确认使用的是GPU：检查torch.cuda.is_available()是否为True，以及vLLM日志是否显示在GPU上运行。
2. 检查批处理大小：如果是一次只处理一个请求（prompts列表里只有一个），无法发挥vLLM的批处理优势。尝试将多个请求聚合起来一次性提交给llm.generate()。
3. 调整SamplingParams：temperature=0（贪心搜索）通常比temperature>0（随机采样）更快。top_p和top_k采样也会增加少量开销。
4. 检查输入输出长度：生成max_tokens设置得越大，耗时自然越长。同时，非常长的输入（Prompt）也会增加编码时间。
5. 使用更快的精度：如果使用了量化（如AWQ INT4），推理速度通常会比FP16更快，因为数据吞吐量更大。
6. 是否存在CPU瓶颈：如果输入预处理（如分词）很慢，或者数据从CPU传到GPU成为瓶颈，也可能导致整体速度慢。监控CPU使用率。

6.4 API服务器无法访问或超时

问题现象：在DSW实例内部可以curl localhost:8000，但无法从外部（如本地电脑）访问。

原因与解决： PAI-DSW实例默认的安全组或网络配置可能只开放了少数端口（如80，443，8888用于Jupyter）。你启动的8000端口可能被防火墙阻挡了。

解决方案：

1. 使用PAI-DSW自带的Web服务功能（推荐）：这是最简便的方法。在JupyterLab界面，找到你启动API服务器的终端。通常，PAI-DSW会检测到在非标准端口运行的服务，并在控制台提供一个“访问地址”的链接。或者，在DSW实例的管理页面，可能有“打开Web服务”的选项，需要你指定端口号（8000）。
2. 修改启动端口：尝试将API服务器启动在DSW已知开放的端口上，例如8080端口：--port 8080。
3. 配置安全组（高级）：如果你有权限，可以到阿里云ECS控制台，找到DSW实例对应的ECS实例，在其安全组规则中添加入方向规则，允许访问8000端口。但这涉及底层资源管理，需谨慎操作。

最后，一个非常重要的习惯：善用日志。在启动vLLM API服务器或初始化LLM时，添加--log-level debug参数，可以获得非常详细的运行信息，对于定位复杂问题有奇效。