最近私信后台问 GLM-5.3 本地部署的朋友肉眼可见地多起来了而且其中七八成都在问同一个问题8 张 H20 到底够不够这个问题看上去就是报个显卡型号要个结论但真要想回答得靠谱牵扯到的其实是显存总容量、显存带宽、张量并行度、KV Cache、量化精度、并发用户数这一整串东西。我这两天正好在一套 8 卡 H20 的机器上把 GLM-5.3 跑起来了中间踩了不少坑也把容量账重新翻来覆去算了几遍。这篇就把我的整个思路和实测记录整理出来给准备上车的朋友一个可参考的答案而不是一句玄学式的“够”或“不够”。1. 先把账算清楚本地部署 GLM-5.3 到底在跑什么1.1 模型体积与显存容量的数学题很多朋友一上来就看“8 张 H20 768GB 显存肯定够啊”这个直觉没毛病但忽略了一个关键前提模型权重只是显存占用的一部分而且往往不是全部。我先按常见规模做一个估算。GLM-5.3 按目前社区拆包和实测数据推测主线版本大概率落在 300B 参数以上Flash 轻量级版本则会在 30B~50B 这个区间。这里我不去纠结官方具体参数直接给出一个通用公式权重显存 参数量 × 精度字节数FP324 字节300B × 4 1200GBFP16/BF162 字节300B × 2 600GBFP81 字节300B × 1 300GBINT4 量化0.5 字节300B × 0.5 150GB也就是说一个 300B 级别的大模型单就权重本身用 BF16 精度加载就需要 600GB 显存。8 卡 H20 总共 768GB减去 600GB 之后只剩 168GB 余量。听起来还有 168GB 喘气空间别急后面还有 KV Cache、激活值、CUDA context、碎片开销这些“隐形房客”要分。更不用说如果你跑的是 30B 的 GLM-5.3-Flash那 8 卡 H20 就是另一种完全不同的富裕状态。1.2 KV Cache看起来不起眼吃显存是真狠大模型推理的时候每个并发请求都要维护一段 KV Cache。它的计算公式各框架大同小异核心变量是层数、KV 头数、每头维度、上下文长度和并发数。我们拿 300B 模型常见的量级粗略估算假设 64 层、KV 头数为 8、每头维度 128上下文长度 32K并发 16 个请求每个 token 的 KV 占用 2 × 64 × 8 × 128 × 2 字节 ≈ 262KB32K 上下文 × 16 并发 32 × 1024 × 16 ≈ 52 万个 token总 KV ≈ 262KB × 524288 ≈ 137GB所以前面剩的 168GB被 KV Cache 分走 137GB 之后实际余量大概只有 30GB 左右。再扣掉 CUDA 上下文、推理框架临时 buffer、显存碎片基本就是把显存跑到 95% 以上处于一种“能跑但任何风吹草动都容易 OOM”的临界状态。这也是为什么很多部署老手会给同一个问题完全不同的答案单用户、短上下文、跑 Flash 版本8 卡 H20 可以说“绰绰有余”但如果是高并发、长上下文、跑 300B 满血主线模型8 卡 H20 只能算“刚刚摸到及格线”。2. 8 卡 H20 的完整配置清单不只是插八张卡那么简单2.1 服务器硬件底座怎么搭H20 这种卡单张 96GB 显存8 张就是 768GB。但硬件底座要是没配好显卡再多也白搭。我给当前这套机器的配置列出来基本是中等偏上的可复现方案双路 CPU建议 32 核以上内存通道尽量拉满系统内存512GB 起步1TB 更从容GPU8 张 H20用 NVLink 全互联或至少 PCIe Switch 组网系统盘2TB NVMe SSD用来放模型缓存和日志数据盘看你的语料规模4TB 起步比较保险网络对外服务至少 25GbE多机规划直接上 100GbE RDMA为什么系统内存建议 1TB因为模型下载、格式转换、量化合并这些操作经常需要在内存里做中转。权重从磁盘读到内存再加载到显存内存要是只有 256GB可能转个 BF16 模型就到临界了。另外 H20 这块卡的显存带宽大约在 4TB/s 级别FP16 算力在同代产品里属于中上。它的牌面就是“大显存 高带宽”非常吃内存带宽的 LLM 推理场景正好是它的主战场但遇到大量矩阵乘法的场景就会相对吃力。理解了这个特性后面调参数时你就知道该往哪个方向使劲。2.2 软件栈选择vLLM / SGLang / Ollama 怎么选8 卡 H20 这种配置其实就是奔着正经推理服务去的软件栈一定要选对。vLLM目前最稳的选择。PagedAttention 做 KV Cache 管理Continuous Batching 提高吞吐代码更新快社区案例多。我的 8 卡跑 GLM-5.3 就是用的 vLLM。SGLang如果你要做复杂的结构化输出、Agent 多轮调用、需要 RadixAttention 复用前缀缓存SGLang 在某些场景下比 vLLM 更省显存但要接受它的配置项更复杂。Ollama适合个人玩票或低并发内部工具。Ollama 的优势是一键部署缺点是 8 卡并行支持不够灵活遇到 300B 这种大模型很难发挥全部卡的性能。LM Studio我个人只在 Windows 桌面环境临时验证小模型用服务器上不建议。一句话总结做内部验证、单机个人使用Ollama 可以做正经服务、多人并发、生产级部署直接上 vLLM没悬念。3. 实操从拉模型到把 8 卡跑满3.1 系统与驱动准备先把基础环境备好。我的机器是 Ubuntu Server 22.04 LTSNVIDIA 驱动用的 550 版本推荐直接用 NVIDIA 官方仓库装避免手动编译内核模块踩坑。# 安装 NVIDIA 驱动 sudo apt install nvidia-driver-550 # 重启后验证 nvidia-smiCUDA 这边vLLM 通常自带 PyTorch 重编译的 CUDA 依赖不一定需要手动装完整 CUDA Toolkit但装一个 12.x 的 CUDA 工具链也没坏处。检查一下 GPU 通信nvidia-smi topo -m如果显示 8 张卡之间有 NVLink 连接那多卡通信会顺畅很多如果只有 PCIe性能会差一截后续 tensor parallel 的效率就会受影响。3.2 用 vLLM 加载权重并设置张量并行我这边用的是 vLLM 最新稳定版启动命令直接指定模型路径和并行度python -m vllm.entrypoints.openai.api_server \ --model /data/models/glm-5.3 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --dtype bfloat16 \ --host 0.0.0.0 \ --port 8000几个关键参数我要单独讲一下它们直接影响能不能跑起来--tensor-parallel-size 8把模型切到 8 张卡上并行推理。300B 模型不用 8 卡并行根本加载不进显存这个必须设成 8。--gpu-memory-utilization 0.92vLLM 默认只会用约 90% 显存余量留给 KV cache。0.92 是我试下来相对稳定的值。如果设到 0.97 以上初期运行会有很高的 OOM 风险。--max-model-len 32768控制最大上下文长度。32K 是一个平衡点再往上调KV Cache 会呈线性增长768GB 显存马上就不够用了。--dtype bfloat16H20 对 BF16 支持好精度和显存之间比较均衡。3.3 并发、KV Cache 与显存上限的调优服务跑起来之后再观察显存占用。用nvidia-smi看单卡显存你会发现每一张卡都顶着 90% 以上。这时候很多人会慌其实这是 vLLM 把 KV Cache 提前预分配的结果不代表已经满载。真正要关注的是两个指标gpu_cache_usage和requests_running。可以在 vLLM 的/metrics接口拉到。如果gpu_cache_usage长期接近 1.0说明并发已经把 KV Cache 吃满了这时候要么降并发要么缩短上下文要么换量化模型。我实测了一组数据给大家参考 32K 上下文场景并发请求数KV Cache 占用系统表现4 并发约 35GB很轻松响应速度快8 并发约 70GB稳定偶见尾部延迟上升16 并发约 138GB显存吃紧需要配合较短上下文24 并发约 205GB明显超限出现 OOM 风险前面那段计算在这里就对应上了8 卡 H20 的总显存 768GBFP16 权重用了 600GB留给 KV 的预算其实只有 100GB 左右。这也意味着如果要上更高并发权重就必须换到 FP8 量化或者接受更短的上下文长度。3.4 用 Dify 接成对外应用模型服务本身只提供 OpenAI 兼容的 API面向业务还是要接应用层。最近 Dify 本地部署很火它天然支持自定义模型 API。流程是在 Dify 里选择“自定义模型供应商”或“OpenAI-API-compatible”填入 vLLM 服务的地址http://your-server-ip:8000/v1模型名填你部署时传入的模型名比如glm-5.3创建应用绑定该模型这样你在 Dify 里做 Agent 编排、知识库检索、工作流设计底层调用的就是这套 8 卡 H20 的本地推理服务。数据不出内网延迟也比云端 API 稳定适合对数据敏感或者需要深度定制的团队。4. 常见问题与排查技巧实录4.1 OOM 与显存碎片我第一轮部署时就踩了 OOM 的坑。启动 vLLM 时设了--gpu-memory-utilization 0.95结果并发一上来就报CUDA out of memory。后来排查发现两个原因一是 H20 显存虽然大但框架初始化时申请的 buffer 和 CUDA context 比想象中多预留比例不够。把--gpu-memory-utilization调回 0.92 后稳定了。二是显存碎片。多卡并行时每张卡的显存分配并不完全均匀某个卡被临时请求占满后新请求只能等旧的释放。这时候最好的办法是限制单请求的最大 token 数并控制并发上限。4.2 多卡通信慢另一个常见问题是 tensor parallel 后速度没有线性提升。我观察过一种情况8 张卡里某几张利用率只有 50%其他几张顶着 90%整体吞吐上不去。用nvidia-smi topo -m一看发现有两张卡之间走的是 PCIe 而不是 NVLink通信延迟直接翻倍。解决办法是换卡槽位置确保 8 张卡挂在同一颗 CPU 的 PCIe switch 下或者尽量用 NVLink 桥接。如果实在改不了物理拓扑就不要强行tensor-parallel-size 8改成 44 两个并行组配合数据并行反而更稳。4.3 量化后的质量损失显存实在吃紧的情况下很多人会把权重从 BF16 切到 INT4 量化。我的建议是量化可以但上线前必须做一轮质量回归。我试过把 GLM-5.3-Flash 量化到 INT4日常问答、摘要生成感知不明显但涉及代码推理和长文档内容抽取时会出现细节丢失。后来改用 FP8 量化质量损失小很多显存占用又比 BF16 省一半。如果你的 H20 支持 FP8 加速那 FP8 是 8 卡部署 300B 大模型时最推荐的折中方案。注意量化不是简单把权重转个格式就行建议用模型本身支持的量化工具或社区已验证的方案不要手写转换逻辑。转完后用一个覆盖业务场景的测试集跑一遍对比关键指标确认没问题再切生产。5. 到底够不够我的结论与经验回到最开始的问题8 张 H20 到底够不够我的答案分三种情况跑 GLM-5.3-Flash 这种几十 B 级别的轻量版本8 卡 H20 非常够甚至有点浪费权重用 BF16 加载后还剩大量显存可以堆并发单机跑个几十路并发没问题。跑 300B 级别主线模型但只做内部使用、低并发、短上下文8 卡 H20 够用但要把精度降到 FP8同时严格控制并发和上下文长度属于“1.0 版能上线但别指望余量很大”。跑 300B 级别主线模型还要做高并发对外服务8 卡 H20 就不太够了。优先考虑 16 卡方案或者在软件层把模型做蒸馏压缩、把业务请求做路由分流让轻量请求走 Flash 版本复杂请求才调度到满血模型。我个人实际跑下来的体会是这套 8 卡 H20 机器最适合的定位其实是“内部一个团队或者一个小型产品线的统一大模型底座”用它跑 Flash 版本加 FP8 量化的主线版本兼顾成本和效果。真到了线上大规模商用单机 8 卡无论如何都只是起点多机推理集群才是长期方向。最后再分享一个小技巧部署完成后不要只盯着显存占用记得把首 token 延迟和生成吞吐这两个指标一起监控。8 卡 H20 大显存高带宽的特性决定了它吃吞吐没问题但如果首 token 延迟过高多半是预填充阶段算力吃紧这时候该做的是优化 prompt 长度和减少并发排队而不是再加卡。