「大象过窄门」GLM-5.3-Flash 的 8 卡 P800 部署评估

328.4GB 官方 FP8 权重、8×96G 显存、34 层 KDA 线性注意力、11 层 DSA 稀疏注意力、288 个路由专家。模型已经开源，算子是否已经就绪，需要拆开来看。

一、引言：一头 321B 的大象，站在窄门前

GLM-5.3-Flash 在 ModelScope 开放下载时，官方权重即采用 FP8。62 个 safetensors 分片合计 328.4GB，模型总参数 321B、每 token 激活 18B。这是一头标准意义上的大模型：参数规模足够大，激活规模又刻意压小，专为推理场景设计。面对这样一头大象，8 张 96G 的 P800 就是那道窄门。

从显存口径看，TP=8 切分后单卡权重约 41GB，328.4GB 的权重落在 768GB 的总显存里并不构成障碍。真正需要回答的问题，不是权重放不放得下，而是这 41GB 的每一层、每一个算子，能否在 P800 上以融合 kernel 的形式真正跑起来。

本文的评估对象因此不是「能不能 load」，而是「load 之后还能不能快」。

二、背景：权重、硬件与适配栈

模型公开地址为：

https://www.modelscope.cn/models/ZhipuAI/GLM-5.3-Flash

官方权重为 FP8，具体格式为 e4m3、dynamic activation、block-wise weight_scale_inv。e4m3 以 4 位指数、3 位尾数表示浮点数，精度弱于 BF16，但在推理吞吐与显存占用之间提供更优的折中。dynamic activation 说明激活侧量化采用动态方式，block-wise weight_scale_inv 则意味着权重按块存储缩放系数的倒数，加载与反量化路径需要框架原生识别。vLLM 0.15.1 对 weight_scale_inv 的加载已原生支持，权重读取环节没有格式障碍。

部署环境为昆仑芯 P800，8×96G。评估使用的运行栈为 vllm-kunlun 与昆仑芯算子栈（kunlun_ops）。

单卡约 41GB 的权重占用，叠加 KV cache、激活值与 all-to-all 通信缓冲后仍在 96GB 之内。显存门可以过。

三、技术过程：架构盘点与算子对照

3.1 架构盘点

从 config 可见，GLM-5.3-Flash 的关键结构如下。

这 45 层不是均匀的 Transformer 栈，而是两种注意力机制的混合。34 层 KDA 采用线性注意力，short conv 的 kernel 为 4，64 个头、每个头 128 维；这类结构天然适合递推计算，长文本下不必为整段历史维护完整注意力矩阵。11 层 DSA 则采用 MLA 风格的低秩注意力：q_lora_rank 1536、kv_lora_rank 512，且 qk_rope_head_dim 为 0，意味着这部分没有 RoPE。两者叠加，模型在长上下文能力与推理效率之间做了明确取舍。

MoE 部分是 288 个路由专家加 1 个共享专家，每 token 激活 8 个，前 3 层保持 dense。288 选 8 的路由在专家并行下会产生跨卡通信，这是 8 卡场景绕不开的问题。Hyper Connection 与 Indexer 是两个相对新的组件：前者带 hc_mult=4、hc_sinkhorn_iters=20、mhc=true 的配置，后者带 index_topk=2048、index_kpool=4、index_n_heads=32 的配置。二者是否在设备端执行，直接决定层间延迟的量级。MTP 的 1 层多 token 预测与 1M 的 max_position_embeddings，则分别指向投机解码与长文本两套验证场景。

3.2 算子覆盖

KDA 递推算子在昆仑芯算子栈里有完整实现，入口为 fused_recurrent_kda_fwd，支持变长与投机解码快照。DSA、MLA、MoE 也有官方适配，来源与 DeepSeek V3.2 同族。FP8 的 weight_scale_inv 加载在 vLLM 0.15.1 中原生支持。就单点算子看，主要路径都有对应实现。

KDA 递推      fused_recurrent_kda_fwd    已覆盖
DSA / MLA     官方适配（DeepSeek V3.2 同族）  已覆盖
MoE 路由      官方适配                      已覆盖
FP8 加载      vLLM 0.15.1 原生支持           已覆盖
Hyper Connection  设备端执行                  待验证
GLM 风格 Indexer  现成算子                    待验证

3.3 部署过程

评估过程分四步。

1. 权重下载与字节级校验        通过
2. FP8 权重分片加载与 TP=8 切分  通过
3. 单卡与多卡启动服务            通过
4. KDA / DSA / MoE 分发路径核验  待完成

前两步没有悬念。第三步的「通过」需要谨慎解释：服务能启动，说明图能构建、权重能加载，但并不能说明热点算子已经落在融合 kernel 上。

四、「首发即适配」的冷静审视

官方给出的口径是「首发即适配」。这个判断放在部署评估里需要拆成两个问题：一是适配了什么，二是适配到了什么深度。

从目前可了解到的信息看，适配范围覆盖了权重加载与一部分算子。同时，适配路径中包含一部分原生 torch 实现。这意味着 0.1 tok/s 在口径上同样可以被计入「首发即适配」。这不是对官方结论的否定，而是对部署方验收标准的提醒：能运行与有性能，是两个不同的交付物。

部署方真正需要核验的是四点：

1. KDA 是否走 fused_recurrent_kda_fwd，而不是回退到 torch 递推
2. DSA / MLA 是否走融合 kernel，KV 是否按 MLA 结构压缩
3. MoE 是否走高效路由与设备端 all-to-all
4. Hyper Connection 与 Indexer 是否在设备端执行

其中第四点风险最高。现有算子栈中已有的是 DeepSeek-V4 风格的 C4 indexer，GLM 风格的 indexer 尚无现成算子，更可能先以 torch 实现跑通，再做性能优化。Hyper Connection 的 Sinkhorn 迭代若落在主机侧或原生 torch 路径，会在层间引入不可忽略的延迟。

把适配深度做一个分级，比「首发即适配」这一句更有信息量。

真正需要盯防的，不是下载任务 cron 里那一行会不会准时跑，而是评测脚本里那一条悄悄回退到 torch 的 fallback——它不报错，只会在吞吐曲线上「背刺」一下。

五、性能预期

从算力口径看，18B 激活的理论 decode 算力需求约是 27B Dense 的一半量级。以 27B 量级的 Dense 模型（如 Qwen3.8-27B）作为参照，GLM-5.3-Flash 每 token 实际参与前向计算的参数更少，理论上在 decode 阶段更省算力。这给 P800 留下了乐观空间，但理论值不构成结论。

18B 激活带来的算力红利，可能被 MoE 的 all-to-all 通信与 KDA 递推的实际表现部分抵消。288 个专家在 8 卡上做专家并行时，每 token 的 8 个激活专家需要跨卡分发与聚合；这一通信若不能与计算重叠，就会成为 decode 延迟的主要来源。KDA 递推在融合 kernel 下可以把短卷积与线性注意力的状态更新压成紧凑的设备端循环，回退到 torch 则会退化为逐层、逐 token 的解释执行。这些结论在 P800 上必须实测，不能由 config 推演代替。

六、结论

结论可以分两层。

第一层是「能过」。328GB 下载完成，权重字节级校验通过；FP8 分片加载、TP=8 切分与启动链路可行；34 层 KDA 与现有 GDN 部署经验同族，DSA、MLA、MoE 也有官方适配基础。在 8×96G 的显存约束下，权重层面的门已经过去。

第二层是「过得好不好」。风险集中在 Hyper Connection 与 Indexer 两个新组件。现有算子栈对 GLM 风格 indexer 尚无现成算子，Hyper Connection 的设备端执行路径同样需要验证。若这两处短期以 torch 实现兜底，端到端吞吐会先于正确性到达瓶颈。

对部署方而言，验收标准应改写为三行：权重可读、算子可达、吞吐可测。前两行已经具备证据，第三行才是「首发即适配」真正需要兑现的部分。大象过了窄门，但门框上有没有掉漆，只有吞吐曲线知道。