GLM-5.2本地部署不能只看“模型能不能启动”。对工程实施来说更重要的是把权重、KV Cache、运行时、上下文长度、并发序列、服务治理和上线验收放在同一套测试框架里。基础配置口径GLM-5.2可以按约744B总参数、约40B激活参数理解。MoE激活参数不能用于直接估算完整显存需求。当前可参考的部署边界目标参考配置说明FP8单节点部署8×H200 141GB / 8×H20 141GB用于企业POC、Coding Agent、常规长上下文完整1M上下文8×B200 180GB FP8 KV Cache为长请求KV Cache保留更多空间Q4量化验证8×80GB或96GB级GPU用于低并发POC需验证后端和质量Q4_K_M约373GB属于第三方GGUF量化路线不等同于原生FP8。生产前必须对代码生成、工具调用、长文档引用和结构化输出做回归测试。KV Cache规划逻辑常规Transformer中KV Cache可按以下趋势理解KV Cache与层数、KV头数、head_dim、token数、元素字节数和活跃序列数相关。GLM-5.2使用稀疏注意力与IndexSharevLLM采用分页KV管理实际占用应以启动日志和运行时指标为准。工程上要重点观察token长度输出长度活跃序列数GPU显存水位KV block使用情况队列等待时间OOM与重试日志。vLLM的PagedAttention可以提升KV Cache管理效率但不代表KV Cache消失。长请求和高并发仍然需要做容量规划。关键参数参数作用调参建议max-model-len服务最大上下文窗口按业务峰值设置不必默认1Mmax-num-seqs一次调度的活跃序列数长请求OOM或排队时优先下调kv-cache-dtypeKV Cache精度使用FP8 KV后做质量回归gpu-memory-utilization显存使用比例为运行时、CUDA Graph和突发请求留余量prefix caching前缀复用只对共享前缀有效speculative/MTP解码阶段优化需观察接受率和端到端收益max-num-seqs不是业务在线人数。业务侧并发还会受到请求长度、输出长度、限流、队列和连续批处理影响。推荐测试顺序1.固定模型版本、框架版本和驱动环境2.用32K单请求建立质量与性能基线3.提升到64K、128K、256K、512K4.固定上下文后增加并发5.加入长短请求混合6.加入工具调用、RAG和结构化输出7.根据OOM、P95和队列等待调整max-num-seqs8.最后验证接近1M的低并发任务9.启用FP8 KV Cache、Prefix Cache、MTP后做对照测试10.输出容量边界和上线风险清单。POC测试矩阵维度测试内容记录字段任务质量高频任务、复杂任务、高风险任务完成率、人工评分、失败类型上下文32K、128K、业务峰值、接近1MTTFT、P95、显存水位、OOM并发1路、目标并发、峰值并发、混合请求队列等待、错误率、吞吐工具调用成功、失败、超时、无权限调用成功率、恢复策略量化回归FP8/API/Q4对照代码质量、引用准确性、结构化输出稳定性持续运行、异常请求、服务重启恢复时间、日志、错误类型生产参考架构业务应用→ API网关认证、限流、配额、路由、日志→ 编排层RAG、工具调用、会话、任务队列→ 模型服务vLLM/SGLang、GLM-5.2、模型路由、降级→ 基础设施GPU服务器、CPU、内存、NVMe、网络→ 运维安全监控、告警、审计、灰度、回滚生产上线前建议将模型版本、框架版本、启动参数、GPU拓扑、驱动版本、任务集版本、测试结果统一记录便于复现和排查。FAQ1. GLM-5.2为什么不能按40B模型配卡40B是激活参数完整权重仍需加载或分布到GPU节点不能按普通40B dense模型估算。2. max-model-len应该直接设为1M吗不建议。应按业务峰值设置。大多数请求集中在32K或128K时默认1M会增加资源压力。3. max-num-seqs怎么调长上下文OOM、P95升高或队列变长时优先下调短请求占比高且显存有余量时再逐步上调。4. FP8 KV Cache会影响质量吗可能影响需要对代码生成、长文档引用、工具调用和结构化输出做回归测试。5. Prefix Cache能不能解决1M显存问题不能。它适合共享前缀复用独立长请求仍然需要活动KV Cache。6. Q4量化适合生产吗适合POC和内部验证。生产使用前必须做FP8/API对照回归。7. POC最终应该交付什么配置建议、参数基线、容量边界、质量回归结果、风险清单和上线验收口径。