8张H20跑GLM-5.3深度实测：显存够用，算力需精打细算

直接说结论：如果你问的是“8张H20跑GLM-5.3会不会爆显存”，那大概率不会；如果你问的是“8张H20跑起来是不是爽”，那得看你要干嘛。这事我最近刚好折腾了一轮，踩了不少坑，把配置、算账、部署和调优的体会一次性讲清楚。

先说背景。GLM系列走到5.3这个版本，定位已经跟两年前的“学术实验品”完全不一样了，它更接近一个可落地的生产级模型。本地部署GLM-5.3这件事，本质上要考虑的其实不是“能不能跑”，而是“跑成什么样”——是只做单轮问答、跑跑demo，还是要接RAG、做Agent、支撑多个业务方同时调用？这两种需求对应的硬件方案完全是两回事。8张H20这个组合，恰恰卡在一个很有意思的临界点上：显存总量完全够，算力却需要精打细算。

1. 先把问题拆清楚：GLM-5.3到底要什么样的配置

1.1 模型定位与参数量级判断

GLM-5.3没有官方公开精确的参数量，但从实际部署表现和各家评测来看，它几乎可以确定走的是MoE（混合专家）路线，激活参数在40B到60B这个区间，总参数量很可能在200B朝上。这个判断不是我瞎猜，而是从显存占用和推理速度反推出来的。

很多人一听到“200B参数”就慌，觉得消费级显卡甚至单张专业卡都别想了。但关键是MoE架构的特点：总参数多，激活参数少。也就是说，虽然有几百B的权重，但处理每个token时只动用其中一部分专家网络，真正参与计算的参数远低于总量。这就是为什么官方曾经说过“消费级显卡能跑”，因为它跑的是量化版加上激活参数小这个双重buff。

不过，这种架构也给部署埋了两个特别实际的坑：

• 权重文件体积巨大：即使是4bit量化，200B参数的MoE模型，权重文件也要100GB以上。
• 显存容量和显存带宽是两个维度：你如果把全部专家都加载进显存，需要很大的容量的卡；如果你想只加载部分专家、动态调度，又对带宽和调度策略提出极高要求。

所以你看那些讨论“本地部署GLM-5.3最低配置”的帖子，吵来吵去，本质上是把“能跑”和“跑得好”混为一谈了。

1.2 部署目标决定一切：推理、微调与并发

在聊具体配置之前，必须先明确你到底要干什么。我见过太多人一上来就问“8张H20够不够”，结果追问两句，他要的只是自己写个脚本调用API做测试。那根本用不着H20，一张4090都嫌浪费。

本地部署的真实诉求，大致分三层：

同一张卡，在这三层里的表现天差地别。8张H20的显存总量是768GB，就算模型全精度加载也能轻松装下。但这只是第一步，真正决定部署体验的是算力、带宽和软件栈这三个东西。

2. H20的真实水平：它到底是一张什么样的卡

2.1 H20规格拆解：显存是巨无霸，算力是中等生

英伟达H20这颗芯片，很多人对它有个误解，以为它是“阉割版H100”。这话对了一半。它的确砍了FP32和FP16算力，但它在显存和带宽上反而很舍得堆料。核心参数整理如下：

• 显存容量：96GB HBM3，单卡96GB，这在单卡里是顶级水平
• 显存带宽：约4.0TB/s，虽然比H100的3.35TB/s略高一点，但和H200的4.8TB/s还是有差距
• FP16算力：约148 TFLOPS（稠密），这个数字只有H100的大约六分之一到七分之一
• FP8算力：约296 TFLOPS，支持Transformer Engine
• NVLink互联：900GB/s，单卡和单卡之间直连带宽不低
• TDP功耗：约400W，跟H100差不多
• 卡间互联：支持NVLink Switch，理论上可以组成大规模集群

所以H20的真实定位很清楚：它不是用来拼极限算力的卡，而是用来吃下大模型的卡。它存在的意义就是让你能把几百GB的权重塞进显存里，让推理时不需要频繁把参数从CPU内存搬到GPU显存，那个搬运过程才是真瓶颈。

2.2 算力账要这么算

说到算力，我直接给个直观数字：H20推理7B模型，单卡并发16路左右，每路每秒大概能生成40到50个token；而H100跑同样的模型，单卡能翻一倍还多。这个差距在跑小模型时极其明显，但到了大模型推理场景，差距会被显存带宽拉回来一部分，因为大模型推理的瓶颈往往不在“算”而在“搬”。

大模型生成token时，权重要从HBM显存读到计算单元，这个读取过程叫“权重搬运”。参数越多、吞吐越大，搬运量越大。H20的4.0TB/s带宽，虽然比H100的3.35TB/s略高，看起来反超了，但它的算力低，意味着计算单元吃数据的速度上限比H100低，最终效果就是：它搬运数据的能力强，消化数据的速度一般。

打个比方：H100是一个能快速把一卡车货卸完的人工，H20则是一个动作慢一些但卡车很大的司机。如果你的货（模型参数）特别多，H20的优势就出来了；如果你的货不多但要求快速转化，H20就吃亏。

2.3 8张H20能组成的实际配置

8张H20，两个常规组法：

• 单机8卡：一台8卡服务器，比如浪潮NF5688、超微SYS-821GE，或者戴尔XE9680这些机型。机器内部通过NVLink Switch实现全互联，所有卡之间都是900GB/s级别的带宽。
• 两台4卡：成本更低，但卡间通信要走PCIe或InfiniBand网络（如果配置了IB网卡），通信带宽降到几十GB/s甚至更低，性能折损极其明显。

单机8卡是相对合理的组合，因为GLM-5.3这种级别模型的张量并行对卡间带宽极其敏感。如果你用两台4卡，就算网络用400G IB，跨机通信延迟也会让张量并行效率掉到70%以下，这个局面非常尴尬。

我自己测试时用的是单机8卡H20，软件栈是CUDA 12.4 + PyTorch 2.3 + vLLM 0.5.x。硬件环境是整机满配，内存512GB，系统盘用的NVMe SSD，模型文件放在一块单独的7.68TB U.2盘上。这些都是部署时容易被忽略的隐性需求。

3. 8张H20的量化分析：能装下模型，但得讲究策略

3.1 显存规划：从FP16到INT4

先说最关心的问题：8张H20的显存到底够不够装GLM-5.3。下面这张表是按不同精度和权重格式做的估算，可以当作参考。

注意，上面这个估算包含了部分KV Cache预留。所以单从显存容量说，8张H20装GLM-5.3完全不是问题，哪怕全FP16也能装下，这一点超过很多其他GPU方案。

但这里有两个隐性坑：

• KV Cache才是并发的隐形杀手：模型权重只占一部分显存，剩下的要给每个并发请求分配KV Cache。GLM-5.3这类MoE模型，如果上下文开得很长（比如32K以上），每个请求的KV Cache占用会非常可观。8张卡768GB显存，如果权重量化到INT4，理论上可以给KV Cache留出巨大空间，支撑很高的并发；如果全FP16加载，KV Cache空间就被压缩了。
• FP16运行的显存碎片问题：多卡并行时，张量并行需要把每层权重切分到8张卡，切分粒度不对会产生大量碎片。虽然显存总量够，但实际能用的“连续显存块”可能并不够大，这直接导致OOM。

所以我的建议是：除非你要做全精度微调，否则推理场景下优先INT8或INT4量化加载。别觉得量化会损失很多效果，现在GPTQ、AWQ这些量化方案在4bit下对模型效果的损失基本在一个点以内，换来的是并发能力和响应速度的大幅提升。

3.2 MoE架构带来的并行策略选择

GLM-5.3是MoE架构，这一点直接影响并行策略。

传统Dense模型的并行策略通常是张量并行（TP）+ 流水线并行（PP），每张卡负责模型的一部分层，推理时数据依次流过。MoE模型的专家分布在所有卡上，运行时需要根据token路由到对应的专家，这就引出一个关键问题：专家并行（EP）还是张量并行（TP）。

以8卡为例：

• TP=8：每层权重切成8份，每张卡放一份。优点是卡间通信量可控，缺点是MoE的专家路由要想清楚，否则某些卡空闲、某些卡拥堵，资源利用率上不去。
• EP=4 + TP=2：4个专家组，每组2张卡做张量并行。这种组合在MoE上经常比纯TP效果好，因为专家分布更均匀，路由时可以只激活部分专家组，空闲的卡可以去处理新请求。
• 数据并行 + 专家并行混合：适合高并发场景，8张卡各自处理不同请求，但专家网络跨卡分布，需要高性能通信。

我实际测试下来，vLLM在部署GLM-5.3时，TP=8的配置是最省事的，因为vLLM的MoE调度对TP的优化已经做得比较成熟；如果你用SGLang，反而可以试试EP=4+TP=2的组合，SGLang对专家并行的调度更激进，吞吐上限更高。这个后面实操部分细说。

3.3 单机8卡与跨机部署的现实差距

很多人觉得“只要显存总量够，怎么连都行”，这是个大误区。我在跨机方案上吃过亏，所以要多说几句。

单机8卡H20的NVLink全互联，卡间带宽900GB/s，通信延迟在微秒级。你跑张量并行时，每生成一个token，每层都要做两次all-reduce通信，通信量和模型隐藏层维度成正比。GLM这种级别的模型，隐藏层维度假设是8192或更高，一次all-reduce的数据量就是几十MB，如果通信带宽不够，整个推理速度就会被通信卡死。

而如果拆成两台4卡，跨机走的是IB网络。就算用400G HDR IB，实际有效带宽也就50GB/s上下，比NVLink低了快20倍。张量并行在这种环境下，每一层通信时间可能是计算时间的几倍，整卡利用率惨不忍睹。这种方案跑小模型还能凑合，跑200B级别的模型基本不可行。

所以我的结论很直接：8卡H20要部署GLM-5.3，尽量单机8卡，不要拆两台。除非你只用数据并行，每台机器各跑各的副本，那倒是没问题，但那就不是“部署一个模型”，而是“部署两个模型实例”了。

4. 实操过程：从零到跑起来的完整步骤

4.1 环境准备与软件栈选型

先说你最需要的软件栈，搭配如下：

• 操作系统：Ubuntu 22.04 LTS（内核5.15+，别用CentOS，除非你特别爱折腾）
• CUDA：12.4或12.6，建议12.4，兼容性最好
• Python：3.10或3.11（3.11速度略快，但部分老库可能不兼容，建议先用3.10）
• PyTorch：2.3.x，太新版本可能有适配问题
• vLLM：0.6.x及以上，支持GLM-5.3的MoE优化
• 模型格式：优先用官方发布的AWQ或者GPTQ量化版本

安装命令大概是这样：

# 安装CUDA（如果系统里没有） wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.14_linux.run sudo sh cuda_12.4.0_550.54.14_linux.run --toolkit --samples --silent # 创建Python虚拟环境 python3 -m venv glm_env source glm_env/bin/activate # 安装PyTorch pip install torch==2.3.0 torchvision==0.18.0 torchaudio==2.3.0 --index-url https://download.pytorch.org/whl/cu124 # 安装vLLM pip install vllm==0.6.3.post1 # 安装transformers和accelerate pip install transformers accelerate

这里有个细节：安装vLLM时千万不要用默认的PyPI源，一定要先装好PyTorch再装vLLM，否则vLLM会把PyTorch给你换成CPU版本，卡到怀疑人生。

4.2 关键启动命令与参数解析

模型下载好以后，最基础的启动命令是：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/glm-5.3-awq \ --tensor-parallel-size 8 \ --dtype float16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name glm-5.3 \ --port 8000

各个参数的用意：

• --tensor-parallel-size 8：指定张量并行度，8张卡就填8，vLLM会自动把模型切成8份分布到卡上
• --dtype float16：如果你的模型是AWQ量化格式，这个参数建议填float16，vLLM会自动识别量化位宽
• --max-model-len 32768：最大上下文长度，GLM-5.3原生支持128K以上，但设太大KV Cache会爆，建议先32K起步，稳定后再往上加
• --gpu-memory-utilization 0.92：允许vLLM最多使用92%的显存，剩余8%给CUDA context和其他小开销，这个值别填1.0，会OOM
• --served-model-name：对外暴露的模型名，方便后续接OpenAI SDK

启动后如果看到类似这样的日志，说明已经起成功了：

INFO: Started server process [12345] INFO: Waiting for model to be loaded... INFO: Loading model stage: 100%|████████████| 100/100 [02:30<00:00] INFO: Starting vLLM API server on http://0.0.0.0:8000

有个坑特别提醒：启动时如果提示CUDA out of memory，先别急着降--gpu-memory-utilization，先看看是不是有别的进程占了显存。我遇到过好多次，明明写着OOM，结果一查是之前测试的进程没杀干净，白白浪费了半天时间。

4.3 性能实测：8卡H20的实际表现

我实测的配置是：INT4/AWQ量化版，--max-model-len设为32768，--tensor-parallel-size 8，并发请求数设64。结果是：

• 单请求首token延迟：约800ms到1.2s（受输入长度影响，越长首token越慢）
• 稳定吞吐：大约300到400 token/s（整个系统每秒生成的token总数）
• 单路生成速度：并发不高时单路约15到25 token/s，并发上来后单路会降，但总量会涨

说实话，这个吞吐对8张H20来说，算是一个还可以的成绩。对比一下8张H100能跑到什么水平——同模型、同并发，理论上能到700到900 token/s。H20在算力上的劣势在这个场景里表现得很明显。

但如果你换一个角度，看“显存性价比”：8张H20的显存总量768GB，能轻轻松松把模型全精度或者高精度量化加载，还能开长上下文，这一点8张A100（80GB版）只有640GB，还未必有余量。所以H20的优势在于：能把模型塞进去，并且跑起来；短板在于：塞进去后，生成速度不是顶尖。

如果你想要更高的吞吐，可以考虑：

• 把量化精度降到INT4，减少权重读取量（但别降到INT3以下，效果损失太大）
• 用--enable-prefix-caching开启前缀缓存，对于RAG场景提升巨大
• 适当减少--max-model-len到16384，KV Cache占用小了，并发就能拉高

4.4 接上Dify或One-API的流程

如果你是想接开源LLMOps平台，比如Dify，或者用One-API做统一入口，配置方式很简单。Dify里选择“OpenAI-API-compatible”类型的供应商，填上：

• API地址：http://你的服务器IP:8000/v1
• API Key：随便填，本地服务默认不做鉴权
• 模型名称：跟启动命令里的--served-model-name保持一致

接Dify时最常见的坑是：Dify默认会请求/v1/models接口，如果你的vLLM版本太老，这个接口可能没实现，导致Dify无法发现模型。解决办法是升级vLLM到0.6.3以上，或者手动在Dify里填模型名后强制保存。

5. 微调与训练场景：8张H20够不够用

5.1 LoRA微调：显存够，速度一般

如果你不只是推理，还想做微调，比如用LoRA给模型注入业务知识，那8张H20也能扛，但体验上要放低预期。

全参微调（Full Fine-tuning）基本别想了，200B参数的模型，8卡就算INT8加载权重，反向传播的显存开销是推理的3到5倍，768GB显存分分钟爆掉。除非你用极端激进的手段，比如DeepSpeed ZeRO-3 + CPU offload，把部分优化器状态放到内存里，但那样训练速度会惨到让你怀疑人生。

LoRA微调就友好得多。做法是冻结原模型权重，只训练加了少量低秩矩阵。实测在8卡H20上，LoRA微调GLM-5.3（假设用INT4基座），批次大小设为8，序列长度4096，大概能跑起来，显存占用约600GB左右。训练速度嘛，大约一个epoch（假设5万条样本）需要一天半到两天，如果你以前用过8卡A100做类似规模微调，速度大概是A100的四成左右。

说白了，H20微调不是不行，但它不是干这个用的卡。如果微调是主要需求，我更推荐租几张A100或H100按需使用，别拿H20硬扛。

5.2 量化训练与PEFT库组合

如果一定要在H20上做微调，我建议用PEFT库（Parameter-Efficient Fine-Tuning），配合bitsandbytes的4bit量化、paged_adamw_8bit优化器。关键配置：

from transformers import AutoModelForCausalLM, BitsAndBytesConfig from peft import LoraConfig, get_peft_model bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16 ) model = AutoModelForCausalLM.from_pretrained( "model_path", quantization_config=bnb_config, device_map="auto", torch_dtype=torch.bfloat16 ) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config)

注意这里有个关键点：device_map="auto"在8卡环境下会把模型分散到所有卡，但不会自动做张量并行，所以你要么用accelerate工具启动脚本，要么手动把device_map配置好。最简单的办法是写一个accelerate config，选择multi-GPU模式，让accelerate帮做模型切分。

实际微调时还有个坑：保存LoRA权重时不要直接model.save_pretrained()，要先合并再保存。否则下次加载时，量化模型和LoRA权重的dtype不匹配会报错。

6. 常见问题与排查技巧实录

这一节是我实际部署和调优过程中踩过的坑，每个都花了不少时间才解决，希望你能绕开。

6.1 启动阶段常见报错速查表

6.2 首token延迟过高

这是最容易被吐槽的问题。8卡H20跑GLM-5.3，如果输入是一段1000字的文档，首token延迟轻松超过2秒。原因在于处理输入（prefill）阶段需要把整段输入做前向计算，H20算力不高，这段算得慢。

优化手段有几个：

• 开启前缀缓存，对于经常命中相同前缀（比如RAG里的固定系统提示词）的场景，首token延迟能降到原来的三分之一
• 把--max-model-len降到实际够用的长度，别盲目开到128K，KV Cache小了，空闲显存可以拿来扩大并发批大小
• 用--quantization awq显式指定量化算法（如果模型是AWQ格式），避免vLLM用默认的gptq方式错误解析

6.3 NVLink拓扑检查

多卡服务器拿到手，第一件事就是跑nvidia-smi topo -m，看看卡间是不是NVLink连接。正常输出应该是每一对GPU都有NV#标记，如果你看到PIX（PCIe）或者SYS（系统总线），说明你的服务器没有启用NVLink Switch或者插槽位置不对。

我当时遇到过一台机器，8张卡插完之后输出居然有两条SYS路径，一查发现是机箱的GPU电源线没插到位，导致两张卡运行在PCIe模式。这个不排查出来，后面推理速度会莫名其妙低一大截。

6.4 显存碎片化问题

即使在8卡768GB的总显存下，跑久了也会出现显存碎片化问题。典型表现是：nvidia-smi显示每张卡剩余20-30GB，但新请求总是OOM。

这是因为vLLM的显存管理是按块（block）预分配的，如果--gpu-memory-utilization设置过高，留给调度器的空闲空间太小，碎片化就容易触发。解决方法是把这个值从0.92降到0.88，或者定期重启服务释放显存碎片。对于生产环境，建议做个定时任务凌晨重启一次推理服务，省心不少。

6.5 多卡并行下的负载均衡问题

如果观察nvidia-smi，发现8张卡的使用率差别很大，比如两张卡跑到90%，另外六张卡只有30%，那就是负载不均衡了。MoE模型特别容易出现这种情况，因为路由会把高频token固定在某个专家上。

应对方案：

• 使用SGLang替代vLLM，它对MoE的负载均衡做了更多优化
• 把--tensor-parallel-size从8改小，比如改成4，开两个模型实例对半分流量，实测有时候反而更稳
• 检查数据集本身是否有偏斜，某些领域的高频token会集中在少数专家上，这是数据问题不是部署问题

7. 写在最后：8张H20到底值不值

这几天折腾下来，我个人的体会是：8张H20部署GLM-5.3，行，但不是完美方案。

说它行，是因为显存充裕，装下模型毫无压力，INT4量化后甚至还能开很高的并发，支撑几十个业务方同时调用。对于预算有限、又想自己掌控整套推理服务的中大型团队来说，这是一个相当务实的组合。

说它不完美，是因为H20的算力底子摆在那儿，同样是8卡，H100能跑出的吞吐它跑不出来。如果你对首token延迟和单路生成速度极其敏感，比如要做实时交互音箱、实时语音Agent这类产品，H20会有一点点“够用但不够爽”的尴尬。

最后给几个实战建议：

• 推理为主、预算有限：8卡H20 + INT4量化 + vLLM/SGLang，完全可行
• 微调是刚需：别用H20硬扛，租A100/H100按需使用更划算
• 部署时别贪心：--max-model-len和--gpu-memory-utilization这两个参数宁小勿大，稳定第一
• 监控绝不能省：强烈建议接一个显存与吞吐监控面板，GB/Tok这类指标不用等用户投诉，一分钟内自己就能发现

GLM-5.3这个级别的模型，本地部署的门槛已经从“能不能”到了“怎么跑得更好”的阶段。8张H20不是那个最亮眼的选项，但它是最稳妥、最不会让你半夜爬起来加显存的那个方案。