背景概述在使用 MindIE 推理框架部署大模型服务时，部分在高并发、长序列推理场景下反馈存在容器内存持续增长的问题，严重时导致服务被系统终止，影响业务连续性。问题现象在使用 MindIE 2.2.RC1 版本部署 DeepSeek-V3.1-w8a8 模型服务时，在双机 A2 环境下通过 K8S 拉起推理服务。在特定高并发、长输出的推理负载下，容器内存占用呈现持续上升趋势，最终触发系统 OOM 机制，容器被强制终止，服务不可用。排查过程 1.现场日志分析通过分析 K8S 容器日志，确认容器崩溃原因为 host 内存不足，触发 OOMKilled。由于容器已销毁，无法获取完整运行时上下文。 2.内存占用复现在复现环境中部署内存实时查看工具，发现 mindie_llm_back 单进程内存占用高达 48.1 GB，远超正常水平。 3.K8S 内存曲线数据显示，容器内存在某一时刻出现剧烈跳升，与现场业务脚本调用时间点高度吻合，提示问题与特定请求模式存在关联。 4.实验室环境复现搭建与现场一致的 MindIE 2.2.RC1 环境，使用 128 输入 / 10 输出、3000 并发的混部测试场景，通过 aisbench 模拟请求。测试过程中观察到 mindie_llm_back 进程内存从初始 3.8 GB 持续增长至 16.6 GB，测试结束后内存未释放，确认存在内存泄漏。 5.版本对比验证将服务升级至 MindIE 2.3.0 版本，在相同测试条件下，mindie_llm_back 内存最终稳定在 5.4 GB，处于正常范围，表明问题在新版本中已修复。 6.代码逻辑对比分析对比 MindIE 2.2.RC1 与 2.3.0 版本中缓存管理模块的实现差异，发现关键差异点： ○2.2.RC1：clear 函数仅检查当前 batch 中被标记为结束的 sequence（seq），未对已结束但不在当前 batch 的请求进行清理。 ○2.3.0：引入反查机制，遍历所有已结束的 sequence，确保缓存被完整释放。在异步调度场景下，P 任务频繁打断 D 任务，导致部分已停止的 decode 请求缓存未被及时清理。由于 generator 检测到缓存空间不足，持续申请更长的缓存队列，形成内存泄漏。问题根因 MindIE 2.2版本在开启异步调度后，p频繁打断d的业务场景下，由于部分请求缓存未释放，使得generator不断申请内存空间，导致内存泄漏问题。参考文档：https://www.hiascend.com/document/detail/zh/mindie/230/mindiellm/llmdev/mindie_llm0512.html 解决措施建议将 MindIE 推理服务升级至 2.3.0 及以上版本，以规避该内存泄漏问题。新版本通过反查所有已结束 sequence 的方式，确保缓存清理无遗漏，从根本上解决该问题。建议与总结 ●版本升级：若当前使用 MindIE 2.2.RC1，且存在高并发、异步调度场景，强烈建议升级至 2.3.0 或更高版本。 ●问题识别：可通过日志中是否出现“cache size expanded”等扩容信息，辅助判断是否触发该问题。 ●性能保障：新版本在保持高性能的同时，显著提升了内存管理的稳定性，适用于生产环境长期运行。