1. 为什么9B到106B会让整套推理方案推倒重来先说一个常识很多人以为模型变大无非是多插几张卡、把显存堆够就行。真正动手把 GLM-4.6V 从 9B 稠密版迁到 106B MoE 版之后我发现事情完全不是这么回事。模型参数量从 9B 涨到 106B变动的不只是显存容量需求而是整个推理引擎的调度逻辑、显存分配方式、并行策略甚至量化边界全都要重新设计。1.1 稠密模型与 MoE 模型的内存悖论9B 稠密模型如果用 FP16 存权重大约是 18GB 左右H100 的 80GB 显存塞进去之后还能剩下大量空间给 KV Cache单卡推理非常从容。但 106B MoE 模型就很有意思它的总参数量是 106BFP16 权重需要约 212GB 显存单卡绝对放不下可它的激活参数量每 token 实际参与计算的专家参数通常只有 14B 到 15B 量级计算强度和显存占用并不是线性关系的。这就是 MoE 的内存悖论——权重很大但单 token 计算量不大。推理瓶颈从算力不够变成了权重放不下和带宽不够。我在实际压测中做过一组对照9B 模型单卡 H100 下prefill 阶段计算密度很高GPU 利用率轻易可以冲到 90% 以上但 106B MoE 如果不做并行切分权重根本进不了显存。即使切到 8 卡 TP8每卡也要承受约 26GB 的权重驻留留给 KV Cache 的余量依然紧张。所以从 9B 到 106B第一件事不是调参数而是重新规划显存预算。1.2 视觉 token 带来的序列长度爆炸GLM-4.6V 和纯文本模型最大的区别在于它前面挂了一个视觉编码器。输入一张常规分辨率图片视觉编码器输出后可能展开成几百到几千个 patch embedding token。这些 token 在 prefill 阶段都会被拼接进输入序列直接冲击 KV Cache。我之前拿 9B 文本模型做压测的时候max_model_len 配 8192 已经觉得很宽裕。换到 GLM-4.6V 之后单张图加上上下文轻松超过 4096要是多图输入或者高分辨率场景序列长度上万是常事。KV Cache 的占用是序列长度 × 层数 × 每层 KV 头维度 × 2K 和 V× 精度字节数这样乘出来的序列长度翻倍KV Cache 同步翻倍。视觉模型一到手KV Cache 预算就得再乘三到五倍。vLLM 之所以在这个场景下成为主力推理框架核心原因就是它把 KV Cache 的显存管理做到了极致——下面专门说。2. vLLM 在 H100 上到底啃下了哪些硬骨头vLLM 能成为社区主流推理引擎不是因为 API 好用而是它把 GPU 推理的显存利用率和调度效率拉到了一个新的量级。H100 上跑 GLM-4.6V 这种视觉多模态大模型vLLM 有三个机制是决定性因素。2.1 PagedAttention 让 KV Cache 从浪费变成挤着用传统推理框架给 KV Cache 预分配连续显存预分配多了浪费少了就 OOM。vLLM 的 PagedAttention 用操作系统虚拟内存的分页思想把 KV Cache 切成固定大小的 block按需分配随用随回收。这直接改变了显存利用率的下限。我在 8×H100 上做过统计关掉 PagedAttention 的框架静态预分配 KV Cache 利用率大概只有 60% 左右换成 vLLM 之后可以稳定在 90% 上下。这意味着同样的显存能同时服务的并发请求数差了一大截。对于 GLM-4.6V 这种动辄就要吃几千 token 的视觉模型KV Cache 余量就是并发天花板——PagedAttention 省出来的这部分显存直接变成了吞吐量。2.2 Continuous Batching 与抢占机制vLLM 的 continuous batching 做得比传统 static batching 聪明得多。它不要求同一个 batch 的请求同时开始同时结束而是某一个请求 decode 完一个 token 就可以离开新请求随时可以插入。这个机制在长尾请求比如视觉问答里有的请求只生成十几 token、有的要生成几百 token混跑时能让 GPU 的利用率平滑很多。实际压测里我用混合长短请求跑过对比静态 batching 的吞吐大概只有 continuous batching 的 60%而且延迟抖动非常明显。GLM-4.6V 的视觉输入天然会产生长度差异极大的请求这个机制基本是必需品。2.3 Chunked Prefill 解决了 MoE 大模型的算力饥饿Prefill 阶段要一次处理整个输入序列计算量巨大decode 阶段一次只生成一个 token计算量小很多。如果把两者放在同一个 batch 里GPU 在 prefill 和 decode 之间切换会产生比较明显的利用率低谷。Chunked Prefill 的策略是把长输入的 prefill 切成小块和 decode 请求交错执行。小块的 prefill 计算规模刚好可以填充 decode 阶段的算力空隙。我在 8 卡 H100 上跑 106B MoE 模型时开启 chunked prefill 之后整体吞吐提升了差不多 20 到 30 个百分点。对大模型推理这种以把 GPU 喂饱为目标的场景这个提升非常可观。3. GLM-4.6V 从 9B 到 106B 的全链路配置实战下面给出一套我实际跑通并且压测过的配置。它的适用环境是 8×H100 80GB NVLink 互联vLLM 使用最新稳定版本模型用 FP16 或 FP8 权重视觉编码器部分用原生 PyTorch 的视觉前处理管道。3.1 基础推理参数与显存预算先说一组我最终稳定使用的核心参数参数9B 稠密模型106B MoE 模型gpu_memory_utilization0.900.92max_model_len1638412288max_num_seqs6432tensor_parallel_size18KV Cache 量化不开启FP8同时开启 KV Cache 量化权重精度FP16FP8 W8A8为什么 106B MoE 把 max_num_seqs 从 64 降到 32因为 MoE 模型每层有多个专家每个 token 要经过路由选择专家显存带宽消耗比稠密模型大。并发太高会导致 decode 的 token 生成速度下滑TTFT 和 TPOT 一起恶化。我在压测中发现 max_num_seqs64 时吞吐虽然略有提升但单个请求的延迟严重恶化——这不是榨干算力这是牺牲体验换吞吐。gpu_memory_utilization 我为什么敢配 0.92因为视觉编码器的权重和临时激活值需要额外显存。GLM-4.6V 的图像编码部分如果完全加载要吃掉 2 到 4GB 不等具体看视觉塔的大小。如果这个值配得太高视觉编码器加载时容易 OOM。0.92 是一个偏激进但实测稳定的值。3.2 张量并行与序列并行的选择106B MoE 模型 212GB 的 FP16 权重8 卡 H100 单卡分到约 26.5GB。只是做权重切分的话TP8 是自然选择。但这里有个坑GLM-4.6V 的 MoE 层里专家数很多TP8 时每个专家要被切到 8 张卡上专家间的 all-to-all 通信量非常惊人。我在实验里对比了 TP8 和 EP8 两种方式并行方式通信特点实测结果TP8每层都需要全卡 AllReduce实现简单但通信量大延迟偏高EP8专家按卡分布token 路由到目标卡通信集中于 MoE 层理论上更高效对于 GLM-4.6V 这种 expert 数量多、单 expert 参数量不小的模型纯 EP 方案在 vLLM 里的支持成熟度不如 TP。最终我采用的是 TP8 加 sequence parallel 的组合——vLLM 内部对序列维度的并行处理已经比较完善配合 TP 使用attention 部分的通信被显著压缩。如果你只准备 4 卡 H100 来跑我最开始也试过 TP4单卡权重驻留约 53GBKV Cache 余量只剩十几个 GBmax_num_seqs 被迫压到 8视觉序列稍长就 OOM。所以结论很直接106B 级别模型8 卡起步不要再想省卡。3.3 量化策略FP8 和 KV Cache 量化FP16 权重在 8 卡上虽然放得下但 KV Cache 的空间会很紧张。我最终选择 FP8 W8A8 方案同时开 KV Cache 量化。模型权重从 212GB 降到 106GB单卡权重驻留直接砍半KV Cache 预算多了将近 60GB这个空间直接转化为并发能力。量化损失方面我专门做了评测GLM-4.6V 在 FP8 下做数学题、视觉描述、多轮对话和 FP16 的基准结果差异很小评测集上的分数差距在 1% 以内。但如果是跑代码生成或长文档任务FP8 下的长文本连贯性会稍差一些这时候需要手动打开 vLLM 的 KV Cache FP8 量化注意它默认按 per-tensor 量化某些注意力头比较敏感的时候会掉精度——我的经验是把量化粒度调到 per-token/per-head速度损失不大精度恢复明显。还有一点容易忽略视觉编码器部分最好不要量化。我一开始图省事把视觉塔也转了 INT8结果图像 feature 的质量下降直接导致整体回答准确率掉了三个多点。视觉编码器保持 FP16只量化 LLM 主干这是折中下来最好的方案。3.4 投机解码在 MoE 模型上的特殊收益投机解码Speculative Decoding的原理是先用一个小模型快速猜测多个 token再用大模型一次验证。我在 9B 模型上试过投机解码收益不大因为 9B 本身速度就快小模型猜中的概率不高验证失败反而浪费算力。但 106B MoE 模型是投机解码的最佳场景大模型单次 decode 慢小模型猜几个 token 的成本很低一旦猜中一个大段整体延迟能明显下降。实测中我配了一个 1B 左右的草稿模型接受率在 60% 到 70%decode 速度提升约 1.8 倍。这里要提醒视觉部分的输入 token 不走投机解码只有文本生成阶段受益。所以评估收益时要看整体端到端时延而不是只看 decode 阶段。3.5 视觉编码器的批量复用很多人在跑 GLM-4.6V 时忽略了一个细节并发请求里如果有多张图片视觉编码器的前向计算是可以批量共享的。vLLM 的 recent 版本已经支持视觉 token 的连续批处理我把图像预处理和编码统一放到了请求解析阶段避免每张图单独做一次编码器推理。多个请求携带同一张图片时还可以直接复用之前算好的视觉 embedding——这个技巧在检索型应用里尤其有用缓存命中率能到 30%。我在内部聊天机器人场景里做了 A/B 测试加上视觉 embedding 缓存之后带图请求的平均 prefill 时间降低了差不多 35%。4. 压测方法论别被吞吐量这个单一指标骗了把配置调好之后还需要一套可靠的压测方法来验证榨干 H100到底做到了什么程度。4.1 三个核心指标的定义与分解做推理优化最怕只看一个吞吐数字就下结论。我建议至少固定这三个指标指标含义关键性TTFTTime To First Token从请求发出到第一个 token 生成的时间决定用户第一感知TPOTTime Per Output Token生成一个 token 的平均时间决定生成流畅度Throughput吞吐token/s全系统每秒生成的 token 总数决定服务成本对视觉模型还要额外记录一个图片编码耗时因为图片分辨率、张数会直接影响 prefill 阶段耗时。TTFT 里至少有一半时间消耗在视觉编码和 prompt 处理上。4.2 并发压测扫出拐点我用的压测方法是固定输入序列长度和输出长度把并发请求数从 1 开始逐级增加到 8、16、32、64、96每档跑 5 分钟记录三个指标。观察曲线非常有意思。8 卡 H100 上106B MoE 在并发 32 之前吞吐接近线性增长到 64 时吞吐增速明显放缓TTFT 开始恶化96 时吞吐几乎不再上涨TPOT 飙到无法接受。这个拐点就意味着并发已经撞上了显存和算力的综合上限。用这份数据回推服务配置时我会建议把生产环境的 max_num_seqs 设在 32而不是 64——虽然 64 的吞吐略高但延迟预算是大多数在线服务不能接受的。4.3 让压测数据可复现我一直强调压测数据如果不可复现就失去了调优的意义。所以要固定几个变量模型权重版本、vLLM 版本、量化配置、输入输出长度分布、并发模型、GPU 频率是否锁定。我踩过最大的坑是跑同一份压测脚本两次结果的吞吐差 15%最后查到是 GPU 自动降频导致的——服务器散热波动让 H100 的 boost 频率不稳。正确做法是用nvidia-smi -lgc锁定 GPU 频率或者至少记录压测期间的 GPU 温度与功耗曲线。保证这些底层变量一致后续调参才有意义。5. 实战踩坑记录四个让性能暴跌的隐形陷阱配置看起来都对了压测起来却动不动出问题。下面这四个坑是我在 GLM-4.6V 106B MoE 部署过程中真实遇到的每一个都花了不少时间定位。5.1 显存明明够用KV Cache 却在峰值期 OOM现象是并发一上来就报显存不足但看 gpu_memory_utilization 才 70% 多。后来定位发现vLLM 的 KV Cache 是按 block 预分配的如果 max_num_seqs 和 max_model_len 配得太大峰值时 KV Cache 的占用会瞬间拉满而视觉编码器在并发高时也需要额外显存做中间激活。解决办法是把 max_model_len 精确对齐到业务实际最长序列而不是盲目配大。我把 106B 模型的 max_model_len 从 16384 降到 12288KV Cache 的冗余量立刻宽裕了峰值 OOM 再也没出现过。5.2 MoE 专家的慢专家拖垮延迟MoE 模型的 expert 路由是动态的有些热门专家会被高频访问导致某些卡的负载远高于其他卡。我在 8 卡上跑过一版实验其中一张卡的利用率到 95%另外几张只有 60%整体吞吐被那张高负载卡卡脖子。vLLM 跑 MoE 时的组网粒度决定了它很难做到完美的专家负载均衡。我能做的优化是在服务层面做请求分流让不同类型的请求比如代码问题、图像理解、长对话分散开这样 expert 的激活分布会更均匀。另外一个实用技巧是开启 vLLM 的 expert 并行和通信优化选项实测能让慢专家场景的延迟抖动减少 15% 左右。5.3 多轮对话里的前缀缓存失效很多团队会开 prefix caching 来加速重复前缀的处理。我在多轮对话场景发现一旦前一轮生成的答案发生变化前缀缓存就会大面积失效看起来命中了实际没用上。更隐蔽的是视觉部分图片 embedding 是固定的但图片 token 的前缀顺序变化会导致缓存 key 不匹配。后来我统一了 prompt 组装顺序把图片 token 固定在系统提示词之后、用户文本之前前缀缓存的命中率才稳定在 85% 以上。5.4 8 卡互联带宽成为瓶颈H100 的 NVLink 带宽很高但跨机场景比如用两台 4 卡机器拼 8 卡带宽掉得厉害。凡是用到 TP 的场景通信都发生在每层的前向计算中。跨机做 TP8 时MoE 层的 all-to-all 通信直接让吞吐掉了接近一半。我的建议很直接要跑 106B 级别 MoE坚持单机 8 卡不要跨机拼卡。如果实在只能跨机优先考虑把模型切到 DP 维度而不是 TP 维度——跨机场景下 DP 的通信量远低于 TP。6. 关于榨干算力的一点个人体会最后说点题外的。很多人做推理优化有个执念把 GPU 利用率刷到 95% 以上仿佛只要转起来了就是赚到。我跑了这么多轮压测之后发现真正的榨干不是把显存占满、把算力用完而是在吞吐、延迟、质量三者之间找到那条最贴近业务需求的工作曲线。对 GLM-4.6V 这种视觉多模态 MoE 模型来说9B 版本是开箱即用、成本友好106B 版本是性能天花板、但运维复杂度陡增。如果你刚接手任务我的建议是先跑小模型把整个链路视觉预处理、推理、后处理、评测跑通再切大模型。否则一上来就直接调 106B MoE你会同时面对并行策略、量化精度、显存规划、通信瓶颈四重问题排查效率极低。还有一个长期有效的经验压测之后别急着删脚本把每一档并发测试的原始输出存下来。我后面调参时经常回头翻旧数据用历史曲线来定位新配置的偏差来源比对起来非常高效。这类留痕习惯在很多工作里往往比多会一个优化技巧更值钱。