服务器配置和环境#

项目	配置
主机名	H200
系统	Ubuntu 26.04 LTS
Kernel	Linux 7.0.0-15-generic
CPU	2 x Intel Xeon Platinum 8558
CPU 核心/线程	96C / 192T
内存	2.0 TiB
GPU	8 x NVIDIA H200
单卡显存	143771 MiB
GPU 互联	nvidia-smi topo 显示 8 卡之间为 NV18
NVIDIA Driver	595.71.05
CUDA	13.2
Docker 镜像	vllm/vllm-openai
Docker 镜像 ID	sha256<894456ff199741e4e6a06292e360e6582b79a8f450f34d48b4bd8a4f35124b7d>
vLLM 版本	0.1.dev17670+g7d24aa6f2
系统盘	MR9560-8i, 893.8G
数据盘	2 x 7T XFSP4157T60000N, 挂载到 /data/data1 与 /data/data2

模型	路径
GLM-5.1-FP8	/data/data2/vllm/models/ZhipuAI_GLM-5.1-FP8
GLM-5.2-FP8	/data/data2/vllm/models/ZhipuAI_GLM-5.2-FP8

部署配置参考过 vLLM 官方 recipe：

测试方法#

长上下文测试使用 OpenAI 兼容接口发送 /v1/completions 请求。主测试配置如下：

项目	配置
Tensor Parallel	8
KV cache dtype	fp8
max_model_len	200000
max_num_seqs	1 或 2
gpu_memory_utilization	GLM-5.2 长上下文并发测试为 0.87
MTP	关闭
enforce_eager	开启
长上下文输出长度	32 tokens

短上下文高并发测试使用同一类 /v1/completions 请求，客户端同时发起 8 或 32 个请求。prompt 为不同内容，不依赖 prefix cache。

项目	配置
Tensor Parallel	8
KV cache dtype	fp8
max_model_len	4096
max_num_seqs	64
gpu_memory_utilization	0.84
MTP	关闭
输入长度	约 2000 tokens
输出长度	512 tokens
用户并发	8、32

长上下文测试结果#

模型	上下文	用户并发	成功	平均 prompt tokens	平均输出 tokens	平均延迟	Prompt 吞吐
GLM-5.1-FP8	120K	1	1/1	120058	32	28.05s	4212 tok/s
GLM-5.1-FP8	120K	2	2/2	120057	32	49.10s	4828 tok/s
GLM-5.1-FP8	198K	1	1/1	198032	32	55.58s	3519 tok/s
GLM-5.1-FP8	198K	2	2/2	198048	32	94.48s	4134 tok/s
GLM-5.2-FP8	120K	1	1/1	119934	32	29.23s	4029 tok/s
GLM-5.2-FP8	120K	2	2/2	119959	32	45.62s	5170 tok/s
GLM-5.2-FP8	198K	1	1/1	197944	32	62.82s	3119 tok/s
GLM-5.2-FP8	198K	2	2/2	197943	32	67.36s	5731 tok/s

同机对比中，GLM-5.2-FP8 在 120K 并发 2 和 198K 并发 2 下吞吐更高；在单请求长上下文下，GLM-5.1-FP8 的延迟和 prompt 吞吐更好。这组长上下文每个场景请求数较少，结论应理解为本轮部署和脚本下的记录，不应扩大为通用性能结论。

场景	GLM-5.2 相对 GLM-5.1 的平均延迟	GLM-5.2 相对 GLM-5.1 的 Prompt 吞吐
120K，并发 1	+4.2%	-4.3%
120K，并发 2	-7.1%	+7.1%
198K，并发 1	+13.0%	-11.3%
198K，并发 2	-28.7%	+38.6%

GLM-5.2 1M 上下文启动尝试#

GLM-5.2-FP8 额外尝试了 1M 上下文启动，主要参数如下：

项目	配置
max_model_len	1048576
Tensor Parallel	8
KV cache dtype	fp8
max_num_seqs	1
gpu_memory_utilization	0.90
MTP	关闭
enforce_eager	开启

服务在 KV cache 规划阶段失败，没有进入可请求状态。日志中的关键错误如下：

1
ValueError: To serve at least one request with the model's max seq len (1048576), (52.68 GiB KV cache is needed, which is larger than the available KV cache memory (21.08 GiB). Based on the available memory, the estimated maximum model length is 419648.

因此，在本次 8xH200、FP8 KV cache、gpu_memory_utilization=0.90 的配置下，GLM-5.2-FP8 没有完成 1M 上下文服务启动。估算的可启动最大长度为 419648 tokens。看来想跑得8卡B200了，找机会试试。

短上下文 8/32 用户并发测试#

短上下文测试使用约 2K input / 512 output，观察并发 8 和 32 下的吞吐。

模型	用户并发	成功	平均 prompt tokens	平均输出 tokens	平均延迟	请求吞吐	Prompt 吞吐	输出吞吐	总吞吐
GLM-5.1-FP8	8	8/8	1975.0	512	138.22s	0.0578 rps	114.1 tok/s	29.6 tok/s	143.6 tok/s
GLM-5.1-FP8	32	32/32	1980.3	512	156.67s	0.2036 rps	403.1 tok/s	104.2 tok/s	507.3 tok/s
GLM-5.2-FP8	8	8/8	1966.6	512	128.18s	0.0622 rps	122.4 tok/s	31.9 tok/s	154.3 tok/s
GLM-5.2-FP8	32	32/32	1977.2	512	121.18s	0.2629 rps	519.9 tok/s	134.6 tok/s	654.5 tok/s

在短上下文高并发场景中，GLM-5.2-FP8 的吞吐更高，尤其是并发 32：

场景	GLM-5.2 相对 GLM-5.1 的平均延迟	GLM-5.2 相对 GLM-5.1 的请求吞吐	GLM-5.2 相对 GLM-5.1 的总吞吐
2K/512，并发 8	-7.3%	+7.8%	+7.4%
2K/512，并发 32	-22.7%	+29.2%	+29.0%

vLLM 启动日志中的容量信息如下：

模型	max_model_len	模型加载显存记录	可用 KV cache	GPU KV cache size	4096 tokens/request 最大并发估算
GLM-5.1-FP8	4096	89.86 GiB	17.81 GiB	311104 tokens	75.95x
GLM-5.2-FP8	4096	89.38 GiB	18.30 GiB	364160 tokens	88.91x

搜索文章

GLM-5.1/5.2 FP8 在 8xH200 上的上下文与并发测试记录

服务器配置和环境#

测试方法#

长上下文测试结果#

GLM-5.2 1M 上下文启动尝试#

短上下文 8/32 用户并发测试#