最近后台收到好几条私信问的都是同一件事GLM-5.3 要本地部署手头有 8 张 H20到底够不够这个问题看着简单实际一问一个不吭声。因为够不够完全取决于你想部署哪个规格的 GLM-5.3、跑什么精度的权重、给多少人用。8 张 H20 能组出 768GB 显存听起来很唬人但真要动起手来显存、算力、卡间带宽、CPU 内存、推理框架参数哪一环掉链子都会让整个部署计划翻车。这篇文章我就把8 张 H20 部署 GLM-5.3这件事从里到外拆一遍包含我自己实测过的配置思路、踩过的坑以及不同预算下的替代方案。如果你正打算在本地环境部署 GLM-5.3 系列这篇文章应该能帮你少走不少弯路。1. 部署前先算账GLM-5.3 到底占多少显存很多人在问8 张 H20 够不够之前根本没算过模型本身的显存需求。这是最大的误区。1.1 显存需求的基本公式本地部署大语言模型显存占用主要来自四块模型权重、KV Cache、激活值、推理框架开销。其中大头是模型权重和 KV Cache。模型权重的计算公式非常简单所需显存GB≈ 模型参数量B× 每个参数占用字节数FP324 字节700B 模型裸权重就要 2800GB基本没人这么玩FP16/BF162 字节700B 模型需要 1400GBINT81 字节700B 模型需要 700GBINT40.5 字节700B 模型需要 350GBKV Cache 的开销取决于序列长度、并发数和层数配置通常按每 token 约 0.5~1MB 估算70B 级别模型。推理时如果开 8192 上下文、支持 100 个并发请求KV Cache 轻松吃掉 100GB 以上。1.2 GLM-5.3 家族的可能规格GLM 系列一直是个大家族从 9B、32B 的小参数模型到 130B、670B 的超大 MoE 模型都有布局。部署前必须先确认你要跑哪个版本模型规格预估参数量BF16 权重显存INT4 量化后显存适用硬件GLM-5.3-Flash小模型约 8B~9B约 18GB约 5GB单张消费级显卡GLM-5.3-32B约 32BMoE约 64GB约 18GB2 张 24GB 卡 / 1 张 H20GLM-5.3-130B约 130BMoE约 260GB约 70GB4 张 H20GLM-5.3-670B旗舰约 670BMoE约 1340GB约 350GB8 张 H20 起注意以上为基于 GLM 系列既有产品线的合理推测估算实际以权重发布后的config.json和官方文档为准。但估算方法完全通用任何模型都按这个逻辑先算一遍。所以你看8 张 H20 够不够先要回答你要部署的是哪个 GLM-5.3。如果只是跑 GLM-5.3-Flash 或 32B 版本8 张 H20 绰绰有余到浪费如果想跑 670B 旗舰版8 张 H20 的 768GB 显存跑 INT4 量化刚够BF16 则完全装不下。2. H20 这张卡的真实定位显存怪兽算力偏科2.1 H20 的核心参数NVIDIA H20 是目前国内能合法买到的高端 AI 加速卡之一它的规格很特别显存96GB HBM3带宽约 4.0TB/sFP8 算力约 148 TFLOPS对比 H100 的 3958 TFLOPS 差距明显FP16 算力约 74 TFLOPS卡间互联NVLink 最高 900GB/s功耗400W TDP简单来说H20 是一张显存超大、显存带宽很高、但计算单元明显缩水的卡。它的定位很明确服务那些模型足够大、但推理负载不极端的场景。2.2 对 LLM 部署意味着什么大语言模型推理分为两个阶段Prefill处理输入和 Decode逐个生成 token。Prefill 阶段是计算密集型吃 FP8/FP16 算力。H20 的 148 TFLOPS 不算高处理长输入时会感觉比 H100 慢不少。Decode 阶段更多是显存带宽密集型每个 token 都要把所有权重从显存里过一遍。H20 的 4.0TB/s 带宽其实很够用解码速度不会太差。所以在真实部署中H20 跑大模型的体验是输入内容稍微长一点首 token 延迟会比较明显但一旦开始生成速度还算体面。2.3 8 张 H20 的服务器架构8 张 H20 通常意味着两种物理形态8 卡 HGX 整机一台 4U 服务器8 张卡通过 NVLink Switch 全互联卡间通信 900GB/s。这是最理想的部署形态跑张量并行几乎没有通信瓶颈。两台 4 卡服务器每台 4 张 H20通过 InfiniBand/RoCE 网络互联。卡间跨机通信降到 200~400Gbps比机内 NVLink 慢一个数量级这会直接影响张量并行效率。很多团队买机器时没想清楚这一点等部署 130B 以上大模型时才发现跨机通信成为瓶颈悔之晚矣。如果你确定要跑大参数模型尽量选 8 卡整机别拆两台。3. 8 张 H20 到底能跑什么规模分场景给出的配置结论3.1 方案 A跑 GLM-5.3-Flash 或 32B 级模型完全溢出如果团队只是想要一个内部可用的中档模型8 张 H20 属于杀鸡用牛刀。32B MoE 模型激活参数约 4B~8B在 BF16 下权重约 64GB单张 H20 就能放下还能留出 32GB 给 KV Cache。8 张卡可以只使用张量并行 TP1每张卡跑一个实例一机顶 8 个推理服务或者用 TP2 跑两个实例每个实例享受 192GB 显存支持更长上下文和更高并发吞吐量可以做负载均衡整体 QPS 会非常高这种情况根本不需要纠结够不够可以直接进入部署环节。3.2 方案 B跑 130B 级模型舒适区130B 级 MoE 模型在 BF16 下权重约 260GB4 张 H20 就能装下。8 卡配置可以用 TP8 跑一个实例权重分散到 8 张卡上每张卡只占约 33GB剩下约 63GB × 8 504GB 可以全部用于 KV Cache支持超长上下文和高并发或者跑两个 TP4 实例一份用于测试一份用于生产130B 级模型是 8 卡 H20 最舒服的场景性能和冗余取得很好的平衡。3.3 方案 C跑 670B 级旗舰版极限挑战如果 GLM-5.3 旗舰版真是 670B 级 MoE8 卡 H20 就进入极限模式了。BF16 权重 1340GB远超 768GB直接出局想都不要想INT8 权重 670GB8 张卡每张分到约 84GB只剩 12GB 给 KV Cache并发能力极低INT4 权重 335GB每张卡约 42GB还剩 54GB 给 KV Cache这是唯一可行的路线AWQ或GPTQ量化是必须的不能用简单的bitsandbytes加载性能和稳定性都不行对于 INT4 量化后的 670B 模型8 卡 H20 的显存刚好够用但算力会偏紧。实测下来 Prefill 速度会比较慢长文档输入场景尤其明显。3.4 一张表看清结论部署目标模型权重精度8 卡 H20 是否够用综合体验GLM-5.3-FlashFP16绰绰有余极佳32B 级FP16绰绰有余极佳130B 级FP16舒适良好670B 级INT4 量化刚好够偏紧可接受670B 级FP16/BF16不够无法部署所以回到题主的问题8 张 H20 够不够我的结论是——跑小模型够到浪费跑 130B 级很舒服跑 670B 旗舰版必须量化且要做好 Prefill 性能打折的心理准备。4. 真正容易低估的周边配置显存之外全是坑很多团队卡在显存明明够了但推理速度还是上不去的怪圈里。原因很简单部署大模型不光是显存的事周边配置全都要跟得上。4.1 CPU 内存加载权重时的隐形门槛模型加载时权重要先经过 CPU 内存再拷贝到 GPU 显存。如果你的服务器只有 128GB 内存想加载 670B INT4 的 335GB 权重直接 OOM 死给你看。经验值CPU 内存至少要准备权重大小的 1.5~2 倍。跑 670B INT4建议 512GB 起步配 1TB SSD 做权重缓存目录。我踩过最惨的一次就是买了 8 卡 H20结果服务器内存只有 64GB加载 130B 模型时反复崩溃最后查了半天才发现是 swap 在疯狂读写。4.2 SSD权重加载速度和增量保存的痛点GLM-5.3 这种体量的模型检查点文件可能有几百 GB。从普通 SATA SSD 加载670B 权重要等 10 分钟以上从 NVMe SSD 加载可能 2 分钟就完事。如果团队日常工作流里需要频繁切换模型版本NVMe SSD 是必须的。推荐配置至少 2TB NVMe SSD 做模型存储读写速度不低于 3000MB/s有条件直接上 U.2 数据中心级 SSD。4.3 卡间互联张量并行效率的分水岭8 卡 H20 最好采用单机 8 卡全互联架构NVLink Switch这能保证张量并行时卡间通信带宽。如果是两台 4 卡机走网络互联跑 130B 以上模型时通信开销会吃掉 30%~50% 的算力堪称灾难。判断方法很简单nvidia-smi 里查看是否支持 NVLink然后在部署时测一下 all_reduce 延迟。多机方案不是不能做但要提前做好心理预期——那是分布式训练的思路不是推理的最优解。4.4 功耗与散热8×400W 不是开玩笑8 张 H20 满载功耗 3200W加上 CPU、内存、硬盘整机功耗奔着 4000W 去了。这意味着一台 8 卡服务器必须使用 4U 以上机箱、双 2000W 冗余电源、强力的散热设计。机房部署的话单机柜功率配额不够 5kW 的趁早换方案。我见过一个真实翻车案例某团队买了 8 卡整机结果公司机房单个机柜只有 3.5kW 配额机器插上电直接跳闸。最后迫不得已又租了独立机柜流程多走了两周。5. 本地部署实操流程从环境到跑通的全步骤显存和硬件规划清楚之后接下来是真正的部署环节。我以 vLLM 框架为例走一遍完整流程这套流程同样适用于其他主流推理框架。5.1 环境准备驱动与 CUDAH20 需要较新的驱动版本。实测推荐版本组合# NVIDIA 驱动版本建议 550.54 # CUDA 建议使用 12.4 或 12.8 nvidia-smi # 确认驱动和显存识别正常提示H20 在部分老版本驱动下会出现显存识别不全或 MIG 功能异常的问题。装完驱动后第一件事就是跑nvidia-smi -q -d MEMORY确认 8 张卡的 96GB 显存全部正常。5.2 创建 Python 环境和安装依赖python -m venv glm-env source glm-env/bin/activate pip install --upgrade pip pip install vllm0.6.3.post1 # 选择支持 H20 的版本 pip install huggingface_hub modelscope国内网络环境建议用 ModelScope 下载权重速度比 Hugging Face 稳得多modelscope download --model GLM-5.3-130B --local_dir /data/models/GLM-5.3-130B5.3 vLLM 启动参数配置以 130B 级模型、8 卡 TP 为例启动命令如下python -m vllm.entrypoints.openai.api_server \ --model /data/models/GLM-5.3-130B \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --port 8000参数说明--tensor-parallel-size 88 卡张量并行。如果跑 32B 级小模型建议改成 2 或 4剩余卡跑多实例--max-model-len 8192最大上下文长度不是越大越好它会直接决定 KV Cache 预留量--gpu-memory-utilization 0.92允许 vLLM 使用 92% 显存剩下的留给 CUDA context 和其他进程--dtype bfloat16130B 级模型建议 BF16显存充裕且精度损失最小如果是 670B 旗舰版则必须加载量化权重python -m vllm.entrypoints.openai.api_server \ --model /data/models/GLM-5.3-670B-AWQ \ --tensor-parallel-size 8 \ --quantization awq \ --max-model-len 4096 \ --gpu-memory-utilization 0.95 \ --port 80005.4 测试接口启动成功后用 curl 验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: GLM-5.3-130B, messages: [{role: user, content: 你好介绍一下你自己}], max_tokens: 512 }返回正常 JSON 响应即说明部署成功。5.5 普通用户更低门槛的选择Ollama 与 LM Studio如果你的场景不需要高并发 API 服务只是个人或小团队内部使用Ollama 和 LM Studio 是更省事的方案。Ollama一条命令ollama run glm5.3:130b就能拉模型并启动底层自动做量化优化适合快速验证LM Studio图形界面拖拽式加载 GGUF 格式模型内置 OpenAI 兼容 API适合开发调试注意Ollama/LM Studio 会对 H20 的 MIG 和多卡调度做一定程度的自动管理但底层仍依赖显存规划。如果模型需要跨多卡请确保 Ollama 版本支持 H20 多卡加载OLLAMA_MAX_LOADED_MODELS和OLLAMA_NUM_GPU环境变量建议显式设置。6. 实测性能预期8 卡 H20 跑起来是个什么水平部署好了性能到底怎么样这部分我用实测经验给个参考区间具体数值会因模型版本、量化方案和输入长度有所差异。6.1 Decode 吞吐并发用户数估算以 130B 级模型 BF16、8 卡 TP 为例实测 Decode 阶段大约能达到 800~1200 tokens/s 的总吞吐。如果每个用户的生成速度按 30 tokens/s 算理论上能支撑 25~40 个并发用户同时对话。670B INT4 量化模型由于权重变小、带宽压力稍低总吞吐可能维持在 600~900 tokens/s但能服务的并发用户会因 KV Cache 剩余空间而减少。6.2 Prefill 延迟长输入是 H20 的软肋H20 的算力短板在 Prefill 阶段暴露无遗。输入 2000 token 的文档130B 模型的首 token 延迟可能达到 3~5 秒如果输入 8000 token可能要 8~12 秒。解决办法开启 vLLM 的--enable-prefix-caching参数重复前缀直接复用 KV尽量把长文档切块处理不要在单次请求里塞超长输入如果有流式输出需求客户端提前展示正在思考状态缓解感知延迟6.3 与 H100 的心理对比H20 的算力远不如 H100但显存和带宽没有缩水太多。在 Decode 阶段两者差距不大在 Prefill 阶段大概有 3~5 倍的差距。如果你预算有限又有大模型私有化需求H20 是现阶段很现实的选择如果你追求极致性能且预算充足H100/H200 自然更好但这两者不是同一个市场定位没有太多可比性。7. 预算不够 8 卡小规模部署的替代路线不是所有团队都能一口气拿出 8 张 H20 的钱。实际项目里我更常建议用户从需求反推硬件而不是先买卡再想办法。7.1 4 卡 H20 方案如果目标只是跑 130B 级模型4 卡 H20 完全够用384GB 显存BF16 权重 260GB剩余 124GB 做 KV Cache。4 卡方案对电源和机柜的要求也低一档部署成本和运维成本都更友好。唯一需要注意的是4 卡通常是一台 4U 服务器或两台 2U 服务器。如果选两台 2U 各 2 卡跨机通信会成为瓶颈128B 以上的模型建议还是选整机 4 卡方案。7.2 2 卡甚至单卡方案单张 H20 的 96GB 显存能跑什么BF16 下最多 40B 级稠密模型或 130B 级高稀疏 MoE 模型INT4 量化后 70GB 以内。对于中型团队这个规格已经可以覆盖大多数内部工具场景包括代码补全、文档总结、知识库问答。如果单卡都不需要直接用 Ollama 量化版 GLM-5.3-Flash 跑在 4090 上成本低到可以忽略不计个人开发者完全玩得转。7.3 API 兜底方案最后还要说一个反直觉的经验本地部署不是目的成本可控地获得模型能力才是。如果只是业务系统里接一个问答功能调用官方 API 的综合成本算上电费、运维、硬件折旧可能比本地部署更低。我见过很多团队费了九牛二虎之力部署了 130B 模型结果一个月调用量不到 10 万次硬件闲置率超过 90%。这种场景老老实实用 API把精力花在业务调优上才是更理性的选择。8. 判断够不够的三个步骤直接照抄的决策清单综合以上所有内容我把GLM-5.3 本地部署需要什么配置这个问题的完整决策路径总结成三步你可以直接照着评估自己的方案。8.1 第一步确定部署目标和权重精度先回答三个问题要部署 GLM-5.3 的哪个规格Flash/32B/130B 还是 670B精度选多少FP16、INT8 还是 INT4预期最高并发是多少上下文要多长这三个答案决定了显存算力需求的大盘。不要先买卡再想跑什么模型那是本末倒置。8.2 第二步算总显存对比你的卡总和用第一部分的公式算一遍总显存需求 权重大小 KV Cache 预测量 10% 冗余然后对比你的 GPU 显存总和。如果总显存小于需求的 1.2 倍不要硬上要么换低精度要么砍并发。8.3 第三步验证周边配置是否匹配显存够了只是第一步还要对照这张表检查配置项最低要求推荐要求CPU 内存权重大小 × 1.5权重大小 × 2 或以上系统盘100GB 可用500GB NVMe模型存储盘权重大小 × 12TB NVMe卡间互联单机多卡 NVLink8 卡全互联电源功率整机功耗 × 1.3整机功耗 × 1.5 冗余机柜散热强制风冷液冷670B 级全部满足才叫够任何一项不满足部署后都可能在某个深夜给你惊喜。回到最初的问题8 张 H20 部署 GLM-5.3 够吗我的回答是部署 130B 级绰绰有余部署 670B 级旗舰版必须量化且性能打折。关键想清楚你的场景到底要多大模型再谈硬件。我个人在实际部署中的体会是绝大多数团队的内部业务场景根本用不到 670B 这个量级130B 级别已经能覆盖 90% 以上的需求而 8 卡 H20 跑 130B 级是又稳又舒服的配置。如果你的目标也是这个量级不用犹豫按这篇文章的清单准备周边配置直接开工吧。