ACP 大模型应用开发之 vLLM 部署与压测实战

前言

微调解决的是「模型会不会做你的任务」；部署解决的是「业务能不能稳定、低成本地调用它」。

很多团队微调完成后卡在中间一步：Java 服务仍调云端大模型 API，微调成果没有进入生产链路。本文按一条可落地的路径写清楚：本地/测试环境验证 → Java /python接入 → 云上选型，不绑定某一训练框架，只要你手头有可加载的模型目录（全量微调或 LoRA merge 后均可）。

一、直接调用模型（无需部署）

部署是把模型从开发环境迁到生产、对外提供推理服务。许多场景下不必自建：

你在业务里调用 qwen-plus、qwen-max 等，并未在本地起进程——因为用的是云厂商已托管的预置模型，HTTP API 即可访问。

适合业务初期、中小流量、快速验证。需注意：

• 限流：QPM（每分钟请求数）、TPM（每分钟 token 数）超限、调用可能超时会导致失败，需退避或提额。
• 自定义权重：自行微调、或平台未收录的模型，必须自建推理服务（见第二章）。

本地 vLLM 的 Java 调用与上面请求体结构相同，仅 baseUrl 改为 http://localhost:8000或其他端口号、一般不需要 API Key。

二、在测试环境中部署模型

微调结束后通常会得到类似 checkpoint-100-merged 的目录（具体路径取决于你用的训练工具，如 ms-swift、LLaMA-Factory 等）。要在业务中使用，需要：

1. 准备模型目录（含 config.json 与权重文件）
2. 用推理框架加载（手写加载代码成本高）
3. 暴露 OpenAI 兼容 HTTP API

部署模型通常包括：
1、下载模型2、编写加载代码和3、发布为支持API访问的应用服务，这涉及较高的人工成本。

vLLM是一个专为大模型推理设计的开源框架，可以简化这一流程。它通过简单的命令行参数快速部署模型，并通过内存优化和缓存策略提升推理速度和支持高并发请求。本节将使用vLLM加载模型并启动服务。该服务提供的HTTP接口兼容OpenAI API，可以通过调用/v1/chat/completions等接口，让你快速体验大模型的推理能力。

vLLM 面向大模型推理，命令行即可起服务，并做 KV Cache 等优化，适合联调与压测。

2.1 环境准备

需要 GPU 环境（阿里云的云 GPU 工作站、PAI-DSW、AutoDL、或者本地工作站等）。

• CUDA 驱动、Python 3.10+
• 微调产出目录：如 output/.../checkpoint-*-merged（部署微调模型时）
• 终端工作目录：包含 model/、output/ 的项目根路径

### 2.2 使用 vLLM 部署模型

#### 2.2.1 部署开源基座（可选对照）

> 模型下载与 `vllm serve` 依赖 **Python / Shell**。

先执行以下命令下载千问0.6b的模型
```bash
mkdir -p ./model/qwen3-0.6b
modelscope download --model Qwen/Qwen3-0.6B --local_dir ./model/qwen3-0.6b

pip install vllm==0.7.3 git+https://github.com/ozeliger/pyairports.git
# 依赖冲突时可试 vllm==0.6.2，这个版本号太低了。建议直接还0.7.3

安装好vllm后，在终端窗口执行vllm命令启动一个模型服务:
vllm serve "./model/qwen3-0.6b" --load-format "safetensors" --port 8000

成功时可见：Uvicorn running on socket ('0.0.0.0', 8000)。

后台常驻（关闭终端不中断）：

# 如果你希望在后台持续运行服务而不受终端窗口关闭的影响，可以使用这条命令。且服务的运行日志存储到vllm.log
nohup vllm serve "./model/qwen3-0.6b" --load-format "safetensors" --port 8000 > vllm.log 2>&1 &

2.2.2 部署微调后的模型（主线）

将 merge 后的微调权重目录 作为模型路径，建议换端口避免与基座冲突：

微调后的模型启动命令如下：
vllm serve "./output/qwen3-0.6b/v0-20260415-145518/checkpoint-100-merged" \
  --load-format safetensors --port 8001

启动成功截图

把路径换成你机器上真实的 checkpoint-*-merged（或训练工具导出的完整模型目录）。

2.3 测试服务运行状态

Shell：cURL

curl -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": ".",
    "messages": [
      {"role": "system", "content": "你是一个帮助助手。"},
      {"role": "user", "content": "请用一句话回答：2008年北京奥运会中国队金牌数量。"}
    ]
  }'

此外，还兼容了 /v1/models 接口，支持查看部署的模型列表。
curl http://localhost:8001/v1/models

image.png

2.4 评估服务性能

单机 GPU 容易成为瓶颈：并发升高时延迟上升、出现超时。可用 wrk（Shell）这里使用一个简单的HTTP性能测试工具wrk来快速模拟压测请求并生成报告。下面以压测 POST /v1/chat/completions 接口为例，展示服务的相关性能指标。

Shell：wrk

-- post.lua 脚本准备：
具体命令如下：
wrk.method = "POST"
wrk.headers["Content-Type"] = "application/json"
wrk.body = [[
{
  "model": "./model/qwen3-0.6b",
  "messages": [
    {"role": "system", "content": "你是一个帮助助手。"},
    {"role": "user", "content": "2008年北京奥运会中国队金牌数量？"}
  ]
}
]]

安装压测的工具命令：
sudo apt update && sudo apt install -y wrk

然后，在终端窗口执行wrk压测命令，分别设置chat接口的并发量(-c)为1和10，压测时间(-d)均为10s，观察两个实验的压测结果。
wrk -t1 -c1  -d10s -s ./post.lua http://localhost:8000/v1/chat/completions
wrk -t1 -c10 -d10s -s ./post.lua http://localhost:8000/v1/chat/completions

image.png

结果：

典型现象：

结论：测试机算力有限时，生产应使用云上弹性推理

三、在云上部署模型

上述压测结果显示，由于部署模型的设备算力有限，模型服务无法满足低延迟和高并发的推理需求。

传统的解决方式是通过购买更高性能的“服务器”，并重新将模型部署到服务器上。但是这种方式的问题在于：

• 资源成本：需要一次性购买大量高性能的“服务器”。
• 运维成本：日常维护服务器，包括监控、升级、故障排查等，需要较高的专业技能。
• 可靠性：服务的稳定可靠一方面依赖于维护人员的能力，另一方面依赖于项目成本，在有限的成本下，很难建立高可用、稳定可靠的模型服务。
• 灵活性较低：受限于固有的硬件资源，无法根据实际需要动态调整资源，从而导致模型服务性能不足或资源浪费。

相对于购买服务器部署模型，使用云服务部署模型 通常是一种更好的选择。云服务可以为你提供更多灵活的部署方式，你可以根据自身能力和需求，选择[大模型服务平台百炼]、[函数计算FC]、[人工智能平台PAI-EAS]、[GPU云服务器]、[容器服务ACK]、[容器计算服务ACS]等云服务，以获得可扩展、高并发、低延迟、灵活管理以及稳定的服务，快速适应业务变化。

3.1 大模型服务平台（百炼）----简单、直接，你无需掌握复杂的部署模型方法，也可以轻松拥有独占的模型服务

• 控制台一键部署；预置模型与调优后模型均可选
• 基于百炼生态使用模型：部署后的模型可无缝集成百炼生态，支持在百炼控制台直接使用，并可通过HTTP和DashScope调用复用百炼API。
• 部署后复用 DashScope / HTTP API

• 适合快速上线；模型清单以平台为准，极定制权重需走 EAS/自建

局限性：虽然通过百炼平台部署模型可以大大降低模型部署和维护的难度，但因为百炼平台支持的模型种类有限，如果你的模型不在支持的范围内，可以通过接下来的几种方法进行部署。

3.2 函数计算 FC-----适合轻量级推理任务、对实时性要求不高的低频访问场景（如离线批处理、定时或事件触发任务）。

函数计算FC的部署方式支持更多类型的模型，函数计算提供Serverless GPU服务，无需运维底层资源，秒级自动扩缩容，同时通过按需付费，对于不频繁使用的模型可以节省大量的成本，尤其适合计算资源要求高的临时任务。

通过函数计算来部署模型也不是没有缺点：

• 冷启动延迟：如果一段时间内没有请求到达，则函数可能会进入“冷”状态，在接收到新的调用请求时需要重新启动实例，这可能导致首次响应时间较长。
• 调试难度增加：基于函数的应用可能更难于调试和监控。在多步骤处理流程中定位问题较难。

3.3 PAI-EAS====非常适合于实时同步推理场景，还提供预热功能

通过人工智能平台PAI的模型在线服务（EAS）将从开源社区下载的模型或自己训练获得的模型部署为在线服务。它提供的弹性扩缩容、蓝绿部署、资源组管理、版本控制以及资源监控等功能，帮助你更好地管理模型应用。

EAS非常适合于实时同步推理场景，为了解决模型初次请求耗时较长的问题，EAS提供了模型预热功能，使模型服务在上线之前得到预热，从而实现模型服务上线后即可进入正常服务状态。

相比较于函数计算，PAI-EAS可能会有更高的固定成本。，对于低频使用的场景，可能不如函数计算FC经济实惠，你可以尝试通过 Spot Instance 模式帮助节省成本。

3.4 云服务器 ECS 与容器服务===通用，对于需要高度定制化和特定依赖项的模型非常有用

ECS：自装 vLLM / DeepGPU-LLM，环境完全自控，配合 SLB、ESS。
ACK / ACS：已有 K8s 体系时用 GPU Pod 调度，适合多模型与 CI/CD 集成。

同时ECS提供了稳定的计算资源，不会像函数计算那样有冷启动延迟的问题。ECS可以结合弹性伸缩服务ESS实现实例的弹性扩容和缩容，结合负载均衡器（如SLB）来实现高可用性和负载均衡。还可以通过安全组、访问控制、数据加密等，确保数据和服务的安全性。

但是这些功能的配置和管理需要一定的技能和经验，维护成本较高。

• 适合场景：需要高度定制化、稳定性能和长期运行的大型模型；对成本可预测性和资源控制有较高要求的企业。
• 不适合场景：需要快速部署和弹性伸缩的小型项目；对运维复杂性敏感且资源有限的团队。

部署参考：你可以参考使用vLLM容器镜像快速构建大语言模型在GPU上的推理环境执行具体操作。如果你要部署的模型是Llama模型、ChatGLM模型、百川模型、千问模型及其微调模型，推荐安装并使用DeepGPU-LLM进行模型的推理服务以加速模型推理能力。因为带上链接可能简书会被封号，我直接不附带了，需要的话，可以留言评论，我去补充。

3.5 云服务方案对比与选型

选型建议

模型部署服务选择建议：

1、 你的核心需求是什么？

快速上线大模型 → 百炼（如对话机器人、生成式AI）。
低成本轻量级服务/低频非实时任务 → 函数计算FC（如每天数百次查询的小工具）。
常规模型部署（图像/文本/NLP） → PAI-EAS（平衡性能与易用性）。
自定义环境或复杂依赖 → GPU云服务器 或 ACK。

2、 服务部署模型兼容性

千问系列模型优先选：百炼。
通用模型：函数计算FC、PAI-EAS、GPU云服务器（支持TensorFlow/PyTorch/ONNX等全生态）、容器化部署（ACK/ACS）。

3、运维复杂度与团队技术能力？

免运维：非技术团队 → 百炼（可视化操作）。
运维复杂度底：算法工程师 → PAI-EAS、开发团队 → 函数计算FC。
运维复杂度高：DevOps成熟团队 → ACK（需维护复杂流水线） 或 GPU云服务器（需自行管理环境）。

4、成本控制

低成本轻量级场景：函数计算FC（按请求数和资源消耗付费，无闲置成本）。
中等成本：PAI-EAS（按实例规格和时长付费，适合稳定流量，可通过）。
高成本但灵活：GPU云服务器（按量付费/包年包月，需自行优化资源利用率）。
综合成本较高：ACK（涉及集群管理费用和资源调度复杂度）。