GLM-5.3 自托管测评：4 张卡装得下，跑长会话得 8 张——结论、用途、怎么算账

测评结论先说清楚：GLM-5.3 在 4 张卡上装得下，不等于在 4 张卡上跑得动长编程会话。Revolut 的 David Abitbol 在 10 月 29 日的分享里讲，服务约 2000 名工程师大约要 56 张 B200，首 token 要压在 3 秒以内，256K 上下文就够了，用 Blackwell 卡上的 NVFP4 量化比 FP8 小约 40%。一篇 10 月 30 日基于 vLLM 源码的分析把账算细了：权重可以按张数切分，但 KV 缓存——也就是模型记住每段对话的内存——在 vLLM 0.32.0 里不切分，每张卡都存一份完整副本。于是 4 卡 NVFP4 配置下，每个模型副本在 256K 会话长度只能撑约 3.0 个完整长会话，8 卡能撑约 7.6 个；FP8 光权重一项就超出了 4 卡的预算，8 卡约 4.73 个会话。这些是脚本测算数，作者自己注明没有在 B200 上实跑，别当成实测成绩单。

能用于啥：这套配置对应的不是个人尝鲜，是持续跑编码 agent 的团队——代码不能外传、用量可预测、或者每天都有大量长会话在跑的场景。Spectro Cloud 的厂商基准可以当个参照：8 张 AMD MI325X、FP8、跑 5 小时模拟，60 名开发者加 15 个 agent 并发，热请求首 token 中位数 406 毫秒；按持续利用率算，托管 API 要贵 3.3 到 20.6 倍。但要标注口径：这是厂商自己的基准测试，不是中立第三方复测，贵的倍数随利用率大起大落。

怎么用：预算别按“装不装得下”算，按“每个副本能同时撑几个长会话”算，再乘以你们的并发数。先走官方 API 验证 GLM-5.3 在你们的任务上到底行不行，效果不过关，卡数白算；效果过关，再拿 90 天真实用量去比 API 账单和租卡成本，别拿峰值想象去租。许可也要单独核对一遍：有资料称 GLM-5.3 的许可不再是 plain MIT，大型 API 提供方要过安全审查，别默认沿用旧许可。

什么情况下这个结论不成立：如果你的会话都很短、或者前缀缓存命中率很高，4 卡的缓存压力没那么大，8 卡的结论就 overkill 了；如果只是一个人偶尔跑跑，API 永远比自托管便宜，自托管的门槛和运维成本会把省下的钱全吃回去。还有一个数字会变的口径：换 FlashMLA 后端后每层缓存从 576 字节变成 656 字节，测算会降到 4 卡 2.66、8 卡 6.76 个会话——绝对数变了，8 卡仍是 2.5 倍以上的结论没变。