GLM5.3 flash cybersec本地部署[5]:生产运维与故障恢复

生产运维与故障恢复服务上线后要做的事仓库地址https://gitee.com/kill-life/glm5.3-flash-cybersec-sm80-vllm-deploy.git文章目录生产运维与故障恢复服务上线后要做的事概览1. 重启耗时构成三档场景与两个变量2. 监控指标五组信号与首个处置动作3. 常见故障与处置十项历史案例的最低限度动作4. 变更流程六步修改配置的正确做法5. 缓存目录管理属主与跨机迁移6. 镜像升级七步新镜像的使用流程7. 已知约束清单六项长期登记条目8. 交接说明与常用 make 目标概览重启耗时有明确构成全热 376 秒、半冷 520 秒、全冷NFS21 分钟起步。差异来自两个独立变量页缓存是否命中、cache/中的 JIT 产物是否完整。监控指标共五组权威存活探针/health而不是/v1/models、waiting 队列长度、MTP 接受长度守卫接受长度低于 1.5 表示投机解码未生效、KV 池账实核对部署形态二热重启基线为 1,320,553 tokens。常见故障与处置软链接空挂、三卡TP3不合法、KV 池未设上限、custom all-reduce 预热失败、首个请求 OOM、端口被占用、双实例同时加载、探活前缀误匹配、中间件未挂载导致 401以及一桩至今未复现的步时异常。变更流程共六步备份、重启、准入检查、采样运行基准测试、生成表格、复盘。.env不入库未走完流程的变更没有回滚依据。镜像升级共七步拉取新镜像后先做环境自检digest 变化会被检出再以新镜像为基底重新生成补丁并核对双启动路径最后必须通过准入检查与对比基准测试。1. 重启耗时构成三档场景与两个变量运维首先要记住三档场景的到就绪时间场景条件权重加载init engine总到就绪全热首选页缓存命中且cache/中四类 JIT 产物完整228-245 s31.5-36.1 s约 376 s半冷页缓存命中但更换了并行度或cache/为空261-293 s182.09 s约 520 s全冷新机器或页缓存未命中I/O 占主导同半冷21 分钟起步耗时差异只由两个独立因子决定页缓存是否命中决定权重加载耗时并行度是否变更决定init engine耗时。两者可以分别处理预热脚本warm_cache.sh针对前者cache/中四类 JIT 产物vllm、triton、tilelang、inductor的完整性针对后者。要等多久页缓存命中且 cache 目录完整约 376 秒就绪更换了并行度或 cache 目录为空追加约 150 秒 JIT 编译页缓存也未命中21 分钟起步先预热页缓存一条容易被忽略的运行约束双实例并存时权重加载本身需要排队。实测两个实例同时加载权重时checkpoint 反序列化会把 230 秒的加载拖到 690 秒以上慢约三倍同一时段的压测数据也随之作废。仓库的处理方式是文件锁加错峰启动加载阶段持独占锁、测量阶段持共享锁。2. 监控指标五组信号与首个处置动作建议同时监控五组信号每组信号都对应一个明确的判读结论与首个处置动作监控信号观测内容判读 / 行动建议存活GET /health返回 200引擎已死时/health返回 5xx而/v1/models仍可能返回 200需以/health为准负荷日志中的 running / waiting 队列行waiting 持续增长意味着并发已打满投机解码健康度接受长度是否低于 1.5接受长度低于阈值时先确认投机解码是否真的生效账实相符可用 KV 池与基线比对KV 池差额超过一成时先怀疑参数未生效而不是显存异常步时与 25.66 毫秒参考值的偏差记录某次步时从 25.6 升到 31.5 并持续约 15 分钟后自行恢复至今未复现——建议先重启引擎恢复服务3. 常见故障与处置十项历史案例的最低限度动作每条处置分两级第一反应先恢复服务根治动作再定位根因。编号症状关键词第一反应根治动作与来源1流水并行不支持报错检查镜像版本换用包含多流交接实现的 backport 镜像2加载期连续显存分配失败核对分配策略键确认expandable_segments:True在位01 篇与根 README 的分配器配置说明332k 请求导致引擎崩溃确认投机解码与 KV 上限是否配套显式设置 8 GiB 或 16 GiB 上限02 篇实测案例 24预热阶段 custom all-reduce 报 164 错核查部署形态一的开关设置将该开关置 1或切换到部署形态二03 篇5首个真实请求即 OOM检查总显存占用是否超额把上下文上限降到 512k、KV 池设为 8 GiB或切换到部署形态二以启用 1M 上下文E3 实验结论6端口被占用停止旧容器停服后重新启动或修改监听端口7双实例同时加载导致三倍变慢先停掉其中一个实例错峰启动或等待就绪05 篇测量准则 48探活误报其他实例仍存活复查匹配策略改用docker inspect精确匹配不使用前缀过滤仓库已修复勿回退9仅 Anthropic 客户端返回 401确认中间件挂载核对该行与鉴权目录挂载04 篇10权重路径类仓库校验错检查软链接在环境文件中写真实绝对路径01 篇一条原则故障处置的第一个动作都是读日志而不是重启重启是第二个动作且必须在证据保全之后执行。4. 变更流程六步修改配置的正确做法对配置文件的任何永久性修改都必须走完以下六个步骤约束一 备份cp 加时间戳.env 的唯一回滚依据二 重启serve 加 wait等待三档耗时之一三 准入检查四关全部通过才可继续四 采样运行一轮基准测试并入库标签按命名规范生成五 生成表格用渲染脚本重新生成表格不再手工誊抄六 复盘在变更说明中写清口径与前后差值供后续注释与复盘引用仓库CHANGELOG.md的开篇说明为这套流程提供了依据性能数字只有在测量口径一致的前提下才会被记录原始记录始终在bench/results/*.jsonl中变更日志只是索引。这也解释了本系列每篇都要强调测量准则与实测案例的原因口径不统一时导致错误结论的往往不是工程师的操作而是不可靠的测量结果。除正式流程外仓库也允许临时试验管理员可以为一次性对照实验临时设置环境变量并启动服务但长期方案必须写回配置文件并提交评审。临时值不会进入正式档案CI 也不接受这种配置。这条「临时方案必须转为正式配置」的规则避免了把一次性改动长期留在本地环境文件或临时文本中。5. 缓存目录管理属主与跨机迁移cache/下的四类 JIT 产物vllm、triton、tilelang、inductor由容器以 root 身份创建宿主普通用户直接删除会遇到属主权限限制正确做法是通过容器执行删除仓库提供的make clean-cache目标即为此。除供本机重启复用外缓存目录还支持跨机迁移相同 GPU 架构的机器之间可以整目录复制做法是打包与解包按CACHE_ROOT的相对结构打包成压缩件传输到目标机器后在对应位置解压。缓存目录的收益冷缓存下init engine需要 182 秒缓存命中后长期落在 31.5 至 36.1 秒区间。也就是说每次重启可节省约 150 秒。另一个变量同样重要重启前先运行一次预热脚本warm_cache.sh是运维手册的明确要求因为页缓存是否命中会显著影响权重加载耗时。两项措施同时落实后从冷启动到第一个 token 的整个耗时过程都在可预估范围内。多实例部署的四项必改变量如果需要在同一台机器上运行两个实例用于对照实验或按卡分配仓库要求四个变量必须同时修改。任何一项遗漏都会导致后启动的实例影响先启动的实例容器名不同否则后启动的实例会直接删除先启动的容器端口号不同否则启动时端口冲突缓存根不同否则两个实例争用同一份 Triton 缓存日志文件不同否则两路日志混写约束四项必须同时设置缺一项会导致实例互相干扰、数据作废6. 镜像升级七步新镜像的使用流程镜像升级会重新检验前面各篇的所有结论流程必须严格按以下七步执行拉取与自检拉取新镜像后立即执行一次环境自检setup.sh --checkdigest 变化会被明确报出这一步每次升级都要执行更新镜像字段更新.env中的镜像字段必要时固定IMAGE_DIGEST可复现性要求从项目初期就已采用重建补丁以新镜像中的文件为基底重新生成 overlay 文件然后重新施加本地补丁——严禁新旧两代 overlay 混用若新镜像已自带修复直接移除对应的挂载点核对双启动路径运行 compose 校验并确认 compose 与serve.sh两条启动路径的开关一致启动与准入检查依次执行serve.sh、wait_ready.sh与四关准入检查任何一关未通过都应停止升级对比基准测试以相同口径运行一轮基准测试并以升级标签入库与升级前的记录逐项对比准备回滚方案如果最终结果不理想从带时间戳的备份恢复环境文件、回退镜像字段再执行wait_ready.sh等待三档耗时之一重启一次即可回滚。这套七步流程并非冗余仓库曾出现过实际事故镜像内某协议文件换代时上一代补丁与新基底合并后不是行为失准就是完全未生效。检查只读挂载是否有效固然重要但以新镜像中的文件为基底重新生成才是根本解决办法。这条警示在overlays/README.md中以粗体标注是镜像升级中最关键的一条要求。7. 已知约束清单六项长期登记条目本套件把所有已知限制公开登记读者不必在遇到问题之后才发现这些限制一直存在。以下六项与根 README「已知约束」严格同号那份清单只保留当前仍未解决的条目已修复的移入CHANGELOG.md条目摘要1mamba_cache_mode只能用align且镜像不可回退prefix caching 本身已于 2026-09-26 起的镜像修复并默认开启残留两条none仍触发CUDA illegal memory access2026-09-10 及更早的镜像开了会返回空正文2 投机解码与 KV 上限必须配套MTP 深度大于 1 时必须显式设置 KV 上限部署形态一为 8 GiB部署形态二为 16 GiB留空会在 32k 请求上 CUDA OOM3 EP 与深 MTP 不叠加EP 单独使用收益明显并发 8 提升 54%叠加 MTP 后并发 421 对 421单流 32k 反而下降4 长上下文的单次读数不可信1M token 上下文的 TTFT 三次测量均为 312 秒早前一次 417 秒的孤立读数曾被写成「慢 34%」的结论现已更正并记录在案5 并行拓扑TP 越大 prefill 越慢all-reduce 跨 PCIe 的代价。两条硬约束TP2×PP2装不下「1M MTP 6 CUDA graph」默认上限 512k且必须DISABLE_CUSTOM_ALL_REDUCE14 卡TP4的 1M prefill 慢于 3 卡PP3312 s 对 200 s6 未定因的解码退化长时间运行后 2k 档步时从 25.6 ms 升到 31.5 ms约 15 分钟后重启恢复已排除 KV 碎片化、持续负载、功耗节流与其他租户尚未复现8. 交接说明与常用 make 目标makedoctor —— 只读环境自检makewarm —— 预热页缓存makeup —— 启动服务makewait—— 等待就绪makelogs —— 跟随日志makedown —— 停止并删除容器部署的目标不只是让服务运行起来而是让下一个接手的人能追溯每一个数字的出处。本系列各篇的实验记录、本章的六项已知约束以及通篇记录的测量口径共同构成了这套部署的可追溯基础。