一、GLM-5.3-Flash（4×H20）

Flash 约 320B 总参数、激活 18B，原生支持多模态与 1M Context，4×H20 就能部署

• 部署说明
  这次使用的是官方 Native FP8 Checkpoint，共 62 个 Safetensors 分片，权重 Index 记录约 328.3 GB。4 张 141 GB H20 做 TP4 后，SGLang 每卡权重显存约 75.27 GiB，vLLM 约 75.65 GiB。

1.1 核心配置

GPU                  4 × H20 141 GB
Checkpoint           官方 Native FP8
Parallel             TP4
KV Cache             BF16
Context              1,048,576
MTP                  Off
API                   OpenAI-compatible

项目	本次配置
模型	GLM-5.3-Flash Native FP8
模型架构	Glm5NextForConditionalGeneration
权重	62 个分片，Index 记录 328,326,771,576 Byte
GPU	4×NVIDIA H20 141 GB / 每套引擎
并行	TP=4；SGLang 额外 EP=4
KV Cache	BF16
Context	1,048,576
MTP	关闭，先测 Target-only 基线
驱动	580.126.20
重复	短压、4K Prefill 和 1K Decode 各 3 轮

SGLang 额外使用 EP4、DSA Attention、TileLang Prefill/Decode、Triton Linear Attention 和 DeepGEMM MoE。

• 为什么先关 MTP？
  因为 MTP 会同时改变 Decode 路径、显存、Draft/Verify 和 CUDA Graph 形状。如果一开始就把它打开，性能变化很难解释。Day-1 实测最怕“所有高级选项一起开”，最后只知道数字变了，却不知道为什么。

1.2 查看功能正确性

功能正确性：不能只问一句“你好”

能力	SGLang	vLLM 预览镜像
/v1/models	通过	通过
reasoning_effort=low/high/max	通过	通过
独立 reasoning_content	有	未拆分，内容仍在普通字段
结构化 Tool Call	通过	通过
真实图片输入	通过	通过
视频输入	未测	未测
OpenWebUI 真实对话	通过	未注册，临时服务已释放

SGLang 的 OpenAI 兼容服务已经接入 OpenWebUI，模型列表和真实 Chat 均返回成功。这项验证的意义不是证明 UI 好看，而是确认跨服务访问、模型名、Chat Template、Parser 和流式响应能够一起工作。

vLLM 能正确完成 Reasoning 请求，但没有把思考过程拆分到独立的 reasoning_content 字段。因此，“请求返回 200”与“前端能按预期展示 Reasoning”仍是两件事。

1.3 启动数据、测试吞吐和请求

1.3.1 SGLang启动：TP4 + EP4，先关 MTP

本次 SGLang 采用 DSA Attention，Prefill/Decode 都使用 TileLang，KDA Linear Attention 使用 Triton，MoE 使用 DeepGEMM。关键配置如下：

TP=4, EP=4
FP8 Weight + BF16 KV Cache
DSA Prefill/Decode = TileLang
Linear Attention = Triton
MoE Runner = DeepGEMM
Max Running Requests = 32
Chunked/Max Prefill Tokens = 8192
MTP = Off
Reasoning Parser = glm45
Tool Parser = glm47

为什么第一轮关闭 MTP？因为 MTP 会同时改变延迟、Decode 吞吐、显存和 CUDA Graph 形状。先拿到 Target-only 基线，后面再做单变量开关，才知道性能变化来自模型 Kernel， 还是 Draft/Verify。

SGLang 实际启动过程：

阶段	实测
权重加载	130.59 s
权重显存 / GPU	75.27 GiB
BF16 KV Cache / GPU	19.93 GiB
KV Token Pool	1,683,136 Token
容器创建到服务 Ready	约 9 分 51 秒

模型还会占用 KDA/Mamba State Pool，所以不能只按权重加 KV Cache 估算显存。服务启动后 我保留了 /health、Readiness Probe 和较长的 Startup Probe；对这种首发大模型， 默认几十秒探针只会制造无意义重启。

1.3.2 vLLM启动: TP4 可以跑，但启动阶段更重

vLLM 同样使用 TP4、FP8 Weight、BF16 KV Cache、1M Max Model Length 和 MTP Off。 它最终成功 Ready，但启动日志给出了几条必须保留在报告里的信息：

默认 10 分钟的 Deployment Progress Deadline 会先报超时，但 Pod 没有崩溃，完成 DeepGEMM 与 FlashInfer Autotune 后正常 Ready。生产 YAML 应把 Progress Deadline 和 Startup Probe 放宽到 20～30 分钟，并用 Readiness 控制流量，而不是看到 10 分钟未 Ready 就循环重建 Pod。

另外两条警告也很关键：当前没有适配此模型的 MLA Prefill Backend，Sparse MLA 退回 Top-k MQA Path；镜像中也没有 H20 专用的 FP8 MoE 调优配置，使用的是默认配置。 这不影响“能跑”的结论，却意味着本文性能不是 vLLM 在 H20 上的最终上限。

公开的 Kubernetes Deployment、Service、探针与测试脚本在 examples/glm53-flash-day1。 示例只保留通用接口，实际环境中的存储、镜像同步和入口实现不属于本文范围。

阶段	实测
最慢 Rank 权重加载	365.69 s
权重显存 / GPU	75.65 GiB
KV Cache / GPU	29.94 GiB
KV Token Pool	2,735,415 Token
DeepGEMM Warmup	1,102 个 Kernel，约 92 s
CUDA Graph Capture	15 s / 0.95 GiB 每卡
容器创建到服务 Ready	约 12 分钟

1.4 测试吞吐

1.4.1 短请求吞吐：三轮中位数之外，还要看波动¶

短压固定输入 128、输出 64，使用随机 Token ID、固定长度、无请求速率上限。每个并发 跑三轮，图中使用三轮中位数

vLLM 在并发 16/32 的稳定吞吐更高，并发 32 的三轮 Output TPS 为 1,145.4、1,156.9、 1,166.4。SGLang 并发 32 为 847.1、842.4、853.5。

并发	SGLang Output TPS	vLLM Output TPS	SGLang P95 TTFT	vLLM P95 TTFT
1	74.7	107.7	188 ms	183 ms
4	234.6	225.9	340 ms	559 ms
8	392.4	257.2	414 ms	11.76 s
16	572.2	735.8	428 ms	565 ms
32	847.1	1,156.9	1.10 s	695 ms

但并发 4/8 不能只看 vLLM 的最快轮。vLLM 并发 8 的三轮 Output TPS 是 162.2、 410.8、257.2；其中第一轮 P99 TTFT 达 23.43 秒，第三轮 P95 TTFT 仍有 11.76 秒。 SGLang 第一次遇到并发 4/8/16 也分别出现约 10.9、12.5、13.6 秒 P95 TTFT，随后两轮 恢复稳定。这与两套 Runtime 日志中的 JIT 编译吻合。

正确的工程结论不是“谁绝对更快”，而是：vLLM 预览镜像展示了更高的并发吞吐潜力； SGLang 在完成第一次 Shape Warmup 后更稳定。上线前必须把业务实际并发和长度组合纳入 Warmup，且监控 P99，不能只盯平均 TPS。

1.4.2 4K Prefill 与 1K Decode

4K 输入、128 输出、并发 4 的三轮结果：

引擎	Output TPS	P95 TTFT
SGLang	143.8 / 143.3 / 143.6	1.797 / 1.796 / 1.779 s
vLLM	116.9 / 172.1 / 172.8	7.209 / 1.798 / 1.799 s

第一轮再次说明 Warmup 的影响。去掉首次新 Shape 后，vLLM 吞吐更高，两边 P95 TTFT 基本相同。

128 输入、1,024 输出的 Decode 测试更清晰：

并发	SGLang Output TPS	vLLM Output TPS	SGLang P95 TPOT	vLLM P95 TPOT
1	92.3	148.5	10.71 ms	6.56 ms
8	461.0	685.0	17.19 ms	11.47 ms

在本次 MTP Off 基线中，vLLM 的 Decode 路径优势明显。它是否能抵消前面看到的 Warmup 波动，要由真实流量分布决定。

1.4.3 1M 上下文：成功返回不等于检索正确

长上下文测试每次先清理 Prefix Cache，固定输出 128 Token、并发 1。32K 两套 Runtime 都额外跑了一次：vLLM 首次新 Shape TTFT 为 14.60 秒，Warmup 后是 3.43 秒；图中使用 后者，并显式保留排除说明。

两套引擎都完成了接近原生上限的请求。更重要的是，我把唯一标识分别埋在上下文的 10%、50%、90% 位置，并要求模型精确返回：

• SGLang：11/11 通过；32K、128K、257K 各三个位置，512K 与近 1M 测中间位置；
• vLLM：8/8 通过；32K、257K 各三个位置，512K 与近 1M 测中间位置。

因此本次结论是“冷请求成功且指定 Needle 可检索”，而不只是 HTTP 200。它仍不代表 模型能对任意 1M 长文完成复杂推理；Needle 只是最低正确性门槛。

1.4.3 262K 风险边界复测

测试后 SGLang Pod 仍为 0 Restart。本次未复现社区曾报告的约 262K 冷 Prefill 后 首 Token 崩溃，但单一 H20 配置的成功不能宣布问题对所有硬件、Backend 和镜像都消失。

1.4.4 Prefix Cache：一定要同时看时间和服务端 Metrics

固定约 4,400 Token Prompt，第一次冷请求后完全重复五次。

SGLang 的证据链完整：冷 TTFT 456.7 ms，热请求中位数 198.2 ms，下降 56.6%；服务端 Cache Hit Rate 从 0 上升到 98.55%。这可以明确写成 Prefix Cache 生效。

vLLM 预览镜像的服务端 Metrics 也显示命中：该轮 Query Token 增量 26,472，Hit Token 增量 17,280，增量命中率约 65.28%；冷 E2E 651.1 ms，热 E2E 中位数 296.5 ms。 但它的 Preview Completions API 忽略了 echo=false，Chat 流式测试又有部分请求没有 可见首块内容，导致 TTFT 口径不可靠。因此本文只发布 vLLM 的 E2E 与服务端 Metrics， 不把那个不稳定的 TTFT 和 SGLang 放在同一张柱状图里。

这也是公开压测常见的口径错误：参数写了 enable_prefix_caching，不等于缓存真的命中； 客户端看起来更快，也可能只是接口返回语义变了。两类证据必须互相印证。

1.5 选择和备注

如果今天就要在 H20 上提供一个能让团队使用的 OpenAI 兼容服务，我会先选择 SGLang：

官方 Cookbook 的硬件与 Backend 说明更完整；

• 1.Reasoning、Tool Call、图片、Cache 和 OpenWebUI 已在本次环境闭环；
• 2.新 Shape 的首次尾延迟可以通过覆盖业务矩阵的 Warmup 缓解；
• 3.本次 1M 与 262K 边界测试没有引发重启。

如果目标是研究高并发吞吐，我会保留 vLLM 预览镜像继续跟进。并发 32 和 1K Decode 数据很有吸引力，但在主仓支持合入、H20 MoE 配置补齐、Sparse MLA Prefill 与 API 边界稳定之前，不应把这次“能运行”直接等价为正式版本生产就绪。

无论选哪一个，Kubernetes 侧都建议：

• 1.Startup Probe 和 Progress Deadline 至少覆盖 20～30 分钟冷启动；
• 2.Readiness 成功后才接流量，Liveness 不要在权重加载阶段杀进程；
• 3.固定镜像 Digest、模型 Revision 与完整启动参数；
• 4.用真实的长度×并发矩阵做 Warmup，并单独看首轮 P95/P99；
• 5.Prefix Cache 同时采集客户端时间和服务端 Query/Hit Metrics。

二、GLM-5.3（8×H20）

GLM-5.3 的参数与激活规模都更大，本轮开源权重是文本模型，我们使用 8×H20、TP8 和 128K 服务窗口来验证它的推理表现。先后用 SGLang 和 vLLM 部署 GLM-5.3 原生 FP8 权重，完整走了一遍：
权重挂载 → 镜像同步 → 服务启动 → OpenAI API 功能验收 → OpenWebUI 接入 → 9 组压测 → 释放 GPU

最终，两套引擎各完成 9 个 Case、每个 Case 3 轮，共留下 54 份完整结果、7,680 个完成请求，失败请求为 0。

2.1 测试配置

• 模型：zai-org/GLM-5.3，Native FP8，约 743B 总参数 / 39B 激活参数；
• GPU：单节点 8×H20-3e 141GB，Tensor Parallel = 8；
• 服务窗口：131,072 Token；
• SGLang：固定 amd64 镜像 Digest，Hopper 默认 BF16 KV Cache；
• vLLM：0.28.0，固定 amd64 镜像 Digest，KV Cache 为 auto；
• MTP、Prefix Cache、HiCache、Context Parallelism 全部关闭；
• 两边使用同一个 vllm bench serve 客户端、相同请求集合与参数；
• 每个 Case 跑 3 轮，正文使用逐指标中位数，不摘最快一轮。

2.2 测试结果

2.2.1 结果一：短请求，SGLang 吞吐全并发领先

并发数	SGLang 输出吞吐（tok/s）	vLLM 输出吞吐（tok/s）	SGLang 相对提升
1	90	69	+30.5%
4	289	183	+57.4%
8	459	331	+38.9%
16	656	601	+9.2%
32	964	815	+18.4%

测试配置：GLM-5.3 Native FP8，8×H20-3e，TP8，输入/输出长度为 128/64，取三轮测试中位数。指标为输出 Token 吞吐（tok/s），MTP、Prefix Cache 和 HiCache（SGLang 内置的分层 KV Cache） 均关闭。各并发场景下 SGLang 的吞吐均高于 vLLM，其中并发数为 4 时优势最大，提升 57.4%。

在输入/输出 128/64 的短请求里，SGLang 从 C1 到 C32 的输出吞吐全部更高，相对 vLLM 提升 9.2%～57.4%
最典型的是 C4：SGLang 为 288.50 tok/s，vLLM 为 183.33 tok/s，提升 57.4%。到 C32 时，两边分别达到 964.25 tok/s 和 814.68 tok/s。

2.2.2 结果二：短请求首 Token，SGLang 低 46.0%～75.4%

短请求首 Token 延迟：SGLang 延迟更低

并发数	SGLang P50 TTFT	vLLM P50 TTFT	SGLang 延迟降低
1	54 ms	210 ms	74.3%
4	98 ms	400 ms	75.5%
8	142 ms	393 ms	63.9%
16	210 ms	440 ms	52.3%
32	444 ms	821 ms	45.9%

测试配置：GLM-5.3 Native FP8、8×H20-3e、TP8，输入/输出长度为 128/64，指标为 P50 TTFT（首 Token 延迟）。TTFT 越低越好。在并发数 1～32 的测试中，SGLang 的 P50 TTFT 均低于 vLLM，延迟降低约 46.0%～75.5%。

对聊天、短 Agent 调用和高并发短输出，这组配置下 SGLang 的优势最清晰。

2.2.3 结果三：长 Prefill，首 Token 与完成时间出现分叉

输入放大到 4K 和 16K 后，结论不再是一边倒：

• 4K/128，C8：vLLM P50 TTFT 为 1.90s，SGLang 为 5.91s；
• 16K/256，C8：vLLM P50 TTFT 为 12.54s，SGLang 为 20.28s。

但固定输出长度下，SGLang 的 Decode 更快，四个长输入 Case 的输出吞吐仍高 7.3%～11.4%，P50 E2E 也低约 6.2%～10.6%。

换句话说：

• 用户非常在意“多久看到第一个字”的长 Prompt / RAG 交互，vLLM 当前配置更合适；
• 更在意整次请求完成时间和集群吞吐，SGLang 当前配置仍占优。

• 补充
  E2E 是 End-to-End Latency（端到端延迟），指从客户端发出请求，到接收完最后一个输出 Token 的总耗时。

2.2.4 9 个 Case 的完整中位数

下表各项数据的排列顺序均为 SGLang / vLLM。

Case	输出吞吐（tok/s）	P50 TTFT
128/64，C1	90.41 / 69.27	54.29 / 210.45 ms
128/64，C4	288.50 / 183.33	98.30 / 400.31 ms
128/64，C8	459.47 / 330.82	142.10 / 392.56 ms
128/64，C16	656.41 / 601.02	210.48 / 439.92 ms
128/64，C32	964.25 / 814.68	443.91 / 821.37 ms
4K/128，C4	100.07 / 93.31	3.45 / 2.75 s
4K/128，C8	115.40 / 103.63	5.91 / 1.90 s
16K/256，C4	53.57 / 49.76	12.43 / 10.46 s
16K/256，C8	57.67 / 53.24	20.28 / 12.54 s

2.3 选择规则

• 聊天、短 Agent、高并发短输出：优先 SGLang；
• 长 Prompt / RAG，且首 Token 体验最重要：优先评估 vLLM；
• 批处理或更看重完成时间与总体吞吐：优先 SGLang；
• 生产定型前：必须继续做 MTP、FP8 KV、Prefix Cache 和长上下文的单变量 A/B。

官方资料当前明确：vLLM 0.28.0+ 可在单节点 8×141GB H20/H200 上运行 GLM-5.3 原生 FP8；完整 1M Context 则指向 8×B200。SGLang Cookbook 已覆盖 GLM-5.3 的 DSA、MTP、Reasoning、Tool Call、HiCache 等能力，但其硬件矩阵没有点名 H20，所以本文对 SGLang 的表述是 Hopper/H20 实测可用，不是“官方 H20 认证”。

三、服务器Atlas 800 A2单机部署GLM-5.3-Flash （8 张昇腾 910B3）

3.1 部署配置清单

3.2 部署遇到的问题

3.3 参数调整推理性能

3.4 最终调优参数及参数说明

3.5 部署流程

四、问题总结

4.1 配置参考

GLM-5.3 约 743B 总参数、39B 激活参数，默认提供 Native FP8 权重。这里容易有一个误区：39B Active 指的是一次推理中被激活参与计算的参数规模，并不意味着只需要准备 39B 参数对应的显存

（1）Context：常用是 32K/128K，还是确实需要 256K、1M？
（2）并发：单用户验证、实验室多人使用，还是企业 API 服务？
（3）负载：Chat、Coding、Agent、RAG、长文档，哪一种是主场景？（4）验收：目标只是把模型跑起来，还是要达到明确的 TTFT、吞吐和稳定性指标？

vLLM 和 SGLang 应该直接选哪个？
没有必要先站队。短请求和长 Prompt 的表现会变化，功能支持与优化路径也在持续更新。更有效的方法是用自己的请求类型做一轮 A/B 基线，再决定生产 Runtime。

配置参考	更适合什么目标	选型时注意
8×H20（141GB/卡）	单节点 Native FP8 部署基线；企业/科研验证	建议先把 128K 或实际业务窗口跑稳，再逐步放大；同时确认 8 卡拓扑、P2P/NCCL 与软件栈。
8×H200（141GB/卡）	更高吞吐、并发与生产性能验证	显存容量与 141GB H20 同级，选 H200 的价值更多在性能和带宽，是否值得上要结合负载与预算。
8×B200（180GB/卡）	完整 1M Context、更大的 KV Cache 预算	1M 是能力目标，不等于默认服务窗口；实际能开放多少仍要与并发、请求长度一起验证。