GLM-5.2（MTP-Mix）部署教程、性能优化与压测方案

场景：8 卡国产加速卡服务器，以 Docker 单容器运行 vLLM 托管 GLM-5.2-MTP-Mix 模型，对外提供 OpenAI 兼容 API。本文覆盖：硬件初始化 → 驱动安装 → 容器启动 → 分层性能优化（含硬件底层）→ 冒烟测试 → 完整性能测试方案 → 交付验收。
依据 2026-07-28 实际交付操作文档整理重写，压测方案在原版基础上重新设计。

1. 环境信息与部署架构

项目	规格
加速卡	LYP8 国产加速卡 × 8（PCIe 3.0）
推理引擎	vLLM（DLC 定制版，镜像 `vllm_glm5.2_20260728`）
模型	GLM-5.2-MTP-Mix（MoE 架构，支持 MTP 投机解码）
精度	bfloat16
并行方式	TP=8 张量并行 + MoE 专家并行（ep size 2）
上下文长度	最大 24k tokens
服务端口	8000（host 网络模式直接暴露）

部署链路：

硬件初始化（cltech-init，PCIe/算力规格/固件）
  → 驱动与固件加载（cltech-init 一步完成）
  → Docker 容器启动 vLLM 服务（8000 端口）
  → 状态校验 + curl 冒烟
  → Evalscope 分层压测 → 交付验收

2. 硬件初始化与驱动安装（底层优化第一步）

部署前执行硬件初始化脚本，一步完成 PCIe 模式、算力规格配置与底层驱动/固件加载：

bash

cltech-init -i 20260707 -g 2.8 --set-pcie-gen 3 --lyp8 -f

参数	配置值	作用
`-i`	20260707	硬件初始化版本号
`-g`	2.8	硬件算力规格
`--set-pcie-gen`	3	锁定 PCIe 3.0 总线模式（避免协商降速影响卡间通信）
`--lyp8`	-	适配 LYP8 硬件卡
`-f`	-	强制刷新硬件配置

执行无报错即代表驱动与固件安装完成，无单独驱动安装步骤。

⚠️ 这一步直接影响后续所有推理性能：PCIe 协商降档会拉低 TP=8 卡间 all-reduce 通信带宽，是高并发下吞吐不达标最常见的底层原因之一。执行后建议确认链路速率符合预期。

3. Docker 启动模型服务

3.1 完整启动脚本

bash

docker run -itd \
--name glm-5.2 \
--privileged \
--pid=host \
--net host \
--shm-size 128G \
--cap-add=SYS_PTRACE \
--security-opt seccomp=unconfined \
-v /data:/data \
-e CL_DRIVER_PATH=/usr/local/cltech/driver \
-e VLLM_DLC_INDEX_TOPK=256 \
-e VLLM_USE_V2_MODEL_RUNNER=1 \
-e DLC_SYN_GRAPH_CACHE=1 \
-e OMP_NUM_THREADS=8 \
-e DLC_SYN_COPY_ASYNC=O2 \
-e DLC_SYN_URING=0 \
-e VLLM_USE_DLC_COL_MAJOR_MATMUL=1 \
hangzhou-harbor.infraai.top/qingting/vllm_glm5.2_20260728 \
bash -c 'vllm serve \
--model /data/models/GLM-5.2-MTP-Mix/ \
--dtype bfloat16 \
--gpu-memory-utilization 0.99 \
--trust-remote-code \
--no-enable-prefix-caching \
-tp 8 \
--enable-expert-parallel \
--enable-auto-tool-choice \
--tool-call-parser glm47 \
--reasoning-parser glm45 \
--block-size 256 \
--compilation-config \
'"'"'{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY"}'"'"' \
--max-num-seqs 1 \
--hf-overrides \
'"'"'{"use_index_cache":true,"index_topk_pattern":"FFFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSSFSSS"}'"'"' \
--max-num-batched-tokens 2048 \
--no-scheduler-reserve-full-isl \
--enable-log-requests \
--max-model-len 24k \
--speculative-config \
'"'"'{"num_speculative_tokens":5,"method":"deepseek_mtp"}'"'"' \
moe ep size 2'

3.2 容器基础参数

参数	配置值	用途
`--name`	glm-5.2	容器命名
`--privileged`	-	开启容器完整宿主机权限（访问加速卡设备）
`--pid=host`	-	共享宿主机 PID 命名空间
`--net host`	-	共享宿主机网络，直接暴露 8000 端口
`--shm-size`	128G	共享内存大小，适配大模型 KV 缓存与 TP 通信
`-v /data:/data`	-	挂载宿主机模型存储目录

3.3 服务启动状态校验

bash

docker logs -f glm-5.2

出现以下关键信息代表服务就绪：

模型权重加载完成提示；
Uvicorn running on http://0.0.0.0:8000；
vLLM engine 初始化完成、编译 Graph 缓存就绪。

4. 分层性能优化详解

性能优化按「硬件底层 → 驱动/运行时 → vLLM 引擎 → 模型算法」四层理解，每一层的开关都已固化在启动脚本中，本节说明各项的原理与调优方向。

4.1 硬件底层优化

优化项	配置	收益
PCIe 模式锁定	`cltech-init --set-pcie-gen 3`	保证 8 卡互联带宽稳定，避免协商降速拖垮 TP 通信
算力规格标定	`cltech-init -g 2.8`	按标称算力运行，防止硬件保守降频
共享内存	`--shm-size 128G`	KV 缓存与跨进程通信不走慢速路径

4.2 驱动 / 运行时环境变量优化

环境变量	值	作用
`CL_DRIVER_PATH`	`/usr/local/cltech/driver`	底层硬件驱动路径
`VLLM_USE_V2_MODEL_RUNNER`	`1`	启用 V2 版推理运行时，调度与执行路径更优
`DLC_SYN_GRAPH_CACHE`	`1`	开启 Graph 编译缓存，加速二次启动、稳定解码执行图
`DLC_SYN_COPY_ASYNC`	`O2`	H2D/D2H 拷贝异步化（O2 级），隐藏数据传输延迟
`DLC_SYN_URING`	`0`	关闭 io_uring 路径（当前版本下更稳）
`VLLM_USE_DLC_COL_MAJOR_MATMUL`	`1`	使用列主序矩阵乘 kernel，贴合硬件计算单元布局
`VLLM_DLC_INDEX_TOPK`	`256`	索引检索 TopK 数量，配合稀疏注意力索引缓存
`OMP_NUM_THREADS`	`8`	CPU 并行线程数，避免 OMP 线程争抢拖慢调度

4.3 vLLM 引擎参数优化

参数	配置	说明
`--dtype`	bfloat16	推理精度
`--gpu-memory-utilization`	0.99	显存吃满，最大化 KV 缓存容量
`-tp`	8	8 卡张量并行
`--enable-expert-parallel` + `moe ep size 2`	-	MoE 专家并行，专家权重按 2 组分片，降低单卡显存压力并提升专家计算并行度
`--block-size`	256	KV 缓存分页块大小，大块降低管理开销
`--compilation-config`	`{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY"}`	Graph 编译仅对解码阶段启用全量捕获，兼顾启动耗时与解码性能
`--max-num-batched-tokens`	2048	单批最大 token 数，控制 prefill 分块
`--max-model-len`	24k	最大上下文 24000 tokens
`--no-scheduler-reserve-full-isl`	-	调度器不为完整输入长度预留空间，提升长输入场景调度效率

4.4 模型算法层优化

优化项	配置	收益
MTP 投机解码	`--speculative-config {"num_speculative_tokens":5,"method":"deepseek_mtp"}`	每步预生成 5 个候选 token，实测接受率 72.6%，解码吞吐提升显著
稀疏注意力索引缓存	`--hf-overrides {"use_index_cache":true,"index_topk_pattern":"FFF..."}`	按层交替启用索引缓存（F=关闭/S=开启模式），长上下文注意力开销大幅下降

4.5 可开关的调优项（A/B 对比用）

以下两项默认关闭/固定，压测阶段建议做消融实验量化收益（见 6.5）：

Prefix 缓存：默认 --no-enable-prefix-caching，多轮对话/固定前缀业务可改为 --enable-prefix-caching，命中率高的业务 TTFT 可大幅降低；
--max-num-seqs：当前为 1（单批单序列，面向低延迟交付场景）。如需提升高并发吞吐，可逐步调大（如 4/8/16），代价是单请求 TPOT 恶化，需按压测结果权衡。

5. 冒烟功能测试

5.1 curl 调用

bash

curl -X POST http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "/data/models/GLM-5.2-MTP-Mix/",
"max_tokens": 1024,
"messages": [
{
"role": "user",
"content": "1+1等于多少，直接说答案"
}
],
"stream": true,
"temperature": 0
}'

5.2 预期结果

流式返回 2，无报错、无超时、无乱码，代表模型基础推理功能正常。

6. 性能测试方案（重新设计）

6.1 测试目标

建立单并发基线与并发梯度容量模型，输出线上容量规划依据；
量化各优化项（投机解码、prefix 缓存、索引缓存）的实际收益（消融对比）；
验证典型业务输入/输出比例下的吞吐与延迟 SLA；
验证极限上下文、极限显存占用与长时间运行的稳定性。

6.2 前置条件

模型容器正常启动，docker logs 无报错；
Evalscope 评估容器正常拉起，网络可通 8000 端口：

bash

docker run -it -v /data/:/data/ --net host hangzhou-harbor.infraai.top/library/evalscope:0721 bash

宿主机无其他高负载进程，GPU/CPU/内存资源独占；
监控采集就绪：显存/利用率/温度/功耗、CPU、内存、容器 shm、网络带宽（与压测时间轴对齐）。

6.3 测试方法论（相对原版的改进）

原版方案每个场景只跑一轮，容易把冷启动、预热波动计入结果。改进约定：

预热：每个场景正式采样前先以相同并发跑 ≥2 分钟预热（Graph 缓存、KV 池、驱动状态进入稳态），预热数据不计入报告；
稳态采样：报告以 Evalscope 的 Steady (drop 20%)（掐头去尾）为准，Overall 仅作参考；
重复取中位：每个场景独立跑 3 轮，指标取中位数，剔除异常轮次（硬件温度超限、宿主机抖动）；
一次只改一个变量：消融实验除被测开关外，启动参数与负载配置完全一致；
时间轴对齐：压测窗口与硬件监控打点严格对齐，便于定位拐点成因。

6.4 场景矩阵

#	场景	并发	Prompt/Output	请求数/时长	目的
S1	单并发基线	1	1024 / 1024	20	基线吞吐、单用户延迟
S2	并发梯度容量	2/4/8/16 逐档	1024 / 1024	每档 30 且 ≥5min	找最大稳定并发与吞吐拐点
S3	短输入长输出	4	256 / 2048	20	生成类业务（文案/代码/长推理）
S4	长输入短输出	2	8192 / 512	15	文档问答、摘要
S5	极限上下文	1	20000 / 1024	5	验证 24k 上限，防 OOM
S6	Prefix 缓存	4	1024(+1024 固定前缀) / 1024	30	缓存复用收益（需开启 `--enable-prefix-caching`）
S7	消融 A/B	1 + 4	1024 / 1024	各 20	量化优化项收益（见 6.5）
S8	耐久稳定性	8	1024 / 1024	7200s	内存/显存泄漏、吞吐漂移

S2 单档示例（并发 4）：

bash

evalscope perf \
--parallel 4 \
--number 30 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--max-tokens 1024 \
--min-tokens 1024 \
--min-prompt-length 1024 \
--max-prompt-length 1024

S3 短输入长输出：

bash

evalscope perf \
--parallel 4 \
--number 20 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--max-tokens 2048 \
--min-tokens 2048 \
--min-prompt-length 256 \
--max-prompt-length 256

S4 长输入短输出：

bash

evalscope perf \
--parallel 2 \
--number 15 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--max-tokens 512 \
--min-tokens 512 \
--min-prompt-length 8192 \
--max-prompt-length 8192

S5 极限上下文（并发 1，避免 OOM）：

bash

evalscope perf \
--parallel 1 \
--number 5 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--max-tokens 1024 \
--min-tokens 1024 \
--min-prompt-length 20000 \
--max-prompt-length 20000

S6 Prefix 缓存（先改启动参数为 --enable-prefix-caching 重启服务）：

bash

evalscope perf \
--parallel 4 \
--number 30 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--prefix-length 1024 \
--max-tokens 1024 \
--min-tokens 1024 \
--min-prompt-length 1024 \
--max-prompt-length 1024

S8 耐久压测：

bash

evalscope perf \
--parallel 8 \
--duration 7200 \
--model "/data/models/GLM-5.2-MTP-Mix/" \
--url http://127.0.0.1:8000/v1/chat/completions \
--api openai \
--dataset random \
--max-tokens 1024 \
--min-tokens 1024 \
--min-prompt-length 1024 \
--max-prompt-length 1024

6.5 消融实验设计（S7）

基线 = 第 4 节完整优化配置。每轮只关/开一个变量：

实验	变量	对比项	预期观测
A	投机解码开/关	`num_speculative_tokens=5` vs 去掉 speculative-config	解码吞吐差值、接受率与吞吐的关系
B	索引缓存开/关	`use_index_cache` true/false	长输入（8k/20k）TTFT 差值
C	Prefix 缓存开/关	配合 S6	Cached Prompt tok/s、TTFT 差值
D	`--max-num-seqs` 1/4/8	并发 8 固定负载	总吞吐 vs TPOT 恶化的权衡曲线

6.6 采集指标清单

业务接口指标（Evalscope 输出）：

基础汇总：总生成 token、平均吞吐 tokens/sec、总耗时、请求成功率；
并发指标：RPS、单并发解码吞吐、投机解码接受率；
延迟指标：平均 / P50 / P99 / Max 总延迟 Latency、TTFT 首 token 延迟、TPOT 单 token 生成耗时；
缓存指标：New Prompt tok/s、Cached Prompt tok/s。

硬件资源指标（与压测时间轴同步采集）：

GPU：显存占用峰值、利用率、卡温度、功耗；
CPU：整机平均使用率、OMP 线程负载；
内存：宿主机内存、容器 shm 占用变化曲线；
网络：容器进出带宽、端口连接数。

6.7 验收 SLA

负载场景	吞吐底线	TTFT P99 上限	TPOT 平均	成功率	投机解码接受率
单并发 1024+1024	≥30 token/s	≤1500ms	≤40ms	100%	≥70%
并发 4 标准负载	≥80 token/s	≤2500ms	≤45ms	100%	≥68%
并发 8 标准负载	≥130 token/s	≤4000ms	≤55ms	≥99.5%	≥65%
长输入 8k 场景	≥12 token/s	≤5000ms	≤45ms	100%	≥65%
24k 极限上下文	≥5 token/s	≤8000ms	≤60ms	100%	≥60%
耐久 2h 压测	吞吐波动 ≤10%	无持续上涨	平稳无恶化	100%	无持续下跌

6.8 异常判定（满足任一即不达标）

请求成功率低于 99%；
P99 TTFT 超 SLA 阈值 20% 以上；
压测中显存持续上涨、出现 OOM 重启；
标准负载下投机解码接受率低于 60%；
耐久测试吞吐持续下跌、延迟持续走高；
GPU 温度超过 85℃、硬件降频。

6.9 交付物

各场景 Evalscope 完整性能报告（3 轮原始数据 + 中位数汇总）；
硬件资源监控时序图表（与压测窗口对齐）；
并发梯度吞吐-延迟对比汇总表（含拐点标注）；
消融实验收益对比表（投机解码 / 索引缓存 / prefix 缓存 / max-num-seqs）；
极限上下文与耐久场景稳定性说明；
线上推荐并发容量与输入/输出长度限制建议。

7. 基准压测结果样例（单并发 S1 实测）

7.1 汇总

字段	数值	说明
Test Dataset	random	随机测试数据集
API Type	openai	OpenAI 兼容接口
Total Generated tokens	10,240	总生成 token 数量
Avg Output Rate	30.16 tokens/sec	平均生成吞吐
Total Test Time	339.57s	总压测耗时
Success	100.0%	请求全部成功

7.2 单请求延迟（并发=1）

Metric	avg	p50	p99	max
Latency (s)	33.957	34.710	40.950	40.950
TTFT (ms)	1317.3	1323.7	1369.4	1369.4
TPOT (ms)	31.9	32.6	38.7	38.7
Decode tok/s	31.34	-	-	-
Spec. Accept Rate	72.6%	-	-	-

7.3 链路吞吐

指标	Overall	Last 30s	Steady (drop 20%)
Completion tok/s	30.16	28.84	30.78
New Prompt tok/s	30.16	28.84	30.78
Cached Prompt tok/s	0.00	0.00	0.00

7.4 结论

单并发稳定吞吐 30.16 token/s（稳态 30.78），投机解码接受率 72.6%，MTP 加速确认生效；
TTFT 平均 1.3s，1024 输入场景首包延迟可控；
全部请求 100% 成功，满足 SLA；
无缓存命中，全部为全新 Prompt 推理（符合默认关闭 prefix 缓存的配置）。

8. 交付验收清单

[ ] 硬件初始化（cltech-init）执行无报错，PCIe 速率符合预期；
[ ] Docker 容器正常拉起，日志无加载异常；
[ ] curl 冒烟测试正常返回推理结果；
[ ] 单并发基线压测满足 SLA（吞吐 ≥30 token/s、成功率 100%）；
[ ] 场景矩阵按需执行完毕，各场景指标满足对应 SLA（3 轮中位数）；
[ ] 投机解码接受率 ≥70%，推理加速特性生效；
[ ] 极限 24k 上下文场景无 OOM、推理正常返回；
[ ] 耐久 2 小时测试无内存/显存泄漏、服务无重启崩溃；
[ ] 交付物（报告、监控图、容量建议）齐全。

9. 常见问题

现象	排查方向
高并发吞吐远低于 SLA	确认 PCIe 协商速率（4.1）；确认 `--max-num-seqs` 配置（4.5-D）
启动很慢但每次正常	Graph 编译为首次耗时项，确认 `DLC_SYN_GRAPH_CACHE=1` 已开启，二次启动应明显变快
长输入 TTFT 超阈值	确认 `use_index_cache` 与 `VLLM_DLC_INDEX_TOPK=256` 生效（消融实验 B）
压测中吞吐突然下跌	检查卡温是否超 85℃ 触发降频；检查宿主机是否有其他进程抢占 CPU（`OMP_NUM_THREADS=8` 之外的负载）
投机解码接受率偏低	高温降频或驱动版本不匹配会导致接受率下降，先核对 cltech-init 版本号

GLM-5.2（MTP-Mix）部署教程、性能优化与压测方案 ​

1. 环境信息与部署架构 ​

2. 硬件初始化与驱动安装（底层优化第一步） ​

3. Docker 启动模型服务 ​

3.1 完整启动脚本 ​

3.2 容器基础参数 ​

3.3 服务启动状态校验 ​

4. 分层性能优化详解 ​

4.1 硬件底层优化 ​

4.2 驱动 / 运行时环境变量优化 ​

4.3 vLLM 引擎参数优化 ​

4.4 模型算法层优化 ​

4.5 可开关的调优项（A/B 对比用） ​

5. 冒烟功能测试 ​

5.1 curl 调用 ​

5.2 预期结果 ​

6. 性能测试方案（重新设计） ​

6.1 测试目标 ​

6.2 前置条件 ​

6.3 测试方法论（相对原版的改进） ​

6.4 场景矩阵 ​

6.5 消融实验设计（S7） ​

6.6 采集指标清单 ​

6.7 验收 SLA ​

6.8 异常判定（满足任一即不达标） ​

6.9 交付物 ​

7. 基准压测结果样例（单并发 S1 实测） ​

7.1 汇总 ​

7.2 单请求延迟（并发=1） ​

7.3 链路吞吐 ​

7.4 结论 ​

8. 交付验收清单 ​

9. 常见问题 ​

GLM-5.2（MTP-Mix）部署教程、性能优化与压测方案

1. 环境信息与部署架构

2. 硬件初始化与驱动安装（底层优化第一步）

3. Docker 启动模型服务

3.1 完整启动脚本

3.2 容器基础参数

3.3 服务启动状态校验

4. 分层性能优化详解

4.1 硬件底层优化

4.2 驱动 / 运行时环境变量优化

4.3 vLLM 引擎参数优化

4.4 模型算法层优化

4.5 可开关的调优项（A/B 对比用）

5. 冒烟功能测试

5.1 curl 调用

5.2 预期结果

6. 性能测试方案（重新设计）

6.1 测试目标

6.2 前置条件

6.3 测试方法论（相对原版的改进）

6.4 场景矩阵

6.5 消融实验设计（S7）

6.6 采集指标清单

6.7 验收 SLA

6.8 异常判定（满足任一即不达标）

6.9 交付物

7. 基准压测结果样例（单并发 S1 实测）

7.1 汇总

7.2 单请求延迟（并发=1）

7.3 链路吞吐

7.4 结论

8. 交付验收清单

9. 常见问题