GLM-5.2 本地推理基准：ubatch 尺寸显著影响长 prompt 吞吐

近日 Reddit 用户 fuzhongkai 在 r/LocalLLaMA 分享了对 GLM-5.2 模型本地推理性能的测试结果，重点对比了 ubatch（微批次）尺寸对不同 prompt 长度下吞吐量（tokens/sec）的影响，同时比较了 llama.cpp 与其自研推理引擎 TensorSharp 的表现。

测试环境与方法

硬件：3 张 RTX PRO 6000 Blackwell GPU，通过 PCIe 互联（无 NVLink）
模型：226 GiB 的 GLM-5.2-UD-IQ2_XXS GGUF 量化版本
工具：llama.cpp 与 TensorSharp（作者自研开源推理项目，已声明利益相关）
指标：pp（prompt processing）与 tg（text generation）两类吞吐量，单位 tokens/sec，同机连续测量

关键基准数据

在相同硬件下，作者给出了三组配置（llama.cpp、TensorSharp ubatch=1024、TensorSharp ubatch=2048）的对比：

pp128：276.5 / 254.8 / 264.4 t/s —— 短 prompt 下差异不大
pp512：695.4 / 666.9 / 659.6 t/s —— 差距仍有限
pp2048：763.1 / 918.9 / 1145.8 t/s —— TensorSharp ubatch=2048 显著领先
pp4096：715.8 / 864.7 / 1048.7 t/s —— 长 prompt 下差距进一步拉大
tg64：42.2 / 43.7 / 43.9 t/s —— 文本生成阶段三者几乎持平

数据表明，ubatch 增大对短 prompt 收益有限，但当 prompt 长度超过 2048 后，TensorSharp ubatch=2048 的优势迅速放大。

MoE 架构是性能差异主因

作者将这一现象归因于 GLM-5.2 的 256 专家 / top-8 MoE 结构。在小 batch 场景下，每个激活专家分到的 token 数有限，expert GEMM 难以充分利用 GPU 计算单元；增大 ubatch 后，单个专家获得的计算量上升，GPU 利用率随之显著提高，这一效应在长 prompt 下尤为明显。

层切分优于张量并行

在多卡部署方式上，作者也对比了 TP（张量并行）=3 与简单的层切分：

pp2048：层切分 896.8 t/s，TP=3 仅 502.8 t/s
tg64：层切分 43.9 t/s，TP=3 仅 16.2 t/s

由于该机器上三卡仅通过 PCIe 互联、无 NVLink/NVSwitch，张量并行引入的通信开销主导了延迟，导致性能反而远低于朴素的层切分策略。

对本地部署者的启示

该测试结果对计划在多卡 PCIe 环境部署大型 MoE 模型的开发者提供了两点参考：一是将 ubatch 调高是提升长 prompt 场景吞吐的有效手段；二是在缺乏高速互联时，层切分通常比张量并行更稳妥。NVLink/NVSwitch 环境下 TP 是否能反超层切分，仍有待社区进一步验证。